Anunciando o NGINX Plus R18

Temos o prazer de anunciar que o NGINX Plus Release 18 (R18) 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 R18 simplifica os fluxos de trabalho de configuração para DevOps e melhora a segurança e a confiabilidade dos seus aplicativos em escala.

Mais de 87% dos sites agora usam SSL/TLS para criptografar comunicações pela Internet, contra 66% há apenas três anos. De ponta a ponta A criptografia agora é o padrão de implantação para sites e aplicativos, e a explosão de certificados SSL/TLS significa que algumas empresas estão gerenciando milhares de certificados em ambientes de produção. Isso exige uma abordagem mais flexível para implantar e configurar certificados.

A novidade nesta versão é o suporte para carregamento dinâmico de certificados . Com milhares de certificados, não é escalável definir cada um manualmente na configuração para carregamento do disco. Além de ser um processo tedioso, a configuração se torna incontrolavelmente grande e a inicialização do NGINX Plus inaceitavelmente lenta. Com o NGINX Plus R18 , os certificados SSL/TLS agora podem ser carregados sob demanda sem serem listados individualmente na configuração. Para simplificar ainda mais as implantações automatizadas, os certificados podem ser provisionados com a API NGINX Plus e nem precisam ficar no disco.

Novos recursos adicionais no NGINX Plus R18 incluem:

• Melhorias no OpenID Connect – Continuamos a melhorar nossa implementação de referência com suporte do OpenID Connect, lançada originalmente no NGINX Plus R15 . Nesta versão, adicionamos suporte para tokens de sessão opacos, tokens de atualização e um URL de logout.
• Intervalos de portas para servidores virtuais – Os servidores virtuais NGINX Plus agora podem ser configurados para escutar em um intervalo de portas, por exemplo 80‑90 . Isso permite que o NGINX Plus ofereça suporte a uma gama mais ampla de aplicativos, como FTP passivo, que exigem que intervalos de portas sejam reservados.
• Definição de chave-valor na configuração – O armazenamento de chave-valor do NGINX Plus permite soluções para uma ampla variedade de casos de uso, incluindo lista de negação dinâmica de endereços IP e mitigação dinâmica de DDoS. Agora você pode criar pares de chave-valor diretamente com variáveis na configuração do NGINX Plus, abrindo ainda mais casos de uso.
• Maior flexibilidade para verificações de integridade ativas – As verificações de integridade ativas do NGINX Plus são uma ferramenta poderosa para monitorar a integridade dos sistemas de backend. Com o NGINX Plus R18 , agora você pode testar o valor de qualquer variável NGINX e desligar automaticamente conexões TCP existentes com servidores com falha.

Completando esta versão estão a configuração simplificada para ambientes em cluster e módulos dinâmicos novos e atualizados (incluindo Brotli). As atualizações do ecossistema NGINX Plus incluem organização de código modular com o módulo NGINX JavaScript e instalação direta do Helm do NGINX Ingress Controller oficial para Kubernetes.

Mudanças importantes no comportamento

• APIs obsoletas – O NGINX Plus R13 (agosto de 2017) introduziu a novíssima API NGINX Plus 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 e/ou upstream_conf , você deverá substituí-las pela diretiva api como parte da atualização para o R18.

  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.

• Diretiva listen atualizada – Anteriormente, quando a diretiva listen especificava um nome de host que era resolvido para vários endereços IP, apenas o primeiro endereço IP era usado. Agora, um soquete de escuta é criado para cada endereço IP retornado.

• Alterações no módulo JavaScript NGINX (njs) – O objeto req.response obsoleto foi removido do módulo JavaScript NGINX . Funções declaradas usando a sintaxe function(req,res) que também fazem referência a propriedades do objeto res geram erros de tempo de execução, retornando código de status HTTP500 e uma entrada correspondente no log de erros:

  AAAA / MM / DD hh : mm : ss [erro] 34#34: exceção js: TypeError: não é possível obter a propriedade "return" de undefined

  Como o código JavaScript é interpretado em tempo de execução, o comando de validação sintática nginx -t não detecta a presença de objetos e propriedades inválidos. Você deve verificar cuidadosamente seu código JavaScript e remover esses objetos antes de atualizar para o NGINX Plus R18 .

  Além disso, objetos JavaScript que representam o estado NGINX (por exemplo, r.headersIn ) agora retornam undefined em vez da string vazia quando não há valor para uma determinada propriedade. Essa alteração significa que os objetos JavaScript específicos do NGINX agora se comportam da mesma forma que os objetos JavaScript integrados.

