Docker + Consul + Registrator

di Andrea Zani, in Memo,

Stavo scrivendo qualche nota aggiuntiva su Docker Swarm quando mi sono deciso di scrivere un post in più piuttosto che incasinare con troppa roba uno solo – già non sono capace di scrivere, se metto poi troppa roba non si capisce veramente nulla…

In un post precedente avevo scritto i vantaggi di Consul nel discovery dei service. Ripropongo velocemente i vari passaggi per installarlo in una distribuzione Linux – per Windows si veda il post precedente, e anche se sono passati mesi ormai, non ho ancora investigato sul punto di integrazione tra Consul e i DNS del sistema operativo.

Innanzitutto, per fare in modo che Consul possa modificare il DNS della macchina, è necessario installare un servizio di DNS, nel mio caso ho scelto la semplicità di Dnsmasq. Sulle Debian e derivate è sufficiente:

apt-get install dnsmasq

Fatto questo ed essersi assicurati che il servizio è attivo, si deve aggiungere una linea in un file di configurazione in modo che possa venire usato da Consul. Nella directory /etc/dnsmasq si deve creare un file dal nome 10-consul con questo contenuto:

# Enable forward lookup of the 'consul' domain:
server=/consul/127.0.0.1#8600

Ora è il momento di Consul. Scaricato dai repositori o dal sito, vediamo cosa offre di utile con Docker. Innanzitutto nei test che descriverò qui ho utilizzato due macchine virtuali con questi IP:

  • 192.168.56.102
  • 192.168.56.101

Se sulle macchine non ci fosse la directory /etc/consul.d, consiglio di crearla perché può essere utile in caso si debbano creare configurazioni. Sulla macchina 102, avvio Consul:

consul agent -server -bootstrap-expect 1 \
-data-dir /tmp/consul -node=agent-one \
-bind=192.168.56.102 -config-dir /etc/consul.d

Quindi sulla macchina 101:

consul agent -data-dir /tmp/consul \
-node=agent-two \
-bind=192.168.56.101 -config-dir /etc/consul.d

Infine dalla macchina 102, collego le due istanze di Consul:

consul join 192.168.56.101

Se tutto è andato bene:

# consul members
Node Address Status Type Build Protocol DC
agent-one 192.168.56.102:8301 alive server 0.6.4 2 dc1
agent-two 192.168.56.101:8301 alive client 0.6.4 2 dc1

Ok, e ora siamo allo stesso punto del post precedente. Ora è ora di tirare in mezzo Docker. Esiste un servizio esterno che è in grado di aggiornare direttamente Consul con tutti i nuovi container creati in Docker e tutto automaticamente. Questo servizio di chiama Registrator. Per utilizzarlo basta lanciarlo sulle macchine interessate come container in Docker. Sulla macchina 102:

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

Ora riprendiamo in mano la semplice API che avevo creato, e su questa macchina l'avvio:

docker run -it --name app1 -p 5000:5000 sbraer/aspnetcorelinux

Controllo che funzioni:

#curl localhost:5000/api/systeminfo
[{"guid":"a382678c-e38a-445c-831c-582f775c54f7"}]

Automaticamente questa API sarà inserita tra i servizi di Consul.

#curl localhost:8500/v1/catalog/services
{"aspnetcorelinux":[],"consul":[]}

Ed ecco la nostra API – aspnetcorelinux – presente. Qui si può vedere che non viene utilizzato il nome che avevo dato quando avevo creato il container, ma il nome stessa dell'immagine utilizzata. Ora controllo che funzioni con i DNS di Consul:

#curl aspnetcorelinux.service.consul:5000/api/systeminfo
[{"guid":"a382678c-e38a-445c-831c-582f775c54f7"}]

Ecco che funziona. E sulla seconda macchina, la 101? Vediamo se Consul ha aggiornato anche su quella macchina la lista dei servizi:

#curl localhost:8500/v1/catalog/services
{"aspnetcorelinux":[],"consul":[]}

Il servizio c'è, ma funziona?

#curl aspnetcorelinux.service.consul:5000/api/systeminfo
[{"guid":"a382678c-e38a-445c-831c-582f775c54f7"}]

Perfetto. Sempre in riferimento a quel mio post, avevo scritto anche della capacità di Consul di fare load balancing delle richieste. Per controllare questo, installo lo stesso servizio sulla seconda macchina:

docker run -it --name app1 -p 5000:5000 sbraer/aspnetcorelinux

Vediamo se funziona:

curl aspnetcorelinux.service.consul:5000/api/systeminfo
[{"guid":"a382678c-e38a-445c-831c-582f775c54f7"}]

Il comando visto prima non dà differenze:

#curl localhost:8500/v1/catalog/services
{"aspnetcorelinux":[],"consul":[]}

Però possiamo avere più dettagli specifici con:

#curl localhost:8500/v1/catalog/service/aspnetcorelinux

Ed ecco il risultato:

Capture2

L'api è disponibile su entrambe le macchine e farà load balancing in caso di chiamata da un terzo pc – Consul rimanda sempre alla stessa macchina se il servizio è presente.

Dimenticavo, se qualcuno si stesse chiedendo se Registrator funziona anche con Docker Swarm, la risposta è no. Leggendo varie discussioni a riguardo, sembra che Docker Swarm non esponga eventi che possono essere intercettati da servizi esterni, quindi Registrator non è in grado di interecettare la creazione e la rimozione dei servizi Swarm. In futuro? Mah...

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Nella stessa categoria
I più letti del mese