Consul - Guia Rápido

Consul é uma ferramenta baseada em Hashicorp para descobrir e configurar uma variedade de serviços diferentes em sua infraestrutura. É baseado e construído em Golang. Uma das principais razões para construir o Consul era manter os serviços presentes nos sistemas distribuídos. Algumas das características importantes que a Consul oferece são as seguintes.

Service Discovery - Usando DNS ou HTTP, os aplicativos podem encontrar facilmente os serviços dos quais dependem.
Health Check Status- Ele pode fornecer qualquer número de verificações de saúde. É usado pelos componentes de descoberta de serviço para rotear o tráfego de hosts não íntegros.
Key/Value Store - Ele pode usar o armazenamento de chave / valor hierárquico do Consul para qualquer número de finalidades, incluindo configuração dinâmica, sinalização de recursos, coordenação, eleição de líder, etc.
Multi Datacenter Deployment- O Consul oferece suporte a vários datacenters. É usado para construir camadas adicionais de abstração para crescer em várias regiões.
Web UI - O Consul oferece aos seus usuários uma bela interface web com a qual pode ser fácil de usar e gerenciar todos os recursos do consul.

Descoberta de serviço

A descoberta de serviços é uma das características mais importantes do Consul. É definido como a detecção de diferentes serviços e protocolos de rede através dos quais um serviço é encontrado. O uso da descoberta de serviço é uma bênção para sistemas distribuídos. Este é um dos principais problemas enfrentados pelas grandes indústrias de hoje com o avanço dos sistemas distribuídos em seu ambiente.

Comparação com Etcd e Zookeeper

Quando olhamos para outras ferramentas de descoberta de serviço neste domínio, temos duas opções populares. Alguns participantes importantes da indústria de software já o utilizaram no passado. Essas ferramentas sãoEtcd e Zookeeper.

Vamos considerar a tabela a seguir para comparar diferentes aspectos de cada ferramenta. Também entenderemos o que cada um deles utiliza internamente.

Propriedades	Cônsul	Etcd	Funcionário do zoológico
Interface de usuário	acessível
RPC	acessível	acessível
Exame de saúde	API HTTP	API HTTP	TCP
Valor chave	3 modos de consistência	Boa Consistência	Consistência forte
Sistema de Token	acessível
Língua	Golang	Golang	Java

Cônsul - Membros e Agentes

Os membros do cônsul podem ser definidos como a lista de diferentes agentes e modos de servidor usando os quais um cluster cônsul é implantado. O Consul nos fornece um recurso de linha de comando com o qual podemos listar facilmente todos os agentes associados ao consul.

O agente da Consul é o processo central da Consul. O agente mantém informações de associação, registra serviços, executa verificações, responde a consultas, etc. Qualquer agente pode ser executado em um dos dois modos:Client ou Server. Esses dois modos podem ser usados de acordo com sua função, conforme decidido ao usar o cônsul. O agente cônsul nos ajuda fornecendo informações, que estão listadas abaixo.

Node name - Este é o nome do host da máquina.
Datacenter- O datacenter no qual o agente está configurado para ser executado. Cada nó deve ser configurado para relatar a seu datacenter.
Server- Indica se o agente está rodando em modo servidor ou cliente. Os nós do servidor participam do quorum de consenso, armazenando o estado do cluster e lidando com as consultas.
Client Addr- É o endereço usado para interfaces de cliente pelo agente. Inclui as portas para as interfaces HTTP, DNS e RPC.
Cluster Addr- É o endereço e o conjunto de portas usadas para comunicação entre Agentes Consul em um cluster. Este endereço deve ser acessado por todos os outros nós.

No próximo capítulo, vamos entender a arquitetura da Consul.

O diagrama de arquitetura para cônsul trabalhando em um datacenter pode ser melhor descrito conforme mostrado abaixo -

Como podemos observar, existem três servidores diferentes, que são geridos pela Consul. A arquitetura de trabalho funciona através do algoritmo de jangada, que nos ajuda a eleger um líder entre os três servidores diferentes. Esses servidores são então rotulados de acordo com as tags, comoFollower e Leader. Como o nome sugere, o seguidor é responsável por seguir as decisões do líder. Todos esses três servidores são conectados entre si para qualquer comunicação.

Cada servidor interage com seu próprio cliente usando o conceito de RPC. A comunicação entre os clientes é possível devido aGossip Protocolcomo mencionado abaixo. A comunicação com a Internet pode ser disponibilizada através de TCP ou método de comunicação gossip. Esta comunicação está em contato direto com qualquer um dos três servidores.

Algoritmo de jangada

Raft é um algoritmo de consenso para gerenciar um log replicado. Baseia-se no princípio deCAP Theorem, que afirma que, na presença de uma partição de rede, é necessário escolher entre consistência e disponibilidade. Nem todos os três fundamentos do Teorema CAP podem ser alcançados em um determinado momento. É preciso trocar por dois deles, na melhor das hipóteses.

UMA Raft Clustercontém vários servidores, geralmente na contagem de número ímpar. Por exemplo, se tivermos cinco servidores, isso permitirá que o sistema tolere duas falhas. A qualquer momento, cada servidor está em um dos três estados:Leader, Follower, ou Candidate. Em uma operação normal, há exatamente um líder e todos os outros servidores são seguidores. Esses seguidores estão em um estado passivo, ou seja, eles não emitem solicitações por conta própria, mas simplesmente respondem às solicitações dos líderes e do candidato.

A ilustração a seguir descreve o modelo de fluxo de trabalho usando o algoritmo de jangada -

Dados de valor chave

Desde a versão 0.7.1 do Consul, houve uma introdução de dados de valor-chave separados. O comando KV é usado para interagir com o armazenamento de valores-chave do Consul por meio da linha de comando. Ele expõe comandos de nível superior paraInserting, Updating, Reading e Deletingda loja. Para obter o armazenamento de objeto de chave / valor, chamamos o método KV disponível para o cliente consul -

kv := consul.KV()

o KVPair Structureé usado para representar uma única entrada de chave / valor. Podemos ver a estrutura do Consul KV Pair no programa a seguir.

type KVPair struct {
   Key string
   CreateIndex uint64
   ModifyIndex uint64
   LockIndex uint64
   Flags uint64
   Value []byte
   Session string
}

