Архитектура и обзор стека

Компоненты системы

Архитектуры и обзор стека

Компоненты системы и их роль (Django, Channels, Daphne, Redis, Nginx)

Django — ядро веб-приложения, фреймворк, обрабатывающий базовую бизнес-логику, HTTP-запросы, работу с базой данных (ORM) и шаблонами. Django Channels — расширение Django, которое позволяет приложению обрабатывать не только HTTP, но и асинхронные протоколы, такие как WebSockets, через систему channel layers (слоёв каналов). Он отделяет входящие соединения (consumers) от фоновых задач и обеспечивает их связь. Redis — высокопроизводительное хранилище «ключ-значение» в памяти. В стеке с Channels он выполняет роль channel layer backend — центрального сообщающегося компонента, который:

Распределяет сообщения между всеми запущенными экземплярами приложения (рабочими процессами).
Обеспечивает синхронизацию состояния между различными consumers WebSocket-соединений.
Позволяет масштабировать приложение горизонтально, добавляя больше рабочих процессов.

Daphne — ASGI-сервер (Asynchronous Server Gateway Interface), созданный специально для поддержки Channels. Его роль:

Принимать входящие HTTP и WebSocket-соединения.
Запускать и поддерживать жизненный цикл асинхронного приложения Django (ASGI).
Маршрутизировать трафик между HTTP-запросами к Django и WebSocket-соединениями к Consumers.

Nginx — фронтальный веб-сервер и обратный прокси. Его ключевые задачи в данной архитектуре:

Принимать входящие запросы от клиентов на стандартных портах (80/443).
Обрабатывать SSL/TLS-терминацию (HTTPS), разгружая от этой задачи Daphne.
Проксировать запросы к бэкенду (Daphne) на внутренний порт (например, 8000).
Эффективно раздавать статические файлы (CSS, JS, изображения) без участия Django-приложения.
Выполнять балансировку нагрузки, кэширование и базовую защиту.

