Anunciando o NGINX Plus R15

Temos o prazer de anunciar que a décima quinta versão do NGINX Plus, nosso principal produto, já está disponível. Desde nosso lançamento inicial em 2013 , o NGINX Plus cresceu tremendamente, 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 é o único balanceador de carga, cache de conteúdo, servidor web e gateway de API tudo-em-um . O NGINX Plus inclui recursos aprimorados exclusivos projetados para reduzir a complexidade na arquitetura de aplicativos modernos, juntamente com suporte premiado.

O NGINX Plus R15 apresenta novo suporte a gRPC, push de servidor HTTP/2, suporte aprimorado para clustering, funcionalidade aprimorada de gateway de API e muito mais:

• Suporte nativo a gRPC – gRPC é o novo padrão de chamada de procedimento remoto (RPC) desenvolvido pelo Google. É uma maneira leve e eficiente para clientes e servidores se comunicarem. Com essa nova funcionalidade, o NGINX Plus pode finalizar com SSL, rotear e balancear a carga do tráfego gRPC para seus servidores de backend.
• Push do servidor HTTP/2 – Com o push do servidor HTTP/2, o NGINX Plus pode enviar recursos antes que os clientes realmente os solicitem, melhorando o desempenho e reduzindo viagens de ida e volta.
• Compartilhamento de estado em um cluster – Com esta versão, os dados de memória compartilhada usados para persistência de sessão do Sticky Learn podem ser compartilhados entre todas as instâncias do NGINX Plus em um cluster. Os próximos lançamentos do NGINX Plus aproveitarão nossos recursos de cluster e introduzirão novos recursos com reconhecimento de cluster.
• Integração do OpenID Connect – Agora você pode fornecer logon único (SSO) para qualquer aplicativo da web com o NGINX Plus, usando o OpenID Connect Authorization Code Flow e emitindo JSON Web Tokens (JWTs) para clientes. O NGINX Plus integra-se com CA Single Sign‑On (antigo SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin, Ping Identity e outros provedores de identidade populares.
• Melhorias no módulo NGINX JavaScript (njs) – Os módulos njs (anteriormente nginScript) permitem que você execute código JavaScript durante o processamento de solicitações do NGINX Plus. O módulo njs para HTTP agora fornece suporte para emitir sub-solicitações HTTP que são independentes e assíncronas à solicitação do cliente. Isso é útil em casos de uso de gateway de API, dando a você a flexibilidade de modificar e consolidar chamadas de API usando JavaScript. Os módulos njs para HTTP e TCP/UDP agora também incluem bibliotecas de criptografia que permitem a implementação de funções de hash comuns.

Completando o lançamento, há mais novos recursos , incluindo uma nova variável ALPN, atualizações para vários módulos dinâmicos e muito mais.

Mudanças no comportamento

• O NGINX Plus R13 viu a introdução da novíssima API NGINX Plus, que habilita funções que antes eram implementadas em APIs separadas, incluindo configuração dinâmica de grupos upstream e métricas estendidas. As APIs anteriores, configuradas com as diretivas upstream_conf e status , estão obsoletas. Recomendamos que você verifique sua configuração para essas diretivas e converta para a nova diretiva de API o mais rápido possível (para mais detalhes, consulte Anunciando 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 enviadas.
• A API NGINX Plus foi atualizada para a versão 3 nesta versão. Versões anteriores ainda são suportadas. Se você estiver pensando em atualizar seus clientes de API, consulte a documentação de compatibilidade de API .
• Os pacotes NGINX Plus disponíveis no repositório oficial agora têm um novo esquema de numeração. O pacote NGINX Plus e todos os módulos dinâmicos agora indicam o número da versão do NGINX Plus. Cada versão do pacote agora corresponde à versão do NGINX Plus, para deixar mais claro qual versão está instalada e simplificar as dependências do módulo. Essa alteração é transparente, a menos que você esteja usando sistemas automatizados que referenciam pacotes pelo número de versão. Nesse caso, teste primeiro seu processo de atualização em um ambiente que não seja de produção.

Recursos do NGINX Plus R15 em detalhes

Suporte gRPC

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

O suporte para 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étodo gRPC, permitindo que você:

• Aplique os recursos do NGINX Plus – incluindo criptografia HTTP/2 TLS, limitação de taxa, listas de controle de acesso baseadas em endereço IP e registro – aos serviços gRPC publicados.
• Publique vários serviços gRPC por meio de um único ponto de extremidade inspecionando e fazendo proxy de conexões gRPC para serviços internos.
• Dimensione seus serviços gRPC quando precisar de capacidade adicional por meio do balanceamento de carga de conexões gRPC para pools de backend upstream.
• Use o NGINX Plus como um gateway de API para endpoints gRPC e RESTful.

Para saber mais, consulte Introdução ao suporte ao gRPC com o NGINX 1.13.10 em nosso blog.

Envio de servidor HTTP/2

As primeiras impressões são importantes, e o tempo de carregamento da página é um fator crítico para determinar se os usuários retornarão ao seu site. Uma maneira de fornecer respostas mais rápidas aos usuários é com o envio de servidor HTTP/2, o que reduz o número de RTTs (tempos de ida e volta, o tempo necessário para uma solicitação e resposta) que o usuário precisa esperar.

O push do servidor HTTP/2 foi um recurso muito solicitado e esperado pela comunidade de código aberto NGINX, introduzido no NGINX Open Source 1.13.9. Agora incluído no NGINX Plus R15 , ele permite que um servidor envie preventivamente dados que provavelmente serão necessários para concluir uma solicitação anterior iniciada pelo cliente. Por exemplo, um navegador precisa de uma ampla gama de recursos – folhas de estilo, imagens e assim por diante – para renderizar uma página de site, então pode fazer sentido 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 preparar um cliente com folhas de estilo e imagens que ele precisará para renderizar a página web de demonstração :

Em alguns casos, no entanto, não é possível determinar o conjunto exato de recursos necessários aos clientes, tornando impraticável listar arquivos específicos no arquivo de configuração do NGINX. Nesses casos, o NGINX pode interceptar cabeçalhos de links HTTP e enviar os recursos marcados como pré-carregados neles. Para habilitar a interceptação de cabeçalhos de link , defina a diretiva http2_push_preload como on .

Para saber mais, consulte Introdução ao HTTP/2 Server Push com 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 em sua pilha de aplicativos. O clustering NGINX Plus foi projetado para implantações de produção de missão crítica, onde resiliência e alta disponibilidade são fundamentais. Existem muitas soluções para implantar clustering de alta disponibilidade com o NGINX Plus .

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

• Resiliência de rede usando o pacote keepalived – Lida com failover se um servidor NGINX Plus cair.
• Sincronização de configuração usando o pacote nginx-sync – Garante que a configuração esteja sincronizada em todos os servidores NGINX Plus.

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

Novo módulo zone_sync

Com o compartilhamento de estado, não há 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 de compartilhamento de estado é independente da solução de alta disponibilidade para resiliência de rede. Portanto, um cluster de compartilhamento de estado pode abranger locais físicos.

Um cluster de compartilhamento de estado 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 , como no seguinte:

A diretiva zone_sync permite 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 para que os membros do cluster possam ser identificados pelo nome do host e para que a configuração seja idêntica para cada membro do cluster.

A configuração mínima acima não possui os controles de segurança necessários para proteger dados de sincronização em uma implantação de produção. O seguinte snippet de configuração emprega várias dessas proteções:

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

Compartilhamento de estado para persistência de sessão de aprendizado fixo

O primeiro recurso compatível do NGINX Plus que usa dados de estado compartilhados em um cluster é a persistência de sessão do Sticky Learn . Persistência de sessão significa que solicitações de um cliente são sempre encaminhadas ao servidor que atendeu à primeira solicitação do 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 permite 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 no cluster.

Observe que para que a sincronização de dados de estado funcione corretamente, a configuração em cada nó 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 ).

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

Integração OpenID Connect

Muitas empresas usam soluções de gerenciamento de identidade e acesso (IAM) para gerenciar contas de usuários e fornecer um ambiente de logon único (SSO) para vários aplicativos. Eles geralmente procuram estender o SSO em aplicativos novos e existentes para minimizar a complexidade e o custo.

O NGINX Plus R10 introduziu suporte para validação de tokens OpenID Connect . Nesta versão, estendemos 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 ao cliente. Isso permite a integração com a maioria dos principais provedores de identidade, incluindo CA Single Sign‑On (antigo SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin e Ping Identity. O recurso recém-ampliado também permite que você:

• Estenda o SSO para aplicativos legados sem modificar ou modernizar esses aplicativos
• Integrar SSO em novos aplicativos sem implementar SSO ou autenticação no código do aplicativo
• Elimine o bloqueio do fornecedor; você obtém SSO baseado em padrões sem precisar implantar software de agente de fornecedor IAM proprietário com o aplicativo

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 configuração de exemplo com instruções sobre instalação, configuração e ajuste fino para casos de uso específicos.

Melhorias no módulo JavaScript NGINX

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

• Para usar o objeto de sessão(ões) refatorado( s ) 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 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.

]

Com o módulo JavaScript do NGINX, njs (antigo nginScript), você pode incluir código JavaScript na sua configuração do NGINX para que ele seja avaliado em tempo de execução, à medida que solicitações HTTP ou TCP/UDP são processadas. Isso permite uma ampla gama de casos de uso potenciais, como obter maior controle sobre o tráfego, consolidar funções JavaScript em todos os aplicativos e defender-se contra ameaças de segurança.

O NGINX Plus R15 inclui duas atualizações significativas para njs: sub-solicitações e funções hash .

Sub-solicitações

Agora você pode emitir solicitações HTTP simultâneas que são independentes e assíncronas à solicitação do cliente. Isso permite uma infinidade de casos de uso avançados.

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

A diretiva js_import na configuração correspondente do NGINX Plus lê o código JavaScript de faster_wins.js . Todas as solicitações que correspondem ao local raiz ( / ) são passadas para a função sendFastest() que gera sub-solicitações para os locais /server_one e /server_two . O URI original com parâmetros de consulta é passado para os servidores de backend correspondentes. Ambas as sub-solicitações executam a função de retorno de chamada done . Entretanto, como essa função inclui r.return() , somente a sub-solicitação que for concluída primeiro envia sua resposta ao cliente.

Funções Hash

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

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

Um exemplo de caso de uso para funções hash é adicionar integridade de dados aos cookies do aplicativo. 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.

A configuração do NGINX Plus a seguir utiliza o código njs para validar assinaturas de cookies em solicitações HTTP de entrada e retornar uma mensagem de erro ao cliente se a validação falhar. O NGINX Plus faz proxy da solicitação se a validação for bem-sucedida ou se nenhum cookie estiver presente.

Novos recursos adicionais no NGINX Plus R15

Variável ALPN para os módulos de fluxo

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 para a conexão que está sendo estabelecida, evitando viagens de ida e volta adicionais que podem gerar latência e degradar a experiência do usuário. O caso de uso mais comum para ALPN é atualizar automaticamente conexões de HTTP para HTTP/2 quando tanto o cliente quanto o servidor suportam HTTP/2.

A nova variável 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 na fase de pré-leitura ALPN. Dada a configuração abaixo, um cliente XMPP pode se apresentar por meio do ALPN de forma que o NGINX Plus roteie o tráfego XMPP para o grupo upstream xmpp_backend , o tráfego gRPC para grpc_backend e todo o outro tráfego para http_backend , tudo por meio de um único ponto de extremidade.

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 .

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

Variável de tempo de fila

O NGINX Plus oferece suporte ao enfileiramento upstream para que as solicitações do cliente não precisem ser rejeitadas imediatamente quando todos os servidores no grupo upstream não estiverem disponíveis para aceitar novas solicitações.

Um caso de uso típico para enfileiramento upstream é proteger servidores de backend contra sobrecarga sem ter que rejeitar solicitações imediatamente se 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 na diretiva do servidor . A diretiva queue então coloca solicitações em uma fila quando não há backends disponíveis, seja porque atingiram seu limite de conexão ou porque falharam em uma verificação de integridade .

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

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 na diretiva log_format , introduzido pela primeira vez no NGINX Open Source 1.13.10, especifica que nenhum escape é 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 autenticação de usuários usando um sistema de autenticação LDAP foi atualizada para resolver problemas e corrigir bugs. Confira no GitHub .

Proxying transparente sem privilégio de root

Você pode usar o NGINX Plus como um proxy transparente incluindo o parâmetro transparent na diretiva proxy_bind . Os processos de trabalho agora podem herdar o recurso CAP_NET_RAW Linux do processo mestre para que o NGINX Plus não exija mais privilégios especiais para 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 (não antes da data), exp (data de expiração) ou ambos – a validação do JWT pelo NGINX Plus inclui uma verificação de que o horário atual está dentro do intervalo de tempo 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 começar no futuro. Para definir o desvio máximo aceitável entre os dois relógios, use a diretiva auth_jwt_leeway .

Módulo dinâmico de sinalizador de cookie

O módulo de terceiros para definir sinalizadores de cookies agora está disponível como o módulo dinâmico Cookie-Flag no repositório NGINX e é 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 NGINX ModSecurity WAF

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

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

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

Atualize ou experimente o NGINX Plus

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

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para a versão 15 o mais rápido possível. Você receberá uma série de correções e melhorias, e a atualização nos ajudará a ajudá-lo quando precisar abrir um tíquete de suporte. As instruções de instalação e atualização do NGINX Plus R15 estão disponíveis no portal do cliente .

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 usou o NGINX Plus , recomendamos que experimente – para aceleração da web, balanceamento de carga e entrega de aplicativos, 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.