Tutorial

Como servir aplicativos Flask com o uWSGI e o Nginx no Ubuntu 18.04

Published on December 12, 2019
Português
Como servir aplicativos Flask com o uWSGI e o Nginx no Ubuntu 18.04

Introdução

Neste guia, você construirá um aplicativo Python usando o microframework do Flask no Ubuntu 18.04. A maior parte deste artigo será sobre como configurar o servidor do aplicativo uWSGI e como iniciar o aplicativo e configurar o Nginx para atuar como um proxy reverso no front-end.

Pré-requisitos

Antes de iniciar este guia, você deve ter:

  • Um servidor com o Ubuntu 18.04 instalado e um usuário não raiz com privilégios sudo. Siga nosso guia de configuração inicial do servidor para orientação.

  • O Nginx instalado, seguindo os Passos 1 e 2 de Como Instalar o Nginx no Ubuntu 18.04.

  • Um nome de domínio configurado para apontar para o seu servidor. Você pode comprar um no Namecheap ou obter um de graça no Freenom. Você pode aprender como apontar domínios para o DigitalOcean seguindo a relevante documentação para domínios e DNS. Certifique-se de criar os seguintes registros DNS:

    • Um registro com o your_domain <^>apontando para o endereço IP público do seu servidor.
    • Um registro A com www.your_domain apontando para o endereço IP público do seu servidor.
  • Familiaridade com a uWSGI, nosso servidor do aplicativo, e as especficiações da WSGI. Este debate sobre definições e conceitos examinará ambos em detalhes.

Passo 1 — Instalando os componentes dos repositórios do Ubuntu

Nosso primeiro passo será instalar todas as partes dos repositórios do Ubuntu que vamos precisar. Vamos instalar o pip e o gerenciador de pacotes Python para gerenciar nossos componentes Python. Também vamos obter os arquivos de desenvolvimento do Python necessários para construir a uWSGI.

Primeiramente, vamos atualizar o índice local de pacotes e instalar os pacotes que irão nos permitir construir nosso ambiente Python. Estes incluem o python3-pip, junto com alguns outros pacotes e ferramentas de desenvolvimento necessários para um ambiente de programação robusto:

  1. sudo apt update
  2. sudo apt install python3-pip python3-dev build-essential libssl-dev libffi-dev python3-setuptools

Com esses pacotes instalados, vamos seguir em frente para criar um ambiente virtual para nosso projeto.

Passo 2 — Criando um Ambiente Virtual em Python

Em seguida, vamos configurar um ambiente virtual para isolar nosso aplicativo Flask dos outros arquivos Python no sistema.

Inicie instalando o pacote python3-venv, que instalará o módulo venv:

  1. sudo apt install python3-venv

Em seguida, vamos fazer um diretório pai para nosso projeto Flask. Acesse o diretório após criá-lo:

  1. mkdir ~/myproject
  2. cd ~/myproject

Crie um ambiente virtual para armazenar os requisitos Python do projeto Flask digitando:

  1. python3.6 -m venv myprojectenv

Isso instalará uma cópia local do Python e do pip para um diretório chamado myprojectenv dentro do diretório do seu projeto.

Antes de instalar aplicativos no ambiente virtual, você precisa ativá-lo. Faça isso digitando:

  1. source myprojectenv/bin/activate

Seu prompt mudará para indicar que você agora está operando no ambiente virtual. Ele se parecerá com isso (myprojectenv)user@host:~/myproject$.

Passo 3 — Configurando um aplicativo Flask

Agora que você está no seu ambiente virtual, instale o Flask e a uWSGI e comece a projetar o seu aplicativo.

Primeiramente, vamos instalar o wheel com a instância local do pip para garantir que nossos pacotes serão instalados mesmo se estiverem faltando arquivos wheel:

  1. pip install wheel

Nota: Independentemente da versão de Python que você estiver usando, quando o ambiente virtual for ativado, você deverá usar o comando pip (não pip3).

Em seguida, vamos instalar o Flask e a uWSGI:

  1. pip install uwsgi flask

Criando um App de exemplo

Agora que você tem o Flask disponível, você pode criar um aplicativo simples. O Flask é um microframework. Ele não inclui muitas das ferramentas que os frameworks mais completos talvez tenham. Ele existe, principalmente, como um módulo que você pode importar para seus projetos para ajudá-lo na inicialização de um aplicativo Web.

