BLOG | NGINX

Anunciando o NGINX Plus R12

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Owen Garrett
Owen Garrett
Publicado em 14 de março de 2017

[Editor – Esta postagem foi atualizada para fazer referência à API NGINX Plus , que substitui e desaprova os módulos separados de configuração dinâmica e status discutidos na versão original da postagem.]

Hoje temos o prazer de anunciar que o NGINX Plus R12 está disponível como uma atualização gratuita para todos os assinantes do NGINX Plus. O NGINX Plus é uma plataforma de entrega de aplicativos de software de alto desempenho que inclui um balanceador de carga, cache de conteúdo e servidor web. O NGINX Plus R12 é uma versão significativa com novos recursos focados em clustering, personalização e monitoramento.

Para saber mais sobre o NGINX Plus R12, assista ao nosso webinar sob demanda .

Usuários corporativos se beneficiarão do novo recurso de cluster, que simplifica o processo de gerenciamento de clusters de alta disponibilidade de servidores NGINX Plus. Todos os usuários se beneficiarão do suporte oficial ao nginScript, uma linguagem de script leve e de alto desempenho que é incorporada diretamente na configuração do NGINX. Melhorias no monitoramento e instrumentação, armazenamento em cache e verificações de integridade melhoram a confiabilidade e o desempenho dos aplicativos.

Outros aprimoramentos incluem autenticação de certificado de cliente para serviços TCP, a capacidade de inspecionar campos personalizados em JWTs OAuth, suporte para o formato WebP no módulo Image-Filter e uma série de melhorias de desempenho e estabilidade.

Incentivamos todos os assinantes a atualizar para o NGINX Plus R12 imediatamente para aproveitar as melhorias de desempenho, funcionalidade e confiabilidade desta versão. Antes de executar a atualização, certifique-se de revisar as alterações de comportamento listadas na próxima seção.

Mudanças no comportamento

O NGINX Plus R12 apresenta algumas alterações no comportamento padrão e nos componentes internos do NGINX Plus que você precisa estar ciente ao atualizar:

  • Formato de metadados de cache – O formato do cabeçalho de metadados de cache interno foi alterado. Ao atualizar para o NGINX Plus R12, o cache no disco se torna inválido e o NGINX Plus atualiza automaticamente o cache conforme necessário. Entradas de cache antigas são excluídas automaticamente.
  • Variáveis SSL “DN” – O formato das variáveis $ssl_client_s_dn e $ssl_client_i_dn foi alterado. A vírgula ( , ) agora serve como separador de campo em vez da barra ( / ) e é escapada de acordo com RFCs2253 e4514 . Para continuar usando o formato X509_NAME_oneline com o separador de campo barra, use as variáveis $ssl_client_s_dn_legacy e $ssl_client_i_dn_legacy .
  • Fila máxima de conexões – A diretiva queue informa ao NGINX Plus para enfileirar conexões com servidores upstream se eles estiverem sobrecarregados . Como consequência das otimizações de memória e desempenho no R12, a diretiva queue agora deve aparecer no bloco upstream abaixo da diretiva que especifica o algoritmo de balanceamento de carga ( hash , ip_hash , least_conn ou least_time ).
  • Módulos dinâmicos de terceiros – Módulos dinâmicos criados ou certificados pela NGINX, Inc. são fornecidos em nosso repositório. Todos os módulos de terceiros devem ser recompilados com o NGINX Open Source versão 1.11.10 para continuar funcionando com o NGINX Plus R12. Consulte o Guia de administração do NGINX Plus para obter mais informações.
  • Lançamento final para versões de fim de vida do sistema operacional – O Ubuntu anunciou o fim da vida útil do Ubuntu 12.04 LTS , e a Red Hat anunciou o fim da vida útil do suporte da Fase de Produção do Red Hat Enterprise Linux 5.10+ , ambos efetivos em 31 de março de 2017. O NGINX Plus R12 é a última versão que incluirá pacotes e oferecerá suporte a essas versões de sistema operacional, bem como ao CentOS 5.10+ e ao Oracle Linux 5.10+. Para continuar recebendo atualizações e suporte após o NGINX Plus R12, atualize para uma versão de sistema operacional compatível.

Recursos do NGINX Plus R12 em detalhes

Compartilhamento de configuração

