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:

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:

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...