Anunciando o NGINX Plus R20

Liam CrillyDiretor Sênior de Gestão de Produtos

Temos o prazer de anunciar que o NGINX Plus Release 20 (R20) já está disponível. O NGINX Plus é a única solução completa que reúne balanceador de carga, cache de conteúdo, servidor web e gateway de API. Baseado no NGINX Open Source, o NGINX Plus inclui recursos avançados exclusivos e suporte premiado.

O NGINX Plus R20 amplia as melhorias que fizemos na limitação de taxa e no armazenamento de chave-valor na R19. Os novos recursos incluem:

• Monitoramento e registro em tempo real do tráfego com limite de taxa – Quando o limite de taxa está configurado, a API do NGINX Plus passa a informar quantas solicitações são processadas imediatamente, atrasadas ou rejeitadas. Também é possível configurar o log de acesso para incluir informações sobre o status de limitação de taxa de cada solicitação.
• Aprimoramentos na limitação de conexões – Os aprimoramentos na limitação de taxa introduzidos na versão R19 e nesta versão foram estendidos à limitação de conexões.
• Correspondência de prefixos no armazenamento de chave-valor – As chaves no armazenamento de chave-valor podem ser comparadas a um prefixo especificado (caracteres no início de uma string). Um caso de uso importante é o roteamento dinâmico de solicitações.
• Resolução de DNS por grupo de upstream – Agora você pode definir um conjunto diferente de servidores DNS para cada grupo de upstream que usa um nome de host resolvível para representar os servidores de backend do grupo.
• Variáveis adicionais do protocolo PROXY – Novas variáveis capturam o endereço IP e a porta do servidor proxy ao qual o cliente se conectou originalmente.
• Melhorias de segurança para HTTP/2 – Diversas alterações melhoram a segurança geral do tráfego HTTP/2, incluindo uma detecção mais eficaz de comportamentos incorretos ou inválidos do cliente e uma implementação mais robusta de determinadas diretivas.

Mudanças importantes de comportamento

• APIs obsoletas – O NGINX Plus R13 (lançado em agosto de 2017) apresentou a nova API do NGINX Plus<.htmlspan> para coleta de métricas e reconfiguração dinâmica de grupos upstream, substituindo as APIs Status e Upstream Conf, que anteriormente implementavam essas funções. Conforme anunciado na época, as APIs descontinuadas continuaram disponíveis e com suporte por um período significativo, que terminou com o NGINX Plus R16. Se a sua configuração incluir as diretivas status ou upstream_conf, você deverá substituí-las pela diretiva api como parte da atualização para a R20. Para obter orientações e assistência na migração para a nova API do NGINX Plus, consulte o guia de transição em nosso blog ou entre em contato com nossa equipe de suporte.
• Novos sistemas operacionais compatíveis –
  • CentOS 8.0+
  • FreeBSD 12.1
  • Red Hat Enterprise Linux 8.1
  • Ubuntu 19.10 (“Eoan Ermine”)

Para obter mais informações sobre as plataformas compatíveis, consulte as especificações técnicas do NGINX Plus e dos módulos dinâmicos.

Novos recursos em detalhes

Monitoramento e registro em tempo real do tráfego com limitação de taxa

O NGINX Plus R20 apresenta recursos que facilitam às equipes de Operações e DevOps o monitoramento da atividade de limitação de taxa em tempo real e a identificação exata dos clientes que excederam o limite de taxa.
O NGINX Plus sempre ofereceu muita flexibilidade para definir os tipos de solicitação de cliente sujeitos à limitação de taxa e como as solicitações excessivas são processadas. Cada solicitação é tratada de uma das seguintes maneiras:

• Aceita sem atraso (porque a taxa de solicitações está abaixo do limite ou dentro do tamanho de pico configurado)
• Atrasada até que seu processamento não faça com que o limite de taxa seja excedido (também conhecido como throttling)
• Rejeitada com um código de resposta de erro HTTP

Em versões anteriores, o log de erros era o único local em que o NGINX Plus registrava o fato de que as solicitações haviam sido atrasadas ou rejeitadas, em entradas padronizadas como esta:

