Usando o Consul – parte 2

consul-2_monitor

A primeira parte serviu apenas como uma apresentação do Consul mostrando seus recursos e algumas de suas funcionalidades — basicamente as interfaces que consultam as informações armazenadas via DNS e HTTP. Nesta parte será criado e configurado um pequeno cluster do Consul com a ajuda do Vagrant e do VirtualBox.

Criando um cluster

Para simplificar um pouco e permitir que seja facilmente reproduzido montei¹ um arquivo com o Vagrant para criar as máquinas virtuais necessárias para o cluster, deixando tudo mais ou menos configurado e em uma rede virtual própria. Sendo assim:

$ mkdir ~/Vagrant
$ cd ~/Vagrant
$ git clone https://github.com/plainspooky/consul.git
$ cd consul
$ vagrant up

Daí é aguardar o Vagrant fazer o resto; serão criadas quatro máquinas virtuais e em cada uma delas o Consul será instalado. Mas desta vez de uma forma “mais correta”, ou seja, além da cópia do binário também são criados:

  1. Usuário específico para rodar o serviço;
  2. Diretório para armazenar a base de dados;
  3. Local/locais para armazenar a configuração e
  4. Script para cuidar do início, encerramento e reinício do serviço.

Há motivo para isto tudo? Sim, o programa não necessita ser executado com privilégios especiais (seja como usuário “root”,  através do sudo etc) mas armazena informações que dizem respeito somente a ele e , claro, precisará ser iniciado sozinho quando o host é reiniciado.

No final do processo estarão disponíveis quatro hosts identificados como:

  • n0 (172.20.20.10);
  • n1 (172.20.20.11);
  • n2 (172.20.20.12) e
  • n3 (172.20.20.13).

Para minimizar o consumo de memória do hospedeiro cada máquina virtual é criada com apenas 192MiB de RAM — sim, é possível rodar este cluster em um computador com 2GiB de RAM, eu testei!

(¹) Fiz baseado no Vagrant Consul Demo mas apenas aumentei o número de nós e acrescentei mas algumas coisas. Até poderia deixar tudo mais automatizado mas aí não teria lá muita graça! 🙂

O agente do Consul

O “agente” é a parte do Consul que ficará em execução em todos os hosts e que opera em dois modos.No primeiro, o modo cliente (o modo padrão), ele cuida de prover as interfaces para acesso via DNS e HTTP, verificar o estado dos serviços e sincronizar as informações. E no outro, o modo servidor, além das atividades do cliente, agregada funções relacionadas com a gerência do cluster como replicação de dados, chamadas via RPC, troca de informações entre os datacenter etc.

Servidor do cluster

Todos os hosts já estão com o Consul instalado mas como há duas interfaces de rede — a máquina virtual tem a eth0 conectada via NAT e a eth1 em uma rede privada — é necessário indicar qual delas será utilizada pelo programa.

Para configurar o servidor eu simplifiquei um pouco criando pequeno arquivo de configuração em “/etc/defaults/consul”, então:

$ vagrant ssh n0
Linux wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.81-1 x86_64

The programs included with the Debian GNU/Linux system are free
software; the exact distribution terms for each program are described
in the individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have mail.
vagrant@n0:~$ sudo nano /etc/default/consul

Deixe o arquivo assim:

BIND_IP=172.20.20.10
MODE=server

Use «Ctrl»+«X» para sair do nano — o clone de vi que vem por padrão na Debian não é  das coisas mais saudáveis, mas você pode usá-lo se desejar. 🙂

Depois inicie o agente com:

$ sudo /etc/init.d/consul start
$ consul monitor

Não feche o terminal, deixe-o quietinho por enquanto cuspindo mensagens na tela…

Ah sim, a documentação recomenda que existam entre 3 a 5 servidores por datacenter para prover a correta replicação das informações do cluster. Como isto aqui é um teste ele terá apenas 1 servidor e por este motivo o agente do  Consul é executado com o parâmetro “-bootstrap” e assim não ficar esperando que outros servidores aparecerem.

Configurando os clientes

Em um segundo terminal, acesse cada um dos outros nós e faça:

$ vagrant ssh n1
...
vagrant@n1:~$ sudo nano /etc/default/consul

Edite o arquivo “/etc/defaults/consul” para refletir a interface da máquina virtuais, ou seja, os endereços IP de 172.20.20.11 a 172.20.20.13 dependendo de cada host. Inicie o agente e também adicione-o ao cluster:

vagrant@n1:~$ sudo /etc/init.d/consul restart
vagrant@n1:~$ consul join 172.20.20.10

Feche a conexão SSH e repita o processo de editar o arquivo, iniciar o dæmon e entrar no cluster também para os hosts n2 e n3.

Testando o Cluster

Finalizada a tarefa de configuração volte para n0, pressione «Ctrl»+«C» para sair do monitor e faça:

