One place for hosting & domains

      Gunicorn

      How To Serve Flask Applications with Gunicorn and Nginx on Ubuntu 18.04


      Introdução

      Neste guia, você construirá um aplicativo Python usando o microframework Flask no Ubuntu 18.04. A maior parte deste artigo será sobre como configurar o servidor do aplicativo Gunicorn, 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.
      • Familiarize-se com a especificação do WSGI, que o servidor do Gunicorn usará para se comunicar com seu aplicativo Flask. Esta discussãoaborda mais detalhadamente o WSGI.

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

      Nosso primeiro passo será instalar todas as partes que precisamos dos repositórios do Ubuntu. Isso inclui o pip, o gerenciador de pacotes Python que irá gerenciar nossos componentes Python. Também vamos obter os arquivos de desenvolvimento do Python necessários para construir alguns dos componentes do Gunicorn.

      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:

      • sudo apt update
      • 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:

      • 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:

      • mkdir ~/myproject
      • cd ~/myproject

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

      • 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:

      • 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 o Gunicorn e comece a projetar seu aplicativo.

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

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

      Em seguida, vamos instalar o Flask e o Gunicorn:

      • pip install gunicorn 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:<^>

      • 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, será necessário permitir o acesso à porta 5000:

      Agora é possível testar seu app Flask digitando:

      Você verá um resultado como o seguinte, incluindo um aviso útil lembrando para não usar essa configuração de 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 do Gunicorn como interagir com o aplicativo.

      Vamos chamar o arquivo de 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 o Gunicorn

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

      Antes de continuar, devemos verificar se o Gunicorn pode atender o aplicativo corretamente.

      Podemos fazer essa verificação simplesmente passando o nome do nosso ponto de entrada para o Gunicorn. Criamos esse ponto de entrada como o 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.

      Também vamos especificar a interface e a porta a vincular, de modo que o aplicativo seja iniciado em uma interface disponível publicamente:

      • cd ~/myproject
      • gunicorn --bind 0.0.0.0:5000 wsgi:app

      Deverá ver um resultado como o seguinte:

      Output

      [2018-07-13 19:35:13 +0000] [28217] [INFO] Starting gunicorn 19.9.0 [2018-07-13 19:35:13 +0000] [28217] [INFO] Listening at: http://0.0.0.0:5000 (28217) [2018-07-13 19:35:13 +0000] [28217] [INFO] Using worker: sync [2018-07-13 19:35:13 +0000] [28220] [INFO] Booting worker with pid: 28220

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

      http://your_server_ip:5000
      

      Você deve ver o resultado do seu aplicativo:

      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:

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

      Em seguida, vamos criar o arquivo da unidade de serviço systemd. Criar um arquivo de unidade systemd permitirá que o sistema init do Ubuntu inicie automaticamente o Gunicorn e atenda o aplicativo Flask sempre que o servidor inicializar.

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

      • 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=Gunicorn 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 a propriedade sobre o grupo para o grupo www-data, de modo que o Nginx possa se comunicar facilmente com os processos do Gunicorn. Lembre-se de substituir o nome de usuário abaixo pelo seu nome de usuário:

      /etc/systemd/system/myproject.service

      [Unit]
      Description=Gunicorn 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. Este comando fará o seguinte:

      • Iniciar três processos de trabalho (embora deva ajustar isso conforme necessário)
      • Criar e vincular a um arquivo de socket Unix, myproject<^>.sock, dentro de nosso diretório de projeto. Vamos definir um valor de umask de 007 para que o arquivo socket seja criado dando acesso ao proprietário e ao grupo, ao mesmo tempo que restringe outros acessos
      • Especificar o nome do arquivo de ponto de entrada da WSGI, junto com o objeto callable do Python dentro daquele arquivo (wsgi:app)

      O systemd exige que seja dado o caminho completo para o executável do Gunicorn, que está instalado dentro do nosso ambiente virtual.

      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=Gunicorn 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/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app
      

      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=Gunicorn 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/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app
      
      [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 Gunicorn que criamos e habilitá-lo para que ele seja iniciado na inicialização:

      • sudo systemctl start myproject
      • sudo systemctl enable myproject

      Vamos verificar o status:

      • sudo systemctl status myproject

      Você deve ver um resultado como este:

      Output

      ● myproject.service - Gunicorn 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: 28232 (gunicorn) Tasks: 4 (limit: 1153) CGroup: /system.slice/myproject.service ├─28232 /home/sammy/myproject/myprojectenv/bin/python3.6 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 ├─28250 /home/sammy/myproject/myprojectenv/bin/python3.6 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 ├─28251 /home/sammy/myproject/myprojectenv/bin/python3.6 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 └─28252 /home/sammy/myproject/myprojectenv/bin/python3.6 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007

      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 Gunicorn deve estar funcionando agora, esperando pedidos no arquivo de socket no diretório do projeto. Vamos agora configurar o Nginx para passar pedidos Web para aquele socket, fazendo algumas pequenas adições ao seu arquivo de configuração.

      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:

      • 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 proxy_params que especifica alguns parâmetros gerais de proxy que precisam ser configurados. Vamos então passar os pedidos para o socket que definimos usando a diretriz proxy_pass:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name your_domain www.your_domain;
      
          location / {
              include proxy_params;
              proxy_pass http://unix:/home/sammy/myproject/myproject.sock;
          }
      }
      

      Salve e feche o arquivo quando terminar.

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

      • sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

      Com o arquivo naquele diretório, você pode testar quanto a erros de sintaxe:

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

      • 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:

      • sudo ufw delete allow 5000
      • 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 do Gunicorn do seu app Flask.

      Passo 6 — 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:

      • sudo add-apt-repository ppa:certbot/certbot

      Aperte ENTER para aceitar.

      Instale o pacote Nginx do Certbot com o apt:

      • sudo apt install python-certbot-nginx

      O Certbot oferece 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:

      • 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 é mais necessária:

      • sudo ufw delete allow 'Nginx HTTP'

      Para verificar a configuração, navegue novamente para 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, o qual 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, e então configurou o servidor de app Gunicorn 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.



      Source link

      How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu 18.04


      Introdução

      O Django é um framework Web poderoso, que pode ajudar o seu aplicativo Python ou site a decolar. O Django inclui um servidor de desenvolvimento simplificado para testar seu código localmente, mas para qualquer coisa ligeiramente relacionada com produção, é necessário um servidor Web mais seguro e poderoso.

      Neste guia, vamos demonstrar como instalar e configurar alguns componentes no Ubuntu 18.04 para apoiar e servir aplicativos do Django. Vamos configurar um banco de dados PostgreSQL ao invés de usar o banco de dados padrão SQLite. Vamos configurar o servidor do aplicativo Gunicorn para interagir com nossos aplicativos. Então, vamos configurar o Nginx como proxy reverso do Gunicorn, dando-nos acesso aos seus recursos de segurança e desempenho para servir nossos aplicativos.

      Pré-requisitos e objetivos

      Para completar este guia, você deve ter uma nova instância de servidor Ubuntu 18.04 com um firewall básico e um usuário não raiz com privilégios sudo configurados. Você pode aprender como configurar isso examinando nosso guia de configuração inicial do servidor.

      Vamos instalar o Django em um ambiente virtual. Instalar o Django em um ambiente específico do seu projeto permitirá que seus projetos e seus requisitos sejam tratados separadamente.

      Assim que tivermos nosso banco de dados e aplicativo funcionando, vamos instalar e configurar o servidor do aplicativo Gunicorn. Isso servirá como uma interface para nosso aplicativo, traduzindo os pedidos do cliente de HTTP para chamadas Python que nosso aplicativo consegue processar. Então, vamos configurar o Nginx na frente do Gunicorn para aproveitar seus mecanismos de gerenciamento de conexão de alta performance e seus recursos de segurança fáceis de implementar.

      Vamos começar.

      Instalando os pacotes dos repositórios do Ubuntu

      Para começar o processo, vamos baixar e instalar todos os itens que precisamos dos repositórios do Ubuntu. Vamos usar o gerenciador de pacotes Python pip para instalar componentes adicionais um pouco mais tarde.

      Precisamos atualizar o índice de pacotes local apt e, em seguida, baixar e instalar os pacotes. Os pacotes que instalamos dependem da versão do Python que seu projeto usará.

      Se estiver usando o Django com o Python 3, digite:

      • sudo apt update
      • sudo apt install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx curl

      O Django 1.11 é a última versão do Django que suportará o Python 2. Se você estiver começando novos projetos, é altamente recomendado que escolha o Python 3. Se ainda for necessário usar o Python 2, digite:

      • sudo apt update
      • sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl

      Isso instalará o pip, os arquivos de desenvolvimento do Python necessários para criar o Gunicorn mais tarde, o sistema de banco de dados Postgres e as bibliotecas necessárias para interagir com ele, e o servidor Web Nginx.

      Criando o banco de dados e o usuário PostgreSQL

      Vamos ir direto e criar um banco de dados e um usuário do banco de dados para nosso aplicativo Django.

      Por padrão, o Postgres usa um esquema de autenticação chamado de “autenticação por peer” para conexões locais. Basicamente, isso significa que se o nome de usuário do sistema operacional do usuário corresponder a um nome de usuário do Postgres válido, o usuário pode logar-se sem autenticação adicional.

      Durante a instalação do Postgres, um usuário do sistema operacional chamado postgres foi criado para corresponder ao usuário administrativo postgres do PostgreSQL. Precisamos usar este usuário para realizar tarefas administrativas. Podemos usar o sudo e passar o nome de usuário com a opção -u.

      Logue-se em uma sessão interativa do Postgres digitando:

      Você receberá um prompt do PostgreSQL onde podemos configurar nossos requisitos.

      Primeiramente, crie um banco de dados para seu projeto:

      • CREATE DATABASE myproject;

      Nota: Cada declaração do Postgres deve terminar com um ponto e vírgula, para garantir que seu comando termine com um, caso esteja passando por problemas.

      Em seguida, crie um usuário do banco de dados para nosso projeto. Certifique-se de selecionar uma senha segura:

      • CREATE USER myprojectuser WITH PASSWORD 'password';

      Depois disso, vamos modificar alguns dos parâmetros de conexão para o usuário que acabamos de criar. Isso irá acelerar as operações do banco de dados para que os valores corretos não tenham que ser consultados e definidos cada vez que uma conexão for estabelecida.

      Estamos definindo a codificação padrão para UTF-8, que é a que o Django espera. Também estamos definindo o esquema padrão de isolamento de transação para “ler confirmados”, que bloqueia a leitura de transações não confirmadas. Por fim, vamos definir o fuso horário. Por padrão, nossos projetos Django serão configurados para usar o UTC. Essas são todas recomendações do projeto Django em si:

      • ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
      • ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
      • ALTER ROLE myprojectuser SET timezone TO 'UTC';

      Agora, podemos dar ao nosso novo usuário acesso para administrar nosso novo banco de dados:

      • GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

      Quando tiver terminado, saia do prompt do PostgreSQL digitando:

      O Postgres agora está configurado para que o Django possa se conectar ao seu banco de dados e gerenciar suas informações.

      Criando um Ambiente Virtual Python para seu Projeto

      Agora que temos nosso banco de dados, podemos começar a preparar o resto dos nossos requisitos do projeto. Vamos instalar nossos requisitos do Python em um ambiente virtual para fácil gerenciamento.

      Para isso, precisamos primeiro acessar o comando virtualenv. Podemos instalar isso com o pip.

      Se estiver usando o Python 3, atualize o pip e instale o pacote digitando:

      • sudo -H pip3 install --upgrade pip
      • sudo -H pip3 install virtualenv

      Se estiver usando o Python 2, atualize o pip e instale o pacote digitando:

      • sudo -H pip install --upgrade pip
      • sudo -H pip install virtualenv

      Com o virtualenv instalado, podemos começar a formar nosso projeto. Crie um diretório onde possamos manter nossos arquivos do projeto e vá até ele:

      • mkdir ~/myprojectdir
      • cd ~/myprojectdir

      Dentro do diretório do projeto, crie um ambiente virtual do Python digitando:

      Isso criará um diretório chamado myprojectenv dentro do seu diretório myprojectdir. Lá dentro, ele instalará uma versão local do Python e uma versão local do pip. Podemos usar isso para instalar e configurar um ambiente Python isolado para nosso projeto.

      Antes de instalarmos os requisitos Python do nosso projeto, precisamos ativar o ambiente virtual. Você pode fazer isso digitando:

      • source myprojectenv/bin/activate

      Seu prompt deverá mudar para indicar que você agora está operando em um ambiente virtual Python. Eles se parecerão com isso: (myprojectenv)user@host:~/myprojectdir$.

      Com seu ambiente virtual ativo, instale o Django, Gunicorn, e o adaptador do PostgreSQL psycopg2 com a instância local do pip:

      Nota: Quando o ambiente virtual for ativado (quando seu prompt tiver (myprojectenv) antecedendo ele) use o pip ao invés do pip3, mesmo se estiver usando o Python 3. A cópia da ferramenta do ambiente virtual é sempre chamada de pip, independente da versão Python.

      • pip install django gunicorn psycopg2-binary

      Agora, você deve ter todos os softwares necessários para iniciar um projeto Django.

      Criando e Configurando um Projeto Django Novo

      Com nossos componentes Python instalados, podemos criar os arquivos do projeto Django em si.

      Criando o Projeto Django

      Como já temos um diretório de projeto, vamos dizer ao Django para instalar os arquivos aqui. Ele criará um diretório de segundo nível com o código real, o que é normal, e colocará um script de gerenciamento neste diretório. A chave para isso é que estamos definindo o diretório explicitamente ao invés de permitir que o Django tome decisões sobre nosso diretório atual:

      • django-admin.py startproject myproject ~/myprojectdir

      Neste ponto, seu diretório de projeto (~/myprojectdir no nosso caso) deve ter o seguinte conteúdo:

      • ~/myprojectdir/manage.py: um script de gerenciamento de projeto Django.
      • ~/myprojectdir/myproject/: o pacote do projeto Django. Isso deve conter os arquivos __init__.py, settings.py, urls.py e wsgi.py.
      • ~/myprojectdir/myprojectenv/: o diretório do ambiente virtual que criamos anteriormente.

      Ajustando as configurações do Projeto

      A primeira coisa que devemos fazer com nossos arquivos de projeto recém-criados é ajustar as configurações. Abra as configurações no seu editor de texto:

      • nano ~/myprojectdir/myproject/settings.py

      Comece locando a diretriz ALLOWED_HOSTS. Isso define uma lista dos endereços ou nomes de domínio do servidor que podem ser usados para se conectar à instância Django. Qualquer pedido recebido com um cabeçalho Host que não está nesta lista irá criar uma exceção. O Django exige que você defina isso para prevenir uma certa classe de vulnerabilidade de segurança.

      Dentro dos colchetes, liste os endereços IP ou nomes de domínio associados ao seu servidor do Django. Cada item deve ser listado entre aspas, com entradas separadas divididas por uma vírgula. Se você quiser pedidos para um domínio inteiro e quaisquer subdomínios, anteceda um período ao início da entrada. No trecho abaixo, há alguns exemplos comentados usados como demonstração:

      Nota: Certifique-se de incluir o localhost como uma das opções, uma vez que vamos estar passando conexões por um proxy através de uma instância local do Nginx.

      ~/myprojectdir/myproject/settings.py

      . . .
      # The simplest case: just add the domain name(s) and IP addresses of your Django server
      # ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
      # To respond to 'example.com' and any subdomains, start the domain with a dot
      # ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
      ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']
      

      Em seguida, encontre a seção que configura o acesso ao banco de dados. Ela começará com DATABASES. A configuração no arquivo é para um banco de dados SQLite. Já criamos um banco de dados PostgreSQL para nosso projeto, então precisamos ajustar as configurações.

      Altere as configurações com as informações do seu banco de dados PostgreSQL. Diremos ao Django para usar o adaptador psycopg2 que instalamos com o pip. Precisamos fornecer o nome do banco de dados, o nome de usuário do banco de dados, a senha do usuário do banco de dados, e então especificar que o banco de dados está localizado no computador local. Você pode deixar a configuração PORT como uma string vazia:

      ~/myprojectdir/myproject/settings.py

      . . .
      
      DATABASES = {
          'default': {
              'ENGINE': 'django.db.backends.postgresql_psycopg2',
              'NAME': 'myproject',
              'USER': 'myprojectuser',
              'PASSWORD': 'password',
              'HOST': 'localhost',
              'PORT': '',
          }
      }
      
      . . .
      

      Em seguida, vá até o final do arquivo e adicione uma configuração indicando onde os arquivos estáticos devem ser colocados. Isso é necessário para que o Nginx possa lidar com pedidos para esses itens. A seguinte linha diz ao Django para colocá-los em um diretório chamado static no diretório base do projeto:

      ~/myprojectdir/myproject/settings.py

      . . .
      
      STATIC_URL = '/static/'
      STATIC_ROOT = os.path.join(BASE_DIR, 'static/')
      

      Salve e feche o arquivo quando você terminar.

      Completando a Configuração Inicial do Projeto

      Agora, podemos migrar o esquema inicial do banco de dados para nosso banco de dados PostgreSQL usando o script de gerenciamento:

      • ~/myprojectdir/manage.py makemigrations
      • ~/myprojectdir/manage.py migrate

      Crie um usuário administrativo para o projeto digitando:

      • ~/myprojectdir/manage.py createsuperuser

      Você terá que selecionar um nome de usuário, fornecer um endereço e-mail, e escolher uma senha e confirmá-la.

      Podemos coletar todos o conteúdo estático no local do diretório que configuramos digitando:

      • ~/myprojectdir/manage.py collectstatic

      Você terá que confirmar a operação. Os arquivos estáticos serão então colocados em um diretório chamado static dentro do seu diretório.

      Se seguiu o guia de configuração inicial do servidor, você deve ter um firewall UFW protegendo seu servidor. Para testar o servidor de desenvolvimento, vamos ter que permitir o acesso à porta que iremos usar.

      Crie uma exceção para a porta 8000 digitando:

      Finalmente, você pode testar nosso projeto iniciando o servidor de desenvolvimento Django com este comando:

      • ~/myprojectdir/manage.py runserver 0.0.0.0:8000

      No seu navegador Web, visite o nome de domínio ou endereço IP do seu servidor seguido de :8000:

      http://server_domain_or_IP:8000
      

      Você deve ver a página inicial padrão do Django:

      Django index page

      Se adicionar /admin no final do URL na barra de endereço, você será solicitado a colocar o nome de usuário administrativo e a senha que criou com o comando createsuperuser:

      Django admin login

      Após a autenticação, você pode acessar a interface de admin do Django padrão:

      Django admin interface

      Quando você terminar de explorar, clique em CTRL-C na janela do terminal para fechar o servidor de desenvolvimento.

      Testando a capacidade do Gunicorn para servir o projeto

      A última coisa que queremos fazer antes de deixar nosso ambiente virtual é testar o Gunicorn para garantir que ele possa servir o aplicativo. Podemos fazer isso entrando no nosso diretório de projeto e usando o gunicorn para carregar o módulo WSGI do projeto:

      • cd ~/myprojectdir
      • gunicorn --bind 0.0.0.0:8000 myproject.wsgi

      Isso irá iniciar o Gunicorn na mesma interface em que o servidor de desenvolvimento do Django estava sendo executado. Você pode voltar e testar o aplicativo novamente.

      Nota: A interface admin não terá qualquer um dos estilos aplicados, uma vez que o Gunicorn não sabe como encontrar o conteúdo CSS estático responsável por isso.

      Passamos um módulo ao Gunicorn especificando o caminho de diretório relativo para o arquivo wsgi.py do Django, que é o ponto de entrada para nosso aplicativo, usando a sintaxe do módulo do Python. Dentro deste arquivo, é definida uma função chamada de application, que é usada para se comunicar com o aplicativo. Para aprender mais sobre a especificação WSGI, clique aqui.

      Quando terminar os testes, clique em CTRL-C na janela do terminal para interromper o Gunicorn.

      Agora, acabamos de configurar nosso aplicativo Django. Podemos sair do nosso ambiente virtual digitando:

      O indicador do ambiente virtual no seu prompt será removido.

      Criando arquivos de socket e de serviço systemd para o Gunicorn

      Nós testamos que o Gunicorn pode interagir com nosso aplicativo Django, mas devemos implementar uma maneira mais robusta de começar e parar o servidor do aplicativo. Para isso, vamos fazer arquivos de serviço e de socket do systemd.

      O socket Gunicorn será criado no boot e escutará as conexões. Quando ocorrer uma conexão, o systemd irá iniciar o processo Gunicorn automaticamente para lidar com a conexão.

      Comece criando e abrindo um arquivo de socket do systemd para o Gunicorn com privilégios sudo:

      • sudo nano /etc/systemd/system/gunicorn.socket

      Dentro, vamos criar uma seção [Unit] para descrever o socket, uma seção [Socket] para definir a localização do socket e uma seção [Install] para garantir que o socket seja criado no momento certo:

      /etc/systemd/system/gunicorn.socket

      [Unit]
      Description=gunicorn socket
      
      [Socket]
      ListenStream=/run/gunicorn.sock
      
      [Install]
      WantedBy=sockets.target
      

      Salve e feche o arquivo quando você terminar.

      Em seguida, crie e abra um arquivo de serviço do systemd para o Gunicorn com privilégios sudo no seu editor de texto. O nome do arquivo de serviço deve corresponder ao nome do arquivo do socket com exceção da extensão:

      • sudo nano /etc/systemd/system/gunicorn.service

      Comece 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. Uma vez que nosso serviço se baseia no socket do arquivo do socket, precisamos incluir uma diretriz Requires para indicar essa relação:

      /etc/systemd/system/gunicorn.service

      [Unit]
      Description=gunicorn daemon
      Requires=gunicorn.socket
      After=network.target
      

      Em seguida, vamos abrir a seção [Service]. Nós especificaremos o usuário e o grupo em que queremos que o processo seja executado. Vamos dar à nossa conta de usuário regular a posse do processo uma vez que ela possui todos os arquivos relevantes. Vamos atribuir a posse do grupo ao grupo www-data para que o Nginx possa se comunicar facilmente com o Gunicorn.

      Então, vamos mapear o diretório em funcionamento e especificar o comando a ser usado para iniciar o serviço. Neste caso, precisaremos especificar o caminho completo para o executável do Gunicorn, que está instalado dentro do nosso ambiente virtual. Vamos ligar o processo ao socket Unix que criamos dentro do diretório /run para que o processo possa se comunicar com o Nginx. Nós registramos todos os dados na saída padrão para que o processo journald possa recolher os registros do Gunicorn. Também podemos especificar quaisquer ajustes opcionais no Gunicorn aqui. Por exemplo, especificamos 3 processos de trabalho neste caso:

      /etc/systemd/system/gunicorn.service

      [Unit]
      Description=gunicorn daemon
      Requires=gunicorn.socket
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myprojectdir
      ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn 
                --access-logfile - 
                --workers 3 
                --bind unix:/run/gunicorn.sock 
                myproject.wsgi:application
      

      Finalmente, adicionaremos uma seção [Install]. Isso dirá ao systemd o que ligar a este serviço se nós habilitarmos que ele seja iniciado no boot. Queremos que este serviço comece quando o sistema regular de vários usuários estiver funcionando:

      /etc/systemd/system/gunicorn.service

      [Unit]
      Description=gunicorn daemon
      Requires=gunicorn.socket
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      WorkingDirectory=/home/sammy/myprojectdir
      ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn 
                --access-logfile - 
                --workers 3 
                --bind unix:/run/gunicorn.sock 
                myproject.wsgi:application
      
      [Install]
      WantedBy=multi-user.target
      

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

      Agora, podemos iniciar e habilitar o socket do Gunicorn. Isso criará o arquivo do socket em /run/gunicorn.sock agora e no boot. Quando uma conexão for feita no socket, o systemd irá iniciar o gunicorn.service automaticamente para lidar com ela:

      • sudo systemctl start gunicorn.socket
      • sudo systemctl enable gunicorn.socket

      Podemos confirmar que a operação foi bem sucedida verificando o arquivo do socket.

      Verificando o arquivo de socket do Gunicorn

      Verifique o status do processo para descobrir se ele foi capaz de iniciar:

      • sudo systemctl status gunicorn.socket

      Em seguida, verifique a existência do arquivo gunicorn.sock dentro do diretório /run:

      Output

      /run/gunicorn.sock: socket

      Se o comando systemctl status indicou que um erro ocorreu ou se você não encontrou o arquivo gunicorn.sock no diretório, é uma indicação de que o socket do Gunicorn não foi criado corretamente. Verifique os registros do socket do Gunicorn digitando:

      • sudo journalctl -u gunicorn.socket

      Veja novamente o seu arquivo /etc/systemd/system/gunicorn.socket para corrigir qualquer problema antes de continuar.

      Testando a ativação do socket

      Se tiver iniciado apenas a unidade gunicorn.socket, o gunicorn.service ainda não estará ativo, já que o socket ainda não recebeu nenhuma conexão. Você pode verificar isso digitando:

      • sudo systemctl status gunicorn

      Output

      ● gunicorn.service - gunicorn daemon Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled) Active: inactive (dead)

      Para testar o mecanismo de ativação do socket, podemos enviar uma conexão para o socket através do curl digitando:

      • curl --unix-socket /run/gunicorn.sock localhost

      Você deve ver a saída HTML do seu aplicativo no terminal. Isso indica que o Gunicorn foi iniciado e conseguiu servir seu aplicativo Django. Você pode verificar se o serviço Gunicorn está funcionando digitando:

      • sudo systemctl status gunicorn

      Output

      ● gunicorn.service - gunicorn daemon Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2018-07-09 20:00:40 UTC; 4s ago Main PID: 1157 (gunicorn) Tasks: 4 (limit: 1153) CGroup: /system.slice/gunicorn.service ├─1157 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application ├─1178 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application ├─1180 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application └─1181 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application Jul 09 20:00:40 django1 systemd[1]: Started gunicorn daemon. Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1157] [INFO] Starting gunicorn 19.9.0 Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1157] [INFO] Listening at: unix:/run/gunicorn.sock (1157) Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1157] [INFO] Using worker: sync Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1178] [INFO] Booting worker with pid: 1178 Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1180] [INFO] Booting worker with pid: 1180 Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1181] [INFO] Booting worker with pid: 1181 Jul 09 20:00:41 django1 gunicorn[1157]: - - [09/Jul/2018:20:00:41 +0000] "GET / HTTP/1.1" 200 16348 "-" "curl/7.58.0"

      Se o resultado do curl ou o resultado do systemctl status indicar que um problema ocorreu, verifique os registros para mais detalhes:

      • sudo journalctl -u gunicorn

      Verifique seu arquivo /etc/systemd/gunicorn.service quanto a problemas. Se fizer alterações no arquivo /etc/systemd/system/gunicorn.service, recarregue o daemon para reler a definição do serviço e reinicie o processo do Gunicorn digitando:

      • sudo systemctl daemon-reload
      • sudo systemctl restart gunicorn

      Certifique-se de que você tenha resolvido os problemas acima antes de continuar.

      Configurar o Nginx para passagem de proxy para o Gunicorn

      Agora que o Gunicorn está configurado, precisamos configurar o Nginx para passar o tráfego para o processo.

      Inicie criando e abrindo um novo bloco de servidor no diretório sites-available do Nginx:

      • sudo nano /etc/nginx/sites-available/myproject

      Lá dentro, abra um novo bloco de servidor. Vamos começar especificando que este bloco deve escutar a porta normal 80 e que ele deve responder ao nome de domínio ou endereço IP do nosso servidor:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name server_domain_or_IP;
      }
      

      Em seguida, vamos dizer ao Nginx para ignorar todos os problemas ao encontrar um favicon. Também vamos dizer a ele onde encontrar os ativos estáticos que coletamos no nosso diretório ~/myprojectdir/static Todos esses arquivos têm um prefixo URI padrão “/static”, então podemos criar um bloco de localização para corresponder a esses pedidos:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name server_domain_or_IP;
      
          location = /favicon.ico { access_log off; log_not_found off; }
          location /static/ {
              root /home/sammy/myprojectdir;
          }
      }
      

      Por fim, vamos criar um bloco location / {} para corresponder a todos os outros pedidos. Dentro deste local, vamos incluir o arquivo proxy_params padrão incluído na instalação do Nginx e então vamos passar o tráfego diretamente para o socket do Gunicorn:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name server_domain_or_IP;
      
          location = /favicon.ico { access_log off; log_not_found off; }
          location /static/ {
              root /home/sammy/myprojectdir;
          }
      
          location / {
              include proxy_params;
              proxy_pass http://unix:/run/gunicorn.sock;
          }
      }
      

      Salve e feche o arquivo quando você terminar. Agora, podemos habilitar o arquivo ligando-o ao diretório sites-enabled:

      • sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

      Teste sua configuração do Nginx para erros de sintaxe digitando:

      Se nenhum erro for reportado, vá em frente e reinicie o Nginx digitando:

      • sudo systemctl restart nginx

      Por fim, precisamos abrir nosso firewall para o tráfego normal na porta 80. Como já não precisamos mais acessar o servidor de desenvolvimento, podemos remover também a regra para abrir a porta 8000:

      • sudo ufw delete allow 8000
      • sudo ufw allow 'Nginx Full'

      Agora, você deve conseguir ir ao domínio ou endereço IP do seu servidor para ver seu aplicativo.

      Nota: Depois de configurar o Nginx, o próximo passo deve ser proteger o tráfego para o servidor usando SSL/TLS. Isso é importante, pois sem ele, todas as informações, incluindo senhas são enviadas para a rede em texto simples.

      Se você tiver um nome de domínio, a maneira mais fácil de obter um certificado SSL para proteger seu tráfego é usando o Let’s Encrypt. Siga este guia para configurar o Let’s Encrypt com o Nginx no Ubuntu 18.04. Siga o procedimento usando o bloco de servidor do Nginx que criamos neste guia.

      Se você não tiver um nome de domínio, ainda é possível proteger seu site como teste e aprendizado com um certificado SSL autoassinado. Novamente, siga o procedimento usando o bloco de servidor do Nginx que criamos neste tutorial.

      Solucionando problemas do Nginx e do Gunicorn

      Se este último passo não mostrar o seu aplicativo, será necessário resolver o problema da sua instalação.

      Nginx está mostrando a página padrão ao invés do aplicativo Django

      Se o Nginx mostra a página padrão em vez de transferir via proxy para seu aplicativo, isso geralmente significa que você precisa ajustar o server_name dentro do arquivo /etc/nginx/sites-available/myproject para apontar ao endereço IP ou nome de domínio do seu servidor.

      O Nginx usa o server_name para determinar qual bloco de servidor usar para responder aos pedidos. Se você estiver vendo a página padrão do Nginx, é um sinal de que o Nginx não conseguiu corresponder ao pedido a um bloco de servidor explicitamente, então ele está recorrendo ao bloco padrão definido em /etc/nginx/sites-available/default.

      O server_name no bloco de servidor do seu projeto deve ser mais específico do que aquele no bloco de servidor padrão para ser selecionado.

      Nginx está exibindo um erro 502 Bad Gateway ao invés do aplicativo Django

      Um erro 502 indica que o Nginx é incapaz de atuar como proxy para o pedido com sucesso. Uma ampla gama de problemas de configuração se expressam com um erro 502, então é necessário mais informações para resolver o problema corretamente.

      O primeiro lugar para procurar mais informações é nos registros de erro do Nginx. Geralmente, isso irá dizer-lhe quais condições causaram problemas durante o evento de proxy. Vá até os registros de erro do Nginx, digitando:

      • sudo tail -F /var/log/nginx/error.log

      Agora, faça outro pedido no seu navegador para gerar um novo erro (tente atualizar a página). Você deve ver uma nova mensagem de erro escrita no registro. Se olhar para a mensagem, ela deve ajudar você a estreitar o problema.

      Pode ser que você veja algumas dessas mensagens:

      connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)

      Isso indica que o Nginx foi incapaz de encontrar o arquivo gunicorn.sock no local indicado. Você deve comparar a localização do proxy_pass definida dentro do arquivo /etc/nginx/sites-available/myproject com a localização real do arquivo gunicorn.sock gerado pela unidade systemd gunicorn.socket.

      Se você não puder encontrar um arquivo gunicorn.sock dentro do diretório /run, isso signica geralmente que o arquivo de socket do systemd foi incapaz de criá-lo. Volte para a seção sobre checar o arquivo de socket do Gunicorn para seguir as etapas de solução de problemas para o Gunicorn.

      connect() to unix:/run/gunicorn.sock failed (13: Permission denied)

      Isso indica que o Nginx foi incapaz de se conectar ao socket do Gunicorn devido a problemas de permissão. Isso pode acontecer quando o procedimento é seguido usando o usuário raiz ao invés de um usuário sudo. Embora o systemd seja capaz de criar o arquivo de socket do Gunicorn, o Nginx é incapaz de acessá-lo.

      Isso pode acontecer se houver permissões limitadas em qualquer ponto entre o diretório raiz (/) e o arquivo gunicorn.sock. Podemos ver as permissões e os valores de posse do arquivo de socket e cada um dos seus diretórios pais passando o caminho absoluto para nosso arquivo de socket pelo comando namei:

      • namei -l /run/gunicorn.sock

      Output

      f: /run/gunicorn.sock drwxr-xr-x root root / drwxr-xr-x root root run srw-rw-rw- root root gunicorn.sock

      O resultado mostra as permissões de cada um dos componentes do diretório. Ao olhar para as permissões (primeira coluna), proprietário (segunda coluna) e proprietário do grupo (terceiro coluna), podemos descobrir qual tipo de acesso é permitido ao arquivo de socket.

      No exemplo acima, o arquivo de socket e cada um dos diretórios que levam ao arquivo de socket têm permissões de leitura e execução global (a coluna de permissões para os diretórios termina com r-x ao invés de ---). O processo Nginx deve ser capaz de acessar o socket com sucesso.

      Se qualquer um dos diretórios que levam ao socket não tiverem permissão de leitura e execução global, o Nginx não poderá acessar o socket sem permitir permissões de leitura e execução globais ou garantir que o proprietário do grupo seja dado a um grupo do qual o Nginx faça parte.

      Django está exibindo: “could not connect to server: Connection refused”

      Uma mensagem que você pode ver do Django ao tentar acessar partes do aplicativo no navegador Web é:

      OperationalError at /admin/login/
      could not connect to server: Connection refused
          Is the server running on host "localhost" (127.0.0.1) and accepting
          TCP/IP connections on port 5432?
      

      Isso indica que o Django é incapaz de se conectar ao banco de dados do Postgres. Certifique-se de que a instância do Postgres está sendo executada digitando:

      • sudo systemctl status postgresql

      Se não estiver, você pode iniciá-la e habilitá-la para iniciar automaticamente no boot (se ela ainda não estiver configurada para fazer isso) digitando:

      • sudo systemctl start postgresql
      • sudo systemctl enable postgresql

      Se ainda estiver tendo problemas, certifique-se de que as configurações do banco de dados definidas no arquivo ~/myprojectdir/myproject/settings.py estão corretas.

      Soluções de problemas adicionais

      Para soluções de problemas adicionais, os registros podem ajudar a reduzir os problemas de raiz. Verifique cada um deles individualmente e procure mensagens que indiquem áreas de problemas.

      Os registros a seguir podem ser úteis:

      • Verifique os registros de processo do Nginx digitando: sudo journalctl -u nginx
      • Verifique os registros de acesso do Nginx digitando: sudo less /var/log/nginx/access.log
      • Verifique os registros de erro do Nginx digitando: sudo less /var/log/nginx/error.log
      • Verifique os registros do aplicativo Gunicorn digitando: sudo journalctl -u gunicorn
      • Verifique os registros do socket do Gunicorn digitando: sudo journalctl -u gunicorn.socket

      Conforme atualiza sua configuração ou aplicativo, provavelmente precisará reiniciar os processos para ajustá-los às suas alterações.

      Se atualizar seu aplicativo Django, você pode reiniciar o processo Gunicorn para aplicar as alterações, digitando:

      • sudo systemctl restart gunicorn

      Se alterar o socket ou arquivos de serviço do Gunicorn, recarregue o daemon e reinicie o processo, digitando:

      • sudo systemctl daemon-reload
      • sudo systemctl restart gunicorn.socket gunicorn.service

      Se alterar a configuração do bloco de servidor do Nginx, teste a configuração e então o Nginx digitando:

      • sudo nginx -t && sudo systemctl restart nginx

      Estes comandos são úteis para aplicar as alterações conforme você ajusta sua configuração.

      Conclusão

      Neste guia, configuramos um projeto Django em seu próprio ambiente virtual. Configuramos o Gunicorn para traduzir pedidos de clientes para que o Django possa lidar com eles. Depois disso, configuramos o Nginx para agir como um proxy reverso para lidar com conexões de clientes e servir o projeto correto, dependendo da solicitação do cliente.

      O Django torna a criação de projetos e aplicativos simples, fornecendo muitas peças comuns, permitindo que você se concentre nos elementos únicos. Ao utilizar a cadeia de ferramentas geral descrita neste artigo, você pode servir facilmente os aplicativos que criar a partir de um único servidor.



      Source link

      Cómo preparar aplicaciones de Flask con Gunicorn y Nginx en Ubuntu 18.04


      Introducción

      A través de esta guía, creará una aplicación de Python utilizando el microframework de Flask en Ubuntu 18.04. En la mayor parte de este artículo se abordarán la configuración del servidor de la aplicación Gunicorn y la forma de iniciar la aplicación y configurar Nginx para que funcione como un proxy inverso de cliente.

      Requisitos previos

      Antes de comenzar con esta guía, deberá contar con lo siguiente:

      • Un servidor con Ubuntu 18.04 instalado y un usuario no root con privilegios sudo. Siga nuestra guía de configuración inicial para servidores a modo de orientación.
      • Nginx instalado conforme a los pasos 1 y 2 de Cómo instalar Nginx en Ubuntu 18.04.
      • Un nombre de dominio configurado para que apunte a su servidor. Puede adquirir uno en Namecheap u obtener uno de forma gratuita en Freenom. Puede aprender a apuntar dominios a DigitalOcean siguiendo la documentación sobre dominios y DNS pertinente. Asegúrese de crear los siguientes registros DNS:

        • Un registro A con your_domain orientado a la dirección IP pública de su servidor.
        • Un registro A con www.your_domain orientado a la dirección IP pública de su servidor.
      • Conocimientos sobre la especificación WSGI, que el servidor de Gunicorn usará para comunicarse con su aplicación Flask. En esta discusión se abarca WSGI de forma más deallada.

      Paso 1: Instalar los componentes desde los repositorios de Ubuntu

      Nuestro primer paso será instalar todo lo que necesitamos desde los repositorios de Ubuntu. Esto incluye pip, el administrador de paquetes de Python, que gestionará nuestros componentes de Python. También obtendremos los archivos de desarrollo de Python necesarios para crear algunos de los componentes de Gunicorn.

      Primero, actualizaremos el índice de paquetes locales e instalaremos los paquetes que nos permitirán crear nuestro entorno de Python. Entre ellos está phyton3-pip, junto con paquetes y herramientas de desarrollo adicionales que se necesitan para un entorno de programación sólido:

      • sudo apt update
      • sudo apt install python3-pip python3-dev build-essential libssl-dev libffi-dev python3-setuptools

      Una vez implementados estos paquetes, crearemos un entorno virtual para nuestro proyecto.

      Paso 2: Crear un entorno virtual de Python

      A continuación, configuraremos un entorno virtual para aislar nuestra aplicación de Flask de los otros archivos de Python del sistema.

      Comience instalando el paquete phyton3-venv, que instalará el módulo venv:

      • sudo apt install python3-venv

      Luego, crearemos un directorio principal para nuestro proyecto de Flask. Después de crearlo, posiciónese en él:

      • mkdir ~/myproject
      • cd ~/myproject

      Cree un entorno virtual para almacenar los requisitos de Python de su proyecto de Flask escribiendo lo siguiente:

      • python3.6 -m venv myprojectenv

      Con esto se instalará una copia local de Python y pip en un directorio llamado myprojectenv dentro del directorio de su proyecto.

      Antes de instalar aplicaciones dentro del entorno virtual, deberá activarlo. Hágalo escribiendo lo siguiente:

      • source myprojectenv/bin/activate

      Su mensaje cambiará para indicar que ahora realiza operaciones dentro del entorno virtual. Se parecerá a esto: (myprojectenv)user@host:~/myproject$.

      Paso 3: Configurar una aplicación de Flask

      Ahora que se encuentra en su entorno virtual, podrá instalar Flask y Gunicorn y comenzar a diseñar su aplicación.

      Primero, instalaremos wheel con la instancia local de pip para asegurarnos de que nuestros paquetes se instalen aunque falten archivos de wheel:

      Nota: Independientemente de la versión de Phyton que use, cuando se active el entorno virtual deberá utilizar el comando pip (no pip3).

      A continuación, instalaremos Flask y Gunicorn:

      • pip install gunicorn flask

      Creación de una aplicación de ejemplo

      Ahora que dispone de Flask, puede crear una aplicación sencilla. Flask es un microframework. No cuenta con muchas de las herramientas que podrían incluirse en frameworks con más características y existe sobre todo como un módulo que puede importar a sus proyectos para que pueda inicializar una aplicación web.

      Aunque la complejidad podría ser mayor, crearemos nuestra aplicación de Flask en un único archivo, llamado myproject.py:

      • nano ~/myproject/myproject.py

      El código de aplicación residirá en este archivo. Importará Flask y creará una instancia de un objeto de Flask. Puede utilizarlo para definir las funciones que deberían ejecutarse cuando se solicita una ruta específica:

      ~/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')
      

      Esto define básicamente el contenido que se presentará al acceder al dominio root. Guarde y cierre el archivo cuando termine.

      Si siguió la guía de configuración inicial para servidores, debería tener activado un firewall UFW. Para probar la aplicación, debe permitir el acceso al puerto 5000:

      Ahora podrá probar su aplicación de Flask escribiendo lo siguiente:

      Verá un resultado como el siguiente, en el cual se incluirá una advertencia útil que le recordará no utilizar esta configuración de servidor en la producción:

      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)

      Agregue :5000 al final de la dirección IP de su servidor en su navegador web y visítela:

      http://your_server_ip:5000
      

      Debería ver algo como esto:

      Aplicación de ejemplo de Flask

      Cuanto termine, pulse CTRL-C en la ventana de su terminal para detener el servidor de desarrollo Flask.

      Creación de un punto de entrada de WSGI

      A continuación, crearemos un archivo que servirá como punto de entrada para nuestra aplicación. Esto indicará a nuestro servidor de Gunicorn cómo interactuar con la aplicación.

      Llamemos al archivo wsgi.py:

      En él, importaremos la instancia de Flask desde nuestra aplicación y luego la ejecutaremos:

      ~/myproject/wsgi.py

      from myproject import app
      
      if __name__ == "__main__":
          app.run()
      

      Guarde y cierre el archivo cuando termine.

      Paso 4: Configurar Gunicorn

      Su aplicación quedará, así, escrita con un punto de entrada establecido. Ahora, podemos continuar con la configuración de Gunicorn.

      Antes de continuar, debe comprobar que Gunicorn pueda proveer correctamente la aplicación.

      Podemos hacerlo con solo pasarle el nombre de nuestro punto de entrada. Se construye como el nombre del módulo (menos la extensión .py) más el nombre del elemento invocable dentro de la aplicación. En nuestro caso, es wsgi:app.

      También especificaremos la interfaz y el puerto que se vinculará para que la aplicación se inicie en una interfaz disponible de forma pública:

      • cd ~/myproject
      • gunicorn --bind 0.0.0.0:5000 wsgi:app

      Debería ver un resultado como el siguiente:

      Output

      [2018-07-13 19:35:13 +0000] [28217] [INFO] Starting gunicorn 19.9.0 [2018-07-13 19:35:13 +0000] [28217] [INFO] Listening at: http://0.0.0.0:5000 (28217) [2018-07-13 19:35:13 +0000] [28217] [INFO] Using worker: sync [2018-07-13 19:35:13 +0000] [28220] [INFO] Booting worker with pid: 28220

      Visite de nuevo la dirección IP de su servidor con :5000 agregado al final en su navegador web:

      http://your_server_ip:5000
      

      Debería ver el resultado de su aplicación:

      Aplicación de ejemplo de Flask

      Cuando confirme que funciona correctamente, pulse CTRL-C en la ventana de su terminal.

      Ya completamos las tareas de nuestro entorno virtual, por lo que podemos desactivarlo:

      Ahora todos los comandos de Python usarán de nuevo el entorno de Phyton del sistema.

      A continuación, crearemos el archivo de unidad de servicio systemd. Crear un archivo de unidad systemd permitirá que el sistema init de Ubuntu inicie automáticamente Gunicorn y haga funcionar la aplicación de Flask cuando el servidor se cargue.

      Cree un archivo de unidad terminado en .service dentro del directorio /etc/systemd/system para empezar:

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

      En su interior, empezaremos con la sección [Unit] que se usa para especificar metadatos y dependencias. Aquí agregaremos una descripción de nuestro servicio e indicaremos al sistema init que lo inicie solo tras haber alcanzado el objetivo de red:

      /etc/systemd/system/myproject.service

      [Unit]
      Description=Gunicorn instance to serve myproject
      After=network.target
      

      A continuación, abriremos la sección [Service]. Esto especificará el usuario y el grupo con los cuales deseamos que se ejecute el proceso. Otorgaremos la propiedad del proceso a nuestra cuenta de usuario normal, ya que tiene la propiedad de todos los archivos pertinentes. También otorgaremos la propiedad del grupo al grupo www-data para que Nginx pueda comunicarse fácilmente con los procesos de Gunicorn. No se olvide de sustituir el nombre de usuario por el suyo:

      /etc/systemd/system/myproject.service

      [Unit]
      Description=Gunicorn instance to serve myproject
      After=network.target
      
      [Service]
      User=sammy
      Group=www-data
      

      A continuación, planearemos los detalles del directorio de trabajo y estableceremos el entorno variable PATH para que el sistema init sepa que los ejecutables para el proceso están ubicados dentro de nuestro entorno virtual. También especificaremos el comando para iniciar el servicio. Este comando hará lo siguiente:

      • Iniciar 3 procesos de trabajadores (debería, no obstante, ajustar esto si es necesario)
      • Crear un archivo de socket de Unix, myproject<^>.sock, dentro del directorio de nuestro proyecto y establecer un vínculo con él. Estableceremos un valor sin máscara de 007 para que se cree el archivo de socket, se proporcione acceso al propietario y, al mismo tiempo, se restrinjan otros accesos.
      • Especifique el nombre del archivo del punto de entrada de WSGI junto con el elemento invocable de Python dentro de ese archivo (wsgi:app).

      Systemd necesita que le proporcionemos la ruta completa al ejecutable de Gunicorn, que se instala dentro de nuestro entorno virtual.

      No se olvide de sustituir el nombre del usuario y las rutas del proyecto por su propia información:

      /etc/systemd/system/myproject.service

      [Unit]
      Description=Gunicorn 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/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app
      

      Por último, vamos a añadiremos una sección [Install]. Esto indicará a systemd a qué deberá vincular este servicio si lo habilitamos para que se cargue en el inicio. Queremos que este servicio se inicie cuando el sistema multiusuario normal esté en funcionamiento:

      /etc/systemd/system/myproject.service

      [Unit]
      Description=Gunicorn 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/gunicorn --workers 3 --bind unix:myproject.sock -m 007 wsgi:app
      
      [Install]
      WantedBy=multi-user.target
      

      Con eso, nuestro archivo de servicio de systemd quedará completo. Guárdelo y ciérrelo ahora.

      Ya podemos iniciar el servicio Gunicorn que creamos y activarlo para que se cargue en el inicio:

      • sudo systemctl start myproject
      • sudo systemctl enable myproject

      Comprobemos el estado:

      • sudo systemctl status myproject

      Debería ver el siguiente resultado:

      Output

      ● myproject.service - Gunicorn 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: 28232 (gunicorn) Tasks: 4 (limit: 1153) CGroup: /system.slice/myproject.service ├─28232 /home/sammy/myproject/myprojectenv/bin/python3.6 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 ├─28250 /home/sammy/myproject/myprojectenv/bin/python3.6 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 ├─28251 /home/sammy/myproject/myprojectenv/bin/python3.6 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007 └─28252 /home/sammy/myproject/myprojectenv/bin/python3.6 /home/sammy/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:myproject.sock -m 007

      Si detecta errores, asegúrese de resolverlos antes de continuar con el tutorial.

      Paso 5: Configurar Nginx para solicitudes de proxy

      Ahora, nuestro servidor de aplicación Gunicorn debería estar funcionando, esperando solicitudes en el archivo de socket del directorio del proyecto. Configuraremos Nginx para que transmita las solicitudes web al socket haciendo algunas pequeñas adiciones a su archivo de configuración.

      Comencemos creando un nuevo archivo de configuración de bloque de servidor en el directorio sites-available de Nginx. Lo llamaremos myproject para que se adecue al resto de esta guía:

      • sudo nano /etc/nginx/sites-available/myproject

      Abra un bloque de servidor e indique a Nginx que escuche en el puerto predeterminado 80. También le indicaremos que utilice este bloque para solicitudes para el nombre de dominio de nuestro servidor:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name your_domain www.your_domain;
      }
      

      A continuación, agregaremos un bloque de ubicación que coincida con cada solicitud. Dentro de este bloque, incluiremos el archivo proxy_params que especifica algunos parámetros de proxy generales que deben configurarse. Luego, pasaremos las solicitudes al socket que definimos usando la directiva proxy_pass:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name your_domain www.your_domain;
      
          location / {
              include proxy_params;
              proxy_pass http://unix:/home/sammy/myproject/myproject.sock;
          }
      }
      

      Guarde y cierre el archivo al finalizar.

      Para habilitar la configuración del bloque de servidor de Nginx que acaba de crear, vincule el archivo al directorio sites-enabled​​​:

      • sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

      Con el archivo en ese directorio, puede realizar una verificación en busca de errores de sintaxis:

      Si no se indican problemas, reinicie el proceso de Nginx para que lea la nueva configuración:

      • sudo systemctl restart nginx

      Por último, ajustaremos el firewall de nuevo. Ya no necesitamos acceso a través del puerto 5000, por lo que podemos eliminar esta regla. Luego, podemos permitir el acceso completo al servidor de Nginx:

      • sudo ufw delete allow 5000
      • sudo ufw allow 'Nginx Full'

      Ahora debería poder visitar el nombre de dominio de su servidor en su navegador web:

      http://your_domain
      

      Debería ver el resultado de su aplicación:

      Aplicación de ejemplo de Flask

      Si encuentra algún error, intente verificar lo siguiente:

      • sudo less /var/log/nginx/error.log: verifica los registros de error de Nginx.
      • sudo less /var/log/nginx/access.log: verifica los registros de acceso de Nginx.
      • sudo journalctl -u nginx: verifica los registros de proceso de Nginx.
      • sudo journalctl -u myproject: verifica los registros de Gunicorn de su aplicación de Flask.

      Paso 6: Proteger la aplicación

      Para asegurarse de que el tráfico hacia su servidor siga siendo seguro, obtendremos un certificado SSL para su dominio. Existen varias formas de hacerlo. Entre otras, obtener un certificado gratuito de Let’s Encrypt, generar un certificado autofirmado o adquirir uno de otro proveedor y configurar Nginx para que lo utilice siguiendo los pasos 2 a 6 de Cómo crear un certificado SSL autofirmado para Nginx en Ubuntu 18.04. Por motivos de conveniencia, elegiremos la primera opción.

      Primero, agregue el repositorio de Certbot de Ubuntu:

      • sudo add-apt-repository ppa:certbot/certbot

      Deberá seleccionar ENTER para aceptar.

      Instale el paquete de Nginx de Certbot con apt:

      • sudo apt install python-certbot-nginx

      Certbot ofrece varias alternativas para obtener certificados SSL a través de complementos. El complemento de Nginx se encargará de reconfigurar Nginx y volver a cargar la configuración cuando sea necesario. Para utilizar este complemento, escriba lo siguiente:

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

      Con esto, se ejecuta certbot con el complemento --nginx usando -d para especificar los nombres para los cuales deseamos que el certificado tenga validez.

      Si es la primera vez que ejecuta certbot, se le solicitará introducir una dirección de correo electrónico y aceptar las condiciones de servicio. A continuación, certbot se comunicará con el servidor de Let’s Encrypt y, luego, realizará una comprobación para verificar que usted controle el dominio para el que solicita un certificado.

      Si la comprobación se realiza correctamente, certbot le preguntará cómo desea configurar sus ajustes 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):

      Seleccione su elección y luego ENTER. La configuración se actualizará y Nginx se volverá a cargar para aplicar los ajustes nuevos. certbot concluirá con un mensaje que le indicará que el proceso tuvo éxito e indicará la ubicación de almacenamiento de sus certificados:

      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

      Si siguió las instrucciones de instalación de Nginx en los requisitos previos, ya no necesitará la asignación de perfil HTTP redundante:

      • sudo ufw delete allow 'Nginx HTTP'

      Para verificar la configuración, acceda una vez más a su dominio utilizando https://:

      https://your_domain
      

      Una vez más, debería ver el resultado de su aplicación junto con el indicador de seguridad de su navegador, el cual debería indicar que el sitio está protegido.

      Conclusión

      A través de esta guía, creó y aseguró una aplicación de Flask simple dentro de un entorno virtual de Python. Creó un punto de entrada de WSGI para que cualquier servidor de aplicación con capacidad para WSGI pueda interactuar con él y configuró el servidor de aplicación de Gunicorn para proporcionar esta función. Luego, creó un archivo de servicio systemd para iniciar automáticamente el servidor de aplicación en el inicio. También creó un bloque de servidor de Nginx que transmite el tráfico de clientes web al servidor de la aplicación, y reenvía solicitudes externas, y protegió el tráfico hacia su servidor con Let’s Encrypt.

      Flask es un framework muy sencillo, pero extremadamente flexible, diseñado para proporcionar funcionalidad a sus aplicaciones sin ser demasiado restrictivo respecto de la estructura y del diseño. Puede utilizar la pila general descrita en esta guía para hacer funcionar las aplicaciones de Flask que diseñe.



      Source link