Какой подход правильный в описании docker-compose?

Question

[mozzart_live]

Познания в контейнеризации близки к нулевым. Доки докера изучены и поняты на 30%.
Начитался различных, вроде опытных комментаторов на хабре и возникли вопросы, которые, как говорят, приводят к куче проблем в будущем:

1. Советуют не задавать явно networks, мол это делает сам докер для всех сервисов
2. Не нужно указывать container_name, но у меня одна нода = один инстанс приложения и наслоения быть не может
3. В контейнере Laravel. Советуют монтировать только storage, весь остальной код хранить внутри контейнера
4. Относительные пути в volumes - зло

Прошу знающих людей прокомментировать данные "факты" и при возможности объяснить, ошибаются комментаторы или же 99% статей по этой теме?

Answer 1

[mureevms]

1. Всегда лучше делать явно, чем не явно. Это упростит работу другим и себе же, когда пройдет полгода.
2. Это как минимум удобно. Контейнер всегда называется одинаково, вместо дурацких автоматических названий. Опять же, пройдет полгода, вы сами читаете конфиг компоуза и видите контейнер не пойми как называется, надо будет догадаться, что имя не назначено. Зачем усложнять?
3. По ситуации, нет верного ответа
4. Относительные пути тру. А вот абсолютные зло. При относительных путях вам надо просто перенести каталог на новый сервер и все запустится. Абсолютные придется править, а это усложнение.

Comments

[bro-dev]

Не согласен, идеал это зеро конфиг к нему стремимся, если написать сеть то другой разраб сразу задумается нафига так было сделано, мб у этого есть скрытый смысл до которого он не допер, это только путаницу создает.

[mureevms]

bro-dev, Если так было сделано, значит надо. Кто-то знающий в докер написал правильно и как считает нужным. Он дает конфиг и инструкцию как пользоваться написанным. Там не надо допирать, что именно написано, надо просто запустить одной командой.
С другой стороны, если указано явно, то для знающего понятно, что даже если и указана дефолтная сеть, то она указана для понимания. Если девелопер не знает какая дефолтная, то ему и понимать не надо, просто пользуйся.
Вспомните Expose портов для докерфайла. Вы лично понимаете для чего он нужен? Если да, то хорошо, но это не обязательно понимать разрабу. Написано для тех, кто в курсе и кто может прочесть. Кто не может, да и не надо, это не его задача.

Answer 2

[Михаил]

1. По ситуации. Иногда это более чем оправданно. Не стал бы возводить это в абсолют
2. Опять же - по ситуации. Иногда требуется.
3. Вопрос с обновлением этого самого кода. Если он лежит на volume, то обновить не проблема (в том числе и изнутри контейнера). Если он в контейнере - то потребуется пересобрать контейнер.
4. Этого вопроса не понял.

Comments

[mozzart_live]

Спасибо за ответ.
П.4 - я про линковку в следующем формате:
./:/var/www

[shurshur]

mozzart_live, не очень удачная идея. В контейнер попадёт docker-compose.yml и возможно ещё какие-то данные. В перспективе в каком-нить проекте контейнеров будет несколько, данные некоторых из них могут оказаться чувствительными и недопустимыми к открытому доступу, но они попадут в web-сервер и смогут быть найдены злоумышленником.

Правильнее всё же данные выносить в подкаталог.

[mozzart_live]

shurshur, я крайне упростил пример. Конечно, исходники или готовая сборка находится в подкаталоге.

[shurshur]

mozzart_live, я просто чтоб нашедшие этот вопрос в поиске не переняли не лучшее решение :)

Answer 3

[shurshur]

1. Очень сильно зависит от задачи. Конечно, если точно не понимаешь, зачем это тебе нужно, то имеет смысл доверить настройку сети докеру. Но если надо, чтобы вместо bridge был macvlan со строго заданной сетью и конкретным parent-интерфейсом, то этим нас докер сам не обеспечит, если ему не подсказать.

2. Тут больше проблема в том, что имена получаются длинными. Но если чётко знаешь свою инфраструктуру и запускаешь предсказуемые контейнеры в пределах данного хоста - почему нет? В конце концов, именование контейнеров может тоже быть частью инфраструктурного решения. Главное не запустить два проекта с пересекающимися именами - получится ах и ох с пересозданием живого контейнера.

3. Это попытка бороться с довольно типичным подходом начинающих докероводов, которые обходятся "универсальным" контейнером, исполняющим любой php-код с внешнего каталога. Конечно, для быстрых экспериментов "ща я чёта сваяю и запущу для проверки" это даже не очень плохое решение, но при широком использовании такого подхода смысл докера существенно уходит: вместо готового к разворачиванию приложения мы имеем контейнер, который ничего не умеет и которому приходится самостоятельно пилить отдельную систему доставки самого кода. Вместо этого лучше сразу научиться и отладиться готовить полноценный образ. В конце концов, можно все приложения делать потомками этого супер-образа с php, что сделает их сборку довольно быстрой.

4. Относительные пути - это как раз очень удобно для многих задач. Мы имеем каталог с проектом, в котором docker-compose.yml и все нужные данные. Размещение данных предсказуемо, точно видно, кто их использует, какой у них размер и всё такое. Удобно в случае чего перекидывать между серверами вместе с данными: просто погасил, rsync, запустил. Напротив, хранение данных в анонимных томах в /var/lib/docker с непонятными именами - это часто антипаттерн, при котором ценное место в /var заполняется чем-то непонятным, что толком невозможно идентифицировать. А использование имён может привести к той же проблеме, что и container_name - в разных compose-проектах имена пересекутся, и узнаешь это только тогда, когда уже сломается.

Comments

[mozzart_live]

Спасибо за развернутый ответ.

п.3 Я правильно понял, что максимально правильный, в перспективе подход, это создание готового образа приложения, которое будет содержать в себе все исходники и готовые бандлы и при разворачивании, никакого билда, по факту, происходить не должно?

[shurshur]

mozzart_live, да, всё так, внутри уже всё разложено, в идеале просто запускается web-сервер или php-fpm и ничего другого. Поэтому запуск/перезапуск делается очень быстро.

При использовании базовых образов dockerfile становится примерно таким:

FROM private-registry.company.ru/images/php-fpm-base
ADD ./www/ /var/www/

И даже ENTRYPOINT/RUN не надо определять - они уже заданы в базовом образе. Вся сборка будет заключаться в добавлении каталога и дальнейшей загрузке полученного образа в свой registry. Загрузка будет происходить быстро, так как слои базового образа уже в registry, и загрузить надо будет единственный слой с новыми файлами.

[mozzart_live]

shurshur, понятно. Спасибо за разъяснение, будем приводить все в образ.