Т.е. именно, что построить secrets lifecycle management

p.s. есть нюансы но все же память отдельных процессов изолирована, и дампить память просто так - это прям нужно жирные дырочки

Если есть рут, то приплыли

Если есть рут, то приплыли

если есть рут - то да, приплыли. потому этот вариант надо рассматривать последним с точки зрения рисков (там по другому вопросы решаются)

есть другие проблемы - представь что у тебя вротпресс какой в контейнере или еще какое мракобесие. Или недоразработчик оставил какую-то отладочную информацию. И прочее. И секреты ты в переменных окружения хранишь. Если токен для волта там - то у тебя обычно доступ на внешку к апишке волта нету. Потому токен (который ты должен раз в недельку ротацию делать) экспоузить не так критично. А вот остальные секреты - это уже другое. Ну и в целом я бы как первый пункт чеклиста делал бы "отрезать доступ с внешки в внутренним ресурсам типа базы"

ну то есть к вопросу управления секретами стоит возвращаться когда ты уже знаешь как можно к ним подобраться.

и какие риски если вдруг заэкспоузят пароль от твоей базы. Если помимо секретов ты и остальные вещи нормально делаешь - то риски от экспоуза таких данных низки

а вот если у тебя там какие-нибудь секретные ключи для работы с... хз... секретный ключь от биткойн кошелька, токены от всяких сэндгридов/мэйлганов и прочее... все что можно заюзать отдельно и получить доступ из вне. тут надо уже запариваться с секретами. Опять же, с точки зрения рисков (а тут риск эксптуатации уязвомисотей приложения выше чем доступ к контейнеру, при этом даже риск выполнениия произвольного кода не столь высок) надо смотреть что куда прятать и что куда ложить можно.

а там дальше уже есть вопрос кому внутри команды можно видеть секреты, как их хранить (тут опять же волт, git crypt и прочее), как их пробрасывать и т.д. Это все уже отдельный вопрос и я полагаю что в основном это интересует @dmvw34 . Возможно я не прав но тогда вопрос составлен неверно

В данный момент меня интересует передача в контейнер данных подключения к БД и генерация конфига.

есть другие проблемы - представь что у тебя вротпресс какой в контейнере или еще какое мракобесие. Или недоразработчик оставил какую-то отладочную информацию. И прочее. И секреты ты в переменных окружения хранишь. Если токен для волта там - то у тебя обычно доступ на внешку к апишке волта нету. Потому токен (который ты должен раз в недельку ротацию делать) экспоузить не так критично. А вот остальные секреты - это уже другое. Ну и в целом я бы как первый пункт чеклиста делал бы "отрезать доступ с внешки в внутренним ресурсам типа базы"

Это не докер специфично

В данный момент меня интересует передача в контейнер данных подключения к БД и генерация конфига.

env - достаточно

Привет. Вопрос от почти новичка. Вот есть гитлаб. Есть у него раннер на шелле. На самом раннере установлен и движок докера и даже компоуз. Есть пайплайн гитлаба, в котором он подключается к этому раннеру и пытается запустить команду docker build с тегом и путем. Но в логах неудачной джобы пишет, что не может найти путь к докерфайлу. В гит-репозитории докерфайл лежит относительно gitlab-ci.yaml в папке /src/ui/Dockerfile. Что-то как не пишу я строку с билдом, он все никак этот файл не видит. Что я делаю не так? Или мне надо на раннер его копирнуть через cp?

- pwd - ls -la - cd ./src/ui - docker build

Или

- docker build -f ./src/ui/Dockerfile ./src/ui

- docker build -f ./src/ui/Dockerfile ./src/ui

А это нормально так делать - https://t.me/docker_ru/122514

я про докер файл

в гите

А это нормально так делать - https://t.me/docker_ru/122514

В смысле? Докерфайл не в корне?

я про докер файл

Нормально

Вообще нефиг корень проекта засорять

В общем решилось через две строчки. Лол, но pwd мне подсказал, что не так. Cp ./src/ui/Dockerfile . Docker build -t ui .

А так подкаталогов, как и докерфайлов много. Они все отдельно, дабы не засорять корень(мне показалось это ок)

Подскажите пожалуйста, volume прокидываются во время билда образа или же во время старта контейнера?

во время старта контейнера

во время старта контейнера

спасибо)

Подскажите пожалуйста, volume прокидываются во время билда образа или же во время старта контейнера?

Билд сборка

Существует ли какой то способ автоматизированно контролировать контейнеры? Через апи к примеру запускать новый контейнер с нужными аргументами, останавливать и т.п. Так же хранить инфу, запускался ли контейнер с данными аргументами или нет

Или же что то своё надо писать?

кубернейтс?

Существует ли какой то способ автоматизированно контролировать контейнеры? Через апи к примеру запускать новый контейнер с нужными аргументами, останавливать и т.п. Так же хранить инфу, запускался ли контейнер с данными аргументами или нет

