Beerus blog

Fix le "joycon drift" de ma switch

Beerus Inc. — Thu, 08 Sep 2022 00:00:00 GMT

Contexte

C'est fait ! J'ai enfin eu le fameux joycon drift sur les deux joycons de ma switch. Pour rappel ce qu'est le joycon drit voir ici.
Cela ne m'empêche pas réellement de jouer mais cela reste très pénible voir même parfois handicapant dans certains jeux, j'ai donc commencé à réfléchir à changer ou réparer mes joycons.

Outils

Forcément c'est un problème rencontré par tous les utilisateurs de la switch à un moment donné donc il existe une foison de tutoriels/vidéos sur internet.
Ce qui ressorti des ressources que j'ai pu consultées c'est qu'il me fallait deux tournevis spécifiques :

Y00 Triwing Screwdriver
PH000 Phillips Screwdriver

Au début je voulais prendre uniquement ces deux tournevis et utiliser une feuille de papier cartonnée (type business card) qui est censée être placée juste en dessous du joycon. Mais j'ai eu du mal à trouver ces deux tournevis seuls (hors site chinois type Aliexpress par lesquels je ne veux pas passer...)
Je suis donc parti sur ce pack à 20 CAD soit environ 15€ ! Peut-être un peu cher mais là il y a tout dedans :

Y00 Triwing Screwdriver
PH000 Phillips Screwdriver
4 joysticks neufs
Un tweezer
Un "Plastic crowbar" (pas trouvé le nom en français)
De la visserie en tout genre (ressort boutons L/R, Slider Lock, vis etc...)
De la cosmétique pour les joycons

Réparation

Ok maintenant qu'on est équipé il s'agit de passer à la pratique ! Pour cela il faut bien distinguer le joycon droit du gauche car ils sont montés différemment.
Je pense qu'il faut compter environ 30min pour les deux joycons pour être large.

Joycon droit

On va tout d'abord enlever les 4 vis entourées sur la photo ci-dessous :

Une fois les 4 vis enlevées, passer le "plastic crowbar" dans la fente qui vient d'apparaître suite aux vis enlevées :

Il suffit ensuite de délicatement ouvrir le joycon et en voici le contenu :

On peut remarquer que les deux parties sont reliées avec des câbles plats flexibles. Maintenant il faut retirer la batterie, légèrement pousser à l'endroit entouré en rouge.

Afin de donner ça :

A partir de ce point il va falloir enlever les 5 vis entourées pour pouvoir retirer le cache de la batterie :

C'est ici que la partie la plus technique va s'opérer. Il va falloir dans un premier temps retirer les 3 câbles plats entourés par un carré rouge. Pour faire cela il faut réaliser les deux tâches suivantes :

Relever le petit ergot noir (ou gris pour le carré n°1)
Avec les doigts ou le tweezer délicatement retirer le câble

Puis retirer les deux vis entourées ce qui va libérer le joycon et vous pourrez mettre à sa place un des nouveaux joycon.

Et voilà ! Il "suffit" de faire toutes les opérations précédentes à l'envers et ainsi remonter le joycon. Attention pour mettre le câble plat je recommande vivement d'utiliser le tweezer afin d'être plus précis :

Pas besoin d'enfoncer jusqu'au bout, une fois réenfoncé il faut descendre l'ergot en plastique relevé précédemment.

NB : Il n'est pas impossible que le bouton L/R vienne à s'échapper (à droite sur la photo ci-dessus), il faut le reclipser avant de remonter la coque qui a été enlevée lors de la première étape.

Joycon gauche

Le joycon gauche est légèrement différent du droit. En voici les différences :

Retirer les 3 vis entourées ci-dessus. Une fois le cache de la batterie enlevé voilà ce que ça donne :

Retirer les deux câbles plats entourés ci-dessus puis les deux vis entourées. Et voilà !

Conclusion

Rien de bien compliqué dans ce changement de sticks sur les joycons, il faut juste être minutieux et bien équipé !

Redondance "du pauvre" d'un site personnel

Beerus Inc. — Thu, 18 Aug 2022 00:00:00 GMT

Contexte

Mon serveur hébergé a des petits soucis en ce moment, il a tendance à planter régulièrement malgré le fait que je le supervise activement.
J'ai très longtemps pensé que c'était l'un de mes containers docker qui s'emballait (malgré le fait qu'il y ait des options de runtime de paramétrées) mais il s'avère que c'est le metrics scraper d'OVH installé qui posait problème !
Bref avant de résoudre le problème, mes services hébergés ne répondaient plus de temps en temps et cela reste tout de même très embêtant. Il a donc fallu que je pense à une potentielle redondance !

Etude des solutions

Il fallait donc que je trouve une solution pour avoir les sites les plus importants toujours en fonction en cas de défaillance majeure de mon serveur dédié le temps que je trouve une solution à long terme. Pour simplifier la problématique je ne souhaite basculer qu'un seul site pour le moment car il est consulté fréquemment pour des raisons professionnelles, les autres n'ont pas d'importance cruciale.

J'ai les équipements suivants avec moi :

Une IP publique dédiée d'OVH
Un serveur hébergé chez OVH
Un micro serveur avec des ressources équivalentes de celle d'OVH chez moi
La fibre et une IP publique dynamique (celle de ma box)

Voici les quelques techniques auxquelles j'ai pensé en premier lieu :

Backup, Replica
Cluster
Solution de fail over

La solution backup/réplica a tout de suite été écartée du fait qu'elle ne soit pas du tout flexible. Je fais déjà du backup de mon serveur vers chez moi mais c'est cela concerne plus la conf de mon dockerfile et les datas de certains containers mais rien qui ne me permet de remonter une infra en 10min automatiquement (surtout pour une solution censée rester temporaire).
Pour le cluster ça serait la solution idéale, dans mon cas passer sous Docker Swarm ou encore mieux tout migrer sous K8s/K3s. Le problème est que je veux une solution rapide à mettre en place ne necessitant pas une refonte complète de mon infra. D'autant plus que je n'ai pas du tout réfléchi à la conception de ma future infra et comment cela est géré avec une IP publique dynamique.
La dernière proposition est surement la plus adaptée pour moi, trouver une solution de failover simple et efficace avec le moins d'intervention humaine sans toucher à la configuration déjà en place.

Une fois choisie il a fallu que je compare les solutions avec les contraintes suivantes :

Une bascule faite en 5 minutes max en cas de problème.
L'ensemble des données doivent être identique et synchronisé (si modification d'un fichier html réplication immédiate sur le backup).
Rapide et simple à mettre en place, pas de service payant etc...

