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.
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.
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.
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:
- sudo -u postgres psql
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:
- \q
O Postgres agora está configurado para que o Django possa se conectar ao seu banco de dados e gerenciar suas informações.
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:
- virtualenv myprojectenv
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.
Com nossos componentes Python instalados, podemos criar os arquivos do projeto Django em si.
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.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.
. . .
# 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:
. . .
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:
. . .
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')
Salve e feche o arquivo quando você terminar.
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:
- sudo ufw allow 8000
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:
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
:
Após a autenticação, você pode acessar a interface de admin do Django padrão:
Quando você terminar de explorar, clique em CTRL-C na janela do terminal para fechar o servidor de desenvolvimento.
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:
- deactivate
O indicador do ambiente virtual no seu prompt será removido.
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:
[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:
[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:
[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:
[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.
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
:
- file /run/gunicorn.sock
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.
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.
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:
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:
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:
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:
- sudo nginx -t
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.
Se este último passo não mostrar o seu aplicativo, será necessário resolver o problema da sua instalação.
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.
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
Outputf: /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.
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.
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:
sudo journalctl -u nginx
sudo less /var/log/nginx/access.log
sudo less /var/log/nginx/error.log
sudo journalctl -u gunicorn
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.
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.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
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!
SSH doesn’t work anymore after I ran the command “sudo ufw allow ‘Nginx Full’”. Any clue of what could it be?
Muito bom Justin, estou rodando meu site(www.cnpj.tech) com a configuração fornecida nesse tutorial.
Funcionou perfeitamente, gostaria de apenas acrescentar uma dica, tive uma certa dificuldade com isso, o gunicorn não identifica as alterações automaticamente feitas nos arquivos .py, para tal é necessário o restart do serviço, pra resolver isso no arquivo gunicorn.service é necessário adicionar --reload, segue o exemplo abaixo.
/etc/systemd/system/gunicorn.service … [Service] User=sammy Group=www-data WorkingDirectory=/home/sammy/myprojectdir ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn
–access-logfile -
–workers 3
*–reload * –bind unix:/run/gunicorn.sock
…
Muito obrigado ai
Muito obrigado, Justin Ellingwood Seu artigo está perfeito.