BLOG | NGINX

Conferência NGINX 2018: Configurando a unidade NGINX para aplicativos de produção - Servindo um projeto Django

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Amanda Bockoven
Amanda Bockoven
Publicado em 28 de novembro de 2018

O NGINX Unit é um servidor de aplicativos totalmente dinâmico que pode atender a vários idiomas, bem como a várias versões de cada idioma. É dinâmico no sentido de que você usa a API RESTful JSON para fazer alterações em sua configuração na memória, sem interrupção do serviço ou recarregamentos de configuração.

Na minha apresentação na NGINX Conf 2018 em outubro, mostrei como configurar um novo aplicativo em um ambiente de produção existente. Especificamente, com o WordPress rodando em PHP, implantei um aplicativo Python que usa o framework Django. Também mostrei como você pode carregar a configuração de um arquivo e conforme especificado com um argumento para uma chamada de API.

Este blog inclui todos os comandos e códigos de configuração que usei na demonstração, para facilitar a adaptação à sua própria implantação.

Pré-requisitos

Para a demonstração na NGINX Conf, instalei o seguinte software:

  • Ubuntu 16.04
  • NGINX Plus, mas você pode usar o NGINX Open Source, exceto conforme indicado
  • Unidade NGINX com todos os módulos de idioma instalados
  • Python 3
  • Django (não configurado – é disso que trata a demonstração e este blog)
  • privilégio de root , ou acesso equivalente via sudo (que usamos quando necessário)

Eu também tinha PHP e WordPress instalados como aplicativos existentes.

Criando o Projeto Django

  1. Mude para o diretório onde estamos criando nosso projeto Django:

    $ cd /var/www/
  2. Use o comando django-admin startproject para inicializar o novo projeto. Estamos chamando-o de djapp .

    $ sudo django-admin startproject djapp
  3. Mude para o diretório do projeto:

    $ cd djapp
  4. Use o script manage.py para migrar o banco de dados do projeto, o que é necessário para um projeto recém-criado. O Django usa SQLite por padrão, e eu aceito o padrão na demonstração, mas você pode usar qualquer banco de dados que atenda às necessidades do seu projeto.

    O script manage.py é instalado pelo comando django-admin que executamos na Etapa 2; ele executa os mesmos comandos e aceita os mesmos argumentos que django-admin , mas deriva e usa automaticamente algumas configurações específicas do projeto, o que é útil. Para mais detalhes, consulte a documentação do Django .

    $ sudo python3 manage.py migrar
  5. Embora não seja estritamente necessário para um projeto de exemplo como este, recomendamos que você crie uma identidade de superusuário do Django:

    $ sudo python3 manage.py criarsuperusuário
  6. Mude para o subdiretório que contém o arquivo settings.py , que foi criado pelo comando django-admin startproject na Etapa 2.

    $ cd /var/www/djapp/djapp
  7. Usando seu editor de texto preferido, abra settings.py . Aqui estamos usando nano :

    $ sudo nano settings.py

    Localize a linha ALLOWED_HOSTS e adicione o nome de domínio, nome do host ou endereço IP do aplicativo:

    ALLOWED_HOSTS = [' nome-de-domínio ']

    Adicione também a seguinte linha no final do arquivo, para nomear o diretório que armazena todo o conteúdo estático servido pelo aplicativo (veja a Etapa 9).

    RAIZ_ESTÁTICA = '/var/www/djapp/djapp/static'
  8. Volte para o diretório principal do projeto (onde manage.py reside).

    $ cd ..
  9. Execute o comando manage.py collectstatic para coletar todos os arquivos estáticos localizados no projeto Django e colocá-los no local STATIC_ROOT definido na Etapa 7.

    $ sudo python3 manage.py collectstatic

Configurando o NGINX

Por padrão, o próprio Django fornece conteúdo estático para um projeto, mas o NGINX Open Source e o NGINX Plus oferecem desempenho superior. Aqui configuramos o NGINX Plus, mas você pode usar o NGINX Open Source, exceto por um recurso indicado abaixo.

  1. Altere o diretório para /etc/nginx/conf.d , o local convencional para arquivos de configuração HTTP específicos da função (ou, no nosso caso, específicos do aplicativo):

    $ cd /etc/nginx/conf.d
  2. Crie um arquivo chamado django.conf (novamente, estamos usando nano ):

    $ sudo nano django.conf

    Insira a seguinte configuração, que habilita o cache.

    A configuração também inclui dois recursos exclusivos do NGINX Plus. Descomente as diretivas relevantes se estiver usando o NGINX Plus e quiser aproveitar os recursos:

    Uma coisa a ser observada é que na demonstração na NGINX Conf eu especifiquei o endereço IP da minha máquina local como o segundo argumento para a diretiva proxy_set_header . Em um ambiente de produção, faz mais sentido usar a variável $host, conforme mostrado abaixo.

    # Grupo upstream para o backend (Unidade NGINX executando o aplicativo Python)
    upstream django_unit {
    zone django_unit 64k;
    server 127.0.0.1:8000;
    }
    
    server {
    listen 8080;
    # Descomente para coletar métricas se estiver usando NGINX Plus e a API NGINX Plus
    #status_zone django;
    
    # habilitar cache
    proxy_cache django_cache;
    proxy_cache_valid 200 60m;
    
    # diretório raiz para arquivos estáticos
    root /var/www/djapp/djapp;
    
    # proxy para o backend da Unidade NGINX
    location / {
    proxy_pass http://django_unit;
    
    # O segundo argumento deve corresponder ao nome do host de produção e ao valor de 
    # ALLOWED_HOSTS em settings.py
    proxy_set_header Host $host; 
    
    # Descomente para habilitar verificações de integridade ativas se estiver usando NGINX Plus
    #health_check;
    }
    
    # Localização para os arquivos estáticos coletados do Django e servidos por 
    # NGINX Plus; pode estar vazio (como aqui), porque herda o valor da 
    # diretiva 'root' de seu bloco pai
    location /static {
    }
    }
  3. Verifique a configuração para validade sintática:

    $ sudo nginx –t
  4. Após corrigir quaisquer erros, recarregue a configuração:

    $ sudo nginx -s recarregar

