https://gist.github.com/nacknime-official/45497fb0797e3f997fbad03ee51bf1e6
Докер не гарантирует порядок запуска контейнеров. Нужно на уровне приложения или его entrypoint проверять, что база запустилась и готова обрабатывать запросы, а уже потом пытаться выполнять миграции и запросы. Например, я использую вот такой скрипт https://github.com/dolfinus/arkenston-backend/blob/master/wait_for_postgres.sh
о, прикольно, видел этот pg_ready где-то, спасибо) но у меня бот в итоге запускается, всё окей, эти ошибки просто засирают логи)
Приложение пытается повторно применить миграцию в случае ошибки, вот и дожидается, пока база не начнет отвечать
а, понял, спасибо за инфу)
не смущает /var/run/postgresql:5432?
да, смущает) всё-таки нужно задавать PGHOST и другие вары перез запуском pg_isready?
Блин, ну очевидно же, что да. В том скрипте, что я скидывал, явно задаются переменные окружения с хостом, портом и credentials для подключения к базе
та думал что можно без них)
Чтобы он с базой общался посредством телепатии?
думал сам определит) но новый вопрос возник: у меня нету ни pg_isready, ни psql, ибо это образ python:3.8-slim, а пихать целую постгрю в образ, который не подразумевает наличие постгри (ибо compose создает отдельный контейнер с постгрей), не буду как быть?(
pg_isready и psql находятся не в пакете postgres-server, а в postgres-client, который весит от силы пару мегабайт
не, я уже пробовал, он мне много чего скачивал
--no-install-recommends использовал?
Обсуждают сегодня