Aqui, as várias estruturas mencionadas no código acima podem ser definidas da seguinte forma -

Key- É um nome de URL de barra. Por exemplo - sites / 1 / domínio.
CreateIndex - Número do índice atribuído quando a chave foi criada pela primeira vez.
ModifyIndex - Número do índice atribuído quando a chave foi atualizada pela última vez.
LockIndex - Número de índice criado quando um novo bloqueio adquirido na entrada de chave / valor
Flags - Pode ser usado pelo aplicativo para definir o valor personalizado.
Value - É uma matriz de bytes de no máximo 512kb.
Session - Pode ser definido após a criação de um objeto de sessão.

Tipos de protocolo

Existem dois tipos de protocolo no Consul, que são chamados de -

Protocolo de consenso e
Protocolo de Fofoca

Vamos agora entendê-los em detalhes.

Protocolo de Consenso

O protocolo de consenso é usado pelo Consul para fornecer consistência conforme descrito pelo teorema CAP. Este protocolo é baseado no Algoritmo de Jangada. Ao implementar o protocolo de consenso, o Algoritmo de jangada é usado onde os nós de jangada estão sempre em qualquer um dos três estados: Seguidor, Candidato ou Líder.

Protocolo de Fofoca

O protocolo gossip pode ser usado para gerenciar a associação, enviar e receber mensagens em todo o cluster. No cônsul, o uso do protocolo de fofoca ocorre de duas maneiras,WAN (Rede de área sem fio) e LAN(Rede local). Existem três bibliotecas conhecidas, que podem implementar um algoritmo Gossip para descobrir nós em uma rede ponto a ponto -

teknek-gossip - Funciona com UDP e é escrito em Java.
gossip-python - Utiliza a pilha TCP e também é possível compartilhar dados através da rede construída.
Smudge - Está escrito em Go e usa UDP para trocar informações de status.

Os protocolos de gossip também têm sido usados para alcançar e manter uma consistência de banco de dados distribuída ou com outros tipos de dados em estados consistentes, contando o número de nós em uma rede de tamanho desconhecido, espalhando notícias de maneira robusta, organizando nós, etc.

Chamadas de procedimento remoto

O RPC pode ser indicado como a forma abreviada de Chamadas de Procedimento Remoto. É um protocolo que um programa usa para solicitar um serviço de outro programa. Este protocolo pode ser localizado em outro computador em uma rede sem ter que reconhecer os detalhes da rede.

A verdadeira beleza de usar RPC no Consul é que nos ajuda a evitar os problemas de latência que a maioria das ferramentas de serviço de descoberta tinha há algum tempo. Antes de RPC, Consul costumava ter apenasTCP e UDPconexões baseadas, que eram boas com a maioria dos sistemas, mas não no caso de sistemas distribuídos. O RPC resolve esses problemas reduzindo o período de tempo de transferência das informações do pacote de um lugar para outro. Nesta área, GRPC by Google é uma ótima ferramenta para olhar para a frente, caso se queira observar benchmarks e comparar desempenho.

Para fins de demonstração, usaremos o agente cônsul no modo de desenvolvedor usando o modo -dev. Apenas para a configuração da máquina local, faremos uma configuração única do cônsul do sistema.Please do not use this single node consul cluster in your production. Como Hashicorp já menciona no cenário de caso de um cluster cônsul de nó único,the data loss is inevitable.

Instalando Consul

O Consul pode ser instalado através da página de Downloads em www.consul.io/downloads.html

Você pode extrair o pacote binário na seção Downloads de sua máquina.

$ cd Downloads $ chmod +x consul
$ sudo mv consul /usr/bin/

Agora vamos começar a usar o cônsul usando o -dev flag.

$ consul agent -dev -data-dir=/tmp/consul

A saída seria conforme mostrado na captura de tela a seguir.

Agora você pode verificar os membros do cônsul usando o seguinte comando.

$ consul members

A saída seria conforme mostrado na captura de tela a seguir.

Se você quiser juntar outros nós a este nó -

$ consul join <Node 2> <Node 3>

Como alternativa, você pode executar o seguinte comando no Nó 2 e 3 -

$ consul join <Node 1>

Usando a linha de comando

A linha de comando do cônsul consiste em várias opções diferentes, algumas das mais comumente usadas são as seguintes -

agent - que dirige um agente Consul.
configtest - para validar um arquivo de configuração.
event - para iniciar um novo evento.
exec - para executar um comando em nós Consul.
force-leave - forçando um membro do cluster a deixar o cluster.
info - fornece informações de depuração para os operadores.
join - para fazer um agente Consul se juntar ao cluster.
keygen - para gerar uma nova chave de criptografia.
keyring - para gerenciar as chaves de criptografia da camada de fofoca.
kv - para interagir com o armazenamento de valor-chave.
leave - deixar o cluster Consul e fechá-lo sem força.
lock - para executar um comando para segurar uma fechadura.
maint - para controlar o modo de manutenção do nó ou serviço.
members - lista os membros de um cluster Consul.
monitor - ele transmite logs de um agente Consul.
operator - fornece-nos um conjunto de ferramentas para os operadores do Consul.
reload - aciona o agente para recarregar os arquivos de configuração.
rtt - estima o tempo de ida e volta da rede entre os nós.
snapshot - salva, restaura e inspeciona instantâneos do estado do servidor Consul.
version - para imprimir a versão atual do Consul.
watch - para estar atento a mudanças no cônsul.

Modelo Consul

O modelo do consul nos fornece um daemon que consulta a instância do Consul e atualiza qualquer número de modelos especificados no sistema de arquivos. O modelo cônsul pode, opcionalmente, executar comandos arbitrários quando o processo de atualização for concluído. Esta opção nos ajuda a configurar o cluster cônsul sem fazer tudo manualmente por conta própria.

O modelo de cônsul deve ser formado em /tmp/<name-of-file>.conf.tmpfl. O idioma no qual o modelo é escrito de acordo comHashicorp Configuration Language (HCL).

Você pode baixar o modelo do cônsul nesta página .

Experimente usando o seguinte comando -

$ ./consul-template -h