Embora seu aplicativo possa ser mais complexo, vamos criar nosso app Flask em um único arquivo, chamado ``myproject.py:

  1. nano ~/myproject/myproject.py

O código do aplicativo ficará neste arquivo. Ele importará o Flask e instanciará um objeto Flask. Você pode usar isto para definir as funções que devem ser executadas quando uma rota específica for solicitada:

~/myproject/myproject.py
from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "<h1 style='color:blue'>Hello There!</h1>"

if __name__ == "__main__":
    app.run(host='0.0.0.0')

Isso define basicamente qual conteúdo apresentar quando o domínio raiz for acessado. Salve e feche o arquivo quando você terminar.

Se você seguiu o guia de configuração inicial do servidor, você deverá ter um firewall UFW ativado. Para testar o aplicativo, você precisa permitir o acesso à porta 5000:

  1. sudo ufw allow 5000

Agora, você pode testar seu app Flask digitando:

  1. python myproject.py

Você verá um resultado como o seguinte, incluindo um aviso útil lembrando você para não usar essa configuração do servidor na produção:

Output
* Serving Flask app "myproject" (lazy loading) * Environment: production WARNING: Do not use the development server in a production environment. Use a production WSGI server instead. * Debug mode: off * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

Visite o endereço IP do seu servidor seguido de :5000 no seu navegador Web:

http://your_server_ip:5000

Você deve ver algo como isto:

Flask sample app

Quando terminar, tecle CTRL-C na janela do seu terminal para parar o servidor de desenvolvimento Flask.

Criando o ponto de entrada da WSGI

Em seguida, vamos criar um arquivo que servirá como o ponto de entrada para nosso aplicativo. Isso dirá ao nosso servidor uWSGI como interagir com ele.

Vamos chamar o arquivo de wsgi.py:

  1. nano ~/myproject/wsgi.py

Neste arquivo, vamos importar a instância Flask do nosso aplicativo e então executá-lo:

~/myproject/wsgi.py
from myproject import app

if __name__ == "__main__":
    app.run()

Salve e feche o arquivo quando você terminar.

Passo 4 — Configurando a uWSGI

Seu aplicativo agora está gravado com um ponto de entrada estabelecido. Podemos agora seguir em frente para configurar a uWSGI.

Testando o atendimento à uWSGI

Vamos testar para ter certeza de que a uWSGI pode atender nosso aplicativo.

Podemos fazer isso simplesmente passando-lhe o nome do nosso ponto de entrada. Criamos esse ponto de entrada através do nome do módulo (menos a extensão .py) mais o nome do objeto callable dentro do aplicativo. No nosso caso, trata-se do wsgi:app.

Vamos também especificar o soquete, de modo que ele seja iniciado em uma interface disponível publicamente, bem como o protocolo, para que ele use o HTTP em vez do protocolo binário uwsgi. Vamos usar o mesmo número de porta, 5000, que abrimos mais cedo:

  1. uwsgi --socket 0.0.0.0:5000 --protocol=http -w wsgi:app

Visite o endereço IP do seu servidor com :5000 anexo ao final no seu navegador Web novamente:

http://your_server_ip:5000

Você deve ver o resultado do seu aplicativo novamente:

Flask sample app

Quando você tiver confirmado que ele está funcionando corretamente, pressione CTRL-C na janela do seu terminal.

Acabamos agora o nosso ambiente virtual, para que possamos desativá-lo:

  1. deactivate

Agora, qualquer comando Python voltará a usar o ambiente do sistema Python.

Criando um arquivo de configuração da uWSGI

Você testou e viu que a uWSGI pode atender o seu aplicativo. Porém, em última instância, você irá querer algo mais robusto para o uso a longo prazo. Você pode criar um arquivo de configuração da uWSGI com as opções relevantes para isso.

Vamos colocar aquele arquivo no diretório do nosso projeto e chamá-lo de myproject.ini:

  1. nano ~/myproject/myproject.ini

Dentro, vamos começar com o cabeçalho [uwsgi], para que a uWSGI saiba aplicar as configurações. Vamos especificar duas coisas: o módulo propriamente dito, recorrendo ao arquivo wsgi.py (menos a extensão) e ao objeto callable dentro do arquivo, app:

