Zero-downtime Docker Swarm Upgrade

APIHour #62 😎

Menu du jour

  • Docker Swarm en 2 phrases
  • Pourquoi mettre Ă  jour notre cluster ?
  • État des lieux d'entrĂ©e
  • La valse des nodes
  • Pour conclure

Docker Swarm en 2 phrases

  • Outil de clustering de containers
  • BundlĂ© nativement dans Docker
  • GĂšre tout plein de trucs pour nous :
    • RĂ©seaux virtuels chiffrĂ©s inter-nodes
    • RĂ©plication (avec healthcheck, anti-affinitĂ©, etc)
    • Secrets, configurations
  • Pour rĂ©sumer : un Kubernetes sans CSI, sans RBAC...
  • ... Mais simple Ă  maintenir, utiliser et stable.

=> APIHour #49 - RETEX sur Docker Swarm Mode (par notre Président)

Pourquoi mettre Ă  jour ?

  • Pour des raisons de sĂ©curitĂ© (le cluster date de 2021) ;
  • Pour ne pas repartir de zĂ©ro (et vautrer la prod) ;
  • Pour prouver qu'on sait le faire (en cas de grosse panne) ;
  • Pour avoir des (rares) nouvelles features de Docker et de Swarm ;
  • Pour en profiter pour faire des grosses modifications sur le cluster ;
  • Et pour "nettoyer" les instances (au fil des pannes, on a bidouillĂ© parfois Ă  la main...).

État des lieux d'entrĂ©e

  • Un cluster de trois noeuds Swarm (Docker 20) ;
  • Les instances sous Alpine 3.14 ;
  • ExposĂ©es Ă  travers un Load-Balancer (qu'on ne gĂšre pas mais qu'on peut controler via DNS) ;
  • Le tout sur OpenStack en IaC (OpenTofu) ;
  • Et Ă©normĂ©ment de tooling en Ansible.

Le tout gÚre environ 50 (micro-)services en production. Quand ça tombe, on prend un ticket. Et on aime pas les tickets.

Objectifs :

  • Passer sur Docker Engine 26.0.2 ;
  • Et sous Alpine 3.18 ;
  • Le tout proprement et sans downtime.

  • Et comme on aime le challenge, on se fixe pour rĂšgle de ne jamais dĂ©passer 3 instances actives.

La valse des nodes

Question : comment faire pour effectuer notre opération ?

  1. On retire notre premiĂšre instance du record DNS (et donc du LB) ;
  2. On demande Ă  Swarm d'Ă©vacuer les containers (docker update --availability=drain swarm-1) ;
  3. On retire le noeud du cluster (docker node demote swarm-1 ; docker swarm leave) ;
  4. On détruit et reconstruit l'instance ;
  5. On fait rejoindre le noeud au cluster ;
  6. On rajoute le cluster au DNS ;
  7. Et on recommence deux fois.

Les problÚmes (forcément)

  • On gĂšre notre LB via DNS : vive le Time To Live 🙃
    • On abaisse de 3600 Ă  300 secondes quand on s'en rend compte (temporairement)
    • En attendant, on va prendre un cafĂ©...
    • Et Ă  chaque entrĂ©e/sortie de node, il a fallu attendre 5-6 minutes.

OpenTofu, relation amour-haine

  • Quand nous avons fait notre code OpenTofu, nous n'avions pas anticipĂ© de dĂ©truire des machines spĂ©cifiques
  • Nous utilisions un count pour crĂ©er nos instances. Pour scale-up/down, c'est super, pour le reste, non.
  • => De gros changements pour passer sur des for_each avec des listes
  • Et aller bidouiller le .tfstate en dur pour ne pas devoir tout dĂ©truire et reconstruire. 😎

Hormis ça, tout va bien !

  • Notre outillage Ansible se comporte Ă  merveille ;
  • Swarm retrouve tout seul ses petits quand on rajoute les noeuds ;
  • Les sorties de noeuds se font proprement et sans interruptions => 0 tickets reçus 🎉
  • Et nous sommes sur un cluster tout neuf et Ă  jour !

Pour conclure

  • Docker Swarm c'est cool ;
  • Ansible c'est bien aussi ;
  • OpenTofu c'est bien mais count = ☠
  • On s'en sort avec des outils encore meilleurs et une meilleure confiance dans notre infra !
  • ... Et on est dĂ©jĂ  plus Ă  jour donc faut tout refaire (mais ce coup-ci, on est prĂȘts).

Merci !