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

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

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

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

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

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

TDD (Test Driven Development) - такой подход в разработке программ, при котором сначала пишутся тесты, а потом сам код программы. Если быть более конкретным, сначала функциональные тесты, потом модульные и только потом сам код.

Но только для VPS. Для обычного хостинга это мало применимо.

Зачем так усложнять ? Наверное, задаёшь ты себе вопрос. Я тоже задавал такой вопрос, и тут сложно как-то уговаривать или убеждать, что так ты сэкономишь себе нервы и время, так автоматизировать процесс разработки легче, так внедрять новое и улучшать старое гораздо легче и безболезненней. Тебе просто придётся это пройти. Создать свой проект, вырастить его до определённого масштаба и почувствовать всю его тяжесть и неповоротливость и то, что TDD могло бы тебе помочь.

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

Приобретаем домен и создаём поддомен

1. Это имя твоего домена
2. Ни куда не направляем
3. После нам потребуется отредактировать несколько DNS-записей для корректной работы домена
4. В качестве бонуса получим бесплатный SSL-сертификат, это потребуется для перехода от протокола http к https.

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

1. Имя твоей базы данных (У меня это будет timachuduk_bddt)
2. Пароль, запомни или запиши (Не скажу)
3. Добавляем
4. Необходим для подключений сайтов созданных для VPS

Создаём почтовый сервер

1. Вводишь желаемое имя (без @., и прочего)
2. Генерируешь пароль (сохрани)
3. Запомни полное название своего ящика, он пригодиться

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

Подготовка или связываем домен с сайтом

Подключение к хостингу через SSH

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

ssh USERNAME_PLACEHOLDER@USERNAME_PLACEHOLDER.beget.tech

ssh localhost -p222

mkdir ~/.beget/tmp cd ~/.beget/tmp

Устанавливаем OpenSSL

wget https://www.openssl.org/source/openssl-1.1.1l.tar.gz && tar -xzvf openssl-1.1.1l.tar.gz

wget -это утилита командной строки для загрузки файлов из интернета по протоколам HTTP, HTTPS и FTP. Она позволяет скачивать как отдельные файлы, так и целые сайты, поддерживает возобновление загрузки, работу через прокси и многое другое

tar - предназначена для создания, извлечения, модификации и просмотра архивов. Она часто используется для объединения нескольких файлов и/или каталогов в один архивный файл (называемый tarball), а также для работы с уже существующими архивами. tar также может использоваться с утилитами сжатия, такими как gzip, bzip2 или xz, для создания сжатых архивов

make - инструмент автоматизации сборки, который считывает Makefile (или GNUmakefile), чтобы определить, как скомпилировать и скомпоновать программу или набор программ.

cd openssl-1.1.1l ./config --prefix=$HOME/.local --openssldir=$HOME/.local/ssl '-Wl,--enable-new-dtags,-rpath,$(LIBRPATH)' make -j$((`nproc`/4)) && make install

openssl version

Устанавливаем Python

cd ~/.beget/tmp wget https://www.python.org/ftp/python/3.11.0/Python-3.11.0.tgz tar -xvzf Python-3.11.0.tgz

cd ~/.beget/tmp/Python-3.11.0 ./configure --prefix=$HOME/.local --with-openssl=$HOME/.local --with-openssl-rpath=auto --enable-optimizations --enable-loadable-sqlite-extensions LDFLAGS="-Wl,-rpath /usr/local/lib" make -j$((`nproc`/4)) && make install

python3 --version

Готовим файловую структуру сайта, переносим проект на сервер

cd ~/staging.bddt.space git clone https://github.com/DmRafaule/DjangoDeploymentTest source

python3 -m venv venv source ./venv/bin/activate

which python

pip install -r source/requirements.txt

Конфигурация файлов работы сервера (.htaccess, passenger_wsgi.py, settings.py)

.htaccess — это локальный конфигурационный файл веб-сервера Apache, который позволяет управлять настройками сайта.

passenger_wsgi.py - служит точкой входа для вашего приложения, обеспечивая взаимодействие между веб-сервером (например, Apache или Nginx) и вашим WSGI-совместимым веб-фреймворком (например, Django или Flask)

Файл passenger_wsgi.py

touch ~/staging.bddt.space/passenger_wsgi.py