A saída seria conforme mostrado na captura de tela a seguir.

Se você deseja mover este binário para um espaço mais proeminente, para que esteja sempre disponível para o usuário. Você pode digitar os seguintes comandos -

$ chmod +x consul-template $ sudo mv consul-template /usr/share/bin/

Para fins de demonstração, vamos usar um exemplo de configuração de nginxpara ser usado como nosso serviço. Você pode experimentar mais demos emhttps://github.com/hashicorp/consul-template/tree/master/examples ou melhor, escreva seu próprio modelo.

$ vim /tmp/nginx.conf.ctmpl

A saída seria conforme mostrado na captura de tela a seguir.

O arquivo de configuração pode ser semelhante a -

{{range services}} {{$name := .Name}} {{$service := service .Name}} upstream {{$name}} {
   zone upstream-{{$name}} 64k; {{range $service}}server {{.Address}}:{{.Port}} max_fails = 3 fail_timeout = 60
   weight = 1;
   {{else}}server 127.0.0.1:65535; # force a 502{{end}}
} {{end}}

server {
   listen 80 default_server;
   location / {
      root /usr/share/nginx/html/;
      index index.html;
   }
   location /stub_status {
      stub_status;
   }
   {{range services}} {{$name := .Name}} location /{{$name}} {
      proxy_pass http://{{$name}};
   }
   {{end}}
}

Agora usando o arquivo binário do modelo do consul, execute os seguintes comandos -

$ consul-template \
 -template = "/tmp/nginx.conf.ctmpl:/etc/nginx/conf.d/default.conf"

Com o comando anterior, o processo foi iniciado. Posteriormente, você pode abrir outro terminal e visualizar o arquivo nginx.conf sendo completamente renderizado usando o seguinte comando.

$ cat /etc/nginx/conf.d/default.conf

A saída seria conforme mostrado na captura de tela a seguir.

Neste capítulo, entenderemos como os microsserviços funcionam com a Consul. Também aprenderemos como os seguintes componentes afetam o Consul.

Usando o docker
Criando registrador para descoberta de serviço
Usando rkt e Nomad

Vamos agora discutir cada um deles em detalhes.

Usando Docker

Antes de começar, please do not use this setup in productionpois é usado apenas para fins de demonstração. Docker é um serviço baseado em contêiner com o qual podemos facilmente implantar nossos aplicativos. Para usar o Consul, vamos usar a imagem do seguinte link –0

https://hub.docker.com/r/progrium/consul/.

Presume-se que seu sistema tenha o Docker instalado e configurado corretamente. Vamos tentar puxar para baixo a imagem do hub Docker, executando o seguinte comando -

$ docker pull progrium/consul

A saída seria conforme mostrado na captura de tela a seguir.

Vamos publicar algumas interfaces com suas portas (usando a opção -p no Docker) da seguinte maneira.

8400 (RPC)
8500 (HTTP)
8600 (DNS)

Também de acordo com o pull feito, vamos definir o nome do host como node1. Você pode alterá-lo para o que quiser usando o -h flag com algum nome de host de sua preferência, conforme mostrado abaixo.

$ docker run -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node1 progrium/consul
-server -bootstrap

A saída seria conforme mostrado na captura de tela a seguir.

Você também pode ativar o modo UI para o Consul usando -

$ docker run -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node1 progrium/consul
-server -bootstrap -ui-dir /ui

Você pode verificar a saída baseada na IU em http://localhost:8500. A captura de tela a seguir dá uma ideia melhor sobre a saída baseada na IU.

Para usar o cônsul em vários contêineres docker em nós diferentes, podemos executar os seguintes comandos em nós diferentes -

No Nó1

$ docker run -d --name node1 -h node1 progrium/consul -server -bootstrap-expect 3

Onde, -bootstrap-expect 3 significa que o servidor cônsul esperará até que haja 3 pares conectados antes de autoinicializar e se tornar um cluster funcional.

Antes de prosseguir, precisamos obter o IP interno do contêiner inspecionando o contêiner. Para nosso uso, propósito de caso, vamos declarar o$ JOIN_IP.

$ JOIN_IP = "$(docker inspect -f '{{.NetworkSettings.IPAddress}}' node1)"

No Nó2

Portanto, vamos iniciar o Nó2 e dizer a ele para se juntar ao Nó1 usando a variável declarada no programa fornecido acima.

$docker run -d --name node2 -h node2 progrium/consul -server -join $JOIN_IP

No Nó 3

$ docker run -d --name node3 -h node3 progrium/consul -server -join $JOIN_IP

Criando registrador para descoberta de serviço

O Registrator automaticamente registra e cancela o registro de serviços para qualquer contêiner Docker inspecionando os contêineres à medida que ficam online. O registrador que estamos prestes a usar atualmente oferece suporte a registros de serviços conectáveis, que atualmente incluemConsul, Etcd e SkyDNS2. O uso do Registrador é altamente recomendado quando estamos interagindo com diferentes serviços na rede.

$ docker pull gliderlabs/registrator:latest

A saída seria conforme mostrado na captura de tela a seguir.

$ docker run -d \
--name = registrator \
--net = host \
--volume = /var/run/docker.sock:/tmp/docker.sock \
gliderlabs/registrator:latest \
 consul://localhost:8500

A saída seria conforme mostrado na captura de tela a seguir.

A saída que você recebeu é o ID do Docker Container que você acabou de iniciar. Você pode verificar se o contêiner está em execução ou não usando o comando -

$ docker ps -a

A saída seria como mostrado na imagem a seguir.

Você também pode visualizar os logs do Registrador usando o seguinte comando.

$ docker logs registrator

Usando rkt e Nomad

O rkt é outro serviço baseado em contêiner, que você pode usar em seu ambiente. É construído porCoreOS. O principal motivo para a construção do rkt foi melhorar a segurança, um dos problemas de crise do Docker quando ele ainda estava em desenvolvimento em 2013-14.

Quanto ao Consul, podemos usar o Rkt Registrator para trabalhar na descoberta de serviços com o Consul. Este projeto específico do Registrador, que é coberto pelo rkt, está em desenvolvimento e estánot recommended for production level use.

Você pode verificar se o rkt está instalado ou não, acessando seu caminho e executando o seguinte comando.

