Anunciando o NGINX Plus R18

Liam CrillyDiretor Sênior de Gestão de Produtos

Temos o prazer de anunciar que o NGINX Plus Release 18 (R18) 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 R18 simplifica os fluxos de trabalho de configuração para DevOps e aumenta a segurança e a confiabilidade das suas aplicações em escala.

Mais de 87% dos sites agora usam SSL/TLS para criptografar as comunicações pela Internet, em comparação com 66% há apenas três anos. A criptografia de ponta a ponta agora é o padrão de implantação para sites e aplicativos, e o aumento vertiginoso no número de certificados SSL/TLS faz com que algumas empresas gerenciem muitos milhares de certificados em ambientes de produção. Isso exige uma abordagem mais flexível para implantar e configurar certificados.

Esta versão passa a oferecer suporte ao carregamento dinâmico de certificados. Com milhares de certificados, não é viável definir cada um manualmente na configuração para carregamento a partir do disco. Além de ser um processo trabalhoso, a configuração se torna grande demais para ser gerenciada, e a inicialização do NGINX Plus fica inaceitavelmente lenta. Com o NGINX Plus R18, os certificados SSL/TLS agora podem ser carregados sob demanda, sem precisar ser listados individualmente na configuração. Para simplificar ainda mais as implantações automatizadas, os certificados podem ser provisionados por meio da API do NGINX Plus e nem sequer precisam estar armazenados em disco.

Outros novos recursos do NGINX Plus R18 incluem:

• Aprimoramentos do OpenID Connect – Continuamos aprimorando nossa implementação de referência compatível com OpenID Connect, lançada originalmente no NGINX Plus R15. Nesta versão, adicionamos suporte a tokens de sessão opacos, tokens de atualização e uma URL de logout.
• Intervalos de portas para servidores virtuais – Agora, os servidores virtuais do NGINX Plus 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 variedade maior de aplicações, como FTP passivo, que exigem a reserva de intervalos de portas.
• Definição de chave-valor na configuração – O armazenamento de chave-valor do NGINX Plus permite criar soluções para uma ampla variedade de casos de uso, incluindo a inclusão dinâmica de endereços IP em listas de bloqueio e a mitigação dinâmica de ataques DDoS. Agora, você pode criar pares de chave-valor diretamente com variáveis na configuração do NGINX Plus, possibilitando ainda mais casos de uso.
• Maior flexibilidade para verificações ativas de integridade – As verificações ativas de integridade 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 do NGINX e encerrar automaticamente as conexões TCP existentes com servidores que apresentarem falha.

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

Mudanças importantes de comportamento

• APIs obsoletas – O NGINX Plus R13 (agosto de 2017) introduziu a nova API do NGINX Plus 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 e/ou upstream_conf, você deverá substituí-las pela diretiva api como parte da atualização para a R18. 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.
• 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 do NGINX (njs) – O objeto obsoleto req.response foi removido do módulo JavaScript do NGINX. As funções declaradas usando a sintaxe function(req,res) que também fazem referência às propriedades do objeto res geram erros de tempo de execução, retornando o código de status HTTP 500 e uma entrada correspondente no log de erros:

YYYY/MM/DD hh:mm:ss [error] 34#34: js exception: TypeError: cannot get property "return" of 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 fazer upgrade para o NGINX Plus R18. Além disso, os objetos JavaScript que representam o estado do NGINX (por exemplo, r.headersIn) agora retornam undefined em vez de uma 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 nativos.
• Sistemas operacionais mais antigos removidos ou a serem removidos:
  • O Amazon Linux 2017.09 não é mais compatível; a versão mais antiga atualmente compatível é a 2018.03
  • O CentOS/Oracle Linux/Red Hat Enterprise Linux 7.3 não é mais compatível; a versão mais antiga atualmente compatível é a 7.4
  • O Debian 8.0 será removido no NGINX Plus R19
  • O Ubuntu 14.04 será removido no NGINX Plus R19

Novos recursos em detalhes

Carregamento dinâmico de certificados SSL/TLS

Nas versões anteriores do NGINX Plus, a abordagem típica para gerenciar certificados SSL/TLS de sites e aplicações seguros era criar um bloco server separado para cada nome de host, especificando estaticamente o certificado e a chave privada associada como arquivos em disco. (Para facilitar a leitura, daqui em diante usaremos certificado para nos referirmos ao par formado pelo certificado e pela chave.) Os certificados eram então carregados durante a inicialização do NGINX Plus. Com o NGINX Plus R18, os certificados podem ser carregados dinamicamente e, opcionalmente, armazenados no repositório de chave-valor em memória do NGINX Plus, em vez de no disco.

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