import os, sys # 1 sys.path.insert(0, '/home/t/timachuduk/staging.bddt.space/source/Website') # 2 sys.path.insert(1, '/home/t/timachuduk/staging.bddt.space/venv/lib/python3.11/site-packages') # 3 os.environ['DJANGO_SETTINGS_MODULE'] = 'Website.settings' from django.core.wsgi import get_wsgi_application application = get_wsgi_application()

1. Где под первым комментарием указывается путь до корня твоего проекта ( это там где manage.py файл находится).
2. Где под вторым комментарием указывается путь до установленных пакетов через виртуальное окружение.
3. Где под третьим комментарием указывается путь до файла settings.py относительно указанного первого путя.

Файл settings.py

{ "SECRET_KEY": "django-insecure-4#-wrp_(53^0_9$%p8lq+qf43z0dx0ji6bh!sa1mfn^l)4-lq@", "DEBUG": true, "ALLOWED_HOSTS": ["staging.bddt.space"], "DATABASES": { "default": { "ENGINE": "django.db.backends.mysql", "NAME": "timachuduk_bddt", "USER": "timachuduk_bddt", "PASSWORD": "xW%exys3ORGS", "HOST": "localhost", "PORT": 3306 } }, "EMAIL": { "DEFAULT_FROM_EMAIL": "bddt@bddt.space", "DEFAULT_TO_EMAIL": "chedrden@gmail.com", "EMAIL_HOST": "smtp.beget.com", "EMAIL_PORT": 25, "EMAIL_HOST_USER": "bddt@bddt.space", "EMAIL_HOST_PASSWORD": "Li9kYCBx*i!!" }, "STAGING_SERVER": "http://staging.bddt.space" }

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 # ...

Файл .htaccess

PassengerEnabled On PassengerPython /home/t/timachuduk/staging.bddt.space/venv/bin/python

Конфигурация статических и медиа файлов

cd ~/staging.bddt.space/source/Website ln -s ../../public_html/static static ln -s ../../public_html/media media

mkdir ~/staging.bddt.space/public_html/static mkdir ~/staging.bddt.space/public_html/media

Завершаем развёртывание сайта

1. Миграция базы данных [./manage.py migrate]
2. Сбор статических файлов [./manage.py collectstatic]
3. Компиляция переводов (если есть) [./manage.py compilemessages]
4. Проверка тестов (если есть) [./manage.py test]

Хотя запустить тесты на хостинге от бегет тебе не удастся. Отсутствуют необходимые библиотеки для этого. Ну или я не понял как это обойти.

Дополнительно (опционально, хотя не очень)

Как перезагрузить сайт на Django если внёс изменения на нём ?

mkdir ~/staging.bddt.space/tmp && touch ~/staging.bddt.space/tmp/restart.txt

Как перенести локальную базу данных на сервер ?

./manage.py dumpdata --exclude auth.permission --exclude contenttypes > data.json

scp data.json timachuduk@timachuduk.beget.tech:~/staging.bddt.space/source/Website

./manage.py loaddata data.json

Хочу подчеркнуть, что кроме дампа базы данных тебе ещё потребуются и вся директория медиа-файлов. БД не хранит файлы, но только ссылки на них. По этому, не забудь переместить на сервер ещё и все свои медиа файлы

Как перенести сайт на HTTPS протокол?

1. Выбираем тип сертификата, бесплатный нам подойдёт.
2. Выбираем поддомен на который хотим распространить работу сертификата.

1. Выбрать сайт, для которого настроить редирект
2. Включить редирект

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

1. Работа в Linux-терминале
2. Работа через оболочку SSH
3. Работа с сервисами и демонами через systemctl
4. Настройка и работа с Nginx сервером
5. Настройка и работа с Gunicorn
6. Написание и выполнение Bash-скриптов

Создаём VPS на beget

A-запись отвечает за возвращение 32-битного числ, более известного как IPv4. Используется для соединения IPv4 адресов с доменными именами.

Ты можешь ещё изменить A-записи в сайтах с поддоменом www, например.

Чтобы изменения вступили в силу надо подождать минут 10-15 минут.

Подключаемся к VPS

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

Вообще, можно обойтись и встроенными средствами на самом сайте. Там есть и файловый менеджер, и эмулятор терминала, через которые тоже можно работать. Может кому-то это будет удобнее.

PowerShell, Git Bash, PyTTy - все они являются терминальными эмуляторами. Суть которых состоит в том, чтобы получить на входе текст(команду), а на выходе выполнить некое действие, взаимодействие с той или иной программной частью машины.

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