$ ./rkt

Você pode verificar a saída para verificar se está instalada corretamente ou não como mostrado na imagem a seguir.

Para experimentar o rkt e o Consul, verifique - https://github.com/r3boot/rkt-registrator.

Ferramenta Nomad

Uma das opções mais utilizadas e favoritas é a ferramenta Nomad. Nomad é uma ferramenta para gerenciar um cluster de máquinas e executar aplicativos nelas. É similar àMesos ou Kubernetes. Por padrão, o Nomad cobre o driver Docker e rkt dentro dele mesmo. Então, se você está procurando uma implantação em larga escala de contêineres com Consul. O Nomad pode ser uma boa solução para isso. Confira -https://www.nomadproject.io/docs/drivers/rkt.html para mais informações sobre o Nomad.

Neste capítulo, discutiremos como os seguintes componentes são usados no Consul.

Bootstraping automático
Inicialização manual
Usando o encaminhamento de DNS
Cache DNS

Vamos agora discutir cada um deles em detalhes.

Bootstraping automático

O bootstrapping é um dos principais recursos do Consul. Quando você instala o consul pela primeira vez, ele é configurado automaticamente para detectar, identificar e unir os nós que encontrar. Durante a formação do cluster, a inicialização automática é um recurso interno do Consul. Para obter mais informações sobre o cônsul, a melhor forma é utilizar o comando abaixo -

$ sudo consul info

A saída seria conforme mostrado na captura de tela a seguir.

Este comando irá mostrar o funcionamento real do cônsul em real working scenarios. Ele exibirá o Algoritmo de Jangada funcionando no Consul. O comando de inicialização automática pode ser mostrado usando o seguinte comando -

$ consul agent -server -data-dir = ”/tmp/consul” -bootstrap-expect 3

Automatic bootstrapping cannot be done in -dev mode.

Esta opção informa ao Consul sobre o número esperado de nós de servidor e inicializa automaticamente quando os servidores estão disponíveis.

Inicialização manual

A inicialização manual é um recurso antigo e útil do Consul. Na verdade, durante a versão anterior do Consul, o bootstrapping deve ser feito manualmente ao instalar e usar o Consul pela primeira vez. Posteriormente, percebeu-se que não era possível realizar essa operação de linha de comando em momentos diferentes. Conseqüentemente, a inicialização automática foi introduzida. Você sempre pode usar o bootstrapping manualmente usando os comandos a seguir.

In this case, we will assume that a 3-node consul cluster is to be built.

Existem duas opções para fazer bootstrap manual

Executando comandos em 2 nós: No Nó B e no Nó C, você pode fazer o seguinte -

$ consul join <Node A Address>

Executando o comando em 1 nó -

$ consul join <Node B Address> <Node C Address>

Usando o encaminhamento de DNS

DNS é servido de port 53. O encaminhamento de DNS pode ser feito usandoBIND, dnsmasq e iptables. Por padrão, o agente do Consul executa um servidor DNS escutando na porta 8600. Ao enviar solicitações de DNS ao servidor DNS do agente do Consul, você pode obter o endereço IP de um nó que executa o serviço no qual está interessado.

A interface Consul DNS disponibiliza as informações da porta de um serviço por meio do SRV records. Sem adicionar manualmente a lógica em seu código, você geralmente fica limitado apenas às informações do endereço IP (ou seja, um registro) do serviço que está consultando.

A melhor opção é ter vários servidores BIND, cada um executando um agente Consul localmente. Todas as consultas recebidas por um servidor BIND serão encaminhadas ao servidor DNS do agente Consul local.

Usando Bind

Podemos usar o encaminhamento de DNS usando a função Bind. Isso pode ser feito usando o seguinte comando.

$ sudo apt-get install bind9 bind9utils bind9-doc

A saída seria conforme mostrado na captura de tela a seguir.

Vamos editar o arquivo /etc/bind/named.conf com o seguinte comando.

$ sudo vim /etc/bind/named.conf

No arquivo, adicione as seguintes linhas abaixo da última linha do código.

options {
   directory "/var/cache/bind";
   recursion yes;
   allow-query { localhost; };
   
   forwarders {
      8.8.8.8;
      8.8.4.4;
   };
   dnssec-enable no;
   dnssec-validation no;
   auth-nxdomain no; # conform to RFC1035
   listen-on-v6 { any; };
};
include "/etc/bind/consul.conf";

A saída seria conforme mostrado na captura de tela a seguir.

Você pode usar o seguinte comando Bind para configurar o Consul.

$ sudo vim /etc/bind/consul.conf

Adicione as seguintes linhas ao criar o arquivo -

zone "consul" IN {
   type forward;
   forward only;
   forwarders { 127.0.0.1 port 8600; };
};

Agora você pode começar a operar seu agente cônsul usando o seguinte comando. (Lembre-se de reiniciar o serviço bind9 também.)

$ sudo service bind9 restart $ consul agent -server -bootstrap-expect 1 -data-dir = /tmp/consul -configdir = [Path]

O sistema precisa ser configurado para enviar consultas ao servidor DNS do agente Consul local. Isso é feito atualizando oresolv.confarquivo no sistema para apontar para 127.0.0.1. Na maioria dos casos, o Consul precisará ser configurado para funcionar na porta 53.

Você pode adicionar as seguintes informações ao /etc/resolv.conf:

nameserver 127.0.0.1

Cache DNS

O Consul exibe todos os resultados DNS com um valor '0 TTL' (Time to Live). Isso evita qualquer armazenamento em cache. No entanto, devido aos valores TTL, ele pode ser configurado para permitir que os resultados DNS sejam armazenados em cache com o downstream do Consul. Valores TTL mais altos reduzem o número de pesquisas nos servidores Consul e aceleram as pesquisas de clientes, ao custo de resultados cada vez mais desatualizados.

Para isso, usaremos o cache DNS usando o método abaixo -

$ sudo apt-get install dnsmasq

A saída seria conforme mostrado na captura de tela a seguir.

Agora, podemos fazer uma configuração muito simples -

$ echo "server = /consul/127.0.0.1#8600" > /etc/dnsmasq.d/10-consul