2019/12/02 11:42:12 [error] 57#57: *339 limiting requests, excess: 0.600 by zone "my_limit", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.0", host: "www.example.com:80"

Extrair informações úteis do log de erros pode ser desafiador, pois o formato das mensagens não é estruturado nem configurável. Além disso, se o limite de taxa for definido com base em uma característica da mensagem diferente das registradas na entrada do log de erros — por exemplo, cabeçalhos HTTP ou informações de identidade —, será necessário localizar a entrada correspondente no log de acesso para determinar exatamente qual cliente excedeu o limite de taxa. Os novos recursos solucionam esses problemas.

Métricas de limitação de taxa da API do NGINX Plus

Um novo endpoint da API do NGINX Plus, /api/version/http/limit_reqs, mantém contadores para todos os resultados das decisões de limitação de taxa tomadas para cada zona definida por uma diretiva limit_req_zone. Esses contadores podem ser usados tanto para monitorar decisões de limitação de taxa em tempo real quanto para integração com soluções de APM, a fim de fornecer painéis e alertas sobre a atividade de limitação de taxa.

No exemplo a seguir, há uma zona definida, my_limit:

$ curl http://localhost/api/6/http/limit_reqs
{
 "my_limit": {
   "delayed": 540,
   "delayed_dry_run": 12162,
   "passed": 804541,
   "rejected": 63,
   "rejected_dry_run": 1209
 }
}

Observe que esses contadores também incluem entradas de solicitações excessivas processadas no modo de simulação, que foi introduzido no NGINX Plus R19.

Registro da atividade de limitação de taxa no log de acesso

As métricas em tempo real são muito úteis para entender quando o NGINX Plus está processando solicitações em excesso, mas não informam quem as está gerando. Para solucionar esse problema, o NGINX Plus R20 disponibiliza uma nova variável $limit_req_status. Ela registra o status de limitação de taxa da solicitação: DELAYED, DELAYED_DRY_RUN, PASSED, REJECTED ou REJECTED_DRY_RUN.

Em seguida, você pode incluir outras variáveis no formato de log que identifiquem de forma exclusiva o cliente, o URI e quaisquer outras informações relevantes. Na configuração a seguir, um limite estrito de 10 solicitações por segundo é aplicado a cada cliente, com base na validação de JSON Web Token (JWT) (linha 1). As solicitações excedentes são rejeitadas (linha 16) e registradas em um arquivo de log separado (linha 21), que também inclui a variável $jwt_claim_sub para capturar a declaração sub (linha 4).

Carregando exemplo de código…

Exemplos de entradas no arquivo reject.log:

time=1575289305.350 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTEDtime=1575289305.395 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED
time=1575289305.402 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED

Aprimoramentos na limitação de conexões

Além da limitação da taxa de solicitações, o NGINX Plus permite limitar as conexões de clientes com o módulo Limit Connections. Você pode definir quantas conexões distintas um cliente pode abrir com o NGINX Plus (ou o número de solicitações simultâneas ao usar HTTP/2). Normalmente, um cliente é identificado pelo endereço IP remoto (a variável $remote_addr ou $binary_remote_addr), mas você pode usar outra variável (como $jwt_claim_sub para o nome de usuário em um JWT) quando o endereço IP remoto for ambíguo ou possivelmente compartilhado por vários clientes.

O NGINX Plus R20 amplia a limitação de conexões com os mesmos aprimoramentos à limitação de taxa introduzidos no NGINX Plus R19 e nesta versão:

• Modo de simulação com a diretiva limit_conn_dry_run directive
• Monitoramento em tempo real no endpoint da API do NGINX Plus /api/version/http/limit_conns
• Uma nova variável, $limit_conn_status, que registra a decisão de limitação de conexões para cada solicitação (PASSED, REJECTED ou REJECTED_DRY_RUN) e pode ser usada conforme descrito em Como registrar a atividade de limitação de taxa no log de acesso para a variável $limit_req_status variable

