De Docker Swarm à Kubernetes avec k3s

Cet article a été publié il y a 3 ans 7 mois 30 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Après plusieurs mois d’attentes et de réflexion, je me suis enfin sorti les doigts du cul et j’ai changé le SSD du micro-serveur. Double espace pour monter de nouvelles VMs, pour lesquelles j’ai décidé non pas de rester sur Docker Swarm, mais de pleinement embrasser Kubernetes, via un projet très intéressant. Et comme souvent, voici le récit de ce voyage, parce qu’il fût semé d’embûches, de celles qu’on ne voit évidemment pas dans les tutos « hello world ».

Avertissement : ceci n’est pas un tuto complet, mais juste un gros retour d’expérience avec les réflexions qui vont avec.

Kubernetes… Le projet initié par Google et libéré depuis est sur toutes les lèvres des décideurs informatiques capturés tels des lapins par les phares des marketeux des agences Web qui pensent pouvoir se passer de qualité. Il est vrai que comparé à du Docker pur, et même à Swarm, il a une quantité d’avantages. Mais il a aussi ses inconvénients, et ça peut vite s’emballer.

Je suis toujours aussi critique sur la conteneurisation des applications, et surtout de son usage souvent mauvais, à l’image d’un php accessible qui permet trop facilement de faire de la merde. Mais pour le manipuler depuis plus d’un an et demi, force est de reconnaître que K8s (le nom abrégé de Kubernetes) me plaît beaucoup, bien que je lui trouve aussi des défauts. C’est selon moi, à date évidemment, la meilleure implémentation d’orchestration de conteneurs que l’on puisse trouver.

À l’image du cluster Swarm qui était surtout à la base un moyen d’entretenir mes compétences Docker, l’évolution du cluster est donc un moyen d’expérimenter et d’entretenir mes compétences sur et autour de Kubernetes.

Rancher, un acteur clé du monde de la conteneurisation

Rancher est une société qui développe beaucoup d’outils et de services centrés sur les containers. OS de supervision de cluster, orchestrateur docker, providers de stockage, et j’en passe. Leur expertise dans ce domaine n’est plus à faire, et beaucoup de leurs outils sont open source.

C’est un acteur de poids qui cherche en permanence de nouveaux moyens de mettre ces technos à la portée du plus grand nombre, des gros serveurs de data centers, aux petits auto hébergés comme moi qui voudraient aussi en profiter. Et dans cette catégorie, tous n’ont pas un serveur comme le mien, qui n’est déjà pas bien puissant, mais encore plus petit. D’ailleurs on verra que finalement j’utilise plusieurs projets liés venant de Rancher.

Je vous recommande de vous intéresser à leurs produits, certains sont intéressants, comme l’utilitaire qui permet de faire de la centralisation de la gestion de clusters, et ce quelque soit leur origine (maison, « cloud-provided », etc), parce que parfois, la ligne de commande c’est chiant même quand on adore 🙂 (Ils ont aussi un catalogue de formations et de certifications qui peut vous intéresser)

k3s, la réponse pour nano-pc

Un des reproches qu’on fait souvent à k8s est sa lourdeur, à savoir que les composants permettant de faire le boulot consomment beaucoup de ressources eux-mêmes. Chez Microsoft ils nous indiquaient un chiffre, certes un peu au doigt mouillé, d’une dizaine de pourcents pour les nœuds worker. Et les masters doivent aussi être si possible des brutes, surtout en mémoire vive (merci etcd). De manière général, on recommande que chaque machine du cluster dispose d’au moins 4 coeurs et de 8Go de RAM. C’est juste la capacité globale de mon micro-serveur actuellement, c’est un peu compliqué.

Et Rancher avait une cible : le Raspberry PI, un nano-pc disponibles aux alentours d’une trentaine euros, sur architecture ARM, d’abord conçu pour le monde de l’éducation, mais qui a bien dépassé ce cadre (on en doute même du succès auprès de cette cible primaire, tant les bidouilleurs se sont jetés dessus). Avec environ 1Go de RAM pour les PI 3, il est évident qu’il n’est pas possible en l’état de faire tourner la bête. Ils ont donc bossé, cherché comment réduire au maximum, parfois en allant jusqu’à remplacer des composants du control plane par d’autres plus légers.

