Как развернуть django сайт на хостинг(или VPS) от reg.ru. Полная инструкция

Введение или про что будет эта статья

VPS(Virtual Private Server) - такой сервер размещён вместе с другими на одном железе(компьютере), от сюда и virtual server, так же доступ к такому серверу есть только у его владельца, от сюда и private.

Особенности данной статьи

1. работа и настройка с БД
2. получение статики
3. загрузка на сайт различных медиа
4. переводы
5. тесты

Я постоянно работаю над этим приложением, ибо собираюсь тестировать его и на других хостингах (не только reg.ru). В конце концов, я вижу его как один, большой интерактивный тест хостингов, на то насколько они дружелюбны к Django-сайтам. Его исходный код и репозиторий можно найти тут -> ГитХаб.

1. search-result-parser.site - для деплоя сайта на хостинге
2. bddt2.space - для деплоя сайта на VPS

Плюс, и это важно, на момент прочтения тобой этой статьи сайт по домену bddt2.site уже не будет доступен (. Ну знаешь, деньги на ветер не бросаю.

Предварительная подготовка, приобретаем домен

1. Нажимаешь
2. Выбираешь домен
3. Вводишь желаемый
4. Подбираешь

Разворачиваем сайт на хостинге

Настройка хостинга

Если ты, мой друг, захочешь какую-нибудь версию python отличную от предложенных на хостинге, то спешу тебя разочаровать у тебя не получится. По крайней мере версии старше 3.10 точно нет. Дело в том, что тебе потребуются рут права для установки соответствующей версии OpenSSL - у тебя под докером не будет таких прав. Так что если твоё приложение использует новейшие фичи Python 3.11 и старше, тебе придётся устанавливать сайт на VPS, или искать нового хостинг провайдера.

И ещё замечание по поводу интерфейса. Очерёдность версий интерпретатора питона идёт от самой ранней, до самой поздней, казалось бы. Но почему-то 3.10 версия находится чуть ли не в середине. Я так-то её и не сразу заметил. А нужна именно она.

Создаём базу данных

Данный способ подойдёт только если разворачивать сайт на приобретённом хостинге. А реализовать удалённый доступ можно только для MySQL 5.7. А БД с такой версией создать не получится через ISPManager.

1. Где u3044930_bddt2_bd - это имя базы данных
2. Где u3044930_bddt2_user - это имя пользователя, который будет работать в базе данных
3. Это просто пароль, запомни или запиши.
4. Можно поставить, а можно не ставить - не имеет значения. Удалённый доступ к таким базам данным всё равно не разрешён

Деплой

cd /www/search-result-parser.site/ /opt/python/python-3.10.1/bin/python3.10 -m venv .venv source .venv/bin/activate pip install -r req.txt

Хочу отметить что, если тебе нужно использовать python3.10, то придётся прописывать полный путь до интерпретатора, ибо его нет в переменной окружения $PATH. Учти.

Apache2 - это свободный веб-сервер с открытым исходным кодом, используемый для обслуживания веб-страниц и другого контента в интернете

Подключение к базе данных

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'database_name', 'USER': 'user_name', 'PASSWORD': 'database_password', 'HOST': 'localhost', } }

1. NAME - Имя базы данных, в моём случае это u3044930_bddt2_bd
2. USER - Имя пользователя базы данных, в моём случае это u3044930_bddt2_user
3. PASSWORD - Пароль от базы данных

python manage.py migrate

Django ORM (Object-Relational Mapper) - это компонент фреймворка Django, который позволяет взаимодействовать с базами данных, используя объекты Python, а не писать SQL-запросы напрямую. Он предоставляет абстракции для работы с реляционными базами данных, делая код более читаемым, переносимым и удобным в обслуживании

Настройка директорий для статических и медиа файлов

cd /www/search-result-parser.site/ mkdir static mkdir media

Мягкая ссылка, также известная как символическая ссылка или симлинк (symlink), - это специальный вид ссылки в файловой системе, который указывает на другой файл или каталог, но не содержит данных файла-оригинала.

cd /www/search-result-parser.site/Website ln -s ../static static ln -s ../media media

python manage.py collectstatic

Подключение к WSGI-серверу

