Переменные среды - это первоклассная концепция в Openshift. Есть много способов их использования:
- Вы можете установить их непосредственно в BuildConfig, чтобы «запекать их» в ваши контейнеры. Это не лучшие практики, так как тогда они не изменятся при перемещении их через среды, но могут потребоваться для настройки вашей сборки или установки вещей, которые не изменятся (например, установите номер порта, который используется node.js для соответствия официальному узлу .js изображение с ”PORT = 8080”)
- Вы можете поместить такие переменные в объекты конфигурации ConfigMap или Secret, чтобы легко делить их между многими похожими BuildConfig
- Вы можете установить их непосредственно в DeploymentConfig, чтобы они устанавливались для каждого модуля, запускаемого этим развертыванием. Это довольно распространенный способ настройки переменных среды приложения. Не рекомендуется использовать это для настроек, которые используются несколькими приложениями, так как вам придется менять общие переменные во многих местах.
- Вы можете настроить их в ConfigMaps и Secrets и применить их к нескольким DeploymentConfigs. Таким образом, вы можете управлять ими в одном месте.
Обычно разработчики используют файл .env с именем в .gitignore, поэтому не в git. В прошлом я писал сценарии для загрузки этого секрета в openshift, а затем использовал envFrom для установки этого секрета при развертывании. Затем есть .env.staging и .env.live, которые мы git secret зашифровали в git.
Проблема с файлами .env заключается в том, что они имеют тенденцию запутываться и через некоторое время иметь неиспользуемый мусор. Таким образом, мы разбили файл на один Секрет, который будет кредитом базы данных, отдельными Секретами для каждого кредита API, ConfigMap для конкретных приложений. ConfigMap для общих настроек.
В наши дни мы используем Helmfile для загрузки всех наших настроек из git на основе git webhooks. Весь конфиг - это yaml в git-репо (с зашифрованным секретным yaml). Если вы объединяете изменения в config git repo, обработчик webhook расшифровывает конфигурацию и запускает Helmfile для обновления настроек в openshift. Я нахожусь в процессе открытых источников всего, включая использование чат-бота для управления выпусками (необязательно) на GitHub
Я также должен сказать, что openshift автоматически создает множество переменных среды, чтобы помочь вам настроить ваши приложения. В каждом проекте множество переменных устанавливается в каждом модуле, сообщая вам детали всех сервисов, которые вы настроили в этом проекте.
Openshift также настраивает внутренние записи DNS для ваших сервисов. Это означает, что если приложение A использует приложение B, вам не нужно настраивать A с URL-адресом для B самостоятельно. Скорее, будет запись dns для B, и вы можете использовать переменные env, которые openshift устанавливает для A, чтобы определить запись dns и номер порта для использования (например, запись dns включает имя проекта и автоматически устанавливается как env var по openshift). Таким образом, наши приложения могут найти сервис Redis, работающий в том же проекте, используя эту технику.