Os servidores NGINX Plus geralmente são implantados em um cluster de duas ou mais instâncias para fins de alta disponibilidade e escalabilidade. Isso permite que você melhore a confiabilidade dos seus serviços, isolando-os do impacto de falhas do servidor, e também dimensione e lide com grandes volumes de tráfego.

O NGINX Plus já oferece uma maneira suportada de distribuir tráfego em um cluster de forma ativa-passiva ou ativa-ativa . O NGINX Plus R12 adiciona um método adicional suportado para sincronizar a configuração em um cluster. Este recurso de sincronização de configuração permite que um administrador configure um “cluster” de servidores NGINX Plus a partir de um único local. Esses servidores compartilham um subconjunto comum de sua configuração.

A configuração do NGINX Plus é enviada do primário para os pares

Veja como você sincroniza a configuração:

  1. Nomeie um ou mais nós “primários” no cluster.
  2. Instale o novo pacote nginx-sync nos nós primários.
  3. Aplicar alterações de configuração a um nó primário.

  4. Invoque o processo de sincronização de configuração, nginx-sync.sh , que está incluído no pacote nginx-sync , para atualizar cada um dos outros servidores no cluster (os peers ). O processo de sincronização executa estas etapas em cada par:

    1. Envia a configuração atualizada para o peer via ssh ou rsync .
    2. Verifica se a configuração é válida para o peer e a reverte caso contrário.
    3. Aplica a configuração se ela for válida e recarrega os servidores NGINX Plus no peer.

Esse recurso é especialmente útil quando o NGINX Plus é implantado em um par tolerante a falhas (ou número maior) de servidores. Você pode usar esse método para simplificar a implantação confiável da configuração em um cluster ou para enviar a configuração de um servidor de preparação para um cluster de servidores de produção.

Para obter instruções detalhadas, consulte o Guia de administração do NGINX Plus .

Disponibilidade geral do módulo JavaScript NGINX

Com o NGINX Plus R12, temos o prazer de anunciar que o módulo NGINX JavaScript agora está disponível para o público em geral como um módulo estável para o NGINX Open Source e o NGINX Plus. [O módulo era chamado anteriormente de nginScript e esta publicação usa os nomes de forma intercambiável.] O nginScript é totalmente suportado para assinantes do NGINX Plus.

nginScript é uma implementação JavaScript exclusiva<.htmla> para NGINX e NGINX Plus, projetada especificamente para casos de uso do lado do servidor e processamento por solicitação. Ele permite que você estenda a sintaxe de configuração do NGINX Plus com código JavaScript para implementar soluções de configuração sofisticadas.

Com o nginScript, você pode registrar variáveis personalizadas usando lógica complexa, controlar a seleção upstream, implementar algoritmos de balanceamento de carga, personalizar a persistência da sessão e até mesmo implementar serviços web simples. Publicaremos instruções completas para algumas dessas soluções em nosso blog nas próximas semanas e adicionaremos links para elas aqui assim que estiverem disponíveis.

Especificamente, o NGINX Plus R12 inclui os seguintes aprimoramentos :

  • Fase de pré-leitura no módulo Stream
  • ECMAScript 6 Métodos matemáticos e constantes
  • Métodos de string adicionais, como endsWith , includes , repeat , startsWith e trim
  • Escopos

Embora o nginScript seja estável, o trabalho continua para oferecer suporte a ainda mais casos de uso e cobertura da linguagem JavaScript. Saiba mais em Aproveitando o poder e a conveniência do JavaScript para cada solicitação com o módulo JavaScript NGINX<.htmla> em nosso blog.

Novas Estatísticas

O monitoramento e a instrumentação no NGINX Plus são um importante valor agregado que fornece insights profundos sobre o desempenho e o comportamento do NGINX Plus e dos aplicativos upstream. As estatísticas são fornecidas por meio do nosso painel gráfico integrado e também no formato JSON, que pode ser exportado para sua ferramenta de monitoramento favorita.

O painel de monitoramento de atividades ao vivo do NGINX Plus com atualizações para a versão 12
O painel de monitoramento de atividades ao vivo foi atualizado para NGINX Plus R12

O NGINX Plus R12 adiciona uma série de melhorias: mais informações sobre o desempenho (tempo de resposta) de servidores com balanceamento de carga, insights sobre a operação de serviços TCP e UDP e uma variedade de dados internos que auxiliam na solução de problemas para identificar problemas e ajustar o NGINX Plus para otimizar o desempenho.