• “Carregamento sob demanda” de certificados do disco
• Armazenamento de certificados na memória

Em ambos os casos, o NGINX Plus pode realizar o carregamento dinâmico de certificados com base no nome do host fornecido pela Indicação de Nome do Servidor (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, sob demanda, o certificado apropriado para cada solicitação recebida.

Carregamento sob demanda de certificados SSL/TLS a partir do disco

Com o “carregamento sob demanda”, os certificados SSL/TLS são carregados na memória somente à medida que as solicitações chegam e especificam o nome de host correspondente. Isso simplifica a configuração (eliminando a lista de certificados por nome de host) e reduz o uso de recursos no host. Quando há um grande número de certificados (muitos milhares), 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, pois o novo conjunto de processos de trabalho carrega na memória uma nova cópia dos certificados, juntamente com os certificados carregados pelo conjunto anterior de processos de trabalho. Os certificados anteriores permanecem na memória até que a última conexão estabelecida com a configuração antiga seja encerrada e os processos de trabalho anteriores sejam finalizados. Se a configuração for atualizada com frequência e as conexões dos clientes forem de longa duração, poderá haver várias cópias dos certificados na memória, o que pode levar ao esgotamento da memória.

O carregamento sob demanda de certificados a partir do disco é ideal para implantações com um grande número de certificados e/ou quando as configurações são recarregadas com frequência. Por exemplo, empresas de SaaS geralmente atribuem um subdomínio separado a cada cliente. Integrar novos clientes é difícil porque é necessário 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 sob demanda elimina a necessidade de alterar a configuração: basta implantar os certificados em cada instância e pronto.

Para oferecer suporte ao carregamento sob demanda, as diretivas ssl_certificate e ssl_certificate_key agora aceitam parâmetros variáveis. A variável deve estar disponível durante o processamento de SNI, que ocorre antes da leitura da linha da solicitação e dos cabeçalhos. A variável mais usada é $ssl_server_name, que contém o nome do host extraído pelo NGINX Plus durante o processamento de 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 memória no cache do sistema de arquivos, reduzindo ainda mais o uso de memória.

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

Carregando exemplo de código…

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

1. Isso elimina o bloco server separado para cada nome de host, tornando a configuração muito menor e, portanto, mais fácil de ler e gerenciar.
2. Isso elimina a necessidade de recarregar a configuração sempre que você adiciona um novo nome de host. Quando for necessário recarregá-la, o processo será muito mais rápido, pois o NGINX Plus não carregará todos os certificados.

Observe que o carregamento sob demanda faz com que o handshake TLS demore de 20% a 30% mais, dependendo do ambiente, devido às chamadas ao sistema de arquivos necessárias para recuperar o certificado do disco. No entanto, a latência adicional afeta apenas o handshake – depois que a sessão TLS é estabelecida, o processamento das solicitações leva o tempo habitual.

Armazenamento de certificados SSL/TLS na memória

Agora você pode armazenar os dados de certificados SSL/TLS na memória, no armazenamento de chave-valor do NGINX Plus, bem como em arquivos no disco. Quando o parâmetro da 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 em que os dados realmente residem).

Outro benefício de armazenar os dados no repositório de chave-valor, em vez de no disco, é que as imagens de implantação e os backups deixam de incluir cópias da chave privada, que poderiam ser usadas por um invasor para descriptografar todo o tráfego enviado ao servidor e recebido dele. Empresas com pipelines de implantação altamente automatizados se beneficiam da flexibilidade de poder usar a API do NGINX Plus para inserir certificados de forma programática no repositório de chave-valor. Além disso, empresas que estão migrando aplicações para um ambiente de nuvem pública sem um módulo de segurança de hardware (HSM) físico para proteger chaves privadas se beneficiam da segurança adicional proporcionada pelo fato de não armazená-las no disco.

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

Carregando exemplo de código…

Uma maneira de enviar certificados e chaves privadas para o armazenamento de chave-valor usando a API do NGINX Plus é executar o seguinte comando curl (apenas o início dos dados da chave é mostrado). Se você usar 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 do payload JSON.

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

O uso do armazenamento de chave-valor para certificados é ideal para implantações em cluster do NGINX Plus, pois basta carregar o certificado uma única vez para que ele seja propagado automaticamente por todo o cluster. Para proteger os próprios dados do certificado, use a diretiva zone_sync_ssl para criptografar com TLS as conexões entre os membros do cluster. 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 ocorre com o carregamento sob demanda a partir do disco, o carregamento de certificados do armazenamento de chave-valor acontece durante cada handshake TLS, o que acarreta uma perda de desempenho. Para obter handshakes TLS mais rápidos, use as diretivas ssl_certificate e ssl_certificate_key com um parâmetro fixo que aponte para um arquivo no disco. Além disso, os certificados ECC são mais rápidos do que os certificados RSA.

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

