В пайплайне нужно использовать разные значения API_URL для dev/staging/prod. Как организовать такую конфигурацию, не хардкодя значения в коде приложения?

Короткий ответ

Значение `API_URL` нужно задавать как переменную окружения (или параметр конфигурации — ConfigMap/values-файл), специфичную для каждого окружения, и считывать её в коде приложения во время запуска, а не записывать напрямую в исходный код.

Как это работает подробнее

один и тот же собранный артефакт (образ, бинарник) деплоится в разные окружения с разным набором переменных окружения или примонтированной конфигурацией — приложение при старте читает `API_URL` из окружения и использует её, не зная заранее, в каком окружении оно работает.

Пример кода

example1.yamlКопировать

# values-staging.yaml
env:
  API_URL: https://api-staging.example.com
# values-prod.yaml
env:
  API_URL: https://api.example.com

Пример кода

example2.shКопировать

helm upgrade myapp ./chart -f values-staging.yaml   # для staging
helm upgrade myapp ./chart -f values-prod.yaml      # для prod

Что использовать на практике

• На практике. такой подход — часть принципа «twelve-factor app» (хранить конфигурацию в окружении) и необходимое условие для build once, deploy many: если зашить URL в код, пришлось бы пересобирать артефакт отдельно для каждого окружения, теряя гарантию, что в прод попало именно протестированное на staging.
• Пример. Ожидаемое поведение: один и тот же Docker-образ приложения в поде staging обращается к `api-staging.example.com`, а в поде prod — к `api.example.com`, в зависимости от переменной окружения, заданной через Helm values.

Подводные камни

• Частые ошибки. хардкодят `API_URL` в коде с условием `if environment == "prod"`, что требует пересборки при каждом изменении инфраструктуры; хранят разные версии кода для разных окружений в отдельных ветках, вместо того чтобы параметризовать конфигурацию.