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.
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 fait beaucoup de CSS de 2008 à 2010, j'étais capable de coder un thème dotclear ou pluxml de A à Z avec un simple éditeur de texte. Mais les choses ont beaucoup changé aujourd'hui, HTML5 est arrivé ainsi que le responsive design et javascript qui prennent une place de plus en plus importante. Donc je suis non seulement rouillé mais en plus totalement à la ramasse par rapport au code moderne.
C'est la raison pour laquelle je me suis contenté de légèrement modifier le thème de base Pluxml au lieu d'en refaire un entier. Rien de bien fracassant puisque je me suis contenté d'ajouter un fichier "local.css" invoqué dans le header afin de modifier certains éléments notamment les couleurs et les polices.
En cherchant comment gérer une image + sa légende dans un article j'ai découvert <figure>. Cette propriété HTML5 évite de devoir créer inutilement des <div> et se révèle plus élégante :
Lisible non ? Plus d'infos chez alsacréations. ou w3schools. Je ne détaille pas la partie CSS car ce serait un peu lourd, mais si ça vous intéresse vous pouvez jeter un œil dans le local.css. En attendant voici le résultat :
Orage à Nantes (août 2015)
Image extraite d'une vidéo prise avec un Lumia 735 il y a quelques temps. La tour que l'on voit entre les grues à gauche et l'éclair est bien sûr la Tour Bretagne.
Qui suis-je ? Certainement un fou pour lancer un blog en 2016, à l'heure où tout le monde ne jure que par les réseaux sociaux à travers le web.
Oui les blogs disparaissent mais ils restent un excellent moyen de publication non formaté adapté à des écrits subjectifs. Et c'est précisément ce point qui m'intéresse car il m'arrive souvent d'avoir des choses à dire ou à partager et les quelques rares réseaux sociaux que je fréquente ne me conviennent pas.
Gérer l'hébergement est une chose amusante pour moi. Le blog est propulsé par Ubuntu (Debian Jessie) + Pluxml + Nginx et hébergé sur un VPS chez Leaseweb. L'accès est possible en HTTP ou en HTTPS signé par Let's Encrypt que je trouve vraiment très intéressant et dont je ne manquerai pas de parler.
EDIT : Désormais c'est Scaleway.
Vous ne trouverez pas de publicité ni d'articles sponsorisés car ce blog n'a pas vocation à rapporter de l'argent.
N'hésitez pas à vous abonner au flux RSS (oui ça aussi c'est obsolète mais tellement pratique) pour suivre mes aventures.
