Докеры с несколькими окружениями

Question

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

Я видел один example где они использовали 2 Докер файлы и 2 Докера-Compose файлов (каждую пару для одного окр, так Dockerfile + докер-compose.yml для прода, Dockerfile-DEV + докер-Compose-DEV. yml для разработчика).

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

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

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

docker-compose -e ENV=dev build 
docker-compose -e ENV=dev up 

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

Answer 1

Вы можете взять некоторые ключи от «Using Compose in production»

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

• Удаления любых привязок объема для кода приложения, так что код находится внутри контейнера и не может быть изменен из-за пределами
• Привязки к различным портам на хосте
• переменной Настройки среды по-разному (например, чтобы уменьшить подробность лесозаготовок, или включить отправку сообщений электронной почты)
• Задание политики перезапуска (например, перезагрузка: всегда), чтобы избежать простоев
• Добавление дополнительных услуг (например, агрегатора журнала)

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

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

docker-compose -f docker-compose.yml -f production.yml up -d 

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

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

Answer 2

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

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

Затем создайте символическую ссылку с именем docker-compose.override.yml для каждого env.
Отслеживать docker-compose.{env}.yml и добавлять docker-compose.override.yml в .gitignore.
В прод окр: ln -s ./docker-compose.prod.yml ./docker-compose.override.yml
В тесте окр: 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, чтобы проверить, правильно ли оно было отменено.