Configurando a unidade NGINX

Para finalizar, precisamos configurar o NGINX Unit para atender as solicitações ao aplicativo.

  1. Execute este comando curl para exibir a configuração atual da unidade NGINX, que é para WordPress executado em PHP. Não mostro a saída aqui, mas a configuração do WordPress aparece na Etapa 6 abaixo, junto com a configuração do aplicativo Python, que estamos prestes a adicionar.

    Observe que eu uso sudo para o comando curl , o que você pode não precisar fazer para a maioria dos comandos curl . Aqui isso é necessário porque para acessar o soquete UNIX precisamos da permissão de leitura e gravação que o root tem nele.

    $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/
  2. Mude para o diretório dos arquivos de configuração da unidade NGINX.

    Tenha em mente que esses arquivos são opcionais e apenas uma maneira conveniente de carregar coleções de configuração sem digitar todos os dados como um argumento para uma chamada para a API do NGINX Unit. Como o conteúdo dos arquivos é carregado por meio da API (como todos os dados de configuração), o NGINX Unit não sabe sobre os locais dos arquivos e não pode ler os arquivos automaticamente quando é iniciado (ao contrário do NGINX Open Source e do NGINX Plus). Em vez disso, o NGINX Unit salva seu estado de tempo de execução em um diretório separado.

    $ cd /etc/unidade
  3. Crie um arquivo chamado django.config (novamente, estamos usando nano ):

    $ sudo nano django.config

    Adicione o seguinte JSON, que representa nosso aplicativo Python.

    {
    "tipo": "python",
    "processos": 5, "módulo": "djapp.wsgi", "caminho": "/var/www/djapp" }
  4. Execute este comando curl para carregar o JSON contido em django.config como um novo objeto de aplicativo a ser gerenciado pela Unidade NGINX, chamado djapp :

    $ sudo curl -X PUT --data-binary @/etc/unit/django.config --unix-socket /run/control.unit.sock http://localhost/config/applications/djapp

    Neste comando:

    • O método HTTP PUT cria um novo objeto de configuração da Unidade NGINX no local nomeado pelo argumento final (a URL). Veja o último item abaixo.
    • O argumento --data-binary informa ao curl para carregar o conteúdo de django.config exatamente como fornecido, preservando novas linhas e retornos de carro, e não realizando nenhum tipo de processamento.
    • O argumento --unix-socket define onde a API da Unidade NGINX está escutando. (Usamos o comando sudo porque estamos usando o proprietário padrão do soquete, root .)
    • O argumento final localiza e nomeia o novo objeto de aplicativo a ser preenchido com os dados de configuração formatados em JSON em django.config : config é o objeto de configuração da Unidade NGINX de nível superior, applications é o pai dos objetos de aplicativo e djapp é o nome do novo objeto de aplicativo.
  5. Defina o objeto ouvinte para o aplicativo. Em vez de carregar um arquivo de dados de configuração como na Etapa 4, definimos os dados diretamente na linha de comando curl , especificando que o aplicativo djapp escuta na porta 8000.

    $ sudo curl -X PUT --data-binary '{"application":"djapp"}' --unix-socket /run/control.unit.sock 'http://localhost/config/listeners/*:8000'
  6. Repita o comando curl da Etapa 1 para exibir a configuração da Unidade NGINX, que agora inclui nosso aplicativo Python, djapp , destacado em laranja:

    $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/ { "listeners": { "127.0.0.1:8090": { "application": "script_index_php" }, "127.0.0.1:8091": { "application": "direct_php" }, "*:8000": { "application": "djapp" } }, "applications": { "script_index_php": { "type": "php", "processes": { "max": 20, "sobressalente": 5 }, "usuário": "www-data", "grupo": "www-data", "raiz": "/var/www/wordpress", "script": "index.php" }, "direct_php": { "tipo": "php", "processos": { "máx": 5, "sobressalente": 0 }, "usuário": "www-data", "grupo": "www-data", "raiz": "/var/www/wordpress", "índice": "index.php" }, "djapp": { "tipo": "python", "processos": 5, "módulo": "djapp.wsgi", "caminho": "/var/www/djapp" } } }

Resumo

Neste post começamos com a Unidade NGINX executando aplicações PHP para WordPress em produção e adicionamos uma aplicação Python. Na demonstração, uso o painel do NGINX Plus para mostrar que não há interrupção nos aplicativos existentes quando um novo aplicativo é adicionado, mas você pode usar qualquer ferramenta de monitoramento do sistema, como o comando ps , para essa finalidade. A natureza dinâmica da configuração da unidade NGINX economiza recursos para seus aplicativos em execução e garante tempo de inatividade zero em novas implantações e transição suave entre versões de aplicativos.

Para saber mais, visite unit.nginx.org .


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."