k3s est né. Avec k3s vous pouvez monter un cluster Kubernetes à base de machines aussi peu puissantes que des Raspberry PI (3 et suivants), ce qui tombe bien puisque je déploie en général des machines virtuelles aux caractéristiques proches sur mon serveur. Je ne suis ni le premier ni le dernier à en parler, mais je vais m’inspirer du travail déjà produit, ne serait que pour valider que c’est réutilisable dans d’autres situations. Et surtout, j’ai des outils déjà déployés qu’il faut que je transfère, car je n’ai pas non plus envie de me paver les deux clusters en maintenance.

Spoiler, c’est pas des Pi 4 😛

Et comme indiqué au début, j’ai pas prévu de me faire mal avec des raspberry PI, j’ai juste un micro-serveur dont j’ai déjà parlé dans le passé.

Monter un cluster en mode « Infra as Code »

Parce que ça fait aussi partie des mes activités au boulot désormais, j’avais envie de déployer tout le cluster en mode Infrastructure-as-Code. Rien de révolutionnaire, j’ai visé l’utilisation de Terraform pour déployer mes machines, et d’Ansible pour faire leur configuration de base.

Je pensais faire la transition en douceur entre Docker Swarm et Kubernetes, mais quelques mésaventures avec le LVM de Proxmox VE m’ont poussé à carrément réinstaller celui-ci dans sa dernière version et donc refaire les machines de zéro. Ce fut également l’occasion de tout refaire à base de Debian 10 (dont j’aurais sûrement l’occasion de faire quelques remarques plus tard). Comme je suis toujours en télétravail prolongé chez ma mère, ça s’est fait lors d’un aller-retour rapide chez moi, car j’ai dû aller au boulot chercher ma Yubikey. J’ai juste pris le temps de réinstaller Proxmox VE sur un SSD flambant neuf deux fois plus gros que celui d’origine, et réinstaller le bastion à la main pour pouvoir faire tout le boulot à distance par la suite, j’avais déjà à disposition mes rôles de bases d’Ansible c’est donc allé très vite.

Déployer des machines avec Terraform suppose d’avoir à disposition un template de machine à déployer. Au final j’ai suivi la plupart des instructions partagées par Anthony (et sur lequel j’ai apporté une précision après avoir rencontré des soucis), après tout pourquoi réinventer la roue quand la solution existe déjà ? L’article propose l’installation bout-en-bout d’un kube complet via kubeadm, je me suis juste inspiré de la partie Terraform car je compte bien rester sur du k3s. Je suis parti sur une base d’un master/deux workers, et j’ai cette fois déployé des machines à 2vCPU et 2 Go de RAM. La seule contrariété finalement que j’ai rencontré c’est que j’étais à distance, et que l’interface de Proxmox VE n’est pas joignable de l’extérieur. Je suis donc passé par un transfert de port via SSH pour exposer en local le port 8006, et c’est localhost qui était désigné comme adresse dans la configuration du provider pour taper sur l’API de Proxmox. Et pour l’anecdote, l’instance Consul qui me sert à stocker mes tfstate était déployée sur Docker Swarm, du coup dans l’immédiat le tfstate reste en local sur mon poste.

Pour la partie configuration de base, comme je disais, j’ai déjà mes rôles Ansible, que j’ai remis à jour pour prendre en compte les changements effectués dans Debian 10. Certains paquets ont changé de nom ou ont disparu, d’autres n’étaient pas inclus de base dans l’image utilisée pour le template, et j’ai également eu à faire une ou deux modifications mineures dans l’environnement bash (via powerline.bash), en vue justement de pouvoir utiliser k3s par la suite.

Pour l’installation de k3s et la création du cluster lui-même, ça a été un peu plus compliqué. J’avais ressorti un article d’itwars et surtout le dépôt Github gardé après avoir lu l’article de Zwindler sur une telle opération sur des machines Scaleway. Cette première version n’avait que peu bougé, et surtout, j’ai perdu du temps en recopiant tout plutôt qu’en clonant, parce qu’au passage j’effectuais en direct mes propres changements dans les tâches, et ça avait abouti à un truc qui ne fonctionnait pas, en tout cas pas complètement. Avant de me rendre compte que le contenu du dépôt a été repris et amélioré de manière communautaire directement par Rancher. Avec toute la maintenance qui va avec, et bizarrement, après avoir fait les deux/trois modifications qui s’imposaient (entre autres désactivation de l’installation de Traefik pour faire la mienne, et la personnalisation du réseau, personnalisation de l’inventaire comme le préconise la doc), ça a fini par tomber en marche. Mais comptez deux après-midi de perte de temps quand même, si c’est pas un boulot de champion ça…

