Kubernetes est probablement la technologie la plus complexe sur laquelle j'ai pu travailler cette année, à tel point que j'ai longtemps été réticent à m'y frotter. J'ai tout de même choisi de me faire violence et de persévérer car ce domaine est très valorisant et très valorisé. Utiliser un outil dans le cadre d'un réel besoin est le meilleur moyen pour apprendre, c'est pourquoi j'ai décidé de migrer mon blog et d'autres sites. Voici une vue d'ensemble du fonctionnement du blog dans Kubernetes, en sachant que le pod est composé d'un container OpenSMTPD (pour le formulaire de contact) et bien entendu d'un container Pluxml :
Note : Fait avec Diagrams (schema as code). L'Ingress Controller est Traefik (j'en parle plus bas).
Le changement n'a pas été instantané, loin de là, à vrai dire j'avais ce projet de côté depuis plus de 1 an. Mon idée de départ était de créer un cluster a plusieurs nœuds mais cela ajoute une contrainte au niveau du stockage, en effet il faut des volumes accessibles en réseau. La question des coût s'est posée également car mon blog n'est pas suffisamment important pour justifier 4 serveurs (3 noeuds + 1 NAS). J'ai donc fait des concessions et accepté d'utiliser un cluster Kubernetes à 1 nœud, avec la Storage Class par défaut de k3s (local-path). C'est donc un premier pas timide mais l'objectif est de me familiariser avec Kubernetes.
J'ai utilisé k3s, le Kubernetes Lightweight de Rancher. Cette distribution a l'avantage d'être facile à installer (une commande curl) et d'avoir une emprunte mémoire assez limitée (même si ça reste beaucoup plus élevé que Docker). Par contre elle n'est pas miraculeuse et le côté "lightweight" s'est fait en excluant ou limitant certaines features. Par exemple pour la gestion des Ingress on a droit à un Traefik built-in en version 1.7 (donc legacy) absolument pas documenté pour la gestion des certificats Let's Encrypt. J'ai donc désactivé cette version et installé le Traefik 2.x de containous grâce à Helm. Cette version de Traefik est implémentée en tant que CustomResourceDefinition (aka CRD) et est documentée sur le site officiel. J'avoue quand même avoir passé 3-4 jours à faire fonctionner ces satanés certificats Let's Encrypt mais j'y suis finalement parvenu et j'ai beaucoup appris.
Un autre point sur lequel k3s est limité est la liste de Storage Classes. Dans Kubernetes, une Storage Class, est en quelques sortes un driver qui peut provisionner à la volée des PersistentVolumes (PV). Dans mon cas je comptais utiliser AzureFiles pour provisionner des partages depuis un Storage account sur Azure mais il semble que k3s ne l'implémente pas. En lisant cette documentation je crois comprendre que k3s ne propose qu'une Storage Class locale, c'est à dire sur le nœud qui exécute le pod. Quand aux backends supportés, je ne trouve pas de liste même si j'ai pu valider que NFS fonctionne bien.
Migrer le blog dans Kubernetes m'a déjà permis d'apprendre beaucoup de choses. Rien de plus gratifiant que le sentiment "j'ai compris !!!" après avoir passé des heures à essayer en vain de faire fonctionner une ressource. J'espère me motiver un jour à ajouter d'autres nœuds dans mon cluster, quand j'aurai résolu le problème du stockage.
Juste un petit billet pour indiquer que le blog tourne à nouveau sous Docker. Cette fois-ci je n'utilise plus un unique container apache, mais 3 containers orchestrés par docker-compose :
1 container opensmtpd (pour le formulaire de contact) basé sur alpine:latest
Et il y a toujours un nginx "en dur" en frontal qui fait reverse proxy et centralise les logs.
Le serveur est désormais un Scaleway VC1S aux pays-bas sur lequel tourne une distribution Debian Stretch. Pour les containers j'ai choisi d'utiliser au maximum des images alpine en raison de leur légèreté et de la simplicité du système. Et pour le moment, ça marche plutôt bien.
J'ai essayé d'utiliser un serveur ARM Scaleway, mais outre le fait qu'il est compliqué d'installer Docker (il faut utiliser Ubuntu-server ou alors compiler) les images du Dockerhub ne semblent pas disponibles pour cette architecture. Je me suis donc rabattu sur un VC1S qui n'est rien d'autre qu'une machine virtuelle x86_64.
J'ai lancé ce blog le 17 Février 2016 et voici quelques statistiques après 1 année d'existence :
63 articles publiés (64 avec celui-ci).
463 commentaires publiés.
~500 visites uniques par jour (la majorité issue des lecteurs de flux RSS).
Vous voulez un discours ? D'accord, allons-y. Tout d'abord je ressens une certaine déception, non pas à cause du nombre de visites, mais à cause du manque de publication, d'inspiration et de volonté de ma part. Je pensais trouver un rythme d'écriture régulier mais c'est visiblement un échec.
Ce qui m'a incité à lancer ce blog, c'est la volonté de partager mon expérience de sysadmin, pousser des coups de gueule, réagir sur l'actualité, mais aujourd'hui tout ceci est un peu retombé. Écrire sur un blog ce n'est pas simple, il faut avoir des idées et les faire entrer dans la ligne éditoriale tout en sachant que la plupart des articles ne seront lus que 1 fois et obsolètes au bout de quelques semaines. C'est aussi très chronophage : un billet écrit à la va-vite demande au minimum 1 heure de boulot (écriture, relecture, corrections) et ça peut aller jusqu'à plusieurs jours pour un article plus poussé. Il m'arrive souvent d'avoir des idées mais de laisser tomber car je sais que je vais consacrer de nombreuses heures à l'écriture pour au final être déçu ou ne pas vouloir publier car le contenu est hors sujet.
Quant aux articles techniques, j'en publie peu car je n'ai rien de pertinent à dire. En fait si, j'ai souvent envie de parler de Docker, mais pour dire quoi ? Expliquer comment faire un hello-world ou spawner des containers Nginx vides à volonté ? Aucun intérêt, des tas de gens l'ont déjà fait. Ce qui est intéressant c'est l'aspect maintenance, volumes persistants, logs, upgrades, rollback, cluster, EC2, bref toutes les choses de la réalité véritable de la production dont je parlerai quand je serai certain que mes pratiques sont propres et optimales. Et quand je le ferai, ce sera peut-être sur un wiki que je trouve plus adapté car plus ordonné, versionné, daté, et non inondé par des articles éphémères.
Quel est l'avenir de Utux ? Je ne sais pas encore. Le Blog va vivre en 2017 car j'ai renouvelé le nom de domaine, en revanche je ne peux pas faire de promesse pour 2018.
J'ai énormément joué à Jedi Outcast et Jedi Academy, la nervosité du moteur de Quake III rend les combats au sabre très souples et dynamiques, un pur plaisir. Et puis il faut dire que la qualité de la narration est au rendez-vous, l'univers de Star Wars est parfaitement respecté, on retrouve les musiques des films et les histoires sont assez bien ficelées (Jedi Outcast est à mon sens un meilleur Épisode 7 que l'Épisode 7 lui même !). Et puis il y a le mode multi-joueurs de Jedi Academy, encore fréquenté aujourd'hui et qui continue à faire vivre le jeu 13 ans après sa sortie.
En 2013 le code source de Jedi Academy et Jedi Outcast a été libéré, ouvrant la porte à OpenJK, un fork qui permet de jouer au jeu sous Linux, OSX, mais aussi Windows, à condition de posséder les fichiers du jeu original (un peu comme Doom et ses WADs).
Les instructions sont dans le README, le principe est de récupérer le dernier build correspondant à votre système (linux-64 par exemple) puis le décompresser dans le répertoire GameData/ du jeu original (que vous devez posséder). Pour Ubuntu vous devez ensuite installer le paquet libsdl2-2.0-0 afin de pouvoir lancer le jeu (openjk_sp.x86_64).
Jedi Academy jeu en fenêtré
Et ça fonctionne plutôt bien, même s'il faut vous attendre à des bandes noires sur le côté car le jeu ne supporte pas le 16:9, ainsi que quelques bugs ou crashes occasionnels. Le jeu étant peu gourmand, il s'adapte bien à du gaming Linux même sur du Intel HD Graphics.
J'ai fait du tri et mis hors ligne des articles que je juge peu flatteurs, peu pertinents ou obsolètes. Ce sont principalement ceux écrits sur un coup de tête ou relatifs à l'actualité. J'ai la chance d'être le dictateur de ce blog donc j'en profite pour réécrire l'histoire.
Le blog ne tourne plus Docker car j'aimerai refaire les images et containers de manière plus propre en me basant sur l'expérience que j'ai acquis dans cette techno. Docker est pratique et bien pensé, le problème est qu'il est peut-être trop accessible donc on trouve de tout et n'importe quoi et souvent des mauvaises pratiques ou des usages détournés.
J'ai réinstallé mon serveur car il a subit de nombreux bidouillages notamment pour Docker et je voulais repartir sur une base propre. J'en ai profité pour faire sa configuration avec Ansible, avec un playbook pour les bases (timezone, locales, reseau, hostname, paquets), un autre pour installer la stack web (nginx, php-fpm, letsencrypt, ufw) et enfin un pour déployer mes sites web (avec génération du certificat let's encrypt au passage). Je peux donc le gérer sans devoir y mettre les pieds en SSH, j'en reparlerai peut être plus tard :)
