Docker Swarm + GlusterFS + Keepalived : poorman-style, super-resilient, cloud infrastructure

Con estremo ritardo rispetto al resto del mondo moderno, ho iniziato finalmente a giocare con Docker, in particolare, la sua modalità Swarm (orchestrazione nativa).

In questo articolo voglio raccontare alcuni aspetti della mia installazione di prova, senza scendere nel dettaglio di cose ovvie, ritrovabili in qualsiasi how-to sull’argomento. Ovviamente si tratta di un laboratorio di prova, senza alcuna pretesa di essere roba production-ready.

Inanzitutto, ho installato 3 VM sulla mia infrastruttura Proxmox, con Debian 10, sulle quali ho installato docker seguendo una delle tante guide.

docker1    192.168.1.214
docker2    192.168.1.215
docker3    192.168.1.216

Successivamente ho scelto di creare una swarm, dove tutti e tre i nodi siano manager, in quanto un manager è in realtà anche un worker.

A questo punto ho installato e configurato GlusterFS su tutti e tre i nodi e ho fatto in modo che venga automaticamente montato al boot:

#su tutti i nodi:
apt install glusterfs-server
systemctl start glusterd
systemctl enable glusterd
sudo mkdir -p /gluster/volumes
echo 'localhost:/staging-gfs /mnt glusterfs defaults,_netdev,backupvolfile-server=localhost 0 0' >> /etc/fstab

#solo su docker1:
gluster peer probe docker2
gluster peer probe docker3
gluster volume create staging-gfs replica 3 docker1:/gluster/volumes/ docker2:/gluster/volumes/ docker3:/gluster/volumes/ force
gluster volume start staging-gfs

… dopo il reboot dei tre nodi, ci ritroviamo con un filesystem replicato montato sotto /mnt/.

Questo e’ il percorso dove andremo in futuro a creare le directory per effettuare il bind-mount all’interno dei container; essendo replicata su tutti i nodi, non ci importerà su quale nodo giri un container: troverà comunque la propria roba nello stesso posto.

A questo punto, ho installato e configurato, su tutti i nodi, keepalived:

apt install keepalived
vi /etc/keepalived/keepalived.conf

il file di configurazione è uguale per tutti i nodi:

vrrp_script leader_node {
    script "/usr/bin/docker node inspect self | /bin/grep Leader" 
    interval 5
    weight -20
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    interface ens18
    state BACKUP
    virtual_router_id 205
    priority 100
    virtual_ipaddress {
        192.168.1.218/32
    }
    track_script {
        leader_node
    }
}

Le cose importanti di questo file sono:

• interface ens18: la scheda di rete su cui tirare su l’ip virtuale, cambiate secondo il vostro setup
• virtual_ipaddress: l’indirizzo IP virtuale, al quale potrete puntare tutti i servizi esposti dalla swarm
• script: è un semplice script che controlla se il nodo su cui viene eseguito è leader della swarm. Se lo è, si prenderà l’ip virtuale, altrimenti no.

#su tutti i nodi:
/etc/init.d/keepalived restart

Adesso, potremo puntare a tutti i servizi esposti dalla nostra swarm, indipendentemente da quale nodo li abbia in esecuzione, semplicemente utilizzando l’ip virtuale che abbiamo appena configurato, ci penserà poi la swarm stessa a indirizzarci attraverso i suoi loadbalancer al (o ai) container che ci interessano.

In caso di morte di un nodo, l’ip passerà automaticamente al nuovo leader e i container verranno istanziati nuovamente sui nodi rimanenti, trovando il contenuto del proprio storage persistente grazie a GlusterFS.

Attenzione a quanti container richiedete di istanziare per lo stesso servizio: stranamente (si, sono sarcastico) molte applicazioni non sono affatto contente se più applicazioni tentano di scrivere su gli stessi file nello stesso momento

UPDATE: in questo setup sono stati successivamente rilevati i seguenti problemi, con le relative soluzioni:

• GlusterFS non viene montato al boot.
  Nonostante abbiamo inserito correttamente la relativa righa in fstab, glusterfs non viene montato al boot, questo a causa di systemd (e chi l’avrebbe mai detto?). Per ovviare, è sufficiente creare un file di override:

# cat /etc/systemd/system/srv.mount.d/override.conf
[Unit]
After=glusterfs-server.service
Wants=glusterfs-server.service

• Keepalived occupa il 100% del processore (senza motivo).
  Questo probabilmente succede solo se usate debian 10 stable per il setup, in quanto keepalived è vecchio (2.0.10), mentre questo bug è stato corretto dall versione 2.0.20. Purtoppo non esistono backports di keepalived per buster, occorre usare la versione in SID (2.1.5).
  Quindi basta aggiungere i repo di SID, configurare apt come segue:

# cat /etc/apt/preferences
Package: *
Pin: release  a=stable
Pin-Priority: 700

Package: *
Pin: release  a=unstable
Pin-Priority: 100

e installare keepalived da SID:

# apt-get -t unstable install keepalived