Просто передайте его как переменную окружения (например, APP_ENV) вашему приложению и используйте System.getenv("APP_ENV") для доступа к нему. Это одна из лучших практик приложения из двенадцати факторов , кстати.
Способ передачи контейнера зависит от способа его запуска.
Docker запустите
Передайте переменные напрямую через --env / -e опции для docker run команды или сохраните их в файле и передайте весь файл через --env-file:
docker run -e VAR1 --env APP_ENV=dev --env-file ./env your_image:latest
Docker compose
Используйте environment или env_file (обратите внимание, что они устанавливают переменную NODE_ENV в документах, как и в вашем случае! ):
version: '3'
services:
app:
image: 'your_image:latest'
env_file:
- ./env
environment:
- APP_ENV=dev
Kubernetes
Использование env:
spec:
containers:
- name: app
image: your_app:latest
env:
- name: APP_ENV
value: "dev"
В k8s вы можете ссылаться другой значения в переменных среды, поэтому среда может храниться в метаданных.
Конечно, существуют и другие способы предоставления значений приложению, например:
- Генерация кода и замены во время сборки. Он может использоваться, например, для предоставления Git ревизии: вывод
git rev-parse просто подставляется где-то в вашем коде. Требуется дополнительная конфигурация сборки + вам потребуются разные сборки для разных envs. - Аргументы программы. Это так же просто, как запустить
app arg1 arg2 ... dev ... argn. Очень похоже на переменные окружения, но, IMHO, имеет недостаток: программные аргументы доступны только в точке входа вашей программы (main), поэтому вам нужно будет проанализировать их и перейти к другим частям приложения. Я подхожу для некоторых динамических c входов, но неудобен для статических c данных, таких как среда приложения. - Метаданные поставщика, такие как EC2 Метаданные экземпляра и Данные пользователя . Для доступа требуются определенные c API.
Как вы видите, ни один из них не обеспечивает сочетание гибкости, повсеместности и простоты переменных среды.