Tudo o que estamos fazendo aqui é especificar as solicitações de DNS para serviços de cônsul, que devem ser tratadas pelo servidor DNS em 127.0.0.1 na porta 8600. A menos que você altere os padrões de cônsul, isso deve funcionar.

Em casos normais, o seguinte comando deve ser usado.

$ dig @127.0.0.1 -p 8600 web.service.consul

Com Dnsmasq, você deve usar o seguinte comando.

$ dig web.service.consul

A saída seria conforme mostrado na captura de tela a seguir.

Neste capítulo, aprenderemos como consultar nós com as seguintes funções -

Usando dig
Usando o comando Monitor
Usando o comando Watch
Registrando serviços externos

Vamos entender cada uma dessas funções em detalhes.

Usando Dig

Consul escuta em 127.0.0.1:8600 para consultas de DNS no cônsul. A maneira como ele determina quais nós estão disponíveis para fornecer um serviço é usando verificações que podem ser:

Um script que é executado e retorna um nagios compliant code.
Uma verificação de HTTP que retorna um código de resposta HTTP.
Uma verificação de TCP que verifica se uma porta está aberta.

O comando geral para experimentar dig é -

$ dig @127.0.0.1 -p <port> <service-name>.consul

Agora, vamos experimentar uma amostra dig comando -

$ dig @127.0.0.1 -p 8600 web.service.consul

A saída seria conforme mostrado na captura de tela a seguir.

Usando o Comando Monitor

É usado para conectar e mostrar os registros de um agente Consul em execução. Este comando mostrará os logs recentes. Também permite registrar o agente em um nível de registro relativamente alto. Consiste em vários níveis de log, que você pode seguir, como - Trace, Debug, Info, Warn e Err.

Vamos experimentar o seguinte comando -

$ consul monitor

A saída seria conforme mostrado na captura de tela a seguir.

Você também pode definir o comando do monitor usando os subcomandos como -log-level e -rpc-address. Por padrão, o endereço do RPC é 127.0.0.1:8400. Para mais informações, clique aqui .

Usando o comando Watch

Este comando nos fornece um mecanismo para observar as mudanças na lista de nós, membros do serviço, valor da chave, etc. Ele também invoca um processo com os valores mais recentes da visualização. Se nenhum processo for especificado, os valores atuais são processados paraSTDOUT, que pode ser uma maneira útil de inspecionar dados no Consul. A ajuda do Consul Watch Command tem uma variedade de opções diferentes, conforme mostrado na imagem a seguir -

Vamos experimentar uma demonstração com -type = service conforme mostrado no comando a seguir.

$ consul watch -type = service -service = consul

Para obter mais informações sobre este tópico, você pode clicar aqui .

Registrando serviços externos

Uma vez registrada, a interface DNS será capaz de retornar os 'Registros A' ou Registros CNAME apropriados para o serviço. Vamos registrar um serviço externo, como o Amazon, conforme mostrado no bloco de código a seguir e também na captura de tela.

$ sudo curl -X PUT -d '{"Datacenter": "dc1", "Node": "amazon",
"Address": "www.amazon.com",
"Service": {"Service": "shop", "Port": 80}}'
http://127.0.0.1:8500/v1/catalog/register

O comando acima especifica um serviço denominado como loja. Este Nó é denominado amazon com sua URL disponível em www.amazon.com na Porta 80. Vamos verificar a saída do consul para ter certeza de que instalamos corretamente este serviço. Para isso, abra a janela do navegador em localhost: 8500.

Para remover o serviço, podemos simplesmente usar o seguinte comando.

$ curl -X PUT -d '{"Datacenter": "dc1", "Node": "amazon"}'
http://127.0.0.1:8500/v1/catalog/deregister

Vamos verificar a IU, conforme mostrado na captura de tela a seguir.

Neste capítulo, aprenderemos sobre os eventos de failover no Consul. Isso será feito com a ajuda das seguintes funcionalidades -

Falha de cluster único
Teste Jepsen
Falha de múltiplos clusters
Tirando fotos

Vamos entender cada um deles em detalhes.

Falha de cluster único

Em uma única falha de cluster, o cluster colocado em um dos datacenter começa a falhar. Em todos os cenários, é importante certificar-se de que, em caso de failover, o sistema não pode apenas evitá-lo, mas também ter um backup em que possa confiar. Para evitar eventos de failover do Consul, usaremos algo chamado de alertas do Consul. O projeto principal pode ser encontrado em -https://github.com/AcalephStorage/consul-alerts.

Consul-alerts é um daemon altamente disponível para o envio de notificações e lembretes com base nas verificações do Consul Health. Este projeto executa um daemon e API em localhost: 9000 e se conecta ao agente cônsul local (localhost: 8500) com o datacenter padrão (dc1).

Existem dois métodos para iniciar o projeto. O primeiro método é instalá-lo viaGO. Para usuários que têm GO instalado e configurado, eles podem seguir as etapas fornecidas abaixo -

$ go get github.com/AcalephStorage/consul-alerts $ go install
$ consul-alerts start

O último comando pode ser facilmente usado para substituir as portas padrão para cônsul-alerta, opção de datacenter, cônsul-acl token, etc. O comando também pode ser escrito conforme fornecido abaixo -

$ consul-alerts start --alert-addr = localhost:9000 --consul-addr = localhost:8500
--consul-dc = dc1 --consul-acl-token = ""

O segundo método envolve o usuário no uso do Docker. Ambos os métodos são igualmente úteis em diferentes cenários. Para usar alertas do Consul sobre o Docker, vamos extrair a imagem do Docker Hub usando o seguinte comando.

$ docker pull acaleph/consul-alerts

No método Docker, podemos considerar as três opções a seguir -

Usando o Consul Agent que é construído no próprio contêiner.
Usando o Consul Agent em execução em outro Docker Container.
Usando os alertas do Consul para conectar-se a uma instância remota do Consul.

Vamos agora discutir ambos em detalhes.

Usando o Consul Agent que é construído no próprio contêiner

Vamos iniciar o agente cônsul usando o seguinte comando -

$ docker run -ti \
   --rm -p 9000:9000 \
   --hostname consul-alerts \
   --name consul-alerts \  
   --entrypoint = /bin/consul \
   acaleph/consul-alerts \
   agent -data-dir /data -server -bootstrap -client = 0.0.0.0

Aqui, estamos substituindo o entrypoint para Consul como mencionado pela bandeira --entrypoint. Junto com ele, estamos inicializando o cliente, mencionando a porta usada usando-p flag, data directory /data usando o sinalizador -data-dir e client como 0.0.0.0.

Em uma nova janela de terminal, vamos iniciar a opção de alertas do cônsul.

$ docker exec -ti consul-alerts /bin/consul-alerts start --alertaddr = 0.0.0.0:9000
--log-level = info --watch-events --watch-checks

Aqui, nas etapas acima, estamos executando os alertas-cônsules para iniciar no modo interativo. A porta do endereço de alerta é mencionada como 9000. O relógio verifica se os agentes do cônsul estão habilitados ou não junto com as verificações do cônsul.

Podemos ver claramente que os alertas cônsules foram iniciados facilmente e foi registrado um novo exame de saúde com adição do agente cônsul. O datacenter é considerado dc1, podendo ser alterado de acordo com o usuário.

Usando o Consul Agent em execução em outro Docker Container

Aqui, você pode usar qualquer tipo de imagem de cônsul para ser executada no Docker Container. Usando a imagem dos alertas do cônsul, podemos facilmente vincular o contêiner dos alertas do cônsul ao contêiner dos alertas do cônsul. Isso é feito usando o--link flag.

Note - Antes de usar o seguinte comando, certifique-se de que o container cônsul já esteja rodando em outro terminal.

$ docker run -ti \
   -p 9000:9000 \
   --hostname consul-alerts \
   --name consul-alerts \
   --link consul:consul \
   acaleph/consul-alerts start \
   --consul-addr=consul:8500 \
   --log-level = info --watch-events --watch-checks

Usando os alertas do Consul para conectar-se a uma instância remota do Consul

Aqui, devemos usar o seguinte comando para usar os alertas do Cônsul para conectar-se a uma instância remota do Cônsul.

$ docker run -ti \
   -p 9000:9000 \
   --hostname consul-alerts \
   --name consul-alerts \
   acaleph/consul-alerts start \
   --consul-addr = remote-consul-server.domain.tdl:8500 \
   --log-level = info --watch-events --watch-checks

Teste Jepsen

Jespen é uma ferramenta escrita para testar a tolerância parcial e a rede em qualquer sistema. Ele testa o sistema criando algumas operações aleatórias no sistema.Jepsen is written in Clojure. Infelizmente, para demonstração, o teste Jepsen requer um grande nível de formação de cluster com sistemas de banco de dados e, portanto, está fora do escopo de ser abordado aqui.

Jepsen funciona configurando o armazenamento de dados em teste em cinco hosts diferentes. Ele cria um cliente, para o armazenamento de dados em teste, apontando cada um dos cinco nós para enviar solicitações. Ele também cria uma série especial de cliente (s) chamado (s) de "Nemesis", que causa estragos no cluster, como cortar links entre nós usandoiptables. Em seguida, ele prossegue para fazer solicitações simultaneamente em diferentes nós enquanto, alternadamente, particiona e cura a rede.

No final da execução do teste, ele recupera o cluster, aguarda a recuperação do cluster e, em seguida, verifica se o estado intermediário e final do sistema é o esperado. Alguns trechos foram retirados daqui .

Para obter mais informações sobre os testes Jepsen, verifique aqui .

Falha de múltiplos clusters

Durante um evento de Failover de Múltiplos Clusters, os clusters implantados em vários datacenters falham em oferecer suporte aos serviços com suporte para o cliente. A Consul nos permite garantir que, quando ocorrer uma dessas condições, a Consul tenha recursos que o ajudem a habilitar os serviços neste tipo de condições.

Para que isso aconteça, examinaremos um projeto que nos ajuda a habilitar a replicação do Consul de um cluster para vários clusters. O projeto nos fornece uma maneira de replicar pares K / V em vários centros de dados do Consul usando o daemon de replicação do consul. Você pode ver este projeto da Hashicorp em -https://github.com/hashicorp/consul-replicate. Alguns dos pré-requisitos para experimentar este projeto incluem:

Golang
Docker
Consul
Git

Vamos começar com os seguintes comandos -

Note - Antes de executar o seguinte comando, certifique-se de ter o Git instalado e configurado corretamente em sua máquina.

$ git clone - https://github.com/hashicorp/consul-replicate.git

A saída seria conforme mostrado na captura de tela a seguir.

$ cd consul-replicate $ make

A saída seria conforme mostrado na captura de tela a seguir.

Se você estiver tendo problemas para construir o binário, também pode tentar extrair as imagens do Docker manualmente usando o seguinte comando -

$ docker pull library/golang:1.7.4

O comando mencionado acima criará bin / consul-replicate, que pode ser chamado como um binário. A tabela a seguir mostra a lista completa de subcomandos que abrange -

Opção	Descrição
auth	O nome de usuário de autenticação básica (e senha opcional), separados por dois pontos. Não há valor padrão.
cônsul ^*	A localização da instância do cônsul a ser consultada (pode ser um endereço IP ou FQDN) com a porta.
max-velho	A desatualização máxima de uma consulta. Se especificado, o Consule distribuirá o trabalho entre todos os servidores, em vez de apenas o líder. O valor padrão é 0 (nenhum).
ssl	Use HTTPS ao falar com o Consul. Requer que o servidor consule seja configurado para conexões seguras do servidor. O valor padrão é falso.
ssl-verificar	Verifique os certificados ao conectar-se via SSL. Isso requer o uso de -ssl. O valor padrão é verdadeiro.
syslog	Envie a saída do log para syslog (além de stdout e stderr). O valor padrão é falso
instalação de syslog	A facilidade a ser usada ao enviar para o syslog. Isso requer o uso de -syslog. O padrão é LOCAL
símbolo	O token Consul API. Não há valor padrão.
prefixo ^*	O prefixo de origem, incluindo o prefixo de destino, com opções, separados por dois pontos (:) Esta opção é aditiva e pode ser especificada várias vezes para que vários prefixos sejam replicados.
excluir	Um prefixo a ser excluído durante a replicação. Esta opção é aditiva e pode ser especificada várias vezes para que vários prefixos sejam excluídos.
esperar	O mínimo (: máximo) para aguardar estabilidade antes de replicar, separado por dois pontos (:) Se o valor máximo opcional for omitido, será considerado 4x o valor mínimo exigido. Não há valor padrão.
repetir	A quantidade de tempo de espera se o Consule retornar um erro ao se comunicar com a API. O valor padrão é 5 segundos.
config	O caminho para um arquivo de configuração ou diretório de arquivos de configuração no disco, relativo ao diretório de trabalho atual. Os valores especificados na CLI têm precedência sobre os valores especificados no arquivo de configuração. Não há valor padrão.
nível de registro	O nível de registro para saída. Isso se aplica ao registro stdout / stderr, bem como ao registro syslog (se ativado). Os valores válidos são "debug", "info", "warn e" err ". O valor padrão é" warn ".
uma vez	Execute o Consule Replicate uma vez e saia (ao contrário do comportamento padrão do daemon). (Somente CLI)
versão	Gerar informações sobre a versão e sair. (Somente CLI)