Novas estatísticas no NGINX Plus R12 incluem:

  • Tempo de resposta do servidor upstream – No NGINX Plus R11 e versões anteriores, o tempo de resposta dos servidores upstream era calculado somente quando o algoritmo de balanceamento de carga de menor tempo era usado. A partir do NGINX Plus R12, o tempo de resposta é medido para todos os algoritmos e relatado nos dados JSON e no painel integrado.
  • Códigos de resposta para upstreams TCP/UDP no painel gráfico – O módulo Stream para balanceamento de carga TCP/UDP gera pseudocódigos de status para identificar como uma conexão foi fechada (200 significa “sucesso”,502 significa “upstream indisponível”, e assim por diante), relatando-os na variável $status . O NGINX Plus R12 adiciona uma série de colunas ao painel para exibir as contagens de códigos de resposta para servidores virtuais TCP e UDP, como aqueles já fornecidos para servidores virtuais HTTP. Os pseudocódigos de status também podem ser registrados para integração com ferramentas de análise de log existentes.
  • Informações sobre a versão do NGINX Plus – Para ajudar na solução de problemas, os dados JSON agora relatam o número da versão do NGINX Plus como nginx_build (por exemplo, nginx-plus-r12 ), bem como o número da versão do NGINX Open Source como nginx_version (por exemplo,1.11.10 ). O painel exibe ambos os valores na caixa superior esquerda da guia principal.

  • Nome do host upstream – Nos dados JSON, o campo do servidor identifica um servidor em um grupo upstream por endereço IP e porta. O novo campo de nome relata o primeiro parâmetro para a diretiva do servidor no bloco de configuração upstream , que pode ser um nome de domínio ou caminho de soquete de domínio UNIX, bem como um endereço IP e uma porta. No painel, a coluna Nome mais à esquerda nas guias Upstreams e TCP/UDP Upstreams agora informa o valor do campo de nome em vez do campo de servidor (que era informado no NGINX Plus R11 e versões anteriores).

    A nova métrica facilita a correlação dos dados JSON e do painel com seus servidores upstream se você defini-los usando nomes DNS, especialmente nomes que resolvem para vários endereços IP.

  • Utilização de zona de memória compartilhada em dados de status estendidos – Zonas de memória compartilhada são configuradas com um tamanho fixo e pode ser difícil selecionar um tamanho que não seja nem muito grande (a memória é alocada, mas nunca usada) nem muito pequeno (a memória é esgotada e os itens em cache são descartados).

    A nova instrumentação nas métricas fornece um relatório interno detalhado do uso de memória de cada zona compartilhada, permitindo que você monitore o uso de memória e o suporte técnico do NGINX forneça conselhos mais informados sobre como otimizar a configuração do NGINX.

  • Escape compatível com JSON no log de acesso do NGINX Plus – Algumas ferramentas modernas de análise de log podem ingerir com eficiência arquivos de log formatados em JSON e conseguem extrair insights mais facilmente do que de arquivos de log não formatados. Você pode definir um modelo JSON na diretiva padrão log_format do NGINX Plus, e o novo parâmetro de escape opcional para a diretiva impõe o escape compatível com JSON para que as linhas de log sejam formatadas corretamente.

Para obter mais informações, consulte Monitoramento de atividades ao vivo .

Cache aprimorado

O NGINX Plus R12 aprimora significativamente o mecanismo de cache do NGINX Plus.

Servir conteúdo obsoleto durante a atualização

O NGINX Plus R12 adiciona suporte para as extensões Cache-Control definidas no RFC 5861 , stale-while-revalidate e stale-if-error . Agora você pode configurar o NGINX Plus para honrar essas extensões de controle de cache e continuar a fornecer recursos expirados do cache enquanto os atualiza em segundo plano, sem adicionar latência à solicitação do cliente. Da mesma forma, o NGINX Plus pode servir recursos expirados do cache se o servidor upstream não estiver disponível – uma técnica para implementar padrões de disjuntor em aplicativos de microsserviços.

A menos que esteja configurado para ignorar o cabeçalho Cache-Control , o NGINX Plus respeita os temporizadores obsoletos dos servidores de origem que retornam cabeçalhos Cache-Control compatíveis com RFC 5861, como neste exemplo:

Controle de cache: idade máxima = 3600 obsoleto enquanto revalidado = 120 obsoleto se erro = 900

Para habilitar o suporte às extensões Cache-Control com atualização em segundo plano, inclua as diretivas destacadas:

proxy_cache_path /caminho/para/o/cache levels=1:2 keys_zone=meu_cache:10m max_size=10g inativo=60m use_temp_path=off; server { # ... location / { proxy_cache meu_cache; # Exiba conteúdo obsoleto ao atualizar proxy_cache_use_stale updating ; # Além disso, não bloqueie a primeira solicitação que aciona a atualização # e faça a atualização em segundo plano proxy_cache_background_update on ; proxy_pass http://meu_upstream; } }

A diretiva de atualização proxy_cache_use_stale instrui o NGINX Plus a fornecer a versão obsoleta do conteúdo enquanto ele está sendo atualizado. Se você incluir apenas essa diretiva, o primeiro usuário a solicitar conteúdo desatualizado pagará a penalidade de “falha de cache” – ou seja, não receberá o conteúdo até que o NGINX Plus o tenha buscado no servidor de origem e o tenha armazenado em cache. Os usuários que posteriormente solicitam o conteúdo desatualizado enquanto ele está sendo atualizado o obtêm do cache imediatamente, enquanto o primeiro usuário não recebe nada até que o conteúdo atualizado seja buscado e armazenado em cache.

Com a nova diretiva proxy_cache_background_update , todos os usuários, incluindo o primeiro usuário, recebem o conteúdo obsoleto enquanto o NGINX Plus o atualiza em segundo plano.

A nova funcionalidade também está disponível nos módulos FastCGI , SCGI e uwsgi .

Solicitações de intervalo de bytes

Um aprimoramento adicional no mecanismo de cache permite que o NGINX Plus ignore o cache para solicitações de intervalo de bytes que iniciam mais do que um número configurado de bytes após o início de um arquivo não armazenado em cache. Isso significa que, para arquivos grandes, como conteúdo de vídeo, solicitações para um intervalo de bytes profundo no arquivo não adicionam latência à solicitação do cliente. Em versões anteriores do NGINX Plus, o cliente não recebia o intervalo de bytes solicitado até que o NGINX Plus buscasse todo o conteúdo do início do arquivo até o intervalo de bytes solicitado e o gravasse no cache.

A nova diretiva proxy_cache_max_range_offset especifica o deslocamento do início do arquivo após o qual o NGINX Plus passa uma solicitação de intervalo de bytes diretamente para o servidor de origem e não armazena a resposta em cache. (A nova funcionalidade também está disponível nos módulos FastCGI , SCGI e uwsgi .)

proxy_cache_path /caminho/para/o/cache levels=1:2 keys_zone=meu_cache:10m max_size=10g inativo=60m use_temp_path=off; server { location / { proxy_cache meu_cache; # Ignorar cache para solicitações de intervalo de bytes além de 10 megabytes proxy_cache_max_range_offset 10m ; proxy_pass http://meu_upstream; } }

Essas melhorias consolidam ainda mais o NGINX Plus como um mecanismo de cache de alto desempenho e compatível com os padrões, adequado para qualquer ambiente, desde a aceleração da entrega de aplicativos até a construção de redes de entrega de conteúdo (CDNs) completas.

Verificações de saúde aprimoradas

O NGINX Plus R12 aprimora ainda mais os recursos de verificação de integridade ativa do NGINX Plus.

Verificação de saúde em servidores recém-adicionados

Com a crescente adoção de ambientes em contêineres e grupos de aplicativos com dimensionamento automático, é essencial que o balanceador de carga implemente verificações de integridade proativas no nível do aplicativo e permita que novos servidores inicializem recursos internos antes de ganharem velocidade.

Antes do NGINX Plus R12, quando você adicionava um novo servidor ao pool de balanceamento de carga (usando a API ou DNS do NGINX Plus ), o NGINX Plus o considerava íntegro imediatamente e enviava tráfego para ele imediatamente. Ao incluir o novo parâmetro obrigatório na diretiva health_check ( HTTP ou TCP/UDP ), o novo servidor deve passar pela verificação de integridade configurada antes que o NGINX Plus envie tráfego para ele. Quando combinado com o recurso de inicialização lenta , o novo parâmetro dá aos novos servidores ainda mais tempo para se conectar aos bancos de dados e “aquecer” antes de serem solicitados a lidar com sua parcela total de tráfego.

upstream my_upstream { zone my_upstream 64k; server backend1.example.com slow_start=30s ; } server { location / { proxy_pass http://my_upstream; # Exigir que o novo servidor passe na verificação de integridade antes de receber tráfego health_check required ; } }

Aqui estão incluídos tanto o parâmetro obrigatório para a diretiva health_check quanto o parâmetro slow_start para a diretiva server ( HTTP ou TCP/UDP ). Servidores adicionados ao grupo upstream usando as interfaces API ou DNS são marcados como não íntegros e não recebem tráfego até passarem na verificação de integridade; nesse ponto, eles começam a receber uma quantidade gradualmente crescente de tráfego ao longo de um período de 30 segundos.

Verificação de integridade do UDP de configuração zero

É tão importante implementar verificações de integridade no nível do aplicativo para servidores UDP quanto para servidores HTTP e TCP, para que o tráfego de produção não seja enviado para servidores que não estejam totalmente funcionais. O NGINX Plus oferece suporte a verificações de integridade ativas para UDP, mas antes do NGINX Plus R12 você tinha que criar um bloco de correspondência que definisse os dados a serem enviados e a resposta a ser esperada . Pode ser desafiador determinar os valores adequados ao usar protocolos binários ou aqueles com handshakes complexos. Para tais aplicações, o NGINX Plus R12 agora oferece suporte a uma verificação de integridade de “configuração zero” para UDP que testa a disponibilidade do aplicativo sem exigir que você defina strings de envio e espera. Adicione o parâmetro udp à diretiva health_check para uma verificação básica de integridade do UDP.

upstream udp_app { server backend1.example.com:1234; server backend2.example.com:1234; } server { listen 1234 udp; proxy_pass udp_app; # Verificação básica de integridade do UDP health_check udp ; }

Atualizações SSL – Certificados de cliente para serviços TCP, variáveis atualizadas

Certificados de cliente SSL são comumente usados para autenticar usuários em sites protegidos. O NGINX Plus R12 adiciona suporte de autenticação para serviços TCP protegidos por SSL ao suporte HTTP existente. Isso normalmente é usado para autenticação de máquina para máquina, em oposição ao login do usuário final, e permite que você use o NGINX Plus para terminação SSL e autenticação de cliente ao balancear a carga dos protocolos da Camada 4. Exemplos incluem a autenticação de dispositivos IoT para comunicação com o protocolo MQTT.

A variável $ssl_client_verify agora inclui informações adicionais para eventos de autenticação de cliente com falha. Isso inclui motivos como certificados “revogados” e “expirados”.

O formato das variáveis $ssl_client_i_dn e $ssl_client_s_dn foi alterado para estar em conformidade com os RFCs2253 e4514 . Para mais detalhes, consulte Mudanças no comportamento .

Validação JWT aprimorada

O NGINX Plus R10 introduziu suporte nativo ao JSON Web Token (JWT) para casos de uso do OAuth 2.0 e OpenID Connect . Um dos principais casos de uso é o NGINX Plus validar um JWT, inspecionar os campos nele e passá-los para o aplicativo de back-end como cabeçalhos HTTP. Isso permite que os aplicativos participem facilmente de um ambiente de logon único (SSO) OAuth 2.0, descarregando a validação do token para o NGINX Plus e consumindo a identidade do usuário lendo cabeçalhos HTTP.

O NGINX Plus R10 e posteriores podem inspecionar os campos definidos na especificação JWT. O NGINX Plus R12 estende o suporte ao JWT para que qualquer campo em um JWT (incluindo campos personalizados) possa ser acessado como uma variável NGINX e, portanto, proxy, registrado ou usado para tomar decisões de autorização.

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para a versão 12 o mais rápido possível. Você aprenderá uma série de correções e melhorias, e isso nos ajudará a ajudar você caso precise abrir um tíquete de suporte. Instruções de instalação e atualização podem ser encontradas no portal do cliente .

Consulte as alterações de comportamento descritas acima antes de prosseguir com a atualização.

Se você ainda não experimentou o NGINX Plus , recomendamos que experimente para aceleração web, balanceamento de carga e entrega de aplicativos, ou como um servidor web totalmente suportado com uma API para monitoramento aprimorado e gerenciamento de configuração . Você pode começar hoje mesmo gratuitamente com uma avaliação de 30 dias e ver por si mesmo como o NGINX Plus pode ajudar você a entregar e dimensionar seus aplicativos.

Leia mais postagens de blog sobre F5 NGINX›

"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."