~/myproject/myproject.ini
[uwsgi]
module = wsgi:app

Em seguida, vamos dizer à uWSGI para iniciar em modo mestre e gerar cinco processos de trabalho para atender a pedidos reais:

~/myproject/myproject.ini
[uwsgi]
module = wsgi:app

master = true
processes = 5

Quando você estava testando, você expôs a uWSGI em uma porta da rede. No entanto, você usará o Nginx para lidar com conexões reais do cliente, as quais então passarão as solicitações para a uWSGI. Uma vez que esses componentes estão operando no mesmo computador,é preferífel usar um soquete Unix porque ele é mais rápido e mais seguro. Vamos chamar o soquete de myproject<^>.sock e colocá-lo neste diretório.

Vamos alterar também as permissões no soquete. Mais tarde, iremos atribuir a propriedade do grupo Nginx sobre o processo da uWSGI. Dessa forma, precisamos assegurar que o proprietário do grupo do soquete consiga ler as informações que estão nele e gravar nele. Quando o processo parar, também limparemos o soquete, adicionando a opção vacuum:

~/myproject/myproject.ini
[uwsgi]
module = wsgi:app

master = true
processes = 5

socket = myproject.sock
chmod-socket = 660
vacuum = true

A última coisa que vamos fazer é definir a opção die-on-term. Isso pode ajudar a garantir que o sistema init e a uWSGI tenham as mesmas suposições sobre o que cada sinal de processo significa. Configurar isso alinha os dois componentes do sistema, implementando o comportamento esperado:

~/myproject/myproject.ini
[uwsgi]
module = wsgi:app

master = true
processes = 5

socket = myproject.sock
chmod-socket = 660
vacuum = true

die-on-term = true

Você pode ter notado que não especificamos um protocolo como fizemos a partir da linha de comando. Isso acontece porque, por padrão, a uWSGI fala usando o protocolo uwsgi, um protocolo binário rápido projetado para se comunicar com outros servidores. O Nginx pode falar este protocolo de maneira nativa, então é melhor usar isso do que forçar a comunicação pelo HTTP.

Quando você terminar, salve e feche o arquivo.

Passo 5 — Criando um arquivo de unidade systemd

Em seguida, vamos criar o arquivo de unidade systemd. Criar um arquivo de unidade systemd permitirá que o sistema init do Ubuntu inicie automaticamente a uWSGI e atenda o aplicativo Flask sempre que o servidor for reinicializado.

Para começar, crie um arquivo de unidade que termine com .service dentro do diretório /etc/systemd/system:

  1. sudo nano /etc/systemd/system/myproject.service

Ali, vamos começar com a seção [Unit], que é usada para especificar os metadados e dependências. Vamos colocar uma descrição do nosso serviço aqui e dizer ao sistema init para iniciar isso somente após o objetivo da rede ter sido alcançado:

/etc/systemd/system/myproject.service
[Unit]
Description=uWSGI instance to serve myproject
After=network.target

Em seguida, vamos abrir a seção [Service]. Isso especificará o usuário e o grupo sob o qual que queremos que o processo seja executado. Vamos dar à nossa conta de usuário regular a propriedade sobre o processo, uma vez que ela possui todos os arquivos relevantes. Vamos também dar propriedade sobre o grupo ao grupo www-data para que o Nginx possa se comunicar facilmente com os processos da uWSGI. Lembre-se de substituir esse nome de usuário pelo seu nome de usuário:

/etc/systemd/system/myproject.service
[Unit]
Description=uWSGI instance to serve myproject
After=network.target

[Service]
User=sammy
Group=www-data

Em seguida, vamos mapear o diretório de trabalho e definir a variável de ambiente PATH para que o sistema init saiba que os executáveis do processo estão localizados dentro do nosso ambiente virtual. Vamos também especificar o comando para iniciar o serviço. O systemd exige que seja dado o caminho completo para o executável uWSGI, que está instalado dentro do nosso ambiente virtual. Vamos passar o nome do arquivo de configuração .ini que criamos no nosso diretório de projeto.

Lembre-se de substituir o nome de usuário e os caminhos do projeto por seus próprios dados:

/etc/systemd/system/myproject.service
[Unit]
Description=uWSGI instance to serve myproject
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myproject
Environment="PATH=/home/sammy/myproject/myprojectenv/bin"
ExecStart=/home/sammy/myproject/myprojectenv/bin/uwsgi --ini myproject.ini

