Как происходит сохранение конфигурации для 12-факторного приложения? - PullRequest
0 голосов
/ 10 декабря 2018

, поэтому я собирал свое приложение в основном как 12-факторное приложение, и теперь смотрю на часть конфигурации.

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

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

Так что различные статьи и блоги не упоминают о конфигурации, это как хранится / обрабатывается конфигурация.Если код разделен в его собственном git-репозитории, и в нем нет сохраненного конфига, то как мы будем обрабатывать конфиг?/ выполнить их в целевой среде (карта конфигурации Kubernet, конфигурация JSON марафона, хранилище и т. д.) в процессе сборки с использованием какого-либо триггера?

1 Ответ

0 голосов
/ 10 декабря 2018

Не существует стандарта, но я наблюдаю некоторые распространенные поведения, такие как:

  1. Чувствительная информация никогда не попадает в систему управления версиями, особенно git, котораяявляется DCVS (вы можете клонировать репо для других мест).Если вы не следите, помните, что наша существующая «система безопасности» основана на неспособности считывать криптоинформацию в определенное время, но в определенный момент вы можете прочитать эту информацию.Обычно в kubernetes я вижу операторов, управляющих служебной учетной записью в нескольких пространствах имен, а затем другие, относящиеся только к служебной учетной записи, приветствуются такие инструменты, как KMS, Cert manager, Vault и т. Д.

  2. Конфигурация , как env vars, конечные точки, хранятся и версии с собственным «жизненным циклом».

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

На самом деле, если вы хотите использовать отдельное хранилище только для конфигурации, вы можете сделать это, но если вы хотите отложить в исходный код проекта конфигурацию, вы можете сделать это также.Это скорее решение, основанное на размере проекта, сложности, разделении обязанностей и командном контексте.(ИМХО)

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

...