Где я должен положить конфигурацию моего приложения?

Недавно я читал дебаты на тему « Где хранить свойства, зависящие от среды? ».

Классический способ состоит в том, чтобы иметь несколько файлов свойств, по одному для среды и на основе переменной среды (DEV, PROD ...), вы выбираете, где их читать при запуске приложения (как в случае профилей Spring).

С другой стороны, если вы используете контейнер для развертывания приложения, говорят, что этот тип конфигурации должен исходить из самой среды (с использованием переменных среды, которые приложение читает), поэтому изображение не меняется между средами.

Каковы плюсы и минусы каждого подхода? Есть ли «лучший» подход для контейнерного сценария?

Кто сказал, что файлы свойств и переменные окружения где взаимоисключающие?

Необходимо проводить различие между «где хранить конфигурацию моего приложения?» И "откуда у моего приложения источник его конфигурации?"

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

Однако вместо того, чтобы помещать этот файл конфигурации в контекст приложения и запускать его, приложение должно просто ожидать, что эти переменные уже будут доступны в среде при запуске.

Это означает, что вам нужно иметь два рабочих процесса развертывания:

1. Я могу развернуть любое приложение в среде, пройдя процесс контроля изменений X и выполнив Y-обзоры с помощью инструмента Z, что угодно.
2. Я развертываю свою конфигурацию среды в среде, проходя процесс контроля изменений и проводя обзоры B с помощью инструмента C, тот же процесс, другой результат.

Чтобы использовать пример управления переменными среды в качестве пар «ключ-значение» в таком инструменте, как консул, если вы храните файлы конфигурации в git, тогда такие инструменты, как git2consul, позволяют обрабатывать эту конфигурацию в среде при ее обновлении.

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

У нас есть 3 штуки (или артефакты) для каждого работающего приложения.

1. Приложение, которое мы разрабатываем. Это то же самое, независимо от окружающей среды. Чтобы соответствовать вашему примеру, это будет приложение Spring как jar / war.
2. Контейнер, который будет запускать приложение. Это то же самое, независимо от окружающей среды. Если вы используете Spring Boot, вам больше не нужен Tomcat, а только среда выполнения Java. Так что используйте контейнер OpenJDK Docker.
3. Конфигурация, которая нужна приложению. Это единственное, что отличается в разных средах. В приложении Spring вы, вероятно, будете использовать файл свойств.

Файл конфигурации находится в отдельном исходном контроле. Раньше это был Git, но сейчас мы используем SaaS, который мы создали под названием Config, на http://www.configapp.com . Основной особенностью Config является простота управления конфигурацией, специфичной для конкретной среды. Чтобы запустить наше приложение на новом сервере, мы извлекаем контейнер Docker, артефакт приложения и файл конфигурации для этой среды. В контейнере мы монтируем каталог, в котором хранится приложение и файл конфигурации, как часть запуска контейнера. Наше приложение то же самое. Наш контейнер / изображение такое же. Только файл конфигурации отличается.

Что касается файла конфигурации против переменных среды. Долгое время мы использовали файлы конфигурации. Когда мы использовали PaaS / cloud, мы использовали переменные среды. Это было дополнительной работой, если у вас много настроек, поэтому мы использовали переменные среды для определения правильного файла конфигурации. У нас есть одно приложение, которое превратило свойства в переменные окружения, но это нетипично. Если у нас есть санкционированный компанией сервер централизованной конфигурации, мы используем его, в противном случае нам нравится простота файлов конфигурации.

Итак, для подведения итогов мы извлекаем app.jar, app.properties, openjdk Docker. Затем мы запускаем openjdk Docker, монтируя расположение app.jar и app.properties. Единственное, что специфично для среды - это app.properties. Чтобы легко управлять app.properties, независимо от того, сколько ключей свойств, сред, экземпляров кластера / региона, мы используем Config.