Tirando fotos

Os instantâneos são uma parte essencial e importante para gerenciar o cluster Consul em caso de backups. Por padrão, o Consul nos fornece uma maneira de salvar instantâneos do cluster do consul. O Consul nos fornece quatro subcomandos separados, usando os quais podemos usar o consul para criar instantâneos, que são -

Salvar instantâneo do cônsul
Agente instantâneo do cônsul
Consulta instantânea de inspeção
Restauração instantânea do Consul

Vamos entender cada um deles em detalhes.

Cônsul Instantâneo Salvar

Este comando é definido para recuperar um instantâneo atômico de um momento específico do estado dos servidores Consul, que inclui entradas de chave / valor, catálogo de serviços, consultas preparadas, sessões e ACLs. O instantâneo é salvo com o nome de arquivo mencionado.

$ consul snapshot save <name-of-the-file>.snap

A saída seria conforme mostrado na captura de tela a seguir.

Para verificar a presença do arquivo no diretório atual, verifique-o executando-o no diretório atual. No caso de um nó não líder, execute o seguinte comando -

$ consul snapshot save -stale <name-of-file>.snap

Agente Instantâneo Cônsul

Este subcomando inicia um processo que tira instantâneos do estado dos servidores Consul e os salva localmente ou os envia para um serviço de armazenamento remoto opcional.

Consulta Instantânea Inspeção

Ele é usado para inspecionar o instantâneo point-in-time do estado dos servidores Consul, que inclui entradas de chave / valor, catálogo de serviços, consultas preparadas, sessões e ACLs. O comando pode ser executado da seguinte forma -

Note - Lembre-se de que o seguinte comando só pode ser executado no Diretório onde o instantâneo é salvo.

$ consul snapshot save <name-of-the-file>.snap

A saída seria conforme mostrado na captura de tela a seguir.

Cônsul Snapshot Restore

O comando snapshot restore é usado para restaurar um instantâneo point-in-time do estado dos servidores Consul, que inclui entradas de chave / valor, catálogo de serviços, consultas preparadas, sessões e ACLs. O instantâneo é lido do arquivo de backup salvo.

Note - Lembre-se de que o comando a seguir só pode ser executado no diretório onde o instantâneo foi salvo.

$ consul snapshot restore <name-of-the-file>.snap

A saída seria conforme mostrado na captura de tela a seguir.

Se você está trabalhando no Consul com AWS, este projeto pode ajudá-lo a economizar algum tempo - https://github.com/pshima/consul-snapshot.

Neste capítulo, aprenderemos como usar o Consul UI (User Interface) e entender seus componentes importantes.

Cônsul UISetup

Consul nos fornece uma interface útil com a qual podemos gerenciar as coisas com facilidade. Você pode facilmente acessar a interface do usuário do cônsul em qualquer porta que desejar. O Consul UI pode ser dividido em três partes importantes, que são -

ACL - Conjunto de regras para bloquear facilmente seus clusters
Datacenter - Permite gerenciar facilmente datacenters e trabalhar com seu cluster.
Nodes - Atualização rápida nos nós que o cluster Consul está usando

Usando Consul UI

Para usar a IU do Consul, temos que instalar o pacote de IU fornecido pela equipe da Hashicorp no site do projeto do Consul. Então, vamos tentar baixá-lo da fonte e começar a usá-lo. Por favor, usesudo à frente de cada comando no caso de Permission Denied error é mostrado.

$ mkdir /opt/consul-ui
$ cd /opt/consul-ui $ wget https://releases.hashicorp.com/consul/0.7.2/consul_0.7.2_web_ui.zip
$ unzip consul_0.7.2_web_ui.zip $ rm consul_0.7.2_web_ui.zip

Você pode visualizar a saída do Consul UI usando o seguinte comando em qualquer agente.

$ consul agent -dev -ui -data-dir /tmp/consul

A saída seria conforme mostrado na captura de tela a seguir.

Por padrão, você observará a IU em http://localhost:8500/ui. A parte / ui é igual à API HTTP do cônsul.

Para usar a IU do Consul em um Docker, execute o seguinte comando para a imagem do Docker (progrium / consul) -

$ docker run -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node1 progrium/consul
-server -bootstrap -ui-dir /ui

A saída seria conforme mostrado na captura de tela a seguir.

Recursos do Consul UI

Você pode começar a navegar pelo Consul UI observando alguns de seus recursos, como -

Nodes
ACL
Key/Value
Settings
Datacenter
Services

Vamos entender cada um deles em detalhes.

Nós

O uso básico de nós no painel de interface do usuário pode ser observado conforme mostrado na captura de tela a seguir.

Quando você clica em um nó específico como node1 em nosso caso, podemos ver que as informações sobre o nó podem ser facilmente vistas como -

Você pode, a qualquer momento, cancelar o registro do nó do Consul. Torna mais fácil gerenciar os nós do ponto de vista do grupo de alto cônsul.

ACL (listas de controle de acesso)

