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

Primeiramente, façamos o que for preciso: já faz um bom tempo que não compartilhamos notícias da equipe da Unidade NGINX. Esses tempos tumultuados afetaram a todos, e não somos exceção. Em março deste ano, dois membros fundadores da equipe da Unit, Valentin Bartenev e Maxim Romanov, decidiram buscar outras oportunidades depois de anos de trabalho e muita criatividade no NGINX Unit . Vamos dar crédito a quem merece: sem eles, o NGINX Unit não estaria onde está agora. Parabéns, rapazes.

Ainda assim, nossa determinação permanece forte, assim como nosso compromisso de concretizar as aspirações originais do cofundador da NGINX, Igor Sysoev, para a Unidade NGINX. A chegada dos dois mais novos membros da equipe, Alejandro Colomar e Andrew Clayton, impulsionou o esforço de desenvolvimento, então agora temos alguns itens dignos de nota das versões 1.25 a 1.28 do NGINX Unit para compartilhar com vocês.

A observabilidade é uma coisa agora

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

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

{
"conexões": {
"aceito": 1067,
"ativo": 13,
"ocioso": 4,
"fechado": 1050
},

"solicitações": {
"total": 1307
},

"aplicativos": {
"wp": {
"processos": {
"em execução": 14,
"começando": 0,
"ocioso": 4
},

"solicitações": {
"ativo": 10 } } } }

A maioria dos campos aqui são autodescritivos: conexões (linha 2) e solicitações (linha 9) fornecem dados de toda a instância, enquanto o objeto de aplicativos (linha 13) espelha /config/applications , abrangendo processos e solicitações que dizem respeito especificamente ao aplicativo.

As linhas 3 a 6 mostram as quatro categorias de conexões rastreadas pela Unidade NGINX: aceitas , ativas , ociosas e fechadas . As categorias para processos são em execução , iniciando e ocioso (linhas 16–18). Essas categorias refletem a representação interna de conexões e processos, então agora você sabe tanto sobre elas quanto seu servidor.

Parece conciso? Isso é praticamente tudo o que há para saber por enquanto. Claro, estamos trabalhando para expor métricas mais úteis; no entanto, você já pode consultar esta API a partir da sua linha de comando para ver o que está acontecendo no seu servidor e até mesmo conectar a saída em um painel ou de sua escolha para uma abordagem mais fantasiosa. Talvez você não tenha um painel? Bem, alguns dos nossos planos incluem fornecer um integrado, então siga-nos para ver como isso funciona.

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

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 é bem direta, mas aqui estão algumas das mais dignas de nota:

• $request_uri contém o caminho e a consulta do URI solicitado com a codificação do navegador preservada
• O $request_line, de nome semelhante, armazena toda a solicitação, como GET /docs/help.html HTTP/1.1 , e se destina ao registro…
• 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 focavam nas solicitações recebidas, mas agora temos variáveis que capturam também as propriedades de resposta, como $status e $body_bytes_sent .

Em relação aos novos locais para usar variáveis, o primeiro a ser mencionado é o novo formato de log de acesso personalizável. Quer usar JSON nas entradas de log da unidade NGINX? Além de especificar uma sequência de caminho simples, 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\" }" 
} 
}

Dessa forma, você pode ir além do formato de registro usual da maneira que quiser.

Um segundo caso de uso notável para variáveis é o valor de localização de uma ação de rota:

{ 
"ação": { 
"retorno": 301, 
"localização": "https://$host$request_uri" 
} 
}

Aqui estamos usando $request_uri para retransmitir a solicitação, incluindo a parte da consulta, para o mesmo site via HTTPS.

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

{ 
"ação": { 
"compartilhar": "/www$uri",
"chroot": "/www/data/$host/" 
} 
} 

O NGINX Unit agora também oferece suporte a variáveis dinâmicas. Argumentos de solicitação, cookies e cabeçalhos 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 se expandem 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 da Unidade NGINX.

Suporte extensivo para os cabeçalhos X-Forwarded-*

