Методы управления конфигурационными файлами между несколькими средами

Question

Проблемой

Мы используем Java WAR файлы и хранить конфигурационные файлы в s3 ведер. Наши среды: DEV, QA, Stage и PROD имеют свои собственные файлы конфигурации и s3-ведра. Если я добавлю новое поле, например «Polling_RATE = 5000», , он должен быть добавлен вручную в каждый env, потому что эти файлы конфигурации также хранят пароли, поэтому они не могут быть привязаны к приложению или хранятся внутри Github. Не каждый инженер имеет доступ к каждому env, поэтому вы должны помнить о том, чтобы сообщить инженерам верхнего уровня (DEVOPS) до даты внедрения prod, чтобы добавить новое поле для работы приложения. Это действительно грязный процесс в настоящее время.

Вопрос

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

Answer 1

Распознаваемая проблема.

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

1. Конфигурация, относящаяся к окружающей среде, но не содержащая конфиденциальной информации. Я бы посоветовал вам хранить эти файлы вместе с исходным кодом и, если возможно, генерировать файлы и автоматически загружать их в хранилище конфигурации (S3 в вашем случае) во время сборки. Они должны быть версированы и привязаны к версии вашего приложения.
2. Конфигурация, содержащая конфиденциальную информацию. Рассматривая вопрос, не всем членам команды разрешено читать/писать эту информацию. Вы можете сохранить их в S3 с определенными правами доступа, чтобы доступ к ним могли получить только уполномоченные участники. Вам понадобится механизм для объединения файлов вместе при развертывании или изменения приложения для чтения из разных файлов конфигурации.
   Однако это только решает часть вашей проблемы. Партиям ops все равно придется выполнять изменения при изменении чувствительных ключей конфигурации. Является ли это приемлемым, зависит от того, как часто меняются чувствительные ключи ключей.

Альтернативой S3 может быть запуск частного репозитория Git (например, CodecCommit AWS). У вас будет лучший контроль версий и более легкий доступ для разработчиков, чтобы выполнять изменения, поскольку вы уже используете Git. Вам все равно придется исправлять права доступа на разделение между dev и ops, или пусть это произойдет (поскольку DevOps - это доверие и сотрудничество, это может быть хорошей идеей). Вы можете применить аналогичную схему здесь, как я описал выше.

Другим решением может быть перемещение конфигурации чувствительных значений из файлов свойств в конфигурацию системы. Когда вы уже используете систему подготовки, такую ​​как Puppet или Chef, это будет естественно для парней ops. Или задайте все чувствительные значения, такие как пароли, как переменные среды и попросите приложение прочитать его как свойства системы.

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

Answer 2

Мы использовали dynamodb для хранения значений конфигурации. Преимущество такого подхода состоит в том, что значения легко читаются с консоли и проверяются. . Еще одно преимущество заключается в том, что мы периодически проверяем значения из dynamodb, поэтому, если какое-либо значение нужно изменить, мы просто меняем его, и приложение автоматически выбирает новое значение, а не запускает его снова. Чувствительные значения хранятся в зашифрованном виде с использованием ключей KMS, и только роль ec2, которая запускает приложение, имеет право расшифровать с помощью этого ключа. Мы улучшили проект Netflix archiaus в соответствии с нашими потребностями. Может быть, вы можете это проверить.