Après un moment de réflexion voici le workflow imaginé :

Le détail des flux serait donc le suivant :

Problème sur la production (serveur OVH) qui rend le site web indisponible
Un script sur le serveur backup vérifie régulièrement la disponibilité du site web
Le script constate l'indisponibilité et via les API OVH change l'IP publique du site en question en la faisant pointer sur le serveur de backup lui-même
Avec un TTL assez faible (60), l'utilisateur devrait avoir accès au site web via le backup

Il reste le sujet de la synchronisation des données, solutions possibles :

Un montage sur le dossier du site web en question
Un rsync depuis le backup vers la prod à une fréquence régulière
Un rsync depuis la prod vers le backup dès qu'un fichier est modifié

J'ai passé pas mal de temps sur ces solutions car elles ont toutes leurs problèmes :

Montage : Aucun intérêt car si la prod plante je n'ai plus de montage et donc plus de donnée, il faut forcément une copie. Je peux toujours par la suite via un cron faire une copie régulière des données en local mais aucun intérêt par rapport aux autres solutions.
Rsync depuis le backup : Pas trop fan de créer des accès sur mon serveur de prod même si c'est du rsync via clé SSH sur un user non root. Mais surtout comment je détecte qu'un fichier a changé ou été créé ? Seule la prod peut avoir ses infos. J'ai tout de même essayé de créer un montage sshfs avec une surveillance du dossier via l'outil inotify mais cela ne marche pas du tout ensemble, inotify fonctionne avec un système de fichier local.
Rsync depuis la prod : Dernière solution, celle-ci parait la plus "faisable" la prod surveillant ses fichiers via inotify ou un autre outil et rsync en cas de changement. Par contre avec l'IP dynamique je suis toujours "bloqué" car à chaque redémarrage de ma box je change d'IP. J'ai donc dû faire appel à un service type DynDNS, ma box ne gérant que DynDNS ou NoIP j'ai choisi ce dernier qui a une version freemium (il faut valider manuellement le domaine tous les mois sinon 5€/mois...)

Mise en place

J'ai 4 parties à mettre en place :

Le script de vérification de la disponibilité du site web.
Le script de changement du DNS.
L'outil qui va permettre la synchro des données de la prod vers le backup.
Des petits scripts annexes pour alerter en cas de défaillance de la prod/backup.

Toute la partie scripting va être condensée dans un seul et même script

Partie scripting

from urllib.request import urlopen, Request
from urllib.error import HTTPError, URLError
import sys
import time
import requests
import dns.resolver
import ovh

new_ip = requests.get('https://api.ipify.org').content.decode('utf8') #Dynamic public IP
domain = "beerus.fr"
site_name = "<the_website_to_monitor>"
ifttt_event = "<event_ifttt_name>" #See https://ifttt.com
ifttt_key = "<event_ifttt_key>" #See https://ifttt.com
ovh_secret = "<ovh_secret>" #See https://docs.ovh.com/ca/fr/api/first-steps-with-ovh-api/
ovh_key = "<ovh_key>" #See https://docs.ovh.com/ca/fr/api/first-steps-with-ovh-api/
ovh_consumer = "<ovh_consumer>" #See https://docs.ovh.com/ca/fr/api/first-steps-with-ovh-api/

# setting the URL you want to monitor
URL = Request("https://{0}.{1}".format(site_name, domain),
              headers={'User-Agent': 'Mozilla/5.0'})
i = 0

#Verify status of the DNS
result = dns.resolver.query(site_name, 'A')
for ipval in result:
    if ipval.to_text() == new_ip:
        print("Already switched")
        sys.exit(0)

#The site is answering ?
while i < 10:
    time.sleep(5)
    print(URL.full_url)
    try:
        response = urlopen(URL, timeout=2)
    except (HTTPError, URLError) as error:
        i = i+1
        continue
    if response.status == 200:
        print("Prod is okay")
        break
    i = i+1

#The website is down so we can switch and alert
if i == 10:
    response = requests.post('https://maker.ifttt.com/trigger/{0}/with/key/{1}'.format(ifttt_event, ifttt_key))
    client = ovh.Client(
        endpoint='ovh-eu',
        application_key=ovh_key,
        application_secret=ovh_secret,
        consumer_key=ovh_consumer,
    )

    result = client.put(
        '/domain/zone/{0}/record/5206233547'.format(domain),
        subDomain=site_name,
        target=new_ip,
        ttl=60,
    )

    result = client.post('/domain/zone/{0}/refresh'.format(domain))

Le script ci-dessus a été passé en cron sur le serveur backup et est exécuté toutes les 10 minutes.
Il exécute les actions suivantes :

Vérification du DNS (le site a-t-il déjà basculé ?)
Curl vers le site en question, 10 tests avec un intervalle de 5s
Si down bascule vers le backup via les API d'OVH
Notification (on verra ça dans une autre partie)

Synchronisation données

Pour la synchro j'avais dans un premier temps pensé à inotify avec rsync.
Il aurait suffi de lancer le binaire (via systemd dans l'idéal) et dès lors qu'il aurait remarqué un event qui match avec les options précisées (create, delete, move etc...) il effectuerait un rsync.
Le problème étant que cela nécessite pas mal de bricolage (script, création d'un systemd etc...) et j'aurais aimé en éviter le plus possible. Heureusement je suis tombé sur l'outil lsyncd qui fait exactement ce travail, pas besoin de réinventer la roue ! En plus il peut se baser sur rsync pour faire ses actions ce qui est parfait pour moi. J'ai fait deux configurations :

Une pour le webroot de mon site, en cas de modification/ajout/suppression lsyncd exécute un rsync immédiatement vers mon backup
Une pour le dossier des certificats de mon site web, étant donné que je suis sous LetsEncrypt les certificats sont renouvelés régulièrement. De la même façon dès qu'il y a une modification de ceux-ci (le certificat public à priori) il copie le nouveau certificat sur le backup

Tous cela est parfait mais il me manque encore la partie SSH pure car mon serveur backup est hébergé chez moi derrière ma box. J'utilise déjà le port 22 pour d'autres usages donc il va falloir faire de la configuration additionnelle.
J'avais deux possibilités :

Je fais un NAT sur un port différent du 22 (du style IP_PUB:2222 --> backup:22)
Je fais un bastion SSH avec un hardenning et qui forward mes requêtes vers mon backup

J'ai décidé de faire la deuxième solution, ça permet de s'entrainer sur quelque chose que je n'ai pas l'habitude de faire 🙂. Je passe la partie hardenning car ce n'est pas ce que j'ai envie d'aborder dans ce post mais ça consiste à faire les choses suivantes (non exhaustives) :

Fail2ban
No PermitRoot
Authentification par clé uniquement
Un Jail chroot avec un nombre de binaire limité (adios su et sudo 😈)

Par rapport au bastion, 3 solutions pour faire ce jump :

Stockage des clés SSH sur le bastion
Forwarding SSH agent
Utiliser ProxyCommand/ProxyJump

Stockage des clés SSH sur le bastion: Cela signifie que le bastion possède la clé SSH privée de mon serveur backup, étant donné qu'il reste public cela est toujours dangereux. On met cette idée de côté pour l'instant.
Forwarding SSH agent: On passe nos clés privées à un agent SSH puis on forward cet agent sur notre bastion. L'agent SSH étant une socket Unix (lié à la variable $SSH_AUTH_SOCK) le jump host va pointer vers notre agent local au lieu de pointer sur le sien. Mais il suffit d'être root sur le bastion pour faire pointer sa variable $SSH_AUTH_SOCK sur notre socket et accéder au backup. Pas terrible niveau sécu également.
ProxyCommand/ProxyJump: La meilleure solution, le serveur intermédiaire (le bastion) exécute une ProxyCommand lors de la connexion et forward l'input et l'output vers le backup. Il suffit pour cela d'utiliser l'option -J du binaire SSH.
Ex : ssh -J username@bastion username@backup. Le seul problème de cette solution c'est que si je veux préciser une clé SSH privée la commande ne peut pas deviner si cela s'applique au bastion ou au backup. Je suis donc passé via la config SSH :

Host bastion
    User linux
    HostName bastion.domain.tld
    IdentityFile ~/.ssh/bastion_rsa

Host backup #Pas besoin d'être accessible depuis internet donc
    User backup
    HostName backup.domain.lan
    IdentityFile ~/.ssh/backup_rsa
    ProxyJump bastion.domain.tld

Et lorsque je fais un simple ssh backup (après recopie des clés publiques sur les bons serveurs) la magie opère ! Petit test de modification d'un fichier ça fonctionne bien, le fichier modifié est bien propagé sur le backup 🙂

Notifications

Dernier point : le fignolage ! Il s'agit désormais de m'avertir en cas de défaillance de la prod OU du backup (on ne sait jamais lui aussi il peut planter !).
Pour le backup je fais presque que la même chose que le script ci-dessus, j'ai des curl qui interroge régulièrement le nom DynDNS pointant vers mon site web (j'ai configuré mon reverse proxy Nginx pour répondre au vrai nom de mon site web et au nom DynDNS). En cas de défaillance je reçois un mail sur ma boite perso @beerus.fr.

Par contre pour la prod c'est plus complexe (et plus important aussi). En fait je pourrais faire le même mécanisme que pour le backup mais je ne recevrai jamais le mail @beerus.fr car mon serveur mail est hébergé sur la même machine que mon site web...
J'ai commencé à regarder pour pouvoir utiliser les API de Gmail mais très honnetement ça ne me tentait pas trop.
Donc à la place j'ai utilisé le service IFTTT, j'ai trouvé le concept tellement simple et efficace. Une application Android (ou Apple) à télécharger ensuite "programmer" son alerte :

Comme on peut le voir ci-dessus en cas de réception d'un webhook on envoie une notification push à l'application IFTTT reliée au compte.
J'ai juste eu à ajouter la commande curl à mon script ci-dessus et le tour était joué, ça marche parfaitement ! Très peu d'infos sont également transmise à ce service tiers (surement une ip publique et peut-être des infos négligables concernant mon téléphone) ça reste acceptable de mon côté, le businness plan consiste à proposer des version premium qui permettent de développer son propre algo ou avoir plus d'event.

Conclusion

Une grosse journée de travail pour concevoir, mettre en place et peaufiner. J'espérais pas mettre plus de temps et c'est chose faite. J'ai une solution, certes bricolée, mais fonctionnelle et facile. Il me reste tout de même une partie manuelle : en cas de défaillance de la prod et de bascule sur le backup, je dois manuellement refaire pointer le DNS vers la prod (bien que j'utilise un script pour ça). La solution n'est de toute façon mise en place que temporairement le temps que je réfléchisse à une nouvelle architecture qui sera bien plus robuste et pensée en amont.
Cela reste malgré tout un très bon exercice, très proche du système ça toujours fait du bien de remettre les mains dans le cambouis 🙂

