Блог

Как запустить docker-compose в разных средах жизненного цикла (скажем, dev, qa, staging, production). Иногда более крупная виртуальная машина используется несколькими разработчиками, поэтому хотелось бы запускать контейнеры с соответствующими суффиксами, специфичными для разработчика (скажем, dev1, dev2, dev3 ..). Должна ли настройка порта обрабатываться вручную через файл среды (т. Е. .env-файл)

Это необычный вариант использования docker-compose, но я все равно оставлю несколько советов! 🙂

Есть два разных способа назвать материал, который вы начинаете с docker-compose . Один из них заключается в том, чтобы назвать службу, которую вы указываете в главном services: ключе вашего файла docker-compose.yml. По умолчанию отдельным запущенным контейнерам будут присвоены имена, указывающие, из какого проекта они (по умолчанию, имя каталога, в котором находится ваш файл docker-compose), какую службу они запускают (это то, что указано в вашем services: ключе), и каким экземпляром этой службы они являются (это число изменяется, если, например. вы используете replica s). Например. имена контейнеров по умолчанию для службы с именем myservice , указанным в файле компоновки ~/my_project/docker/docker-compose.yml , будут иметь имя типа docker_myservice_1 (или _2 , _3 и т.д., Если предполагается запустить более одного контейнера).

Вы можете использовать переменные среды для указания множества пар ключ-значение в файлах docker-compose, но вы не можете условно указать имя службы — служебные ключи могут содержать только буквенно-цифровые символы, а файлы compose не могут выглядеть, например:

 version: "3"

services:
  ${ENVVAR}:
    image: ubuntu:20.04
 

Однако вы можете переопределить схему именования контейнера, используя container_name поле в вашем файле docker-compose (документация для использования здесь ). Возможно, решение, которое вы могли бы использовать, выглядит следующим образом:

 version: "3"
services:
  myservice:
    image: ubuntu:20.04
    container_name: ${DEVELOPER_ENVVAR?err}
 

для этого разработчику потребуется указать DEVELOPER_ENVVAR во время выполнения, либо экспортировав его в свою оболочку, либо запустив docker-compose like DEVELOPER_ENVVAR=myservice_dev1 docker-compose up . Обратите внимание, что использование container_name несовместимо с использованием реплик для запуска нескольких контейнеров для одной и той же службы — имена должны быть уникальными для этих запущенных контейнеров, поэтому вам придется либо определять отдельные службы для каждого имени, либо отказаться от использования container_name .

Однако вы окажетесь в затруднительном положении, если ожидаете, что несколько разработчиков смогут запускать контейнеры с разными именами, используя один и тот же файл compose в одном каталоге. Это потому, что при запуске службы в docker-compose есть Recreating шаг, на котором, если уже запущены контейнеры, реализующие эту службу, они будут ждать завершения этого контейнера. В конечном счете, я думаю, что это к лучшему — если несколько разработчиков пытались запустить один и тот же проект compose одновременно, должен ли разработчик иметь контроль над запущенными контейнерами других разработчиков? Вероятно, нет, верно?

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

• во-первых, (и вы, вполне возможно, уже сделали это! но это все равно хорошее напоминание) убедитесь, что это хорошая идея. Будут ли проблемы с конфликтом ресурсов (например. для переадресации портов), которые приводят к конфликту разных запущенных экземпляров вашего проекта? Для многих служб Docker они будут, но, вероятно, их не будет, например, для изображений, предназначенных для запуска в рое.
• во-вторых, извлеките разные файлы компоновки в разных каталогах, чтобы для каждого разработчика были отдельные проекты компоновки. Чтобы использовать .env файлы одним из способов, один очевидный вариант — просто поддерживать отдельные копии, по одной на каталог разработчика. Если для вашего варианта использования неудовлетворительно поддерживать одну копию .env для каждого разработчика таким образом, вы можете использовать символические ссылки с именем .env (или любым другим именем вашего файла env) на тот же файл где-то еще на виртуальной машине.

После того, как вы это сделаете, вы сможете определить по именам контейнеров, кто что запускает.

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

Я выполнил очень похожую автоматизацию и использовал Ansible для создания конфигурации «docker compose» на лету. Таким образом, на основе среды ввода ansible playbook создаст соответствующий файл docker-compose. Итак, в основном у меня есть docker-compose template в моем репозитории git со значениями, которые являются динамическими, и ansible playbook заполняет их и т. Д.

а также вы можете использовать ansible для запуска такого создания или автоматизации один за другим

Аналогичный пример был размещен в репозитории ansible_docker_splunk. По сути, весь проект заключается в автоматизации сквозного кластера docker из файла CSV