BLOG | NGINX

Anunciando o NGINX Plus R20

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Liam Crilly
Liam Crilly
Publicado em 03 de dezembro de 2019


Temos o prazer de anunciar que o NGINX Plus Release 20 (R20) já está disponível. O NGINX Plus é o único balanceador de carga, cache de conteúdo, servidor web e gateway de API tudo-em-um . Baseado no NGINX Open Source, o NGINX Plus inclui recursos aprimorados exclusivos e suporte premiado.

O NGINX Plus R20 se baseia nos aprimoramentos que fizemos na limitação de taxa e no armazenamento de chave-valor no R19. Os novos recursos incluem:

Mudanças importantes no comportamento

  • APIs obsoletasO NGINX Plus R13 (lançado em agosto de 2017) introduziu a novíssima NGINX Plus API<.htmlspan> para coleta de métricas e reconfiguração dinâmica de grupos upstream, substituindo as APIs Status e Upstream Conf que implementavam essas funções anteriormente. Conforme anunciado na época, as APIs obsoletas continuaram disponíveis e com suporte por um período significativo de tempo, que terminou com o NGINX Plus R16 . Se sua configuração incluir as diretivas status ou upstream_conf , você deverá substituí-las pela diretiva api como parte da atualização para o R20.

    Para obter orientação e assistência na migração para a nova API NGINX Plus , consulte o guia de transição em nosso blog ou entre em contato com nossa equipe de suporte.

  • Novos sistemas operacionais suportados

    • 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 suportadas, consulte as especificações técnicas do NGINX Plus e dos módulos dinâmicos .

Novos recursos em detalhes

Monitoramento em tempo real e registro de tráfego com taxa limitada

O NGINX Plus R20 apresenta recursos que facilitam para as equipes de Operações e DevOps monitorar a atividade de limitação de taxa em tempo real e determinar exatamente quais clientes excederam o limite de taxa.
O NGINX Plus sempre forneceu bastante flexibilidade na forma como você define os tipos de solicitação de cliente para limitar a taxa e como solicitações excessivas são processadas. Cada solicitação é tratada de uma das seguintes maneiras:

  • Aprovado sem demora (porque a taxa de solicitação está abaixo do limite ou dentro do tamanho de burst configurado)
  • Atrasado até que seja aprovado não faz com que o limite de taxa seja excedido (também conhecido como limitação )
  • Rejeitado com um código de resposta de erro HTTP

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

02/12/2019 11:42:12 [erro] 57#57: *339 limitando solicitações, excesso: 0,600 por zona "my_limit", cliente: 172.17.0.1, servidor: www.example.com, solicitação: "OBTER / HTTP/1.0", host: "www.example.com:80"

Extrair informações úteis do log de erros pode ser desafiador, porque o formato da mensagem não é estruturado e não é configurável. Além disso, se o limite de taxa for baseado em uma característica de mensagem diferente daquelas observadas na entrada do log de erros – por exemplo, cabeçalhos HTTP ou informações de identidade – você deverá encontrar a entrada correspondente no log de acesso para determinar exatamente qual cliente excedeu o limite de taxa. Os novos recursos abordam esses problemas.

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

Um novo ponto de extremidade para a API NGINX Plus , /api/ versão /http/limit_reqs , mantém contadores para todos os resultados de decisões de limitação de taxa tomadas para cada zona definida por uma diretiva limit_req_zone . Esses contadores podem ser usados para monitorar decisões de limitação de taxa em tempo real e integrados com soluções de APM para fornecer painéis e alertas sobre atividades de limitação de taxa.

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

$ curl http://localhost/api/6/http/limit_reqs { "meu_limite": { "atrasado": 540, "teste_a_seco_atrasado": 12162, "aprovado": 804541, "rejeitado": 63, "teste_seco_rejeitado": 1209 } }

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

Taxa de registro de atividade limitadora no log de acesso

Métricas em tempo real são muito úteis para entender quando o NGINX Plus está processando solicitações excessivas, mas não informam quem as está gerando. Para enfrentar esse desafio, o NGINX Plus R20 fornece uma nova variável $limit_req_status . Ele registra o status de limitação de taxa da solicitação: ATRASADO , EXECUÇÃO_DE_SECA_ATRASADA , APROVADO , REJEITADO ou EXECUÇÃO_DE_SECA_REJEITADA .

Você pode então incluir outras variáveis no formato de log que identifiquem exclusivamente o cliente, o URI e qualquer outra informação relevante. Na configuração a seguir, um limite de taxa estrito de 10 solicitações por segundo é aplicado para cada cliente, com base na validação do JSON Web Token (JWT) (linha 1). Solicitações excessivas 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 sub -reivindicação (linha 4).

Entradas de exemplo no arquivo reject.log :

tempo=1575289305.350 cliente=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJEITADOtempo=1575289305.395 cliente=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJEITADO
tempo=1575289305.402 cliente=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJEITADO

Melhorias na limitação de conexão

Além da limitação de taxa para solicitações, o NGINX Plus oferece suporte à limitação de conexões de clientes com o módulo Limit Connections . Você pode definir quantas conexões separadas um cliente pode abrir para o NGINX Plus (ou o número de solicitações simultâneas ao usar HTTP/2). Um cliente normalmente é 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 estende a limitação de conexão com os mesmos aprimoramentos de limitação de taxa introduzidos no NGINX Plus R19 e nesta versão:

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

Correspondência de prefixo no armazenamento de valor-chave

Com o armazenamento de chave-valor na memória para 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. Exemplos de casos de uso incluem lista de negação dinâmica de endereços IP , limitação dinâmica de largura de banda e armazenamento em cache de tokens de autenticação .

O NGINX Plus R20 adiciona suporte para correspondência de chaves com um prefixo especificado (caracteres no início de uma string), permitindo um novo conjunto de casos de uso para o armazenamento de chave-valor. Por exemplo, ser capaz de comparar chaves com prefixos de URI (caminhos base) em vez de URIs exatos significa que você pode criar uma tabela de roteamento dinâmica para mapear cada caminho base para um grupo upstream, substituindo ou aumentando os mapeamentos estáticos definidos pelas diretivas de localização .

Para habilitar a correspondência de 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 para esse valor enquanto o NGINX Plus encaminha a solicitação para o servidor upstream.

Usamos a API NGINX Plus para definir o valor do cabeçalho de resposta Cache-Control para cada caminho base (nesse 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/paths HTTP/1.1 201 Servidor criado: nginx/1.17.6 Data: Seg, 2 Dez 2019 12:36:31 GMT Conteúdo-Duração: 0 Localização: http://localhost:8080/api/6/http/keyvals/paths/ Conexão: 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.jpg HTTP/1.1 200 OK Servidor: nginx/1.17.6 Data: Seg, 2 Dez 2019 12:27:39 GMT Tipo de conteúdo: image/jpeg Comprimento do conteúdo: 120847 Conexão: keep-alive Controle de cache: max-age=3600

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

Resolução DNS por grupo upstream

Ao usar o NGINX Plus para executar o balanceamento de carga em 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 de dimensionamento automático, onde 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 servidores DNS que o NGINX Plus consulta para obter os endereços IP associados ao nome do host. Em 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 continham 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 DevOps – ela permite que as equipes de aplicativos tenham mais propriedade sobre sua infraestrutura de entrega de aplicativos, incluindo servidores DNS e 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 de servidor e localização . Se um bloco upstream não incluir uma diretiva resolver , ele herdará a configuração resolver do contexto ou bloco que inclui uma diretiva proxy_pass referenciando o grupo upstream, como em versões anteriores.

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

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

Variáveis para metadados do servidor de protocolo PROXY

O Protocolo PROXY é um mecanismo pelo qual um proxy da Camada 4 pode transmitir informações sobre a conexão original do cliente para o próximo proxy ou balanceador de carga que manipula a solicitação do cliente. Isso é particularmente importante para casos de uso em que você precisa 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 aplicativo, à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:

As variáveis estão disponíveis para os módulos HTTP e Stream (TCP/UDP) e suportam 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 manipular o Protocolo PROXY, adicionando o parâmetro proxy_protocol à diretiva listen .

Melhorias de segurança para HTTP/2

O 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 HTTP/2:

  • Detecção aprimorada de comportamento incorreto ou inválido do cliente
  • Envio aprimorado de respostas de erro HTTP/2 antes que o corpo da solicitação do cliente seja lido
  • Robustez aprimorada da diretiva worker_shutdown_timeout para conexões HTTP/2 de longa duração
  • Robustez aprimorada 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 anterior, recomendamos atualizar para o NGINX Plus R20 o mais breve possível.

Atualizações no ecossistema NGINX Plus

Módulo JavaScript NGINX

O módulo NGINX JavaScript (njs) foi atualizado para a versão0.3.7 , adicionando suporte para mais objetos JavaScript:

  • Construtor Function()
  • Método Object.assign()
  • Métodos numéricos : toFixed() , toPrecision() e toExponential()
  • Método Array.prototype.copyWithin()
  • Parâmetro de rótulo para o método console.time()

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

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R20 o mais rápido possível. Você também receberá uma série de correções e melhorias adicionais, e isso ajudará o NGINX a ajudar você quando precisar abrir um tíquete de suporte.

Revise cuidadosamente os novos recursos e mudanças de comportamento descritos nesta postagem do blog antes de prosseguir com a atualização.

Se você ainda não experimentou o NGINX Plus, recomendamos que experimente – para segurança, balanceamento de carga e gateway de API, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento. Você pode começar hoje mesmo com um teste gratuito de 30 dias . Veja você mesmo como o NGINX Plus pode ajudar você a entregar e dimensionar seus aplicativos.


"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."