Comments 20
добавлять django.contrib.postgres нужно только если используешь PostgreSQL specific features
настройки в DATABASES лучше передавать через переменные окружения, а не явно их прописывать. Для pgdb же сделано, почему так же и для остальных не сделать?
а зачем AutoField писать? он и так уже есть у Model
как использовать докер, хорошо посмотреть у крупных проектов на github, например, https://github.com/saleor/saleor-platform/blob/main/docker-compose.yml https://github.com/saleor/saleor/blob/main/Dockerfile
Я начинающий разработчик и хочу поделиться своим решением проблемы, с которой столкнулся и не нашел готового решения в интернете.
Серьезно? Это вот прям проблема, решение которой достойно аж отдельной статьи? И прям решений в интернете нет?
Попробуйте вот этот сайт https://letmegooglethat.com/?q=dockerize+django+postgres
Шаг 1: Не суйте СУБД в контейнер.
Конец.
Только что хотел это написать) Советую всегда БД на отдельном сервере разворачивать. Или в виртуалке, если учитесь и для себя делаете. Не нужно воплощать в жизнь плохие практики
я так понимаю это касается прода, никогда не пихал базу в контейнер, но интересно почему это не рекомендуется?
сервис API тоже не рекомендуется в контейнере заливать на прод?
Дело в том, что контейнеры очень любят падать и штука эта вообще не стабильная. К примеру, вы поднимаете свой Django проект в контейнере вместе с БД, всё работает отлично. Трафик и идёт, пользователи авторизируются, базёнка всё сохраняет. Но вдруг происходит какая то ошибка и тогда сразу контейнер завершит свою работу и падает, и все данные в БД и сама БД исчезают.
Контейнеры нужны только для того, чтобы изолировать программу от хоста со своими зависимостями. Благодаря этому контейнеры жрут мало ресурсов по сравнению с ВМ. Но обратная сторона медали - это скудное его наполнение, только самое необходимое (файловая система, плюс возможность создать процесс). А держать БД в контейнере - плохая идея, потому что он в целом не предназначен под работу с дисковой памятью, да и изоляция БД от хостовой системы не требуется, потому что дисковая память итак изолирована, сегментирована. Если контейнер упадёт, то вы потеряте файл БД и все данные, там хранящиеся.
Для решения проблемы устойчивости контейнеров как раз и придумали Kubernetes, который сам чуть что сбалансирует трафик, переподнимет, так же ещё можно сделать несколько реплик одного и того же приложения (для горизонтального масштабирования), можно задать количество потребляемых ресурсов на контейнер (RAM и CPU). Но Kubernetes также не решает проблемы БД (хотя потуги есть, например, StatefulSet)Сервис API в контейнере - это самое популярное и правильное решение. Но рекомендуется выносить БД на отдельный сервер, куда сервис API будет слать данные и брать оттуда. Так вы обеспечите сохранность и нивелируете кучу рисков. Также на сервере рекомендуется создать крон для бекапирования БД(на всякий случай). Ну и в идеале конечно вообще сделать несколько реплик БД, которые живут на разных серваках, географически разделенных с бекапами, блекджеком и тд :)). Так обеспечивается 99.99% сохранения данных.
Также, желательно, на проде иметь Kubernetes, который и будет оркестрировать ваши контейнеры с сервисами. Для этого он представляет все возможности (внутреннюю сеть, неймспэйсы для изолирования, про реплики и балансировку описал выше)
Но вдруг происходит какая то ошибка и тогда сразу контейнер завершит свою работу и падает, и все данные в БД и сама БД исчезают.
Если контейнер упадёт, то вы потеряте файл БД и все данные, там хранящиеся.
Эм... Что, простите?
Но рекомендуется выносить БД на отдельный сервер
Кем рекомендуется? Поделитесь рефенсами на исследования об этом. Желательно за последние лет 10.
А в случае если сервер один ? На хосте, а приложение в докер?
На Stackoverflow есть хороший ответ на эту тему от одного из разработчиков PostgreSQL.
"PostgreSQL DBA, время от времени контрибьютор проекта." != разработчик PostgreSQL
Итак, файловая система необходима хоста, сеть необходима хоста. Итог - а зачем вам вообще база (в смысле получается только её исполняемые бинарники) в докере? Что вы отсюда хотите получить?
Я хочу отсюда получить возможность запускать в рамках одной машины десятки/сотни постгресов произвольных версий и, возможно, по разному настроенных. И потом так же просто их бесследно удалять.
"PostgreSQL DBA, время от времени контрибьютор проекта." != разработчик PostgreSQL
В кодовой базе есть его код - значит разработчик.
Я хочу отсюда получить возможность запускать в рамках одной машины десятки/сотни постгресов произвольных версий и, возможно, по разному настроенных. И потом так же просто их бесследно удалять.
Цитата из вышеупомянутого ответа
Более того, сама надобность иметь сотни постгресов сомнительна и может означать, что разработчик не изучил возможности СУБД и изобретает велосипед.
Для разработки почему бы и нет?
Когда у тебя много проектов, то очень удобно запустить бд для конкретно этого проекта одной командой, а потом так же быстро остановить
А в случае прода соглашусь
Сейчас я ищу работу и не впервые сталкиваюсь с ситуацией, когда в тестовом задании требуется упаковать проект с базой данных в Docker и предоставить его работодателям. Поэтому решил написать туториал - вдруг кому-то будет полезно.
Стал замечать, что становится много токсичных комментариев к статьям хаба. Причем не негативных/отрицательнах, а именно токсичных. И не зависит причём от тематики. Печально конечно такую тенденцию наблюдать... :-(
Здравствуйте, остановился на шаге 9. Вроде, всё запустилось, но по адресу: http://localhost:8000 не устанавливается соединение. Подскажите, в чём может быть причина?
Связь Django и PostgreSQL внутри Docker