Usando o Consul – parte 4

consul-4_abertura

Relembrando que na primeira parte foi feita uma rápida apresentação da ferramenta, na segunda foram criadas as máquinas virtuais e configurado um cluster e na terceira¹ acrescentada criptografia e também verificações a ele.

Nesta última parte é a vez de usar o repositório de dados do Consul mas antesé bom cuidar de algumas “pontas soltas”.

(¹) Foi corrigido um bug no script de inicialização que eu montei para o Consul. Em determinadas situações ele não criava o arquivo “/run/consul.pid” do modo correto, daí o serviço era iniciado normalmente mas ficava impossível terminá-lo a partir dele.

A verificação “Ping”

A primeira delas é quanto a verificação chamada “ping” (aquela que apenas copiei dos exemplos do Consul). Sua função é verificar a conectividade do nó com a Internet — o que ela faz é “pingar” o Google a cada 30 segundos e atualizar o status de acordo com o retorno. Apesar de ter comentado que a rede do cluster não deveria ser pública e que existiam duas interfaces de rede em cada nó faltou mostrar a topologia (maluca) da rede do cluster:

consul-4_rede-do-cluster

A primeira interface de rede (eth0), usando NAT, é a conexão principal e todos os hosts tem o mesmo endereço de IP — sim, todas as máquinas virtuais são 10.0.2.15 — e é por onde se dá o acesso à Internet e feita a conexão quando vagrant ssh é usado. A a outra (eth1) é usada exclusivamente para o tráfego do Consul, a rede 172.20.20.0/255, e também para meu acesso à interface web — lembrando que me computador também faz parte desta rede sendo o 172.20.20.1.

Aliás, um teste bastante interessante é fazer:

$ vagrant ssh n0
vagrant@n0:~$ sudo ifdown eth0 ; sleep 120 ; sudo ifup eth0

E acompanhar n0 indicando erros na verificação “ping” durante dois minutos pela interface web do Consul… 🙂

Adicionando novos serviços

Bom lembrar que o Vagrant foi utilizado apenas para facilitar a configuração das máquinas virtuais (os scripts que instalaram a ferramenta, copiaram os arquivos para os locais corretos etc) e apesar de ambos serem da HashiCorp funcionam de forma independente um do outro.

Então é chegado o momento de deixar o cluster um pouco assimétrico instalando o MongoDB² em apenas um dos nós mas desta vez fazendo do jeito “clássico”:

$ vagrant ssh n2
vagrant@n2:~$ sudo apt-get install mongodb
...
Setting up mongodb (1:2.0.6-1.1+deb7u1) ...
vagrant@n2:~$ mongo
MongoDB shell version: 2.0.6
connecting to: test
> exit
bye

Claro, também é preciso criar um arquivo JSON com as informações do serviço e sua respectiva verificação com o arquivo “/etc/consul.d/mongodb.json”:

{
  "service": {
        "name": "mongodb",
        "tags": ["database","db","nosql"],
        "port": 28017,
        "check": {
            "tcp": "localhost:28017",
            "interval": "20s"
        }
    }
}

Esta verificação é diferente das criadas anteriormente, ela é do tipo “tcp” e se encarrega de testar se há conexão pela porta padrão do MongoDB, a 28017, a cada 20s. Daí é usar consul reload para recarregar as configurações do agente dentro do nó e pronto:

vagrant@n2:~$ cat /var/log/consul.log
...
    2016/10/16 14:43:40 [INFO] agent: Synced service 'web'
    2016/10/16 14:43:40 [INFO] agent: Synced service 'mongodb'
    2016/10/16 14:43:40 [INFO] agent: Synced check 'ping'
    2016/10/16 14:43:49 [INFO] agent: Synced check 'service:web'
    2016/10/16 14:43:55 [INFO] agent: Synced check 'service:mongodb'
...

Grifei as duas linhas para lembrar que  verificações e serviços são coisas distintas, aliás não existe a necessidade de um serviço estar atrelado a uma verificação. Tanto que também instalei o MongoDB em n1 mas desta vez definindo o serviço sem rotina de verificação, ou seja:

{
  "service": {
        "name": "mongodb",
        "tags": ["database","db","nosql"],
        "port": 28017
    }
}

Apesar da ausência da verificação para o Consul eles ainda compõe o mesmo serviço:

vagrant@n0:~$ dig @127.0.0.1 -p 8600 mongodb.service.consul
...
mongodb.service.consul.    0    IN    A    172.20.20.11
mongodb.service.consul.    0    IN    A    172.20.20.12
...

Mas sem a rotina de verificação em n1 ele não tomará conhecimento de eventuais falhas, o manterá como disponível dentro do cluster e consequentemente retornará uma informação errada na descoberta de serviços.