Vocês pediram e nós atendemos. A partir da versão 1.25.0, o NGINX Unit oferece alguns recursos de configuração TLS para seus ouvintes, incluindo um grau de reconhecimento de X-Forwarded-* ; agora, você pode configurar endereços IP de clientes e substituição de protocolo na configuração para seus ouvintes:

{
"listeners": {
"*:80": {
"pass": "routes/my-app",
"forwarded": {
"client_ip": "X-Forwarded-For",
"protocolo": "X-Forwarded-Proto",
"recursivo": falso,
"fonte": [
"198.51.100.1-198.51.100.254",
"!198.51.100.128/26",
"203.0.113.195"
]
}
}
},
...
}

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

Para mais detalhes, consulte IP, Encaminhamento de Protocolo na documentação da Unidade NGINX.

A opção de ações renovada

A versão 1.11.0 do NGINX Unit introduziu a opção de roteamento de compartilhamento para veicular conteúdo estático. É comparável à diretiva root no NGINX:

{
"share": "/caminho/para/diretório/"
}

Inicialmente, a opção de compartilhamento especificava o chamado diretório raiz do documento. Para determinar qual arquivo servir, a Unit simplesmente anexou o URI da solicitação a esse caminho de compartilhamento . Por exemplo, em resposta a uma simples solicitação GET para /some/file.html , a Unit serviu /path/to/dir/some/file.html . Ainda assim, continuamos nos deparando com casos extremos 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 de compartilhamento especifica o caminho completo para um arquivo compartilhado, em vez de apenas a raiz do documento.

Você quer servir um arquivo específico? Multar:

{
"compartilhar": "/caminho/para/um/arquivo.html"
}

Usar variáveis dentro do caminho? Legal, sem problemas:

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

Mas como você imita o comportamento que você já está acostumado no NGINX e nas versões anteriores do Unit? Sabe, a coisa da raiz do documento que consideramos obsoleta alguns parágrafos atrás? Nós temos uma solução.

Agora você pode reescrever configurações assim:

{
"compartilhar": "/www/data/"
}

como segue, anexando o URI solicitado ao caminho, mas explicitamente!

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

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

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

Se nenhum arquivo for encontrado, o roteamento passa para um cair pra trás ação; se não houver cair pra trás, o 404 (Não Encontrado) o código de status é retornado.

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

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

Enquanto você lê isso, já estamos trabalhando no próximo lançamento; aqui está um vislumbre do que temos na manga.

Primeiro, estamos integrando o NGINX Unit com o módulo NGINX JavaScript ( njs ), outro projeto de trabalho pesado em desenvolvimento ativo no NGINX. Em resumo, isso significa que o NGINX Unit suportará a invocação de módulos JavaScript. Considere isto:

var hellonjs = {} hellonjs.hello = function(vars) { if ('unitvar' em vars) { return vars.unitvar;

    } else { return 'padrão';
    } } exportar hellonjs padrão

Após importar o módulo no NGINX Unit, você poderá fazer algumas coisas legais com a configuração:

{
"corresponder": {
"uri": "~(?.*)"
},
"ação": {
"compartilhar": "`/www/html${hellonjs.hello(vars)}`"
}
}

Além disso, pretendemos introduzir algo semelhante à sempre popular diretiva de reescrita do NGINX:

{
"correspondência": {
"uri": "/app/old_path"
},

"ação": {
"reescrever": "/app/new_path",
"passar": "rotas"
}
}

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

{
"ação": [
{
"pass": "aplicativos/verificação_de_autenticação"
},
{
"pass": "aplicativos/meu_aplicativo"
}
]
}

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,200 OK é retornado e a solicitação é passada para my_app .

Enquanto isso, também estamos trabalhando em uma especificação OpenAPI para definir de uma vez por todas a API da Unidade NGINX e seus recursos exatos. Desejem-nos sorte, pois esta é uma empreitada gigantesca.

Se isso ainda não for suficiente para satisfazer sua curiosidade, consulte nosso roteiro para uma análise detalhada de nossos planos; ele é interativo, então qualquer contribuição sua, caro leitor, é muito bem-vinda.