LINUX.ORG.RU

Docker и Django - развертывание приложений

 ,


0

2

Привет всем. Есть ли однозначно годные рецепты деплоя django-приложений с помощью docker'а? Или каждый отдельный случай - особенный? Нужно ли создавать в таком случае virtualenv и если да, то как правильно? Гуглил гугл, но похоже, единого рецепта нет, буду рад вашим объяснениям.

Прилагаю свой Dockerfile:

FROM python:3.9
ENV PYTHONBUFFERED 1
ENV VIRTUAL_ENV=/MarketProject/env
ENV PATH="$VIRTUAL_ENV/bin::$PATH"
RUN mkdir /MarketProject
RUN python -m venv /MarketProject/venv
WORKDIR /MarketProject
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . /MarketProject
До кучи docker-compose.yaml:
services:
  web:
    build: .
    command: python manage.py runserver localhost:8000
    ports:
      - 8000:8000

Почему-то не хочет коннектиться браузер после старта контейнера с сервисом.

venv не нужен (но и мешать не будет), рецепта нет (всё зависит от зависимостей)

Goury ★★★★★
()

Такой вопрос: как при развертывании Django через Docker создавать админа? Или уже все должно быть создано заранее?

LongLiveUbuntu ★★★★★
() автор топика
Ответ на: комментарий от LongLiveUbuntu

Почему-то не хочет коннектиться браузер после старта контейнера с сервисом.

localhost:8000

Попробуй 0.0.0.0:8000

das_tier ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Такой вопрос: как при развертывании Django через Docker создавать админа? Или уже все должно быть создано заранее?

Смотри, у тебя прод живёт всё время: один раз создал, потом деплоишь только новый код после релиза.

Поэтому достаточно после создания dev/staging/prod окружений один раз войти в контейнер, и создать админа вручную командой ./manage.py createsuperuser.

emorozov
()

Единого рецепта нет, к сожалению. Я хотел создать единый рецепт, но мало времени и мотивации, к сожалению.

virtualenv не нужен. Он вообще не нужен (в смысле использовать его напрямую), слишком низкоуровневый и неудобный. Лучше сразу привыкать работать с более высокоуровневыми инструментами, типа poetry. В докере poetry можно вызывать для установки без создания virtualenv, есть такой флаг у poetry.

По докеру много хороших статей, этот dockerfile неоптимальный, т.к. все команды RUN можно было бы объединить в одну, например. Есть шаблон cookiecutter для Django (полуофициальный, так-то понятно, что их много, и у меня свой есть), там же есть и конфигурация docker.

Мне эта полуофициальная конфигурация кажется очень громоздкой и неоптимальной: https://github.com/cookiecutter/cookiecutter-django

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

У меня есть свой шаблон, который использую для своих мелких проектов, но пока не добавлял туда Docker, т.к. docker на мелких проектах не использую: https://github.com/emorozov/cookiecutter-django-small

emorozov
()
Ответ на: комментарий от emorozov

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

LongLiveUbuntu ★★★★★
() автор топика

Безотносительно докера, встроенный runserver кроме чем для разработки использовать не рекомендуется. Надо какой-нибудь wsgi-сервер вроде gunicorn или uwsgi.

PolarFox ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

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

И заморачиваться автоматическим созданием пользователя при первом деплое - лишнее занятие. Хотя теоретически можно сделать, но это лишняя работа, и небезопасно (во всех инстансах будет один пароль).

emorozov
()
Ответ на: комментарий от LongLiveUbuntu

Я бы не советовал apache wsgi использовать. Вместо этого лучше nginx + gunicorn или nginx + uwsgi.

Сравнивать технически мне их сложно, но Apache WSGI это седое легаси. Очень сложно будет найти информацию как настраивать, масштабировать, отлаживать.

Я сейчас работаю с одним проектом, который на Apache сделан, и это, блин, просто финиш. Ощущение, что на 20 лет в прошлое провалился, всё какое-то невнятное, неудобное.

Короче, даже если с технической точки зрения это ещё норм, выглядит ужасно устаревшим и неудобным, как лапти против кроссовок.

emorozov
()

Про миграции забыл. VEnv, по-моему, не нужен, контейнер - сам по себе VEnv.

heilkitty ★★
()
Последнее исправление: heilkitty (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.