• Sistemas operacionais mais antigos removidos ou a serem removidos:

  • O Amazon Linux 2017.09 não é mais suportado; a versão mais antiga suportada agora é 2018.03
  • CentOS/Oracle Linux/Red Hat Enterprise Linux 7.3 não é mais suportado; a versão mais antiga suportada agora é 7.4
  • O Debian 8.0 será removido no NGINX Plus R19
  • Ubuntu 14.04 será removido no NGINX Plus R19

Novos recursos em detalhes

Carregamento dinâmico de certificado SSL/TLS

Com versões anteriores do NGINX Plus, a abordagem típica para gerenciar certificados SSL/TLS para sites e aplicativos seguros era criar um bloco de servidor separado para cada nome de host, especificando estaticamente o certificado e a chave privada associada como arquivos no disco. (Para facilitar a leitura, usaremos certificado para nos referir ao certificado e à chave pareados a partir de agora.) Os certificados foram então carregados quando o NGINX Plus foi inicializado. Com o NGINX Plus R18 , os certificados podem ser carregados dinamicamente e, opcionalmente, armazenados no armazenamento de chave-valor do NGINX Plus na memória em vez de no disco.

Há dois casos de uso principais para carregamento dinâmico de certificados:

• “Carregamento lento” de certificados do disco
• Armazenando certificados na memória

Em ambos os casos, o NGINX Plus pode executar o carregamento dinâmico de certificados com base no nome do host fornecido pelo Server Name Indication (SNI) como parte do handshake TLS. Isso permite que o NGINX Plus hospede vários sites seguros em uma única configuração de servidor e selecione o certificado apropriado sob demanda para cada solicitação recebida.

Carregamento lento de certificados SSL/TLS do disco

Com o “carregamento lento”, os certificados SSL/TLS são carregados na memória somente quando as solicitações chegam e especificam o nome do host correspondente. Isso simplifica a configuração (eliminando a lista de certificados por nome de host) e reduz a utilização de recursos no host. Com um grande número (milhares) de certificados, pode levar vários segundos para ler todos eles do disco e carregá-los na memória. Além disso, uma grande quantidade de memória é usada quando a configuração do NGINX é recarregada, porque o novo conjunto de processos de trabalho carrega uma nova cópia dos certificados na memória, juntamente com os certificados carregados pelo conjunto anterior de trabalhos. Os certificados anteriores permanecem na memória até que a conexão final estabelecida na configuração antiga seja concluída e os trabalhadores anteriores sejam encerrados. Se a configuração for atualizada com frequência e as conexões do cliente forem duradouras, pode haver várias cópias dos certificados na memória, o que pode levar ao esgotamento da memória.

O carregamento lento de certificados do disco é ideal para implantações com grandes números de certificados e/ou quando as recargas de configuração são frequentes. Por exemplo, empresas de SaaS geralmente atribuem um subdomínio separado para cada cliente. A integração de novos clientes é difícil porque você precisa criar um novo servidor virtual para cada um e, em seguida, copiar a nova configuração e o certificado do cliente para cada instância do NGINX Plus. O carregamento lento elimina a necessidade de alterações de configuração – basta implantar os certificados em cada instância e pronto.

Para oferecer suporte ao carregamento lento, as diretivas ssl_certificate e ssl_certificate_key agora aceitam parâmetros variáveis. A variável deve estar disponível durante o processamento SNI, que ocorre antes da linha de solicitação e dos cabeçalhos serem lidos. A variável mais comumente usada é $ssl_server_name , que contém o nome do host extraído pelo NGINX Plus durante o processamento SNI. O certificado e a chave são lidos do disco durante o handshake TLS no início de cada sessão do cliente e armazenados em cache na memória do sistema de arquivos, reduzindo ainda mais a utilização da memória.

Uma configuração de site seguro se torna tão simples quanto isto:

Essa mesma configuração de servidor pode ser usada para um número ilimitado de sites seguros. Isso tem dois benefícios:

1. Ele elimina o bloco de servidor separado para cada nome de host, tornando a configuração muito menor e, portanto, mais fácil de ler e gerenciar.
2. Elimina a necessidade de recarregar a configuração toda vez que você adiciona um novo nome de host. Quando você precisa recarregar a configuração, é muito mais rápido porque o NGINX Plus não carrega todos os certificados.