(²) Apenas para a parte de descobrimento de serviços pelo Consul, para a operação do MongoDB em cluster (com réplicas e/ou shards) a coisa é bem diferente.

Key/Value

O Consul funciona como um “catálogo” que armazena/atualiza informações sobre serviços, suas mudanças de estado, nós etc e que também possibilita o uso desta mesma estrutura como um repositório simples (e distribuído) de dados — aliás, não pense nisto como substituto a bancos de dados para aplicações, apenas como um local onde é possível armazenar de forma prática informações que ficam rapidamente disponíveis aos nós do cluster.

As informações são armazenadas no formato de chave (key) e seu correspondente valor (value) ou um conjunto de outras chaves — em uma estrutura em árvore — e isto é feito a partir da própria API da ferramenta. Por exemplo, para armazenar “valor” dentro de “chave1”, faça³:

$ curl -X PUT -d "valor" http://localhost:8500/v1/kv/chave1

Para recuperar o valor armazenado use:

$ curl http://localhost:8500/v1/kv/chave1
...
[{"LockIndex":0,"Key":"chave1","Flags":0,"Value":"dmFsb3I=","CreateInde
x":10672,"ModifyIndex":10672}]

Mas onde está o valor “valor” armazenado em “chave1”? O Consul retorna o dado codificado em BASE64 dentro da chave “Value”:

$ curl http://localhost:8500/v1/kv/chave1 | ./decode_value.py
...
valor

O programa “decode_value.py” é algo que fiz para extrair do JSON apenas a chave “Value” e decodificar o conteúdo:

#!/usr/bin/env python2
import base64, json, sys
print base64.b64decode(json.load(sys.stdin)[0]['Value'])

Para alterar o conteúdo basta enviar o novo valor para a chave e para remover, use:

$ curl -X DELETE -d "valor" http://localhost:8500/v1/kv/chave1
true

Para listar todas as chaves armazenadas a partir de uma chave use o parâmetro “?recurse”:

$ curl http://localhost:8500/v1/kv/?recurse

Um outro exemplo, digamos que eu queira manter um registro da versão do kernel, arquitetura etc dos nós do cluster. Eu posso criar algo assim:

vagrant@n0:~$ curl -X PUT -d "$( uname -a )" \
http://localhost:8500/v1/kv/cluster/n0
true

Executar e deixar esta informação automaticamente disponível para todo o cluster:

vagrant@n2:~$ curl http://localhost:8500/v1/kv/cluster/n0 \
2>/dev/null | ./decode_value.py 
Linux n0 3.2.0-4-amd64 #1 SMP Debian 3.2.81-1 x86_64 GNU/Linux

É bobo mas ajuda a mostrar que o uso deste repositório serviria principalmente como uma forma de expandir os recursos da ferramenta mesclando informações já gerenciadas pelo Consul com outras coletadas em outros programas e armazenados aqui.

Aliás, vale a pena conhecer as bibliotecas que permitem usar o Consul com linguagens de programação como Java, Node.js, PHP, Python, Ruby etc — você não está obrigado a usar somente o shell 🙂

Maiores informações sobre como utilizar o armazenamento Key/Value podem ser obtidos na documentação da ferramenta.

(³) Sim, é possível enviar dados via HTTP usando o curl como se fosse um navegador web.

Considerações finais

Preferi não falar muito sobre a estrutura dos protocolos internos do Consul e também sobre o conceito de datacenter — conjuntos de nós e servidores que estão “em uma mesma rede” ou “mesmo espaço geográfico” — pois neste caso acabaria precisando de bem mais que quatro nós e um deles como servidor.

A interface DNS pode ser interligada ao BIND para a resolução de nomes (veja o guia: Forwarding DNS) e também pode ser configurado para o envio de informações para agregadores de estatísticas como Statsite ou StatsD para, por exemplo, produzir gráficos em ferramentas como o Graphite.

Os arquivos citados acima estão disponíveis na ramificação “parte-4” do repositório no GitHub e basta fazer:

$ cd ~/Vagrant/consul
$ git checkout parte-4
$ git pull

Aliás, não era minha ideia a princípio mas no final o cluster de testes ficou bastante parecido com a versão de demonstração do Consul. 🙂

Anúncios

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

  1. Giovanni,

    Voce é o Giavanni R. NUnes, que postou a pinagem do RGC do MSX gradiente expert por ai?
    De qual versão de MSX é aquilo?

    Curtir

    • Sim, fui eu. A porta RGB dos Expert existe somente nas versões 1.0 e 1.1 e ela é diferente da porta RGB do padrão MSX. Na série plus ela foi removida mas pode ser recolocada com a instalação dos componentes faltosos, do conector e, claro, do respectivo buraco do gabinete.

      Curtir

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