vagrant@n0:~$ consul members
Node  Address            Status  Type    Build  Protocol  DC
n0    172.20.20.10:8301  alive   server  0.7.0  2         dc1
n1    172.20.20.11:8301  alive   client  0.7.0  2         dc1
n2    172.20.20.12:8301  alive   client  0.7.0  2         dc1
n3    172.20.20.13:8301  alive   client  0.7.0  2         dc1

Aliás, isto pode ser feito de qualquer nó do cluster não necessariamente do como servidor.

Repetindo o teste feito na primeira parte para ver se funciona:

vagrant@n0:~$ curl localhost:8500/v1/catalog/nodes
[{"Node":"n0","Address":"172.20.20.10","TaggedAddresses":{"lan":"172
.20.20.10","wan":"172.20.20.10"},"CreateIndex":4,"ModifyIndex":10},{
"Node":"n1","Address":"172.20.20.11","TaggedAddresses":{"lan":"172.2
0.20.11","wan":"172.20.20.11"},"CreateIndex":6,"ModifyIndex":7},{"No
de":"n2","Address":"172.20.20.12","TaggedAddresses":{"lan":"172.20.2
0.12","wan":"172.20.20.12"},"CreateIndex":5,"ModifyIndex":9},{"Node"
:"n3","Address":"172.20.20.13","TaggedAddresses":{"lan":"172.20.20.1
3","wan":"172.20.20.13"},"CreateIndex":8,"ModifyIndex":11}]

Mas que tal testar algo mais interessante e realmente diferente? — as cores são por minha própria conta, apenas para ajudar a diferenciar a saída. 🙂

vagrant@n0:~$ consul exec uptime
    n1:  22:05:06 up  1:37,  0 users, load average: 0.00, 0.02, 0.05
    n1:
    n3:  22:05:05 up 47 min,  0 users, load average: 0.00, 0.01, 0.05
    n3:
==> n1: finished with exit code 0
    n2:  22:05:06 up  1:31,  0 users, load average: 0.03, 0.04, 0.05
    n2:
==> n3: finished with exit code 0
==> n2: finished with exit code 0
    n0:  22:05:06 up 39 min,  1 user, load average: 0.62, 0.22, 0.17
    n0:
==> n0: finished with exit code 0
4 / 4 node(s) completed / acknowledged

Justamente! Sim este comando permite executar remotamente comandos em um outro nó, em um conjunto de nós ou, como eu fiz displicentemente, em todo o cluster —  aliás é mais um motivo para (i) ele executá-lo em um usuário só dele e (ii) ter uma rede separada só para estas atividades.

Antes de pensar em riscos de segurança, é possível sim utilizar encriptação na comunicação entre os nós e também usar TLS para verificar a autenticidade dos hosts no cluster.

Introdução aos serviços

Uma das funcionalidades do Consul é a descoberta de serviços, ou seja, ele se encarrega de catalogar aquilo que cada nó disponibiliza na rede, isto é feito através de um arquivo em JSON, como este aqui:

{
    "service": {
        "name": "web",
        "tags": ["lighttpd"],
        "port": 80
    }
}

Estas definições devem ficar no diretório definido para guardar a configuração — no caso do script que montei é “/etc/consul.d” — e sempre que o Consul é iniciado (ou reiniciado) ele se encarrega de fazer a leitura dos arquivos que encontrar por lá.

Propositalmente o lighttpd foi instalado em todas as máquinas virtuais faça o seguinte em n0:

vagrant@n0:~$ cd /etc/consul.d
vagrant@n0:~$ sudo cp /vagrant/json/web.json .
vagrant@n0:~$ consul reload
vagrant@n0:~$ dig @127.0.0.1 -p 8600 web.service.consul
...
;; ANSWER SECTION:
web.service.consul.    0    IN    A    172.20.20.10
...

Depois escolha ao acaso algum dos outros nós do cluster, repita a operação e ao repetir a consulta (mesmo que de um terceiro nó) será possível verificar que a informação já se encontra espalhada:

vagrant@n3:~$ dig @127.0.0.1 -p 8600 web.service.consul
...
web.service.consul.    0    IN    A    172.20.20.10
web.service.consul.    0    IN    A    172.20.20.11
...

É possível adicionar mais funcionalidades ao serviço mas isto ficará para a próxima parte.

Fim da segunda parte

Por enquanto é isso, na próxima parte será a vez de expandir o conceito dos serviços criando verificações, testando se funcionam como deveriam e, claro, colocando a interface web em operação.

Não esqueça de “desmontar” o cluster:

$ vagrant halt
==> n3: Attempting graceful shutdown of VM...
==> n2: Attempting graceful shutdown of VM...
==> n1: Attempting graceful shutdown of VM...
==> n0: Attempting graceful shutdown of VM...

E até!

Anúncios

3 comentários sobre “Usando o Consul – parte 2

  1. Pingback: Usando o Consul – parte 2 - cluster usando Vagrant e VirtualBox - Linux em Ação XYZ

  2. Pingback: Usando o Consul – parte 3 | giovannireisnunes

  3. Pingback: Usando o Consul – parte 4 | giovannireisnunes

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s