[Editor – Esta postagem foi atualizada para se referir à API NGINX Plus , que substitui e desaprova o módulo de configuração dinâmica separado mencionado na versão original da postagem.]
Uma das grandes vantagens de uma arquitetura de microsserviços é a rapidez e facilidade com que você pode dimensionar instâncias de serviço. Com várias instâncias de serviço, você precisa de um balanceador de carga e de alguma maneira de informá-lo rapidamente sobre alterações no conjunto de instâncias de serviço disponíveis. Isso é conhecido como descoberta de serviço . O NGINX Plus oferece duas opções para integração com sistemas de descoberta de serviços: a API do NGINX Plus e a re-resolução do Sistema de Nomes de Domínio (DNS) . Esta postagem do blog se concentra no último.
Ao dimensionar instâncias de serviço (vamos chamá-las de backends nesta postagem do blog) adicionando ou removendo máquinas virtuais (VMs) ou contêineres, a configuração do balanceador de carga deve ser alterada para refletir cada alteração no conjunto de backends. O dimensionamento pode ocorrer várias vezes por dia, por hora ou até mesmo por minuto, dependendo da aplicação. Dada a alta frequência de alterações de configuração, elas precisam ser automatizadas, e uma das maneiras de fazer isso é a descoberta de serviços via DNS.
Muitas plataformas onde você executa seus aplicativos hoje, como o Kubernetes , oferecem suporte à descoberta de serviços usando DNS. Fornecemos links no final desta postagem do blog para artigos que explicam como integrar o NGINX Plus com plataformas populares e ferramentas de descoberta de serviços que usam DNS.
Antes de explicar como configurar a descoberta de serviço via DNS, vamos dar uma olhada rápida em alguns recursos do protocolo DNS que são particularmente relevantes ou úteis.
Para evitar que clientes DNS usem informações desatualizadas, os registros DNS incluem o campo de tempo de vida (TTL) para definir por quanto tempo os clientes podem considerar o registro válido. Para cumprir com os padrões de DNS , os clientes devem consultar o servidor DNS para obter uma atualização quando um registro ultrapassar seu TTL. O NGINX Plus respeita o TTL por padrão, mas também fornece um controle mais granular sobre o “tempo de vida” de um registro – você pode configurar o NGINX Plus para ignorar os TTLs e, em vez disso, atualizar os registros em uma frequência especificada. (Discutiremos como o NGINX Open Source lida com o TTL mais adiante no post.)
Por padrão, clientes e servidores DNS se comunicam via UDP, mas se um nome de domínio for resolvido para um grande número de endereços IP de backend, a resposta completa pode não caber em um único datagrama UDP, que é limitado a 512 bytes. Usar TCP em vez de UDP resolve esse problema: quando um conjunto completo de registros não cabe em um datagrama, o servidor define um sinalizador de truncamento em sua resposta, que informa ao cliente para alternar para TCP para obter todos os registros. DNS sobre TCP é suportado no NGINX versão 1.9.11 e posteriores, e no NGINX Plus R9 e posteriores. Para mais detalhes, consulte Balanceamento de carga de tráfego DNS com NGINX e NGINX Plus em nosso blog.
SRV
O DNS resolve nomes de host em endereços IP, mas e os números de porta? Há alguns casos – por exemplo, ao balancear a carga de contêineres Docker – em que você não pode confiar em números de porta conhecidos, porque os números de porta são atribuídos dinamicamente. O DNS tem um tipo especial de registro – o registro de serviço ( SRV
) – que inclui números de porta e alguns outros parâmetros. No R9 e versões posteriores, o NGINX Plus oferece suporte a registros SRV
(e, portanto, pode extrair informações de porta deles).
Editor – Para uma visão geral de todos os novos recursos do NGINX Plus R9, consulte Anunciando o NGINX Plus R9 em nosso blog.
Agora mostraremos cinco maneiras de usar DNS para descoberta de serviços no NGINX e NGINX Plus, em ordem crescente de sofisticação. Os três primeiros estão disponíveis no NGINX e no NGINX Plus, e os dois últimos apenas no NGINX Plus.
Nesta pesquisa de métodos de descoberta de serviços, assumiremos que temos um servidor de nomes autoritativo para a zona example.com , com endereço IP 10.0.0.2. Há três servidores de backend que correspondem ao nome de domínio backends.example.com , conforme mostrado na seguinte saída do utilitário nslookup
. Com os quatro primeiros métodos que discutiremos, o NGINX e o NGINX Plus solicitam registros A
padrão do DNS; com o método final, o NGINX Plus solicita registros SRV
.
$ nslookup backends.example.com 10.0.0.2 Servidor: 10.0.0.2 Endereço: 10.0.0.2#53 Nome: backends.example.com Endereço: 10.0.0.11 Nome: backends.example.com Endereço: 10.0.0.10 Nome: backends.example.com Endereço: 10.0.0.12
Começaremos mostrando três maneiras de usar DNS com o NGINX Open Source (como mencionamos acima, você também pode usá-lo com o NGINX Plus).
proxy_pass
A maneira mais simples de definir o grupo de servidores upstream (backends) é especificar um nome de domínio como parâmetro para a diretiva proxy_pass
:
servidor { localização / {
proxy_pass http://backends.example.com:8080;
}
}
Quando o NGINX inicia ou recarrega sua configuração, ele consulta um servidor DNS para resolver backends.example.com . O servidor DNS retorna a lista de três backends discutidos acima, e o NGINX usa o algoritmo Round Robin padrão para balancear a carga de solicitações entre eles. O NGINX escolhe o servidor DNS no arquivo de configuração do sistema operacional /etc/resolv.conf .
Este método é a maneira menos flexível de fazer descoberta de serviços e tem as seguintes desvantagens adicionais:
do servidor
, que descreveremos na próxima seção.Para aproveitar as opções de balanceamento de carga fornecidas pelo NGINX, você pode definir o grupo de servidores upstream no bloco de configuração upstream
. Mas em vez de identificar servidores individuais por endereço IP, use o nome de domínio como parâmetro para a diretiva do servidor
.
Assim como no primeiro método , backends.example.com é resolvido em três servidores de backend quando o NGINX inicia ou recarrega sua configuração. Mas agora podemos definir um algoritmo de balanceamento de carga mais sofisticado, Least Connections , e usar o parâmetro max_fails
para habilitar verificações de integridade passivas, especificando que o NGINX marca um servidor como inativo quando três solicitações consecutivas falham.
backends upstream { less_conn;
servidor backends.example.com:8080 max_fails=3;
}
servidor {
localização / {
proxy_pass http://backends;
}
}
Embora esse método nos permita escolher o algoritmo de balanceamento de carga e configurar verificações de integridade, ele ainda tem as mesmas desvantagens em relação à inicialização, recarga e TTL do método anterior.
Este método é uma variante do primeiro , mas nos permite controlar a frequência com que o NGINX resolve novamente o nome de domínio:
resolver 10.0.0.2 válido=10s;
servidor {
localização / {
definir $backend_servers backends.example.com;
proxy_pass http://$backend_servers:8080;
}
}
Quando você usa uma variável para especificar o nome de domínio na diretiva proxy_pass
, o NGINX resolve novamente o nome de domínio quando seu TTL expira. Você deve incluir a diretiva resolver
para especificar explicitamente o servidor de nomes (o NGINX não se refere a /etc/resolv.conf como nos dois primeiros métodos). Ao incluir o parâmetro válido
na diretiva resolver
, você pode dizer ao NGINX para ignorar o TTL e resolver novamente os nomes em uma frequência especificada. Aqui dizemos ao NGINX para resolver novamente os nomes a cada 10 segundos.
Observação: Para balanceamento de carga TCP/UDP, esse método de usar uma variável na diretiva proxy_pass
é suportado no NGINX 1.11.3 e posteriores, e no NGINX Plus R10 e posteriores.
Este método elimina duas desvantagens do primeiro método: a operação de inicialização ou recarga do NGINX não falha quando o nome de domínio não pode ser resolvido, e podemos controlar a frequência com que o NGINX resolve novamente o nome. Entretanto, como ele não usa um grupo upstream, você não pode especificar o algoritmo de balanceamento de carga ou outros parâmetros para a diretiva do servidor
(como fizemos no segundo método ).
Agora veremos os dois métodos de descoberta de serviço com DNS que são exclusivos do NGINX Plus.
A
com NGINX PlusCom o NGINX Plus, podemos resolver novamente nomes DNS com a frequência que quisermos e sem as desvantagens discutidas acima para os três primeiros métodos. Para usar esse recurso, precisamos:
resolver
para especificar o servidor de nomes, como no método anterior.de zona
no bloco de configuração upstream
para alocar uma zona de memória compartilhada.resolve
à diretiva do servidor
onde usamos o nome de domínio.Considere o seguinte exemplo:
resolver 10.0.0.2 válido=10s ; backends upstream { zona backends 64k ; servidor backends.example.com:8080 resolver ; } servidor { localização / { proxy_pass http://backends; } }
Por padrão, o NGINX Plus respeita o TTL, resolvendo novamente os nomes quando os registros expiram. Para que o NGINX Plus resolva novamente os nomes em uma frequência especificada, inclua o parâmetro válido
na diretiva resolver
.
No snippet, a cada 10 segundos o NGINX Plus consulta o servidor de nomes em 10.0.0.2 para resolver backends.example.com . Se o nome não puder ser resolvido, o NGINX Plus não falhará, nem na inicialização, nem ao recarregar a configuração, nem durante o tempo de execução. Em vez disso, o cliente vê o padrão502
página de erro.
SRV
com NGINX PlusO NGINX Plus R9 e versões posteriores oferecem suporte a registros DNS SRV
. Isso permite que o NGINX Plus obtenha não apenas endereços IP de um servidor de nomes, mas também números de porta, pesos e prioridades. Isso é essencial em ambientes de microsserviços onde os números de porta dos serviços são frequentemente atribuídos dinamicamente.
Editor – Para uma visão geral de todos os novos recursos do NGINX Plus R9, consulte Anunciando o NGINX Plus R9 em nosso blog.
Os registros SRV
são definidos por um tripleto do nome do serviço, do protocolo de comunicação com o serviço e do nome do domínio. Ao consultar o servidor de nomes, devemos fornecer todos os três. Nosso servidor de nomes 10.0.0.2 tem três registros SRV
com o tripleto de nome de serviço http , protocolo tcp e nome de domínio backends.example.com , conforme mostrado nesta saída do utilitário nslookup
:
$ nslookup -query=SRV _http._tcp.backends.example.com 10.0.0.2 Servidor: 10.0.0.2 Endereço: 10.0.0.2#53 _http._tcp.backends.example.com serviço = 0 2 8090 backend-0.example.com. _http._tcp.backends.example.com serviço = 0 1 8091 backend-1.example.com. _http._tcp.backends.example.com serviço = 10 1 8092 backend-2.example.com.
Quando consultamos o nome do host em cada registro SRV
, obtemos seu endereço IP:
$ nslookup backend-0.example.com 10.0.0.2 ...
Nome: backend-0.example.com Endereço: 10.0.0.10 $ nslookup backend-1.example.com 10.0.0.2 ...
Nome: backend-1.example.com Endereço: 10.0.0.11 $ nslookup backend-2.example.com 10.0.0.2 ...
Nome: backend-2.example.com Endereço: 10.0.0.12
Vamos examinar mais de perto as informações no primeiro registro SRV
retornado pelo primeiro comando nslookup
:
Serviço _http._tcp.backends.example.com = 0 2 8090 backend-0.example.com.
_http._tcp.
– O nome e o protocolo do registro SRV
. Especificaremos isso como o valor do parâmetro de serviço
para a diretiva do servidor
no arquivo de configuração do NGINX Plus (veja abaixo).0
– A prioridade. Quanto menor o valor, maior a prioridade. O NGINX Plus designa os servidores com a maior prioridade como servidores primários e o restante dos servidores como servidores de backup. Este registro tem o menor valor (a maior prioridade) entre todos os registros, então o NGINX Plus designa o backend correspondente como um servidor primário.2
– O peso. O NGINX Plus define o peso do backend para esse valor, pois adiciona o backend ao grupo upstream (equivalente ao parâmetro de peso
na diretiva do servidor
).8090
– O número da porta. O NGINX Plus define a porta do backend para esse valor, pois adiciona o backend ao grupo upstream.backend‑0.example.com
– O nome do host do servidor backend. O NGINX Plus resolve esse nome e adiciona o backend correspondente ao grupo upstream. Se o nome for resolvido para vários registros, o NGINX Plus adicionará vários servidores.Agora vamos ver como configuramos o NGINX Plus para usar registros SRV
. Aqui está o arquivo de configuração de exemplo:
resolver 10.0.0.2 válido=10s;
backends upstream {
zona backends 64k;
servidor backends.example.com serviço=_http._tcp resolver;
}
servidor {
localização / {
proxy_pass http://backends;
}
}
Usando o parâmetro de serviço
na diretiva do servidor
, especificamos o nome e o protocolo dos registros SRV
que desejamos resolver. No nosso caso, eles são _http e _tcp, respectivamente. Tirando o parâmetro de serviço
e o fato de não especificarmos uma porta, ele se parece com o exemplo de configuração da seção anterior .
Com base nos valores retornados pelo primeiro comando nslookup
nesta seção, o NGINX Plus é configurado com três servidores de backend:
Se configurarmos o monitoramento de atividades ao vivo para o NGINX Plus, poderemos ver esses backends no painel integrado:
Observe como as solicitações são distribuídas de acordo com os pesos especificados. O servidor 10.0.0.11:8091 (com peso 1) recebe um terço das solicitações, enquanto o servidor 10.0.0.10:8090 (com peso 2) recebe dois terços. Como servidor de backup, o servidor 10.0.0.12:8092 não recebe nenhuma solicitação, a menos que os outros dois servidores estejam inativos.
Ao usar DNS para descoberta de serviço com o NGINX Plus, há algumas coisas a serem lembradas:
resolver
, de modo que, se um deles estiver inativo, o NGINX Plus tentará os outros.Se você quiser mergulhar em exemplos completos, confira estas postagens de blog sobre a integração do NGINX e do NGINX Plus com plataformas de descoberta de serviços que usam DNS:
SRV
do ConsulAtualizaremos esta lista à medida que escrevermos mais sobre novas opções de integração no futuro.
A descoberta de serviços via DNS, totalmente disponível no NGINX Plus, fornece uma maneira simples de atualizar a configuração do balanceador de carga em um ambiente de microsserviços. O suporte para registros SRV
na versão 9 e posteriores torna o NGINX Plus ainda mais poderoso, pois permite que o NGINX Plus obtenha não apenas endereços IP, mas também números de porta de backends.
Pronto para experimentar a descoberta de serviços com DNS para NGINX Plus, juntamente com seus outros recursos aprimorados? Comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .
"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."