Почему при сборке compose не видит переменные окружения?

Question

[Alexej Belkin]

Хочу пароль и логин закинуть в переменные окружения, чтобы не хранить конфигах.
В сервисе docker-compose.yml указал переменные окружения:

db:
    image: postgres:14.6
    container_name: postgres-db
    restart: always
    environment:
      POSTGRES_PASSWORD: "${PASSWORD_FOR_DOCKER}"
      POSTGRES_USER: "${USER_FOR_DOCKER}"
      POSTGRES_DB: "db_docker"
    expose:
      - 5432

Но при поднятии сервиса и вводе логина и пароля - не дает войти. Можно ли как-то это реализовать в компосе или единственный выход - это поднимать самому контейнеры и указывать там все параметры в консоли?

Comments

[Alexej Belkin]

Justa Gain, попробовал запустить компос так:

export PASSWORD_FOR_DOCKER=123 USER_FOR_DOCKER=d_user; docker-compose up -d

Потом решил проверить информацию о переменных запущенного контейнера(начинается на 3f3) через:
docker inspect 3f3
Он мне показал что они встали:

.......
"Env": [
                "POSTGRES_USER=d_user",
                "POSTGRES_PASSWORD=123",
                "POSTGRES_DB=db_docker",
      .........

Но когда пытаюсь авторизоваться в админере вводя этот логин и пароль, то сообщает:

... port 5432 failed: FATAL: password authentication failed for user "d_user"

[Valentin Barbolin]

Открой shell в контейнере и проверь есть ли там эти переменные в окружении.

[Alexej Belkin]

Valentin Barbolin, да есть
написал:
docker exec -i -t 3а3 bash
потом
env
Там лежит:

...
POSTGRES_PASSWORD=123
POSTGRES_USER=d_user
...

[Valentin Barbolin]

Alexej Belkin, Значит он их видит. Проблема в другом месте. Смотри логи своих контейнеров.

Но при поднятии сервиса и вводе логина и пароля

Ты в sql пытаешься зайти или в какое-то приложение которое использует sql?

[Alexej Belkin]

Все разобрался. Не знаю конечно как это работает, но заметил, что если запускать все с нуля, то все прекрасно работает - он подтягивает из виртуального окружения переменные.
Но если остановить контейнере, а потом поменять конфиги, то видимо, что БД инициализировалась со старыми данными, поэтому для входа надо использовать старые данные.
--
Видимо единственное решение при внесении изменений - это заходить в консоль контейнера БД и заводить пользователя с паролем, который будет висеть в виртуальном окружении

[nolotion]

Alexej Belkin, можете вынести volume для базы и грохать ее одновременно с изменением конфигов. Тогда initdb будет запускаться заново при старте остановленного контейнера. Хотя юзкейс странный - зачем менять рутового пользователя и пароль на поднятой базе через окружение.

[shurshur]

Alexej Belkin, всё так и есть, при любых изменениях контейнер надо полностью пересоздавать.

[Alexej Belkin]

nolotion, Ну, например в целях безопасности - менять пароль раз в месяц.

[nolotion]

Alexej Belkin, пароль для рутового пользователя берется из окружения _только_ при первом запуске контейнера.
Менять пароль рута в контейнере ради безопасности - еще более сомнительное занятие. У вас база в контейнере, какая безопасность еще. Это продакшен что ли? 0_o

[Alexej Belkin]

nolotion, база не совсем в контейнере, там есть volume. Я просто в вопросе не указал это, но он там есть и при инициализации все сохраняется не в самом контейнере, а на диске. Соответственно, если контейнер остановить и перезапустить(да даже если образ пересобрать по новой), то все данные сохранятся в БД.

Answer 1

[khevse]

Опция --env-file должна помочь: