Sam Candy

Le cluster Kubernetes gratuit, c'est fini !

2025-04-25T00:00:00+00:00

Pour rappel, le cluster Kubernetes dont je parle tourne chez Oracle Cloud Infrastructure et ne me coûte strictement rien.

Un petit retour sur les mises à jour de Kubernetes

Du peu que je l'ai utilisé, Oracle Cloud Infrastructure (que je vais abbréger OCI) est plutôt aligné avec les autres gros fournisseurs cloud américains. En terme d'utilisation en tout cas.

Mais le cluster Kubernetes était compliqué à mettre à jour : il faut mettre à jour le cluster, puis les groupes de nœuds. Ça aurait pu être facile si le groupe de nœud se mettait vraiment à jour mais il reste bloqué.

En version gratuite, on n'a pas le choix d'utiliser une mise à jour "rolling" : un nouveau nœud démarre avant qu'un ancien nœud ne s'éteigne, et ainsi de suite jusqu'à ce que je tous les nœuds soient à jour. Jusque là, rien de bien original ni complexe, c'est plutôt bien.

Sauf qu'avec les restrictions de stockage offert (donc si on ne veut pas payer), impossible de démarrer un nouveau nœud.

Deux solutions possibles : réduire le nombre de nœuds désirés (et donc la puissance totale du cluster) pour faire la mise à jour, ou bien détruire et recréer le groupe de nœuds.

Vu que j'ai tout gérer en infrastructure as code, j'ai choisi de détruire et recréer le groupe de nœuds mais il faut accepter un downtime pendant la mise à jour du coup.

Bref, pas un retour très bloquant mais il faut le savoir. Et de toute façon, je supprime ce cluster.

Pourquoi je supprime mon cluster

J'ai deux raisons d'arrêter l'utilisation de ce cluster.

La première, c'est que le projet pour lequel je l'utilisais est dormant. Ce sont des choses qui arrivent, j'ai dû prioriser pas mal d'autres sujets et aussi prendre du temps pour moi, ce n'est que partie remise.

La seconde, c'est parce que je souhaitais supprimer mon compte OCI suite aux prises de position du patron d'Oracle.

Utiliser les fournisseurs cloud américains ou non, c'est déjà financer des grandes fortunes. Ça, on y échappe difficilement.

Mais Larry Ellison, le président exécuif d'Oracle, a clairement indiqué qu'il souhaitait utiliser la surveillance de masse et l'intelligence artificielle. Sa vision "utopique" (de son point de vue) est que si tout le monde est surveillé, plus personne ne commet de crimes.

Pour information, voici quelques sources au hasard sur ce qu'il a dit :

Au passage, il a soutenu Donald Trump lors de sa campagne, bref rien de bien original mais c'est assez pour faire un boycott au moins pour tout ce qui est personnel. J'aurai sûrement plus de mal si c'était un·e client·e qui l'utilisait (de toute façon, ma clientèle préfère les trois grands fournisseurs américains dont on sait que les patrons apprécient bien assez Trump, j'aimerais bien retrouver des client·e·s qui accepteraient d'utiliser un cloud européen comme j'ai pu en avoir par le passé).

Voilà donc pourquoi je supprime ce cluster Kubernetes !

Une suite ?

J'ai par contre décidé de faire un peu plus d'auto-hébergement donc je pense que bientôt je vais parler de mon "homelab" (j'aime pas les anglicismes mais je ne trouve pas d'équivalent français, "labo à la maison" ça me semble pas aussi expressif). Il est en cours d'évolution (à ce stade je crois que je peux parler de révolution) pour accueillir un peu plus de charge, j'espère arriver à en faire un petite série d'articles "sympas" !

"Homelab", un serveur à la maison : introduction

2025-03-05T00:00:00+00:00

Je sais que je devrais terminer mon trépied pour mon didgeridoo (et promis : ça viendra, si possible avant que la première partie fête son anniversaire) mais j'ai été alpagué·e sur d'autres sujets, incluant celui dont je vais parler aujourd'hui.

Voyons cet article comme une introduction sur le sujet d'un "homelab", terme utilisé pour parler d'un ou plusieurs serveur(s) qu'on a chez soi généralement dans le but de faire des tests de technologies ou autre.

Avant-propos

Dans cette introduction, je vais évoquer pourquoi je souhaite avoir mon serveur à la maison et quelles sont mes contraintes matérielles et logicielles. D'autres articles suivront, le plan est encore indéfini mais je divulgâche un peu : j'ai fait deux itérations.

Je ne sais pas combien de parties il y aura : j'ai fait deux itérations mais je me sens déjà obligé·e de faire une introduction à part entière (commune aux itérations donc). Il y aura probablement un article sur les réflexions que la première itération ont amené, en plus d'un part itération et probablement un ou deux autres sur des sujets plus globaux.

Bref, il faut s'attendre à un peu de lecture ! Mais je vais tenter de découper les articles pour les rendre indépendants afin de permettre un peu de liberté aux personnes qui s'intéressent éventuellement à un sujet mais pas au reste.

Historique

Quand je vivais en appartement, j'avais mis en place un serveur sur un vieux PC portable avec un Core i7 Ivy Bridge (donc un processeur qui datait de 2012) et 8Go de RAM. Bien assez pour ce que j'en faisais : un serveur domotique et multimédia.

Au déménagement, je l'ai décommissionné (traduction : « débranché puis jamais rebranché ») car on allait faire des travaux dans notre maison et je me rendais bien compte que je ne le gérais pas très bien en terme de mises à jour (il était sous Debian 9 si je me souviens bien, Debian 11 existait au moment où je l'ai débranché) et qu'il prenait une certaine place là où je pouvais le mettre.

D'un autre côté, j'avais une petite machine virtuelle chez un fournisseur cloud français qui hébergeait un serveur Nextcloud. Devinez quoi : 10€ par mois, tout sur le même serveur (PHP, MySQL et Redis) et, soyons honnête, peu de maintenance de ma part. C'était pas terrible mais ce temps est révolu !

Pour cette machine virtuelle, j'avais quand même automatisé des sauvegardes sur un "object storage" type S3, c'était le minimum pour ne pas perdre mes contacts et mes calendriers.

Les besoins

Cette liste n'est pas exhaustive et contient l'essentiel des mes besoins au moment de la création de mon homelab.

Domotique

Sur mon ancien serveur à la maison, je faisais fonctionner Home Assistant (lien en anglais). Dans l'appartement, ça me servait surtout à collecter des informations sur la température et l'humidité de la cuisine, du salon et de la salle de bain, ainsi que l'ouverture de la porte (étant au deuxième étage, les fenêtres avaient peu de chances d'être le point d'entrée pour un cambriolage). J'avais bien quelques idées supplémentaires mais je n'ai jamais pris le temps de les mettre à exécution.

Dans la maison, j'aimerais surveiller ces paramètres et quelques autres choses : notre consommation d'électricité et notre production solaire (on a une petite production, sans batterie). Éventuellement, j'aimerais automatiser quelques petits trucs mais c'est encore ne réflexion.

Bref, j'aimais bien mon serveur domotique et j'aimerais recommencer, en mieux !

Contacts et calendriers

Évidemment, le fameux Nextcloud précédemment cité, il était temps que je le migre autre part. Le but étant de ne plus payer un hébergeur, puisque je l'aurais chez moi, et de me motiver pour le maintenir (en voyant le serveur sous mes yeux, je me souviendrai facilement qu'il existe et qu'il faut le gérer).

Je n'utilise pas tant Nextcloud pour les fichiers, c'est surtout pour les contacts et calendriers. Je le synchronise en CardDAV et CalDAV sur mes appareils (Linux et Android), ça me va bien comme système.

J'aimerais avoir un peu "mieux" que Nextcloud pour faire ça, notamment plus léger, mais je ne trouve rien qui a le côté pratique de l'interface Nextcloud, pour envoyer des invitations par exemple. Et j'ai une autre contrainte qui arrive et à laquelle Nextcloud se plie sans problème.

SSO

Cette contrainte, c'est pour ma facilité : j'aimerais me connecter via un seul portail à toutes mes applications. Et Nextcloud est compatible avec OpenID Connect (lien en anglais) notamment.

Bon, Home Assistant ne l'est pas donc il me restera un compte à part pour ça, mais est-ce grave ?

Galerie photos

Je souhaite pouvoir téléverser automatiquement mes photos depuis mon mobile vers un serveur qui me permettrait de faire des albums par exemple.

La référence dans ce domaine, pour l'instant, semble être Immich (lien en anglais) mais j'ai vite constaté (en essayant de le démarrer lors de ma première itération) que ça prenait beaucoup de ressources que je n'avais pas.

Bref, grâce à ce chouette comparatif (lien en anglais), j'ai décidé d'utiliser Nextcloud Memories, comme ça Nextcloud gagnerait en utilité. Mais on verra plus tard que ce n'était pas gagné non plus.

Mes contraintes

On pourrait croire que la réponse à tout ça c'est « Installe Debian sur un vieux PC, comme tu l'avais déjà fait, et puis tu mets tous tes trucs dessus, voilà ! », sauf que ce serait mal me connaître.

Mises à jours automatiques (ou presque)

Un point sur lequel j'ai de plus en plus de mal à déroger : je ne veux pas avoir à trop « penser » à la maintenance. Je sais qu'il y en aura mais justement, plus elle peut être minimale, mieux c'est.

Et maintenant, on a plusieurs OS (côté serveur comme côté bureau) qui répondent à ce besoin d'une belle manière : une fois installé, le système se met à jour automatiquement de manière régulière et il n'y a qu'à le redémarrer pour avoir la dernière version. Mieux encore, sur les OS modernes, les mises à jour sont transactionnelles, ou « atomiques » : le système revient à la précédente version installée si la nouvelle ne fonctionne pas.

Dans la théorie, cela réduit la maintenance à… Peu de choses.

Kubernetes

Je fais partie des gens qui remarquent que Kubernetes résout beaucoup de problèmes. Et comme je l'utilise tous les jours chez la clientèle, autant garder les bonnes habitudes. Ce sujet mériterait un article à lui tout seul d'ailleurs. En plus, avec k3s (lien en anglais), ça s'installe à peu près n'importe où, alors pourquoi se priver ?

Ça veut aussi dire que je vais devoir mettre sur Kubernetes des choses qui ne sont pas forcément prévues pour à l'origine, comme Home Assistant justement. Bon, ça ne me fait pas peur (et d'ailleurs, ça fonctionne parfaitement à l'heure où j'écris ces lignes).

Aussi, j'utilise beaucoup les outils GitOps comme ArgoCD (lien en anglais) ou FluxCD (lien en anglais), ça fait partie de mon utilisation de Kubernetes et des choses que je trouve vraiment pratiques.

Consommation et silence

Mon précédent serveur ventilait pas mal quand même, la faute à l'espace où il était un peu confiné. Et un Core i7 de Ivy Bridge, même pour PC portable, on dirait pas mais ça consomme.

Bref, au moment de m'y mettre on était en 2024 donc c'était déjà le bon moment pour utiliser un ordinateur à l'architecture aarch64 (ou arm64 selon comment vous l'écrivez) et sans ventilateur. Ça veut dire : non merci pour le Raspberry Pi 5 qui a besoin d'un refroidissement actif.

Stockage

Généralement, les PC en aarch64 utilisent une carte SD et éventuellement une puce eMMC pour le stockage mais en terme de performance et de capacité, c'est rarement très élevé.

Je souhaite donc avoir la possibilité de mettre un SSD supplémentaire pour les données. Idéalement NVMe plutôt que SATA, ça permet de ne pas avoir un câble (même petit) qui traînerait et de garder le boîtier d'origine de l'ordinateur s'il en existe un.

Et la suite ?

Au moment où je publie cet article, j'ai déjà choisi du matériel et presque arrêté mon choix sur le système d'exploitation. Par la suite je vais donc parler :

De ma première itération à ce sujet, notamment :
1. Le matériel que j'ai choisi ainsi que l'OS.
2. Ma manière de gérer les logiciels que j'installe.
3. Probablement, la gestion de l'image Nextcloud que j'utilise, car tout n'est pas automatique.
4. Les réflexions que m'ont apporté
De ma seconde itération, incluant :
1. Le matériel qui me permet de faire mieux que la première fois.
2. Le système d'exploitation (c'est un sujet en cours, même une certaine aventure).
3. Des évolutions sur la gestion des logiciels, si je décide de faire les évolutions que j'imagine.
4. Des sauvegardes, parce que ma première itération n'est pas très fiable pour ça.

Je rappel que le plan n'est pas forcément définitif mais il y aura de quoi raconter !

Nouveau didgeridoo

2024-11-10T00:00:00+00:00

J'ai produit moins de son que lors de mes premières expériences sonores mais c'était surtout pour jouer avec le « petit nouveau » que j'ai acheté à Colas. Bon, ce n'est pas la première fois que je soufflais dedans mais j'avais envie de l'enregistrer un peu, pour mon plaisir.

Je n'ai activé aucun effet sur la loopstation, j'ai juste rajouté du gain au « mixage » avant d'exporter les fichiers (je mets des guillemets parce qu'à mon niveau, je sais juste couper des pistes sonores et appliquer quelques effets, ce qui me suffit amplement).

J'ai commencé par un traditionnel « échauffement ». Enfin, c'était plus long que ça mais j'ai exporté seulement une trentaine de secondes parce que pour le reste, c'est pas terrible.

J'adore cette note bien grave, ça m'ancre au sol.

Ensuite, j'ai joué en champ libre, sans ajouter de rythme à la loopstation.

Ça s'est terminé sur une faute de souffle !

Après, j'ai enregistré un tout petit rythme dans la RC-202 (la loopstation). Comme je le fais à traver le didgeridoo il y a une légère résonance.

La version « résumée ».

Et la version longue.

Et j'ai terminé par l'enregistrement d'un autre rythme (toujours au travers du didgeridoo) et un jeu un peu expérimental.

C'est pas parfait mais l'idée globale de cet extrait me satisfait.

Quelles conclusions pour ce nouvel essai ?

Avoir un micro dédié pour le beatbox, je pense me commander un AKG D5 d'occasion ;
Changer le micro du didgeridoo car je trouve que le Shure SM57 rend pas forcément bien (notamment le « grain » du didgeridoo me semble sous-représenté), j'aimerais trouver un Audix i5 d'occasion mais ça part vite ;

Bref, de l'investissement peut-être.

Aussi, j'aimerais finir les modification de mon trépied pour utiliser les deux didgeridoos en même temps (il me faudra donc forcément un deuxième microphone).

Je me rends compte que pour ce genre de tentatives, les deux pistes de la RC-202 sont très convenables, c'est juste limitant quand on veut faire quelques chose de plus long avec un changement de rythme, ou encore qu'on veut pouvoir activer et désactiver des parcelles du rythmes.

Par ailleurs, je ne les ai pas uploadés mais j'avais fait quelques essais de kick au pied (je parlais de stompbox lors de mon dernier essai mais en fait, j'ai une pédale pour ma loopstation donc je peux l'utiliser comme kick en enregistrant un son au beatbox sur la loopstation et en le lançant en « one shot » plutôt qu'en boucle) : c'est intéressant et je veux creuser un peu pour voir si j'arrive à en faire quelque chose.

Le temps manque encore, toujours dans les travaux (les finitions, ça prend un temps très long) mais j'aimerais vraiment faire plus d'expériences musicales !

Comment va mon cluster Kubernetes gratuit ?

2024-05-05T00:00:00+00:00

Avis sur Oracle Cloud

Cette première partie est un peu auxiliaire mais n'ayant jamais utilisé Oracle Cloud Infrastructure, je me dis que c'est le moment de rédiger un avis. Si cette partie ne vous intéresse pas, il est tout à fait possible d'aller directement à la prochaine partie.

Pour information, je précise où je me place, j'ai déjà utilisé (pour mon compte ou pour la clientèle) :

Amazon Web Services ;
Microsoft Azure ;
Google Cloud Platform, dans une moindre mesure ;
Orange Flexible Engine, qui se base sur la plateforme développée par Huawei et qui n'est franchement pas terrible ;
Scaleway ;
OVH ;
Hetzner ;
Exoscale, de manière très succinte ;
OpenStack chez Infomaniak, juste pour de l'object storage.

Il me surprend que la liste soit si longue, certes en comptant les utilisations « moindres ». Un de ces jours, il faudrait vraiment que je fasse un comparatif entre OVH et Scaleway, il y a des choses à raconter !

Déjà, j'apprécie beaucoup la page de free tier qui est très précise. Pour les besoins au delà, il y a un calculateur comme chez les « grands fournisseurs » cloud (et son ergonomie est discutable mais je n'ai jamais trouvé de calculateur de coûts qui me sied parfaitement chez les fournisseurs, c'est déjà bien quand ça existe).

J'ai uniquement utilisé le module Opentofu/Terraform qui m'intéressait, il est plutôt bien si on exclue le besoin de faire le tofu apply en plusieurs fois (je l'avais évoqué dans mon précédent article).

Le nombre de services a l'air intéressant, pas aussi grand que chez AWS ou Azure mais il y en a suffisamment pour couvrir tous les besoins de base et même un peu plus.

L'interface web

J'ai navigué un peu sur l'interface web d'Oracle Cloud (que j'appellerai aussi « console ») pour observer un peu les ressources qui étaient créées et chercher quelques informations sur mon utilisation des crédits offerts. Je n'ai initié la création d'aucune ressource via ce portail, j'ai uniquement utilisé OpenTofu pour ça.

Avant de parler d'ergonomie, je note que le « style » est basique. Pas très beau mais pas spécialement laid. Oui, c'est un avis un peu nul. Je dirais que ça ressemble à la console d'AWS en 2018, donc un peu austère et « vieillot », mais sans les dégradés de gris qui laissaient croire (à l'époque) à un retard de 10 ans chez la direction artistique.

Mais le vrai problème des console des fournisseurs cloud, ce n'est pas d'avoir de jolies couleurs, c'est surtout de faire en sorte que les gens se retrouvent dans les services, les ressources, les options et tout ce que le fournisseur propre.

À ma connaissance, je n'ai pas de problème visuel au delà du fait que je porte constamment des lunettes pour corriger ma vue.

Toutefois, la frustration monte vite en moi quand je ne trouve pas ce que je cherche ou que je ne comprends pas une indication. Je ne m'énerve pas pour autant, j'ai une grande patience et j'ai appris à garder une bonne tolérance face à cette frustration mais je tombe facilement dans un cercle vicieux où par frustration, j'ai du mal à réfléchir sur une autre manière de trouver ce que je cherche.

Donc pas de handicap notable quand je me balade sur une interface graphique, juste un cerveau qui n'aime pas trop travailler pour des broutilles. Ah, j'ai aussi horreur des icônes sans texte, je préfère du texte sans icône (ça se voit probablement sur mon site).

Petite parenthèse : j'aimerais beaucoup trouver des articles qui parlent de l'accessibilité des interfaces graphiques des fournisseurs cloud, avec des témoignages et des tests par des personnes qui ne sont pas aussi valides que moi.

Commençons par un bon point : Oracle n'a pas mis des icônes dans tous les sens, c'est très textuel et j'apprécie vraiment. Mon cerveau se sent à l'aise pour trouver l'information sur une page.

Aussi, la catégorisation des services est plutôt bien, sauf pour quelques outils. Notamment, OKE (le service de Kubernetes auto-géré) est dans la catégorie « Developers services » qui a l'air d'être le fourre-tout pour tout ce qui ne rentre pas dans une autre catégorie.

Enfin, la vue d'une ressource est… Particulière mais fonctionnelle. On s'y fait et on comprend vite le fonctionnement de la page qui est d'ailleurs très cohérente entre tous les services (les gens qui ont utilisé AWS Beanstalk savent qu'il peut y avoir des produits qui ont une interface différente des autres chez un même fournisseur, en tout cas en 2016 c'était ça). Et je dirais même que j'ai fini par apprécier cette ergonomie car je trouvais facilement les informations que je cherchais sur les ressources.

Petit point bonus : les liens internes sont bien pensés et certains s'ouvrent dans un nouvel onglet quand ça mène vers une ressource d'un autre service. Par exemple, quand on clique sur le nom d'une machine virtuelle qui est listée dans un groupe de nœuds du cluster Kubernetes, alors ça ouvre la ressource dans un nouvel onglet car on passe sur le service « Compute ». On aime ou on n'aime pas, personnellement j'apprécie ce point.

Entrons maintenant dans le vif du sujet !

Gratuit, vraiment ?

Sachant qu'on a 250€ de crédits offerts sur un mois, comment savoir si le cluster avait un coût ? Il suffit de regarder ce qui est consommé dans le crédit.

Du coup : est-ce que j'ai pu utiliser le cluster sans que ça ne touche les crédits offerts par Oracle ? La réponse est : presque ! J'ai consommé 5,65€ au 4 mai (dernier jour de mon crédit), apparemment à cause d'un load balancer que j'aurais créé le 22 avril. Ce qui me surprend, c'est qu'on a normalement droit à un load balancer gratuit.

En tout cas, c'était un service Kubernetes de type LoadBalancer qui a créé la ressource sur Oracle Cloud, lorsque j'ai installé ma gateway. Le load balancer créé de manière automatique doit être d'une puissance qui va au delà de ce à quoi on a droit gratuitement. J'avais pourtant changé la configuration pour utiliser un autre type de service mais il semblerait que le changement ne se soit pas passé comme prévu. J'ai donc manuellement supprimé le service Kubernetes en question puisqu'il n'était plus censé servir.

Donc il semblerait que l'objectif de gratuité puisse être atteint si on n'a pas besoin de load balancer. Mais « gratuit » ne veut pas dire « illimité » (personne n'a dit le contraire mais ça fait la transition pour la suite) !

Les limitations découvertes

Puissance disponible

Avec tous les outils que j'ai installé dans le cluster (je ne suis pas assez minimaliste en terme technologique), ça m'a fait manquer de ressources. Ça me fait penser que je devrais faire un petit wiki sur mon site avec la liste de mes logiciels essentiels.

En architecture ARM, on a droit à 4 OCPU (donc théoriquement l'équivalent de 8 vCPU) et 24Go de RAM. Je ne parle pas de l'architecture x86 car l'offre gratuite est très très faible et j'avais donc indiqué dans mon premier article que je m'intéressais qu'à l'offre ARM qui est assez généreuse.

Resources des pods

En premier lieu, j'ai changé pas mal de requêtes et limites de ressources sur certains outils qui n'ont pas besoin de leur puissance habituelle dans mon cas. Aussi, comme un OCPU est censé valoir « au moins deux vCPU », j'ai considéré que quand un pod a besoin d'au moins 1 CPU, il faut donc considérer qu'il a besoin que d'un demi-CPU chez Oracle. Pour retourner un peu la chose, j'ai considéré que 1 CPU vaut 500m (rappel : pour Kubernetes, 1 cœur de CPU vaut normalement 1000m donc mathématiquement, si 1 OCPU vaut deux cœurs, ça signifie que 1 OCPU vaut théoriquement 2000m).

Ça fait beaucoup de chiffres et d'unités, j'espère que c'est assez clair.

Nombre de machines virtuelles

Aussi, à l'origine, j'avais créé un groupe de deux nœuds, chacun ayant 1 OCPU et 6Go de RAM ce qui faisait un total de 2 OCPU et 12Go de RAM. Gratuitement, on a droit à un total de 4 OCPU et 24Go de RAM donc j'ai ajouté un nœud de la même puissance ce qui fait que j'utilise 3 OCPU et 18Gi de RAM.

Une solution possible est de plutôt tourner avec deux nœuds chacun d'une puissance de 1 OCPU et 8Go de RAM mais du coup on garde une certaine limite en terme de processeur (on ne pourrait pas avoir 2 OCPU par nœud car le roulement ne pourrait pas se faire à cause de la limite à 4 OCPU qui serait dépassée lors de celui-ci). L'avantage de passer sur trois machines virtuelles est donc qu'on a 3 OCPU au total en temps normal et pas seulement 2 OCPU.

Mais du coup, ça crée un blocage sur les volumes, ce qui fait une transition parfaite pour mon point suivant.

Volumes

Si vous avez lu la partie précédente sur le CPU et la RAM, vous aurez noté que j'utilise trois machines en temps normal et que le roulement en cas de mise à jour ou de maintenance fait que les 200Go sont totalement utilisés. Cette limite semble avoir été parfaitement calculée par Oracle pour être bien frustrante et forcer un peu le passage à la caisse mais je ne juge pas, il faut bien vendre.

J'ai rapidement constaté que je n'arrivais plus à créer de PersistentVolumeClaim à cause de cette limitation du stockage qui est entièrement utilisée par mes machines et celle de roulement.

Trois choix s'offraient à moi :

Accepter de payer (haha, vous me prenez pour qui ?) ;
Utiliser des volumes de type hostPath là où c'était suffisant ;
Installer Rook ou Longhorn pour pouvoir gérer moi-même les volumes.

Si vous n'avez pas envie de lire mes justifications et explications, je divulgâche : j'ai utilisé Longhorn (les raisons sont expliquées ci-dessous). Voilà, vous pouvez aller directement à la conclusion si vous n'avez pas besoin ni envie d'en savoir plus.

En premier lieu, dans ma grande radinerie et mon habituelle flemme, j'ai choisi d'utiliser des hostPath à gogo.

En tout état de cause, ça m'a créé des problèmes avec les droits de certains outils sur les chemins montés dans les pods donc j'ai décidé que ce serait l'occasion de tester Rook (un collègue indépendant m'en avait parlé en bien). Sauf que, surprise (ou pas), Rook est un peu complexe (ça démarre et gère un cluster Ceph notamment) et j'ai vite déchanté en essayant d'apprendre son architecture alors que sur le moment je voulais juste faire mes volumes sans réfléchir. Toutefois, je donnerais une chance à Rook quand j'aurai du temps à lui donner, ça a l'air trop intéressant pour que je le laisse définitivement de côté !

Donc j'ai plutôt essayé Longhorn, l'architecture est assez simple : les volumes utilisent le disque des nœuds et les contenus sont répliqués pour la sûreté. Ici je l'utilise de manière très basique mais Longhorn peut être très puissant et proprement configuré en utilisant des serveurs avec des disques physiques supplémentaires qui lui seront dédiés.

On pourrait croire que tout ça ressemble beaucoup à une utilisation des hostPath avec un outil au milieu mais il y a quelques avantages :

Si un pod se fait couper et est relancé sur un autre nœud, le volume sera déplacé et suivra le pod pour éviter une perte de données ;
En théorie, Longhorn nettoie les données des volumes inutilisés (toutefois j'ai l'impression que ce n'est pas pleinement fonctionnel mais je ne sais pas si j'ai eu une bug ou si j'ai mal configuré tout ça) ;
Certains paramètres de Longhorn sont utiles même pour un déploiement aussi basique : nettoyages des données orphelines, pourcentage minimum d'espace libre voulu sur le disque…

En toute transparence, je trouve que c'est une chouette technologie à avoir dans un coin de ma tête pour des besoins très spécifiques chez quelques clients.

Conclusion

Rappelons-nous que je n'ai fait que créer et utiliser un cluster Kubernetes (ainsi que le réseau et les sous-réseaux), qui lui-même crée des ressources annexes (comme les machines virtuelles).

Je pense avoir quatre points principaux à évoquer :

Oracle Cloud me satisfait pour ce que j'en ai essayé ;
La gratuité est réelle mais attention aux ressources annexes créées via Kubernetes (load balancers et volumes blocs par exemple) qui ne sont pas offertes ;
La puissance disponible peut être limitante si, comme moi, on installe beaucoup de choses pour servir de base ;
Il ne faut pas compter sur la possibilité de créer des volumes de type bloc, aussi je recommande d'installer Longhorn ou autre technologie du même genre pour compenser le manque de place.

D'ailleurs, ça m'a fait plaisir de tester Longhorn mais j'aurais aimé aller du côté de Rook. J'avais quand même testé l'installation mais ça prenait vraiment beaucoup de ressources. Longhorn démarre pas mal de pods lui aussi mais Rook semble encore plus consommateur.

Voilà, je me réserve la possibilité de faire une troisième partie ou une petite mise à jour si je découvre de nouvelles choses !

Un cluster Kubernetes gratuit ?

2024-04-07T00:00:00+00:00

Mon besoin

Donc, je souhaite avoir un cluster Kubernetes gratuit.

Bien sur, j'ai des critères en plus du coût qui doit rester nul :

Que ça tourne sur le territoire français (idéalement chez un fournisseur lui-même français ou européen mais pour quelque chose de gratuit, je ne suis pas ferme sur ce point) ;
Que le cluster soit infogéré (je ne veux pas lancer un k3s ou équivalent, je suis la flemme incarnée ) ;
Qu'il y ai au moins deux nœuds, comme ça lors des mises à jour il y en aurait toujours un en route pour les composants « essentiels » ;
Avoir au moins 4 CPUs et 8Go de RAM en tout dans le cluster, ça peut paraître léger mais pour le stade de développement auquel je suis, ça suffira amplement.

Du coup, j'ai trouvé une réponse à tout ça, avec les points d'attention suivant :

C'est géré par des américains (mais pas Amazon, ni Microsoft, ni Google, on va dire que c'est déjà ça) ;
C'est bien dans une région française, il y a quelques autres régions européennes disponibles ;
Les nœuds gratuits à vie ne sont pas en amd64/x86_64 mais en… aarch64 (ou arm64 si vous préférez) !

Je vais donc avoir un cluster gratuit, hébergé en France, avec une architecture ARM 64 bits.

Mais qui fourni gratuitement ces ressources ? Oracle Cloud Infrastructure (qu'on abrège apparemment OCI, ce qui me crée une petite confusion avec l'Open Containers Initiative mais je vais m'y faire).

À propos d'Oracle

Je ne suis pas fan d'Oracle, tout comme je ne suis pas fan des trois gros fournisseurs cloud américains (AWS, Azure et GCP).

En l'occurence, c'est le seul moyen que j'ai trouvé actuellement pour avoir un cluster Kubernetes gratuit : Oracle offre des nœuds aarch64 gratuitement à vie ! Pour prototyper, c'est génial : ça peut grimper à 8 cœurs de processeur et 24Go de RAM, divisables en une à quatre machines virtuelles.

Je n'aurais pas choisi Oracle s'il n'y avait eu aucune région disponible en Union Européenne, toutefois j'ai conscience qu'un doute plane sur la possibilité pour le gouvernement américain de réclamer des données hébergées chez des entreprises américaines, même en Union Européenne voire en France.

Si le sujet du Cloud Act vous intéresse, certais founisseurs proposent leurs solutions (sans évoquer les projets Bleu et S3NS) :

AWS indique que chiffrer les données est suffisant alors qu'à l'époque de l'annonce du Cloud Act, ils indiquaient que les demandes des USA ne seraient pas applicables (ce qui contrastait avec ce que disait IBM, à savoir que le cadre imposé par le gouvernement américain n'était pas contournable) ;
Azure cloisonne les données européenne, il me semble qu'à l'époque de l'annonce leur discours était nuancé et qu'ils évoquaient une possibilité de faire des remboursements en cas de demandes de données appliquées (c'est bien d'avoir un gros chéquier ) ;

Mise en place

Quelques concepts sur Oracle Cloud Infrastructure

On notera qu'Oracle permet de créer des compartments (soit des compartiments en français) et qu'un compte sur leur cloud fait partie d'un tenant (ça se traduit par « locataire » en français, je n'y avais jamais réfléchis malgré le fait que dans mon milieu on parle souvent de tenants).

Chaque tenant a un compartment par défaut nommé « root ». Personnellement j'en ai créé un spécifique pour mon projet.

Comme chez tout bon fournisseur cloud, on retrouvera (dans ce qui nous intéresse) :

Des réseaux virtuels, nommés Virtual Cloud Networks et abrégés VCN ;
Des sous-réseaux pour ces derniers, nommés subnets (rien de très original, tant mieux) ;
Diverses gateways et IP à mettre dans les VCN ;
Et le service de Kubernetes infogéré qui s'appelle Container Engine for Kubernetes et qui est abrégé OKE (donc ce n'est pas un acronyme puisque ça ne correspond pas au nom complet, c'est curieux mais ce n'est pas notre sujet du jour ).

Configurer le cluster Kubernetes

Je fais tout en « infrastructure as code » (qu'on abrège « IaC »), du coup cet exemple n'y échappe pas. Habituellement, j'utilise Terraform mais j'ai profité de cette occasion pour tester OpenTofu, le fork de Terraform sous licence réellement libre géré par la Linux Foundation (juste au cas où : le manifeste d'OpenTofu explique pourquoi ce fork a eu lieu) et ça a très bien fonctionné.

J'aime optimiser les choses et Oracle a eu la bonne idée de publier un module Terraform qui crée toutes les ressources nécessaires, ce qui permet de gagner beaucoup de temps !

Voici le code HCL qui permet d'utiliser ce module, avec des commentaires pour donner quelques détails. En réalité j'ai utilisé beaucoup de variables, que j'ai remplacées ici par des valeurs fixes pour l'exemple (sauf pour les choses qu'il faut, à mon avis, absolument passer en variables).

1 terraform {
2  required_version = ">= 1.6"
3 
4  required_providers {
5  oci = {
6  source = "oracle/oci"
7  # J'utilise Renovate pour mettre à jour automatiquement la version, d'où le fait que j'utilise une version précise.
8  version = "5.36.0"
9  }
10  }
11 }
12 
13 # Ces valeurs me permettent d'avoir une petite cohérence dans mes ressources quand je vais voir sur l'interface d'Oracle Cloud Infrastructure.
14 locals {
15  app_name = "example-application"
16  environment = "development"
17 
18  resource_name = "${app_name}-${environment}"
19  tags = {
20  "name" = local.app_name,
21  "environment" = local.environment,
22  }
23 }
24 
25 # On doit fournir une IP déjà créée pour que les nœuds aient accès à internet, c'est dommage mais pourquoi pas.
26 resource "oci_core_public_ip" "example" {
27  compartment_id = var.oracle_compartment_ocid
28 
29  display_name = local.resource_name
30  freeform_tags = local.tags
31 
32  lifetime = "RESERVED"
33 }
34 
35 module "example" {
36  depends_on = [resource.oci_core_public_ip.example]
37 
38  source = "oracle-terraform-modules/oke/oci"
39  # Comme pour le provider, le module sera mis à jour automatiquement par Renovate.
40  version = "5.1.4"
41  providers = {
42  oci.home = oci
43  }
44 
45  compartment_id = var.oracle_compartment_ocid
46  home_region = "eu-paris-1"
47  region = "eu-paris-1"
48 
49  # Je n'ai aucune honte : tout se nommera pareil et aura les mêmes tags.
50  vcn_name = local.resource_name
51  cluster_name = local.resource_name
52  freeform_tags = {
53  bastion = local.tags,
54  cluster = local.tags,
55  iam = local.tags,
56  network = local.tags,
57  operator = local.tags,
58  persistent_volume = local.tags,
59  service_lb = local.tags,
60  workers = local.tags,
61  }
62 
63  # Le label DNS permet d'avoir des noms DNS « propres » pour les nœuds dans leur réseau, en vrai ça m'est complètement inutile mais je le renseigne pour le principe.
64  vcn_dns_label = "example"
65 
66  # L'operator est une machine qui permet de gérer le cluster avec kubectl et Helm depuis le réseau du cloud, je ne souhaite pas faire ça.
67  create_operator = false
68 
69  # De la meme manière, le bastion permet de se SSH dans les nœuds directement depuis le réseau du cloud, ce qui ne m'intéresse pas.
70  create_bastion = false
71 
72  # Je souhaite accéder au cluster depuis mon PC local, donc le control plane doit être publique, avec une IP assignée.
73  control_plane_is_public = true
74  assign_public_ip_to_control_plane = true
75  # Ce paramètre n'est pas compatible IPv6 donc j'ai mis seulement mon IPv4, avec un `/32` à la fin pour qu'elle soit vue comme un bloc CIDR.
76  # Donc je ne peux accéder au control plane que depuis chez moi.
77  # Il est possible de mettre `["0.0.0.0/0"]` mais quand même, la sécurité…
78  control_plane_allowed_cidrs = var.kubernetes_control_plane_allowed_cidrs
79 
80  # Voilà donc l'IP publique pour que les nœuds et les pods puissent accéder à internet.
81  nat_gateway_public_ip_id = resource.oci_core_public_ip.example.id
82 
83  # Attention à bien rester à jour !
84  # Je n'ai as trouvé de système d'auto-upgrade de Kubernetes chez Oracle Cloud Infrastructure, dommage.
85  # Chez les autres fournisseur, c'est généralement disponible donc on indique seulement la version globale qu'on veut, par exemple `v1.29`, et une fenêtre de maintenance qui fait que le fournisseur cloud patche les nœuds quand il le faut.
86  kubernetes_version = "v1.29.1"
87 
88  # Ce sont les valeurs par défaut, pour le coup je suis plutôt Debian qu'autre chose coté serveur mais je me dis que quitte à être chez Oracle, autant utiliser leur OS qui est probablement optimisé pour les machines virtuelles fournies.
89  worker_image_os = "Oracle Linux"
90  worker_image_os_version = "8"
91 
92  worker_pools = {
93  "${local.resource_name}-main" = {
94  # Il faut préciser que le groupe de nœuds doit être créé, pourquoi pas hein !
95  create = true
96 
97  # Je commence doucement avec deux nœuds.
98  size = 2
99 
100  # J'utilise des machines basées sur un processeur Ampere 1.
101  shape = "VM.Standard.A1.Flex"
102  # Je rappelle qu'un OCPU vaut « au moins » deux CPU virtuels.
103  ocpus = 1
104  # La RAM est en gigaoctets.
105  memory = 6
106  # Le volume de démarrage est en gigaoctets et 50Go est sa taille minimale requise (j'ai essayé moins, l'APi a retourné une erreur indiquant que 50Go est le minimum).
107  boot_volume_size = 50 # this is the minimum
108 
109  # Je ne veux pas que deux nœuds soient indisponibles en même temps.
110  node_cycling_enabled = true
111  node_cycling_max_surge = 0
112  node_cycling_max_unavailable = 1
113  }
114  }
115 }
116 
117 # Voilà comment on récupère un fichier kubeconfig avec accès publique.
118 data "oci_containerengine_cluster_kube_config" "kube_config" {
119  depends_on = [module.example]
120 
121  cluster_id = module.example.cluster_id
122  endpoint = "PUBLIC_ENDPOINT"
123 }
124 
125 # Et voilà comment on l'enregistre dans un coin.
126 resource "local_file" "kube_config" {
127  depends_on = [data.oci_containerengine_cluster_kube_config.kube_config]
128 
129  content = data.oci_containerengine_cluster_kube_config.kube_config.content
130  filename = "${abspath(path.root)}/kubeconfig.yaml"
131 }

Démarrer le cluster

Le fichier c'est bien, avoir le cluster en bonne et due forme c'est mieux !

Déjà on n'oublie pas de configurer le provider en exportant les variables d'environnement nécessaires, sachant que je me connecte avec une clé d'API créée pour mon compte (chez Oracle ce sont des clés RSA, après tout pourquoi pas) :

TF_VAR_oracle_compartment_ocid="<votre-compartment-ocid>"
TF_VAR_tenancy_ocid="<votre-tenancy-id>"
TF_VAR_user_ocid="…"
TF_VAR_fingerprint="…" # fingerprint de la clé d'API utilisée
TF_VAR_private_key_path="…" # chemin vers le fichier PEM de la clé privée
TF_VAR_region="eu-paris-1" # en France, évidemment, d'ailleurs il y a une région à Marseille
TF_VAR_kubernetes_control_plane_allowed_cidrs='["<votre-ip-fixe>/32"]' # attention, c'est un tableau dans une string!

Ensuite, j'ai dû appliquer en plusieurs fois car une ressource ne peut ête créée avant que les autres ne le soient, donc j'ai fait trois apply pour m'assurer que ça voulait bien se lancer (on notera que tofu peut être remplacé par terraform) :

$ tofu apply -target 'module.example.module.vcn[0].oci_core_vcn.vcn'
# …
$ tofu apply -target 'module.example.module.cluster[0].oci_containerengine_cluster.k8s_cluster'
# …
$ tofu apply

Et normalement, si on va sur l'interface d'Oracle Cloud Infrastructure, tout est bon !

Accéder au cluster avec kubectl

On a un kubeconfig.yaml qui est généré par le code que j'ai proposé mais en l'utilisant, on verra qu'il nous manque un élément important : la CLI OCI qui permet de générer le token de connexion ! En effet, en décorticant le fichier kubeconfig, on voit que l'authentification est gérée par cette fameuse CLI :

1 users:
2  - name: user-[REDACTED]
3  user:
4  exec:
5  apiVersion: client.authentication.k8s.io/v1beta1
6  command: oci
7  args:
8  - ce
9  - cluster
10  - generate-token
11  - --cluster-id
12  - [REDACTED]
13  - --region
14  - eu-paris-1

Vous aurez deux choix pour installer la CLI :

Les instructions officielles ou…
… un petit python3 -m pip install oci-cli (avec éventuellement --break-system-packages si vous avec le même empressement que moi).

Ça vaut dire aussi qu'il faut avoir son fichier ~/.oci/config, que vous obtiendrez en générant votre clé d'API (qui, je le rappelle, est une clé RSA).

Après ça, un petit kubectl get nodes devrait vous prouver que tout fonctionne parfaitement et que vous avez deux nœuds qui sont en fonctionnement.

Utilisation

Consommation de base

Par défaut, le serveur de métriques n'est pas installé. Je l'ai donc appliqué manuellement, vite-fait bien-fait (à l'avenir je ferai en sorte qu'il soit ajouté par mon outil GitOps, avec une version fixe et toutes les recommandations habituelles) :

$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Après une petite minute durant laquelle je laissais le serveur de métriques collecter quelques informations, j'ai pu voir les consommations des nœuds :

$ kubectl top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
10.0.152.38 47m 4% 1272Mi 22%
10.0.158.90 44m 4% 1290Mi 23%

En réalité, en faisant un kubectl top pods --all-namespaces et en additionnant la RAM réellement utilisée par chaque pod, j'obtiens environ 220Mi consommés (celle des nodes est en fait l'addition des limites de RAM de chaque pod, qui sont « surestimées » par rapport à l'utilisation que j'en aurais). Sachant que j'ai mis deux nœuds avec chacun six gigaoctets de RAM et qu'on peut même grimper à 24Go gratuitement, j'ai de la marge !

Installation

Pour ce projet, il m'arrivait de lancer des clusters chez des fournisseurs cloud et de les détruire peu de temps après donc j'ai fait en sorte de me faciliter la tâche au niveau du démarrage.

Du coup, j'ai un petit script (en fait, un Justfile) qui installe les composants de base dans mon cluster. Ça installe notamment ArgoCD qui va lui-même ajouter beaucoup de choses : des opérateurs de gestion de bases de données, Tekton et des pipelines que j'ai créé, un registre Docker léger, Renovate pour faire les mises à jour, etc.

J'ai quand même eu deux problème de compatibilité avec des outils que j'utilise :

L'opérateur de CockroachDB ne propose que des images en amd64, toutefois un ticket est ouvert pour avoir des images aarch64 et une personne a précisé en commentaire avoir construit une image pour aarch64 (attention, elle a une version de retard, je ferais peut-être une nouvelle image à jour moi-même) ;
Le registre d'images Zot propose des images en aarch64 mais ce ne sont pas des images à architectures multiples donc il faut préciser dans les valeurs Helm qu'on veut utiliser leur registre aarch64.

Et bien sûr, mon application était jusque là compilée pour des processeurs amd64 mais je devrais être en mesure de régler ça facilement (j'espère ).

Conclusion

Que dire ? Ça fonctionne, à première vue. Je pense mettre à jour cet article dans un mois environ (ou en faire un nouveau si j'ai beaucoup de choses à dire) pour indiquer si la consommation financière est bien restée nulle selon Oracle (j'ai 250€ de crédit vu que je viens d'y créer mon compte et je peux voir ce qui m'en reste) et si tout fonctionne toujours.

Du coup, voilà les points positifs que je trouve « à chaud » :

Le module fourni par Oracle pour OpenTofu/Terraform est complet et permet de démarrer facilement sur leur cloud ;
La consommation de base sur les nœuds est normale (pas de mauvaise surprise) ;
On peut avoir jusqu'à 8 cœurs de CPU (4 OCPU) et 24Go de RAM, ce qui est plutôt généreux !

Et le négatif que je vois à l'heure actuelle :

Le module fourni par Oracle nécessite de faire des tofu apply/terraform apply en plusieurs fois avec des -target pour ne pas refuser de démarrer l'infrastructure, ça m'a fait batailler un peu au début ;
Le seul CNI proposé est Flannel (et un autre spécifique qui s'intègre aux réseaux virtuels d'Oracle Cloud) et si on veut installer Cilium, il faut activer l'operator dans leur module, ce qui fait une machine qui tourne inutilement (je vais me débrouiller autrement) ;

Il me surprend aussi qu'en 2024, il y ai des « incompatibilités » avec l'architecture aarch64 mais heureusement elles se contournent. Je ne met pas ça dans les points négatifs car ce n'est pas la faute d'Oracle, qui a la gentillesse de fournir des nœuds gratuits sous cette architecture donc je ne vais pas cracher dans la soupe.

Sur ce, je vais tenter de compiler mon application pour cette architecture et je vous dis « à bientôt » pour voir si le prix s'élève bien à 0€ !

Amélioration du trépied de mon didgeridoo : partie 1

2024-02-25T00:00:00+00:00

Où trouver un trépied pour didgeridoo

J'ai un seul trépied malgré mes multiples instruments car jusqu'ici, j'utilise un seul didgeridoo à la fois. Quand je l'ai acheté, je ne savais pas à quel point je trouverais ça utile donc je ne souhaitais pas trop dépenser. Par chance, une personne avait diffusé sur Facebook une annonce Le Bon coin pour se séparer de son didgeridoo et de son trépied. J'ai acheté le trépied seul (et j'espère que le didgeridoo a trouvé sa nouvelle souffleuse ou son nouveau souffleur).

Il y a une chose qu'on remarque rapidement dans le monde du didgeridoo : il y a peu de choses dédiées. Rares sont les trépieds uniquement destinés au didgeridoo et quand c'est indiqué, c'est plutôt un effet de bord (par exemple « trépied pour percussions, peut aussi être utilisé pour d'autres instruments comme les didgeridoos »). Du coup, celui que j'ai acheté d'occasion est en fait vendu neuf comme un trépied de djembé qui répond au doux nom de « DJS9000 » et qu'on trouve par exemple sur MusicStore pour 40€ environ (je n'ai aucune affiliation avec ce magain, je le cite car c'est le seul où il semble être encore en stock).

D'ailleurs, le joueur Adrien B, qui fait partie notamment de Underground Cosmic Didgs et de Kaophonic Tribu au moment où j'écris ces lignes, a fait un excellent article sur Wakademy (je n'ai aucune affiliation avec Wakademy non plus, bien que c'est grâce à ce site et Gauthier Aubé que j'ai appris les bases du didgeridoo) dans lequel il indique qu'il faut parfois bricoler pour avoir ce qu'on veut.

Sinon, quand on n'a pas la possibilité de bricoler (que ce soit par maque de moyens, d'énergie, de courage ou quoi que ce soit) et qu'on a les moyens, le magasin Didgeridoo Passion (là aussi, je n'y ai pas d'affiliation) propose un trépied pré-modifié pour environ 140€ et optionnellement un support pour microphone qui va avec pour environ 30€. Personnellement ça me paraissait un peu cher à l'époque où j'ai acheté mon trépied mais je pense que l'investissement peut être très intéressant (surtout que les pièces sont adaptées par Didgeridoo Passion de manière plus professionnelle que ce que je vais présenter ici).

Anatomie de mon trépied avant les modifications

En nettoyant récemment mon trépied de fond en comble, je me suis rendu compte qu'il est démontable à souhait. J'ai d'ailleurs pu découvrir que certaines pièces pouvaient se régler et qu'elles avaient juste besoin d'être graissées (notamment, certaines parties que le vendeur me disait fixes étaient en fait mobiles).

Voilà à quoi ressemble le trépied (en tout cas, comme je l'ai reçu). Avec mes excuses pour le décors, l'OSB et le placo enduit ne font pas les plus beaux fonds.

On peut donc diviser son anatomie en deux parties principales :

Le corps et les pieds ;
La tête, où l'instrument est posé.

Normalement, la tête est plutôt à la verticale lorsqu'on utilise le trépied avec un djembé mais on peut la pivoter très facilement pour une utilisation détournée (à tout hasard, afin d'y mettre un didgeridoo).

Cette tête n'accueille qu'un seul instrument mais est très bien conçue pour ce faire :

Elle est réglable en longueur ;
Entre deux embouts qui forment un « V » et permettent de placer l'instrument, il y a une sangle qui maintient celui-ci ;
Au bout, il y a deux « crochets » qui empêchent l'instrument de glisser, ça me semble assez important.

Il serait donc appréciable de garder à minima l'idée de la sangle et des crochets afin de stabiliser l'instrument.

Améliorations souhaitées

Il y a deux choses que je souhaite faire :

Utiliser deux instruments en parallèle sans avoir à enlever et remettre chacun d'eux sur le support ;
Placer un microphone microphone devant la cloche de chaque didgeridoo.

Pour le second point, j'ai remarqué que la technique de certaines joueuses et de certains joueurs consistait à créer une « rallonge », percer le bout de la tête pour rattacher cette rallonge et fixer le support de microphone dessus. D'ailleurs, c'est ce que montre Adrien B dans son article sur Wakademy dont je parlais tout-à-l'heure. Cette idée me plaît et il me semble difficile de trouver mieux donc je vais m'en inspirer.

Toutefois, la tête actuelle me déplaît, car elle a quelques tête de vis (certes arrondies) et une arrête qui me font un peu peur de rayer mes didgeridoos. Et quand on connaît le prix qu'un bon instrument peut coûter, ça fait mal de l'abîmer, même si c'est seulement visuel.

Du coup, ne serait-ce pas l'occasion de créer une nouvelle tête sur mesure pour accueillir les deux instruments avec des micros ? Oui, c'est l'occasion. En s'inspirant des bonnes idée de l'existante.

Dans le vif du sujet

J'ai choisi de « construire » une seule tête pour commencer et si ça fonctionne bien j'en ferai une seconde en faisant en sorte de pouvoir les fixer ensemble sur le trépied (j'ai déjà une idée pour le faire mais on verra ça plus tard).

Le plan

J'ai réalisé mes plans avec CadQuery, je l'ai pris en main pour la première fois pour ce projet. J'avais appris à utiliser SolidWorks de manière très basique au collège et au lycée, du coup je voulais essayer FreeCAD mais autant dire que j'ai bien ramé et que j'ai eu des petits bugs qui m'ont fait un peu trop ramer à mon goût.

Vu le temps que j'ai passé sur la modélisation de mon idée, la prochaine fois je pense que je ferai des ébauches sur papier et j'improviserai un peu plus sur le moment. Ça me ressemble un peu plus et je passerai moins de temps sur l'ordinateur. Revers de la médaille, je n'aurais pas un beau modèle en trois dimensions à montrer sur ce blog. C'est un choix !

Plus concrètement, j'ai pris en compte certaines contraintes personnelle :

J'utilise de l'OSB 18mm et de l'OSB 12mm car il m'en reste plein de chutes (les travaux à la maison ont menés à beaucoup de découpes ) ;
La fixation actuelle de la tête sur la rotule (je souhaite conserver cette dernière) est constitué de quatre vis de 6mm de diamètres et espacées chacune de 4cm, du coup j'ai reproduis la même ;
Le support fourni avec mon microphone est a pas de vis de diamètre 3/8" (apparemment c'est souvent comme ça) donc j'ai fait les trous de fixation du support en 9,525mm sur mes plans (dans la vraie vie, j'ai plutôt utilisé une mèche de 8mm parce que c'est ce que j'avais qui s'en rapprochait le plus sans dépasser ce diaètre mais je compte commander une mèche en 3/8" pour finaliser les trous au bon diamètre, au moins ça m'a permis de faire mes tests pour l'instant).

Voilà donc comment je me figure ce nouveau support, qui ira sur le trépied à la place de l'actuel. Les quatres trous qui forment un carré sont la partie qui sera fixée à la rotule du trépied (précisément là où la tête existante est fixée).

La ligne de trous à l'opposé est celle qui servira à mettre un petit « bloqueur » qui évitera que le didgeridoo ne glisse vers l'avant. Ce bloqueur aura deux trous afin qu'il ne puisse pas pivoter sur lui-même et l'un d'eux permettra aussi de fixer le microphone.

Pourquoi avoir fait un ligne de trous pour le bloqueurs, plutôt que de fixer celui-ci directement ? Deux didgeridoos pouvant avoir des longueurs différents, je ferai un premier réglage de l'inclinaison de cette nouvelle tête via la rotule déjà existante sur le trépied (et sur laquelle cette nouvelle tête sera fixée à la place de l'ancienne) et ensuite je pourrai régler l'avancée (ou le recul selon comment on voit les choses) du bloqueur, donc du didgeridoo, pour que les embouchures (le côté où je souffle) soit toutes les deux à une hauteur convenable (je dois pouvoir être debout, les pieds bien ancrés au sol, le corps en position droite et la tête légèrement inclinée en avant afin de souffler confortablement et proprement).

Outils et matériaux

En terme d'outils, il nous en faut deux, éventuellement trois :

De quoi faire de la découpe (scie à onglet, scie circulaire, scie sauteuse ou bonne vieille scie à main) ;
De quoi faire un peu de perçage (perceuse à colonne ou perceuse tout court) ;
En option, pour faire plus propre, de quoi poncer (papier ponce, ponceuse à stationnaire ou encore toute autre option similaire).

Personnellement, j'ai fait les « grandes » découpes à la scie circulaire, les plus petites à la scie sauteuse, les trous à la perceuse/visseuse et le ponçage à la ponceuse excentrique (j'ai eu la flemme de poser la stationnaire mais quand on aura notre atelier, elle sera bien plus accessible et agréable à utiliser).

Pour ce qui est des matériaux, j'ai choisi :

Comme prévu, des chutes d'OSB 18mm et d'OSB 12mm ;
Des boulons adaptés au diamètre de fixation de la tête et à l'épaisseur de mes chutes, sauf que je n'avais rien en 6mm donc j'ai utilisé du 4mm pour l'instant ;
Des vis suffisantes pour finaliser le « bloqueur » (puisque sur mon super modèle 3D, on peut voir deux petites protubérances carrées afin de mieux caler le didgeridoo).

Le résultat et les futurs changements

Je n'ai aucunement pensé à prendre des photos pendant que je travaillais sur ce sujet donc je présente directement le résultat.

Voilà à quoi ressemble le trépied maintenant. N'ayant pas les fixations, j'ai scotché le « bloqueur » pour la photo.

Bon du coup, ça donne quoi ?

Techniquement, ma satisfaction est mitigée : je n'ai pas encore trouvé de quoi sangler le didgeridoo et si celui-ci n'est pas assez « droit » dans sa conception our que le poids n'est pas plus élevée du côté de la cloche, il glisse par dessus la cale (le « bloqueur ») donc il tombe.

Donc, que faire pour la suite ? Je sais déjà quelles sont mes prochaines étapes :

Modifier la cale pour avoir un genre de crochet, comme sur la tête d'origine (qui en a deux) afin de mieux tenir le didgeridoo ;
Coller une bande de scratch (qui passerait sous la tête) pour pouvoir sangler le didgeridoo afin de le stabiliser latéralement ;
Et bien sûr commander une mèche de diamètre 3/8" pour faire les trous correctement ;
Enfin, commander aussi une tige filetée de diamètre 3/8" pour pouvoir faire les fixations de la cale et du microphone (n'ayant pas trouvé ce que je veux en "tout prêt").

Je pense déjà savoir comment je vais modifier la cale, potentiellement sans crochet, mais ce sera pour le « prochain épisode » !

Switch de thème sans JavaScript

2024-02-16T00:00:00+00:00

En créant mon site, j'espérais parler peu de technologies et finalement, mes deux premiers sont dédiés à ça. Mais je sais déjà que le troisième sera sur une autre thématique.

En attendant, pour lire cet article, il faut avoir quelques bases en HTML/CSS et éventuellement JavaScript. « Déso pas déso » comme on disait il fût un temps.

L'objectif

Je souhaitais proposer un bouton qui permet de basculer entre un thème clair et un thème sombre. On trouve beaucoup d'exemples en ligne mais ils ne me convenaient pas pour deux raisons :

Soit ils utilisent beaucoup de JavaScript, hors je n'apprécie pas de mettre du JavaScript là où ça a peu de sens ;
Soit ils ne permettaient pas de changer le thème de manière aussi complète que je le souhaitais (notamment avec le bouton un peu là où je le souhaites, voire un bouton dans le menu principal et un dans les informations de bas de page).

En m'inspirant tout de même de ce que j'ai trouvé à droite et à gauche, mais aussi avec mes propres réfléxions, j'ai réussi à faire ce que je voulais. Je discuterais des avantages et inconvénients de ma solution à la fin de l'article.

Implémentation étape par étape

Pour faire simple, les exemples que je vais montrer utilisent des couleurs très simplistes.

Un thème selon la préférence du navigateur

Il est possible de régler une préférence entre le thème clair et le thème sombre dans le navigateur. La première étape est d'appliquer celle-ci.

En CSS, la media query prefers-color-scheme permet d'obtenir cette préférence. En la combinant avec l'élément :root et les variables CSS, on devrait pouvoir s'amuser un peu.

Déjà, on peut simplement créer et appliquer des couleurs de thème clair :

1 :root {
2  --color-background: white;
3  --color-foreground: black;
4  --color-accent: blue;
5 }
6 
7 body {
8  background-color: var(--color-background);
9  color: var(--color-foreground);
10 }
11 
12 h1, h2, h3, h4, h5, h5, strong {
13  color: var(--color-accent);
14 }

Maintenant, préparons un peu le terrain avec des couleurs « inversées » qui seront utilisées pour le thème sombre, mais en utilisant seulement celles du thème clair :

1 :root {
2  --color-light-background: white;
3  --color-light-foreground: black;
4  --color-light-accent: blue;
5 
6  --color-dark-background: black;
7  --color-dark-foreground: white;
8  --color-dark-accent: red;
9 
10  --color-background: var(--color-light-background);
11  --color-foreground: var(--color-light-foreground);
12  --color-accent: var(--color-light-accent);
13 }
14 
15 body {
16  background-color: var(--color-background);
17  color: var(--color-foreground);
18 }
19 
20 h1, h2, h3, h4, h5, h5, strong {
21  color: var(--color-accent);
22 }

Si vous avez regardé le lien qui documente prefers-color-scheme, vous aurez vite compris qu'il devient facile d'appliquer les couleurs inversées quand le navigateur est configuré pour un thème clair :

1 :root {
2  --color-light-background: white;
3  --color-light-foreground: black;
4  --color-light-accent: blue;
5 
6  --color-dark-background: black;
7  --color-dark-foreground: white;
8  --color-dark-accent: red;
9 
10  --color-background: var(--color-light-background);
11  --color-foreground: var(--color-light-foreground);
12  --color-accent: var(--color-light-accent);
13 }
14 
15 @media (prefers-color-scheme: dark) {
16  :root {
17  --color-background: var(--color-dark-background);
18  --color-foreground: var(--color-dark-foreground);
19  --color-accent: var(--color-dark-accent);
20  }
21 }
22 
23 body {
24  background-color: var(--color-background);
25  color: var(--color-foreground);
26 }
27 
28 h1, h2, h3, h4, h5, h5, strong {
29  color: var(--color-accent);
30 }

Jusque là, on a donc un thème clair et un thème sombre, l'un ou l'autre étant appliqué selon la préférence du navigateur (normalement contrôlé par l'utilisatrice ou l'utilisateur de celui-ci, toutefois pas tout le monde ne connaît cette possibilité).

Thème par défaut

Il est volontaire de ma part de ne pas utiliser une requête @media (prefers-color-scheme: light).

Pourquoi ? Car si un navigateur ne supporte pas prefers-color-scheme, ça évite de devoir faire une solution de secours. Toutefois, ce cher Can I Use indique un support assez étendu (on ne remercie pas Internet Explorer et Opera Mini qui sont un peu en retard, leurs parts de marché rendant la chose peu problématique tout de même).

Si le souhait est d'appliquer le thème sombre par défaut et le thème clair là où il est souhaité, il suffit d'inverser les valeurs par défaut pour utiliser le thème sombre et de changer la media query pour utiliser @media (prefers-color-scheme: light) et d'y utiliser les couleurs claires.

Ajout d'un switch en pur HTML/CSS : solution habituelle

J'expliquais au début de cet article que je souhaite répondre à une éventualité (que j'ai d'ailleurs appliqué sur ce site) : le besoin ou l'envie d'afficher plusieurs switchs.

La technique purement HTML/CSS se base généralement sur le fait d'avoir un <input type="checkbox"> et un <label> qui sont proches et qui précèdent le conteneur de l'application :

1 <input type="checkbox" id="theme-switch-state">
2 <label for="theme-switch-state">SWITCH</label>
3 
4 <div id="content"><!-- … --></div>

Cela permet de créer un fichier CSS simpliste, sans besoin d'utiliser :root d'ailleurs :

1 /* L'input est caché, on clique sur le label qui est très personnalisable */
2 #theme-switch-state {
3  display: none;
4 }
5 
6 #content {
7  --color-light-background: white;
8  --color-light-foreground: black;
9  --color-light-accent: blue;
10 
11  --color-dark-background: black;
12  --color-dark-foreground: white;
13  --color-dark-accent: red;
14 
15  --color-background: var(--color-light-background);
16  --color-foreground: var(--color-light-foreground);
17  --color-accent: var(--color-light-accent);
18 }
19 
20 @media (prefers-color-scheme: dark) {
21  #content {
22  --color-background: var(--color-dark-background);
23  --color-foreground: var(--color-dark-foreground);
24  --color-accent: var(--color-dark-accent);
25  }
26 }
27 
28 #theme-switch-state:checked ~ #content {
29  --color-background: var(--color-dark-background);
30  --color-foreground: var(--color-dark-foreground);
31  --color-accent: var(--color-dark-accent);
32 }
33 
34 @media (prefers-color-scheme: dark) {
35  #theme-switch-state:checked ~ #content {
36  --color-background: var(--color-light-background);
37  --color-foreground: var(--color-light-foreground);
38  --color-accent: var(--color-light-accent);
39  }
40 }

Sauf que ça force la création des éléments dans l'ordre et que du coup, si l'élément <input> est dans un menu, on ne peut déjà pas changer la couleur de ce menu.

Ma solution se base donc sur le besoin (ou l'envie) de mettre le <input type="checkbox" id="theme-switch-state"> où on souhaite et de créer autant de <label for="theme-switch-state"> qu'on le désire, là où on le désire.

Ajout d'un switch en pur HTML/CSS : solution « miracle »

Notons les guillemets du titre ci-dessus : il n'y a pas de solution miracle et j'évoquerais les inconvénients de ma solution à la fin de cet article.

J'utilise simplement l'élément :root avec le récent sélecteur :has et la (pas si récente) pseudo-class :checked. Du coup, en gardant l'ID theme-switch-state sur l'input, on peut écrire le code CSS suivant qui fonctionne :

1 :root {
2  --color-light-background: white;
3  --color-light-foreground: black;
4  --color-light-accent: blue;
5 
6  --color-dark-background: black;
7  --color-dark-foreground: white;
8  --color-dark-accent: red;
9 
10  --color-background: var(--color-light-background);
11  --color-foreground: var(--color-light-foreground);
12  --color-accent: var(--color-light-accent);
13 }
14 
15 /**
16  * Quand le thème est clair par défaut et qu'on a cliqué sur le label un nombre impair de fois (donc qu'on a coché l'input de type checkbox),
17  * on change les variables de base pour utiliser les valeurs sombres
18  */
19 :root:has(#theme-switch-state:checked) {
20  --color-background: var(--color-dark-background);
21  --color-foreground: var(--color-dark-foreground);
22  --color-accent: var(--color-dark-accent);
23 }
24 
25 @media (prefers-color-scheme: dark) {
26  :root {
27  --color-background: var(--color-dark-background);
28  --color-foreground: var(--color-dark-foreground);
29  --color-accent: var(--color-dark-accent);
30  }
31 
32  /**
33  * Quand le thème est sombre par défaut et qu'on a cliqué sur le label un nombre impair de fois (donc qu'on a coché l'input de type checkbox),
34  * on change les variables de base pour utiliser les valeurs claires
35  */
36  :root:has(#theme-switch-state:checked) {
37  --color-background: var(--color-dark-background);
38  --color-foreground: var(--color-dark-foreground);
39  --color-accent: var(--color-dark-accent);
40  }
41 }
42 
43 body {
44  background-color: var(--color-background);
45  color: var(--color-foreground);
46 }
47 
48 h1, h2, h3, h4, h5, h5, strong {
49  color: var(--color-accent);
50 }

Et voilà, on a un bouton pleinement fonctionnel, en pur HTML/CSS, avec la possibilité de mettre plein de <label for="theme-switch-state"> pour que nos visiteuses et visiteurs puissent changer le thème à volonté.

Sauvegarde de l'état

Un inconvénient de cette méthode est que la <input type="checkbox"> ne garde pas forcément son status coché ou décoché entre deux visites. Firefox a l'air de le garder si le cache n'est pas rafraichi en même temps que la page mais Chrome l'efface au moindre changement de page.

Malheureusement (pour moi), je n'ai pas trouvé comment sauvegarder cet état sans JavaScript. Toutefois, le script est très simpliste : il se base sur le classique localStorage et la lecture de l'évènement change sur l'<input> qui gère l'état du thème.

Déjà, posons les bases en écoutant les changements d'état de l'<input> et en l'enregistrant sur le localStorage :

1 const localStorageThemeSwitchKey = 'theme-switch-state'; // la clé qu'on utilisera dans l'object storage
2 const themeState = document.getElementById('theme-switch-state'); // l'élément <input> qui contient notre état
3 
4 themeState.addEventListener('change', () => {
5  if (themeState.checked) {
6  window.localStorage.setItem(localStorageThemeSwitchKey, 'checked');
7  } else {
8  window.localStorage.removeItem(localStorageThemeSwitchKey);
9  }
10 });

On comprend facilement qu'il suffit alors d'utiliser localStorage.getItem(…) au chargement de la page pour rétablir l'état du thème :

1 if (window.localStorage.getItem(localStorageThemeSwitchKey) !== null) {
2  themeState.checked = true; // c'est presque trop facile mais ça marche vraiment
3 }

Et voilà, on a une sauvegarde de l'état qui survit tant que le localStorage n'est pas vidé !

Voici le code complet, que j'encapsule dans un scope parce que je suis un peu maniaque :

1 // Ce script est chargé juste après la balise `<input type="checkbox" id="theme-switch-state">`
2 (function() {
3  const localStorageThemeSwitchKey = 'theme-switch-state';
4  const themeState = document.getElementById('theme-switch-state');
5 
6  /**
7  * On pourrait faire ça sur un window.onload ou mieux, un window.addEventListener('load'),
8  * toutefois je souhaite que le thème soit appliqué au plus tôt donc je le fais de manière synchrone.
9  */
10  if (window.localStorage.getItem(localStorageThemeSwitchKey) !== null) {
11  themeState.checked = true;
12  }
13 
14  themeState.addEventListener('change', () => {
15  if (themeState.checked) {
16  window.localStorage.setItem(localStorageThemeSwitchKey, 'checked');
17  } else {
18  window.localStorage.removeItem(localStorageThemeSwitchKey);
19  }
20  });
21 })();

On n'oublie pas de passer un outil de minification dessus, ça fait toujours quelques octets de gagnés.

Avantages et inconvénients

Ça fonctionne, c'est tout ce qu'on voulait. Mais il est bon de se poser la question : est-ce que c'est la solution parfait ? On sait déjà que la réponse est : ça n'existe pas. Alors quels avantages et inconvénients j'y trouve ?

Les avantages selon mois :

S'adapte au thème choisi par défaut par la visiteuse ou le visiteur ;
La sauvegarde de l'état est très simple à mettre en place ;
On peut mettre autant de switchs qu'on veut puisque ce sont des <label> qui peuvent pointer vers la même <input>.

Les inconvénients de mon point de vue :

Pour garder l'état, il faut un peu de JavaScript (je chipote beaucoup peut-être, c'est vraiment léger) ;
Le sélecteur :root:has(#theme-switch-state:checked), surtout la partir :root:has(…) doit être assez complexe à gérer pour le navigateur, je ne m'y connais pas assez pour savoir mais je sais que mon site n'a pas un DOM immense donc j'en déduis (peut-être maladroitement) que dans ce cas, ça ne doit pas être un problème réel ;
La compatibilité n'est valable que pour les navigateurs très récents (en tout cas, au 16 février 2024), notamment le :has(…) en CSS n'est pas supporté de partout (d'après Can I Use, au moment d'écrire ces lignes, on peut tabler sur presque 92% en global et presque 89% en France et pour une fois, c'est Firefox qui plombe un peu le score).

Dans ce qui me semble être un point d'amélioration sans être réellement un inconvénient, si une personne change sa préférence de thème sur son navigateur, ça va inverser le thème (puisque l'état sauvegardé ne dépend pas de la préférence du navigateur). C'est potentiellement indésiré et il faudrait avoir un script un peu plus intelligent qui utilise window.matchMedia('(prefers-color-scheme: /* light|dark */)').matches pour garder l'état selon la préférence qui était en place. Toutefois, ça me semble très mineur et je préfère avoir un script le plus simple possible.

Blog low tech et low maintenance

2024-02-09T00:00:00+00:00

Choix de la plateforme

Dis, comment on crée un blog ?

Techniquement parlant, il y a de multiples façons de publier et gérer un blog. Peut-être pas autant de façon de faire que de personnes sur terre mais il y en a bien assez :

Utiliser un CMS (« Content Management System », traduisible par « Système de gestion de contenu »), le plus connu étant le fameux WordPress, avec deux possibilité :
- en l'installant et en l'hébergeant soi-même (par là, j'inclus le fait de passer par un hébergeur qui propose des facilités d'installation et de maintenance) ;
- en choisissant un service de gestion de contenu sans installation, d'ailleurs WordPress en propose un sur wordpress.com mais on peut aussi évoquer des plateformes aux sources fermées comme Medium.
Créer sa propre plateforme (et après, on peut même publier les sources ou encore en faire une plateforme d'hébergement payante ) ;
Utiliser un outil de génération statique et héberger ça là où ça nous intéresse (chez un hébergeur de contenu statique, sur un serveur chez un fournisseur cloud ou bien sur un serveur qu'on a chez soi).

Voilà les solutions « habituelles », j'ai pu en oublier une ou deux moins courantes.

Bien sûr, chaque personne ou entreprise choisira sa solution selon ses propres critères.

Mes critères

Justement, j'ai mes propres critères « de base ».

Je souhaite respecter un objectif de faible consommation de ressources, c'est-à-dire que je ne veux pas une plateforme « usine à gaz » qui nécessiterait trop de puissance processeur ou de quantité de mémoire vive. J'ai déjà un serveur très peu cher (mais très peu performant) qui héberge le site statique de mon entreprise (vous me voyez venir, j'avais des critères similaires pour ce dernier), il m'arrangerait de mutualiser mon site dessus pour des raisons économiques et écologiques (surtout que je prévois très peu de traffic pour les deux sites).

De manière un peu similaire, j'ai envie d'avoir pas ou peu de maintenance à faire (pour éviter de la consommation de mes ressources humaines, qui sont constituées de moi et qui dépendent fortement d'une liste de paramètre qui est trop longue pour être explicitée ici), ce qui sous-entend : pas trop de choses à mettre à jour, pas de migration lourde en cas de grosse mise à jour, pas trop de dépendances à installer.

Aussi, j'apprécie vraiment l'utilisation d'un gestionnaire de version pour tout ce qui est code et j'ai tendance à trouver que c'est bien pratique au delà de ça, donc j'aimerais pouvoir stocker mes articles sur un dépôt Git.

Éventuellement, j'aimerais une compatibilité ActivityPub mais c'est très optionnel et plutôt pour la satisfaction personnelle. Si toutefois ce critère n'est pas rempli, avoir la possibilité de générer des flux RSS/Atom me semble être le minimum.

Enfin, je veux que la solution soit open source, parce qu'il y en a plein et que ça me ferait mal de choisir une plateforme propriétaire quand il y a du choix libre.

Qu'est-ce qui nous reste ?

De là, ça filtre :

Les solutions qui utilisent une base de données, parce que soit je dois la gérer (donc ça me coûte en ressources personnelles de l'ordre de la charge de travail), soit je dois en prendre une gérée par un fournisseur (donc ça me coûte en ressources personnelles de type financières) ;
Les solutions qui utilisent un langage interprété, comme PHP/Ruby/Python, parce que ça rajoute une dépendance lourd (on notera que je prône la conteneurisation donc la gestion peut être simplifiée, mais ça reste du CPU et de la RAM à consommer pour peu de choses).

Il reste donc :

Les générateurs de sites statiques, ça reste un peu de travail mais beaucoup moins (et rappelons que j'ai un déjà serveur pour un autre site statique donc ce sera mutualisé) ;
Les solutions hébergées qui utilisent un CMS open source comme plateforme.

Bref, j'ai choisi un générateur de site statique. Et comme il faut en choisir un seul alors qu'il y en a plétore, j'utilise Zola car il correspond à mes critères et pour d'autres raisons qui nécessiteraient presque un nouvel article.

Maintenant, l'hébergement

Tout ça c'est chouette et en sautant quelques étapes, admettons que j'ai maintenant mes fichiers HTML et CSS qui sont générés, comment je les déploie et comment je les sers ?

Déjà, je réutilise le serveur que j'ai cité plus haut et qui me coûte presque rien (ce n'est pas de la radinerie, c'est du bon sens).

En terme de logiciels, j'ai besoin d'un simple serveur HTTP qui permet de délivrer des fichiers statiques. Je dois aussi pouvoir configurer le HTTPS dessus : on est en 2024, ça fait presque dix ans qu'on peut avoir des certificats gratuits avec Let's Encrypt donc il est inconcevable de ne pas mettre en place du HTTPS (si vous voyez un site qui ne propose toujours pas du HTTPS, fuyez ne serait-ce que pour le principe, mais je m'égare).

Ça tombe bien, j'ai fait le choix de la simplicité sur la machine virtuelle que j'ai déjà : on y trouve Debian et Podman. Et grâce à un conteneur lancé par ce dernier, Caddy tourne en dernière version.

Caddy, c'est un serveur HTTP à la configuration très simpliste et lisible, qui intègre l'automatisation de la gestion des certificats HTTPS avec le protocole ACME (en utilisant Let's Encrypt par défaut). Il fait donc tout le travail dont j'ai besoin. Et pour prouver que c'est facile, voici la base de mon Caddyfile, le fichier de configuration de Caddy :

1 # redirection permanente de ces deux domaines vers le domaine principal
2 candy.pm, www.candy.pm {
3  redir https://sam.candy.pm{uri} permanent
4 }
5 
6 # le fameux domaine pricinpal
7 sam.candy.pm {
8  encode zstd gzip # activation de la compression du contenu envoyé en HTTP
9  root * /var/www/sam.candy.pm # chemin du dossier qui contient les fichiers statiques
10  file_server # quand un chemin fini par /, on tente index.html
11 }

Sans aucune indication spécifique, Caddy va tenter de générer les certificats HTTPS pour tous les domaines listés automatiquement. Fini le certbot ou autre (qui ne donnait pas un travail fastidieux mais il fallait configurer le serveur HTTP, tout ça… Bref, il fallait faire des choses et j'ai horreur de faire des choses ) !

De manière un peu plus complète, j'y ai ajouté la gestion du cache et des pages d'erreurs :

1 # les règles de caches : 90 jours pour les polices d'écritures, 30 jours pour les images
2 (cache) {
3  @image {
4  path *.svg *.png *.jpg *.jpeg *.gif *.ico
5  }
6 
7  @font {
8  path *.ttf *.eot *.woff2
9  }
10 
11  header @font Cache-Control "public, no-transform, max-age=7776000"
12  header @image Cache-Control "public, no-transform, max-age=2592000"
13 }
14 
15 # la gestion des erreurs, il faut donc bien avoir un fichier 404.html et un 500.html
16 (errors_handling) {
17  handle_errors {
18  @404 {
19  expression {http.error.status_code} == 404
20  }
21 
22  @500 {
23  expression {http.error.status_code} == 500
24  }
25 
26  rewrite @404 /404.html
27  rewrite @500 /500.html
28 
29  file_server
30  }
31 }
32 
33 # redirection permanente de ces deux domaines vers le domaine principal
34 candy.pm, www.candy.pm {
35  redir https://sam.candy.pm{uri} permanent
36 }
37 
38 # le fameux domaine pricinpal
39 sam.candy.pm {
40  encode zstd gzip # activation de la compression du contenu envoyé en HTTP
41  root * /var/www/sam.candy.pm # chemin du dossier qui contient les fichiers statiques
42  file_server # quand un chemin fini par /, on tente index.html
43 }

Ce Caddyfile est dans un dépôt Git, le site Zola a son propre dépôt.

Et voilà, cet article est donc sur tous les écrans qui le désirent grâce à Zola, Debian, Podman et Caddy.

Pour plus tard

Actuellement, je gère tout ça avec une certaine flemme, parce que c'était un des objectifs principaux (pas d'avoir la flemme mais de composer avec). Sauf que je suis irrécupérable et que je sais qu'un jour, je changerai complètement ma manière d'héberger tout ça.

Pour l'instant, j'utilise un conteneur pour Caddy qui gère tous mes sites. Mais à terme j'espère avoir une architecture de qualité encore plus professionnelle :

Chaque site (actuellement deux) serait dans son propre conteneur ;
Les conteneurs ne feraient que lancer un zola build en premier « stage » et récupérer les fichiers résultants dans un deuxième stage, avec un simple serveur HTTP (sans HTTPS) comme commande par défaut ;
Du coup, le serveur frontal ne servirait plus des fichiers statiques mais aurait plutôt un rôle de proxy.

Jusque là, on pourrait trouver peu d'intérêt à cette évolution. Pour mieux comprendre, voici deux rappels : je n'aime pas maintenir les choses et là, je dois maintenir un serveur Debian ainsi que mettre à jour le conteneur de Caddy. Du coup, pour héberger des fichiers statiques je pourrais me contenter de Netlify ou équivalent.

Mais je n'aime pas trop ces plateformes, je ne saurais pas vraiment expliquer pourquoi, c'est peut-être simplement « pas mon genre ».

Je compte plutôt exploiter les connaissances que j'utilise professionnellement pour faire évoluer mon hébergement vers une solution d'orchestration de conteneurs avec un cluster Kubernetes auto-géré chez un fournisseur cloud français (certainement OVH ou Scaleway) dans lequel j'installerai la gateway Envoy avec cert-manager pour versionner le routage et automatiser le TLS. Oui, ça a l'air de faire « usine à gaz », pas très « low tech » (mais quand même « low maintenance » puisque le cluster serait infogéré). Pour couronner le tout, je ferais fonctionner Renovate pour automatiser la mise à jour des dépendances sus-citées.

Pour autant, c'est un projet qui n'a pas lieu d'être actuellement pour quelques raisons :

Le fonctionnement actuel me convient ;
Le coût de mon serveur actuel est dérisoire et ce serait dommage de payer plus cher ;
Tant que je n'ai pas de besoins au delà de l'hébergement de fichiers statiques, ça ne vaudra donc pas les efforts que ça me demanderait ni le coût.

Bref, c'est une ouverture que je regarde de loin pour l'instant et que j'approcherais quand j'aurais des besoins plus « importants » (le choix du futur conditionnel n'est pas anodin ici). En attendant, mon petit Caddy dans un conteneur m'est amplement suffisant (et je m'attache même un peu à lui).

Premier essai

2024-02-03T00:00:00+00:00

Voilà donc les premiers enregistrement de mes expériences musicales que j'ai recoupé et publié. Au total, c'est environ une heure de bruit que j'ai découpé à la hache pour proposer à peu près un quart d'heure ici (je m'attendais à plus de pertes que ça, et pourtant j'ai réduit certaines boucles ).

Allez, ça commence par un léger test sonore avec le didgeridoo.

Petit échauffement, qui fini sur un léger cafouillage.

Dans les deux extraits qui suivent, j'utilise la loopstation pour créer un rythme de base et je joue par dessus au didgeridoo.

Une première utilisation de la loopstation.

Encore de la loopstation, avec un style un peu « bizarre » (pas le genre de choses que j'écouterais mais apparemment le genre de choses que je produits intuitivement).

Petit interlude pour m'amuser.

Ensuite, j'ai tenté de faire des boucles d'abord avec du didgeridoo, sur lesquelles j'ai apposé mes rythmes. C'est un peu « chiant » de faire un rythme parfaitement continu sur la loopstation (je ne la maîtrise pas assez probablement) donc j'ai fait quelques petites corrections au montage pour ne pas avoir de « croisements » entre les boucles.

J'en ai profité pour mettre des fondus de fermeture (la vérité étant que je ne savais pas trop comment les finir donc le montage m'a permis de rattraper ).

Dans cet extrait, les décalages dans le rythme sont involontaires mais ont créé quelque chose que je trouvais finalement sympa.

Cette boucle est un peu hasardeuse, j'y ai testé un effet de la loopstation (ça descend la note d'entrée d'un octave) mais c'est un essai plutôt insatisfaisant et je trouve le résultat peu intéressant.

Par la suite, j'ai fait une boucle dans laquelle je pose d'abord un rythme en beatbox et ensuite je fais de même avec le didgeridoo. Puis sur la fin je rajoute de nouveau un peu de beatbox (j'espérais ainsi tester une superposition « alternée »).

La fin est un peu soudaine parce que je ne savais encore pas comment finir. Je dois vraiment apprendre à clôturer ce que je fais !

Et j'ai fini par tenter d'enchaîner les choses, c'est un peu n'importe quoi (surtout à la fin) mais je dois avouer que je trouve certaines parties du morceau assez intéressantes !

Je ne sais pas comment on nomme ce style de musique mais je me demande si des artistes produisent et vendent ça de manière professionnelle, c'est intéressant.

De ces premières expérimentations, je conclus qu'il serait sympa de jouer avec deux ou trois didgeridoos de notes différentes. Ça tombe bien, j'ai commandé un « La » !

Aussi, je pense que j'aimerais essayer une stomp box pour me passer de la loopstation par moment. D'ailleurs, cette dernière est vite limitée avec ses deux pistes, toutefois les modèles avec plus de pistes sont bien plus onéreux et généralement plus complexe (l'idéal serait une Boss RC-505 pour garder les habitudes mais à 500€ ça fait cher pour mon niveau actuel).

Enfin, il faut aussi que j'apprenne à mieux utiliser le logiciel de montage, mais ça c'est un autre problème !

J'espère recommencer l'expérience bientôt mais le montage prend du temps, ça attendra donc un peu que j'avance sur certains travaux à la maison.

1	terraform {
2	required_version = ">= 1.6"
3
4	required_providers {
5	oci = {
6	source = "oracle/oci"
7	# J'utilise Renovate pour mettre à jour automatiquement la version, d'où le fait que j'utilise une version précise.
8	version = "5.36.0"
9	}
10	}
11	}
12
13	# Ces valeurs me permettent d'avoir une petite cohérence dans mes ressources quand je vais voir sur l'interface d'Oracle Cloud Infrastructure.
14	locals {
15	app_name = "example-application"
16	environment = "development"
17
18	resource_name = "${app_name}-${environment}"
19	tags = {
20	"name" = local.app_name,
21	"environment" = local.environment,
22	}
23	}
24
25	# On doit fournir une IP déjà créée pour que les nœuds aient accès à internet, c'est dommage mais pourquoi pas.
26	resource "oci_core_public_ip" "example" {
27	compartment_id = var.oracle_compartment_ocid
28
29	display_name = local.resource_name
30	freeform_tags = local.tags
31
32	lifetime = "RESERVED"
33	}
34
35	module "example" {
36	depends_on = [resource.oci_core_public_ip.example]
37
38	source = "oracle-terraform-modules/oke/oci"
39	# Comme pour le provider, le module sera mis à jour automatiquement par Renovate.
40	version = "5.1.4"
41	providers = {
42	oci.home = oci
43	}
44
45	compartment_id = var.oracle_compartment_ocid
46	home_region = "eu-paris-1"
47	region = "eu-paris-1"
48
49	# Je n'ai aucune honte : tout se nommera pareil et aura les mêmes tags.
50	vcn_name = local.resource_name
51	cluster_name = local.resource_name
52	freeform_tags = {
53	bastion = local.tags,
54	cluster = local.tags,
55	iam = local.tags,
56	network = local.tags,
57	operator = local.tags,
58	persistent_volume = local.tags,
59	service_lb = local.tags,
60	workers = local.tags,
61	}
62
63	# Le label DNS permet d'avoir des noms DNS « propres » pour les nœuds dans leur réseau, en vrai ça m'est complètement inutile mais je le renseigne pour le principe.
64	vcn_dns_label = "example"
65
66	# L'operator est une machine qui permet de gérer le cluster avec kubectl et Helm depuis le réseau du cloud, je ne souhaite pas faire ça.
67	create_operator = false
68
69	# De la meme manière, le bastion permet de se SSH dans les nœuds directement depuis le réseau du cloud, ce qui ne m'intéresse pas.
70	create_bastion = false
71
72	# Je souhaite accéder au cluster depuis mon PC local, donc le control plane doit être publique, avec une IP assignée.
73	control_plane_is_public = true
74	assign_public_ip_to_control_plane = true
75	# Ce paramètre n'est pas compatible IPv6 donc j'ai mis seulement mon IPv4, avec un `/32` à la fin pour qu'elle soit vue comme un bloc CIDR.
76	# Donc je ne peux accéder au control plane que depuis chez moi.
77	# Il est possible de mettre `["0.0.0.0/0"]` mais quand même, la sécurité…
78	control_plane_allowed_cidrs = var.kubernetes_control_plane_allowed_cidrs
79
80	# Voilà donc l'IP publique pour que les nœuds et les pods puissent accéder à internet.
81	nat_gateway_public_ip_id = resource.oci_core_public_ip.example.id
82
83	# Attention à bien rester à jour !
84	# Je n'ai as trouvé de système d'auto-upgrade de Kubernetes chez Oracle Cloud Infrastructure, dommage.
85	# Chez les autres fournisseur, c'est généralement disponible donc on indique seulement la version globale qu'on veut, par exemple `v1.29`, et une fenêtre de maintenance qui fait que le fournisseur cloud patche les nœuds quand il le faut.
86	kubernetes_version = "v1.29.1"
87
88	# Ce sont les valeurs par défaut, pour le coup je suis plutôt Debian qu'autre chose coté serveur mais je me dis que quitte à être chez Oracle, autant utiliser leur OS qui est probablement optimisé pour les machines virtuelles fournies.
89	worker_image_os = "Oracle Linux"
90	worker_image_os_version = "8"
91
92	worker_pools = {
93	"${local.resource_name}-main" = {
94	# Il faut préciser que le groupe de nœuds doit être créé, pourquoi pas hein !
95	create = true
96
97	# Je commence doucement avec deux nœuds.
98	size = 2
99
100	# J'utilise des machines basées sur un processeur Ampere 1.
101	shape = "VM.Standard.A1.Flex"
102	# Je rappelle qu'un OCPU vaut « au moins » deux CPU virtuels.
103	ocpus = 1
104	# La RAM est en gigaoctets.
105	memory = 6
106	# Le volume de démarrage est en gigaoctets et 50Go est sa taille minimale requise (j'ai essayé moins, l'APi a retourné une erreur indiquant que 50Go est le minimum).
107	boot_volume_size = 50 # this is the minimum
108
109	# Je ne veux pas que deux nœuds soient indisponibles en même temps.
110	node_cycling_enabled = true
111	node_cycling_max_surge = 0
112	node_cycling_max_unavailable = 1
113	}
114	}
115	}
116
117	# Voilà comment on récupère un fichier kubeconfig avec accès publique.
118	data "oci_containerengine_cluster_kube_config" "kube_config" {
119	depends_on = [module.example]
120
121	cluster_id = module.example.cluster_id
122	endpoint = "PUBLIC_ENDPOINT"
123	}
124
125	# Et voilà comment on l'enregistre dans un coin.
126	resource "local_file" "kube_config" {
127	depends_on = [data.oci_containerengine_cluster_kube_config.kube_config]
128
129	content = data.oci_containerengine_cluster_kube_config.kube_config.content
130	filename = "${abspath(path.root)}/kubeconfig.yaml"
131	}

1	users:
2	- name: user-[REDACTED]
3	user:
4	exec:
5	apiVersion: client.authentication.k8s.io/v1beta1
6	command: oci
7	args:
8	- ce
9	- cluster
10	- generate-token
11	- --cluster-id
12	- [REDACTED]
13	- --region
14	- eu-paris-1

1	:root {
2	--color-background: white;
3	--color-foreground: black;
4	--color-accent: blue;
5	}
6
7	body {
8	background-color: var(--color-background);
9	color: var(--color-foreground);
10	}
11
12	h1, h2, h3, h4, h5, h5, strong {
13	color: var(--color-accent);
14	}

1	:root {
2	--color-light-background: white;
3	--color-light-foreground: black;
4	--color-light-accent: blue;
5
6	--color-dark-background: black;
7	--color-dark-foreground: white;
8	--color-dark-accent: red;
9
10	--color-background: var(--color-light-background);
11	--color-foreground: var(--color-light-foreground);
12	--color-accent: var(--color-light-accent);
13	}
14
15	body {
16	background-color: var(--color-background);
17	color: var(--color-foreground);
18	}
19
20	h1, h2, h3, h4, h5, h5, strong {
21	color: var(--color-accent);
22	}

1	<input type="checkbox" id="theme-switch-state">
2	<label for="theme-switch-state">SWITCH</label>
3
4	<div id="content"><!-- … --></div>

1	/* L'input est caché, on clique sur le label qui est très personnalisable */
2	#theme-switch-state {
3	display: none;
4	}
5
6	#content {
7	--color-light-background: white;
8	--color-light-foreground: black;
9	--color-light-accent: blue;
10
11	--color-dark-background: black;
12	--color-dark-foreground: white;
13	--color-dark-accent: red;
14
15	--color-background: var(--color-light-background);
16	--color-foreground: var(--color-light-foreground);
17	--color-accent: var(--color-light-accent);
18	}
19
20	@media (prefers-color-scheme: dark) {
21	#content {
22	--color-background: var(--color-dark-background);
23	--color-foreground: var(--color-dark-foreground);
24	--color-accent: var(--color-dark-accent);
25	}
26	}
27
28	#theme-switch-state:checked ~ #content {
29	--color-background: var(--color-dark-background);
30	--color-foreground: var(--color-dark-foreground);
31	--color-accent: var(--color-dark-accent);
32	}
33
34	@media (prefers-color-scheme: dark) {
35	#theme-switch-state:checked ~ #content {
36	--color-background: var(--color-light-background);
37	--color-foreground: var(--color-light-foreground);
38	--color-accent: var(--color-light-accent);
39	}
40	}

1	const localStorageThemeSwitchKey = 'theme-switch-state'; // la clé qu'on utilisera dans l'object storage
2	const themeState = document.getElementById('theme-switch-state'); // l'élément <input> qui contient notre état
3
4	themeState.addEventListener('change', () => {
5	if (themeState.checked) {
6	window.localStorage.setItem(localStorageThemeSwitchKey, 'checked');
7	} else {
8	window.localStorage.removeItem(localStorageThemeSwitchKey);
9	}
10	});

1	if (window.localStorage.getItem(localStorageThemeSwitchKey) !== null) {
2	themeState.checked = true; // c'est presque trop facile mais ça marche vraiment
3	}

1	// Ce script est chargé juste après la balise `<input type="checkbox" id="theme-switch-state">`
2	(function() {
3	const localStorageThemeSwitchKey = 'theme-switch-state';
4	const themeState = document.getElementById('theme-switch-state');
5
6	/**
7	* On pourrait faire ça sur un window.onload ou mieux, un window.addEventListener('load'),
8	* toutefois je souhaite que le thème soit appliqué au plus tôt donc je le fais de manière synchrone.
9	*/
10	if (window.localStorage.getItem(localStorageThemeSwitchKey) !== null) {
11	themeState.checked = true;
12	}
13
14	themeState.addEventListener('change', () => {
15	if (themeState.checked) {
16	window.localStorage.setItem(localStorageThemeSwitchKey, 'checked');
17	} else {
18	window.localStorage.removeItem(localStorageThemeSwitchKey);
19	}
20	});
21	})();

1	# redirection permanente de ces deux domaines vers le domaine principal
2	candy.pm, www.candy.pm {
3	redir https://sam.candy.pm{uri} permanent
4	}
5
6	# le fameux domaine pricinpal
7	sam.candy.pm {
8	encode zstd gzip # activation de la compression du contenu envoyé en HTTP
9	root * /var/www/sam.candy.pm # chemin du dossier qui contient les fichiers statiques
10	file_server # quand un chemin fini par /, on tente index.html
11	}

1	# les règles de caches : 90 jours pour les polices d'écritures, 30 jours pour les images
2	(cache) {
3	@image {
4	path .svg .png .jpg .jpeg .gif .ico
5	}
6
7	@font {
8	path .ttf .eot *.woff2
9	}
10
11	header @font Cache-Control "public, no-transform, max-age=7776000"
12	header @image Cache-Control "public, no-transform, max-age=2592000"
13	}
14
15	# la gestion des erreurs, il faut donc bien avoir un fichier 404.html et un 500.html
16	(errors_handling) {
17	handle_errors {
18	@404 {
19	expression {http.error.status_code} == 404
20	}
21
22	@500 {
23	expression {http.error.status_code} == 500
24	}
25
26	rewrite @404 /404.html
27	rewrite @500 /500.html
28
29	file_server
30	}
31	}
32
33	# redirection permanente de ces deux domaines vers le domaine principal
34	candy.pm, www.candy.pm {
35	redir https://sam.candy.pm{uri} permanent
36	}
37
38	# le fameux domaine pricinpal
39	sam.candy.pm {
40	encode zstd gzip # activation de la compression du contenu envoyé en HTTP
41	root * /var/www/sam.candy.pm # chemin du dossier qui contient les fichiers statiques
42	file_server # quand un chemin fini par /, on tente index.html
43	}

Sam Candy

Le cluster Kubernetes gratuit, c'est fini !

Un petit retour sur les mises à jour de Kubernetes

Pourquoi je supprime mon cluster

Une suite ?

"Homelab", un serveur à la maison : introduction

Avant-propos

Historique

Les besoins

Domotique

Contacts et calendriers

SSO

Galerie photos

Mes contraintes

Mises à jours automatiques (ou presque)

Kubernetes

Consommation et silence

Stockage

Et la suite ?

Nouveau didgeridoo

Instrument et matériel utilisés

Formats et qualité des fichiers

Comment va mon cluster Kubernetes gratuit ?

Avis sur Oracle Cloud

L'interface web

Gratuit, vraiment ?

Les limitations découvertes

Puissance disponible

Resources des pods

Nombre de machines virtuelles

Volumes

Conclusion

Un cluster Kubernetes gratuit ?

Mon besoin

À propos d'Oracle

Mise en place

Quelques concepts sur Oracle Cloud Infrastructure

Configurer le cluster Kubernetes

Démarrer le cluster

Accéder au cluster avec kubectl

Utilisation

Consommation de base

Installation

Conclusion

Amélioration du trépied de mon didgeridoo : partie 1

Où trouver un trépied pour didgeridoo

Anatomie de mon trépied avant les modifications

Améliorations souhaitées

Dans le vif du sujet

Le plan

Outils et matériaux

Le résultat et les futurs changements

Switch de thème sans JavaScript

L'objectif

Implémentation étape par étape

Un thème selon la préférence du navigateur

Thème par défaut

Ajout d'un switch en pur HTML/CSS : solution habituelle

Ajout d'un switch en pur HTML/CSS : solution « miracle »

Sauvegarde de l'état

Avantages et inconvénients

Blog low tech et low maintenance

Choix de la plateforme

Dis, comment on crée un blog ? 🤔

Mes critères

Qu'est-ce qui nous reste ?

Maintenant, l'hébergement

Pour plus tard

Premier essai

Instrument et matériel utilisés

Formats et qualité des fichiers

Dis, comment on crée un blog ?