Текст и данные · Инструкция
Docker Compose env_file и .env: в чём разница
`.env` и service `env_file` выглядят похоже, потому что оба содержат KEY=VALUE, но используются на разных этапах. `.
Короткий ответ
`.env` обычно участвует в подстановке значений в Compose-модель, а `env_file` у сервиса передаёт переменные в environment контейнера. Это разные этапы.
Где Compose берёт переменные
Одинаковый формат KEY=VALUE сбивает с толку. `${TAG}` в `image:` обрабатывается Compose CLI при построении модели, а service `env_file:` формирует переменные среды процесса внутри контейнера. Источники interpolation имеют свой precedence: shell environment, `--env-file`, затем стандартный `.env` проекта при обычном запуске. Для проверки Docker рекомендует `docker compose config --environment`.
Совет: Проверяйте interpolation через `config --environment`, а container env — внутри запущенного сервиса.
Как проверить переменные на двух этапах
- Определите, где нужна переменная: в модели или приложении.
- Для `${VAR}` проверьте shell, --env-file и .env.
- Для контейнера проверьте environment и env_file сервиса.
- Выполните `docker compose config --environment`.
- Сравните с `docker compose run SERVICE env`.
Предупреждение: Не используйте один секретный файл во всех ролях только ради удобства — разделяйте назначение.
Нюансы: environment variables и interpolation
Service env_file имеет отдельные правила и путь, связанный с расположением compose.yaml. Несколько files могут задаваться в порядке, где последующие значения переопределяют предыдущие. Если переменная видна в итоговом image name, но отсутствует внутри application, это не противоречие: возможно, она использовалась только на этапе interpolation и не передавалась в container environment.
Важно: Если значения расходятся, найдите источник с более высоким precedence вместо случайного редактирования файлов.
Пример: TAG и DATABASE_URL
`TAG=v1.5` в `.env` может подставить `image: web:${TAG}`, а `env_file: app.env` передаст `DATABASE_URL` процессу приложения.
Как проверить обе группы переменных
Сначала выполните `docker compose config --environment`, чтобы увидеть значения, которыми Compose интерполирует YAML. Затем посмотрите `docker compose config` и environment запущенного контейнера. Так становится понятно, потерялась переменная до создания контейнера или уже на этапе передачи в process environment.
Почему один KEY может иметь разные значения
Compose применяет precedence и к interpolation, и к container environment, но это разные правила. Shell может переопределить `.env` для `${VAR}`, а `environment:` может переопределить service `env_file`. Поэтому диагностика должна фиксировать конкретный этап, а не просто искать «последний файл с KEY».
Где Compose берёт переменные
- .env / --env-file / shell. интерполяция `${VAR}` в Compose-модели. `docker compose config --environment`
- service env_file. передача переменных окружения внутрь контейнера. смотреть итоговый service environment
- service environment. явные значения для контейнера. учитывать правила приоритета над env_file
Что учитывать
Compose применяет precedence и к interpolation, и к container environment, но это разные правила. Shell может переопределить `.env` для `${VAR}`, а `environment:` может переопределить service `env_file`. Поэтому диагностика должна фиксировать конкретный этап, а не просто искать «последний файл с KEY».
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. Compose variable interpolation). Пример и формулировки — редакция N1RO на 2026-09-22.