Подход Git Branch рекомендован fabric8. Из документации Helm по репозиторию gihub они вообще не используют kubeclt, все управляется через установку helm и т. Д. Но, может быть, я что-то упустил?
есть приложение, которое работает на GKE Kubernetes и ожидает, что в качестве переменной среды будет передан URL-адрес авторизации (на который пользователь будет перенаправлен через браузер).
Мы используем разные пространства имен для каждой среды
Итак, наша текущая конфигурация pod выглядит примерно так:
env:
- name: ENV
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: AUTH_URL
value: https://auth.$(ENV).example.org
И все работает потрясающе, у нас может быть столько динамических сред, сколько мы хотим, мы просто применяем -f config.yaml, и он работает без сбоев, не меняя один файл конфигурации и не создавая никаких сторонних скриптов.
Теперь для производства мы хотим использовать другой домен, поэтому общая схемаhttps://auth.$(ENV).example.org
больше не работает.
Какие у нас есть варианты?
Поскольку конфиги находятся в git repo, создайте отдельную ветку дляprod
средаИметь ConfigMap по умолчанию и определенный для среды prod, и запускать его через какой-то скрипт (если есть)prod-config.yaml
затем используйте это, иначе используйтеconfig.yaml
) - но при таком подходе мы больше не можем напрямую использовать kubectlПереместите этот конфиг на уровень приложения и получите отдельный файл конфигурации дляprod
env - но этот вид идет вразрез с приложением 12factor?Другой...?