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

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

app
|-- config.json

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

12 Руководство по Factor App рекомендует полностью удалить файлы конфигурации и использовать переменные среды для настройки конфигурации:

... сохраняет конфигурацию в переменных окружения. Env vars легко переключать между развертываниями без изменения кода; в отличие от конфигурационных файлов, существует небольшая вероятность того, что они случайно попадут в репозиторий; и в отличие от пользовательских файлов конфигурации или других механизмов конфигурации, таких как Java System Properties, они являются независимым от языка и ОС стандартом.

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

Существует ли какой-либо общепринятый способ обработки параметров конфигурации, в котором нет риска сохранения локальной конфигурации в системе контроля версий?

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

• С исходным кодом (в SVN / GIT и т. Д.) Действительно плохая идея, так как эти данные будут содержать пароли производственной базы данных и тому подобное.
• Ваша корпоративная ночная резервная копия может быть достаточной, но вряд ли она сохранит легкодоступную историю изменений.
• Данные должны быть версии отдельно для потребляющего программного обеспечения. В нашей текущей системе изменение конфигурации приводит к новой сборке приложения, и это просто неправильно.

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

При рассмотрении проблем и возможных решений мне помогает метод, популярный у Джеффа Этвуда : если бы Бог создал способ хранения конфиденциальной информации о конфигурации, как бы он это сделал?

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

О первой части уже следует позаботиться: ваша система контроля версий должна проходить аутентификацию пользователей. И этому подходу также дают силу согласно # 10 в 10 заповедях Троя Ханта «Контроль источника» , «зависимости должны находиться в управлении источником».

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

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

• Простота реализации на любом языке. Во многих вы получаете поддержку сложных файлов конфигурации из коробки. Например, в случае Java с Spring Boot вы получаете поддержку YAML, которая может выражать любую древовидную структуру, и легко иметь отдельные файлы конфигурации для разных сред, а также базовую конфигурацию, от которой могут наследоваться специфичные для среды файлы.
• Конфигурация необходима для запуска вашего программного обеспечения, а изменения в коде часто требуют добавления / изменения параметров конфигурации, поэтому естественно сохранять конфигурацию и код вместе.
• Хранение конфигурации с исходным кодом дает вам все преимущества управления исходным кодом, например, знание, кто изменил какой параметр и когда, или возможность проверять конфигурации во время регулярного просмотра кода.
• Если вы не работаете на ЦРУ, аргумент безопасности кажется мне раздутым. Таким образом, пароль вашей базы данных хранится в файле на компьютере, где работает ваше приложение. Что ж, если кто-то получит доступ к компьютеру с помощью вашего приложения, вы, вероятно, уже столкнулись с большими проблемами - он может, например, закрыть ваше приложение и запустить свое собственное приложение на том же порту. В таком случае доступ к паролю БД может не быть такой большой проблемой. Если все ваши соединения не будут полностью зашифрованы и не имеют доступа к вашему компьютеру, они все равно могут прослушивать большую часть интересных данных с сетевых интерфейсов.
• Вы можете использовать такой инструмент, как Hiera, чтобы иметь текстовый файл конфигурации, но не хранить в нем пароли или другие конфиденциальные данные.

Поэтому во многих случаях текстовая конфигурация, хранящаяся в системе контроля версий вместе с кодом, является хорошим началом.

Если вы работаете в распределенных системах или хотите иметь возможность горячей замены конфигурации без повторного развертывания приложений, вы можете лучше найти решение, основанное на сервере конфигурации. Spring Cloud поддерживает такие механизмы , и конфигурациями серверной части могут быть Git-репозиторий или Eureka . Вы также можете свернуть свои собственные, используя, например, Zookeeper . Любой из этих подходов облегчит управление согласованными конфигурациями на многих серверах, чтобы обновлять конфигурации без необходимости перестраивать и повторно развертывать программное обеспечение. Это, конечно, обходится дорого: изучение сервера конфигурации и его использования из ваших приложений, а также еще одной системы для развертывания и обслуживания.

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

Тем не менее, я думаю, что мы нашли хорошее решение в будущем. Мы перемещаем наши файлы конфигурации в отдельное git-репо (помеченное как config-репо). Затем мы настраиваем сервер spring-cloud-config (java), который просто обслуживает файлы из репозитория config на основе переданных ему профилей. Это отлично подходит для приложений Java, которые могут использовать клиент и загружать их во время запуска. Для наших PHP / не Java-приложений мы будем извлекать файл напрямую. (Не идеально). В будущем мы можем написать что-то, что позволит PHP-приложению самостоятельно загружать конфигурации и кэшировать их где-то, но это не является первоочередной задачей для первого запуска. Я рассматриваю это решение как конфигурацию как услугу, которая явно не нарушает рекомендации 12-факторных приложений.

Я полагаю, что zookeeper может использоваться для той же цели (я видел настройку с kubernetes + zookeeper), поэтому я не совсем уверен, почему этот ответ получил -1 выше.

Ссылки:

https://spring.io/guides/gs/centralized-configuration/

https://cloud.spring.io/spring-cloud-config/

Вместо того, чтобы хранить всю конфигурацию в одном файле, сохраните ее в нескольких файлах.

• Есть каталог конфигурации . Все файлы там интерпретируются как файлы конфигурации, за исключением, может быть README*.
• Все имена файлов отсортированы в алфавитном порядке, и файлы загружаются в указанном порядке. Именно поэтому файлы в таких случаях часто начинаются с цифры или два: 01-logging.json. 02-database.json, так далее.
• Данные из всех файлов загружаются в ту же структуру конфигурации, которая доступна для приложения. Вот как несколько файлов могут дополнять настройки друг друга и даже переопределять их предсказуемым образом.
• Храните в VCS только файлы конфигурации с безопасными для просмотра значениями или значениями по умолчанию. Добавьте файлы конфигурации с секретами во время развертывания или, что еще лучше, используйте службу хранения аутентифицированных секретов.

На ближайшем к вам Linux-сервере посмотрите /etc/sudoers.dили /etc/nginx/conf.d. Это показывает ту же картину.

Секреты управления это другой зверь. Вы можете управлять ими как ручным шагом, пока вы маленький. Вы можете использовать такие вещи, как Zookeeper. Вы даже можете проверить секреты в VCS в зашифрованном виде и расшифровать их как этап развертывания. Существует ряд других вариантов.

(Также, часть мнения: JSON не является хорошим форматом файла конфигурации, потому что он не допускает комментарии; комментарии имеют решающее значение. Форматы TOML, YAML и даже INI лучше в практическом использовании.)

Я думаю, что ваши параметры в некоторой степени определяются операционной системой, в которой вы развертываете

Я хотел бы предложить, да поставить значения в системе контроля версий. НО только версии 'dev'. Вы хотите, чтобы ваш исходный код компилировался и работал! не включать дополнительные секретные шаги

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

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