Несколько малоизвестных возможностей docker-compose

Во многих инструкциях с просторов интернета описывают некий минимум действий, и как следствие минимум команд и возможностей.

Я решил сделать некую подборку мало освещенных возможностей, особенностей. Статья не претендует на уникальность, это и мне, как памятка, и возможно некоторым падаванам поможет, начинающим свой путь с docker-compose.

Использование нескольких docker-compose.yml файлов

Бывают сложные конфигурации, где есть некий базовый пласт контейнеров, который, скажем, нужен всегда. И обычно происходит так, что берем у соседней команды\другого проекта\интернета и допиливаем под свои нужды. Но если команд несколько, то можно базовую часть вынести в общий, внутренний репозиторий. И получаем идентичную базовую часть у большинства проектов, которая к тому же версионируется.

Опишем пример базового docker-compose-base.yml.

Предположим, это настроенный образ nginx с сертификатами, тюнингом, и скажем метриками. И exporter для prometheus:

version: '2'
services:
  nginx:
    image: nginx
  nginx-exporter:
    image: nginx/nginx-prometheus-exporter

Теперь опишем пример нашего приложения docker-compose-app.yml:

version: '2'
services:
  backend:
    image: internal.local/super-app:0.1.2

Для запуска нужна привычная нам команда с одним отличием. Указывать будем 2 docker-compose файла :

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

И вуаля, мы получаем набор сервисов, как если бы они были описаны в едином docker-compose файле!

Так же есть второй вариант использования нескольких файлов, через использование директивы extends.

docker-compose-base.yml:

version: '2'
services:
  nginx:
    image: nginx
  nginx-exporter:
    image: nginx/nginx-prometheus-exporter

docker-compose-app.yml:

version: '2'
services:
  backend:
    image: internal.local/super-app:0.1.2
  ### Добавляем секцию с веб сервером
  web:
    extends:
      # В какой файл смотрим (относительный или полный путь)
      file: docker-compose-base.yml
      # Какой сервис берем оттуда к нам
      service: nginx
  web-exporter:
    extends:
      file: docker-compose-base.yml
      service: nginx-exporter

Дополнение от iSlava:
Можно описать все compose файлы в environment переменных, и использовать docker-compose up -d без указания файлов вручную:

COMPOSE_PATH_SEPARATOR=:
COMPOSE_FILE=docker-compose-base.yml:docker-compose-app.yml

Какой вариант выбрать — выбирать вам. Все индивидуально, я лишь хотел показать варианты =)

Наследование в docker-compose

Следующий пример требует версию docker-compose >= 2.4
Тоже довольно интересная особенность, причем действительно мало где упоминается.
Этот функционал позволяет нам описывать несколько однотипных сервисов в docker-compose файле, при этом не дублируя их описание, а именно наследуя.
Например у нас есть такой файл:

version: '2.4'
services:
  backend:
    image: internal.local/super-app:0.1.2
    ports:
      - 8080:8080
      - 9090:9090
    volumes:
      - ./conf/some.conf:/etc/app/some.conf:ro

И появилась необходимость поднимать несколько контейнеров, но с некоторыми различиями, можем конечно "накопипастить" и поменять, а можем сделать так:

version: '2.4'
services:
  backend:
   &base-app #все что под данным указателем будет доступно по его имени
    image: internal.local/super-app:0.1.2
    ports:
      - 8080:8080
      - 9090:9090
    volumes:
      - ./conf/some.conf:/etc/app/some.conf:ro

  backend-2:
  <<: *base-app #наследуемся
  ports: # переопределяем опубликованные порты
     - 8081:8080

Таким образом мы получаем возможность изменять в одном месте, чем править в описании каждого контейнера.
Есть еще вариант вынести в корневую область, например:

version: '2.4'
services:

x-backend: #Секции начинающиеся с "x-" будут игнорироваться, но их можно переиспользовать.
  &base-app
  image: internal.local/super-app:0.1.2
  ports:
    - 8080:8080
    - 9090:9090
  volumes:
    - ./conf/some.conf:/etc/app/some.conf:ro

  backend:
   <<: *base-app #наследуемся

  backend-2:
  <<: *base-app #наследуемся
  ports: # переопределяем опубликованные порты
     - 8081:8080

Ограничения по ресурсам

Начиная с версии 2.2 можно использовать ограничения по ресурсам для контейнеров, на самом деле с версии 2.1, но там еще не все завезли =)
Есть нюанс! В версии 3 эти возможности убрали! Там уже упор на docker swarm.

Самый простой пример ограничения ресурсов по CPU, MEM:

version: '2.2'
services:
  backend:
    cpus: 1.5 #Позволяем использовать полтора ядра.
    cpuset: '0,3' #Использовать первое и четвертое ядро системы.
    mem_limit: 1gb #Позволяем использовать 1Гб памяти
    memswap_limit: 2gb #Ограничиваем SWAP двумя Гб памяти.
    oom_kill_disable: true # В редких случаях, надо гарантировать что OOM Killer не убьет наше приложение в случае нехватки памяти, вот так можем запретить ему убивать контейнер.

    image: internal.local/super-app:0.1.2
    ports:
      - 8080:8080
      - 9090:9090
    volumes:
      - ./conf/some.conf:/etc/app/some.conf:ro

Упаковка образов в архив

К сожалению, не всегда есть возможность пушить образы в docker registry свой или облачный. Иногда стоит необходимость собрать образы по docker-compose файлу и отправить, скажем, файловым архивом. Руками это делать иной раз долго, поэтому я набросал простой скрипт, вдруг кому пригодится:

#!/bin/bash

dc=${1}

if [ ! -z ${dc} ] && [ -f ${dc} ]; then
  echo "Saving docker images from file ${dc}..."
  images=`grep image: ${dc} | awk '{print $2}'`
  docker save ${images} | gzip > docker-images.gz
  echo "Success!"
else
  echo "ERROR! You must set path to docker-compose.yml as argument!"
fi

Сохраняем в файл скажем 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 нет на вашей машине, будь то виртуалка, или сервер в интернете.
Неоходимо убедиться, что ipv6 на уровне системы включен:

    sysctl net.ipv6.conf.all.disable_ipv6

Значение должно быть равно 0, если не так, изменяем:

    sysctl -w net.ipv6.conf.all.disable_ipv6=0

Устанавливаем miredo (Это сервис с встроенным впн до сервера, который выдаст нам публичный ipv6)

    apt-get install miredo -y

Проверяем, что сервис запушен:

    systemctl status miredo

Проверяем, что мы получили ipv6 адрес:

    ifconfig teredo

Прописываем в /etc/docker/daemon.json

    {
        "ipv6": true,
        "fixed-cidr-v6": "2001:db8:1::/64"
    }

Рестартуем докер:

    systemctl restart docker

Ну и осталось включить NAT для ipv6, чтобы внутренние адреса нашего контейнера смогли выходить в внешний мир через наш teredo интерфейс:

    ip6tables -t nat -A POSTROUTING -o teredo -j MASQUERADE

Поднимаем docker контейнер нужный нам, и он может выходить в свет через ipv6 адрес.

Приведенный пример с sysctl и iptables будет работать до перезагрузки, если необходимо сделать на постоянной основе, то следует посмотреть инструкции по вашему дистрибутиву, бывают различия.

Надеюсь кому-то предоставленная информация здесь будет полезна.