docker exec увидел новый ENV, приложение нет: область переменной

В контейнере включили отладку командой docker exec -e LOG_LEVEL=debug, затем проверили переменную через env. Значение на месте, но основной сервер продолжает писать прежние сообщения. Перезапуск отдельной команды ничего не меняет в окружении уже работающего приложения: docker exec создаёт новый процесс со своим набором параметров.

Окружение передаётся процессу при запуске. Оно не является общей редактируемой таблицей контейнера, которую все программы постоянно перечитывают. Поэтому export в интерактивной shell меняет настройки этой shell и её будущих детей. Основной сервер, запущенный раньше и не являющийся таким ребёнком, автоматически новое значение не получает.

Разделить диагностику и конфигурацию сервиса

Флаг -e удобен для одной диагностической команды. Например, можно проверить поведение утилиты с нужным значением, не меняя постоянную конфигурацию контейнера:

docker exec -e LOG_LEVEL=debug app env

Здесь app — имя существующего контейнера, а env должен присутствовать в его образе. Вывод этой команды описывает окружение нового процесса env. Он не подтверждает настройку основного сервера. Для изменения сервиса задайте переменную в Compose или при создании контейнера, затем пересоздайте его. Обычный restart использует сохранённую конфигурацию создания и не подхватит произвольные изменения интерактивной shell.

services:
  app:
    build: .
    environment:
      LOG_LEVEL: debug

После docker compose up -d для изменённого сервиса проверьте фактическое поведение приложения. Docker может передать LOG_LEVEL корректно, но приложение должно поддерживать это имя и читать его на старте. Если оно использует конфигурационный файл с более высоким приоритетом, переменная не изменит итоговый уровень логирования.

Сравнить источник и результат

Команда docker inspect позволяет увидеть Environment в конфигурации контейнера. Осторожно с полным выводом: там могут находиться секреты, поэтому для совместной диагностики выбирайте только нужное несекретное поле. Затем найдите стартовое сообщение приложения об эффективном уровне логирования или выполните действие, которое должно дать debug-сообщение.

Если приложение поддерживает перезагрузку настроек без рестарта, используйте его документированный интерфейс: сигнал, административный endpoint или перечитывание файла. Это отдельный механизм, а не побочный эффект docker exec. Он может быть полезен, когда активные соединения нежелательно прерывать, но требует собственной проверки и управления доступом.

После диагностики верните отладочный уровень к рабочему значению и пересоздайте сервис снова. Постоянную настройку храните в том же месте, откуда запускается проект. Тогда следующий коллега получит тот же результат из Compose-файла, а успешная разовая команда не будет создавать ложное ощущение, что конфигурация основного процесса уже изменена.

Продолжить практику

Эту настройку проще понимать в составе приложения, у которого есть сеть, данные и понятная процедура обновления. На курсе «Docker и Docker Compose: контейнеризация приложений» вы упакуете HTTP-сервис с PostgreSQL, разберёте конфигурацию, хранение данных и диагностику сбоев. В программе есть локальные лабораторные, работа с registry и версиями образов; итоговый проект включает передачу окружения другому разработчику и проверку восстановления базы.

Посмотреть программу курса

Источник: официальная документация.

Другие задачи по теме: Процессы, сеть, тома и сборка контейнера.