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

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

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

Прошу знающих людей прокомментировать данные "факты" и при возможности объяснить, ошибаются комментаторы или же 99% статей по этой теме?
  • Вопрос задан
  • 372 просмотра
Пригласить эксперта
Ответы на вопрос 3
@mureevms
1. Всегда лучше делать явно, чем не явно. Это упростит работу другим и себе же, когда пройдет полгода.
2. Это как минимум удобно. Контейнер всегда называется одинаково, вместо дурацких автоматических названий. Опять же, пройдет полгода, вы сами читаете конфиг компоуза и видите контейнер не пойми как называется, надо будет догадаться, что имя не назначено. Зачем усложнять?
3. По ситуации, нет верного ответа
4. Относительные пути тру. А вот абсолютные зло. При относительных путях вам надо просто перенести каталог на новый сервер и все запустится. Абсолютные придется править, а это усложнение.
Ответ написан
@Akela_wolf
Extreme Programmer
1. По ситуации. Иногда это более чем оправданно. Не стал бы возводить это в абсолют
2. Опять же - по ситуации. Иногда требуется.
3. Вопрос с обновлением этого самого кода. Если он лежит на volume, то обновить не проблема (в том числе и изнутри контейнера). Если он в контейнере - то потребуется пересобрать контейнер.
4. Этого вопроса не понял.
Ответ написан
shurshur
@shurshur
1. Очень сильно зависит от задачи. Конечно, если точно не понимаешь, зачем это тебе нужно, то имеет смысл доверить настройку сети докеру. Но если надо, чтобы вместо bridge был macvlan со строго заданной сетью и конкретным parent-интерфейсом, то этим нас докер сам не обеспечит, если ему не подсказать.

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы