Search
Write a publication
Pull to refresh

Comments 20

PinnedPinned comments

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

  • добавлять 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. я так понимаю это касается прода, никогда не пихал базу в контейнер, но интересно почему это не рекомендуется?

  2. сервис API тоже не рекомендуется в контейнере заливать на прод?

  1. Дело в том, что контейнеры очень любят падать и штука эта вообще не стабильная. К примеру, вы поднимаете свой Django проект в контейнере вместе с БД, всё работает отлично. Трафик и идёт, пользователи авторизируются, базёнка всё сохраняет. Но вдруг происходит какая то ошибка и тогда сразу контейнер завершит свою работу и падает, и все данные в БД и сама БД исчезают.

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


    Для решения проблемы устойчивости контейнеров как раз и придумали Kubernetes, который сам чуть что сбалансирует трафик, переподнимет, так же ещё можно сделать несколько реплик одного и того же приложения (для горизонтального масштабирования), можно задать количество потребляемых ресурсов на контейнер (RAM и CPU). Но Kubernetes также не решает проблемы БД (хотя потуги есть, например, StatefulSet)

  2. Сервис API в контейнере - это самое популярное и правильное решение. Но рекомендуется выносить БД на отдельный сервер, куда сервис API будет слать данные и брать оттуда. Так вы обеспечите сохранность и нивелируете кучу рисков. Также на сервере рекомендуется создать крон для бекапирования БД(на всякий случай). Ну и в идеале конечно вообще сделать несколько реплик БД, которые живут на разных серваках, географически разделенных с бекапами, блекджеком и тд :)). Так обеспечивается 99.99% сохранения данных.

    Также, желательно, на проде иметь Kubernetes, который и будет оркестрировать ваши контейнеры с сервисами. Для этого он представляет все возможности (внутреннюю сеть, неймспэйсы для изолирования, про реплики и балансировку описал выше)

Но вдруг происходит какая то ошибка и тогда сразу контейнер завершит свою работу и падает, и все данные в БД и сама БД исчезают.

Если контейнер упадёт, то вы потеряте файл БД и все данные, там хранящиеся.

Эм... Что, простите?

Но рекомендуется выносить БД на отдельный сервер

Кем рекомендуется? Поделитесь рефенсами на исследования об этом. Желательно за последние лет 10.

А в случае если сервер один ? На хосте, а приложение в докер?

На Stackoverflow есть хороший ответ на эту тему от одного из разработчиков PostgreSQL.

"PostgreSQL DBA, время от времени контрибьютор проекта." != разработчик PostgreSQL

Итак, файловая система необходима хоста, сеть необходима хоста. Итог - а зачем вам вообще база (в смысле получается только её исполняемые бинарники) в докере? Что вы отсюда хотите получить?

Я хочу отсюда получить возможность запускать в рамках одной машины десятки/сотни постгресов произвольных версий и, возможно, по разному настроенных. И потом так же просто их бесследно удалять.

"PostgreSQL DBA, время от времени контрибьютор проекта." != разработчик PostgreSQL

В кодовой базе есть его код - значит разработчик.

Я хочу отсюда получить возможность запускать в рамках одной машины десятки/сотни постгресов произвольных версий и, возможно, по разному настроенных. И потом так же просто их бесследно удалять.

Цитата из вышеупомянутого ответа

Более того, сама надобность иметь сотни постгресов сомнительна и может означать, что разработчик не изучил возможности СУБД и изобретает велосипед.

У меня не один разработчик на сервере, а 10, каждый пилит свои сервисы для разных департаментов и, возможно, организаций. Вы кому предлагаете это все администрировать при помощи "отличного скрипта pg_ctlcluter"? Мне? Или им доступ дать? А разные версии они тоже себе поднимать будут?

Для разработки почему бы и нет?
Когда у тебя много проектов, то очень удобно запустить бд для конкретно этого проекта одной командой, а потом так же быстро остановить

А в случае прода соглашусь

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

Стал замечать, что становится много токсичных комментариев к статьям хаба. Причем не негативных/отрицательнах, а именно токсичных. И не зависит причём от тематики. Печально конечно такую тенденцию наблюдать... :-(

Не переживайте, это, по всей видимости, продлится недолго - обнулить карму я, к сожалению, могу только один раз :)
По комментариям понятно. А наличие таких статей на хабре вас в целом воодушевляет или какие чувства вы испытываете?

Хабр я читаю читаю постоянно. Конкретно данную статью смотрел обзорно (бегло), т.к. сам специализируюсь на других направлениях.

Здравствуйте, остановился на шаге 9. Вроде, всё запустилось, но по адресу: http://localhost:8000 не устанавливается соединение. Подскажите, в чём может быть причина?

Sign up to leave a comment.

Articles