Подход 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?Другой...?

Ответы на вопрос(2)

Ваш ответ на вопрос