Correr Flask ou Django com gunicorn e systemd num VPS

O servidor que vem com o Flask e com o Django (flask run, manage.py runserver) é para desenvolver, não para o público. Num VPS, a combinação habitual é o gunicorn (que corre a aplicação com vários processos) gerido pelo systemd (que a arranca com o servidor e a levanta se cair), com o nginx à frente a tratar do HTTPS. Este artigo monta as duas primeiras peças. É para um VPS com root; na hospedagem partilhada serve-se o «Setup Python App».

Passo a passo

1 Crie o ambiente virtual e instale o gunicorn na pasta da aplicação, com um utilizador próprio (não o root): cd /home/appuser/app
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt gunicorn
Se o pip se queixar de «externally-managed-environment», veja esse erro.
2 Teste à mão primeiro. Flask: .venv/bin/gunicorn --bind 127.0.0.1:8000 app:appO app:app quer dizer «o ficheiro app.py, a variável app». No Django, use o módulo WSGI do projecto: meuprojecto.wsgi:application. Se responde a curl http://127.0.0.1:8000, pare com Ctrl+C e avance.
3 Crie o serviço, com sudo nano /etc/systemd/system/minha-app.service:[Unit]
Description=Minha aplicacao
After=network.target

[Service]
User=appuser
Group=appuser
WorkingDirectory=/home/appuser/app
EnvironmentFile=/home/appuser/app/.env
ExecStart=/home/appuser/app/.venv/bin/gunicorn --workers 3 --bind 127.0.0.1:8000 app:app
Restart=on-failure

[Install]
WantedBy=multi-user.target
4 Active e arranque:sudo systemctl daemon-reload
sudo systemctl enable --now minha-app
sudo systemctl status minha-app
O enable faz arrancar com o servidor; o --now arranca já.
5 Leia os registos quando algo falha: journalctl -u minha-app -n 100. Depois de actualizar o código: sudo systemctl restart minha-app.

Os pontos que costumam trazer problemas

Ponto O que fazer
Número de processos (--workers) O 3 acima é um exemplo. Cada processo gasta memória: comece com poucos e veja o que o VPS aguenta.
Endereço do bind 127.0.0.1 só aceita pedidos do próprio servidor, que é o que quer atrás de um proxy. Não ponha 0.0.0.0 sem uma razão.
Segredos No ficheiro apontado por EnvironmentFile, com chmod 600, e não escritos no serviço nem no código.
Ficheiros estáticos (Django) O gunicorn não os serve bem: deixe-os ao nginx, ou veja os estáticos do Django.
O serviço não arranca systemctl status e journalctl dizem porquê: ler o systemctl status.
Use sempre o gunicorn do ambiente virtual no ExecStart, com o caminho completo. O systemd não activa o ambiente: se escrever só gunicorn, ou usa o do sistema (e não encontra as suas bibliotecas) ou não o encontra de todo. E nunca corra a aplicação como root.
Falta o HTTPS e o domínio. O gunicorn atrás do nginx faz-se como em nginx como proxy inverso: o proxy_pass aponta para http://127.0.0.1:8000. Para a visão geral de serviços próprios, veja correr o seu programa como serviço. Num VPS não gerido, o serviço é seu de manter: até onde vai o nosso suporte.

Precisa de um servidor para a sua aplicação Python? Veja os VPS.

Ver os servidores VPS

VEJA TAMBÉM

Correr uma aplicação Flask ou FastAPI

Como correr o seu programa como serviço do systemd que arranca com o servidor

Nginx como proxy inverso à frente de um contentor

PRODUTO RECOMENDADO

Servidor VPS com acesso root

Recursos só seus, o sistema que escolher, reinstalação quando quiser. desde 7.560,00 Kz/mês (plano de 3 anos, com cupão)

Ver planos
  • 0 Utilizadores acharam útil
Esta resposta foi útil?