Observe que o carregamento lento faz com que o handshake TLS demore de 20 a 30% mais, dependendo do ambiente, devido às chamadas do sistema de arquivos necessárias para recuperar o certificado do disco. No entanto, a latência adicional afeta apenas o handshake – uma vez que a sessão TLS é estabelecida, o processamento da solicitação leva o tempo normal.

Armazenamento de certificado SSL/TLS na memória

Agora você pode armazenar dados de certificado SSL/TLS na memória, no armazenamento de chave-valor do NGINX Plus, bem como em arquivos no disco. Quando o parâmetro para a diretiva ssl_certificate ou ssl_certificate_key começa com o prefixo data:, o NGINX Plus interpreta o parâmetro como dados PEM brutos (fornecidos na forma de uma variável que identifica a entrada no armazenamento de chave-valor onde os dados realmente residem).

Um benefício adicional do armazenamento no repositório de chave-valor em vez de no disco é que as imagens de implantação e os backups não incluem mais cópias da chave privada, que um invasor pode usar para descriptografar todo o tráfego enviado de e para o servidor. Empresas com pipelines de implantação altamente automatizados se beneficiam da flexibilidade de poder usar a API NGINX Plus para inserir certificados programaticamente no armazenamento de chave-valor. Além disso, as empresas que migram aplicativos para um ambiente de nuvem pública, onde não há um módulo de segurança de hardware (HSM) real para proteção de chave privada, se beneficiam da segurança adicional de não armazenar chaves privadas em disco.

Aqui está um exemplo de configuração para carregar certificados do armazenamento de chave-valor:

Uma maneira de carregar certificados e chaves privadas no armazenamento de chave-valor com a API NGINX Plus é executar o seguinte comando curl (somente o início dos dados da chave é mostrado). Se estiver usando o comando curl , lembre-se de fazer uma cópia dos dados PEM e substituir cada quebra de linha por \n ; caso contrário, as quebras de linha serão removidas da carga JSON.

$ curl -d '{"www.example.com":"-----INICIAR CHAVE PRIVADA RSA-----\n..."}' http://localhost:8080/api/4/http/keyvals/ssl_key

Usar o armazenamento de chave-valor para certificados é ideal para implantações em cluster do NGINX Plus, porque você carrega o certificado apenas uma vez para propagação automática no cluster. Para proteger os dados do certificado em si, use a diretiva zone_sync_ssl para criptografar com TLS as conexões entre os membros do cluster. Usar o armazenamento de chave-valor também é ideal para certificados de curta duração ou para automatizar integrações com emissores de certificados como Let's Encrypt e Hashicorp Vault .

Assim como no carregamento lento do disco, o carregamento de certificados do armazenamento de chave-valor acontece durante cada handshake TLS, o que acarreta uma perda de desempenho. Para handshakes TLS mais rápidos, use as diretivas ssl_certificate e ssl_certificate_key com um parâmetro codificado para um arquivo no disco. Além disso, os certificados ECC são mais rápidos que os certificados RSA.

Observe que, embora o armazenamento de chave-valor torne mais difícil para um invasor obter arquivos de chave privada do que no armazenamento em disco, um invasor com acesso de shell ao host NGINX Plus ainda pode acessar chaves carregadas na memória. O armazenamento de chave-valor não protege chaves privadas na mesma extensão que um módulo de segurança de hardware (HSM); para que o NGINX Plus busque chaves de um HSM, use o parâmetro engine: engine-name : key-id na diretiva ssl_certificate_key .

Melhorias no OpenID Connect

O NGINX Plus oferece suporte à autenticação OpenID Connect e ao logon único para aplicativos de back-end por meio de nossa implementação de referência . Isso foi simplificado e aprimorado agora que o armazenamento de chave-valor pode ser modificado diretamente do módulo JavaScript usando variáveis ( veja abaixo ).

A implementação de referência do OpenID Connect agora emite aos clientes tokens de sessão opacos na forma de um cookie do navegador. Os tokens opacos não contêm informações de identificação pessoal sobre o usuário, portanto, nenhuma informação sensível é armazenada no cliente. O NGINX Plus armazena o token de ID real no armazenamento de chave-valor e o substitui pelo token opaco que o cliente apresenta. A validação do JWT é realizada para cada solicitação para que tokens expirados ou inválidos sejam rejeitados.