Aprimoramentos do OpenID Connect

O NGINX Plus oferece suporte à autenticação OpenID Connect e ao logon único para aplicações de backend por meio da nossa implementação de referência. Esse processo foi simplificado e aprimorado, pois agora o armazenamento de chave-valor pode ser modificado diretamente no módulo JavaScript usando variáveis (veja abaixo).

A implementação de referência do OpenID Connect agora fornece 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 do usuário, portanto, nenhuma informação confidencial é armazenada no cliente. O NGINX Plus armazena o token de ID real no armazenamento de chave-valor e o substitui pelo token opaco apresentado pelo cliente. A validação do JWT é realizada em todas as solicitações 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, permitindo que tokens de ID expirados sejam atualizados de forma transparente, sem exigir a 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 emitirá um novo token de ID, que será atualizado de forma transparente no armazenamento de chave-valor. Os tokens de atualização permitem usar tokens de ID de curta duração, o que proporciona mais segurança sem causar inconvenientes aos usuários.

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

Intervalos de portas para servidores virtuais

Um bloco server normalmente tem uma diretiva listen que especifica a única porta na qual o NGINX Plus escuta; se for necessário configurar várias portas, haverá uma diretiva listen adicional para cada uma delas. Com o NGINX Plus R18, agora também é possível especificar intervalos de portas, por exemplo, 80‑90, quando não for conveniente especificar um grande número de diretivas listen individuais.

É possível especificar intervalos de portas tanto para a diretiva HTTP listen quanto para a diretiva TCP/UDP (Stream) listen. A configuração a seguir permite que o NGINX Plus atue como proxy para um servidor FTP no modo passivo, em que a porta de dados é escolhida em um amplo intervalo de portas TCP.

Carregando exemplo de código…

Essa configuração cria um servidor virtual para encaminhar conexões ao servidor FTP pela mesma porta em que a conexão foi recebida.

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

Quando o armazenamento de chave-valor está habilitado, o NGINX Plus fornece uma variável para os valores armazenados nele 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 por meio da API do 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 dos endereços IP dos clientes que acessaram o site recentemente, juntamente com o último URI solicitado por eles.

Carregando exemplo de código…

A diretiva set (linha 7) atribui um valor ($last_uri) a cada endereço IP de cliente ($remote_addr), criando uma nova entrada caso ela não exista ou modificando o valor para refletir o $uri da solicitação atual. Assim, a lista atual de clientes recentes e seus URIs solicitados fica disponível por meio de uma chamada à API do 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 avançados podem ser implementados com extensões de script, como o módulo JavaScript do NGINX (njs) e o módulo Lua. Qualquer configuração que utilize o njs tem acesso a todas as variáveis, inclusive às armazenadas no repositório de chave-valor, por exemplo, r.variables.last_uri.

Maior flexibilidade para verificações ativas de integridade

Os health checks ativos do NGINX Plus testam rotineiramente os sistemas de backend, para que o tráfego não seja direcionado a sistemas que estejam comprovadamente indisponíveis. O NGINX Plus R18 amplia esse importante recurso com duas funcionalidades adicionais.

• Suporte ao teste de variáveis arbitrárias em verificações de integridade
• Capacidade de encerrar sessões TCP em caso de falha na verificação de integridade

Testando variáveis arbitrárias em verificações de integridade

Ao definir uma verificação de integridade para uma aplicação de backend, você pode usar um bloco match para especificar o valor esperado de vários aspectos da resposta, incluindo o código de status HTTP e as cadeias de caracteres nos cabeçalhos e/ou no 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 oferece a diretiva require para testar o valor de qualquer variável, tanto as variáveis padrão do NGINX quanto as que você declara. Isso proporciona mais flexibilidade na definição de verificações de integridade, pois as variáveis podem ser avaliadas com blocos map, 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. O exemplo de configuração a seguir define como íntegro um servidor upstream que retorna cabeçalhos indicando que a resposta pode ser armazenada em cache – seja um cabeçalho Expires com um valor diferente de zero ou um cabeçalho Cache-Control.

Carregando exemplo de código…