Comme je prévois d’utiliser quelques softs sans forcément pousser la configuration de ouf, j’ai cherché à installer Helm, que je viens d’évoquer, en tentant quelques tâches Ansible. Après plusieurs échecs minables parce que je ne suis parfois pas doué (ou pas concentré), j’ai finalement retrouvé la mémoire, à savoir qu’il existe une base de données plutôt fournie de rôles communautaires qui s’appelle Ansible Galaxy. J’ai donc fouillé dedans et il n’a pas fallu une minute pour que Helm soit installé. On ne regarde pas assez souvent ce que les gens ont contribué sur Galaxy, c’est une vraie mine d’or.

Convertir mes services, en mode feignant ?

À l’image de Gogs, qui était passé de « bare metal » à Docker Swarm, j’ai ensuite dû me pencher sur la conversion du fichier docker stack/compose en manifestes Kubernetes. On va le voir, de la même façon qu’on déclare un réseau, des services, et des volumes, il faut aussi déclarer plusieurs types d’objets pour faire le boulot, l’architecture globale n’ayant cette-fois-ci pas trop besoin de changer puisqu’on est déjà dans un contexte container.

Par contre, même les plus aguerris vous le dirons, la syntaxe des manifestes k8s, écrit le plus souvent en yaml, est pour le moins verbeuse. À tel point que si on définit une stack Swarm dans un fichier unique généralement, les bonnes pratiques consistent à créer un fichier par objet ou type d’objet pour Kubernetes. Oui, on en est là.

De cette complexité est né l’outil Kompose, un véritable must have selon moi qui permet de créer des manifestes K8s à partir de fichiers docker-compose. Ils sont rarement exploitables en l’état mais permettent de mâcher le boulot pour avoir la structure qui va bien, un peu à l’image d’ansible-galaxy qui peut vous générer la structure d’un module Ansible pour vous, dans l’optique d’une publication.

La question sensible des volumes persistants…

Toujours cette satanée persistance dont personne ne veut prendre en charge les problèmatiques. C’est faux en partie, Kubernetes embarque nativement pas mal de plugins pour des technos de stockage diverses et variées, notamment celles des fournisseurs de cloud qui proposent des services Kubernetes hébergés et gérés prêts à l’emploi, ces plugins permettant alors, depuis Kubernetes, de « commander » automatiquement des volumes de différents types.

K3s étant simplifié, par défaut tous ces plugins sautent et seul le hostpath et l’emptydir persistent. C’est embêtant parce que j’utilise déjà du NFS et il est possible de déclarer les PV NFS sans problème, mais pas les PVC (et on parle de plusieurs heures à essayer). Comme je l’indiquais dans le billet dédié à ce sujet maintenant les volumes NFS sont déclaré explicitement dans mes stacks, et non plus via un montage global sur chaque nœud. J’ai de toute façon prévu de m’en débarrasser, rappelez-vous, quand tout redémarre le temps de démarrage du NAS faisait que mes services tentaient de démarrer sans leur volume, avec un résultat parfois intéressant, mais il faut bien que je transfère les données. Une des solutions de contournement, serait d’utiliser le nfs-client-provisioner, pluggé sur mon partage global, qui crée des dossiers dynamiquement, dans lesquels je synchroniserai éventuellement les data le temps de faire cette migration. Mais au final, si le nfs-client-provisioner est là, il n’est que très peu utilisé.

Pour disposer de volumes persistants au sein même du cluster, j’ai décidé d’utiliser un autre projet de Rancher, Longhorn. J’ai eu par contre la désagréable surprise de voir sa lourdeur pour mon cluster, donc tant pis, on verra à l’usage. Un autre élément à prendre en compte, c’est que les volumes Longhorn ne supporte que le mode d’écriture RWO, pour Read-Write-Once, ce qui veut dire pas de replicas d’un même pod, et surtout pas de rolling update. Aussi, même en déclarant un volume aussi petit que 32Mi via PVC, il a créé un PV d’1Go, et le PVC mentionne aussi 1Go. Fort heureusement ce sont des volumes « dynamiques », à savoir qu’ils consomment réellement uniquement ce qu’on y met, mais si on vide manuellement un volume, le fichier correspondant sous-jacent sur l’OS n’est pas redimensionné, à l’image d’une image disque de machine virtuelle (ce qu’on avait pu voir à l’époque sur le format qcow2).