Uma das melhores características do Consul são as Listas de Controle de Acesso. Você pode gravar suas diferentes permissões para diferentes clusters em vários datacenters. Uma das maneiras mais fáceis de ativar as ACLs é adicionar um novo arquivo json no diretório de dados do Consul. Para habilitar e atualizar a ACL, você pode adicionar o token ACL mestre no campo nas configurações e atualizá-lo usando a guia ACL

Para mais informações, por favor, verifique aqui

Valor chave

A opção Valor-chave para o Consul está, por padrão, presente na IU do Consul. Você pode criar sua própria chave usando a IU do Consul. Também oferece a opção de criar uma pasta para armazenar sua chave.

Configurações

Você pode verificar a opção de configurações da IU do Consul no lado superior direito da tela. Ao clicar nessa opção, você pode ver facilmente que o Consul oferece uma opção com a qual você pode definir suas configurações de armazenamento local e sistema de token para verificação.

Centro de dados

A opção de datacenter pode ser facilmente alterada e alternada por escolha. A IU do Consul atualiza automaticamente a detecção do número de centros de dados nos quais o Consul está trabalhando.

Serviços

A UI do Consul também fornece uma guia Serviços para configurar e visualizar os serviços que estão implementados atualmente usando o Consul. Ele nos fornece uma opção para configurar serviços dependendo dos nós.

Neste capítulo, aprenderemos como usar o Consul na AWS (Amazon Web Services).

Recursos da AWS

Alguns recursos úteis ao usar o Consul na AWS são -

Fácil de manter os estados do cluster.
Escalabilidade e alta disponibilidade.
Excelente interface de usuário para gerenciar clusters em vários datacenters.
Opções de linha de comando fáceis de usar.

Se você está procurando por uma solução com a qual podemos facilmente implantar o Consul no AWS com Docker. Confira o seguinte link -https://github.com/dwmkerr/terraform-consul-cluster.

Implantação AWS

Para usar a AWS, podemos começar criando um VPC para ela. Para implantar o cônsul na AWS, usaremos um modelo de início rápido fornecido pelo serviço AWS. Este modelo pode ser facilmente encontrado em -https://aws.amazon.com/quickstart/architecture/consul/.

Para este capítulo, presumimos que você já conheça os fundamentos da AWS. O modelo AWS CloudFormation criará os seguintes componentes -

UMA VPC com sub-redes públicas e privadas em três zonas de disponibilidade.
UMA Seed Consul server e um Seed client junto com dois grupos de Auto Scaling.
Você pode escolher criar 3, 5 ou 7 servidores. O número de clientes é definido como três por padrão, mas é configurável pelo usuário.
Dnsmasq, que é instalado e configurado para Consul como parte da instalação.
Um cluster Consul usando bootstrap_expect opção.

Dê uma olhada na ilustração a seguir para entender como os diferentes componentes estão interconectados.

Usando o AWS

Certifique-se de já ter feito login em sua infraestrutura AWS usando o console da web. Agora, coloque o seguinte URL na janela do navegador. Depois de digitar o URL e pressionar Enter, o site da AWS será aberto.

Para esta demonstração, escolheremos implantá-lo em um novo VPC (Virtual Private Cloud). Você sempre pode verificar seu Gerenciamento de VPC da AWS no seguinte link - https: // <awsregion> .console.aws.amazon.com / vpc / home. Para usuários iniciantes, a região padrão é West Oregon, nos EUA. Portanto, você pode visitar diretamente o URL em - https: // us-west- 2.console.aws.amazon.com/vpc/home.

Como você pode ver, o serviço VPC da AWS está operacional e você não tem VPC, ou seja, já está em execução / configurado em sua conta AWS. Agora, clique na opção Deploy no AWS em um novo VPC ou Deploy em um VPC existente de acordo com sua escolha. Você pode visualizar a opção no site conforme mostrado na imagem a seguir.

Ao clicar na opção descrita acima, você verá que se abre outra janela, que é semelhante à mostrada abaixo.

Como você pode ver no modelo, o URL já foi escolhido em seu nome pela AWS. Também lhe dá a liberdade de personalizar o modelo de formação de nuvem como você quiser. Você pode personalizá-lo se quiser e clicar no botão Próximo para continuar.

Como você pode ver, existem vários valores e opções diferentes que você pode configurar aqui. Para algumas alterações, você pode renomeá-lo de acordo com sua escolha em substituição ao nome HashiCorp-Consul. Fique à vontade para alterar as outras opções de acordo com sua conveniência.

Como você pode ver acima, várias opções podem ser personalizadas de acordo com sua escolha. Como você pode ver na seção Configuração do Consul, o tipo de instância padrão do Consul Cluster ét2.medium. Você pode alterá-lo para sua escolha de instância.

Note - Preencha o intervalo permitido como 0.0.0.0/0 para permitir qualquer endereço IP.

Por padrão, o número de servidores cônsul é três. Você pode alterá-lo para cinco para testar mais servidores no ambiente cônsul. Na configuração de início rápido, você pode ver que umS3 buckettambém é usado e nomeado para a referência de início rápido por padrão. Quando você terminar as alterações, clique no botão Avançar na parte inferior da tela.

Na captura de tela acima, você pode ver que há uma opção de usar Tags para melhor identificação e utilização. Junto com ele, você também tem a opção de escolher a função IAM para fornecer acesso a outras pessoas à sua pilha VPC. Você pode escolher de acordo com sua escolha de opções.

Para opções mais avançadas, selecione o advanced tab, onde você pode habilitar Amazon SNS para seu VPC para suas notificações. Prossiga para a opção Avançar quando tiver concluído os detalhes.

A tela acima mostra os detalhes revisados da pilha cônsul que você escolheu. Você pode revisar as opções selecionadas para a pilha VPC e prosseguir para a parte inferior da tela, marque a caixa de confirmação para a criação de recursos de IAM e clique no botão Criar para concluir a formação da pilha.

Você pode verificar a saída na seção CloudFormation Stack do console de gerenciamento da AWS. De acordo com a saída do VPC, você também pode verificá-la na seção VPC do console da AWS, conforme mostrado na captura de tela abaixo.

Se você estiver apenas testando o Modelo do Consul, certifique-se de excluir os recursos que usou. Você pode fazer isso facilmente excluindo o CloudFormation Stack na seção CloudFormation e o VPC no VPC Dashboard.