Je me suis récemment donné comme projet de devenir un CHATONS (le Collectif des Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires). L’idée est de proposer des services web éthiques, locaux et à tailles humaine.

  • Locaux : je proposerai mes services à mes proches, mes voisins de quartier, à toute personne qui souhaite reprendre le contrôle sur ses données personelles. Les serveurs seront hébergés à mon domicile sur ma connection ADSL. Seules les sauvegardes seront externalisées.
  • A taille humaine : Je ne compte pas héberger des milliers d’utilisateurs, étant seul sur le projet difficile de gérer beaucoup de monde. Néanmoins, je souhaite créer une petite communauté d’irréductibles geek qui résistent encore et toujours à l’envahisseur et qui se réunissent souvent autour d’un grand banquet.

Comme je l’expliquais plus haut je suis seul pour maintenir ces services, je dois concevoir une infrastructure sécurisée**, **performante**, **scalable**, **automatisée et facile à maintenir. Ce billet est le point de départ de nombreux autres qui me premettrons de partager mes aventures sur la réalisation de cette nouvelle infrastructure.

1. Conteneurisation et Orchestration

La conteneurisation est une méthode qui permet de virtualiser, dans un conteneur, les ressources matérielles ‒ systèmes de fichiers, réseau, processeur, mémoire vive, etc. ‒ nécessaires à l’exécution d’une application. Cette technologie offre plusieurs avatanges, la légèreté, la performance, l’efficacité à la maintenance.

Le déploiement et l’organisation des conteneurs pour prendre en charge les applications s’appelle l'orchestration. Elle s’effectue via un outil d’orchestration de conteneur. Il existe plusieurs outils d’orchestration mais mon choix s’est porté sur Docker Swarm. Swarm est un mode natif de Docker depuis la version 1.13. Il permet d’utiliser un groupe de machines exécutant Docker comme un seul Docker Engine. On parlera de grappe ou de cluster. Les commandes sont exécutées sur le cluster à l’aide d’un swarm manager. Les machines (physiques ou virtuelles) sont désignées comme des nœuds (nodes).

  • Les machines swarm managers :

    • sont les seules du cluster à pouvoir exécuter les commandes ;
    • autorisent d’autres machines à se joindre au cluster.
  • Les machines swarm workers :

    • sont utiles uniquement pour augmenter la capacité du cluster.

Source : https://docs.docker.com/engine/swarm/

Le choix de cette solution me permet de déployer très rapidement, en fonction de la demande les applications. Elles s’installent avec toutes les dépendances et sont indépendantes de l’hôte. De plus la configuration de chaque services est contenue dans un seul fichier, écrit en YAML qui se déploie avec une seule ligne de commande. Pratique lors d’un renouvellement ou ajout d’un serveur dans l’insfrastructure ou d’une migration.

Mon choix s’est porté sur Swarm, car il s’intègre parfaitemenent à Docker et Docker Compose, ce qui simplifie grandement la configuration et la portabilité du cluster. Swarm est en permanence mis en opposition avec Kubernetes (K8s pour les intimes). Malgrè beaucoup de fonctionnalités intéressantes, K8s reste très difficile à installer, à configurer, et à maintenir, à tel point qu’aujourd’hui beaucoup d’entreprises utilisant K8s préfèrent payer une version managée. De plus K8s fut crée par Google pour ses besoins internes, sauf que les besoins de Google ne sont pas les miens, et malgrè un nombre important de conteneurs, mon infrastrusture n’a pas besoin de toutes les fonctionnalités de configurations avancées qu’offre K8s.

2. L’infrastructure

Encore à l’état expérimental, mon laboratoire est actuellement composé d’un manager et d’un worker. Idéalement il me faudrait un worker de plus mais je préfère garder le budget pour investir dans le matériel final. La version de production sera basée sur ce genre de carte ARM, couplée avec un nas pour la gestion des volumes persistents. Le tout sera sauvegardé sur un serveur dédié loué chez Oneprovider en France. Voici le premier schémas que j’ai réalisé lors de mes premières reflexions.

