Comments 22
Нормас, некоторые советы просто супер, особенно касательно наследования в compose
Как раз столкнулся с этим «наследованием» портов. Насколько я понял, compose не перезаписывает, а конкатенирует списки. Поправьте, если не прав.
Если вы имеете ввиду, что при переопределении вместо перезаписи используется конкатенация, то насколько я знаю — нет. В противном случае при поднятии контейнеров сыпались бы ошибки, из-за попытки второго контейнера к примеру занять порт, который уже занял первый.
Я предполагаю если внешний порт совпадает с уже определенным, то перезаписывает эту часть. Если же добавляется новый порт, то конкатенируется. То есть нельзя отбросить старые записи и добавить совсем новые
Я перед публикацией статьи проверял данный момент. В случае переопределения секции с портами происходит перезапись.
mem_limit: 1000000000 #Позволяем использовать 1Гб памяти
memswap_limit: 2000000000 #Ограничиваем SWAP двумя Гб памяти.


Можно задать проще:
mem_limit: 1gb
memswap_limit: 2gb

Из официальной доки:

The supported units are b, k, m and g, and their alternative notation kb, mb and gb. Decimal values are not supported at this time.

На работе очень активно используем docker-compose -f, а вот наследованием пока не пользовались. Обязательно пишите еще по теме!
Малоизвестная возможность docker-compose которая малоизвестна даже авторам таких статей:
Вместо того чтобы набирать портянку в стиле

docker-compose up -d -f docker-compose-base.yml -f docker-compose-app.yml ... 


Можно один раз создать .env файл с содержимым где перечислить все compose файлы

COMPOSE_PATH_SEPARATOR=:
COMPOSE_FILE=docker-compose.shared.admin.yml:docker-compose.shared.base-images.yml:docker-compose.shared.depends.yml:docker-compose.shared.env.yml:docker-compose.dev.build.yml:docker-compose.dev.command.yml:docker-compose.dev.env.yml:docker-compose.dev.labels.yml:docker-compose.dev.networks.yml:docker-compose.dev.ports.yml:docker-compose.dev.volumes.yml


И поднимать всё это классическим docker-compose up -d

Документация: docs.docker.com/compose/reference/envvars/#compose_file
Пример использования: GitHub
А если в разных случаях нужно запускать разное сочетание файлов? Не править же каждый раз .env файл. Хотя, возможность и в самом деле занятная.

.env подцепляется только с текущего каталога, так что можно закостылить структуру каталогов по окружения, переходить в них и из них запускать докер-компоуз с относительным путем к ЯМЛ файлу. Можно? Да. Удобно? Вряд ли.


Ну, либо оборачивать запуск докер-компоуза в баш скрипт. Но тогда возникает вопрос — а почему тогда не обойтись вообще без него? Т.к. по сути докер компоуз это враппер вокруг команд управления докером (docket build, docker run, docker volume/network create etc.). Больше врапперов богу врапперов ?

ЕМНИП docker-compose также создает сеть, в которой контейнеры из docker-compose.yml могут общаться друг с другом, используя имена из docker-compose.yml. Мы это используем для запуска тестов — в отдельных контейнерах сидят PHP/Apache, MySQL, Selenium (headless, если не нужна отладка), тот же MailCatcher, итп.

Делается руками, прекрасно.
Это не является какой-то особенной фичей докер-компоуза.
Что хуже — я сталкивался с ситуацией, когда докер-компоуз игнорирует глобальные настройки докер-демона. Например, это особенно неприятно, когда корп. сеть не в 10-й подсети, а в 172-й.
Типа такого https://github.com/docker/compose/issues/5204

Хм, я не сталкивался с таким, но мне не приходилось менять подсетки. Интересно, что по тому линку есть вот это:

«Don't believe this is a compose issue. Compose just uses docker-py which calls the daemon under the hood, Compose doesn't interact with that file at all.»

Т.е. вопросы к демону, а не к компоузу.

Не хочу спорить. Эту фразу можно понять по-разному. Но факт в том, что docker network create создаёт сеть правильно, а docker-compose при тех же настройках — нет. Вывод — что-то сломано, возможно по дороге.

Следующий пример требует версию docker-compose >= 2.4

Выглядит немного по-издевательски, учитывая, что 3.1 вышел раньше 2.4
Фактически — это две разные линейки форматов, каждая со своими "фичами"


Касательно параметра -f — мы ими активно пользуемся но в сочетании с /dev/stdin, чио позволяет генерировать докер-компоуз файл по шаблону той же Jinja, например

Наследование в docker-compose — это печаль и боль. Сам формат yaml с первой версии поддерживает подстановки/алиасы. Но разработчики почему-то реализовали какой-то свой yaml :-(

Я бы сказал, что проблема не в наследовании как таковом, а в его реализации. Есть 5+ разных механизмов, которые нормально не работают (конкатенация ямлов через -f, extends, docker-compose.override.yml, .env vs env_file, может быть что-то еще, что я забыл).

По IPv6: teredo, серьезно? Я тоже не рад что ipv6 не популизирован в массы. Получить IPv6 в Киеве можно только в ЦОД или через BGP, что для некоторых большой оверхед. Но если и брать вирт адреса IPv6 то хотя бы у лидеров, а не пойми откуда, разверните tunnelbroker.net клиент на шлюзе, не сравнимое преймущество с teredo. Единственное: если вам нужен outgoing smtp server-server с 25 порта: сразу проходите сертификацию в ЛК, без нее он залочен. Заодно получите футболку по почте бесплатно :)

Только уже ради футболки надо попробовать!
А по делу — спасибо за дельный комментарий, обязательно попробую!
Only those users with full accounts are able to leave comments. Log in, please.