A configuração a seguir aplica uma largura de banda baixa aos clientes que abrem mais de dez conexões simultâneas.

Carregando exemplo de código…

Correspondência de prefixos no armazenamento de chave-valor

Com o armazenamento de chave-valor em memória do NGINX Plus, você pode usar a API do NGINX Plus para configurar dinamicamente o gerenciamento de tráfego com base nos atributos da solicitação. Alguns exemplos de casos de uso incluem inclusão dinâmica de endereços IP em listas de bloqueio, limitação dinâmica de largura de banda, e armazenamento em cache de tokens de autenticação.

O NGINX Plus R20 adiciona suporte à correspondência de chaves com um prefixo especificado (caracteres no início de uma string), possibilitando um novo conjunto de casos de uso para o armazenamento de chave-valor. Por exemplo, a possibilidade de fazer a correspondência de chaves com prefixos de URI (caminhos-base), em vez de URIs exatos, permite criar uma tabela de roteamento dinâmica para mapear cada caminho-base para um grupo upstream, substituindo ou complementando os mapeamentos estáticos definidos pelas diretivas location.

Para habilitar a correspondência por prefixo, inclua o novo parâmetro type=prefix na diretiva keyval_zone. Na configuração a seguir, a diretiva keyval associa uma diretiva Cache-Control (como max-age ou no-cache) a cada prefixo de URI, e a diretiva add_header define o cabeçalho de resposta Cache-Control com esse valor quando o NGINX Plus encaminha a solicitação ao servidor upstream.

Carregando exemplo de código…

Usamos a API do NGINX Plus para definir o valor do cabeçalho de resposta Cache-Control para cada caminho base (neste caso, caminhos que começam com /images/ ou /reports/) no armazenamento de chave-valor:

$ curl -i -X POST --data '{"/images/":"max-age=3600", "/reports/":"no-cache"}' http://localhost:8080/api/6/http/keyvals/pathsHTTP/1.1 201 Created
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:36:31 GMT
Content-Length: 0
Location: http://localhost:8080/api/6/http/keyvals/paths/
Connection: keep-alive

Quando fazemos uma solicitação com um caminho base que existe no armazenamento de chave-valor, a resposta inclui o cabeçalho Cache-Control que definimos:

$ curl -I http://localhost/images/sample.jpgHTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:27:39 GMT
Content-Type: image/jpeg
Content-Length: 120847
Connection: keep-alive
Cache-Control: max-age=3600

Como o armazenamento de chave-valor pode ser sincronizado em um cluster de instâncias do NGINX Plus, basta fazer cada chamada de API para uma única instância. Isso torna o processo de automatização das alterações na configuração do cluster muito mais simples do que coordenar alterações nos arquivos de configuração.

Resolução de DNS por grupo de upstream

Ao usar o NGINX Plus para realizar o balanceamento de carga entre vários servidores upstream, você pode definir os membros do grupo upstream especificando um nome de host que seja resolvido para vários endereços IP. Isso é particularmente útil em ambientes dinâmicos ou com escalabilidade automática, nos quais os membros do grupo upstream podem mudar com frequência.

Para concluir a configuração desses grupos upstream dinâmicos, inclua também a diretiva resolver para designar o servidor ou os servidores DNS que o NGINX Plus consulta para obter os endereços IP associados ao nome do host. Nas versões anteriores, uma diretiva resolver era aplicada a todos os grupos upstream referenciados pelas diretivas proxy_pass no contexto (http, server ou location) que continha a diretiva. Com o NGINX Plus R20, agora você pode especificar um resolvedor DNS diferente para cada grupo upstream.

A nova flexibilidade é especialmente útil em um ambiente de DevOps, pois permite que as equipes de aplicativos tenham maior controle sobre sua infraestrutura de entrega de aplicativos, incluindo os servidores DNS e os registros de serviços, em vez de depender de serviços centralizados e compartilhados.

Você ainda pode definir um resolvedor global no contexto http de nível superior e nos blocos server e location. Se um bloco upstream não incluir uma diretiva resolver, ele herdará a configuração de resolver do contexto ou bloco que inclui uma diretiva proxy_pass que referencia o grupo upstream, como nas versões anteriores.

