NGINX Unit dá as boas-vindas ao outono de 2022 com novos recursos (um mecanismo de estatísticas!) e planos empolgantes

Artem Konev

Antes de mais nada: já faz um bom tempo desde que compartilhamos novidades da equipe do NGINX Unit — estes tempos turbulentos afetaram a todos, e nós não somos exceção. Em março deste ano, dois membros fundadores da equipe do Unit, Valentin Bartenev e Maxim Romanov, decidiram seguir novos caminhos após dedicarem anos de trabalho e muita criatividade ao NGINX Unit. É preciso dar o devido crédito: sem eles, o NGINX Unit não teria chegado aonde está hoje. Parabéns, pessoal.

Ainda assim, nossa determinação continua firme, assim como nosso compromisso de concretizar as aspirações originais do cofundador do NGINX, Igor Sysoev, para o NGINX Unit. A chegada dos dois mais novos membros da equipe, Alejandro Colomar e Andrew Clayton, impulsionou o trabalho de desenvolvimento. Por isso, agora temos várias novidades importantes das versões 1.25 a 1.28 do NGINX Unit para compartilhar com vocês.

A observabilidade agora é uma realidade

Uma das principais aspirações do Unit sempre foi a observabilidade, e a versão 1.28.0 inclui a primeira implementação de um dos recursos mais aguardados: um mecanismo de estatísticas. Sua saída é disponibilizada no novo endpoint da API /status:

$ curl --unix-socket /var/run/control.unit.sock http://localhost/status

{
    "connections": {
        "accepted": 1067,
        "active": 13,
        "idle": 4,
        "closed": 1050
    },

    "requests": {
        "total": 1307
    },

    "applications": {
        "wp": {
            "processes": {
                "running": 14,
                "starting": 0,
                "idle": 4
            },

            "requests": {
                "active": 10
            }
        }
    }
}

A maioria dos campos aqui é autoexplicativa: connections (linha 2) e requests (linha 9) fornecem dados de toda a instância, enquanto o objeto applications (linha 13) espelha /config/applications, abrangendo processos e solicitações relacionados especificamente ao aplicativo.

As linhas 3–6 mostram as quatro categorias de conexões monitoradas pelo NGINX Unit: aceitas, ativas, ociosas, e fechadas. As categorias de processos são em execução, em inicialização, e ociosos (linhas 16–18). Essas categorias refletem a representação interna das conexões e dos processos, então agora você sabe tanto sobre eles quanto o seu servidor.

Parece sucinto? Por enquanto, isso é praticamente tudo o que há para saber. É claro que estamos trabalhando para disponibilizar métricas mais úteis; no entanto, você já pode consultar essa API pela linha de comando para ver o que está acontecendo no seu servidor e até integrar a saída a um painel ou à ferramenta de sua preferência, caso queira algo mais sofisticado. Talvez você não tenha um painel? Bem, alguns dos nossos planos incluem oferecer um painel integrado, então acompanhe-nos para ver como isso vai se desenrolar.

Para mais detalhes, consulte Estatísticas de uso na documentação do NGINX Unit.

Mais variáveis, mais lugares para usá-las

A lista de variáveis introduzidas desde a versão 1.24 é bastante extensa e inclui $body_bytes_sent, $header_referer, $header_user_agent, $remote_addr, $request_line, $request_uri, $status e $time_local.

A maioria delas é bastante simples, mas estas são algumas das que mais se destacam:

• $request_uri contém o caminho e a consulta do URI solicitado, preservando a codificação do navegador
• A variável de nome semelhante $request_line armazena a requisição inteira, como GET /docs/help.html HTTP/1.1, e destina-se ao registro de logs…
• Assim como $status que contém o código de status da resposta HTTP

Você percebeu? Mencionamos respostas. Sim, também estamos entrando nesse território: as variáveis nas versões anteriores do Unit se concentravam nas solicitações recebidas, mas agora também temos variáveis que capturam as propriedades da resposta, como $status e $body_bytes_sent.

Quanto aos novos locais em que é possível usar variáveis, o primeiro a mencionar é o novo formato personalizável do log de acesso. Quer usar JSON nas entradas de log do NGINX Unit? Além de especificar uma string simples de caminho, a opção access_log pode ser um objeto que também define o formato das entradas de log:

{ 
    "access_log": {
        "path": "/var/log/unit/access.log", 
        "format": "{ \"remote_addr\":\"$remote_addr\", "time\":\"$time_local\", \"request\":\"$request_line\", \"response\":\"$status\", \"header_referer\":\"$header_referer\", \"header_user_agent\":\"$header_user_agent\" }" 
    } 
}

Assim, você pode ir além do formato de log convencional da maneira que preferir.

Um segundo caso de uso relevante para variáveis é o valor location de uma action de rota:

{ 
    "action": { 
        "return": 301, 
        "location": "https://$host$request_uri" 
    } 
 }

Aqui, estamos usando $request_uri para redirecionar a solicitação, incluindo os parâmetros de consulta, para o mesmo site via HTTPS.

A opção chroot agora aceita variáveis, assim como a opção share, o que é perfeitamente lógico:

{ 
    "action": { 
        "share": "/www$uri",
        "chroot": "/www/data/$host/" 
    } 
} 

O NGINX Unit agora também oferece suporte a variáveis dinâmicas. Os argumentos, cookies e cabeçalhos da solicitação são expostos como variáveis: por exemplo, a string de consulta Type=car&Color=red resulta em duas variáveis de argumento, $arg_Type e $arg_Color. Em tempo de execução, essas variáveis são expandidas para valores dinâmicos; se você fizer referência a uma variável inexistente, ela será considerada vazia.

