Как передать переменную среды в команду docker compose up?
Я хочу передать переменную среды в команду docker compose up, но, насколько я вижу, это возможно только с помощью команды docker compose run, как указано в официальной документации:
Установите переменные среды с помощью docker compose run --env
Подобно docker run --env, вы можете установить переменные среды в одноразовом контейнере с помощью docker compose run --env или его краткой формы docker compose run -e:
docker compose run -e DEBUG=1 web python console.py
Я пытаюсь интегрировать Spring Cloud Vault в приложение Spring Boot, и мне нужно обеспечить безопасность токена хранилища без использования k8 и т. д. Для этой цели, когда я запускаю приложение, я могу передать переменную среды (переменная vault_token), но мне также нужно передать эту переменную при запуске docker compose, как показано ниже:
docker compose up -e vault_token=00000000-0000-0000-0000-000000000000 --build
Итак, как я могу это сделать? Обратите внимание, что я не хочу читать из файла .env и просто пропускаю его при выполнении команды из соображений безопасности.
докер-compose.yml:
version: '3.8'
services:
vault:
container_name: vault
image: vault
restart: always
environment:
VAULT_DEV_LISTEN_ADDRESS: '0.0.0.0:8200'
# VAULT_DEV_ROOT_TOKEN_ID: 00000000-0000-0000-0000-000000000000
VAULT_DEV_ROOT_TOKEN_ID: ${vault_token}
ports:
- '8200:8200'
volumes:
- ./volumes/logs:/vault/logs
- ./volumes/file:/vault/file
- ./volumes/config:/vault/config
cap_add:
- IPC_LOCK
Примечание. Я использую Windows 11.
Да, вы правы, и я думал об этом. Я добавил, не могли бы вы взглянуть на?
Ответы 2
просто пройдите во время выполнения команды из соображений безопасности
Это помещает ваш токен в историю вашей оболочки, что не следует считать безопасным... Итак, почему файл .env предпочтительнее.
Но вместо этого вы также можете использовать интерполяцию.
env:
- MY_VARIABLE
или
env:
MY_VARIABLE: ${MY_VARIABLE}
С
MY_VARIABLE=foobar docker compose up
или (при условии Linux)
export MY_VARIABLE=foobar
docker compose up
Однако обратите внимание, что они также отображают ваш токен в виде открытого текста в истории вашего терминала. Чтобы обойти это, вы можете source внешний файл или обернуть docker compose up скрипт.
Однако если вы будете использовать Kubernetes (или даже Nomad), то секреты Vault могут быть смонтированы как прямые переменные среды в контейнеры, и поэтому вашему коду вообще не нужно напрямую использовать Vault API, поэтому не требуется токен. .
Хм, хорошо, что я не подумал (терминальная история). Согласен, что к8 лучший способ, но пока (как новичок) хочу воткнуть решение без к8. Итак, могу ли я получить ваше ценное мнение по этим вопросам? -->>>>
Обычно я передаю переменные среды через файл .env в свои файлы docker-compose.yml и application.yml путем интерполяции, а при публикации или отправке проекта пользователям/покупателям я просто добавляю демонстрационные значения в качестве переменных среды в этот файл. Затем предупредите пользователей/клиентов, чтобы они обновили все параметры в этом .env файле. Однако в этом сценарии я не уверен, понадобится ли пользователям один из этих параметров (токен хранилища) после запуска docker-compose. Предположим, что я отправляю проект заказчику, они обновили значения в файле .env. Затем запустите docker compose. -->
Затем они удаляют содержимое этого .env файла. В этом случае им понадобится большинство этих параметров, например. (vault_token, database_password) каждый раз, когда они запускают приложение. Это правда? Если это так, им нужно будет хранить эти конфиденциальные данные в этом файле, верно?
@jonathan Файл .env не должен быть включен в проект, например репозиторий Git. Его следует добавить в .gitignore. Вы можете добавить .env.example с пустыми значениями. Затем вы должны задокументировать, как его использовать, и быть уверенным, что пользователи его прочитают. Обходного пути нет, и следует ожидать ошибки, если переменная не определена.
В качестве альтернативы вы можете задокументировать использование minikube и Helm с развернутым Vault Operator... Любой, кто в настоящее время использует Docker для рабочего стола, уже имеет доступный кластер Kubernetes, который можно использовать, и нет особой необходимости в Docker Compose для сложных рабочих процессов, которые на самом деле не нужны. требуется Vault SDK в исходном коде.
Хорошо, обычно я добавляю .env к .gitignore, но в таких ситуациях пользователю нужно будет использовать его. Итак, я предоставлю файл .env с пустым значением, но должен ли он быть .env.example ? В смысле, почему бы не .env вместо него?
Я также задокументирую, но, насколько я понимаю, вы предлагаете использовать Kubernetes, чтобы избавиться от подобных проблем (защита токена также для хранилища). Буду конечно, но для этого конкретного примера я только новичок и не хотел бы его использовать.
1) Не делитесь .env, потому что это ваш собственный файл с вашими секретами. Поэтому вы не должны фиксировать этот файл. Например, запуск нового контейнера Vault создает совершенно другой токен. 2) «Новичок», ничего не знающий, не знает разницы между Docker Compose и Minikube. Как уже упоминалось, если используется Docker Desktop, kubernetes уже доступен, и в него можно установить Vault Operator. За последние несколько месяцев я столкнулся с несколькими проектами с открытым исходным кодом, в которых нет файла компоновки, но есть диаграммы Helm.
Переменная в сеансе «среда» будет использоваться внутри контейнера. Если вам нужно установить переменную внутри контейнера, это нормально.
Чтобы использовать переменные системы во время компоновки докера, разверните контейнер, просто вызовите его:
Определите переменную среды vault_token в системе (Linux):
export vault_token = "Token12345"
Получите переменную в файле компоновки докера, например, в сеансе команд:
command: server -dev -dev-root-token-id=${vault_token}
Покажите пример файла
docker-compose.yml, который вы используете с этой командой, вместе сDockerfile, если это имеет смысл. Обратите внимание, что это не обязательно должен быть весь вашdocker-compose.yml, нужно только показать, где используются переменные среды.