Pour contourner la limitation du RWO, il existe un provisioner « longhorn-nfs » disponible dans la dernière version qui va créer un volume unique d’une certaine taille (20Go par défaut), et l’exposer en NFS via une StorageClass, ce qui permet du coup de bénéficier des rolling updates. J’arrive toujours pas à me décider si je vais tout utiliser de cette manière, on verra à l’usage.

… et le réapprentissage de l’Ingress controller

Comme je l’ai évoqué un peu plus tôt, même si k3s est fourni avec Traefik, la version embarquée me plait moyennement car la 2.2 apporte beaucoup de fonctions sympatiques. Pour l’installation de cette version, là encore rien de transcendant, je me suis basé sur le travail de configuration « simple » mis à disposition par Djerfy, en l’adaptant légèrement pour mes besoins. J’avais commencé par Helm, mais j’avais un petit risque de passer à côté de la souplesse de personnaliser complètement l’outil. Je peux maintenant exposer les ports via la box, et faire tout le boulot qu’on demande d’un reverse-proxy. Et voilà, j’ai la base pour redéployer mes services désormais.

Traefik a l’air très intéressant, mais son implémentation dans Kubernetes amène pas mal de concepts que je dois réapprendre, par rapport à un Ingress Controller plus classique (Nginx étant le plus répandu, et j’ai pratiqué haproxy lors d’un projet client). Et sinon, là où ça restera compliqué pour la conversion, c’est que je crois que Kompose ne crée pas les fichiers d’Ingress, je n’ai donc aucune base de travail. Pas étonnant, aucun label particulier pour l’aider, son travail à partir du docker-compose se limite donc à l’exposition du service.  L’avantage c’est que tout est documenté, mais ça n’empêche pas que je doives apprendre toute la syntaxe de configuration, adapter les « tricks » que j’avais pu faire sur mon reverse-proxy Nginx, et surtout, trouver un moyen de coupler les IngressRoute propres à Kubernetes à des bouts de configuration plus statiques pour les quelques services qui ne seront pas dans le cluster, l’interface du NAS en premier lieu.

En tout cas pas mécontent d’avoir dans mes contacts proches un Djerfy qui est Traefik Ambassador pour m’épauler (bien qu’il soit parfois lui-même en train de déterrer des trucs), ça aide bien pendant cette mini-traversée du désert 🙂

La mise en pratique de la migration de service

Pour l’article je vais prendre l’exemple simple de Smokeping. Un container, deux volumes, un port, on peut difficilement faire plus accessible. Voici d’ailleurs la stack actuelle :

Passons maintenant à Kompose, pas besoin de détailler son installation, il suffit de suivre la doc (rtfm quoi). Pour son utilisation, il suffit de le lancer en lui indiquant le fichier compose et paf, ça fait des chocapic, ou presque. On constate qu’il a créé plusieurs fichiers yaml, dont on va détailler les éléments :

On a donc deux persistent volume claims, un deployment, un networkpolicy et un service. Il manque encore l’IngressRoute et un ou deux éléments annexes dont on va parler juste après.

Voyons un peu à quoi ressemblent ces fichiers, celui du deployment étant assez intéressant :

Je l’avais dit que c’était particulièrement verbeux ? C’est un des reproches que je fais à la techno. Pareil pour les volumes, dans Swarm, vous déclarez un volume, vous l’utilisez, point barre. Ici il faut déclarer un volume (PersistentVolume), déclarer qu’on va l’utiliser (PersistentVolumeClaim), et ensuite l’attacher dans le Deployment en le déclarant. Et tout ça avec 10 fois plus de lignes. Et encore, grâce à Longhorn, on « simplifie » parce qu’il n’y a besoin que du VolumeClaim, le PV étant provisionné de manière dynamique derrière. Vient ensuite le service, sans lequel le port de l’application n’est pas réellement exposé, et même là, ça reste de la communication « interne », à moins de faire un service de type nodePort, qui réplique finalement le comportement de docker Swarm.