Retour d'expérience sur la certification CKA

Beerus Inc. — Thu, 11 Aug 2022 00:00:00 GMT

Mon entreprise a pu cette année me financer la Certified Kubernetes Administrator (CKA), obtenue avec succès il y a quelques jours c'est l'occasion pour moi de faire un petit retour d'expérience !

Contexte

Tout d'abord il faut savoir qu'il n'existe que 4 certifications Kubernetes officielles :

Kubernetes and Cloud Native Associate (KCNA)
Certified Kubernetes Application Developer (CKAD)
Certified Kubernetes Administrator (CKA)
Certified Kubernetes Security Specialist (CKS)

Celle qui correspond le plus à mon profil et ce que je sais faire est la CKA. Elle coûte environ 400$ et possède les avantages suivants :

Un certain nombre de ressources sur Kubernetes (rien d'exceptionnel)
Deux examens blancs (identiques cependant) pour se préparer
Des accès à des plateformes d'entrainement et de scénario divers
L'accès à certification en elle-même

Afin d'obtenir la certification il "suffit" d'avoir 66% de réponse correcte le jour de l'examen.
Les réponses ne sont pas de type QCM mais plus en mode TP, il faut "réaliser" l'exercice sur un environnement Kubernetes.
L'examen se décompose de la façon suivante :

Storage 10%
Troubleshooting 30%
Workloads & Scheduling 15%
Cluster Architecture, Installation & Configuration 25%
Services & Networking 20%

Se préparer

Etant donné que je n'ai jamais eu de réelle expérience professionnelle de Kubernetes je n'ai pas pris cette certification à la légère, j'ai acheté deux formations sur Udemy pour préparer cet examen :

Certified Kubernetes Administrator (CKA) with Practice Tests (~13€)
Kubernetes for the Absolute Beginners (~13€)

Ces formations comprennent :

Les cours en vidéo de 3 à 20 minutes chacune
Des résumés PDF des chapitres étudiés (honnêtement pas terrible les PDF)
Accès à une plateforme d'entrainement scénarisée selon les chapitres
Quelques examens blancs (ne représente pas les conditions de l'examen cependant)

Franchement je n'attendais pas grand-chose de ces formations notamment par rapport au prix investi mais j'ai vraiment été agréablement surpris ! (Comme quoi ne pas juger une formation en fonction du prix).
Par contre si j'avais su je n'aurais peut-être pas pris la formation "Kubernetes for the Absolute Beginners" qui est reprise en entier ou presque dans la formation "Certified Kubernetes Administrator (CKA) with Practice Tests".

Pour ceux qui ne veulent pas débourser de l'argent pour cela je conseille les vidéos de Xavki sur YouTube dans la playlist Kubernetes. Elle ne prépare pas en tant que tel pour la certification mais ses vidéos sont vraiment de qualité et vont plus loin que le périmètre de la certification.

Ensuite je conseille les liens suivants qui m'ont été utile pour fignoler ma préparation :

https://kubernetes.io/docs : fait partie des rares sites autorisés le jour de l'examen, je conseille de bien s'approprier le site afin de perdre le moins de temps possible le jour J.
https://docs.linuxfoundation.org/tc-docs/certification/tips-cka-and-ckad : concerne les détails pratique de l'examen (comment cela se passe, la plateforme utilisé etc...)
https://github.com/StenlyTU/K8s-training-official : un repo d'exercices en lien avec les topics CKA

Je conseille plus que vivement d'utiliser la plateforme d'examen blanc fourni par le site killer.sh
Elle propose des conditions d'examen identiques et permet donc d'avoir une première approche de ce qu'il sera proposé le jour J.
Personnellement je n'ai eu que 75/125 soit seulement 60% donc en dessous des 66% demandé. MAIS :

Les questions sont plus difficiles que celles du vrai examen
Elles sont également plus nombreuses (25 au lieu de 17) pour le même temps (2h)

En lisant quelques sub reddit je me suis rendu compte que je n'étais pas seul dans ce cas et que 75pts restait finalement un bon score.

Enfin voici quelques conseils que j'ai pu trouver ici et là sur internet.
Ajouter des variables bash pour aller plus vite :

export do="--dry-run=client -o yaml"
export now="--force --grace-period 0"

Ces deux variables peuvent être ajoutées à la fin des commandes kubectl pour créer un fichier ou supprimer un pod plus rapidement.
Ex: kubectl run nginx --image nginx $do > pod.yml

Bien étudier ce workflow qui détaille comment troubleshoot une partie des ressources K8S, cela représente 30% de la note tout de même :

L'examen en lui même

Une fois qu'une date sera choisie il faudra respecter les conditions suivantes le jour J :

Avoir une webcam (externe ou interne)
Avoir une pièce d'identité non expirée (permis de conduire, passeport, CNI etc...)
Être dans une pièce isolée où être seul et au calme

Bien vérifier également que la webcam puisse filmer la pièce d'identité distinctement (c'est très important !).

Il faut se connecter jusqu'à 30min avant, une fois cela fait il sera possible de télécharger un logiciel qui fera office de plateforme d'examen (attention 300Mo dans mon cas).
Une fois téléchargé et installé il faudra prendre une photo de soi-même via la webcam et une photo de notre pièce d'identité, cela enclenchera la vérification par un instructeur.
La vérification dans mon cas n'a pas duré très longtemps, cela effectué l'instructeur demandera de filmer la pièce afin de vérifier que tout est ok et qu'il n'y a rien d'interdit à proximité.
Dans mon cas on m'a demandé de poser mon téléphone dans le champ de la caméra mais hors de portée et d'enlever le plastique de ma bouteille d'eau ! Lorsque toutes ces vérifications sont terminées on peut enfin commencer l'examen ! Comme vu précédemment l'environnement est exactement le même que killer.sh mais en plus simple.
A part un ou deux écueils je n'ai pas trouvé l'examen très complexe.

On obtient le résultat au bout de 24h max, pour moi j'ai réussi à l'obtenir avec 83% donc ça passe 🙂

Conclusion

Je doutais un peu que la certification m'apporte réellement quelque chose mais finalement afin de l'obtenir je me suis vraiment investi et cela m'a apporté des connaissances théoriques sur la techno.
Cela me donne un véritable vernis de base lorsqu'il sera question de Kubernetes.

Ceci dit cela ne remplacera jamais l'expérience "sur le terrain" selon moi et la certification ne vient qu'en complément. J'ai donc hâte de pouvoir mettre en pratique les connaissances acquises ! 🤞

Déployer son infra K3S sur Proxmox en mode IaC

Beerus Inc. — Tue, 19 Jul 2022 00:00:00 GMT

Architecture

Je suis en train de préparer la Certified Kubernetes Administrator (CKA) et il me faudrait un lab pour m'exercer. J'ai pas mal fait de Kubernetes classique en lab via des formations Udemy et j'aimerai tester autre chose mais toujours sur une base K8S. Je me suis penché sur K3S de Rancher. Il dispose de plusieurs qualités qui me semble intéressantes :

Il est léger et plus rapide que K8s
Il peut s'exécuter sur du plus petit matériel (proc ARM par ex 🥰). J'ai comme projet potentiel de faire un cluster de raspberry donc K3S est plus qu'indiqué.
Il ne dispose pas de tous les connecteurs cloud mais vu que ça sera du "on premise" dans mon cas c'est parfait.
Plein de petits avantages : + facile et rapide à déployer, moins de surface d'attaque, facile à update etc...

Par contre il ne fait pas tourner docker nativement mais containerd (bien que j'ai vu un projet passer s'appelant k3d qui intègre docker), ça sera l'occasion d'apprendre autre chose surtout que le CRI (Container Runtime Interface) en soi n'est pas le plus important.

Une fois mon choix d'orchestrateur choisi je me suis dit que j'allais installer mon cluster K3s sur mon lab maison qui exécute un Proxmox et tant qu'à faire autant avoir un workflow de déploiement un peu évolué pour s'exercer.

Parmi toutes les ressources que j'ai pu voir le workflow qui me semblait au départ le plus intéressant faisait les choses suivantes :

Récupération de l'ISO Ubuntu 20 sur Proxmox
Création du template Proxmox "à la main" via des commandes qm (cli proxmox)
Configuration de cloud init via l'onglet promox dédié
Création des VM via Terraform
Ansible pour déployer K3s sur mes nouvelles VM

Cela paraissait sympa sur le papier et puis ça permettait de mettre en application les quelques connaissances Terraform dont je disposais. Mais à bien réfléchir il y avait quand même deux problèmes dans ce process :

Une partie manuelle qui cassait un peu l'automatisation voulue. Si je pouvais automatiser cela je serais vraiment dans un cas d'IaC (Infra As Code)
Pas très flexible car si je veux customiser mon template ça sera à la main aussi ou à la limite via script bash

C'est là que je suis tombé sur un autre outil d'Hashicorp qui fait tout ce travail manuel pour moi et dispose de la flexibilité voulue : Packer !

Voici les deux workflows qui sont ressortis au final :

Création du template --> Cloud init --> Terraform --> Ansible --> K3S
Packer (+Cloud init) --> Terraform --> Ansible --> K3S

J'ai donc choisi le deuxième worflow
Avantages :

Infra as code - Full automatisée
Pas d'interaction directe avec Proxmox, seulement via son API
Peut donc être piloté depuis une machine tierce

⚠️ Inconvénients :

Nécessite plus de développement et de temps pour un résultat équivalent dans mon cas (installation d'un potentiel DHCP, création du fichier de conf packer etc...)
Temps d'exécution de création du template plus long

Retrouver l'ensemble du projet sur ce git : https://github.com/ramuskay/k3s-proxmox-terraform-ansible-packer

Packer

Je vais donc utiliser packer pour packager mon image Ubuntu 20.04 avec quelques packages et confs additionnelles. Il suffit d'installer packer puis nous verrons les fichiers de configuration.
D'ailleurs dans mon cas pas besoin de DHCP, celui de ma box avec ma VM template en mode bridge sera largement suffisant.
Voici mon arborescence packer pour la config :

├── http
│   ├── meta-data
│   └── user-data
├── ubuntu20.pkr.hcl
└── variables.pkr.hcl

Les fichiers de conf peuvent être en json ou HCL (format hashicorp), j'ai choisi HCL à la place de JSON pour deux raisons :

Langage commun avec tous les outils HashiCorp (vu qu'on va aussi utiliser Terraform ça a du sens)
Plus "fonctionnel", on peut par exemple mettre des commentaires (dans JSON non ça fera toujours partie de la data)

On a donc 2 fichiers hcl concernant :

variables.pkr.hcl : la définition des variables par défaut
ubuntu20.pkr.hcl : la définition du job packer

Regardons plus en détail ubuntu20.pkr.hcl :

source "proxmox" "template" {
  proxmox_url = "${var.proxmox_hostname}/api2/json"
  username = var.proxmox_username
  password = var.proxmox_password
  node = var.proxmox_node_name
  insecure_skip_tls_verify = var.proxmox_insecure_skip_tls_verify
  network_adapters {
    bridge = "vmbr0"
  }
  disks {
    type = "scsi"
    disk_size = "20G"
    storage_pool = var.vm_storage_pool
    storage_pool_type = "lvm"
  }
  #iso_file = "local:iso/ubuntu-20.04.4-live-server-amd64.iso"
  iso_url               = var.iso_url
  iso_storage_pool      = var.iso_storage_pool
  iso_checksum          = var.iso_checksum
  unmount_iso = true
  boot_wait = "5s"
  memory = var.vm_memory
  sockets   = var.vm_sockets
  cores     = var.vm_cores
  template_name = var.vm_name
  vm_id     = var.vm_id
  http_directory = var.http_directory
  cloud_init = true
  cloud_init_storage_pool = var.iso_storage_pool
  boot_command = [
    "<esc><wait><esc><wait><f6><wait><esc><wait>",
    "<bs><bs><bs><bs><bs>",
    "autoinstall ds=nocloud-net;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/ ",
    "--- <enter>"
  ]
  ssh_username = var.username
  ssh_password = var.user_password
  ssh_timeout = "20m"
}

build {
  sources = [
    "source.proxmox.template"
  ]
  provisioner "shell" {
    inline = [
      "sudo rm -f /etc/cloud/cloud.cfg.d/99-installer.cfg",
      "sudo rm -f /etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg",
      "sudo cloud-init clean"
    ]
  }
}

Rien de bien compliqué là-dedans c'est aussi l'avantage en général des outils Hashicorp la configuration est très descriptive et donc compréhensible rapidement. On va renseigner les informations suivantes :

Des credentials pour le proxmox
Un peu de hardware pour le template (RAM, CPU, Disk etc...)
Une config pour le template (ID, nom, boot command , ssh cred etc...)
Un dossier pour la conf subiquity
On active cloud-init car sinon on ne peut pas set les IP via Terraform
On tweak un peu l'image car on veut qu'elle soit cloud-init ready

Justement concernant autoinstall depuis la version 20.04 preseed a été délaissé au profit de subiquity qui est (de mon point de vue) bien plus facile à utiliser car format yaml et s'intègre très bien avec Packer. Ce qui donne deux fichiers :

meta-data : requis. Utilisé par le cloud vu qu'on déploit en local on le laisse vide
user-data : l'équivalent du preseed, utilise autoinstall

Le fichier user-data en détail :

#cloud-config
autoinstall:
  version: 1
  locale: en_US
  keyboard:
    layout: fr
  ssh:
    install-server: true
    allow-pw: true
  packages:
    - qemu-guest-agent
  user-data:
    users:
        - name: canadium
          passwd: $6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0
          groups: [adm, cdrom, dip, plugdev, sudo]
          lock-passwd: false
          sudo: ALL=(ALL) NOPASSWD:ALL
          shell: /bin/bash
          ssh_authorized_keys:
            - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJEXrwiuUOCpWPvwOsGuF4K+aq1ufToGMi4ra/1omOZb

Fichier de configuration ultra basique, on définit un seul user et deux confs pour le système. Les autres options peuvent être trouvées dans la doc
⚠️ Ce fichier est "templatiser" et redéfini via Terraform voir plus bas

On peut ensuite exécuter packer via Terraform pour avoir une seule et même exécution
Ce qui nous donne un template de qualité !

Terraform

Il faut maintenant déployer notre template sous forme de VM, on va utiliser Terraform pour qui sera notre outil principal. Tout passera par Terraform :

La création de fichier de conf pour Packer, Ansible et Terraform
L'exécution de Packer
L'exécution de Terraform bien sûr
L'exécution d'Ansible

On installe Terraform puis on s'attaque aux fichiers de configuration :

├── main.tf
├── output.tf
├── provider.tf
├── terraform.tfvars
└── variables.tf

Listons les fichiers Terraform :

main.tf : On décrit notre déploiement, le fichier de job.
output.tf : La sortie voulue lors de l'exécution de Terraform apply (on va print les IP ici)
provider.tf : On précise quel provider on utilise, ici proxmox. (voir doc)
terraform.tfvars : la définition des variables pour le main.tf (même principe que Packer)
variables.tf : la définition des variables par défaut (même principe que Packer)

Et on a des fichiers de template qui vont nous permettre de définir notre inventory ansible, groups_vars ansible, user-data de autoinstall etc...

Je vais juste décrire le fichier main.tf car les autres sont plutôt évident. On définit les variables pour l'exécution future de packer :

locals {
  template_folder = "${path.module}/${var.folder_packer}/${var.distrib_folder}"
  packer_cfg = {
    PKR_VAR_proxmox_hostname  = var.pm_host
    PKR_VAR_proxmox_username  = var.pm_user
    PKR_VAR_proxmox_password  = var.pm_password
    PKR_VAR_proxmox_node_name = var.pm_node_name
    PKR_VAR_proxmox_insecure_skip_tls_verify = var.pm_tls_insecure

    PKR_VAR_vm_id                 = var.vm_id
    PKR_VAR_vm_name               = var.vm_name
    PKR_VAR_vm_storage_pool       = var.vm_storage_pool
    PKR_VAR_vm_cores              = var.vm_cores
    PKR_VAR_vm_memory             = var.vm_memory
    PKR_VAR_vm_sockets            = var.vm_sockets

    PKR_VAR_iso_url             = var.iso_url
    PKR_VAR_iso_storage_pool    = var.iso_storage_pool
    PKR_VAR_iso_checksum        = var.iso_checksum

    PKR_VAR_http_directory      = var.http_directory

    PKR_VAR_username              = var.username
    PKR_VAR_user_password         = var.user_password
  }
}

Ici justement on définit le job packer avec l'ensemble des paramètres souhaités (au final c'est une exécution shell classique).
J'ai ajouté un petit sleep car parfois le template n'était pas prêt pour l'exécution Terraform. Également un script python pour supprimer le template créé par Packer (pas de ressource native donc obligé de "hack") :

resource "null_resource" "packer_build" {
    provisioner "local-exec" {
    working_dir = local.template_folder
    command     = "packer build . && sleep 30"
    environment = local.packer_cfg
  }
  provisioner "local-exec" {
    when  = destroy
    command = "${path.module}/scripts/delete_template.py"
    interpreter = ["python"]
    working_dir = path.module
    environment = merge(yamldecode(self.triggers.packer_cfg))
  }
    triggers = {
    packer_cfg = yamlencode(local.packer_cfg)
  }
  depends_on = [
    local_file.user-data
  ]
}

On redéfinit un master K3S par-dessus notre template (var.tamplate_vm_name), on remarque qu'on doit préciser une dépendance pour que les tâches s'exécutent dans le bon ordre. A noter aussi un script sh qui vérifiera que le déploiement cloud-init est bien fini sur le serveur :

resource "proxmox_vm_qemu" "proxmox_vm_master" {
  count       = var.num_k3s_masters
  name        = "k3s-master-${count.index}"
  target_node = var.pm_node_name
  clone       = var.template_vm_name
  os_type     = "cloud-init"
  agent       = 1
  memory      = var.num_k3s_masters_mem
  cores       = var.num_k3s_masters_cpu

  ipconfig0 = "ip=${var.master_ips[count.index]}/${var.networkrange},gw=${var.gateway}"

  lifecycle {
    ignore_changes = [
      ciuser,
      sshkeys,
      disk,
      desc,
      network
    ]
  }

  connection {
    type = "ssh"
    user = var.username
    password = var.user_password
    host = var.worker_ips[count.index]
  }

  provisioner "file" {
    source      = "${path.module}/scripts/wait-cloud-init.sh"
    destination = "/tmp/wait-cloud-init.sh"
  }

  provisioner "remote-exec" {
    inline = [
      "chmod +x /tmp/wait-cloud-init.sh",
      "/tmp/wait-cloud-init.sh",
    ]
  }
  depends_on = [
    null_resource.packer_build
  ]
}

On fera la même tâche pour les workers

Et ici on définit nos tâches de customisation de conf, c'est à dire :

Générer des fichiers de configuration pour la future exécution d'ansible
Générer le user-data nécessaire à l'autoinstall de packer (on modifie essentiellement le user/password)

data "template_file" "cloud-init-user-data" {
    template = "${file("${path.module}/templates/user-data.tpl")}"
    vars = {
        SUDO_PASSWORD_HASH = "${var.user_password_hash}"
        SUDO_USERNAME = "${var.username}"
        SSH_PUBLIC_KEY = "${var.ssh_pub_key}"
    }
}
resource "local_file" "user-data" {
    content     = "${data.template_file.cloud-init-user-data.rendered}"
    filename = "${local.template_folder}/http/user-data"
}

data "template_file" "k8s" {
  template = file("./templates/k8s.tpl")
  vars = {
    k3s_master_ip = "${join("\n", [for instance in proxmox_vm_qemu.proxmox_vm_master : join("", [instance.default_ipv4_address, " ansible_ssh_private_key_file=", var.pvt_key])])}"
    k3s_node_ip   = "${join("\n", [for instance in proxmox_vm_qemu.proxmox_vm_workers : join("", [instance.default_ipv4_address, " ansible_ssh_private_key_file=", var.pvt_key])])}"
  }
}

resource "local_file" "k8s_file" {
  content  = data.template_file.k8s.rendered
  filename = "${path.module}/ansible/hosts"
}

data "template_file" "groups_vars_ansible" {
    template = "${file("${path.module}/templates/all.tpl")}"
    vars = {
        ANSIBLE_USER = "${var.username}"
        K3S_VERSION = "${var.k3s_version}"
    }
}

resource "local_file" "groups_vars_ansible" {
    content     = "${data.template_file.groups_vars_ansible.rendered}"
    filename = "${path.module}/ansible/group_vars/all.yml"
}

Et enfin le job ansible :

resource "null_resource" "ansible-playbook" {
  provisioner "local-exec" {
    command = "ansible-playbook -i ${var.inventory_file}  --private-key ${var.ssh_key_file} site.yml"
    working_dir = ".."
  }
  depends_on = [
    proxmox_vm_qemu.proxmox_vm_workers,
    proxmox_vm_qemu.proxmox_vm_master,
    local_file.k8s_file,
    local_file.var_file
  ]
}

Ansible

Le cluster K3S est déployer via ansible. En voici l'arborescence :

ansible/
├── ansible.cfg
├── group_vars
│   └── all.yml
├── playbook.yml
└── roles
    ├── download
    │   └── tasks
    │       └── main.yml
    ├── k3s
    │   ├── master
    │   │   ├── tasks
    │   │   │   └── main.yml
    │   │   └── templates
    │   │       ├── k3s.service.j2
    │   │       └── k3s.service.j2.withoutterafic
    │   └── node
    │       ├── tasks
    │       │   └── main.yml
    │       └── templates
    │           └── k3s.service.j2
    ├── postconfig
    │   └── localhost
    │       └── tasks
    │           └── main.yml
    ├── prereq
    │   ├── defaults
    │   │   └── main.yml
    │   ├── tasks
    │   │   └── main.yml
    │   └── templates
    │       └── resolv.conf.j2
    ├── raspberrypi
    │   ├── handlers
    │   │   └── main.yml
    │   └── tasks
    │       ├── main.yml
    │       └── prereq
    │           ├── CentOS.yml
    │           ├── Raspbian.yml
    │           ├── Ubuntu.yml
    │           └── default.yml

Voici les différents roles :

download : Télécharge la release de k3s
k3s : La configuration de k3s pour le master et les nodes (rien de bien compliqué)
postconfig : On configure kubeconfig et installe helm en local sur le server/workstation exécutant le job ansible
prereq : On installe les prérequis K3S (netfilter, ip forwarding etc...)
raspberrypi : Un job spécifique si on est sous Raspberry PI

A noter :

Le fichier de group vars all.yml est généré via Terraform à partir de variables
Le fichier ansible.cfg peut être configurer à votre convenance

Conclusion

On a donc créé un cluster K3s de 0 sans aucune interaction directe ou manuelle avec Proxmox, pas mal non ? En plus de cela tous est dynamique et flexible, il suffit de changer les conf 😉

Vous pouvez reprendre ce projet (qui lui-même est forké). Par rapport à son utilisation tout est expliqué dans le README et consiste principalement à changer des variables Terraform.

Malgré tous cela il y a pas mal d'axes d'améliorations et problèmes inhérents à la solution choisie :

On pourrait mettre les variables sensibles dans Vault (Outil Hashicorp) et un git qui à chaque push redéploit une image packer.
Il faudrait aussi créer les utilisateurs adaptés (Terraform & Packer) avec les bons droits, voir ressource Terraform par exemple.
Il faudrait que le job packer se termine au bon moment pour que le job Terraform ne se lance pas trop tôt (j'ai un sleep 30 pour l'instant)
Pas de provider packer natif donc on doit "tricher" pour supprimer le template
Terraform considère à un deuxième run que rien a changé et ne relance pas le job ansible (on peut tout de même le lancer à la main)

Bref il y a plein d'autres moyens de faire et d'améliorer ce pipeline, les outils HashiCorp sont quand même super pour cela !

Sources

https://www.aerialls.eu/posts/ubuntu-server-2004-image-packer-subiquity-for-proxmox/
https://tlhakhan.medium.com/ubuntu-server-20-04-autoinstall-2e5f772b655a
https://stackoverflow.com/questions/72567455/running-cloud-init-twice-via-packer-terraform-on-vmware-ubuntu-22-04-guest
https://salmonsec.com/blogs/home_lab_3#6-init-kubeadm-images-sh
https://github.com/blz-ea/proxmox-packer
https://medium.com/@ssnetanel/build-a-kubernetes-cluster-using-k3s-on-proxmox-via-ansible-and-terraform-c97c7974d4a5

Créer mon propre blog !

Beerus Inc. — Thu, 14 Jul 2022 00:00:00 GMT

Je cherchais une bonne solution pour monter mon propre blog. Au début j'ai forcément réfléchis à des CMS classique tel que :

Wordpress
Drupal
Grav etc...

Mais je désirais aussi avoir quelque chose de simple si possible et facile d'utilisation car contenu blogging (pas de difficulté particulière). Un CMS tel que wordpress nécessite une base de donnée que j'aimerai éviter au maximum mon site n'hébergeant que des pages statiques. Si on peut éviter le PHP aussi c'est pas mal :) (toujours source de faille de sécu entre autres choses).

C'est là que j'ai découvert JAMStack (JavaScript, APIs, and (HTML) Markup). Il build le site en amont et le met à disposition sur un CDN (ou n'importe quel hoster) et en fait donc un site composé de pages statique ! Cela correspond totalement à mon besoin, on ajoute à ça quelques feature cool :

Pas besoin de database
Surface d'attaque bien moins étendue, sécurité +++
Meilleur référencement
S’intègre super bien dans une pipeline CI/CD ou n'importe quel process d'automatisation (🤤)
Apparemment bien plus rapide qu'un CMS traditionnel (vu que c'est des pages statiques je veux bien le croire)

Plus d'infos ici : https://jamstack.org/

Le truc c'est que JAMStack n'embarque aucune techno par défaut c'est au développeur de choisir comment l'implémenter. Je cherchais vers quel générateur JAMStack j'allais choisir, il en existe plusieurs sur le marché :

Next.js
Jekyll
Gastby

Et je suis tombé sur le post de ce blog qui explique pourquoi et comment il est passé de Jekyll à Gatsby et son cas d'usage correspond totalement au mien (et j'adore le design de son blog !)

J'ai donc choisi les paramètres suivants :

Redaction du code en local sur VS-Studio code (j'ai les plugins preview markdown etc...)
Je push une fois fini sur un de mes projets github
Le push trigger un build GitHub action (workflow dans le projets) qui héberge mon blog sur GitHub Pages

Plusieurs avantages :

Mon blog est centralisé et versionné (une ancienne version de ce post décrivait l'ancienne façon d'héberger via GatsbyCloud héhé)
Les utilisateurs peuvent collaborer sur les articles en soumettant un PR (dans les faits un simple edit du post sur GitHub)
J'avais hésité à l'héberger sur l'infra maison mais vu que tout est déjà publique aucun problème à le faire héberger par un tiers
Tout passe par un seul hebergeur --> Github

Et quelques inconvénients:

Je repose sur ce tiers pour le build et l'exposition de mon blog (free version 25 build/jour)
Pas facile d'utilisation (même si sur ce cas là j'ai forké le projet de calvin)