Sugiro que você leia a transcrição do relatório Service Discovery em sistemas distribuídos de Alexander Sigachev usando o Consul como exemplo.
O Service Discovery foi criado para que com um custo mínimo você possa conectar uma nova aplicação ao nosso ambiente existente. Usando o Service Discovery, podemos separar ao máximo um contêiner docker ou um serviço virtual do ambiente em que está sendo executado.
Dou as boas-vindas a todos! Sou Alexander Sigachev, trabalho na Inventos. E hoje vou apresentar a você um conceito como Service Discovery. Vejamos o Service Discovery usando o Consul como exemplo.
Que problemas o Service Discovery resolve? O Service Discovery foi criado para que com um custo mínimo você possa conectar uma nova aplicação ao nosso ambiente existente. Usando o Service Discovery, podemos separar ao máximo um contêiner docker ou um serviço virtual do ambiente em que está sendo executado.
Com o que se parece? Num exemplo clássico da web, este é o front end que aceita a solicitação do usuário. Em seguida, ele o encaminha para o back-end. Neste exemplo, este balanceador de carga equilibra dois back-ends.
Aqui vemos que estamos lançando uma terceira instância do aplicativo. Da mesma forma, quando o aplicativo é iniciado, ele é registrado no Service Discovery. Service Discovery notifica o balanceador de carga. O balanceador de carga altera sua configuração automaticamente e o novo backend é colocado em operação. Desta forma, back-ends podem ser adicionados ou, inversamente, excluídos do trabalho.
O que mais é conveniente fazer com o Service Discovery? O Service Discovery pode armazenar configurações nginx, certificados e uma lista de servidores back-end ativos.
O Service Discovery também permite detectar falhas e detectar falhas. Quais são os esquemas possíveis para detectar falhas?
- Este aplicativo que desenvolvemos notifica automaticamente o Service Discovery de que ainda está funcional.
- O Service Discovery, por sua vez, pesquisa a disponibilidade do aplicativo.
- Ou usamos um script ou aplicativo de terceiros que verifica a disponibilidade de nosso aplicativo e notifica o Service Discovery de que está tudo bem e pode funcionar ou, inversamente, que tudo está ruim e esta instância do aplicativo precisa ser excluída do balanceamento.
Cada um dos esquemas pode ser usado dependendo do software que usamos. Por exemplo, acabamos de começar a desenvolver um novo projeto, então podemos facilmente fornecer um esquema quando nosso aplicativo notificar o Service Discovery. Ou podemos conectar que o Service Discovery está verificando.
Se herdamos o aplicativo ou foi desenvolvido por outra pessoa, a terceira opção é adequada quando escrevemos um manipulador, e tudo isso entra em nosso trabalho automaticamente.
Este é um exemplo. O balanceador de carga na forma de nginx é reinicializado. Este é um utilitário opcional fornecido com o Consul. Este é o modelo de cônsul. Descrevemos a regra. Dizemos que estamos usando um template (Golang Template Engine). Quando ocorrem eventos, quando notificações de mudanças ocorreram, ele é regenerado e o comando “recarregar” é enviado para o Service Discovery. O exemplo mais simples é quando o nginx é reconfigurado por um evento e reiniciado.
O que é Cônsul?
-
Em primeiro lugar, trata-se de descoberta de serviço.
-
Possui um mecanismo de verificação de disponibilidade - Health Checking.
-
Também possui uma Loja KV.
-
E é baseado na capacidade de usar Multi Datacenter.
Para que tudo isso pode ser usado? No KV Store podemos armazenar configurações de exemplo. Verificação de Saúde podemos verificar o serviço local e notificar. Multi Datacenter é utilizado para que um mapa de serviços possa ser construído. Por exemplo, a Amazon possui várias zonas e roteia o tráfego da maneira mais otimizada para que não haja solicitações desnecessárias entre data centers, que são cobrados separadamente do tráfego local e, portanto, têm menos latência.
Vamos entender um pouco sobre os termos que são usados no Consul.
- Consul é um serviço escrito em Go. Uma das vantagens de um programa Go é 1 arquivo binário que você acabou de baixar. Lançado de qualquer lugar e você não tem dependências.
- Então, usando as chaves, podemos iniciar este serviço tanto em modo cliente quanto em modo servidor.
- Além disso, o atributo “datacenter” permite definir um sinalizador ao qual o data center este servidor pertence.
- Consenso – baseado no protocolo de jangada. Se alguém estiver interessado, pode ler mais sobre isso no site do Cônsul. Este é um protocolo que permite determinar o líder e determinar qual dinheiro é considerado válido e acessível.
- Gossip é um protocolo que permite a interação entre nós. Além disso, este sistema é descentralizado. Dentro de um data center, todos os nós se comunicam com seus vizinhos. E, consequentemente, as informações sobre o estado atual são transmitidas entre si. Podemos dizer que isso é fofoca entre vizinhos.
- LAN Gossip – troca local de dados entre vizinhos dentro do mesmo data center.
- WAN Gossip - usado quando precisamos sincronizar informações entre dois data centers. As informações fluem entre nós marcados como servidores.
- RPC – permite executar solicitações através de um cliente em um servidor.
Descrição do RPC. Digamos que o Consul esteja rodando como cliente em uma máquina virtual ou servidor físico. Nós o contatamos localmente. E então o cliente local solicita informações do servidor e é sincronizado. Dependendo das configurações, as informações podem ser recuperadas do cache local, ou podem ser sincronizadas com o líder, com o servidor mestre.
Esses dois esquemas têm prós e contras. Se trabalharmos com cache local, então é rápido. Se trabalharmos com dados que estão armazenados no servidor demora mais, mas obtemos informações mais relevantes.
Se você representar isso graficamente, esta é a imagem do site. Vemos que temos três mestres em execução. Um está marcado com um asterisco como líder. Neste exemplo, há três clientes que trocam informações localmente entre si via UDP/TCP. E as informações entre data centers são transferidas entre servidores. Aqui os clientes interagem entre si localmente.
Qual API o Consul fornece? Para obter informações, a Consul dispõe de dois tipos de API.
Esta é a API DNS. Por padrão, o Consul é executado na porta 8600. Podemos configurar o proxy de solicitação e fornecer acesso por meio de resolução local, por meio de DNS local. Podemos consultar por domínio e receber informações de endereço IP em resposta.
API HTTP - ou podemos solicitar localmente informações sobre um serviço específico na porta 8500 e receber uma resposta JSON, qual IP o servidor possui, qual host, qual porta está registrada. E informações adicionais podem ser transferidas via token.
O que você precisa para administrar o Consul?
Na primeira opção, no modo desenvolvedor indicamos a flag de que se trata do modo desenvolvedor. O agente inicia como um servidor. E executa toda a função de forma independente em uma máquina. Conveniente, rápido e praticamente nenhuma configuração adicional é necessária para a primeira inicialização.
O segundo modo é o lançamento em produção. É aqui que o início fica um pouco complicado. Se não tivermos nenhuma versão do cônsul, então devemos colocar a primeira máquina em bootstrap, ou seja, esta máquina, que assumirá as responsabilidades do líder. Nós o levantamos, depois levantamos a segunda instância do servidor, passando para ele a informação de onde nosso mestre está localizado. Nós levantamos o terceiro. Depois de termos três máquinas instaladas, nós a reiniciamos no modo normal na primeira máquina a partir do bootstrap em execução. Os dados estão sincronizados e o cluster inicial já está ativo.
Recomenda-se executar de três a sete instâncias no modo servidor. Isso se deve ao fato de que se o número de servidores crescer, o tempo de sincronização das informações entre eles aumenta. O número de nós deve ser ímpar para garantir o quorum.
Como são fornecidos os exames de saúde? Escrevemos uma regra de verificação na forma de Json no diretório de configuração do Consul. A primeira opção é a disponibilidade do domínio google.com neste exemplo. E dizemos que essa verificação precisa ser realizada em intervalos de 30 segundos. Desta forma verificamos se o nosso nó tem acesso à rede externa.
A segunda opção é verificar você mesmo. Usamos curl regular para chamar localhost na porta especificada em intervalos de 10 segundos.
Essas verificações são resumidas e enviadas ao Service Discovery. Com base na disponibilidade, esses nós são excluídos ou aparecem na lista de máquinas disponíveis e funcionando corretamente.
O Consul também fornece uma interface UI, que é iniciada com um sinalizador separado e estará disponível na máquina. Isso permite que você visualize informações e também possa fazer algumas alterações.
Neste exemplo, a aba “Serviço” está aberta. Mostra-se que estão funcionando três serviços, um deles é o Cônsul. Número de verificações realizadas. E há três data centers onde as máquinas estão localizadas.
Este é um exemplo da guia Nós. Vemos que eles têm nomes compostos envolvendo data centers. Também mostra quais serviços estão em execução, ou seja, vemos que nenhuma tag foi definida. Essas tags adicionais podem fornecer algumas informações que o desenvolvedor pode usar para especificar parâmetros adicionais.
Você também pode transmitir informações ao Consul sobre o status dos discos e carga média.
perguntas
Pergunta: Temos um contêiner docker, como usá-lo com o Consul?
Resposta: Existem várias abordagens para o contêiner docker. Uma das mais comuns é usar um contêiner docker de terceiros responsável pelo registro. Na inicialização, um soquete docker é passado para ele. Todos os eventos de registro e despublicação de contêineres são registrados no Consul.
Pergunta: Então o próprio Consul inicia o contêiner docker?
Resposta: Não. Estamos executando um contêiner docker. E na hora de configurar indicamos - ouça tal e tal soquete. É aproximadamente o mesmo que trabalhamos com um certificado, quando carregamos informações sobre onde e o que temos.
Pergunta: Acontece que dentro do contêiner Docker que estamos tentando conectar ao Service Discovery deve haver algum tipo de lógica que possa enviar dados ao Consul?
Resposta: Na verdade não. Quando começa, passamos variáveis através da variável de ambiente. Digamos nome do serviço, porta de serviço. O registro escuta essas informações e as insere no Consul.
Pergunta: Tenho outra pergunta sobre a IU. Implantamos a UI, por exemplo, em um servidor de produção. E quanto à segurança? Onde os dados são armazenados? É possível acumular dados de alguma forma?
Resposta: Na UI existem dados do banco de dados e do Service Discovery. Nós mesmos definimos senhas nas configurações.
Pergunta: Isso pode ser publicado na Internet?
Resposta: Por padrão, o Consul inicia no localhost. Para publicar na Internet, você precisará instalar algum tipo de proxy. Somos responsáveis pelas nossas próprias regras de segurança.
Question: Ele fornece dados históricos prontos para uso? É interessante observar as estatísticas sobre exames de saúde. Você também pode diagnosticar problemas se o servidor falhar com frequência.
Answer: Não tenho certeza se há detalhes de verificações lá.
Pergunta: O estado atual não é tão importante quanto a dinâmica.
Resposta: Para análise – sim.
Pergunta: É melhor não usar o Service Discovery para a janela de encaixe Consul?
Answer: Eu não recomendaria usá-lo. O objetivo do relatório é apresentar que tal conceito existe. Historicamente, chegou, na minha opinião, à 1ª versão. Agora existem soluções mais completas, por exemplo, o Kubernetes, que tem tudo isso em segundo plano. Como parte do Kubernetes, o Service Discovery é inferior ao Etcd. Mas não estou tão familiarizado com isso quanto com o Consul. Portanto, decidi fazer Service Discovery usando o Consul como exemplo.
Pergunta: O esquema com servidor líder não retarda o início da aplicação como um todo? E como o Cônsul determina um novo líder se este está mentindo?
Answer: Eles têm todo um protocolo descrito. Se você estiver interessado, você pode lê-lo.
Pergunta: O Consul atua como um servidor completo para nós e todas as solicitações passam por ele?
Resposta: Ele não atua como um servidor completo, mas assume uma zona específica. Geralmente termina com service.consul. E então seguimos em frente logicamente. Não usamos nomes de domínio na produção, mas sim a infraestrutura interna, que geralmente fica escondida atrás do cache do servidor se trabalharmos usando DNS.
Pergunta: Ou seja, se quisermos acessar um banco de dados, então de qualquer forma vamos puxar o Consul para encontrar primeiro esse banco de dados, certo?
Resposta: Sim. Se trabalharmos com DNS, funcionará da mesma forma que sem o Consul quando usarmos nomes DNS. Normalmente os aplicativos modernos não extraem o nome de domínio em todas as solicitações, pois instalamos o connect, tudo funciona e em um futuro próximo praticamente não o utilizaremos. Se a conexão for interrompida, então sim, perguntamos novamente onde está nossa base e vamos até ela.
— Bate-papo do usuário Hashicorp: Consul, Nomad, Terraform
P.S. Em relação aos exames de saúde. O Consul, assim como o Kubernetes, usa o mesmo sistema para verificar o status de sobrevivência de um serviço com base no status do código.
200 OK for healthy
503 Service Unavailable for unhealthyFontes:
Fonte: habr.com