Para mais detalhes, consulte Variáveis na documentação do NGINX Unit.

Amplo suporte aos cabeçalhos X-Forwarded-* Headers

Você pediu, e nós atendemos. Desde a versão 1.25.0, o NGINX Unit oferece alguns recursos de configuração de TLS para seus listeners, incluindo certo nível de reconhecimento dos cabeçalhos X-Forwarded-*; agora, você pode configurar os endereços IP dos clientes e a substituição de protocolo na configuração dos seus listeners:

{
    "listeners": {
        "*:80": {
            "pass": "routes/my-app",
            "forwarded": {
                "client_ip": "X-Forwarded-For",
                "protocol": "X-Forwarded-Proto",
                "recursive": false,
                "source": [
                    "198.51.100.1-198.51.100.254",
                    "!198.51.100.128/26",
                    "203.0.113.195"
                ]
            }
        }
    },
    ...
}

Observação: Esta nova sintaxe torna obsoleta a sintaxe anterior de client_ip, que será removida em uma versão futura.

Para mais detalhes, consulte Encaminhamento de IP e protocolo na documentação do NGINX Unit.

A opção share reformulada

A versão 1.11.0 do NGINX Unit introduziu a opção de roteamento share para servir conteúdo estático. Ela é comparável à diretiva root do NGINX:

{
    "share": "/path/to/dir/"
}

Inicialmente, a opção share especificava o chamado diretório raiz de documentos. Para determinar qual arquivo deveria fornecer, o Unit simplesmente acrescentava o URI da solicitação a esse caminho de share. Por exemplo, em resposta a uma simples solicitação GET para /some/file.html, o Unit fornecia /path/to/dir/some/file.html. No entanto, continuávamos nos deparando com casos limítrofes que exigiam um controle mais preciso sobre o caminho do arquivo, então decidimos evoluir. A partir da versão 1.26.0, a opção share especifica o caminho completo para um arquivo compartilhado, em vez de apenas a raiz de documentos.

Quer servir um arquivo específico? Tudo bem:

{
    "share": "/path/to/a/file.html"
}

Quer usar variáveis no caminho? Legal, sem problema:

{
    "share": "/www/data/$host/app.html"
}

Mas como imitar o comportamento ao qual você já está acostumado no NGINX e nas versões anteriores do Unit? Sabe aquela história de raiz de documentos que consideramos obsoleta alguns parágrafos atrás? Temos uma solução.

Agora você pode reescrever configurações como esta:

{
    "share": "/www/data/"
}

da seguinte forma, acrescentando explicitamente o URI solicitado ao caminho!

{
    "share": "/www/data/$uri"
}

Por fim, a diretiva share agora pode aceitar um array de caminhos, testando-os um a um até encontrar um arquivo:

{
    "share": [
        "/www/$host$uri",
        "/www/static$uri",
        "/www/app.html"
    ]
}

Se nenhum arquivo for encontrado, o roteamento será encaminhado para uma ação de fallback; se não houver um fallback, o código de status 404 (Não Encontrado) será retornado.

Para mais detalhes, consulte Arquivos estáticos na documentação do NGINX Unit.

Planos: njs, reescrita de URI, encadeamento de ações, OpenAPI

Enquanto você lê isto, já estamos trabalhando na próxima versão; confira uma prévia do que estamos preparando.

Primeiro, estamos integrando o NGINX Unit ao módulo JavaScript do NGINX (njs), outro projeto essencial em desenvolvimento ativo na NGINX. Em resumo, isso significa que o NGINX Unit permitirá invocar módulos JavaScript. Considere o seguinte:

var hellonjs = {}

hellonjs.hello = function(vars) {
    if ('unitvar' in vars) {
        return vars.unitvar;

    } else {
        return 'default';
    }
}

export default hellonjs

Depois de importar o módulo no NGINX Unit, você poderá fazer algumas coisas bem interessantes com a configuração:

{
    "match": {
        "uri": "~(?.*)" }, "action": { "share": "`/www/html${hellonjs.hello(vars)}`" } }

Além disso, pretendemos introduzir algo semelhante à popular diretiva rewrite do NGINX:

{
    "match": {
        "uri": "/app/old_path"
     },
     
    "action": {
        "rewrite": "/app/new_path",
        "pass": "routes"
    }
}

Mas nossos planos não param por aí. Que tal vincular o roteamento do NGINX Unit à saída dos próprios aplicativos (também conhecido como encadeamento de action)?

{
    "action": [
        {
            "pass": "applications/auth_check"
        },
        {
            "pass": "applications/my_app"
        }
    ]
}

A ideia aqui é que o aplicativo auth_check autentique a solicitação recebida e retorne um código de status para indicar o resultado. Se a autenticação for bem-sucedida, o código 200 OK será retornado e a solicitação será encaminhada para my_app.

Enquanto isso, também estamos trabalhando em uma especificação OpenAPI para definir de uma vez por todas a API do NGINX Unit e seus recursos exatos. Desejem-nos sorte, pois essa é uma tarefa colossal.

Se isso ainda não for suficiente para satisfazer sua curiosidade, consulte nosso roadmap para conferir uma análise detalhada dos nossos planos; ele é interativo, portanto, suas contribuições, caro leitor, serão muito bem-vindas.

Sobre o autor

Artem Konev

Mais publicações de Artem Konev