Как мне хранить переменные среды?

Это очень широкий вопрос о методах и рекомендациях относительно переменных / структуры среды. Но в конечном итоге я ищу ответы на очень специфический вопрос «Как хранить переменные среды?».

Сначала некоторые уточнения:

• Среда для меня может быть от 3 до 10 серверов и является способом сдерживания инфраструктуры конкретного клиента.
• Внутри каждой среды есть несколько переменных, которые в основном автоматически генерируются из нескольких ключевых входных данных (имя, размер и т. Д.).

В настоящий момент мы храним все переменные окружения в такой структуре:

<playbook>.yml                   # Various playbooks for deployment
roles/windows                    # Ansible role for Ubuntu
roles/ubuntu                     # Ansible role for Ubuntu
config/hosts/<name>.yml          # Ansible inventory
config/hosts/vars/<name>.json    # Environment specific variables 

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

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

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

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

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

Какие-либо предложения?

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

Общие Факторы

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

Использование Consul KV Pairs

Переменные среды загружаются из репозитория артефактов (никогда не из исходного git-репо) и загружаются, например, в дерево пар KV с пространством имен

/env/dev1/my/application/v1.1.1

Если предыдущий dev1 - это имя среды, my / application - это пространство имен приложения, а v1.1.1 - версия переменных среды, которые следует использовать.

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

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

Хранение «Развертывания» Артефакта со встроенными переменными

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

Сам артефакт развертывания представлял собой файл yaml, в котором содержался URL-адрес выпускаемого двоичного файла и вся присоединенная к нему конфигурация.

Платформа содержит компоненты для чтения переменных и их вывода в дерево процессов приложения при запуске.

До сих пор это было гораздо более успешным, потому что есть артефакт, который мы можем проследить в истории и который мы можем передать любой доске обзора и сказать: «Это единственный артефакт, который нас волнует, нам не нужно смотреть на него». любые другие изменения, только изменения в этой вещи "(т. е. версия приложения для развертывания, переменные среды включены и т. д.

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

Бонусные очки

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

Общеизвестно, что управление секретами - это своя червя. Но, наверное, стоит задуматься.

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

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

Если вы используете репозиторий артефактов , убедитесь, что артефакты имеют правильную версию и эти версии правильно указаны в переменных среды.

Автоматизация важна, потому что переменные среды не должны обновляться людьми, где это возможно, а должны генерироваться сценариями. Удостоверьтесь, что в инвентаризации для каждого клиента почти нет обновлений вручную, а разработчики обновляют только репозитории кода. Если они хотят внести изменения в конфигурацию, это следует сделать с одним из генерирующих сценариев, который затем запускается для генерации переменных, и diff сохраняется в репозитории клиента. Стоит настроить непрерывную интеграцию для этого процесса. Без этого в какой-то момент будет слишком много хранилищ для обслуживания .