Usar blocos map dessa forma é uma maneira comum de incorporar a lógica OR à configuração do NGINX Plus. A diretiva require permite aproveitar essa técnica nas verificações de integridade, bem como realizar verificações de integridade avançadas. Também é possível definir verificações de integridade avançadas usando o módulo JavaScript (njs) para analisar outros atributos das respostas de cada servidor upstream, como o tempo de resposta.

Encerramento de 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 aplicações TCP/UDP, ele encaminha os dados em ambas as direções pela conexão estabelecida entre o cliente e o servidor de backend. As verificações ativas de integridade são uma parte importante dessa configuração, mas, por padrão, o status de integridade de um servidor de backend só é considerado quando um novo cliente tenta estabelecer uma conexão. Se um servidor de backend ficar offline, os clientes já conectados poderão enfrentar um tempo limite ao enviar dados para o servidor.

Com a diretiva proxy_session_drop, introduzida no NGINX Plus R18, você pode fechar imediatamente a conexão quando o próximo pacote for recebido do servidor offline ou enviado a ele. O cliente é forçado a se reconectar e, nesse momento, o NGINX Plus encaminha suas solicitações para um servidor de backend íntegro.

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

Outras melhorias no NGINX Plus R18

Configuração simplificada de clustering

O NGINX Plus oferece suporte à sincronização do estado de execução em todo o cluster desde o NGINX Plus R15. Atualmente, o módulo Sincronização de Zonas permite compartilhar dados de estado sobre sessões persistentes, limitação de taxa, e o armazenamento de chave-valor em uma implantação em cluster de instâncias do NGINX Plus.

Uma única configuração de zone_sync agora pode ser usada para todas as instâncias de um cluster. Antes, era necessário configurar explicitamente o endereço IP ou o nome do host de cada membro, o que fazia com que cada instância tivesse uma configuração ligeiramente diferente. Agora, é possível fazer com que o servidor zone_sync escute em todas as interfaces locais especificando um valor curinga para o parâmetro endereço:porta da diretiva listen. Isso é particularmente útil ao implantar o NGINX Plus em um cluster dinâmico no qual o endereço IP da instância só é conhecido no momento da implantação.

Usar a mesma configuração em todas as instâncias 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 compactação Brotli – O Brotli é um algoritmo de compactação de dados sem perdas e de uso geral que utiliza uma variante do algoritmo LZ77, codificação de 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 o OpenTracing para diversos serviços de rastreamento distribuído, como Datadog, Jaeger e Zipkin.
• Atualizado módulo Lua – Lua é uma linguagem de script para o NGINX Plus. O módulo agora usa o LuaJIT 2.1.

Atualizações no ecossistema do NGINX Plus

Aprimoramentos no módulo JavaScript do NGINX

O módulo JavaScript do NGINX (njs) foi atualizado para a versão 0.3.0. A melhoria mais significativa é o suporte aos módulos import e export do JavaScript, que permite organizar seu código JavaScript em vários arquivos específicos para cada função. Anteriormente, todo o código JavaScript precisava estar 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, usamos JavaScript para realizar a mascaramento de dados para proteger a 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 novamente no endereço IP real.

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

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

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

Colocamos as funções necessárias para mascarar endereços 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.

Carregando exemplo de código…

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

Carregando exemplo de código…

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 outros caminhos a serem pesquisados.

Carregando exemplo de código…

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 distintas podem manter seu próprio código JavaScript sem precisar realizar uma mesclagem complexa no arquivo JavaScript principal.

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

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 chart Helm (embora essa opção ainda seja compatível). Para obter mais informações, consulte o repositório do GitHub.

Correções de bugs importantes

Limites de largura de banda para aplicações UDP

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

TLV do protocolo PROXY com verificação de integridade causa falha no NGINX

Anteriormente, o NGINX Plus podia falhar 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 do AWS PrivateLink.

O balanceamento de carga por menor tempo ignorava o upstream mais lento

Anteriormente, se um servidor upstream respondesse com lentidão suficiente por um longo período, ele poderia nunca mais ser selecionado, pois seu valor para a métrica de tempo especificada era muito alto em comparação com o de outros servidores upstream. Agora, um servidor upstream que antes apresentava lentidão acaba sendo reinserido no processo de seleção do balanceador de carga à medida que novas medições permitem reduzir a média móvel.

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

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 R18 o mais rápido possível. Você também terá acesso a diversas correções e melhorias adicionais, além de facilitar o atendimento da NGINX, Inc. quando precisar abrir um chamado de suporte.

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. Você pode começar 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 seus aplicativos.

Sobre o autor

Liam CrillyDiretor Sênior de Gestão de Produtos

Mais publicações de Liam Crilly