A implementação de referência do OpenID Connect agora também oferece suporte a tokens de atualização para que tokens de ID expirados sejam atualizados perfeitamente sem exigir interação do usuário. O NGINX Plus armazena o token de atualização enviado por um servidor de autorização no armazenamento de chave-valor e o associa ao token de sessão opaco. Quando o token de ID expira, o NGINX Plus envia o token de atualização de volta ao servidor de autorização. Se a sessão ainda for válida, o servidor de autorização emite um novo token de ID, que é atualizado perfeitamente no armazenamento de chave-valor. Os tokens de atualização possibilitam o uso de tokens de ID de curta duração, o que proporciona maior segurança sem incomodar os usuários.

A implementação de referência do OpenID Connect agora fornece um URL de logout. Quando usuários conectados visitam o URI /logout , seus IDs e tokens de atualização são excluídos do armazenamento de chave-valor, e eles devem se autenticar novamente ao fazer uma solicitação futura.

Intervalos de portas para servidores virtuais

Um bloco de servidor normalmente tem uma diretiva de escuta especificando a única porta na qual o NGINX Plus escuta; se várias portas precisarem ser configuradas, há uma diretiva de escuta adicional para cada uma delas. Com o NGINX Plus R18 , agora você também pode especificar intervalos de portas, por exemplo 80‑90 , quando for inconveniente especificar um grande número de diretivas de escuta individuais.

Os intervalos de portas podem ser especificados para a diretiva de escuta HTTP e a diretiva de escuta TCP/UDP (Stream). A configuração a seguir permite que o NGINX Plus atue como um proxy para um servidor FTP no modo passivo, onde a porta de dados é escolhida entre um grande intervalo de portas TCP.

Esta configuração configura um servidor virtual para fazer proxy de conexões com o servidor FTP na mesma porta em que a conexão foi feita.

Atualizando o armazenamento de valor-chave por meio de variáveis

Quando o armazenamento de chave-valor está habilitado, o NGINX Plus fornece uma variável para os valores armazenados lá com base em uma chave de entrada (normalmente uma parte dos metadados da solicitação). Anteriormente, a única maneira de criar, modificar ou excluir valores no armazenamento de chave-valor era com a API NGINX Plus . Com o NGINX Plus R18 , você pode alterar o valor de uma chave diretamente na configuração, definindo a variável que contém o valor.

O exemplo a seguir usa o armazenamento de chave-valor para manter uma lista de endereços IP de clientes que acessaram o site recentemente, juntamente com o último URI solicitado.

A diretiva set (linha 7) atribui um valor ( $last_uri ) para cada endereço IP do cliente ( $remote_addr ), criando uma nova entrada se estiver ausente ou modificando o valor para refletir o $uri da solicitação atual. Assim, a lista atual de clientes recentes e seus URIs solicitados está disponível com uma chamada para a API NGINX Plus :

$ curl http://localhost:8080/api/4/http/keyvals/recents { "10.19.245.68": "/blog/nginx-plus-r18-released/", "172.16.80.227": "/products/nginx/", "10.219.110.168": "/blog/nginx-unit-1-8-0-now-available" }

Casos de uso mais poderosos podem ser alcançados com extensões de script, como o módulo NGINX JavaScript (njs) e o módulo Lua. Qualquer configuração que utilize njs tem acesso a todas as variáveis, incluindo aquelas apoiadas pelo armazenamento de chave-valor, por exemplo r.variables.last_uri .

Maior flexibilidade para verificações de saúde ativas

As verificações de integridade ativas do NGINX Plus testam rotineiramente os sistemas de back-end para que o tráfego não seja direcionado para sistemas que são conhecidos por não serem íntegros. O NGINX Plus R18 estende esse importante recurso com dois recursos adicionais.

• Suporte para testar variáveis arbitrárias em verificações de integridade
• Capacidade de encerrar sessões TCP após falha na verificação de integridade

Testando Variáveis Arbitrárias em Verificações de Saúde

Ao definir uma verificação de integridade para um aplicativo de backend, você pode usar um bloco de correspondência para especificar o valor esperado para vários aspectos da resposta, incluindo o código de status HTTP e sequências de caracteres nos cabeçalhos e/ou corpo da resposta. Quando a resposta inclui todos os valores esperados, o backend é considerado íntegro.