Общая схема потока запроса для WebSocket: Клиент устанавливает защищённое (wss://) соединение с Nginx. Nginx «апгрейдит» его до WebSocket и проксирует на Daphne. Daphne принимает соединение и передаёт его в соответствующий Consumer приложения через Channels. Consumer может общаться с другими частями системы через общий channel layer в Redis

1.2

Схема взаимодействия

Схема взаимодействия (клиент ↔ Nginx (SSL) ↔ Daphne (ASGI) ↔ Redis (Channel Layer) ↔ Django)

Следующая схема иллюстрирует последовательность взаимодействия компонентов для обработки WebSocket-соединения и HTTP-запроса.

 
        [КЛИЕНТ]
              │ (wss://domain.com/ws)
              ▼
          [NGINX]
       (SSL, прокси)
              │
        ┌─────┴─────┐
        │           │
    (HTTP)    (WebSocket)
        │           │
        ▼           ▼
[Django Views]   [DAPHNE]
        │           │ (Маршрутизация в ASGI)
        │           ▼
        │   [Channels Consumers]
        │           │
        ▼           │ (Отправка/публикация)
[База данных]      │
        │           ▼
        │       [REDIS]
        │    (Channel Layer)
        │           │
        │           │ (Синхронизация)
        ▼           ▼
    [Ответ] ← [Другие процессы/серверы]

Детализация потока:

Клиент → Nginx: Браузер устанавливает безопасное соединение (WSS/HTTPS). Nginx выступает как публичная конечная точка и терминатор SSL.
Nginx → Daphne: Обнаружив заголовок Upgrade: websocket, Nginx проксирует соединение на внутренний порт Daphne, например: 127.0.0.1:8000. Обычные HTTP-запросы проксируются аналогично.
Daphne → Маршрутизация: Daphne, как ASGI-сервер, определяет тип соединения по конфигурации routing.py и направляет его:
- HTTP → в ядро Django (Views, ORM).
- WebSocket → в соответствующий Consumer (асинхронный обработчик).
Обработка в приложении:
- HTTP-путь: Запрос проходит middleware-стэк, обрабатывается View и возвращает ответ, часто с взаимодействием с базой данных.
- WebSocket-путь: Consumer устанавливает постоянное соединение, читает и отправляет сообщения.
Координация через Redis: Для широковещательной рассылки сообщений (например, в чате) Consumer публикует сообщение в Channel Layer Redis. Все Consumer'ы, подписанные на этот канал (включая те, что работают в других процессах Daphne), мгновенно получают это сообщение. Redis выступает единым центром синхронизации.

Эта схема обеспечивает масштабируемость: за одним Nginx может работать несколько процессов Daphne, которые координируются через единый Redis.

1.3

Требования к серверу

Требования к серверу (память, порты, зависимости)

1. Аппаратные требования: – Память (RAM): Минимум: 1 ГБ. Рекомендуется: 2 ГБ и более. Обоснование: Redis хранит данные channel layer в оперативной памяти. – Процессор: 1-2 ядра x86-64. – Дисковое пространство: 5-10 ГБ для ОС, кода и логов. 2. Требования к портам и сетевой доступности – Входящие порты (открыть в firewall): 80/tcp (HTTP) и 443/tcp (HTTPS) — для трафика приложения. 22/tcp (SSH) — для управления. – Внутренние порты (только localhost): 8000/tcp — порт Daphne для проксирования от Nginx. 6379/tcp — порт Redis (обязательно ограничить доступ в конфиге). 3. Системные зависимости и ПО Операционная система: Ubuntu Server 20.04/22.04 LTS. Ключевые серверные компоненты устанавливаются одним набором команд:


# 1. Обновление системы и установка базовых инструментов
sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential curl git ufw python3-pip python3-dev python3-venv libssl-dev

# 2. Установка обязательных сервисов
sudo apt install -y redis-server nginx

# 3. (Опционально) Установка PostgreSQL вместо SQLite 
sudo apt install -y postgresql postgresql-contrib libpq-dev

Базовые зависимости

Подготовка сервера и базовые зависимости

Данный раздел описывает первоначальную настройку сервера Ubuntu 20.04/22.04 LTS, установку системных пакетов и настройку основных сервисов (Redis, Nginx, PostgreSQL), которые требуются для работы стека Django Channels перед развёртыванием самого приложения. Содержание раздела:

Установка Python 3.7+, virtualenv, pip
Установка и безопасная конфигурация Redis для работы в качестве channel layer.
Установка и запуск веб-сервера Nginx в качестве обратного прокси и терминатора SSL.
Опциональная установка и настройка PostgreSQL.
Подготовка директории проекта и создание виртуального окружения Python.

2.1

Python, virtualenv, pip

Установка Python 3.7+, virtualenv, pip

Ubuntu 20.04 включает Python 3.8, что достаточно. Для проекта используются специфические версии библиотек из requirements.txt. Ключевой нюанс — channels 3.0.4 требует Python ≥3.6 и Django ≥3.2.

# Проверка текущей версии Python
python3 --version

# Установка pip и venv (если отсутствуют)
sudo apt update
sudo apt install -y python3-pip python3-venv

# Создание виртуального окружения в директории проекта
python3 -m venv /var/www/chat-2.0/venv37

# Активация окружения
source /var/www/chat-2.0/venv37/bin/activate

2.2

Redis

Установка и базовая настройка Redis

Роль Redis в проекте

Выступает в качестве Channel Layer Backend для Django Channels.
Обеспечивает синхронизацию сообщений между всеми экземплярами Consumers (WebSocket-обработчиков).
Хранит состояние подключений в оперативной памяти для минимальной задержки.

Установка Redis

# Установка последней стабильной версии из репозитория Ubuntu
sudo apt update
sudo apt install -y redis-server

# Проверка версии (проект использует Redis 5+)
redis-server --version

Критическая настройка безопасности

# Редактирование конфигурационного файла
sudo nano /etc/redis/redis.conf

Найдите и установите следующие параметры:

bind 127.0.0.1 ::1  # доступ только с локального интерфейса 
protected-mode yes # включение защищённого режима
requirepass  #  опционально, установите пароль если Redis используется другими приложениями

Применение настроек

# Перезагрузка Redis с новыми настройками
sudo systemctl restart redis-server

# Проверка статуса службы
sudo systemctl status redis-server

# Проверка подключения из командной строки
redis-cli ping

# Ожидаемый ответ: PONG

Проверка работы с Python-окружением проекта

# Активируйте виртуальное окружение проекта
source /var/www/chat-2.0/venv37/bin/activate

# Тестирование подключения через Python
python3 -c "
import redis
r = redis.Redis(host='localhost', port=6379, db=0)
print('Redis connection test:', r.ping())
"

Автозапуск при загрузке системы

# Включение автоматического запуска
sudo systemctl enable redis-server

# Просмотр логов Redis в реальном времени
sudo journalctl -u redis-server -f

Особенности для проекта Django Channels

Проект использует channels-redis==3.3.0 и aioredis==1.3.1 — эти версии полностью совместимы с Redis 5 и 6.
При ошибках подключения проверьте настройку bind и убедитесь, что в CHANNEL_LAYERS указан правильный хост ('localhost', 6379).
Для мониторинга используйте команду: redis-cli info stats | grep connected_clients — показывает количество активных подключений к Redis.

Следующий шаг — установка и базовая настройка PostgreSQL (если используется вместо SQLite) или переход к настройке Nginx.

2.3

PostgreSQL/MySQL

Установка и базовая настройка PostgreSQL/MySQL (опционально, если не SQLite)

Развертывание Django-проекта

3.1

Структура каталогов

Структура каталогов проекта (рекомендуемая: /var/www//)

3.2

Виртуальное окружение

Настройка виртуального окружения и установка зависимостей (channels, daphne, channels_redis и др.)

3.3

Settings.py

Settings.py: ALLOWED_HOSTS, DATABASES, STATIC/MEDIA, CHANNEL_LAYERS

3.4

Миграции, статика, superuser

Применение миграций, сбор статики, создание суперпользователя

Глоссарий

Краткий глоссарий

Сетевые протоколы и методы передачи данных

Протокол связи

Набор правил и соглашений для обмена данными между устройствами в сети.

HTTP (HyperText Transfer Protocol)

Протокол передачи данных в формате «запрос-ответ» между клиентом и сервером. Основа веб-коммуникаций, но не поддерживает постоянные соединения.

Multiplexing

Техника передачи нескольких независимых потоков данных через одно физическое соединение. Позволяет одновременную обработку множества запросов.

HTTP/2

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

Полнодуплексная связь (Full Duplex)

Режим связи с одновременной двусторонней передачей данных. Обе стороны могут отправлять и получать информацию в один момент времени без переключения режимов.

WebSocket

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

SSL/TLS (Secure Sockets Layer/Transport Layer Security)

Протоколы криптографической защиты данных при передаче по сети. Обеспечивают конфиденциальность, целостность и аутентификацию соединения.

Система

Демон (daemon)

Фоновая программа в Unix-системах, работающая без прямого взаимодействия с пользователем. Выполняет системные задачи и обслуживает запросы.

Systemd

Системный менеджер и демон инициализации в современных Linux-дистрибутивах. Управляет запуском системных служб, ресурсами и зависимостями.

Сервис (systemd service)

Программа, работающая в фоновом режиме под управлением systemd. Имеет конфигурационный файл (.service), описывающий условия запуска, окружение и правила перезапуска.

systemctl

Командная утилита для управления системными сервисами в Linux. Обеспечивает запуск, остановку, мониторинг и настройку автозагрузки служб.

Симлинк (symbolic link)

Ссылка на файл или директорию в файловой системе Linux. Позволяет обращаться к одному объекту через несколько различных путей.

Виртуальное окружение Python

Изолированная среда для установки пакетов Python. Содержит собственную копию интерпретатора и менеджера пакетов, предотвращает конфликты версий.

Сетевые технологии

Проксирование

Процесс перенаправления сетевых запросов через промежуточный сервер. Клиент взаимодействует с прокси, который передает запросы целевому серверу.

Обратный прокси (reverse proxy)

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

TLS-терминация

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

Nginx

Высокопроизводительный веб-сервер и обратный прокси. Используется для раздачи статических файлов, балансировки нагрузки и терминации SSL-соединений.

Технологии Python

Событийно-ориентированная архитектура

Парадигма программирования, где поток выполнения определяется событиями. Позволяет эффективно обрабатывать множество одновременных соединений без блокировок.

Twisted

Событийно-ориентированный сетевой фреймворк на Python. Обеспечивает асинхронную обработку множественных сетевых соединений.

ASGI (Asynchronous Server Gateway Interface)

Спецификация интерфейса между Python-веб-приложениями и серверами для асинхронной обработки запросов. Поддерживает HTTP, WebSocket и другие протоколы.

ASGI-сервер

Сервер приложений, реализующий ASGI-спецификацию. Может одновременно обрабатывать HTTP-запросы и постоянные соединения (WebSocket).

Daphne

Сервер приложений, реализующий ASGI-спецификацию. Способен обслуживать одновременно HTTP и WebSocket, что делает его идеальным для Django Channels.

Gunicorn (Green Unicorn)

WSGI-сервер для запуска традиционных синхронных Django-приложений. Часто используется в паре с Daphne для разделения нагрузки.

Вспомогательные сервисы

Let's Encrypt

Автоматизированный центр сертификации, предоставляющий бесплатные SSL-сертификаты для защиты веб-сайтов. Использует протокол ACME для автоматического выпуска и обновления сертификатов.

Daphne

Daphne — ASGI-сервер для развертывания Django Channels на рабочем сервере.

Особенности:

— Одновременная обработка: Daphne поддерживает параллельное выполнение HTTP и WebSocket-запросов. — Асинхронная архитектура: Обеспечивает обработку тысяч одновременных соединений в реальном времени. — Протоколы связи: Корректно реализует спецификации WebSocket и HTTP/2. — Интеграция с Nginx: Работает через обратное проксирование для балансировки нагрузки. — Безопасность: Обеспечивает защищенную обработку TLS-соединений. — Надежность: Интегрируется с systemd для автоматического восстановления при сбоях. — Горизонтальное масштабирование: Поддерживает возможность запуска нескольких независимых экземпляров сервера для распределения нагрузки.

5.1

Установка Daphne

Установка Daphne в виртуальное окружение (для Ubuntu)

Daphne рекомендуется устанавливать в виртуальное окружение, для избежания конфликтов, управляемости и т.д. Исключение: Глобальная установка возможна в Docker-контейнерах или выделенных серверах для одного приложения. Мы будем рассматривать установку в виртуальное окружение (для Linux)

# Создание и активация вашего виртуального окружения (myvenv) 
python -m venv myvenv && source myvenv/bin/activate

# Установка Daphne, channels,  twisted
pip install daphne channels twisted[tls,http2]

5.2

Daphne сервис

Cоздание systemd сервиса для Daphne в виртуальном окружении

1. Создание файла сервиса

sudo nano /etc/systemd/system/daphne.service

2. Конфигурация сервиса с виртуальным окружением

Добавляем содержимое (указано в общем виде) Надо прописать собственные пути + посмотреть какой питон работает в виртуальном окружении (может быть несколько папок)

[[Unit]
# Описание сервиса для отображения в системных логах и утилитах мониторинга:
# gри systemctl status daphne покажет "Daphne ASGI Server"
Description=Daphne ASGI Server

# Сервис запускается только после полной загрузки сетевых интерфейсов:
# гарантия, что сеть готова до запуска веб-сервера
After=network.target

# Явное указание зависимости от сетевой подсистемы:
# если сеть не поднята - сервис не будет запущен
Wants=network.target

[Service]
# Тип сервиса: simple - основной процесс не форкается:
# systemd отслеживает непосредственно процесс Daphne
Type=simple

# Пользователь и группа от имени которых запускается процесс (безопасность)
# Пример: www-data стандартный пользователь для веб-серверов в Ubuntu
User=www-data
Group=www-data

# Рабочая директория - корневая папка Django-проекта (где manage.py, settings.py)
# Пример: WorkingDirectory=/var/www/myproject
WorkingDirectory=/path/to/your/project

# Переменная окружения PATH указывает на bin виртуального окружения
# Пример: Environment=PATH=/var/www/myproject/venv/bin
Environment=PATH=/path/to/your/project/venv/bin

# Команда запуска: Daphne из виртуального окружения на localhost порт 8000
# Пример: ExecStart=/var/www/myproject/venv/bin/daphne -b 127.0.0.1 -p 8000 myapp.asgi:application
ExecStart=/path/to/your/project/venv/bin/daphne \
  -b 127.0.0.1 \        # bind только на локальный интерфейс (безопасность)
  -p 8000 \             # порт для приема соединений
  your_project.asgi:application  # ASGI-приложение Django

# Автоматический перезапуск при аварийном завершении процесса
# Пример: если Daphne упадет с ошибкой - автоматически перезапустится
Restart=on-failure

# Задержка 5 секунд перед перезапуском после сбоя
# Пример: избежание бесконечного цикла перезапусков при постоянных ошибках
RestartSec=5s

[Install]
# Сервис запускается при загрузке системы в многопользовательском режиме
# Пример: после systemctl enable daphne сервис будет стартовать при загрузке ОС
WantedBy=multi-user.target

# Пример daphne.service для проекта MYPROJECT (папка проекта) / myapp (приложение) / myuser (user)
[Unit]
Description=WebSocket Daphne Service
After=network.target

[Service]
Type=simple
User=myuser
WorkingDirectory=/home/myuser/MYPROJECT
# 127.0.0.1 -p 8000 только локально 
ExecStart=/home/myuser/MYPROJECT/venv/bin/daphne -b 127.0.0.1 -p 8000 myapp.asgi:application

[Install]
WantedBy=multi-user.target

3. После создания файла daphne.service, выполняем в терминале:


systemctl daemon-reload
systemctl start daphne.service
systemctl status daphne.service
systemctl enable daphne.service # добавляем сервис в автозагрузку

5.3

Daphne HTTP/2

Daphne : HTTP/2 Support

Daphne изначально поддерживает HTTP/2. Однако вам нужно будет сделать пару вещей, чтобы заставить его работать. Во-первых, нужно убедиться, что установили дополнения Twisted http2 и tls. Далее, поскольку все современные браузеры поддерживают HTTP/2 при использовании TLS, вам нужно будет запустить Daphne с включенным TLS:

Симлинки для сертификатов:

Добавим симлинки для ssl-сертификатов в папку проекта:


cd /var/www/myproject
ln -s /etc/letsencrypt/live/mysite.ru/privkey.pem key.pem
ln -s /etc/letsencrypt/live/mysite.ru/cert.pem crt.pem

Безопасность - сертификаты в /etc/letsencrypt/ защищены правами root Автообновление - Let's Encrypt автоматически обновляет сертификаты по исходным путям Упрощение конфигов - короткие относительные пути в настройках Daphne Доступность - сервис Daphne получает доступ к сертификатам из рабочей директори

Запуск с HTTPS:

daphne -e ssl:443:privateKey=key.pem:certKey=crt.pem django_project.asgi:application

Редактируем файл daphne.service для добавления поддержки HTTP/2:

sudo nano /etc/systemd/system/daphne.service

[Unit]
Description=WebSocket Daphne Service
After=network.target

[Service]
Type=simple
User=myuser
WorkingDirectory=/var/www/myproject
ExecStart=/var/www/myproject/venv/bin/daphne -e ssl:8443:privateKey=key.pem:certKey=crt.pem mysite.asgi:application

[Install]
WantedBy=multi-user.target

После обновления/создания файла daphne.service, выполняем в терминале:

systemctl daemon-reload
systemctl start daphne.service
systemctl status daphne.service
systemctl enable daphne.service # добавляем сервис в автозагрузку