Докеры с несколькими средами

Я пытаюсь обмотать голову вокруг Докера, но мне сложно понять это. Я попытался реализовать его в своем маленьком проекте (стек MERN), и я думал, как вы отличаетесь между разработкой (возможно, постановкой) и производственными средами.

Я увидел один пример, в котором они использовали 2 файла Docker и 2 файла для создания docker файлов (каждая пара для одного env, поэтому Dockerfile + docker-compose.yml для prod, Dockerfile-dev + docker-compose-dev.yml для dev).

Но для меня это кажется немного лишним. Я бы предпочел использовать его только в двух файлах.

Также одна из проблем заключается в том, что, например, для разработки Я хочу установить nodemon глобально, но не для поддукции.

В идеальном решении я представляю себе что-то вроде этого

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

Ответы

Ответ 1

Вы можете взять некоторые подсказки из Использование Compose in production"

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

Удаление любых привязок томов для кода приложения, поэтому код остается внутри контейнера и не может быть изменен извне

Связывание с различными портами на хосте

Настройка переменных среды по-разному (например, для уменьшения подробностей ведения журнала или для отправки электронной почты)

Указание политики перезапуска (например, перезагрузка: всегда), чтобы избежать простоев

Добавление дополнительных сервисов (например, агрегатор журналов)

Совет тогда не совсем похож на пример, который вы упомянули:

По этой причине вы, вероятно, захотите определить дополнительный файл Compose, скажем production.yml, который определяет конфигурацию, подходящую для производства. Этот файл конфигурации должен включать только те изменения, которые вы хотели бы сделать из исходного файла Compose.
docker-compose -f docker-compose.yml -f production.yml up -d

Этот механизм лучше, чем пытаться смешивать логику dev и prod в одном файле компоновки с переменной окружения попробуйте и выберите один.

Примечание. Если вы назовете ваш второй файл dockerfile docker-compose.override.yml, простой docker-compose up будет автоматически читать переопределения.
Но в вашем случае имя, основанное на среде, более ясное.

Ответ 2

Docker Compose будет читать по умолчанию docker-compose.yml и docker-compose.override.yml. Understanding-Multiple-Compose-Files

Вы можете установить стандартный файл docker-compose.yml и другой файл с перезаписи. Например, docker-compose.prod.yml docker-compose.test.yml. Храните их в одном месте.

Затем создайте символическую ссылку с именем docker-compose.override.yml для каждого env.
Отслеживайте docker-compose.{env}.yml файлы и добавьте docker-compose.override.yml в .gitignore.
В prod env: ln -s ./docker-compose.prod.yml ./docker-compose.override.yml
В тесте env: ln -s ./docker-compose.test.yml ./docker-compose.override.yml
Структура проекта будет выглядеть следующим образом:

project\
  - docker-compose.yml       # tracked
  - docker-compose.prod.yml  # tracked
  - docker-compose.test.yml  # tracked
  - docker-compose.override.yml # ignored
          #linked to override composefile for current env 
  - src/
  - ...

Тогда вы это сделали. В каждой среде вы можете использовать compose файл с той же командой docker-compose up

Если вы не уверены, используйте docker-compose config для проверки правильности переопределения.