Car oui, en temps normal dans un cluster K8s, c’est l’Ingress Controller qui est chargé de faire le lien entre l’extérieur et les services. Et donc Kompose ne s’occupe absolument pas de cet aspect, il faut que je bosse le sujet. Pour Smokeping, je suis le seul à y accéder, on a donc une IngressRoute classique avec juste un auth basic http. Un modèle qui sera réutilisé pour la plupart des services je pense, comme c’était le cas sur mon Nginx. Ce setup a une particularité : il a besoin d’un secret, pour stocker le couple utilisateur:motdepassehashé, d’un Middleware qui est une ressource Custom créée par le déploiement de Traefik pour déclarer cette authentification, et dans l’IngressRoute lui-même, l’appel à ce Middleware. Certes je pourrais regrouper ces éléments dans le même fichier, mais pour l’exercice, ça fait donc trois fichiers de plus :

Dans l’immédiat je n’ai pas appliqué la NetworkPolicy, parce que je dois l’adapter à mon installation d’abord, mais ça fait partie des bonnes pratiques que je recommande vivement d’appliquer en production pour isoler vos applications entre elles. J’ai d’autres priorités dans l’immédiat, et je radote je sais, mais c’est le stockage.

Revenons vite fait à l’Ingress pour mentioner un dernier morceau : pour la génération du mot de passe dans le secret, je recommande d’utiliser openssl qui a l’avantage, sous Linux, d’être déjà fourni par la plupart des distributions :

Au passage vous pouvez aussi utiliser htpasswd du paquet httpd-tools/apache2-tools.

La migration du stockage des applications a été une autre aventure. J’évoquais la possible utilisation du nfs-client-provisioner, mais faire un premier déploiement avec un tel volume, procéder au rsync depuis le NAS sur le dossier créé, puis depuis le pod refaire un rsync sur le volume final, c’était beaucoup trop lourd. J’ai finalement trouvé quelque chose de pas super souple, mais beaucoup plus simple. On commence par créer le namespace et les pvc, et on crée un micro-déploiement qui monte ces deux volumes. Je me suis basé sur nginx parce que c’est léger, rapide, avec un compte root pour éviter les problèmes de permissions pendant les manipulations. Ensuite sur le master, j’ai également monté le partage Docker du NAS en NFS de manière dynamique, parce que ça n’a pas vocation à persister, et j’ai donc copié les données des volumes via « kubectl cp », sachant que derrière, il peut y avoir encore quelques manipulations à l’intérieur du pod nginx parce que les chemins sont souvent mal interprétés (ou alors je suis mauvais, je me suis fait une raison avec le temps). Une fois terminé, je supprime le déploiement temporaire pour lancer le vrai déploiement. Pour l’instant, je n’ai pas rencontré de difficulté. Ça restera la partie la plus pénible des autres migrations.

L’accès au cluster de l’extérieur, pas trivial

En effet, pour accéder à l’admin du cluster via kubectl, ça se fait via https sur le port 6443 du master. Je n’ai pas l’intention de l’exposer à l’extérieur dans l’immédiat, mais pour déployer des services dessus à distance ou procéder aux interventions de manière générale, il va falloir une solution. Exposer le control plane n’est jamais une bonne idée, après quelques tergiversations je vais faire ça avec une connexion SSH qui redirige le port 6443 du master vers le port 6443 local, et en plus je fais ça via le fichier ~/.ssh/config plutôt que via la ligne de commande, ce qui me permet de gagner du temps :

Me reste à utiliser une copie du fichier kubeconfig en remplaçant l’ip du master par 127.0.0.1. On retrouve donc la même méthode que pour le déploiement via terraform vu plus haut, avec un poil de « sucre » en plus en vue d’une utilisation plus régulière.

Enfin pour la partie Ingress Controller, j’ai déjà indiqué comment je comptais procéder, j’expose les ports 80 et 443 du master via le NAT de la box. Le tout malheureusement en full IPv4 car toujours pas de vrai pare-feu ipv6 sur la Freebox (et ça sera bientôt aussi le cas sur Livebox, la fibre étant au programme pour septembre, Free n’étant pas encore à jour dans l’Oise malgré une promesse de disponibilité fin 2019).

Les différences avec le cluster swarm, la suite

La principale différence vient du fait que je n’ai qu’une seule machine qui joue le rôle de master/control plane, quand toutes les VMs du swarm étaient manager. Vu que tout est sur la même machine physique, j’ai envie de dire que ce n’est pas trop grave. Exit également portainer pour l’instant, même s’il supporte k8s désormais, et qui avait déjà sauté à l’occasion d’une petite corruption de configuration suite à une mauvaise manipulation lors d’une mise à jour. Je n’ai pas encore pour l’instant envisagé de réinstaller une forme de dashboard « global », en dehors de celui de Traefik et de Longhorn, je verrai dans le futur si j’en ressens le besoin.