Para verificações ainda mais complexas, o NGINX Plus R18 agora fornece a diretiva require para testar o valor de qualquer variável – tanto variáveis NGINX padrão quanto variáveis declaradas por você. Isso lhe dá mais flexibilidade ao definir verificações de integridade porque as variáveis podem ser avaliadas com blocos de mapa , expressões regulares e até mesmo extensões de script.

A diretiva require dentro de um bloco match especifica uma ou mais variáveis, todas as quais devem ter um valor diferente de zero para que o teste seja aprovado. A configuração de exemplo a seguir define um servidor upstream saudável como aquele que retorna cabeçalhos indicando que a resposta pode ser armazenada em cache – um cabeçalho Expires com um valor diferente de zero ou um cabeçalho Cache-Control .

Usar blocos de mapa dessa maneira é uma maneira comum de incorporar lógica OR na configuração do NGINX Plus. A diretiva require permite que você aproveite essa técnica em verificações de integridade, bem como execute verificações de integridade avançadas. Verificações de integridade avançadas também podem ser definidas usando o módulo JavaScript (njs) para analisar atributos adicionais das respostas de cada servidor upstream, como tempo de resposta .

Encerrando conexões da camada 4 quando as verificações de integridade falham

Quando o NGINX Plus atua como um balanceador de carga de Camada 4 (L4) para aplicativos TCP/UDP, ele envia dados por proxy em ambas as direções na conexão estabelecida entre o cliente e o servidor de backend. Verificações de integridade ativas são uma parte importante dessa configuração, mas, por padrão, o status de integridade de um servidor de backend é considerado apenas quando um novo cliente tenta estabelecer uma conexão. Se um servidor de backend ficar offline, clientes estabelecidos poderão sofrer um tempo limite ao enviar dados para o servidor.

Com a diretiva proxy_session_drop , nova no NGINX Plus R18 , você pode fechar a conexão imediatamente quando o próximo pacote for recebido ou enviado para o servidor offline. O cliente é forçado a se reconectar, momento em que o NGINX Plus envia suas solicitações por proxy para um servidor backend íntegro.

Quando essa diretiva é habilitada, duas outras condições também acionam o encerramento de conexões existentes: falha de uma verificação de integridade ativa e remoção do servidor de um grupo upstream por qualquer motivo. Isso inclui remoção por meio de pesquisa de DNS, onde um servidor de backend é definido por um nome de host com vários endereços IP, como aqueles fornecidos por um registro de serviço .

Outras melhorias no NGINX Plus R18

Configuração de cluster simplificada

O NGINX Plus oferece suporte à sincronização do estado de tempo de execução em todo o cluster desde o NGINX Plus R15 . O módulo Zone Synchronization atualmente oferece suporte ao compartilhamento de dados de estado sobre sessões persistentes , limitação de taxa e armazenamento de chave-valor em uma implantação em cluster de instâncias do NGINX Plus.

Uma única configuração zone_sync agora pode ser usada para todas as instâncias em um cluster. Anteriormente, você tinha que configurar o endereço IP ou o nome do host de cada membro explicitamente, o que significava que cada instância tinha uma configuração ligeiramente diferente. Agora você pode fazer com que o servidor zone_sync escute em todas as interfaces locais especificando um valor curinga para o parâmetro endereço : porta na diretiva listen . Isso é particularmente valioso ao implantar o NGINX Plus em um cluster dinâmico onde o endereço IP da instância não é conhecido até o momento da implantação.

Usar a mesma configuração em cada instância simplifica muito a implantação em ambientes dinâmicos (por exemplo, com grupos de dimensionamento automático ou clusters em contêineres).

Módulos dinâmicos novos e atualizados

Os seguintes módulos dinâmicos foram adicionados ou atualizados nesta versão:

• Novo módulo de compressão Brotli – Brotli é um algoritmo de compressão de dados sem perdas e de uso geral que usa uma variante do algoritmo LZ77, codificação Huffman e modelagem de contexto de segunda ordem.
• Novo módulo OpenTracing – Agora você pode instrumentar o NGINX Plus com solicitações compatíveis com OpenTracing para uma variedade de serviços de rastreamento distribuídos, como Datadog, Jaeger e Zipkin.
• Módulo Lua atualizado – Lua é uma linguagem de script para NGINX Plus. O módulo agora usa LuaJIT 2.1.

