Anunciando o NGINX Plus R15

Liam CrillyDiretor Sênior de Gestão de Produtos

Temos o prazer de anunciar que a décima quinta versão do NGINX Plus, nosso principal produto, já está disponível. Desde o nosso lançamento inicial em 2013, o NGINX Plus cresceu enormemente, tanto em seu conjunto de recursos quanto em seu apelo comercial. Agora, há mais de [ngx_snippet name=’nginx-plus-customers’] clientes do NGINX Plus e [ngx_snippet name=’number-sites’] usuários do NGINX Open Source.

Baseado no NGINX Open Source, o NGINX Plus é a única solução completa que reúne balanceador de carga, cache de conteúdo, servidor web e gateway de API. O NGINX Plus inclui recursos avançados exclusivos, desenvolvidos para reduzir a complexidade da arquitetura de aplicações modernas, além de oferecer suporte premiado.

O NGINX Plus R15 apresenta novo suporte a gRPC, push de servidor HTTP/2, suporte aprimorado a clustering, funcionalidades avançadas de gateway de API e muito mais:

• Suporte nativo a gRPC – o gRPC é o novo padrão de chamada de procedimento remoto (RPC) desenvolvido pelo Google. É uma forma leve e eficiente de comunicação entre clientes e servidores. Com essa nova funcionalidade, o NGINX Plus pode encerrar conexões SSL, rotear e balancear a carga do tráfego gRPC para seus servidores de backend.
• Push de servidor HTTP/2 – Com o push de servidor HTTP/2, o NGINX Plus pode enviar recursos antes mesmo que os clientes os solicitem, melhorando o desempenho e reduzindo as idas e vindas.
• Compartilhamento de estado em um cluster – Com esta versão, os dados de memória compartilhada usados para a persistência de sessão Sticky Learn podem ser compartilhados entre todas as instâncias do NGINX Plus em um cluster. As próximas versões do NGINX Plus ampliarão nossos recursos de clustering e introduzirão novos recursos compatíveis com clusters.
• Integração com o OpenID Connect – Agora você pode oferecer logon único (SSO) a qualquer aplicação web com o NGINX Plus, usando o fluxo de código de autorização do OpenID Connect e emitindo JSON Web Tokens (JWTs) para os clientes. O NGINX Plus integra-se ao CA Single Sign‑On (anteriormente SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin, Ping Identity e outros provedores de identidade populares.
• Aprimoramentos do módulo NGINX JavaScript (njs) – Os módulos njs (anteriormente chamados de nginScript) permitem executar código JavaScript durante o processamento de solicitações pelo NGINX Plus. O módulo njs para HTTP agora oferece suporte à emissão de subsolicitações HTTP independentes e assíncronas em relação à solicitação do cliente. Isso é útil em casos de uso de gateway de API, proporcionando flexibilidade para modificar e consolidar chamadas de API usando JavaScript. Os módulos njs para HTTP e TCP/UDP agora também incluem bibliotecas criptográficas que permitem implementar funções hash comuns.

Para completar a versão, há mais novidades, incluindo uma nova variável ALPN, atualizações para vários módulos dinâmicos e muito mais.

Mudanças de comportamento

• O NGINX Plus R13 apresentou a nova API do NGINX Plus, que oferece funções anteriormente implementadas em APIs separadas, incluindo a configuração dinâmica de grupos de upstream e métricas ampliadas. As APIs anteriores, configuradas com as diretivas upstream_conf e status, estão obsoletas. Recomendamos verificar se essas diretivas estão presentes na sua configuração e migrar para a nova diretiva api assim que possível (para obter detalhes, consulte Apresentamos o NGINX Plus R13 em nosso blog). A partir da próxima versão, NGINX Plus R16, as APIs obsoletas não serão mais distribuídas.
• A API do NGINX Plus foi atualizada para a versão 3 nesta versão. As versões anteriores continuam sendo compatíveis. Se você estiver pensando em atualizar seus clientes de API, consulte a documentação de compatibilidade da API.
• Os pacotes do NGINX Plus disponíveis no repositório oficial agora têm um novo esquema de numeração. O pacote do NGINX Plus e todos os módulos dinâmicos agora indicam o número da versão do NGINX Plus. Cada versão de pacote agora corresponde à versão do NGINX Plus, deixando mais claro qual versão está instalada e simplificando as dependências dos módulos. Essa alteração é transparente, a menos que você use sistemas automatizados que façam referência aos pacotes pelo número da versão. Nesse caso, primeiro teste o processo de atualização em um ambiente que não seja de produção.

Recursos do NGINX Plus R15 em detalhes

Suporte a gRPC

Com esta versão, o NGINX Plus pode atuar como proxy e fazer o balanceamento de carga do tráfego gRPC, que muitas organizações já utilizam para a comunicação com microsserviços. O gRPC é uma estrutura de chamada de procedimento remoto (RPC) de código aberto e alto desempenho, desenvolvida pelo Google para proporcionar uma comunicação entre serviços altamente eficiente e de baixa latência. O gRPC exige o uso de HTTP/2, em vez de HTTP 1.1, como mecanismo de transporte, pois os recursos do HTTP/2 – controle de fluxo, multiplexação e transmissão bidirecional de tráfego com baixa latência – são ideais para conectar microsserviços em grande escala.

O NGINX roteia o tráfego gRPC e encerra a conexão SSL

O suporte a gRPC foi introduzido no NGINX Open Source 1.13.10 e agora está incluído no NGINX Plus R15. Agora você pode inspecionar e rotear chamadas de métodos gRPC, o que permite:

• Aplique recursos do NGINX Plus — incluindo criptografia TLS com HTTP/2, limitação de taxa, listas de controle de acesso baseadas em endereços IP e registro em logs — aos serviços gRPC publicados.
• Publique vários serviços gRPC por meio de um único endpoint, inspecionando e encaminhando por proxy as conexões gRPC para serviços internos.
• Escale seus serviços gRPC quando precisar de capacidade adicional, balanceando a carga das conexões gRPC entre os pools de backends upstream.
• Use o NGINX Plus como gateway de API para endpoints gRPC e RESTful.

Para saber mais, consulte Apresentação do suporte a gRPC no NGINX 1.13.10 em nosso blog.

Server Push HTTP/2

As primeiras impressões são importantes, e o tempo de carregamento da página é um fator crucial para determinar se os usuários voltarão a visitar seu site. Uma forma de fornecer respostas mais rápidas aos usuários é usar o server push do HTTP/2, que reduz o número de RTTs (tempos de ida e volta, ou seja, o tempo necessário para uma solicitação e sua resposta) que o usuário precisa aguardar.

O NGINX pode enviar recursos antecipadamente aos clientes para melhorar o desempenho

O server push do HTTP/2 era um recurso muito solicitado e aguardado pela comunidade de código aberto do NGINX, introduzido no NGINX Open Source 1.13.9. Agora incluído no NGINX Plus R15, ele permite que um servidor envie antecipadamente dados que provavelmente serão necessários para concluir uma solicitação anterior iniciada pelo cliente. Por exemplo, um navegador precisa de diversos recursos – folhas de estilo, imagens e assim por diante – para renderizar uma página de um site. Portanto, pode ser conveniente enviar esses recursos imediatamente quando um cliente acessa a página pela primeira vez, em vez de esperar que o navegador os solicite explicitamente.

No exemplo de configuração abaixo, usamos a diretiva http2_push para fornecer antecipadamente ao cliente as folhas de estilo e imagens necessárias para renderizar a página da Web demo:

Carregando exemplo de código…

No entanto, em alguns casos, não é possível determinar o conjunto exato de recursos necessários aos clientes, o que torna inviável listar arquivos específicos no arquivo de configuração do NGINX. Nesses casos, o NGINX pode interceptar os cabeçalhos HTTP Link e enviar por push os recursos marcados como preload neles. Para habilitar a interceptação dos cabeçalhos Link, defina a diretiva http2_push_preload como on.

Carregando exemplo de código…

Para saber mais, confira Apresentamos o HTTP/2 Server Push com o NGINX 1.13.9 em nosso blog.

Compartilhamento de estado em um cluster

Configurar vários servidores NGINX Plus em um cluster de alta disponibilidade torna seus aplicativos mais resilientes e elimina pontos únicos de falha na pilha de aplicativos. O clustering do NGINX Plus foi projetado para implantações de produção de missão crítica, nas quais a resiliência e a alta disponibilidade são fundamentais. Há muitas soluções para implantar clusters de alta disponibilidade com o NGINX Plus.

O suporte a clustering foi introduzido em versões anteriores do NGINX Plus, oferecendo dois níveis de clustering:

• Resiliência de rede usando o pacote keepalived – Gerencia o failover caso um servidor NGINX Plus fique indisponível.
• Sincronização da configuração usando o pacote nginx-sync package – Garante que a configuração esteja sincronizada em todos os servidores NGINX Plus.

O NGINX Plus R15 apresenta um terceiro nível de clustering – o compartilhamento de estado durante a execução, permitindo sincronizar dados em zonas de memória compartilhada entre os nós do cluster. Mais especificamente, os dados armazenados em zonas de memória compartilhada para persistência de sessão Sticky Learn agora podem ser sincronizados entre todos os nós do cluster usando o novo módulo zone_sync para tráfego TCP/UDP.

Novo módulo zone_sync Module

Com o compartilhamento de estado, não há um nó primário – todos os nós são pares e trocam dados em uma topologia de malha completa. Além disso, a solução de cluster com compartilhamento de estado é independente da solução de alta disponibilidade para resiliência da rede. Portanto, um cluster com compartilhamento de estado pode abranger diferentes locais físicos.

Um cluster de compartilhamento de estado do NGINX Plus deve atender a três requisitos:

• Conectividade de rede entre todos os nós do cluster
• Relógios sincronizados
• A configuração em cada nó habilita o módulo zone_sync, conforme mostrado a seguir:

  Carregando exemplo de código…

A diretiva zone_sync habilita a sincronização de zonas de memória compartilhada em um cluster. A diretiva zone_sync_server identifica as outras instâncias do NGINX Plus no cluster. O NGINX Plus oferece suporte à descoberta de serviços DNS, permitindo que os membros do cluster sejam identificados pelo nome do host e que a configuração seja idêntica para todos eles.

A configuração mínima acima não inclui os controles de segurança necessários para proteger os dados de sincronização em uma implantação de produção. O trecho de configuração a seguir emprega várias dessas medidas de proteção:

• Criptografia SSL/TLS dos dados de sincronização
• Autenticação por certificado de cliente, para que cada nó do cluster se identifique perante os demais (TLS mútuo)
• Listas de controle de acesso (ACLs) que usam endereços IP, para que apenas os nós do NGINX Plus na mesma rede física possam se conectar para sincronização

Carregando exemplo de código…

Compartilhamento de estado para persistência de sessão com Sticky Learn

O primeiro recurso compatível do NGINX Plus que usa dados de estado compartilhados em um cluster é a persistência de sessão Sticky Learn. A persistência de sessão significa que as solicitações de um cliente são sempre encaminhadas ao servidor que atendeu à primeira solicitação desse cliente, o que é útil quando o estado da sessão é armazenado no backend.

Na configuração a seguir, a diretiva sticky learn define uma zona de memória compartilhada chamada sessions. O parâmetro sync habilita o compartilhamento de estado em todo o cluster, instruindo o NGINX Plus a publicar mensagens sobre o conteúdo de sua zona de memória compartilhada para os outros nós do cluster.

Observe que, para que a sincronização dos dados de estado funcione corretamente, a configuração de cada nó do NGINX Plus no cluster deve incluir o mesmo bloco upstream, com a diretiva sticky learn, bem como as diretivas que habilitam o módulo zone_sync (descrito acima).

Carregando exemplo de código…

Observação: o suporte a clustering e a persistência de sessão Sticky Learn são exclusivos do NGINX Plus.

Integração com o OpenID Connect

Muitas empresas usam soluções de gerenciamento de identidade e acesso (IAM) para gerenciar contas de usuários e oferecer um ambiente de logon único (SSO) para vários aplicativos. Elas geralmente buscam estender o SSO a aplicativos novos e existentes para minimizar a complexidade e os custos.

“O uso do OpenID Connect com o NGINX Plus nos permitiu integrar de forma rápida e fácil com nosso provedor de identidade e, ao mesmo tempo, simplificar a arquitetura de nossa aplicação.” – Scott Macleod, engenheiro de software, NHS Digital

O NGINX Plus R10 introduziu suporte à validação de tokens do OpenID Connect. Nesta versão, ampliamos esse recurso para que o NGINX Plus também possa controlar o Fluxo de Código de Autorização para autenticação com o OpenID Connect 1.0, comunicando-se com o provedor de identidade e emitindo o token de acesso para o cliente. Isso permite a integração com a maioria dos principais provedores de identidade, incluindo CA Single Sign‑On (anteriormente SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin e Ping Identity. O recurso recém-ampliado também permite:

• Estender o SSO a aplicações legadas sem modificá-las ou modernizá-las
• Integre o SSO a novos aplicativos sem implementar o SSO ou a autenticação no código do aplicativo
• Elimine a dependência de fornecedor; você obtém SSO baseado em padrões sem precisar implantar, junto ao aplicativo, um software de agente proprietário do fornecedor de IAM

A integração do OpenID Connect com o NGINX Plus está disponível como uma implementação de referência no GitHub. O repositório do GitHub inclui uma configuração de exemplo com instruções de instalação, configuração e ajustes para casos de uso específicos.

Aprimoramentos no módulo JavaScript do NGINX

[Editor – Os exemplos a seguir são apenas alguns 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 nesta seção foi atualizado da seguinte forma para refletir as alterações na implementação do NGINX JavaScript desde a publicação original do blog:

• Para usar o objeto de sessão (s) refatorado para o módulo Stream, que foi introduzido no NGINX JavaScript 0.2.4.
• Para usar a diretiva js_import, 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 os arquivos JavaScript.

]

Com o módulo JavaScript do NGINX, o njs (anteriormente chamado nginScript), você pode incluir código JavaScript na configuração do NGINX para que ele seja avaliado em tempo de execução, à medida que as solicitações HTTP ou TCP/UDP são processadas. Isso possibilita uma ampla variedade de casos de uso, como obter um controle mais preciso sobre o tráfego, consolidar funções JavaScript entre aplicações e proteger-se contra ameaças à segurança.

O NGINX Plus R15 inclui duas atualizações importantes para o njs: subsolicitações e funções de hash.

Subsolicitações

Agora você pode fazer solicitações HTTP simultâneas, independentes e assíncronas em relação à solicitação do cliente. Isso possibilita uma grande variedade de casos de uso avançados.

O código JavaScript de exemplo a seguir envia uma solicitação HTTP simultaneamente para dois backends diferentes. A primeira resposta é enviada ao NGINX Plus para ser encaminhada ao cliente, e a segunda resposta é ignorada.

Carregando exemplo de código…

A diretiva js_import na configuração correspondente do NGINX Plus lê o código JavaScript de fastest_wins.js. Todas as solicitações que correspondem ao local raiz (/) são encaminhadas para a função sendFastest(), que gera subsolicitações para os locais /server_one e /server_two. O URI original com os parâmetros de consulta é encaminhado aos servidores de backend correspondentes. Ambas as subsolicitações executam a função de callback done. No entanto, como essa função inclui r.return(), somente a subsolicitação que for concluída primeiro enviará sua resposta ao cliente.

Carregando exemplo de código…

Funções de hash

Os módulos njs para tráfego HTTP e TCP/UDP agora incluem uma biblioteca criptográfica com implementações de:

• Funções de hash: MD5, SHA‑1, SHA‑256
• HMAC usando: MD5, SHA‑1, SHA‑256
• Formatos de resumo: Base64, Base64URL, hexadecimal

Um exemplo de uso de funções hash é garantir a integridade dos dados dos cookies da aplicação. O exemplo de código njs a seguir inclui uma função signCookie() para adicionar uma assinatura digital a um cookie e uma função validateCookieSignature() para validar cookies assinados.

Carregando exemplo de código…

A configuração do NGINX Plus a seguir utiliza o código njs para validar as assinaturas de cookies nas solicitações HTTP recebidas e retornar uma mensagem de erro ao cliente caso a validação falhe. O NGINX Plus encaminha a solicitação por proxy se a validação for bem-sucedida ou se nenhum cookie estiver presente.

Carregando exemplo de código…

Novos recursos adicionais no NGINX Plus R15

Variável ALPN para os módulos Stream

A Negociação de Protocolo da Camada de Aplicação (ALPN) é uma extensão do TLS que permite que um cliente e um servidor negociem, durante o handshake TLS, qual protocolo será usado na conexão que está sendo estabelecida, evitando viagens de ida e volta adicionais que poderiam aumentar a latência e prejudicar a experiência do usuário. O caso de uso mais comum da ALPN é atualizar automaticamente as conexões de HTTP para HTTP/2 quando tanto o cliente quanto o servidor oferecem suporte a HTTP/2.

A nova variável do NGINX $ssl_preread_alpn_protocols, introduzida pela primeira vez no NGINX Open Source 1.13.10, captura a lista de protocolos anunciados pelo cliente em sua mensagem ClientHello durante a fase de leitura prévia do ALPN. Com a configuração abaixo, um cliente XMPP pode se identificar por meio do ALPN, permitindo que o NGINX Plus encaminhe o tráfego XMPP para o grupo upstream xmpp_backend, o tráfego gRPC para grpc_backend e todo o restante do tráfego para http_backend, tudo por meio de um único endpoint.

Para permitir que o NGINX Plus extraia informações da mensagem ClientHello e preencha a variável $ssl_preread_alpn_protocols, você também deve incluir a diretiva ssl_preread on.

Carregando exemplo de código…

Para saber mais, consulte a documentação do módulo ngx_stream_ssl_preread.

Variável de tempo na fila

O NGINX Plus oferece suporte a enfileiramento upstream para que as solicitações dos clientes não precisem ser rejeitadas imediatamente quando nenhum servidor do grupo upstream estiver disponível para aceitar novas solicitações.

Um caso de uso típico para o enfileiramento de upstream é proteger os servidores de backend contra sobrecarga sem precisar rejeitar solicitações imediatamente quando todos os servidores estiverem ocupados. Você pode definir o número máximo de conexões simultâneas para cada servidor upstream com o parâmetro max_conns da diretiva server. A diretiva queue coloca as solicitações em uma fila quando não há backends disponíveis, seja porque atingiram o limite de conexões ou porque falharam em uma verificação de integridade.

Nesta versão, a nova variável do NGINX $upstream_queue_time, introduzida pela primeira vez no NGINX Open Source 1.13.9, registra quanto tempo uma solicitação permanece na fila. A configuração abaixo inclui um formato de log personalizado que registra várias métricas de tempo para cada solicitação; essas métricas podem então ser analisadas offline como parte do ajuste de desempenho. Limitamos a 20 o número de solicitações na fila para o grupo upstream my_backend. O parâmetro timeout define por quanto tempo as solicitações permanecem na fila antes que uma mensagem de erro seja retornada ao cliente (503 por padrão). Aqui, definimos esse tempo como 5 segundos (o padrão é 60 segundos).

Carregando exemplo de código…

Para saber mais, consulte a documentação da diretiva queue.

Logs de acesso sem escape

Agora você pode desabilitar o escape no log de acesso do NGINX Plus. O novo parâmetro escape=none da diretiva log_format, introduzido pela primeira vez no NGINX Open Source 1.13.10, especifica que nenhum escape seja aplicado a caracteres especiais em variáveis.

Atualização da implementação de referência de autenticação LDAP

Nossa implementação de referência para autenticar usuários por meio de um sistema de autenticação LDAP foi atualizada para solucionar problemas e corrigir bugs. Confira no GitHub.

Proxy transparente sem privilégios de root

Você pode usar o NGINX Plus como um proxy transparente incluindo o parâmetro transparent na diretiva proxy_bind. Agora, os processos de trabalho podem herdar o recurso CAP_NET_RAW do Linux do processo mestre, de modo que o NGINX Plus não precise mais de privilégios especiais para o proxy transparente.

Observação: este recurso se aplica somente a plataformas Linux.

Período de carência do JWT

Se um JWT incluir uma declaração baseada em tempo – nbf (data de início da validade), exp (data de expiração) ou ambas – a validação do JWT pelo NGINX Plus verificará se o horário atual está dentro do intervalo especificado. No entanto, se o relógio do provedor de identidade não estiver sincronizado com o relógio da instância do NGINX Plus, os tokens poderão expirar inesperadamente ou parecer que sua validade começa no futuro. Para definir a diferença máxima aceitável entre os dois relógios, use a diretiva auth_jwt_leeway.

Módulo dinâmico Cookie Flag

O módulo de terceiros para definir atributos de cookies agora está disponível como o módulo dinâmico Cookie-Flag no repositório do NGINX e está coberto pelo seu contrato de suporte do NGINX Plus. Você pode usar sua ferramenta de gerenciamento de pacotes para instalá-lo:

$ apt-get install nginx-plus-module-cookie-flag # Ubuntu/Debian$ yum install nginx-plus-module-cookie-flag     # Red Hat/CentOS

Atualização do módulo WAF NGINX ModSecurity

NGINX ModSecurity WAF, um módulo dinâmico para o NGINX Plus baseado no ModSecurity 3.0, foi atualizado com as seguintes melhorias:

• Melhorias de desempenho no libmodsecurity
• Correções de vazamentos de memória no ModSecurity-nginx

[Editor – O NGINX ModSecurity WAF saiu oficialmente de comercialização em 1º de abril de 2022 e está em transição para o fim da vida útil, que entrará em vigor em 31 de março de 2024. Para mais detalhes, consulte O F5 NGINX ModSecurity WAF está em transição para o fim da vida útil<.htmla> em nosso blog.]

Faça upgrade ou experimente o NGINX Plus

O NGINX Plus R15 inclui recursos aprimorados de autenticação para seus aplicativos clientes, recursos adicionais de clustering, melhorias no njs e correções de bugs importantes.

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para a versão 15 o mais rápido possível. Você terá acesso a diversas correções e melhorias, e a atualização nos ajudará a oferecer um suporte melhor quando você precisar abrir um chamado. As instruções de instalação e atualização do NGINX Plus R15 estão disponíveis no portal do cliente.

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

Se você ainda não usou o NGINX Plus, recomendamos que experimente a solução para aceleração da Web, balanceamento de carga e entrega de aplicações, ou como um servidor Web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Comece hoje mesmo gratuitamente 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