Même si à l’époque j’aurais pu exposer le port d’admin de Docker Swarm pour me connecter de l’extérieur, la configuration est beaucoup plus rudimentaire, et sur ce point Kubernetes est bien plus facilitant. Attention, ce n’est pas nécessairement recommandé, d’ailleurs la conf par défaut de k3s crée un simple token et j’avoue que je tenterai bien d’ajouter une authentification via certificat client, ce qui est bien plus sécurisant.

J’ai pu constater la réactivité de k8s par rapport à des actions de mises à jour ou de relancement d’application, de mon point de vue c’est plus rapide sur kube quand on tue un pod pour qu’il réapparaisse, et surtout, j’ai désormais la possibilité de faire du rolling update (via longhorn-nfs), limitant très fortement les indisponibilités en cas de mise à jour. Un élément plutôt impactant à prendre en compte tiens d’ailleurs, qui a couru dès le début de l’installation du cluster : sans la fibre, pas mal de manipulations prennent du temps, le téléchargement de chaque binaire par exemple (via Ansible, k3s était téléchargé sur trois serveurs en même temps, idem pour Helm), ou chaque image docker de plusieurs centaines de Mo est pénalisant.

Les chantiers pour la suite

Tellement, déjà, en l’état j’ai redéployé un peu comme un gougnafier, et il manque des éléments qui seront importants surtout vu la capacité du cluster actuellement, à savoir les requests et limits pour éviter tout débordement d’une application. Voici l’état de la consommation avec Traefik, Longhorn, le nfs-client-provisioner, smokeping et gitea :

L’idée va être de laisser tourner un peu sans ces limites, voir le comportement (via ctop ou kube-capacity par exemple), et appliquer les limites raisonnables en conséquence. Dans le même état d’esprit, des liveness/readiness ne seront pas de trop pour redémarrer automatiquement les services, pour l’instant c’est le désert.

J’ai déjà évoqué l’utilisation de Longhorn, reléguant le NFS aux seules sauvegardes. Justement je n’ai absolument pas parlé de sauvegardes, ça sera peut-être l’occasion de bosser sur Velero, histoire de sauvegarder le contenu des volumes car sauvegarder les VMs ne suffira peut-être pas à assurer le boulot. Il ne sera d’ailleurs pas nécessairement utile de sauvegarder toutes les machines, au moins le master, les nodes pouvant être réinstallés/ajoutés à l’envi via terraform/ansible.

À l’image du backup, il manque le déploiement d’une forme de monitoring. C’est d’autant plus nécessaire qu’on est justement dans un mode contraint de ressources, et comme je compte bien réinstaller Prometheus, pas dans le cluster lui-même mais sur un Raspberry Pi qui fera le travail dédié (avec celui de bastion certainement pour laisser toutes les ressources du serveur au cluster). Possible encore que je me base sur le travail de Stéphane Robert qui a eu l’amabilité de tout partager.

Enfin, il sera l’occasion de commencer à bosser sur de l’intégration continue, dans la continuation de ma migration vers gitea, ce sera donc drone qui sera potentiellement amené dans le futur à déployer les mises à jour de mes services kube sur le cluster.

En dehors du stockage, on parle donc d’automatiser les choses un maximum, en bon feignant qui se respecte, mais le feignant va quand même devoir pas mal se retrousser les manches pour arriver au résultat voulu 🙂

Par contre, cela va devoir se faire dans une enveloppe de ressources plutôt compliquée à gérer, car en l’état, voilà l’état du cluster :

On le voit, c’est serré, même sur le NAS qui participe au calcul du stockage. Il est temps que je rentre chez moi pour m’occuper de tout ça 🙂

PS : On a pu le voir ici, je n’ai pas eu à réinventer la roue, j’ai pu grandement bénéficier du travail déjà effectué et surtout partagé par d’autres, et je tiens encore à tous les remercier. Je n’ai pas eu l’occasion de beaucoup améliorer ou compléter leur travail, à part mes mésaventures avec Terraform sur le déploiement des VMs après la création du template que j’ai remonté, et des échanges en direct avec Djerfy par rapport aux bricoles autour de Traefik. Cet article est donc aussi un témoignage de mon amour pour leur travail. Un jour peut-être je pourrais moi-même en faire plus.