Лучшие практики для управления несколькими переменными среды в производстве

Question

Хотя я не знаком с лучшими практиками DevOps, я пытаюсь найти надежный и эффективный метод управления несколькими переменными в производстве. Следующее представляет мой текущий подход:

/
|ENV_VAR.sh
|--/api1
|--/staging.api1
|--/api2
|--/staging.api2

Где:

ENV_VAR. sh

### API 1 variables ###
export API1_VAR_1=foo
export API1_VAR_2=foo2
export API1_STAG_VAR_1=foo_stag
export API1_VAR_2=foo2_stag2

### API 2 variables ###
export API2_VAR_1=foo
export API2_VAR_2=foo2
export API2_STAG_VAR_1=foo_stag
export API2_VAR_2=foo2_stag2

API 1 и 2 основаны на двух nodejs приложения, работающие на одном сервере с использованием конфигурации обратного прокси. Если с сервером ничего не происходит (например, неожиданное отключение), мне просто нужно (пере) установить переменные время от времени через SOURCE ENV_VAR.SH, чтобы убедиться, что новые переменные определены.

Перед продолжением При таком подходе я хотел бы знать, является ли он правильным или имеет большой недостаток. Если с этим подходом все в порядке, как автоматически (повторно) получать переменные среды из package.json при развертывании новой версии любого приложения? (просто чтобы гарантировать, что переменные все еще определены)

Заранее спасибо.

Answer 1

Мне нравится использовать пакет Loren West config для этих параметров конфигурации. Мне нравится расширять его пакетом properties : таким образом, мне не нужно помещать параметры в допустимый, без комментариев формат JSON. JSON5 также помогает решить проблему читабельности, но я не пробовал.

Почему мне это нравится?

1. Это дает структурированный способ работы с средами разработки / тестирования / постановки / производства. Он отключает переменную окружения ENV, которая, конечно, имеет значения, такие как development и production.

2. Все файлы свойств go в одном каталоге, обычно ./config. Ваш производственный Krewe может сказать, что они смотрят. default.properties, development.properties и production.properties являются именами типичных файлов.

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

4. Секреты (пароли, строки подключения, ключи API и т. Д. c) могут храниться в local.properties файлах, помещенных в ./config вашей системой развертывания. (Упомяните local.properties в вашем .gitignore файле.)

5. Секреты также могут быть загружены из переменных среды, названных в файле с именем ./config/custom_environment_variables.json.

6. Отлично работает с pm2.

Это очень легко настроить.

Ваши файлы:

 default.properties   (used when not overridden by another file)
 [API1]
 VAR_1 = foo
 VAR_2 = foo2
 [API2]
 VAR_1 = foo
 VAR_2 = foo_for_api2

 staging.properties
 [API1]
 VAR_1 = foo_stag
 VAR_2 = foo2_stag2
 [API2]
 VAR_1=foo_stag
 VAR_2=foo2_stag2

 custom_environment_variables.json
 {
   "API1" : {
     "password": "API1_PASS"
   },
   "API2" : {
     "password": "API2_PASS"
   }
}

Ваша nodejs программа:

const config = require( 'config' )
require( 'properties' )
const appConfig = config.get( 'API1' )

const var1 = appConfig.VAR_1
const password = appConfig.password

Затем вы запускаете программу с API1_PASS=yaddablah nodejs program.js и получаете все свои настройки.