salt? ansible?

или что нужно?

Или же что то своё надо писать?

Если хочется - пишите своё, но готовые решения, вроде kubernetes или docker swarm, есть

Просто возможностей не знаю. Главная задачка - динамично поднимать новые контейнеры с динамичными аргументами, затем о каждом хранить инфу, даже если он остановлен и если надо запускать заного. Пример - под каждого пользователя будет запускаться свой контейнер.

Ну, используйте kubernetes

То есть если нет инфы о контейнере остановленном/запущенном, то создать новый конфиг для его запуска ну и по условиям запускать и останавливать его

Ну, используйте kubernetes

Ох, страшно туда лезть)

ну, автоматизацию запуска - я предложил

для остального - да, к сожалению, кубернетес. Или мезос-номад

ну, автоматизацию запуска - я предложил

спасибо, буду гуглить эти варианты, смотреть какой подходит

для остального - да, к сожалению, кубернетес. Или мезос-номад

Я вот планирую свой маленький костыль написать (без хранения информации о том, работает контейнер или остановлен)

Я вот планирую свой маленький костыль написать (без хранения информации о том, работает контейнер или остановлен)

У меня условие примерно такое. Если пользователь в сети, то нужно запустить для него его уникальный контейнер. Если уходит в оффлайн, то остановить этот контейнер и сохранить о нём инфу и если пользователь вернулся, то запустить его же

У меня условие примерно такое. Если пользователь в сети, то нужно запустить для него его уникальный контейнер. Если уходит в оффлайн, то остановить этот контейнер и сохранить о нём инфу и если пользователь вернулся, то запустить его же

В сети, где

Что имеется ввиду

В сети, где

Есть общая точка входа скажем так.

Основной докер контейнер

Внутри которого крутится приложение, которое будет детектить онлайн/оффлайн пользователя

Внутри которого крутится приложение, которое будет детектить онлайн/оффлайн пользователя

Ну так напишите приложение, которое это будет делать (детектить, запускать/останавливать контейнер через API Swarm`a или Kubernetes`а)

Ну так напишите приложение, которое это будет делать (детектить, запускать/останавливать контейнер через API Swarm`a или Kubernetes`а)

угу, буду смотреть, апишка как раз то что нужно

Docker Swarm нативный, да и будет попроще кубера для Ваших целей

У меня условие примерно такое. Если пользователь в сети, то нужно запустить для него его уникальный контейнер. Если уходит в оффлайн, то остановить этот контейнер и сохранить о нём инфу и если пользователь вернулся, то запустить его же

ну, можно договориться как

именование контейнеров

и тогда стейт хранить не придется

единственное, что для каждого нового контейнера будут прокидываться volume базовые, которые уже будут модифицироваться в зависимости от действий пользователя

тут кажись уже надо будет всё таки свою приблуду пилить для хранения инфы о volum'ах

тут кажись уже надо будет всё таки свою приблуду пилить для хранения инфы о volum'ах

что понимается под "хранением инфы о вольюмах" ?

Через команду docker info Вы можете посмотреть, что и куда у Вас в контейнере примонтировано

о, спс

о, спс

Не то, docker inspect

подскажите нормальные варианты, надо бэкапить базу percona в докере, на innodb, желательно не поднимать никакие контейнеры и не перенастраивать основной контейнер, крайне желательно без остановки 1) натравить xtrabackup на директорию волюма /var/lib/docker/volumes/... 2) docker export и уже оттуда бэкапить

подскажите нормальные варианты, надо бэкапить базу percona в докере, на innodb, желательно не поднимать никакие контейнеры и не перенастраивать основной контейнер, крайне желательно без остановки 1) натравить xtrabackup на директорию волюма /var/lib/docker/volumes/... 2) docker export и уже оттуда бэкапить

точно не docker export

да и вообще - что мешает тупо сделать лвм бекап тома вместе с volume докера?

да и вообще - что мешает тупо сделать лвм бекап тома вместе с volume докера?

ну если это нормальный путь, то наверное это лучший вариант

ну, не худший - точно

а база не развалится?

от чего?

от снапшота? нет. А вот бекап - нужно проверять

пугает, что много элементов

бд -> docker -> файловая система хоста

от снапшота не развалится innodb?

при активной записи в неё

от снапшота не развалится innodb?

при востановлении

дак когда снимешь снапшот - он уже будет неконсистентный. буфферы же

восстановишь - попытается восстановиться, но гарантии нет, что восстановится (даблврайт и тд)

дак когда снимешь снапшот - он уже будет неконсистентный. буфферы же

еще чего. у него ж write barrier должен быть

?

https://www.lullabot.com/articles/mysql-backups-using-lvm-snapshots

народ делает так

https://www.digitalocean.com/community/tutorials/how-to-back-up-a-mysql-database-to-spaces-using-lvm-snapshots

а, ну вот, да: FLUSH TABLES WITH READ LOCK