Во многих инструкциях с просторов интернета описывают некий минимум действий, и как следствие минимум команд и возможностей. Я решил сделать некую подборку мало освещенных возможностей, особенностей. Статья не претендует на уникальность, это и мне, как памятка, и возможно некоторым падаванам поможет, начинающим свой путь с docker-compose. Бывают сложные конфигурации, где есть некий базовый пласт контейнеров, который, скажем, нужен всегда. И обычно происходит так, что берем у соседней команды\другого проекта\интернета и допиливаем под свои нужды. Но если команд несколько, то можно базовую часть вынести в общий, внутренний репозиторий. И получаем идентичную базовую часть у большинства проектов, которая к тому же версионируется. Опишем пример базового docker-compose-base.yml. Предположим, это настроенный образ nginx с сертификатами, тюнингом, и скажем метриками. И exporter для prometheus: Теперь опишем пример нашего приложения docker-compose-app.yml: Для запуска нужна привычная нам команда с одним отличием. Указывать будем 2 docker-compose файла : И вуаля, мы получаем набор сервисов, как если бы они были описаны в едином docker-compose файле! Так же есть второй вариант использования нескольких файлов, через использование директивы extends. docker-compose-base.yml: docker-compose-app.yml: Дополнение от iSlava:
Можно описать все compose файлы в environment переменных, и использовать docker-compose up -d без указания файлов вручную: Какой вариант выбрать — выбирать вам. Все индивидуально, я лишь хотел показать варианты =) Следующий пример требует версию docker-compose >= 2.4
Тоже довольно интересная особенность, причем действительно мало где упоминается.
Этот функционал позволяет нам описывать несколько однотипных сервисов в docker-compose файле, при этом не дублируя их описание, а именно наследуя.
Например у нас есть такой файл: И появилась необходимость поднимать несколько контейнеров, но с некоторыми различиями, можем конечно "накопипастить" и поменять, а можем сделать так: Таким образом мы получаем возможность изменять в одном месте, чем править в описании каждого контейнера.
Есть еще вариант вынести в корневую область, например: Начиная с версии 2.2 можно использовать ограничения по ресурсам для контейнеров, на самом деле с версии 2.1, но там еще не все завезли =)
Есть нюанс! В версии 3 эти возможности убрали! Там уже упор на docker swarm. Самый простой пример ограничения ресурсов по CPU, MEM: К сожалению, не всегда есть возможность пушить образы в docker registry свой или облачный. Иногда стоит необходимость собрать образы по docker-compose файлу и отправить, скажем, файловым архивом. Руками это делать иной раз долго, поэтому я набросал простой скрипт, вдруг кому пригодится: Сохраняем в файл скажем docker-compose-images-save.sh
Даем права на исполнение:
chmod +x docker-compose-images-save.sh
Запускаем, и в качестве аргумента передаем путь до docker-compose файла:
./docker-compose-images-save.sh /home/some_user/docker-compose-app.yml
На выходе получим в папке откуда вызвали скрипт архив с образами — docker-images.gz
Любым доступным образом отправляем на удаленный сервер.
Теперь на удаленном сервере достаточно выполнить:
gzip -cd docker-images.gz | docker load
Все образы загрузятся в локальный реестр, после чего можно тут смело запускать
docker-compose up -d, по скольку все образы есть в локальном реестре в интернет уже докер не полезет. В определенных задачах ipv6 бывает крайне полезен, взять хотя бы нюанс, что Роскомнадзор пропускает по ipv6 без проблем весь трафик, и тот же телеграм бот работает без проблем.
Я рассмотрю ситуацию, когда ipv6 нет на вашей машине, будь то виртуалка, или сервер в интернете.
Неоходимо убедиться, что ipv6 на уровне системы включен:  Значение должно быть равно 0, если не так, изменяем: Устанавливаем miredo (Это сервис с встроенным впн до сервера, который выдаст нам публичный ipv6) Проверяем, что сервис запушен: Проверяем, что мы получили ipv6 адрес: Прописываем в /etc/docker/daemon.json Рестартуем докер: Ну и осталось включить NAT для ipv6, чтобы внутренние адреса нашего контейнера смогли выходить в внешний мир через наш teredo интерфейс: Поднимаем docker контейнер нужный нам, и он может выходить в свет через ipv6 адрес. Надеюсь кому-то предоставленная информация здесь будет полезна. DevOps, Network, Linux\Unix