Управление конфигурацией в контейнерах Docker

Question

В настоящее время у меня есть файлы конфигурации, хранящиеся в GitHub. У меня есть один файл JSON с форматом, как показано ниже { DEV: { key1 : val1, key2 : val2 }, PROD: { key1 : val1, key2 : val2 } }.

Моя система сборки клонирует git repo, создает проекты и создает изображение Docker и хранит в приватном реестре Docker. У меня есть файлы jar и файлы конфигурации, скопированные в изображение Docker. Всякий раз, когда я разворачиваю контейнер, я ввожу переменную окружения (ENV = DEV/PROD), которую мой код использует для чтения конфигураций на основе среды.

У меня есть несколько вопросов здесь:

• Что является лучшим способом для поддержания среды конкретной конфигурации?

• Файлы конфигурации могут содержать конфиденциальные данные, такие как ключи api и секреты, как я могу шифровать и хранить и расшифровывать, когда я создаю изображение Docker?

• Если я хочу изменить некоторую конфигурацию, мне нужно вызвать сборку, потому что мой файл конфигурации помещается внутри изображения Docker. Могу ли я помещать файлы конфигурации вне контейнера Docker в качестве тома, чтобы я мог заменить файл конфигурации и перезапустить контейнер, чтобы код читал обновленные конфиги? Если я хочу разместить вне контейнера Docker, могу ли я использовать любые инструменты управления кластерами для управления оркестром/управления контейнерами (Kubernetes/ECS)?
• Каким образом приложения, запущенные в контейнерах Docker, читают обновленные конфигурации, просто перезагружая контейнер, вместо того чтобы создавать новое изображение докеров и развертывать новый контейнер?

Answer 1

1. Переменные ENV в порядке. Если у вас действительно сложная система, вы можете вращать Consul и/или Vault для управления защищенной конфигурацией, но если ваша система мала, беспорядок не стоит усилий.
2. Вы можете зашифровать всю конфигурацию в хэш и расшифровать ее ключом, который известен только для приложения.

3. Использование докеров. Это позволяет совершенный механизм - тот, который вы на самом деле запрашивающей здесь, пример docker-compose.yml:

Файл ./config/config.env ваш «динамический» конфигурации. Вам нужно просто обновить контейнер, чтобы обновить значения внутри вашего приложения. Насколько я знаю, сборщик докеров хорошо работает со всем, что вы упомянули (я не знаком с Kubernetes, но я уверен, что есть такая вещь, это базовая для контейнера api).

Answer 2

Мой ответ на большинство вопросов будет "Vault by Hashicorp"

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

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

Как это соответствует тому, что вы просили?

• Каков наилучший способ поддерживать конфигурацию, специфичную для окружающей среды?

Я бы сказал, Сейф. Вы можете писать секреты в файл или папку с помощью Puppet с помощью Hiera, если хотите, но это означает, что нужно писать секреты на диск, который не идеален. TMK K8s хранит секреты, незашифрованные в покое, что также не идеально. Я бы предпочел Сейп здесь. Каждая среда имеет свой собственный кластер Vault, и есть ваша «конфигурация, специфичная для среды».

• файлы конфигурации могут содержать конфиденциальные данные, такие как ключи API и секретов, как можно зашифровать и хранить и расшифровывать, когда я построить Docker изображение?

См. Выше. Хранилище хранит тайны, зашифрованные в покое. Используйте токен Vault (который вы можете подключить к своему контейнеру через том, если хотите), чтобы получить доступ к секретам и расшифровать их. Затем вы можете подтолкнуть их к своей ENV, прежде чем запускать основной процесс контейнеров, или упростить интеграцию и сделать Vault частью логики вашего приложения.

• Если я хочу изменить некоторую конфигурацию, мне нужно вызвать сборку , потому что мой файл конфигурации помещается внутри изображения Docker. Могу ли я разместить файлы конфигурации вне контейнера Docker в качестве тома, чтобы я мог заменить файл конфигурации и перезагрузить контейнер, чтобы код читал обновленные configs? Если я хочу разместить за пределами контейнера Docker, могу ли я все еще использовать любые инструменты управления кластерами для контейнера orchestration/management (Kubernetes/ECS)?

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

Если он не зависит от кода (например, настройки или секреты настройки), я бы бросил их в Vault - зачем их помещать в файл, когда вы можете хранить их в зашифрованной системе секретного управления?

Однако, если ваше сердце настроено на файлы, вы можете легко установить их с известного тома на известный путь, а все системы планирования (включая Nomad now) позволяют монтировать тома с развернутыми контейнерами.

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

С Vault: envconsul - ваш друг, если вы хотите, чтобы секреты менялись только во время загрузки.

См. Выше мое мнение о изменениях времени выполнения в значениях конфигурации.

Фактическое значение Выполнение этого заключается в создании сценария «запуска», который является точкой входа для вашего контейнера. Сценарий запуска будет извлекать секреты из любой системы управления, которую вы выбираете (тома монтирует, Vault, файл и т. Д.) И готовит их для чтения вашего приложения.

Затем запускается сценарий запуска, который запускает процесс запуска вашего основного приложения.

Надеюсь, это поможет!

PS: Я не работаю для Hashicorp, но мне нравится их программное обеспечение для работы с контейнерами. Многое из того, что вы можете получить, купив разрозненное программное обеспечение Hashicorp, вы также можете получить от K8s как единое решение. Отдельные приложения (Hashicorp) позволяют выбирать и смешивать бит требуемого решения, но также требуют более высоких затрат на обслуживание. K8s - довольно тяжелый замок, но делает большинство вещей, которые вы, скорее всего, захотите, не изучая ничего другого.

Удача