Hoje lançamos o NGINX 1.19, a versão mais recente do NGINX Open Source, o servidor web mais popular da Internet. Esta versão marca o lançamento da ramificação de desenvolvimento do NGINX 1.19, após o lançamento da ramificação estável do NGINX 1.18 no mês passado.
Neste blog, discutimos o esquema de versionamento do NGINX, relembramos o que aconteceu durante o ciclo de desenvolvimento do NGINX 1.17 e apresentamos o que está por vir com o NGINX 1.19.
Entenda o versionamento do NGINX
Na NGINX, mantemos duas ramificações no repositório de código do NGINX Open Source, chamadas mainline e stable:
- Mainline é a ramificação de desenvolvimento ativo à qual são adicionados os recursos mais recentes e as correções de bugs. Ela é indicada por um número ímpar na segunda parte do número da versão, por exemplo, 1.19.0.
- Estável recebe correções para bugs de alta gravidade, mas não é atualizado com novos recursos. É indicado por um número par na segunda parte do número da versão, por exemplo, 1.18.0.
O que significa ser “estável”
No NGINX Open Source, a palavra “estável” se refere à funcionalidade e à frequência de atualizações, não à qualidade do software. A ramificação estável nunca recebe novas funcionalidades durante seu ciclo de vida e normalmente recebe apenas uma ou duas atualizações para corrigir bugs críticos.
A ramificação estável tem um ciclo de vida anual. Todo mês de abril, descontinuamos a ramificação estável atual, após o que nenhuma outra correção de bugs é feita. Isso desencadeia dois eventos:
- É feito um fork da ramificação mainline atual para criar a próxima ramificação estável. A nova ramificação estável herda todas as correções de bugs, funcionalidades e outras alterações incorporadas à ramificação mainline durante o ano anterior. No mês passado, foi feito um fork do NGINX 1.17.10 para gerar o NGINX 1.18.0. Observe que, até o lançamento da nova ramificação mainline, a ramificação “estável” é idêntica à ramificação mainline atual e pode incluir novas funcionalidades lançadas há apenas alguns dias (essa situação termina hoje para a ramificação NGINX 1.18).
- A ramificação mainline recebe um “incremento de versão”; ou seja, a segunda parte do número da versão é incrementada para o próximo número ímpar. O desenvolvimento contínuo prossegue na ramificação mainline, com novas versões geradas a partir dela a cada quatro a seis semanas. Hoje ocorre o primeiro lançamento da ramificação mainline do NGINX 1.19, com o NGINX 1.19.0.
Qual branch o NGINX Plus usa?
NGINX Plus, a versão comercial do NGINX, é mantida em um repositório de código privado e separado. Ela sempre se baseia na versão mais recente do NGINX mainline, combinada com os recursos e funcionalidades proprietários adicionais do NGINX Plus. No momento da redação deste texto, a versão mais recente é a NGINX Plus R21, baseada no NGINX 1.17.10.
Qual branch devo usar?
Em geral, recomendamos usar a ramificação mainline. É nela que incorporamos todos os novos recursos, melhorias de desempenho e aprimoramentos. Testamos ativamente e realizamos o controle de qualidade da ramificação mainline e, como ela é a fonte das compilações do NGINX Plus, é totalmente adequada para uso em produção.
Se você estiver preocupado com o esforço necessário para monitorar a ramificação mainline em busca de novos recursos e correções de bugs, usar a ramificação stable significa que você só precisará analisar novas funcionalidades uma vez por ano e correções de bugs ocasionalmente.
Retrospectiva do NGINX 1.17, ou: novidades da versão estável NGINX 1.18
O ciclo de desenvolvimento do NGINX 1.17 introduziu alguns novos recursos e melhorias, incluindo aprimoramentos na limitação da taxa de requisições e de conexões em ngx_http_limit_req_module e ngx_http_limit_conn_module, respectivamente, a adição de uma diretiva para atrasar a autenticação ao ngx_http_core_module, a introdução de suporte a variáveis para a diretiva grpc_pass e de variáveis que capturam o endereço e a porta do servidor com o protocolo PROXY, entre outras novidades. Antes de analisarmos mais detalhadamente as melhorias mais significativas, confira o NGINX 1.17 em números:
- 10 versões mainline
- 37 correções de bugs
- 11 novos recursos
Aprimoramentos na limitação da taxa de requisições HTTP e de conexões
As diretivas limit_rate e limit_rate_after controlam a largura de banda (taxa em bytes por segundo) com que o NGINX responde às solicitações. No NGINX 1.17.0 e versões posteriores, o parâmetro que define a taxa pode ser uma variável, permitindo o controle dinâmico com base nos atributos da solicitação. Para ver um exemplo, consulte Controle dinâmico de largura de banda.
O NGINX 1.17.1 adicionou o modo de simulação para limitação da taxa de solicitações, com a diretiva limit_req_dry_run. No modo de simulação, o NGINX Plus não aplica os limites de taxa, mas ainda monitora a taxa de solicitações excessivas na zona de memória compartilhada e registra uma entrada no log de erros para cada solicitação que excede o limite configurado. Isso permite determinar com mais facilidade qual limite de taxa é adequado aos padrões de tráfego do seu site. Para obter mais detalhes, consulte Como testar limites de taxa no modo de simulação.
Para tornar o modo de simulação ainda mais útil, o NGINX 1.17.6 adicionou a variável $limit_req_status, que pode ser incluída nas entradas do log de acesso para registrar o efeito da limitação de taxa no processamento de solicitações – especificamente, se uma solicitação:
- Aprovada (foi encaminhada aos servidores de backend sem atraso) [
PASSED] - Foi atrasada [
DELAYED] - Foi rejeitado [
REJECTED] - Foi contabilizado como atrasado no modo de simulação [
DELAYED_DRY_RUN] - Foi contabilizado como rejeitado no modo de simulação [
REJECTED_DRY_RUN]
O NGINX 1.17.6 também adicionou o modo de simulação para limitação de conexões com a diretiva limit_conn_dry_run, além da variável $limit_conn_status, para registrar quando uma solicitação de conexão:
- Permitida (foi encaminhada aos servidores de backend) [
PASSED] - Foi rejeitado [
REJECTED] - Foi contabilizado como rejeitado no modo de simulação [
REJECTED_DRY_RUN]
Para ver um exemplo de configuração, consulte Aprimoramentos na limitação de conexões.
Nova diretiva auth_delay Directive
A diretiva auth_delay (adicionada no NGINX 1.17.10) permite atrasar o processamento de solicitações não autorizadas, retornando ao cliente o código de status 401 (Não autorizado). Isso evita ataques de temporização durante o processamento de solicitações de acesso. Os métodos de autenticação disponíveis incluem:
- Uma senha (ao usar ngx_http_auth_basic_module)
- O resultado de uma subsolicitação (disponível em ngx_http_auth_request_module)
- A presença de um JWT (disponível em ngx_http_auth_jwt_module)
Suporte a variáveis para a diretiva grpc_pass Directive
O suporte nativo ao tráfego gRPC foi adicionado no NGINX 1.13.10, incluindo a diretiva grpc_pass, que especifica os servidores aos quais o NGINX encaminha as solicitações gRPC. No NGINX 1.17.8, adicionamos a capacidade de incluir nomes de domínio no identificador do servidor, permitindo a pesquisa entre grupos de servidores upstream. Se o nome de domínio não for encontrado, o NGINX recorre a um resolvedor para identificar os endereços dos servidores.
Variáveis adicionais do protocolo PROXY
O protocolo PROXY permite que um proxy de camada 4 forneça as informações originais do cliente ao próximo proxy ou balanceador de carga que processará a solicitação. Isso é importante em casos de uso nos quais é necessário saber o endereço IP do cliente — por exemplo, para limitar o número de conexões de cada cliente (usando a diretiva least_conn). Esses dados estão disponíveis na variável $proxy_protocol_addr (HTTP | Stream).
Quando vários proxies de Camada 4 são implantados, pode ser importante que o NGINX saiba o endereço IP e a porta do servidor proxy ao qual o cliente se conectou originalmente. Os metadados do protocolo PROXY incluem essas informações, e o NGINX 1.17.6 adicionou as seguintes variáveis aos módulos HTTP e Stream para capturá-las:
Observação: As variáveis serão preenchidas somente se você também incluir o parâmetro proxy_protocol na diretiva listen para habilitar o processamento do protocolo PROXY.
Adição de suporte a variáveis nas diretivas proxy_upload_rate e proxy_download_rate Directives
As diretivas proxy_upload_rate e proxy_download_rate do módulo Stream controlam, respectivamente, a taxa na qual o NGINX lê dados de um cliente ou de um servidor com proxy. No NGINX 1.17.0 e versões posteriores, as diretivas aceitam uma variável como parâmetro, permitindo definir taxas específicas para cada condição.
Adição de suporte à chamada de sistema ioctl(FIONREAD) System Call
Em sistemas Linux, a chamada de sistema ioctl() fornece o número de bytes que podem ser lidos do dispositivo host. O NGINX 1.17.5 adicionou ioctl(FIONREAD) para evitar loops quando os dados são adicionados ao buffer do soquete mais rapidamente do que o NGINX consegue lê-los e processá-los. Quando o kernel não fornece o número de bytes disponíveis, podemos usar ioctl(FIONREAD) para obter essa informação de um buffer preenchido.
Especificando um local nomeado na função Perl internal_redirect Function
No NGINX 1.17.2 e versões posteriores, o parâmetro uri da função internal_redirect no módulo Perl do NGINX pode ser um URI com caracteres de escape ou um local nomeado.
O que vem por aí no NGINX 1.19
A primeira versão da linha principal do NGINX 1.19 será lançada muito em breve. O NGINX 1.19.0 inclui suporte a QUIC (HTTP/3), a próxima atualização significativa dos protocolos de transporte usados na comunicação entre clientes e sites, aplicativos e APIs.
Se você quiser experimentar os recursos avançados do NGINX Plus, comece hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.