ssh root@192.168.1.1

ssh root@192.168.1.1 -i .ssh/rsa_key

1. Где root - это имя пользователя, через которого ты хочешь иметь доступ к серверу.
2. Где 192.168.1.1 - это адрес сервера к которому ты хочешь подключиться.
3. Где .ssh/rsa_key - это путь к приватному ключу для подключения без пароля

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

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 ~/staging.bddt.space cd ~/staging.bddt.space git clone https://github.com/DmRafaule/DjangoDeploymentTest source python -m venv venv

1. staging.bddt.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": ["staging.bddt.space"], "DATABASES": { "default": { "ENGINE": "django.db.backends.mysql", "NAME": "timachuduk_bddt", "USER": "timachuduk_bddt", "PASSWORD": "xW%exys3ORGS", "HOST": "timachuduk.beget.tech", "PORT": 3306 } }, "EMAIL": { "DEFAULT_FROM_EMAIL": "bddt@bddt.space", "DEFAULT_TO_EMAIL": "chedrden@gmail.com", "EMAIL_HOST": "smtp.beget.com", "EMAIL_PORT": 25, "EMAIL_HOST_USER": "bddt@bddt.space", "EMAIL_HOST_PASSWORD": "Li9kYCBx*i!!" }, "STAGING_SERVER": "http://staging.bddt.space" }

1. Во-первых нужно знать какой бекенд подключать - django.db.backends.mysql
2. Во-вторых имя пользователя и базы данных, они будут совпадать - timachuduk_bddt
3. В-третьих, пароль от базы данных - xW%exys3ORGS
4. В-четвёртых, имя хоста базы данных - его можно найти на странице настройки баз данных
5. И в пятых порт подключения - он всегда один и тот же - 3306

1. DEFAULT_FROM_EMAIL - это адрес почты от имени которого мы отправляем сообщения. Необязательно
2. DEFAULT_TO_EMAIL - это адрес почты на имя которой отправляется сообщение. Необязательно
3. EMAIL_HOST - это константа, smtp.beget.com
4. EMAIL_PORT - это константа, 25
5. EMAIL_HOST_USER - имя ранее созданного почтового ящика, bddt@bddt.space в моём случае
6. EMAIL_HOST_PASSWORD - ранее заданный пароль

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

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. Имя для нашего сервера (доменное имя). В моём случае это должно быть staging.bddt.space.
3. Папки, которые этот сервер будет обслуживать. Как минимум нужно настроить корневой каталог "/". Но этим всё не ограничивается, на моём сайте используется различная статика в виде картинок и иконок. Плюс медиа файлы, которые загружаются непосредственно пользователем.

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

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

cd ~/staging.bddt.space mkdir static mkdir media cd source/Website

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

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

1. staging.bddt.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_https-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 ~/staging.bddt.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/staging.bddt.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 ~/staging.bddt.space/source/gunicorn.service /etc/systemd/system/staging-gunicorn.service sudo vim /etc/systemd/system/staging-gunicorn.service sudo systemctl start staging-gunicorn sudo systemctl enable staging-gunicorn

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

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

sudo ~/staging.bddt.space/venv/bin/certbot certonly --nginx -d staging.bddt.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/staging.bddt.space/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/staging.bddt.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, в свою очередь говорит: УРЛ на который ты попал сейчас доступен по этому адресу, но возможно так будет не всегда.

Деплой боевого сервера (опционально)

cd ~/staging.bddt.space/source ./server-setup.sh bddt.space on_https

1. bddt.space - это домен боевого сервера
2. on_https - это флаг, который указывает скрипту разместить сайт сразу на протоколе HTTPS

cd ~/staging.bddt.space/source ./deploy.sh bddt.space --skip-tests

1. Где bddt.space - домен твоего боевого сервера.
2. Где --skip-tests - пропуск тестов

1. Мы делаем некоторые изменения в проекте на локальном сервере на ноутбуке(например)
2. Делаем коммит
3. Подключаемся к серверу и тащим(git pull) обновления на тестовый сервер - staging.bddt.space
4. Запускаем тесты (Функциональные, Модульные). Сами, в конце концов, обозреваем не сломали ли чего
5. Если всё ок, запускаем deploy.sh и изменения, которые были сделаны на локальном сервере применяются на боевом сервере - bddt.space.

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

Заключение