No exemplo a seguir, o grupo upstream website usa o resolvedor global, enquanto mobile_app usa seu próprio resolvedor:

Carregando exemplo de código…

Observe que estamos incluindo o parâmetro status_zone (introduzido no NGINX Plus R19) em ambas as diretivas resolver, para coletar métricas de erros e outras métricas sobre a atividade do resolvedor.

Variáveis para metadados do servidor do protocolo PROXY

O PROXY Protocol é um mecanismo pelo qual um proxy de Camada 4 pode transmitir informações sobre a conexão original do cliente ao próximo proxy ou balanceador de carga que processa a solicitação do cliente. Isso é particularmente importante em casos de uso nos quais é necessário saber o endereço IP do cliente – por exemplo, para limitar o número de conexões feitas por cada cliente (com a diretiva least_conn) ou simplesmente para registrar o endereço IP real do cliente. Assim como nas versões anteriores, a variável $proxy_protocol_addr captura essas informações.

Quando há vários proxies de Camada 4 implantados em um ambiente de aplicação, às vezes é importante que o NGINX Plus também saiba o endereço IP e a porta do servidor proxy ao qual o cliente se conectou originalmente. Os metadados do protocolo PROXY incluem essas informações, e o NGINX Plus R20 adiciona variáveis para capturá-las:

• $proxy_protocol_server_addr
• $proxy_protocol_server_port

As variáveis estão disponíveis para os módulos HTTP e Stream (TCP/UDP) e são compatíveis com as versões 1 e 2 do protocolo PROXY. Observe que, antes de usar as variáveis, você deve habilitar explicitamente o NGINX Plus para processar o protocolo PROXY, adicionando o parâmetro proxy_protocol à diretiva listen.

Melhorias de segurança para HTTP/2

NGINX Plus R18 P1 corrigiu três vulnerabilidades de segurança no HTTP/2 que foram anunciadas em agosto. O NGINX Plus R20 inclui alterações adicionais que melhoram a segurança geral da nossa implementação do HTTP/2:

• Detecção aprimorada de comportamentos incorretos ou inválidos do cliente
• Aprimorado o envio de respostas de erro HTTP/2 antes da leitura do corpo da solicitação do cliente
• Maior robustez da diretiva worker_shutdown_timeout para conexões HTTP/2 de longa duração
• Maior robustez da diretiva proxy_request_buffering para clientes HTTP/2

Se você estiver usando HTTP/2 em produção com o NGINX Plus R18 (sem patch) ou uma versão anterior, recomendamos atualizar para o NGINX Plus R20 assim que possível.

Atualizações do ecossistema do NGINX Plus

Módulo JavaScript do NGINX

O módulo JavaScript do NGINX (njs) foi atualizado para a versão 0.3.7, adicionando suporte a mais objetos JavaScript:

• Function() construtor
• Object.assign() método
• Number métodos: toFixed(), toPrecision(), e toExponential()
• Array.prototype.copyWithin() método
• Parâmetro de rótulo do método console.time() method

Para saber mais sobre o njs, confira a página inicial do projeto e o nosso blog<.htmla>.

Faça upgrade ou experimente o NGINX Plus

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para o NGINX Plus R20 o mais rápido possível. Você também terá acesso a diversas correções e melhorias adicionais, além de facilitar o suporte da NGINX quando precisar abrir um chamado.

Antes de prosseguir com a atualização, analise cuidadosamente os novos recursos e as mudanças de comportamento descritos nesta publicação do blog.

Se você ainda não experimentou o NGINX Plus, recomendamos que faça um teste – para segurança, balanceamento de carga e gateway de API, ou como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Comece hoje mesmo com uma avaliação gratuita de 30 dias. Veja por si mesmo como o NGINX Plus pode ajudar você a disponibilizar e escalar suas aplicações.

Sobre o autor

Liam CrillyDiretor Sênior de Gestão de Produtos

Mais publicações de Liam Crilly