В Docker, как работать с несколькими конфигурациями сборки test/prod

Question

Мы оцениваем Docker для использования при развертывании наших приложений. До сих пор мы не могли получить от Interwebs информации о том, как мы будем иметь дело с различными средами исполнения, которые мы используем в нашей компании.

Для упрощения скажем, что у нас есть тестовая среда и производственная среда. Если бы я развертывал Application-X в тестовой среде, я бы передавал параметр командной строки в Maven или Gradle, который заставлял бы его использовать конкретную конфигурацию, которая, например, указывала бы на Service-X-Test.

При развертывании в производство Application-X будет собран с конфигурацией, которая вместо этого указывает на Service-X-Prod.

Может ли Docker справиться с подобными вещами, или я полностью упускаю суть в Docker?

У нас есть несколько приложений, которые являются более новыми и управляют этой конфигурацией во время выполнения с помощью сценариев Spring и Groovy, но, к сожалению, это скорее исключение, чем правило. Docker, похоже, очень хорошо работает с этими новыми приложениями.

Answer 1

Обратитесь к этой презентации:

Уроки использования Docker для повышения производительности веб-разработчиков

Перейдите к отметке 21:09, решение состоит в том, чтобы использовать фиксированное доменное имя (в вашем случае Service-X-Prod). В тестовой среде разработчика вы должны настроить файл /etc /hosts так, чтобы трафик указывал на Service-X-Prod, а вместо этого направлялся на Service-X-Test.

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