Finalmente, vamos adicionar uma seção [Install]. Isso dirá ao systemd ao que vincular este serviço se nós o habilitarmos para iniciar na inicialização. Queremos que este serviço comece quando o sistema regular de vários usuários estiver funcionando:

/etc/systemd/system/myproject.service
[Unit]
Description=uWSGI instance to serve myproject
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myproject
Environment="PATH=/home/sammy/myproject/myprojectenv/bin"
ExecStart=/home/sammy/myproject/myprojectenv/bin/uwsgi --ini myproject.ini

[Install]
WantedBy=multi-user.target

Com isso, nosso arquivo de serviço systemd está completo. Salve e feche-o agora.

Podemos agora iniciar o serviço uWSGI que criamos e habilitá-lo para que ele seja iniciado na inicialização:

  1. sudo systemctl start myproject
  2. sudo systemctl enable myproject

Vamos verificar o status:

  1. sudo systemctl status myproject

Você deve ver um resultado como este:

Output
● myproject.service - uWSGI instance to serve myproject Loaded: loaded (/etc/systemd/system/myproject.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-07-13 14:28:39 UTC; 46s ago Main PID: 30360 (uwsgi) Tasks: 6 (limit: 1153) CGroup: /system.slice/myproject.service ├─30360 /home/sammy/myproject/myprojectenv/bin/uwsgi --ini myproject.ini ├─30378 /home/sammy/myproject/myprojectenv/bin/uwsgi --ini myproject.ini ├─30379 /home/sammy/myproject/myprojectenv/bin/uwsgi --ini myproject.ini ├─30380 /home/sammy/myproject/myprojectenv/bin/uwsgi --ini myproject.ini ├─30381 /home/sammy/myproject/myprojectenv/bin/uwsgi --ini myproject.ini └─30382 /home/sammy/myproject/myprojectenv/bin/uwsgi --ini myproject.ini

Se encontrar erros, certifique-se de resolvê-los antes de continuar com o tutorial.

Passo 5 — Configurando o Nginx para solicitações de proxy

Nosso servidor do aplicativo uWSGI agora deverá estar funcionando, esperando pedidos no arquivo do soquete, no diretório do projeto. Vamos configurar o Nginx para passar pedidos da Web àquele soquete, usando o protocolo uwsgi.

Comece criando um novo arquivo de configuração do bloco do servidor no diretório sites-available do Nginx. Vamos chamá-lo de myproject para mantê-lo alinhado com o resto do guia:

  1. sudo nano /etc/nginx/sites-available/myproject

Abra um bloco de servidor e diga ao Nginx para escutar na porta padrão 80. Vamos também dizer a ele para usar este bloco para pedidos para o nome de domínio do nosso servidor:

/etc/nginx/sites-available/myproject
server {
    listen 80;
    server_name your_domain www.your_domain;
}

Em seguida, vamos adicionar um bloco de localização que corresponda a cada pedido. Dentro deste bloco, vamos incluir o arquivo uwsgi_params, que especifica alguns parâmetros gerais da uWSGI que precisam ser configurados. Vamos então passar os pedidos para o soquete que definimos usando a diretiva uwsgi_pass:

/etc/nginx/sites-available/myproject
server {
    listen 80;
    server_name your_domain www.your_domain;

    location / {
        include uwsgi_params;
        uwsgi_pass unix:/home/sammy/myproject/myproject.sock;
    }
}

Salve e feche o arquivo quando você terminar.

Para habilitar a configuração do bloco do servidor Nginx que você acabou de criar, vincule o arquivo ao diretório sites-enabled:

  1. sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

Com o arquivo naquele diretório, podemos realizar testes à procura de erros de sintaxe, digitando:

  1. sudo nginx -t

Se esse procedimento retornar sem indicar problemas, reinicie o processo do Nginx para ler a nova configuração:

  1. sudo systemctl restart nginx

Finalmente, vamos ajustar o firewall novamente. Já não precisamos de acesso através da porta 5000, então podemos remover essa regra. Podemos então conceder acesso total ao servidor Nginx:

  1. sudo ufw delete allow 5000
  2. sudo ufw allow 'Nginx Full'

Agora, você consegue navegar até o nome de domínio do seu servidor no seu navegador Web:

http://your_domain

Você deve ver o resultado do seu aplicativo:

Flask sample app

Caso encontre quaisquer erros, tente verificar o seguinte:

  • sudo less /var/log/nginx/error.log: verifica os registros de erros do Nginx.
  • sudo less /var/log/nginx/access.log: verifica os registros de acesso do Nginx.
  • sudo journalctl -u nginx: verifica os registros de processo do Nginx.
  • sudo journalctl -u myproject: verifica os registros de uWSGI do seu app Flask.

Passo 7 — Protegendo o aplicativo

Para garantir que o tráfego para seu servidor permaneça protegido, vamos obter um certificado SSL para seu domínio. Há várias maneiras de fazer isso, incluindo a obtenção de um certificado gratuito do Let’s Encrypt, gerando um certificado autoassinado ou comprando algum de outro provedor e configurando o Nginx para usá-lo, seguindo os Passos 2 a 6 de Como criar um certificado SSL autoassinado para o Nginx no Ubuntu 18.04. Vamos escolher a opção um por questão de conveniência.

Primeiramente, adicione o repositório de software Ubuntu do Certbot:

  1. sudo add-apt-repository ppa:certbot/certbot

Aperte ENTER para aceitar.

Em seguida, instale o pacote Nginx do Certbot com o apt:

  1. sudo apt install python-certbot-nginx

O Certbot oferecer várias maneiras de obter certificados SSL através de plug-ins. O plug-in Nginx cuidará da reconfiguração do Nginx e recarregará a configuração sempre que necessário. Para usar este plug-in, digite o seguinte:

  1. sudo certbot --nginx -d your_domain -d www.your_domain

Esse comando executa o certbot com o plug-in --nginx, usando -d para especificar os nomes para os quais desejamos um certificado válido.

Se essa é a primeira vez que você executa o certbot, você será solicitado a informar um endereço de e-mail e concordar com os termos de serviço. Após fazer isso, o certbot se comunicará com o servidor da Let’s Encrypt, executando posteriormente um desafio para verificar se você controla o domínio para o qual está solicitando um certificado.

Se tudo correr bem, o certbot perguntará como você quer definir suas configurações de HTTPS.

Output
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. ------------------------------------------------------------------------------- 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

Select your choice then hit ​​​ENTER​​​​​. A configuração será atualizada e o Nginx recarregará para aplicar as novas configurações. O certbot será encerrado com uma mensagem informando que o processo foi concluído e onde os certificados estão armazenados:

Output
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2018-07-23. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

Se seguiu as instruções de instalação do Nginx nos pré-requisitos, a permissão do perfil HTTP redundante não será mais necessária:

  1. sudo ufw delete allow 'Nginx HTTP'

Para verificar a configuração, vamos navegar novamente até o seu domínio, usando https://:

https://your_domain

Você deve ver novamente o resultado do seu aplicativo, junto com o indicador de segurança do seu navegador, que deve indicar que o site está protegido.

Conclusão

Neste guia, você criou e protegeu um aplicativo Flask simples em um ambiente virtual Python. Você criou um ponto de entrada da WSGI para que qualquer servidor de aplicativo compatível com a WSGI possa interagir com ela; depois, configurou o servidor de app uWSGI para fornecer essa função. Depois, criou um arquivo de serviço systemd para iniciar automaticamente o servidor do aplicativo na inicialização. Você também criou um bloco de servidor Nginx que passa o tráfego Web do cliente para o servidor do aplicativo - retransmitindo pedidos externos - e protegeu o tráfego para seu servidor com o Let’s Encrypt.

O Flask é um framework muito simples - mas extremamente flexível, destinado a fornecer funcionalidade a seus aplicativos sem ser restritivo demais em termos de estrutura e design. Você pode usar a pilha geral descrita neste guia para atender os aplicativos flask que projetar.

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about our products

About the authors


Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?
 
1 Comments


This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Hi there! Althought i find your “tutorial” very simple to follow and well explained, i still have some trouble concluding it. My error comes right at the end of step 6, when i access https://my_domain it shows a "502 bad gateway <br> nginx 1.14.0(ubuntu). I checked all the log files and ran the journal commands has you recommended but even then i cant seem to figure whats causing this error. Could you point out some sugestions so i could solve this?

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

Featured on Community

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more