Pull to refresh

Comments 9

Опять какие-то вредные советы…
Если у вас файлик settings.py не в .gitignore, то после изменения на сервере Debug = False, вы уже не сможете сделать git pull, как сказано у вас в статье. Поэтому, лучше выносить это все (настройки) в отдельный файл по типу .env и оттуда считывать параметры.

gunicorn ProjectName.wsgi:application- -bind 0.0.0.0:9000
Что даст эта команда? Она просто в текущем соединении shh запустит этот процесс, как только вы закроете консоль gunicorn упадет и толка в этом всем 0.
Если нужно, что бы оно постоянно работало (а я так подозреваю именно это вы и хотели получить), то можно воспользоваться systemd (как самым простым вариантом) или docker (для продвинутых).

А еще, если на сервере несколько приложений планируется хостить, то лучше что бы у проекта был свой venv. Хотя даже если не планируется, все же лучше venv делать.
то можно воспользоваться systemd (как самым простым вариантом) или docker (для продвинутых).

Жаль, что сейчас таких "продвинутых" слишком много. Без докера уже hello word не поднять.


то лучше что бы у проекта был свой venv.

Да да, а самое идеальное запихнуть по venv'у в каждый hello word контейнер. Сейчас так модно.
Самые упоротые умудряются запихнуть в контейнер pyenv и забацать там внутри еще venv. Иначе ж hello world с помощью ansible не автоматизировать.

Жаль, что сейчас таких «продвинутых» слишком много. Без докера уже hello word не поднять.

Ну docker для hello word — это выстрел в ноги будет, особенно новичку (хотя на чем то же тренироваться нужно). Но для чего-то маленького он реально не нужен, конечно, все зависит от того, что нужно получить, иногда все же docker очень удобно (если умеешь с ним работать:) ).

запихнуть по venv'у в каждый hello word контейнер
запихнуть в контейнер pyenv и забацать там внутри еще venv
Соболезную, что такое приходилось видеть :)

Согласен, здесь больше похоже на "как запустить", а не "как развернуть". Еще тема с HTTPS на nginx проигнорирована, впрочем, это может быть вынесено на отдельный прокси-сервер.
Однако, справедливости ради, если нужно запустить именно в ssh-сессии, то можно это провернуть через screen или tmux. Тогда можно отключаться. Для тестовых целей сгодится.

Сейчас рекомендуется тянуть настройки из переменных среды.

1. gunicorn лучше развернуть на 127.0.0.1 и уже с него проксировать в nginx
2. Удобнее создать отдельный файл с настройками, например gunicorn.py:

from multiprocessing import cpu_count
from os import environ

def max_workers():
return cpu_count()

bind = '127.0.0.1:' + environ.get('PORT', '9000')
max_requests = 1000
worker_class = 'gevent'
workers = max_workers()

env = {
'DJANGO_SETTINGS_MODULE': 'main.settings'
}

reload = True
name = 'AppName'

$ gunicorn -c gunicorn.py main.wsgi&
systemd (как самым простым вариантом) или docker (для продвинутых).
А может все таки наоборот?
Sign up to leave a comment.

Articles