Comments 15
За инструкцию спасибо. Вопрос по миграции: может лучше так:
python3 manage.py migrate --run-syncdbВроде как подчищается всё старое, и вообще ...
Я пользуюсь gunicorn за nginx Тоже нормально. Все упаковано в контейнеры docker.
Тут скорее вопрос как перезапустить все чтобы у пользователей на сайте падения на время перезапуска. Это же не мгновенно - перезапуск 100500 микросервисов пачкой
Ну вот опять снова. Добро пожаловать в клуб писателей статей про деплой джанго на убунте.
Постоянные члены приветствуют вас: раз, два, три, четыре.. Ну и я отметился немного. Остальных лень искать просто. Со статьи на DigitalOcean вообще начинают все, по-моему.
Привет вам из 2022 года, кстати. Ubuntu 20.04, хоть и LTS, но новая выходит уже через 3 месяца и, соответственно, ценность вашей статьи "слегка" упадет. А ее могут найти и через 3 года. Python, кстати, тоже уже 3.10 вышел.
Типичный вопрос - а где контейнеры? А где сертификаты?
Ubuntu 20.04, хоть и LTS, но новая выходит уже через 3 месяца и, соответственно, ценность вашей статьи "слегка" упадет
Любители Bleeding Edge обычно не сидят на LTS версиях Ubuntu :)
меня смутил 1 воркер (я ставлю 3); и про сертификаты сейчас писать надо сразу, потому что без HTTPS далеко не уехать. И, конечно, лучше делать конфиг в /etc/nginx/sites-available, и следующим шагом делать ln -s линк в /etc/nginx/sites-enabled. Иначе, когда будете варианты делать, nginx будет с ума сходить от количества противоречивых записей и откажется запускаться.
это очень плохо
а цель у нас одна - задеплоить уже наконец этот **** проект!
...
то была огромная "простыня" текста, читать которую было слишком долго.
That's the spirit! Может и не лезли бы тогда делиться мудростью?
По существу. Руками ничего делать не надо. Никогда. Надо писать скрипты и запускать их. Вот хотите с нуля сконфигурировать машину - пишете скрипт, кладёте в гит. Запускаете его. Получаете сконфигурированную машину. Хотите задеплоить версию сайта из гита - пишете скрипт, кладёте в гит. Запускаете его. Получаете новую задеплоенную версию. Это позволяет добиться прозрачности и воспроизводимости. Под скриптами понимается что угодно от баша на коленке до всяких там терраформов.
Для этого есть Nginx Unit с поддержкой питона.
Простите, для чего - "для этого"? Nginx Unit, судя по всему, может заменить только gunicorn, но будет ли что-то лучше после этого?
Nginx + gunicorn/uwsgi
В статье больше ничего и нет.
А вы сами-то его используете?
Unit заменяет только gunicorn. Перед ним все равно надо ставить еще, например, nginx.
Конфиги в json, как по мне - довольно спорная фича. Ни строчку не закомментировать, ни запятую не пропустить, да и скобок миллион... Валидируется проще, конечно, и парсер легче чем yaml... API есть - это плюс.
Да и с поддержкой, как тут написали, все непонятно. На StackOverflow всего 16 вопросов по тегу.
Не надо перед ним ничего ставить. Он заменяет nginx.
Использовал на нескольких проектах.
Все-таки, "заменяет nginx" - это очень громко сказано. Он даже позиционируется как "app server". Статику он может раздавать, но кэширования - нет. Авторизации - нет, вообще никакой. Да что там говорить - даже gzip упаковки при передаче нет. Только если приложение само это все реализует.
Конфиг в nginx - это свой язык. Там можно и переменные определять, и логику писать.
Я уж даже не буду упоминать про расширение nginx с помощью lua-скриптов, например.
Ленивый деплой Django проекта UWSGI + NGINX (UBUNTU 20.04)