# -*- coding: utf-8 -*- import os, sys sys.path.insert(0, '/var/www/u3044930/data/www/search-result-parser.site/Website') sys.path.insert(1, '/var/www/u3044930/data/www/search-result-parser.site/.venv/lib/python3.10/site-packages') os.environ['DJANGO_SETTINGS_MODULE'] = 'Website.settings' from django.core.wsgi import get_wsgi_application application = get_wsgi_application()

1. Где вместо sys.path.insert(0, ..., ты должен будешь указать путь до корневой папки своего django-сайта.
2. Где вместо sys.path.insert(1, ..., ты должен будешь указать свой путь до пакетов в виртуальном окружении, созданным ранее.

Как перезапустить сервер?

Как перезапустить сервер? Теперь перезапусти сервер создав в корневой директории сайта, /www/bddt2.space/ файл .restart-app. Сервера работают таким образом, что каждую минуту проверяют хостинги на наличие вот такого файла и если он есть, перезапускают. Подожди окончания минуты :)

Разворачиваем сайт на VPS

Создаём VPS на Reg.ru

1. Тут мы выберем Ubuntu LTS 24.04 (самая последня версия на данный момент).
2. Тип и мощность процессора
3. Тариф, много нам не надо. Но чем требовательней сайт, тем больше тебе потребуется

Редактируем DNS записи и добавляем поддомен

DNS (Domain Name System) - Это телефонная книга интернета, преобразующая понятные человеку доменные имена (например, google.com) в числовые IP-адреса, используемые компьютерами для определения местоположения друг друга. Она позволяет пользователям получать доступ к веб-сайтам и другим онлайн-ресурсам, используя легко запоминающиеся имена вместо сложных IP-адресов.

Учти, чтобы DNS сервера поменялись потребуется время. Сколько? Бывает по-разному, у меня это заняло 15 минут. Только учти что у браузеров есть свой встроенный DNS кеш. Посмотреть его ты можешь вбив вот это(для firefox) : about:networking#dns.

Создаём базу данных

1. Либо создавать базу данных на том же VPS сервере
2. Либо воспользоваться облаком и создать там
3. Либо использовать базы данных других хостингов.

1. Выбираем тип базы данных (в моём случае я буду работать с MySQL)
2. Выбираем тариф

MySQL - это система управления реляционными базами данных (СУБД), используемая для хранения, организации и извлечения данных.

1. Нужна ли нам отказоустойчивая база данных. Если одна падёт, на её место станет другая, её точная копия
2. Имя базы данных, надо запомнить - в моём случае это bddt2_bd
3. Имя пользователя, через которого мы будем подключаться к базе данных - bddt2_user
4. Пароль

Вообще, когда я написал "потребуется время" тебе прям придётся подождать сутки-двое. Я так долго ждал, что уж начал думать использовать какое-нибудь другое решение. Например, с использованием баз данных бегета. Слёзно прошу владельцев Reg.ru, предупреждайте ваших пользователей(клиентов) сколько процесс создания кластера займёт времени.

1. Открыв создавшийся кластер зайди во вкладку "Базы данных"
2. bddt2_bd - имя базы данных к которой подключаешься
3. bddt2_user - имя пользователя через которого подключаешься
4. 79.174.89.21 - адрес хоста на котором сидит MySQL сервер
5. 18320 - порт на котором данная база данных принимает запросы

Подключаемся к созданному VPS, через SSH

SSH (Secure SHell) - это интернет-протокол по которому осуществляется безопасное, зашифрованное общение между клиентом и сервером. Есть SSH-клиент (он необходим для тех машин, с которых будет осуществлено подключение), а есть SSH-сервер (он необходим, если вы хотите предоставить удалённый доступ к своей машине). Все сервера имеют SSH-сервер установленным по умолчанию.

1. Адрес виртуального сервера
2. Имя пользователя для входа на сервер
3. Пароль авторизации на сервер

ssh root@83.166.244.155

На Linux машинах SSH-клиент установлен по умолчанию, но на Windows нет. Чтобы активировать SSH-клиент, потребуется просто активировать такую "Фичу". Вот замечательная статья об этом.

А через что, собственно подключаться? Можно через PowerShell, можно через Git Bash если привык к Линукс, можно и через специально созданные программы для подключения к серверам через SSH, а можно установить специальное расширение для VSCode и получить не только терминал на удалённом сервере, но и файловый менеджер и среду разработки - расширение такое называется если что Remote - SSH.

Подключение к серверу по ключу (опционально)

ssh-keygen -t rsa -f .ssh/bddt2

1. Где флаг -t отвечает за тип сгенерированного ключа
2. Где флаг -f отвечает за путь к файлу (который может не существовать), куда будет сохранён ключ

ssh-copy-id .ssh/bddt2.pub USERNAME@SERVER

1. Где .ssh/bddt2.pub - путь к публичной части ключа
2. Где USERNAME - это имя пользователя, через которое ты хочешь попасть на сервер, обычно это root, если никаких других пользователей ещё не создавалось.
3. Где SERVER- это адрес удалённого сервера. Это может быть как IPv4, так и доменное имя.

ssh USERNAME@SERVER_ADDR -i .ssh/bddt2

Устанавливаем необходимые пакеты

apt-get update && apt-get upgrade && apt-get install gettext libgettextpo-dev && apt-get install pkg-config default-libmysqlclient-dev build-essential && apt-get install nginx && apt-get install gunicorn && apt-get install python3.12-venv python3-dev

1. apt-get update - всегда выполняй её первой, при установке любого пакета. Она синхронизирует индекс пакетов приложений и обновляет все зависимости, при необходимости.
2. apt-get upgrade - устанавливает самые последние версии установленных пакетов на системе.
3. apt-get install gettext libgettextpo-dev - она устанавливает зависимости необходимые для генерации переводов для твоих сайтов (которые используют утилиту gettext)
4. apt-get install pkg-config default-libmysqlclient-dev build-essential - необходимые зависимости для работы с базами данных на MySQL.
5. apt-get install nginx - для запуска веб-сервера
6. apt-get install gunicorn - для переадресации запросов от nginx-сервера к нашему django-приложению
7. apt-get install python3-dev python3.12-venv - для возможности создания виртуального окружения при работе python-приложений

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

nginx - это легко конфигурируемый веб-сервер и прокси для запросов направляемые на сервер.

gunicorn - это сервер для python-приложений который связывает веб-сервера (такие, как nginx и apache) и python приложение

wget https://github.com/mozilla/geckodriver/releases/download/v0.36.0/geckodriver-v0.36.0-linux64.tar.gz tar -xzvf geckodriver-v0.36.0-linux64.tar.gz sudo mv geckodriver /usr/local/bin/

Создаём пользователя

useradd -m -s /bin/bash site passwd site usermod -aG sudo site

sudo - это команда(программа) выполняемая в терминале на Unix-like операционных системах (Linux, MacOS), которая позволяет запускать другие программы с разрешениями выполнять административные и потенциально опасные команды.

Перенос проекта

Все дальнейшие команды я выполнял от лица новосозданного пользователя "site". Если, что-то изменится, я дам знать.

mkdir ~/bddt2.space cd ~/bddt2.space git clone https://github.com/DmRafaule/DjangoDeploymentTest source python -m venv venv

1. bddt2.space <- Ты тут
2. venv
3. source

source ./venv/bin/activate pip install -r source/requirements.txt

cd ./source/Website python manage.py runserver

Настройка базы данных mysql (опционально, хотя не очень)

{ "SECRET_KEY": "django-insecure-4#-wrp_(53^0_9$%p8lq+qf43z0dx0ji6bh!sa1mfn^l)4-lq@", "DEBUG": true, "ALLOWED_HOSTS": ["bddt2.space"], "DATABASES": { "default": { "ENGINE": "django.db.backends.mysql", "NAME": "bddt2_bd", "USER": "bddt2_user", "PASSWORD": "aD9bN5oV3pjD7qJ9", "HOST": "79.174.89.21", "PORT": 18320 } }, "EMAIL": { "DEFAULT_FROM_EMAIL": "bddt@bddt.space", "DEFAULT_TO_EMAIL": "chedrden@gmail.com", "EMAIL_HOST": "", "EMAIL_PORT": , "EMAIL_HOST_USER": "", "EMAIL_HOST_PASSWORD": "" } , "STAGING_SERVER": "http://staging.bddt2.space" }

1. Во-первых нужно знать какой бекенд подключать - django.db.backends.mysql
2. Во-вторых имя базы данных- bddt2_bd
3. Во-вторых имя пользователя - bddt2_user
4. В-третьих, пароль от базы данных - aD9bN5oV3pjD7qJ9
5. В-четвёртых, имя хоста базы данных - 79.174.89.21
6. И в пятых, порт подключения - он всегда один и тот же - 18320

from django.utils.translation import gettext_lazy as _ from pathlib import Path import os import json import sys # Build paths inside the project like this: BASE_DIR / 'subdir'. BASE_DIR = Path(__file__).resolve().parent.parent # Read the settings file with open(os.path.join(BASE_DIR,"settings.json"), 'r') as settings_file: settings = json.load(settings_file) # SECURITY WARNING: keep the secret key used in production secret! SECRET_KEY = settings["SECRET_KEY"] # SECURITY WARNING: don't run with debug turned on in production! DEBUG = settings["DEBUG"] ALLOWED_HOSTS = settings["ALLOWED_HOSTS"] STAGING_SERVER = settings["STAGING_SERVER"] # More code bellow # ...

Заканчиваем перенос проекта

Почему, а главное зачем именно Nginx и Gunicorn? Смотри, nginx делает наш VPS сервер, как бы доступным для других машин. Он настраивает 80-й порт и домен(при необходимости), чтобы другие машины знали где он, и куда направлять свои запросы. Но одного nginx мало, нам нужно как-то передать запросы от других машин на наше Django-приложение. Для этого и используется Gunicorn, он тоже прослушивает соответствующий, 80-й порт (хотя можно и нужно это делать через UNIX-сокеты, я покажу), а после того как получил запрос направляет его в Django-приложение, где уже и происходи вся остальная логика сайта.

Настраиваем Nginx

Супер быстрая настройка Nginx (очень опционально)

./server-setup.sh YOUR_DESIRED_DOMAIN on_https

1. Где YOUR_DESIRED_DOMAIN - это желаемый домен
2. Где on_https - это флаг, который говорит настроить редирект на HTTPS протокол

Продолжаем настраивать Nginx

server { listen 80; server_name HOST_PLACE_SETUP; location /static { root /home/USER_PLACE_SETUP/HOST_PLACE_SETUP; } location /media { root /home/USER_PLACE_SETUP/HOST_PLACE_SETUP; } location / { proxy_set_header Host HOST_PLACE_SETUP; proxy_pass http://unix:/tmp/HOST_PLACE_SETUP.socket; } }

1. В этой конфигурации мы настраиваем порт на котором мы будем слушать входящие запросы.
2. Имя для нашего сервера (доменное имя). В моём случае это должно быть bddt2.space.
3. Папки, которые этот сервер будет обслуживать. Как минимум нужно настроить корневой каталог "/". Но этим всё не ограничивается, на моём сайте используется различная статика в виде картинок и иконок. Плюс медиа файлы, которые загружаются непосредственно пользователем.

Что за непонятные переменные USER_PLACE_SETUP и HOST_PLACE_SETUP? Всё дело в том, как работает мой кастомный скрипт по настройке сервера. Если в кратце, то он, используя sed команду заменяет две вышеуказанные переменные и заменяет их на необходимые администратору значения. Всё это делается через специальный скрипт server-setup.sh, о котором через главу.

server { listen 80; server_name bddt2.space; location /static { root /home/site/bddt2.space; } location /media { root /home/site/bddt2.space; } location / { proxy_set_header Host bddt2.space; proxy_pass http://unix:/tmp/bddt2.space.socket; } }

cd ~/bddt2.space mkdir static mkdir media cd source/Website

Мягкая ссылка, также известная как символическая ссылка или симлинк (symlink), - это специальный вид ссылки в файловой системе, который указывает на другой файл или каталог, но не содержит данных файла-оригинала.

ln -s ../../static static ln -s ../../media media

1. bddt2.space
2. venv
3. media
4. static
5. source
6. Website
7. Backend
8. Frontend
9. Website
10. media -> ../../media
11. static -> ../../static
12. manage.py
13. settings.json
14. deploy.sh
15. server-setup.sh
16. requirements.txt
17. gunicorn.service
18. nginx-server-http_only.conf
19. nginx-server-on_httsp-301.conf
20. nginx-server-on_https.conf

При работе с медиа файлами, сервер может дать 413 ответ - 413 Request Entity Too large. Связано это с тем, что максимальный размер тела в запросе по умолчанию может быть не больше 1 Мегабайта. Что бы изменить это, в файле /etc/nginx/nginx.conf, в раздел http добавь: ```client_max_body_size 50M;```

Решаем проблему с 403 ошибкой - запрещено (опционально, надеюсь)

1. Заменить пользователя в файле /etc/nginx/nginx.conf
2. Дать доступ всем к чтению файлов
3. Добавить пользователя www-data в группу пользователя, который запускает приложение.

sudo usermod -aG site www-data

1. site - имя группы к которому хотите добавить пользователя (оно будет совпадать с именем пользователя)
2. www-data - имя пользователя, которого хотите присоединить к группе.

Заканчиваем настройку Nginx

sudo cp ~/bddt2.space/source/nginx-server.conf /etc/nginx/sites-available/staging-nginx-server.conf

sudo cd /etc/nginx/sites-enabled sudo ln -s ../sites-available/staging-nginx-server.conf staging-nginx-server.conf

sudo systemctl restart nginx

... proxy_pass http://unix:/tmp/bddt2.space.socket; ...

Настраиваем Gunicorn

[Unit] Description=Gunicorn server for HOST_PLACE_SETUP [Service] Restart=on-failure User=USER_PLACE_SETUP WorkingDirectory=/home/USER_PLACE_SETUP/HOST_PLACE_SETUP/source/Website ExecStart= /home/USER_PLACE_SETUP/HOST_PLACE_SETUP/venv/bin/gunicorn --bind unix:/tmp/HOST_PLACE_SETUP.socket Website.wsgi:application [Install] WantedBy=multi-user.target

Данный скрипт имеет подстановочные переменные HOST_PLACE_SETUP И USER_PLACE_SETUP. Я заменяю их на необходимые мне значения через специальный скрипт server-setup.sh. О нём подробнее в следующей главе.

sudo cp ~/bddt2.space/source/gunicorn.service /etc/systemd/system/gunicorn.service sudo vim /etc/systemd/system/gunicorn.service sudo systemctl start gunicorn sudo systemctl enable gunicorn

Переходим на HTTPS (опционально, хотя не очень)

source ~/bddt2.space/venv/bin/activate pip install certbot certbot-nginx

sudo ~/bddt2.space/venv/bin/certbot certonly --nginx -d bddt2.space

1. Просит ввести почту
2. Согласись на продажу своей души и души своего сайта)
3. Регистрация, по желанию
4. Выбор доменов(поддоменов) для который будет действовать данный сертификат. Если просто нажать ENTER, сертификат будет применён ко всем.
5. Путь до сертификата (для настройки nginx)
6. Путь до ключа (для настройки nginx)

echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

server { listen 443 ssl; server_name HOST_PLACE_SETUP; ssl_certificate /etc/letsencrypt/live/bddt2.space/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/bddt2.space/privkey.pem; location /static { root /home/USER_PLACE_SETUP/HOST_PLACE_SETUP; } location /media { root /home/USER_PLACE_SETUP/HOST_PLACE_SETUP; } location / { proxy_set_header Host HOST_PLACE_SETUP; proxy_pass http://unix:/tmp/HOST_PLACE_SETUP.socket; } }

server { listen 80; server_name HOST_PLACE_SETUP; location / { return 301 https://HOST_PLACE_SETUP$request_uri; } }

301 код сервера - Его ещё называют перманентный редирект, ответ сервера при котором происходит перенаправление с одного URL на другой.

Есть ещё и 302 код сервера и это тоже редирект. Так в чём их отличие? Отличие в значении которое передаёт 302 код. Если 301, то он как бы говорит: УРЛ на который ты попал, всегда будет доступен только по новому адресу. А 302, в свою очередь говорит: УРЛ на который ты попал сейчас доступен по этому адресу, но возможно так будет не всегда.

Сравнение запуска сайта через Хостинг и через VPS

Заключение