image

Le choix du sysème d’exploitation est purement subjectif puisque les conteneurs sont indépendants de l’hôte et que Docker s’installe sur presque tout les systèmes. Souhaitant offrir des services web éthiques, hors question pour moi de travailler avec des systèmes privateurs et non libres, c’est tout naturellement que j’ai choisi Debian Stable.

Préparation du cluster

Sur chaque noeud du cluster

  1. Editer le fichier /etc/hosts avec les Ip de chaque noeud.
192.168.0.1 noeud1
192.168.0.3 manager
...
  1. Pour plus de praticité je copie ma clef publique sshsur tous les noeuds et je créer le fichier ~/.ssh/config.
Host noeud1
Hostname noeud1
User draconis
Host manager
Hostname manager
User draconis

Ainsi pour me connecter en ssh sur un noeud je n’ai qu’à taper.

ssh noeud1
  1. Installation de docker
# installation des dépendances
sudo apt install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

# importation de la clef gpg du dépôt docker
 curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# ajout du dépôt docker
echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# installation de docker
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io

# j'ajoute mon tulisateur au groupe docker, ce qui me permettra d'utiliser docker directement avec cet tulisateur
sudo usermod -aG docker draconis
  1. Persistence des données

Avec Docker Swarm, les containers sont volatiles et ne restent pas toujours reliés à un serveur unique. Il faut donc utiliser un volume tier pour que chaque conteneurs puisse accéder aux données qui le concerne. J’ai fait le choix d’héberger les volumes persistants sur mon nas afin de ne pas éparpiller les données et simplificier les sauvegardes. Cela necéssite l’installation de nfs et du plugin docker-volume-netshare.

# NFS
sudo apt install nfs-common

# docker-volume-netshare 
wget https://github.com/ContainX/docker-volume-netshare/releases/download/v0.36/docker-volume-netshare_0.36_amd64.deb
sudo dpkg -i docker-volume-netshare_0.36_amd64.deb
sudo systemctl enable docker-volume-netshare
sudo systemctl start docker-volume-netshare

Déploiement du cluster

  1. sur le manager.
docker swarm init
docker swarm join --token SWMTKN-1-0hzewfzefsgerglqk2d45xtrn8iqgb6htvb09tgfnso80jdf7v6u8anc-0n3etnna4h85s7rqpcqakq 192.168.0.3:2377
  1. Je récupère la commande entière que je déploie sur les workers et depuis le manager je vérifie que tous les noeuds sont dans le cluster.
docker node ls
ID                         HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS  ENGINE VERSION
j3r3gjickgo8rcda5q09pbz8   ecto1     Ready   Active                               20.10.5
f3lk2z0wn96ku7o6a83jwp65 * oribos    Ready   Active        Leader                 20.10.5

Gérer le cluster

Maintenant que le cluster est fonctionnel, je peux l’administrer via ces quelques commandes :

  • pour voir toutes les applications et où elles ont été déployées : docker stack ps <stack name>
  • pour voir les applications installées sur un noeud spécifique : docker node ps <node name>
  • visualiser les logs d’une application : docker service logs <stack name>_<service name>
  • supprimer complètement toute la stack : docker stack rm <stack name>

Lorsque je souhaite déployer une stack d’application j’upload le fichier <nom_application>.yml et j’exécute la commande docker stack deploy -c <nom_application.yml> <nom_de_la_stack>.

Dans mes prochains billets j’aurai l’occasion de revenir sur le déploiemet et la sauvegarde des conteneurs du cluster.

Conclusion

Au final, déployer un cluster Swarm, c’est simple et rapide. Bien entendu j’en suis encore au stade expérimental mais cela me donne bon espoir pour le reste de l’aventure. Dans mon prochain billet il s’agira de rendre tout ce petit monde accessible depuis internet, on parlera reverse-proxy, certificat et de Traefik.