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

Стандарта нет, но то, что я наблюдал, — это некоторые распространенные модели поведения, такие как:

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

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

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

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

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