Atualizações do ecossistema NGINX Plus

Melhorias no módulo JavaScript NGINX

O módulo JavaScript NGINX (njs) foi atualizado para a versão 0.3.0 . A melhoria mais notável é o suporte aos módulos de importação e exportação de JavaScript, que permitem organizar seu código JavaScript em vários arquivos específicos de função. Anteriormente, todo o código JavaScript tinha que residir em um único arquivo.

O exemplo a seguir mostra como os módulos JavaScript podem ser usados para organizar e simplificar o código necessário para um caso de uso relativamente simples. Aqui, empregamos JavaScript para realizar o mascaramento de dados para privacidade do usuário, de modo que uma versão com hash (mascarada) do endereço IP do cliente seja registrada em vez do endereço real. Um determinado endereço IP mascarado no log sempre representa o mesmo cliente, mas não pode ser convertido de volta para o endereço IP real.

[ Editor – O exemplo nesta seção é apenas um dos muitos casos de uso do módulo NGINX JavaScript. Para uma lista completa, consulte Casos de uso para o módulo JavaScript NGINX .

O código é atualizado para usar a diretiva js_import , que substitui a diretiva js_include no NGINX Plus R23 e posteriores. Para obter mais informações, consulte a documentação de referência do módulo NGINX JavaScript – a seção Exemplo de configuração mostra a sintaxe correta para a configuração do NGINX e os arquivos JavaScript.

No NGINX Plus R22 e posteriores, além dos módulos de importação e exportação JavaScript , você pode usar a diretiva njs js_import para organizar seu código JavaScript em vários arquivos específicos de função. ]

Colocamos as funções necessárias para o mascaramento de endereço IP em um módulo JavaScript que exporta uma única função, maskIp() . A função exportada depende de funções privadas que estão disponíveis apenas dentro do módulo e não podem ser chamadas por outro código JavaScript.

Este módulo agora pode ser importado para o arquivo JavaScript principal ( main.js ) e as funções exportadas podem ser referenciadas.

Como resultado, main.js é muito simples, contendo apenas as funções referenciadas pela configuração do NGINX. A instrução import especifica um caminho relativo ou absoluto para o arquivo do módulo. Quando um caminho relativo é fornecido, você pode usar a nova diretiva js_path para especificar caminhos adicionais a serem pesquisados.

Os novos recursos melhoram muito a legibilidade e a manutenção, especialmente quando há um grande número de diretivas njs em uso e/ou uma grande quantidade de código JavaScript. Agora, equipes separadas podem manter seu próprio código JavaScript sem precisar realizar uma mesclagem complexa no arquivo JavaScript principal.

Instalação direta do Helm do NGINX Ingress Controller para Kubernetes

Agora você pode instalar o NGINX Ingress Controller para Kubernetes diretamente do nosso novo repositório Helm, sem precisar baixar os arquivos de origem do gráfico Helm (embora isso ainda seja suportado). Para mais informações, consulte o repositório do GitHub .

Correções de bugs notáveis

Limites de largura de banda para aplicações UDP

As diretivas proxy_upload_rate e proxy_download_rate agora funcionam corretamente para datagramas UDP.

Protocolo PROXY TLV com verificação de integridade trava o NGINX

Anteriormente, o NGINX Plus podia travar quando a diretiva health_check era incluída em um local que fazia referência à variável $proxy_protocol_tlv_0xEA , por exemplo, em um ambiente AWS PrivateLink .

Menor tempo de balanceamento de carga ignorado, upstream mais lento

Anteriormente, se um servidor upstream respondesse lentamente por um longo tempo, ele poderia nunca mais ser selecionado porque seu valor para a métrica de tempo especificada era muito alto em comparação com outros servidores upstream. Agora, um servidor upstream anteriormente lento é eventualmente reintroduzido no processo de seleção do balanceador de carga, pois novas medições permitem que a média móvel seja reduzida.

Isso se aplica a algoritmos de balanceamento de carga que usam o tempo de resposta upstream como uma métrica de seleção, especificamente least_time e random com o parâmetro least_time .

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R18 o mais rápido possível. Você também receberá uma série de correções e melhorias adicionais, e isso ajudará a NGINX, Inc. a ajudá-lo 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 uma avaliação gratuita de 30 dias . Veja você mesmo como o NGINX Plus pode ajudar você a entregar e dimensionar seus aplicativos.