Здравствуйте!
Хочу представить вам пошаговую инструкцию по деплою django проекта.
Сразу скажу, что используя мою краткую инструкцию вы не поймете механику развертывания. По сути, это просто список команд для деплоя. Тут не будет никаких подробностей касательно работы UWSGI, NGINX и самого Django. Я просто помогу быстро добраться до цели, а цель у нас одна - задеплоить уже наконец этот **** проект!
(Инструкция тестировалась на VPS Ubuntu 20.04 с Django 3.2.8, python3.8, NGINX 1.18.0, UWSGI 2.0.20)
Заходим в консоль линукс сервера и вперед!
sudo apt update
sudo apt upgrade
sudo apt-get install nginx uwsgi
sudo apt-get install uwsgi-plugin-python3
Переходим в директорию /var
cd /var
Создаем себе внутри папку для дальнейшей работы
mkdir work
cd work
Создаем папку под статику и предоставляем пользователю www-data права на неё. (UWSGI и NGINX будут работать от лица www-data)
mkdir static
chown www-data /var/work/static
Проверим версию пайтона, установим пакет для вирт. окружения и создадим егоpython3 -V
sudo apt install python3.8-venv
python3 -m venv venv
Активируем окружение
. ./venv/bin/activate
pip install django
(и другие или загрузите их позже из requirements.txt)
git clone https://github.com/nick_name/project.git
(или переместите в текущую папку ваш проект любым другим способом)
(В инструкции я использую проект со стандартной архитектурой вида:
projectname/
...
manage.py
projectname/
...
settings.py
wsgi.py
...
)
Переходим в файл settings.py вашего проекта джанго и редактируем его.
Необходимо добавить ip вашего сервера в ALLOWED_HOSTS должно получиться что-то вроде ['1.1.1.1', '127.0.0.1']
добавить STATIC_ROOT = '/var/work/static'
Вернитесь в папку с manage.pycd /var/work/имя вашего проекта
Далее подготовим сам Django проект. Проведем миграции и соберем статику в папку, которую мы ранее создали в work.
python3 manage.py makemigrations
python3 manage.py migrate
python3 manage.py collectstatic
python3 manage.py runserver
Если есть ошибка в проекте - устранить, если не хватает библиотек - установить через pip install
Если ошибок не возникло - ваш Django проект в порядке, если нет, то исправляйте ошибки в нем. Советую сверить ту ли версию Django вы поставили себе на сервер.
Близимся к концу. Виртуальное окружение можно выключить. Сделаем это командой:
deactivate
Далее откроем файл nginx.conf и проверим в нем параметр user, он должен быть www-data.
user www-data;
nano /etc/nginx/nginx.conf
далее создадим и заполним конфиг my_app (для nginx)
nano /etc/nginx/sites-enabled/my_app
server {
listen 81;
server_tokens off;
server_name 0.0.0.0;
location / {
include uwsgi_params;
uwsgi_pass unix:///run/uwsgi/app/myapp/socket;
}
location /static/ {
alias /var/work/static/;
}
}
далее создадим и заполним конфиг myapp.ini (для uwsgi)
[uwsgi]
chdir = /var/work/projectname
env = DJANGO_SETTINGS_MODULE = projectname.settings
wsgi-file = /var/work/projectname/projectname/wsgi.py
workers = 1
max-requests = 5000
plugins = python3
home = /var/work/venv
pythonpath = /var/work/venv/lib/python3.8/site-packages
processes = 5
threads = 2
master = true
die-on-term = true
socket = /run/uwsgi/app/myapp/socket
chmod-socket = 664
vacuum = true
uid = www-data
gui = www-data
!!! Я использую python3 (3.8) если у вас другой, то измените пункты, связанные с python
Или используйте версию 3.8)) !!!
projectname ВЕЗДЕ измените на имя вашего проекта
далее перезапустим uwsgi и nginx
service uwsgi restart
service nginx restart
После перезапуска nginx и uwsgi сайт должен быть доступен по адресу http://IP вашего сервера:81
ГДЕ СМОТРЕТЬ ЛОГИ?
/var/log/nginx
/var/log/uwsgi/app
Надеюсь, это вам помогло. В интернете ничего из того, что я смотрел не работало "из коробки". Каждый раз возникала ошибка то тут, то там.. Ну или это была огромная "простыня" текста, читать которую было слишком долго. Да и после стольких ошибок не было доверия к тем или иным туториалам.
Составив эту инструкцию я создал несколько новых серверов на Ubuntu и протестировал каждый шаг.
Буду рад комментариям. Пишите, если у вас возникли какие-то ошибки!
Комментарии (14)
DrBulkin
15.01.2022 12:54+3Я пользуюсь gunicorn за nginx Тоже нормально. Все упаковано в контейнеры docker.
Тут скорее вопрос как перезапустить все чтобы у пользователей на сайте падения на время перезапуска. Это же не мгновенно - перезапуск 100500 микросервисов пачкой
baldr
15.01.2022 13:18+17Ну вот опять снова. Добро пожаловать в клуб писателей статей про деплой джанго на убунте.
Постоянные члены приветствуют вас: раз, два, три, четыре.. Ну и я отметился немного. Остальных лень искать просто. Со статьи на DigitalOcean вообще начинают все, по-моему.
Привет вам из 2022 года, кстати. Ubuntu 20.04, хоть и LTS, но новая выходит уже через 3 месяца и, соответственно, ценность вашей статьи "слегка" упадет. А ее могут найти и через 3 года. Python, кстати, тоже уже 3.10 вышел.
Типичный вопрос - а где контейнеры? А где сертификаты?
Areso
16.01.2022 01:24Ubuntu 20.04, хоть и LTS, но новая выходит уже через 3 месяца и, соответственно, ценность вашей статьи "слегка" упадет
Любители Bleeding Edge обычно не сидят на LTS версиях Ubuntu :)
js605451
16.01.2022 23:02+1а цель у нас одна - задеплоить уже наконец этот **** проект!
...
то была огромная "простыня" текста, читать которую было слишком долго.
That's the spirit! Может и не лезли бы тогда делиться мудростью?
По существу. Руками ничего делать не надо. Никогда. Надо писать скрипты и запускать их. Вот хотите с нуля сконфигурировать машину - пишете скрипт, кладёте в гит. Запускаете его. Получаете сконфигурированную машину. Хотите задеплоить версию сайта из гита - пишете скрипт, кладёте в гит. Запускаете его. Получаете новую задеплоенную версию. Это позволяет добиться прозрачности и воспроизводимости. Под скриптами понимается что угодно от баша на коленке до всяких там терраформов.
killla
17.01.2022 08:09Для этого есть Nginx Unit с поддержкой питона.
baldr
17.01.2022 09:37Простите, для чего - "для этого"? Nginx Unit, судя по всему, может заменить только gunicorn, но будет ли что-то лучше после этого?
killla
17.01.2022 20:01Nginx + gunicorn/uwsgi
В статье больше ничего и нет.baldr
17.01.2022 20:38А вы сами-то его используете?
Unit заменяет только gunicorn. Перед ним все равно надо ставить еще, например, nginx.
Конфиги в json, как по мне - довольно спорная фича. Ни строчку не закомментировать, ни запятую не пропустить, да и скобок миллион... Валидируется проще, конечно, и парсер легче чем yaml... API есть - это плюс.
Да и с поддержкой, как тут написали, все непонятно. На StackOverflow всего 16 вопросов по тегу.
killla
17.01.2022 23:07-1Не надо перед ним ничего ставить. Он заменяет nginx.
Использовал на нескольких проектах.baldr
17.01.2022 23:40Все-таки, "заменяет nginx" - это очень громко сказано. Он даже позиционируется как "app server". Статику он может раздавать, но кэширования - нет. Авторизации - нет, вообще никакой. Да что там говорить - даже gzip упаковки при передаче нет. Только если приложение само это все реализует.
Конфиг в nginx - это свой язык. Там можно и переменные определять, и логику писать.
Я уж даже не буду упоминать про расширение nginx с помощью lua-скриптов, например.
OnYourLips
17.01.2022 13:35Судя по состоянию его дел на докерхабе, там все плохо с поддержкой. Версия продукта для php новой версии там чуть ли не с годовым опозданием вышла. Тащить в продакшен я бы этот продукт точно не стал.
Apoheliy
За инструкцию спасибо. Вопрос по миграции: может лучше так:
Вроде как подчищается всё старое, и вообще ...