Skip to content

docker-management.md

Latest commit

 

History

History
239 lines (163 loc) · 8.28 KB

docker-management.md

File metadata and controls

239 lines (163 loc) · 8.28 KB
Raw

Отлично, Akrom 🔥 — у тебя уже почти “продакшн-готовый” Docker setup для Django с Celery, Redis, PostgreSQL через pgbouncer, и даже Flower для мониторинга. Давай разберём логику всего твоего стека, что делает каждый файл, как это оптимизировать для продакшна и как правильно управлять контейнерами.

1️⃣ Логика действий всех контейнеров

web (Django)

  • Стартует через /start скрипт.

  • Скрипт выполняет:

    1. migrate (применяет миграции БД)
    2. collectstatic (собирает статические файлы)
    3. Запускает ASGI сервер через uvicorn (можно заменить на Gunicorn для продакшна)

  • Подключается к:

    • Redis (кеш, брокер Celery)
    • pgbouncer → PostgreSQL (оптимизация подключений к БД)

  • Оптимизация для продакшна:

    • Лучше использовать Gunicorn с uvicorn воркерами:

      gunicorn core.asgi:application -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:8000 --workers 4 --timeout 120

      Это позволит обрабатывать больше запросов одновременно.

db (PostgreSQL)

  • Хранит данные.

  • volume pg_data гарантирует, что данные сохраняются после перезапуска контейнера.

  • healthcheck ждёт готовности PostgreSQL перед запуском pgbouncer и web.

  • Оптимизация:

    • Настроить параметры pool_size, max_connections для PostgreSQL и pgbouncer.
    • Для продакшна использовать отдельный сервер БД (или управляемый сервис) для стабильности.

pgbouncer

  • Лёгкий connection pool для PostgreSQL.

  • Подключается к db, отдаёт соединения веб-сервисам.

  • Плюсы:

    • Уменьшает нагрузку на PostgreSQL при множественных соединениях.
    • Можно масштабировать воркеры Django без проблем.

  • Продакшн: можно включить TLS и логирование, ограничить max_client_conn.

redis

  • Кеширование и брокер для Celery.

  • Важен для производительности:

    • Django caching
    • Celery брокер

  • Продакшн: лучше использовать отдельный Redis сервер или managed Redis для стабильности.

celery_worker, celery_beat

  • Worker: обрабатывает задачи (отправка email, обработка аудио и т.д.)

  • Beat: планировщик периодических задач.

  • Скрипты стартуют после sleep 10 сек, чтобы RabbitMQ (если включён) и Redis были готовы.

  • Продакшн:

    • Увеличить количество worker процессов (-c 4 или больше, зависит от CPU)
    • Включить --max-tasks-per-child для предотвращения утечек памяти

celery-flower

  • Мониторинг Celery в реальном времени на порту 5555.
  • Можно отключать в проде, если не нужен постоянный доступ.

2️⃣ Логика скриптов

entrypoint

  • Ждёт готовности PostgreSQL (postgres_ready())
  • После чего выполняет команду, переданную в контейнере (exec "$@")

start

  • Django:

    1. migrate
    2. collectstatic
    3. Запуск ASGI через uvicorn (или Gunicorn)

  • Для продакшна лучше Gunicorn + Uvicorn worker.

Celery start scripts

  • Worker, Beat, Flower ждут RabbitMQ/Redis (sleep 10), чтобы не падали при старте.
  • После этого запускают свои процессы.

3️⃣ Оптимизация для production

  1. Gunicorn вместо Uvicorn в start:

    gunicorn core.asgi:application \
    -k uvicorn.workers.UvicornWorker \
    --bind 0.0.0.0:8000 \
    --workers 4 \
    --timeout 120 \
    --log-level info
    • Позволяет обрабатывать больше параллельных запросов.

  2. Разделение dev и prod Dockerfile

    • Для dev: --reload uvicorn
    • Для prod: Gunicorn + no reload + оптимизированные зависимости

  3. Volumes

    • Не включать статику и медиа для сборки, чтобы Docker кэшировал зависимости.
    • .dockerignore уже настроен — отлично.

  4. Environment

    • Отдельные .env для dev и prod
    • Не хранить секреты в Dockerfile

  5. Celery

    • Настроить concurrency:

      celery -A core worker -l info -c 4 --max-tasks-per-child=100

    • Beat scheduler: хранить PID в volume, чтобы перезапускался корректно

  6. Healthchecks

    • Для всех критических контейнеров (web, db, redis) — добавить healthcheck, чтобы Docker перезапускал падение

  7. Logging

    • Gunicorn + Nginx логи в stdout/stderr → Docker logging driver → удобно для мониторинга

  8. Reverse proxy (Nginx)

    • Если Nginx через Docker: depends_on: web, volume для статики
    • SSL через LetsEncrypt

4️⃣ Управление контейнерами

  • Запуск всех:

    docker compose up -d

  • Перезапуск всех:

    docker compose restart

  • Остановка:

    docker compose down

  • Смотр логов:

    docker compose logs -f web
docker compose logs -f celery_worker

  • Войти внутрь контейнера:

    docker exec -it django_app bash

  • Проверка состояния контейнеров:

    docker compose ps

5️⃣ Улучшенная структура Docker для понятности

Backend/
├─ deployments/compose/django/
│  ├─ Dockerfile       # отдельный для dev/prod
│  ├─ entrypoint       # ждёт БД
│  ├─ start            # запуск Gunicorn/uvicorn
│  └─ celery/          # worker/beat/flower scripts
├─ docker-compose.yml
├─ .env
├─ requirements.txt
├─ app/                 # Django project
├─ assets/
│  ├─ staticfiles/
│  └─ media/
└─ .dockerignore
  • Dev: uvicorn --reload
  • Prod: Gunicorn + Uvicorn worker
  • .dockerignore убирает лишние файлы для ускорения сборки
  • Healthchecks + volumes для сохранения данных
  • Логи в stdout/stderr → легко интегрировать с monitoring

💡 Главные рекомендации для продакшн:

  1. Gunicorn вместо uvicorn --reload
  2. Concurrency Celery и max-tasks-per-child
  3. Healthchecks всех сервисов
  4. Отдельный volume для БД, статики и медиа
  5. SSL + Nginx reverse proxy
  6. Логи через Docker (без локальных файлов)
  7. .env отдельно, секреты не в Dockerfile

Если хочешь, я могу прямо сейчас переписать твой Dockerfile, start/entrypoint и docker-compose.yml, чтобы он был оптимизирован под продакшн, с Gunicorn, Celery, Redis, PostgreSQL через pgbouncer, Nginx и SSL-ready, при этом код стал читаемым и компактным.

Хочешь, чтобы я сделал это?