Suggestions

Grafikart.fr
feedburner.com
Farid BEN SALEM YouTube channel
www.youtube.com
lunarviews YouTube channel
ptb.lunarviews.net
A l’encontre
alencontre.org
TesseracT YouTube channel
www.youtube.com

Do you enjoy using Feedbot ?

You can support its material needs and its development by participating financially via Liberapay.

Yet another homelab (again) Il y a quasiment 10 ans (à 1 mois près), je concevais et construisais mon propre “meuble” pour mon homelab de l’époque, composé de plusieurs cartes MicroATX et de matériel récupéré. Je m’étais inspiré de Ike-hackers (pour ceux qui ne connaissent pas les Ikea-hacks ou Ikeacks, je vous laisse chercher, ça vaut le coup) qui transformaient un meuble “Red helmer” en cluster de rendering 3D. Depuis, mon homelab a changé 45 fois (à peu près) et récemment, je me suis lancé dans un lab basé sur des dell micro, des tout petits desktops (il y en a aussi chez HP et Lenovo) qui consomment peu (donc peu puissants) et sont assez robustes :
L’article à ce sujet Crude but effective On ne va pas se mentir, trimballer ça dans un bac “Trofast” de chez Ikea, c’est quand même un peu bourrin. Mais faute de mieux c’était pas mal. Sauf que par les hasards de Twitter (octobre 2023), je suis tombé sur ça :
printables.com - SergeiBuilds - Mini Lab Rack For Dell Optiplex MFF Servers Un “rack” compact et propre pour ranger des dell micro ??? A faire en DIY ? Mais c’est trop bien !! Problème(s) Bon, sur le papier ça a l’air cool, mais il y a quand même plusieurs problèmes à régler. D’abord, le lien sur printables.com est assez peu détaillé. Les photos sont pas tops (on ne voit pas comment c’est monté), on sait juste qu’il faut imprimer des pièces (dont les modèles sont fournis) et qu’il faut monter ça dans un cadre en aluminium. The frame is assembled from 4x 200mm, 4x 300mm, 4x 400mm & 2x 360mm 2020 aluminium extrusion and held together with L corner brackets. The overall dimensions are 240mm wide, 400mm high & 340mm deep. D’abord: je n’ai pas d’imprimante 3D (et je n’y connais rien).
Lien du tweet On m’a conseillé plusieurs moyens de contournement. En acheter une (le plus simple xD), demander à un copain, passer dans un fablab, la faire imprimer sur Internet (ça coûte assez cher). (Finalement, j’ai trouvé une âme charitable pour me les imprimer au boulot, merci Fabien) Ensuite, comment on l’achète et on le monte ce fichu cadre en aluminium ? A force de recherches (décembre 2023), j’ai fini par trouver que les “2020 aluminium extrusion” s’appellent en bon français des “profilés aluminium 20x20”. On peut en trouver sur Amazon pré-coupés (c’est fort cher). Et même si on en prend des grands à recouper soi-même, j’avais un peu peur de la précision de coupe (même si je suis outillé). Heureusement, on a fini par me donner l’adresse d’un site industriel qui en vend à la découpe (motedis.fr). Profilé aluminium 20x20 Type B rainure 6 Pour assembler les profilés, il faut des équerres internes (L corner brackets, fallait deviner…). Heureusement on en trouve aussi chez Motedis, je suis tombé dessus par hasard en fouillant les vidéos du site ! Équerre interne 20 B-Type rainure 6 M5 Alternative Il en faut 20 (ce que ne dit pas ce cher SergeiBuilds, j’ai compté 3 fois pour être bien sûr). Une fois que vous avez pris ces deux trucs là, vous en avez déjà pour 60€ (dont 20€ de frais de port)… Il faut aussi des écrous à glisser dans les rails pour fixer nos pièces de PLA, ainsi que des vis M5. J’en ai compté 24 mais je ne les ai pas achetés (on y reviendra dans la section suivante). Et là, c’est le drame Je laisse passer décembre (trop occupé) et je commande tout ça (mi-janvier 2024) Au bout de quelques jours, ma commande Motedis est arrivée et j’étais comme un gosse à Noël. Mais je déchante très très vite…
Lien du tweet Les équerres ne rentrent pas dans le profilé. Un peu bourrin (oui je suis pas toujours très fin), je tape dessus au marteau. Sur les extrémités ça marche (bien). Au milieu, j’arrive à mettre le premier. Mais je casse les suivantes. Pourtant c’est bien du 2020 mon profilé 🤔… Bon, je ne vous fais pas mariner trop longtemps. La raison c’est que je n’ai pas pris le bon profilé 2020. Il existe 2 sortes, toutes les deux disponibles sur Motedis et j’ai pris la mauvaise : Grosso modo, j’ai pris par erreur les types I, qui ont une rainure “arrondie” de 5, alors que ceux qu’il fallait, c’était des types B, avec une rainure trapézoïdale de 6… A partir de là, 2 solutions : je rachète tout je m’adapte Ca m’ennuie de jeter de l’alu parce que j’ai été trop bête… J’ai donc décidé (5 février) de trouver des solutions, quitte à ce que le rendu soit moins “net”. J’ai donc remplacé l’usage des écrous+vis M5 par visser les parties imprimées. Clairement, le résultat me parait acceptable. Mais ne faites pas la même erreur que moi, car il sera impossible d’avoir un rendu parfait avec des vis plantées dans un rail alu. L’avantage des équerres et des écrous + vis M5, c’est que c’est repositionnable juste en desserrant / resserrant la vis. Le 13 février, j’ai reçu de la part de mon collègue les pièces imprimées en PLA. Premier problème : comme je dois les visser directement dans le rail alu (puisque je ne peux pas insérer d’écrous pour mes vis M5) je ne peux pas les positionner correctement. Même en faisant de mon mieux, j’ai parfois des petits “jours” d’un 1/2 millimètre. Deuxième problème : je ne peux pas non plus visser la cage pour le switch, car je ne pourrais pas passer un tournevis. Je laisse ce problème de côté dans un premier temps. Troisième problème, je n’ai pas vérifié, mais mon switch est trop épais. Je découpe donc à la Dremel (content de l’avoir même si elle sert pas souvent) et à la pince perroquet mon bout de PLA. Petite surprise (évidente) : le PLA, ça fond 😅. J’arrive quand même à tout assembler et à obtenir un résultat correct. C’est fonctionnel, ça reste joli malgré quelques imprécisions, et c’est assez pratique à l’usage. La suite ? Après avoir posté ça sur Twitter et à quelques copains, on m’a donné quelques idées d’améliorations, qui serviront pour une V2 : Remplacer le passe câble Ethernet du haut et la cage pour le switch en dessous par un support caché pour un switch 8 ports. Il n’y a vraiment de raison fonctionnelle à ce que les ports soient visibles et 5 ports c’est trop limité. Pourquoi pas acheter un managé tant qu’à y être. En profiter pour ajouter un étage de plus (dell micro ? Raspberry pi ?) Remplacer la multiprise (en prendre une connectée ?) et trouver un moyen de la fixer proprement sur les rails Trouver un moyen de fixer les alims pour qu’elles ne pendouillent pas Ajouter un pikvm (cher++ !) pour se passer du mini écran ? A voir Éventuellement couvrir une partie des côtés avec du plexi ? A voir Pour l’instant je ne vais rien faire, car je suis content du résultat (et un peu fatigué de tout ces rebondissements !). Mais on verra après un peu d’usage ce que je fais / ne fais pas :) En attendant, have fun !
Read more
Introduction Si vous me suivez sur les réseaux sociaux, vous avez peut-être vu que j’étais pour la deuxième fois au FOSDEM (Free and Open Source Software Developers’ European Meeting). Note: comme l’an dernier, mon employeur a payé le voyage pour moi et une quinzaine de collègues. Merci à lui. Contrairement à l’an dernier par contre, cette année, j’étais speaker ! J’ai refait (en anglais) mon talk sur GoReleaser. J’étais un peu stressé car je suis relativement débutant en Golang, surtout par rapport au niveau de la room. The state of Go lien de la session La première conférence que je suis allé voir est “The State of Go”. C’est un “must” au FOSDEM et beaucoup de monde me l’a conseillé et effectivement, j’ai passé un très bon moment : Maartje a beaucoup d’humour. Je n’avais pas spécialement suivi les nouveautés du langage en 1.21 (et la future 1.22) mais j’ai été content de voir qu’il y a pas mal de nouvelles fonctions built-in assez utiles, notamment les fonctions sur les maps et les slices (rendues possibles grâces aux generics). Le changement qui m’a le plus marqué est le changement du scope de la variable d’itération dans les boucles for. Évidemment, il y a aussi pas mal d’amélioration côté WASM ;-) (“c’est le turfu!” dirait un copain). External Rook Ceph Cluster lien de la session J’avais prévu d’aller voir ce talk ensuite et j’ai été un peu court en temps pour aller du bâtiment Ud jusqu’à K… Je regarderai le replay et mettrai à jour l’article. Point positif, pas mal de gens m’ont arrêté en voyant mon GopherBadge. C’est un bon moyen d’engager la discussion ;-P. Incus lien de la session Je suis assez fan de LXC et LXD depuis un moment (j’ai écris plusieurs articles sur le sujet, certains sont dans mes brouillons aussi). Mais si vous lisez mes “rants” sur ce blog, vous savez que Canonical a fait un “move” pour refermer reprendre la main sur LXD en le retirant de la fondation LinuxContainer. L’auteur du talk donne un peu plus de détail sur ce qui s’est passé (je n’avais pas tous les détails) mais c’était encore un peu plus rude que je pensais. Stephane Graber nous a présenté l’outil, et fait une petite démo de l’outil. A titre perso, je suis toujours fan, mais clairement l’outil va moins loin que d’autres solutions de virtualisation + containérisation (Proxmox ? Kubernetes ?). Je pense que c’est un bon fit pour un homelab comme le miens, voire des workloads de prod plutôt simple. Dans les points qui me paraissent manquants : les sauvegardes (il n’y a que des snapshots). Les choix techniques sont bons, (Ceph pour le stockage distribué, OVN pour le SDN, support d’OIDC). La CLI est agréable et permet de gérer plusieurs clusters en même temps. Kubernetes Operators: Expanding Automation in Containerized Applications lien de la session Ce talk réalisé par Edith est aussi une introduction aux concepts de Kubernetes. La seconde partie est dédiée à l’explication des concepts d’opérateurs, avec un exemple simple permettant aux débutants de bien comprendre. Déjeuner Étant un peu stressé, je voulais avoir bien le temps de manger. Nous avons donc fait une queue interminable pour un burger pas terrible (et même pas de frites). Un peu frustré, je me suis rattrapé sur le club maté, qui me redonné la patate :D. Pour être serein, je me suis posé dans la devroom go au milieu du talk “How we almost secured our projects by writing more” mais je pense que j’ai manqué de contexte pour bien tout comprendre (ça parle de tests, de strace et d’eBPF, je pense qu’il faut être concentré). Dependency injection: a different way lien de la session Dylan Reimerink, ingénieur chez Isovalent nous a fait un retour d’expérience sur les injections de dépendances dans un projet d’envergure en go. J’ai pris peu de notes (concentré sur mon talk) mais j’ai quand même bien aimé l’explication de sa solution pour résoudre les problématiques d’injection de dépendance dans un projet complexe. Putting an end to makefiles in Go projects with GoReleaser lien de la session Ma session. Ayant vu le niveau globalement élevé de la devroom go, j’étais nécessairement un peu inquiet du retour que j’aurais, étant un débutant dans le domaine (comparativement). Dans l’ensemble, le talk (et surtout la démo) s’est bien passé. J’ai eu un petit glitch lors du docker build que j’ai subtilement esquivé et j’ai pu montrer ce que j’avais à montrer. Avec le stress, j’ai fini 5 minutes trop tôt, ce qui a laissé 10 minutes de questions donc je suis forcément un poil frustré par ça (mon côté perfectionniste ?), mais je pense que les gens ont apprécié et finalement c’est bien ça l’essentiel. Une fois le talk terminé, j’ai pris une “gaufre de la victoire” (de toute façon c’était l’heure du goûter) et un deuxième club maté (l’équivalent de 2.5 cafés dans chaque bouteille, je crois). Bare-Metal Networking For Everyone lien de la session Reboosté, je suis allé dans la salle Cloud & Virtualisation. Mateusz Kowalski, Principal engineer chez Redhat a fait un talk sur les difficultés à déployer des cluster Kubernetes sur des serveurs baremetal (surtout on-prem). Évidemment, ce genre de discours me parle forcément. Il a parlé de plusieurs exemples de corner cases un peu tordus dans lesquels les layouts réseau “opinionated” de kubeadm ou kubespray ne sont pas utilisables (IPv6 dualstack, ranges chelous, …). J’ai bien aimé ce talk mais je reste un peu frustré car je n’ai pas compris dans quel “produit” ils avaient du développer les features dont il nous a parlé. Instant Ramen: Quick and easy multi-cluster Kubernetes development on your laptop lien de la session J’ai trouvé le titre de cette session un peu déceptif. Je m’attendais à nouvelle façon de déployer des clusters Kubernetes sur un laptop. En fait, il s’agissait plutôt d’une présentation d’un tool appelé RamenDR, qui, comme son nom l’indique, permet de faire du disaster recovery sur des clusters Kubernetes, notamment avec Kubevirt. FOSDEM Saturday Night Fever Une fois nos talks terminés, je suis allé voir un copain puis nous sommes allé directement aux bars. ERREUR ! Il n’y a pas à manger dans tous les bars (obviously?). Après une pinte de delirium, avec la fatigue et à jeun j’étais HS. Heureusement nous sommes aller diner ensuite, puis nous avons déambulé dans les rues de Bruxelles. Dimanche ! Après une bonne nuit de sommeil, retour à l’ULB pour quelques talks de plus ! Après une bonne gaufre, c’est reparti pour un tour :). 20 years of Open Source building XWiki and Cryptpad lien de la session Je me suis levé “tôt” exprès pour aller voir Ludovic parler de la façon dont il a réussi à faire tourner une entreprise avec un produit open source (XWiki dans un premier temps, puis Cryptpad en plus à partir de 2016). J’ai la façon qu’a Ludovic de voir l’open source. Contrairement au modèle open core (une partie du produit est open source, le reste closed source), Ludovic croit en un modèle d’Open source payant (l’open source, ce n’est pas gratuit), soit bien le support, soit en faisait payer le produit, mais en gardant tout open source. Open source is not free!
Focus on the product! Involve the team.
“Open core tends to push you to do more proprietary” J’adore cette philosophie et Ludovic a su nous expliquer les pièges et les difficultés de ce genre d’entreprises. You too could have make curl! lien de la session Un très bon talk de Daniel Steinberg, avec beaucoup de conseils et de bons sens pour créer de bon logiciels (open sources). Quelques exemples : Keep having fun
Success requires time and attention
Learn to use the time you get / spare time is a luxury
Own your mistakes / Learn, adapt, add more tests
People are more difficult than code Je ne vais évidemment pas tout lister. Écrit comme ça, ça parait évidement / enfoncer des portes ouvertes. Mais en réalité, le talk est impossible à transcrire, Daniel est passionnant à écouter. Si le sujet vous intéresse, je vous invite donc à aller écouter le replay. Je laisse juste cette capture d’écran d’un email reçu par Daniel en 2021 (il avait fait un article là dessus si vous voulez en savoir plus)… Rires dans la salle. Moi, quand j’ai vu la réaction de Daniel en relisant le titre, je n’ai pas ri. Les gens ne se rendent pas compte de la violence d’internet. Je ne suis pas sûr d’être capable d’encaisser ça, à sa place… Introducing ‘Refiners’ – A Micro-Framework for Seamless Integration of Adapters in Neural Networks Pour finir, je suis allé voir le talk de la boite d’un copain qui bosse dans le domaine de l’AI depuis bien avant que ce soit hype. Son entreprise actuelle a créé un micro-framework permettant d’adapter des modèles existants, pour les rendre plus performants (sans ré-entrainement complet donc) à des cas d’usages bien précis à moindre coût (adapters). Ne travaillant pas dans ce domaine, j’avoue ne pas avoir d’avis sur le framework en lui même, mais les explications étaient très claires et je ne me suis pas senti perdu. This is the end Pour être parfaitement honnête, je n’avais pas l’énergie pour aller dans la room observability, même s’il y avait certainement de bons talks qui auraient pu m’intéresser. J’ai donc décider de retourner à Bruxelles un peu plus tôt pour aller chercher quelques souvenir (et accessoirement, écrire cet article). J’ai passé un très bon moment au FOSDEM et à Bruxelles, rencontré plein de gens (merci le GopherBadge), “miggled” avec de très chouettes communautés que je ne croise habituellement pas. Quelques photos en vrac de ce week-end
Read more
Suite de la migration Fin décembre, j’ai migré ce blog sur Clever Cloud. Cependant, David Legrand m’a fait remarquer que je n’avais plus de méthode pour planifier mes posts. Depuis quelque temps, je poste à flux tendu donc ça ne m’a pas encore gêné (j’écris un post, je le rends public dans la foulée) mais c’est vrai qu’il me manque cette possibilité par rapport à précédent mon hébergement (une VM). Cependant, il existe une solution sur Clever Cloud pour le faire. David en a d’ailleurs écrit un petit article sur son blog perso, adapté pour “Astro” son générateur de site statique. Je vais donc faire pareil pour mon propre blog avec Hugo. Adaptations Repartons donc d’où j’en étais au post précédent. Nous avons un blog avec Hugo qui se déploie quand on fait des clever deploy (ou des commits sur le git remote de clever). La première chose qu’on va devoir faire, c’est récupérer un token. En effet, c’est notre blog qui va déclencher de lui même les redéploiements, on va donc devoir lui donner de quoi s’authentifier. Si vous n’avez pas de token sous la main, on peut en retrouver un en faisant clever login depuis un terminal, comme je l’expliquais dans l’article précédent. Et on va rajouter le TOKEN dans la liste des variables d’environnement de notre app : $ clever env set CC_SECRET "aaaaaaaaaaaaaaaaaaaaaaaaaa" $ clever env set CC_TOKEN "aaaaaaaaaaaaaaaaaaaaaaaaaa" A partir de là on va créer plusieurs fichiers. D’abord, un script qui va déclencher ce fameux redéploiement : cat > clever_rebuild.sh << EOF #!/bin/bash -l clever link ${APP_ID} clever restart --quiet --without-cache EOF chmod +x clever_rebuild.sh Ensuite, je vais créer un fichier qui sera lu par clever-cloud et qui va déclencher ce redéploiement aux heures où je publie mes posts planifiés (le matin, un peu avant 9h) : mkdir clevercloud echo '["00 08 * * * $ROOT/clever_rebuild.sh"]' > clevercloud/cron.json Attention aux petites blaguounettes de timezone. Comme tous sysadmins qui se respectent, les gens de clever utilisent le temps UTC sur leurs serveurs (moi aussi). Cependant, ça nécessite une petite gymnastique intellectuelle si jamais vous n’utilisez pas aussi le temps UTC dans votre tête pour planifier les posts ;-P. Si tout se passe bien, vous verrez qu’il remarque qu’il y a un cron dans les logs : [...] 2024-01-25T14:05:21+01:00 Importing cronjobs 2024-01-25T14:05:21+01:00 Starting crons setup [...] 2024-01-25T14:06:05+01:00 (CRON) INFO (running with inotify support) 2024-01-25T14:06:05+01:00 (CRON) INFO (RANDOM_DELAY will be scaled with factor 89% if used.) 2024-01-25T14:06:05+01:00 (CRON) STARTUP (1.7.0) [...] Tout dernier point que j’ai éludé jusqu’à présent, il est possible de redémarrer une application à partir d’un cache (pour que ça aille plus vite). Cependant, il est nécessaire d’indiquer à clever cloud quoi mettre dans ce cache. On va donc ajouter “/clevercloud/cron.json:/clever_rebuild.sh” à la variable existante : # précédemment CC_OVERRIDE_BUILDCACHE "/public" $ clever env set CC_OVERRIDE_BUILDCACHE "/public:/clevercloud/cron.json:/clever_rebuild.sh" (Fail to) hack the template Si Hugo a bien un flag pour permettre de “builder” les posts dont la date de sortie est postérieure à la date actuelle (buildFuture), mon thème “Stack” les affiche par défaut dans la liste des derniers posts ainsi que dans le flux RSS. La solution la plus simple à ce problème est de laisser les paramètres par défaut, et d’attendre que la date de publication soit dépassée (idéalement juste avant le passage d’un cron) et le tour est joué. Mais David a eu une autre approche qui m’a bien plu : ajouter une condition dans le template pour que le post ne soit pas visible dans la liste des posts, mais quand même publié. Avantage : on peut consulter l’article à paraître, si on a le lien. Il se rajoute à la liste des articles de la homepage de lui-même lors du prochain rebuild, une fois la date dépassée. Dans mon thème, la page d’accueil qui liste les posts est définie ici dans le code : {{ define "main" }} {{ $pages := where .Site.RegularPages "Type" "in" .Site.Params.mainSections }} {{ $notHidden := where .Site.RegularPages "Params.hidden" "!=" true }} + {{ $notFuture := where .Site.RegularPages ".Date" "le" now }} + {{ $filtered := ($pages | intersect $notHidden | intersect $notFuture) }} - {{ $filtered := ($pages | intersect $notHidden) }} {{ $pag := .Paginate ($filtered) }}
{{ range $index, $element := $pag.Pages }} {{ partial "article-list/default" . }} {{ end }}
{{- partial "pagination.html" . -}} {{- partial "footer/footer" . -}} {{ end }} [...] En théorie, ça fonctionne. Sauf que je n’ai pas réussi à le faire marcher avec le thème “Stack” que j’utilise sur le site (j’ai réussi avec un thème “blank”). C’est peut-être lié à un problème d’appel multiple à la fonction .Paginate(), qui “cache” la pagination la première fois qu’elle est lancée. If you call .Paginator or .Paginate multiple times on the same page, you should ensure all the calls are identical. Once either .Paginator or .Paginate is called while generating a page, its result is cached, and any subsequent similar call will reuse the cached result. This means that any such calls which do not match the first one will not behave as written. https://gohugo.io/templates/pagination/ Même en partant du principe que j’arrive à le faire marcher, reste encore la problématique du flux RSS, comme j’ai pu le remarquer avec Seboss666 ;-) J’ai donc laissé tomber cette idée. De toute façon, je n’avais jamais vraiment eu besoin jusqu’à présent puisque je n’y avais pas pensé ;-P. J’ai donc, comme avant, mes posts “planifiés” qui sont visible le matin de leur publication et c’est déjà bien comme ça (pour l’instant). Have fun !
Read more
Suite de la migration Fin décembre, j’ai migré ce blog sur Clever Cloud. Cependant, David Legrand m’a fait remarquer que je n’avais plus de méthode pour planifier mes posts. Depuis quelques temps, je poste à flux tendu donc ça ne m’a pas encore gêné (j’écris un post, je le rend public dans la foulée) mais c’est vrai qu’il me manque cette possibilité par rapport à précédent mon hébergement (une VM). Cependant, il existe une solution sur Clever Cloud pour le faire. David en a d’ailleurs écrit un petit article sur son blog perso, adapté pour “Astro” son générateur de site statique. Je vais donc faire pareil pour mon propre blog avec Hugo. Adaptations Repartons donnc d’où j’en étais au post précédent. Nous avons un blog avec Hugo qui se déploie quand on fait des clever deploy (ou des commits sur le remote de clever). La première chose qu’on va devoir faire, c’est récupérer un token. En effet, c’est notre blog qui va déclencher de lui même les redéploiements, on va donc devoir lui donner de quoi s’authentifier. Si vous n’avez pas de token sous la main, on peut en retrouver un en faisant clever login depuis un terminal, comme je l’expliquais dans l’article précédent. Et on va rajouter le TOKEN dans la liste des variables d’environnement de notre app : $ clever env set CC_SECRET "aaaaaaaaaaaaaaaaaaaaaaaaaa" $ clever env set CC_TOKEN "aaaaaaaaaaaaaaaaaaaaaaaaaa" A partir de là on va créer plusieurs fichiers. D’abord, un script qui va déclencher ce fameux redéploiement : cat > clever_rebuild.sh << EOF #!/bin/bash -l clever link ${APP_ID} clever restart --quiet --without-cache EOF cmod +x clever_rebuild.sh Ensuite, je vais créer un fichier qui sera lu par clever-cloud et qui va déclencher ce redéploiement aux heures où je publie mes posts planifiés (le matin, un peu avant 9h) : mkdir clevercloud echo '["00 08 * * * $ROOT/clever_rebuild.sh"]' > clevercloud/cron.json Attention aux petites blagounettes de timezone. Comme tous sysadmins qui se respectent, les gens de clever utilisent le temps UTC sur leurs serveurs (moi aussi). Cependant, ça nécessite une petite gymnastique intellectuelle si jamais vous n’utilisez pas aussi le temps UTC dans votre tête pour planifier les posts ;-P. Tout dernier point que j’ai éludé jusqu’à présent, il est possible de redémarrer une application à partir d’un cache (pour que ça aille plus vite). Cependant, il est nécessaire d’indiquer à clever cloud quoi mettre dans ce cache. On va donc ajouter “/clevercloud/cron.json:/clever_rebuild.sh” à la variable existante : # précédemment CC_OVERRIDE_BUILDCACHE "/public" $ clever env set CC_OVERRIDE_BUILDCACHE "/public:/clevercloud/cron.json:/clever_rebuild.sh" Hack the template J’ai le même problème que David. Si hugo a bien un flag pour permettre de “builder” les posts dont la date de sortie est postérieure à la date actuelle (buildFuture), mon thème “Stack” les affiche par défaut dans la liste des derniers posts ainsi que dans le flux RSS. La solution la plus simple à se problème est de laisser les paramètres par défaut, et d’attendre que la date de publication soit dépassée (idéalement juste avant le passage d’un cron) et le tour est joué. Mais David a eu une autre approche qui m’a bien plu : ajouter une condition dans le template pour que le post ne soit pas visible dans la liste des posts, mais quand même publié. Avantage : on peut consulter l’article à paraître si on a le lien. Dans mon thème, la page d’accueil qui liste les posts est définie ici dans le code : {{ define "main" }} {{ $pages := where .Site.RegularPages "Type" "in" .Site.Params.mainSections }} {{ $notHidden := where .Site.RegularPages "Params.hidden" "!=" true }} + {{ $notFuture := where .Site.RegularPages ".Date" "le" now }} + {{ $filtered := ($pages | intersect $notHidden | intersect $notFuture) }} - {{ $filtered := ($pages | intersect $notHidden) }} {{ $pag := .Paginate ($filtered) }}
{{ range $index, $element := $pag.Pages }} {{ partial "article-list/default" . }} {{ end }}
{{- partial "pagination.html" . -}} {{- partial "footer/footer" . -}} {{ end }} [...] Note 1 : En théorie, il est également nécessaire de modifier la pagination. Cependant, si vous utilisez plusieurs fois la fonction Paginate dans la même page,le résultat est “caché” et la pagination sera unique jusqu’au redémarrage. Cela étant dit, il est préférable d’avoir quelque chose de consistant pour être sûr d’éviter des cas de figures un peu tordus : If you call .Paginator or .Paginate multiple times on the same page, you should ensure all the calls are identical. Once either .Paginator or .Paginate is called while generating a page, its result is cached, and any subsequent similar call will reuse the cached result. This means that any such calls which do not match the first one will not behave as written. https://gohugo.io/templates/pagination/ Note 2 : En faisant ces modifications je suis tombé sur un “bug” dans Hugo. Le code ne fonctionnera pas si vous utilisez une version > 1.110. L’issue est disponible ici. Maintenant qu’on ne liste plus les posts “dans le futur”, je peux ajouter --buildFuture dans la variable CC_POST_BUILD_HOOK : $ clever env set CC_POST_BUILD_HOOK "cp layouts/index.html themes/hugo-theme-stack/layouts/index.html && hugo --minify --gc --buildFuture" Have fun :)
Read more
Message à caractère informatique, le retour Après deux épisodes où on ne m’avait pas beaucoup entendu parler 😂, j’ai été réinvité par mes copain⋅es de Clever Cloud à un “Message à caractère Informatique”. Mais cette fois-ci il s’agissait d’un épisode un peu spécial, puisqu’à l’occasion du 100ème (ish) épisode, l’enregistrement s’est fait IRL dans les locaux de clever à Nantes, et avec du public, devant une bonne 50aines de personnes, ainsi que ceux sur le live twitch. Le replay de l’épisode, en attendant la version podcast, est disponible sur Twitch
Touriste Cet épisode était également l’occasion pour moi de mettre les pieds pour la première fois à Nantes (étonnamment).
J’ai également profité de la soirée pour parler à Julia (ton “get over it” résonne encore), Nida, Panda, et quelques autres chez Clever que j’oublie. Content d’avoir pu rencontrer et discuter longuement IRL avec Yannick :). Merci beaucoup Carine pour l’accueil et l’organisation. Et ensuite ? Je ne suis pas “on-tour” comme Lætitia (;-P) mais vous pourrez me retrouver à ces prochaines dates : BBL avec ManoMano le 25 janvier FOSDEM 2024 (3 et 4 février) en tant que speaker (pour la première fois !) KubeconEU (du 19 au 22 mars), a minima en tant que participant ;-) Il n’y aura pas de DevoxxFR pour moi cette année (trop compliqué familialement parlant d’enchainer FOSDEM + Kubecon + DevoxxFR) mais je n’imagine pas une seule seconde rester en place en avril/mai 🤣.
Read more
Une recette sur le blog ? C’est dimanche, on pose le clavier. On évite les dramas sur LinkedIn et X (ah non, ça c’est raté). Et si on faisait un peu de cuisine plutôt ? Des pancakes à la banane 🥞🍌, par exemple ? C’est pas la première fois que je poste une recette sur le blog. Si vous l’avez loupée, je vous conseille d’aller voir celle que j’avais postée en 2022 : le Chao Mian, qui est vraiment super bon et relativement simple à faire. Et ici, elle est vraiment ENCORE plus simple, si bien que j’hésite pas à en faire à l’arrache quand on a rien de prévu le dimanche matin ou pour le gouter, pourvu qu’on ait 2 bananes un peu trop mûres (ce qui nous arrive souvent). Ingédients Pour cette recette, il vous faudra donc : 2 bananes, les plus mûres possibles (- pénible à écraser, + de goût) 2 œufs 200g de farine 40g de sucre (on pourrait même faire sans) 1 sachet de levure 100 mL d’eau Cette recette n’est donc pas vegan puisque j’ai enlevé le lait (remplacé par de l’eau) ni beurre (c’est les bananes qui remplacent), mais qu’il y a des œufs… Préparation Commencez par écraser les bananes avec vraiment beaucoup d’application. Il ne faut pas juste écraser grossièrement, il faut que la banane se transforme en un genre de pâte gluante informe. C’est pas très appetissant mais promis, c’est mieux pour la suite. Si vous avez de la main d’œuvre pas qualifiée et à bas coût (aka des enfants) c’est parfait pour les occuper. Dans un saladier, mettez ensuite les 2 œufs, les bananes écrasées, la farine, le sucre, la levure et l’eau. Mélangez. J’ai pas menti quand j’ai dit que c’était simple. Là encore, n’hésitez pas à déléguer : avec l’eau, la pate doit être presque liquide mais pas trop (encore un peu visqueuse). En théorie, il faudrait laisser reposer un peu la pâte mais moi je trouve qu’on peut la cuire directement. Dans le doute, 30 minutes - 1h, c’est sûrement mieux (l’avis de ma femme). Cuisson Finalement presque la partie la plus compliquée de l’opération. Idéalement, avec une crêpière graissée (beurre, huile), mettez une petite quantité de pâte de manière à faire un disque un peu plus petit que le pancake que vous voulez avoir. J’arrive à les faire 3 par 3 dans ma crêpière 28cm. Protip : il faut les retourner quand des petits trous se forment sur le dessus (bulles qui éclatent) Dans la photo ci dessus, on devine les bulles, qui font devenir des petits “trous” dans notre pancake. Là, il est encore trop tôt pour les retourner. Le mot de la fin Avec les quantités que je vous ai donné, vous devriez pouvoir faire entre 12 et 15 pancakes, selon la taille que vous leur donnerez. On sent bien le gout de banane si on les mange nature et ils ont le moelleux des pancakes normaux, tout en étant moins gras. Idéalement, ils sont à déguster avec du sirop d’érable (c’est les meilleurs pancakes), bien imbibés quand on est gourmand comme moi. Mais j’aime aussi ajouter de la confiture de framboise (on sent moins la banane malheureusement) ou avec de la Nocciolata (sans lait, elle a plus de cacao). Have fun
Read more
Cet article fait partie d’une série d’articles dédiés à la découverte de MAAS, un outil de déploiement d’OS sur un parc de serveurs (souvent baremetal mais pas que) : Premiers pas avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical Un peu plus loin avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical Déployer un hyperviseur VMware ESXi avec MAAS Résumé des épisodes précédents Dans les deux derniers épisodes, on a vu comment déployer MAAS sur un lab perso, comment déployer ensuite nos premiers OS sur des machines baremetal de manière automatisée, comment les customiser en changeant de version d’Ubuntu ou avec cloud-init. Mais dans les promesses de MAAS, il y a plus que ça. En théorie, on doit pouvoir démarrer “out of the box” (ouais pas tout à fait, mais je ne spoil pas plus) des serveurs d’autres OS, comme Windows (beurk) ou des hyperviseurs VMware ESXi. Et même plus (mais ça n’est pas le but de cet article pour l’instant). ESXi ? Vous l’avez compris, point de Windows Server dans ce tutoriel, cependant sachez qu’avec les deux liens que j’ai déjà donnés dans l’article précédent vous devriez pouvoir vous en sortir : Documentation de Canonical MAAS - How to customise images Discourse de Canonical MAAS - How to build MAAS images Même si c’est un hyperviseur propriétaire, j’ai quand même passé pas mal de temps à travailler avec VMware et j’ai toujours été relativement content d’ESXi (no comment sur le reste de la “suite” par contre). Note: vous pouvez d’ailleurs retrouver tous les articles qui parlent de VMware sur ce blog, ça date un peu, mais il reste peut-être des trucs utiles. On va donc voir si c’est si facile que ça… Ubuntu Pro ? La première chose qu’on apprend dans la doc, c’est qu’il existe 2 manières de customiser des OS non Ubuntu pour les faire marcher dans MAAS : Packer MAAS MAAS Image Builder MAAS Image Builder nécessitant une souscription Ubuntu Pro, je vais évidemment me rabattre uniquement sur Packer MAAS… Heureusement, le projet est relativement bien fourni, avec des CentOS (8 ou 9 stream), des Debian jusqu’à la 12, et donc… VMware ESXi, de la 6 à la 8. Pour cet article, je me suis d’abord basé sur le tutoriel officiel, mais il est sévèrement “pas à jour” (on a un petit doute dès la première étape qui demande d’utiliser Ubuntu 18.04) et pointe vers des versions obsolètes… Installer Packer Comme son nom le laisse deviner, on va avoir besoin de Packer, un tool de mes copain⋅es de chez Hashicorp. Pour l’instant personne n’a forké Packer, donc : wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list sudo apt update && sudo apt install packer On vérifie que ça a bien marché packer --version Packer v1.10.0 Récupérer un ISO chez VMware Alors, là c’est la partie pénible. Si on est pas client VMware, il n’est pas possible de télécharger d’ISO de VMware ESXi sans : se créer un compte demander un trial sur une version (idéalement la dernière) d’ESXi C’est pénible, ça demande plein d’infos personnelles et ça pourri les BAL mais bon… c’est ça aussi, d’utiliser des logiciels privateurs. Avant, l’usage de l’ESXi était gratuit mais visiblement c’est de l’histoire ancienne… Pas de bol, j’avais fait mes premiers tests sur VMware ESXi 8.0u1, et j’ai voulu récupérer la u2, mais voici ce que me dit VMware Your evaluation has expired on August 29, 2023 Pour paraphraser un certain Linus T., F… YOU VMware! Tant pis, je vais donc faire avec l’ISO que j’ai… VMware-VMvisor-Installer-8.0U1a-21813344.x86_64.iso Récupérer packer-maas Si vous suivez le tuto que je vous ai donné en début d’article, il y a un moment où on va vous demander un Nom/Prénom/Email pour avoir le droit de télécharger un script pour transformer notre ISO VMware en image MAAS. https://maas.io/vmware-images Sauf que : l’archive que vous allez télécharger est obsolète et ne fonctionnera pas les sources et les releases sont dispos et à jour sur le github du projet Rant: Je suis éventuellement OK pour donner mes informations personnelles en échange de l’outil, mais s’il vous plait, gardez vos tutos à jour !?! On va donc plutôt télécharger directement la dernière version de packer-maas qui supporte les Debian et des variantes de RHEL supplémentaires :) et est disponible ici (page de la release / archive tgz) wget https://github.com/canonical/packer-maas/archive/refs/tags/v1.1.0.tar.gz tar xzf v1.1.0.tar.gz cd packer-maas-1.1.0/vmware-esxi/ Construire l’image VMware ESXi pour MAAS On commence par charger le driver nbd. Si comme moi vous ne savez pas ce que c’est, sachez que c’est Network Block Devices. sudo modprobe nbd # si ça ne renvoie rien, c'est bon Ensuite, on lance Packer avec les arguments suivants : sudo packer init . sudo PACKER_LOG=1 packer build -var 'vmware_esxi_iso_path=../../VMware-VMvisor-Installer-8.0U1a-21813344.x86_64.iso' . Note: packer-maas fourni aussi un Makefile pour vous simplifier encore plus la vie… Vous pouvez juste lancer make ISO=/path/to/VMware-VMvisor-Installer.iso A ce moment là, les scripts de packer-maas vont booter une VM avec notre ISO et réaliser des actions pour “l’installer” en envoyant des caractères dans une session VNC ! Quand on y réfléchit, c’est à la fois un peu bourrin et awesome à la fois. Si tout se passe bien, vous devriez vous retrouver avec un fichier vmware-esxi.dd.gz au bout de quelques minutes. ESXi dans MAAS Maintenant qu’on a notre image, on va l’envoyer dans MAAS ! Sur l’UI, récupérer une clé pour API (sinon on ne pourra pas pousser l’image) sur votre utilisateur (il doit être avec des privilèges admin) : Je n’ai pas trouvé de menu dans la GUI pour le faire, mais on peut loguer notre terminal avec la commande suivante (en n’oubliant pas de renseigner l’API key) : maas login admin http://192.168.x.y:5240/MAAS/ API key (leave empty for anonymous access): Puis envoyer l’image en CLI maas admin boot-resources create name='esxi/8.0u1' title='VMware ESXi 8.0u1' architecture='amd64/generic' filetype='ddgz' content@=vmware-esxi.dd.gz Note 1 : ne faites pas de Packer sur une partition Windows montée sous Linux (fuse + packer = KK) Note 2 : si vous avez installé MAAS en tant que snap sur votre poste, vous ne pouvez accéder aux fichiers que dans votre /home (vous vous prendez un “no such file or directory”) A partir de là, elle devrait apparaitre dans la liste des “Images” disponibles ! Let’s go la déployer sur une machine du lab… Et au bout de quelques minutes…
Victoire !
Read more
Une petite mise à jour ? Si vous me suivez sur les réseaux sociaux, vous savez que je parle souvent d’argent dans la tech. Bouuuuh, l’argent c’est sale !* *en France seulement. Et je me demande bien à qui ça profite 🤔 Eh oui, même si ce ne devrait pas être la seule source de motivation d’un dev / sysadmin / whatever (quoique ??), il ne vous aura pas échappé que nous ne vivons pas d’amour et d’eau fraîche. Nous n’avons pas intérêt en tant que salarié⋅e de la tech à être sous-payé⋅e juste pour les beaux yeux des dirigeant⋅es des entreprises qui nous emploient. Voilà pour l’introduction :D Maintenant que c’est dit, j’avais écrit un article avec le même titre en 2022 (suite à une énième 💩storm sur Twitter) dans lequel j’avais donné des liens vers ma collection d’études de salaires. Car pour savoir si on est sous-payé ou pas, il n’y a pas de miracle, il faut se renseigner. Demander à ses pairs est un bon début, mais on vit parfois dans des bulles (moi y compris), comme cette personne qui m’avait expliqué qu’il était impossible qu’un senior touche plus de 50k€ en France, puisqu’il en connaissait une centaine et qu’aucun n’avait de telles rémunérations… Note: à l’inverse, les études de salaires souffrent aussi de biais, et c’est pour ça qu’il ne faut pas non plus tout baser là-dessus. Mais pour vous faire une idée, il faut commencer par les lire ! Balance tes sources Parmi mes hobbies chelous, outre le droit du travail, les recettes à base de butternut et les puzzles, je collectionne depuis une douzaine d’années des études/baromètres/enquêtes sur les salaires dans la tech, de tout type (véridique, j’ai un dossier sur mon NAS). Et comme je suis quelqu’un de foncièrement sympa, je vous propose donc de vous partager mon petit top10 pour 2023-2024 : Grille des salaires EXTERNATIC 2023 (cabinet de recrutement Nantais) Baromètre des salaires 2023 de SILKHOM Baromètre de l’AFUP (avec un historique depuis 2013 !) Enquête des salaires The Product Crew (plus orienté product, mais pas que) Les salaires des Développeurs (sondage WeLoveDevs.com) Sondage association Okiwi 2023-2024 (région bordelaise uniquement, en cours) Etude talent.io 2023 Etude Hays 2023 Etude Michael Page 2024 Plateforme collaborative Salaires.dev Bonus Certaines entreprises, dans un effort de transparence, n’hésitent pas à publier des grilles de salaire ou des outils pour estimer le salaire qu’elles vous proposeraient si vous postuliez chez elles. Ca reste encore assez confidentiel mais ça se démocratise : Grille de salaire chez Alan Estime ton salaire chez la néobanque Shine, qui a priori se positionne dans le 75ème percentile des boites Next40/FT120 Le Shomulator Calculatrice Zefir Vous avez également des sources plus généralistes (APEC, Glassdoor, Linkedin) que je ne citerai pas ici mais que vous pouvez trouver assez facilement. Epilogue Si vous gagnez moins que ce que les études disent que vous devriez gagner, n’allez pas immédiatement sortir la fourche #toutCramer #revolte. Le but n’est pas d’aller chercher à maximiser sa rem à tout prix, il y a plein d’autres critères qui doivent rentrer en compte dans votre vie professionnelle. De plus, les chiffres donnés ici sont des moyennes (ou bien mieux, des médianes), qui ne donnent qu’une vision étriquée du marché. Mais ces outils sont quand même intéressants pour rester lucide par rapport à votre position sur le marché, qui est bien plus vaste que ce que vous en connaissez. La petite requête de la fin, s’il vous plait : N’hésitez pas à participer aux études de salaires, surtout si vous n’êtes pas dans les médianes ! C’est comme ça qu’on aura des chiffres toujours plus pertinents. N’hésitez pas à demander aux recruteurs le budget pour le poste qu’ils vous proposent. Ce budget, ils le connaissent, ne vous laissez pas berner par le classique “salaire selon profil”.
Read more
Cet article fait partie d’une série d’articles dédiés à la découverte de MAAS, un outil de déploiement d’OS sur un parc de serveurs (souvent baremetal mais pas que) : Premiers pas avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical Un peu plus loin avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical Introduction Dans la première partie, nous nous étions arrêté au moment où MAAS était installé sur un Raspberry Pi, routeur entre mon LAN et mon lab. Nous avions également déployé un OS (Ubuntu 20.04 par défaut) pour valider que l’installation fonctionnait Dans cette partie, on va essayer d’aller un peu plus loin et de faire des trucs plus funs pour déployer des OS différents, et pourquoi pas des hyperviseurs ! Modifier l’OS par défaut Il est possible de modifier l’OS installé par défaut sur nos machines lors des phases “Commissioning” et “Deploying” Comme j’avais déjà récupéré les ISO pour Ubuntu 22.04, j’ai donc essayé de modifier toutes les étapes en Ubuntu 22.04. La procédure est assez simple, on peut même changer le kernel par défaut (pratique pour profiter des dernières avancées eBPF, notamment si vous voulez faire du Kubernetes! )
Rappel : la phase commissioning sert à faire une première installation d’un hôte minimal pour l’enrôler dans notre pool de serveurs disponibles avec MAAS, en vue d’une future installation. Si on veut modifier l’OS installé par défaut quand on déploie une machine, c’est bien le menu de la phase “Deploying” qu’il faut modifier. Déployer un hôte “KVM” Par défaut, il est également possible de déployer des hôtes qui vont gérer des machines virtuelles directement depuis MAAS.
Même si j’avais le doute au début, les machines LXD sont bien de vraies machines virtuelles (pas de containers LXC), comme l’explique la documentation officielle LXD vs libvirt - maas.io/docs/virtual-machines Both libvirt KVMs and LXD VMs are based on QEMU, but LXD VMs offer more advantages such as enhanced security and a robust API. Unlike libvirt KVMs, LXD VMs can be managed remotely without requiring SSH access. A noter, les machines libvirt sont aujourd’hui considérées comme “legacy” et il n’est pas possible d’en ajouter provenant de l’extérieur dans l’UI 3.4.0 beta que j’ai installé, contrairement aux machines LXD qui peuvent être ajoutées à MAAS même si elles ne sont pas sur des serveurs gérés par MAAS.
On peut ensuite aller dans virsh/LXD (selon ce qu’on a choisi) et poper des VMs depuis l’interface de MAAS. Et ce qui est rigolo, c’est qu’on peut ensuite installer des trucs sur ces machines, qui se retrouvent dans notre liste :
Machines making machines! How perverse. – C3PO - Star Wars Episode 2 Et on peut déployer des trucs dessus bien sûr ;-)
Bon, ce n’est par contre pas spécialement user friendly (mais ça marche). L’idée est probablement un peu plus utile avec Juju (que je ne testerai pas ici). VM hosts offer unique benefits when integrated with Juju, including dynamic VM allocation with custom interface constraints. Customiser son OS avec cloud-init Avouez que déployer des OS nus (juste l’OS, rien d’autre) avec MAAS, c’est cool, mais c’est quand même un poil limité en prod. Pour aller plus loin, MAAS nous donne accès à plusieurs mécanismes pour customiser notre OS. Pour faire simple et parce que c’est devenu un des standards du marché, je vais tester l’utilisation de cloud-init avec MAAS pour customiser mon OS. Et parce que j’aime Kubernetes, je vais poper un “cluster” de test avec microk8s. En l’état celà ne servira pas à grand-chose en utilisation réelle, mais ça vous donne une idée de ce qu’on peut faire avec. #cloud-config runcmd: - | # install and start microk8s snap install microk8s --classic microk8s start usermod -a -G microk8s ubuntu mkdir /home/ubuntu/.kube chown -R ubuntu ~/.kube apt_update: true apt_upgrade: true package_update: true package_upgrade: true package_reboot_if_required: false Au bout de quelques minutes, la machine est déployée, et l’OS est correctement customisé : ssh -J 192.168.x.y ubuntu@10.10.0.4 microk8s kubectl get pods No resources found in default namespace. Note : Ici j’utilise le RPi comme “JumpHost” car je n’ai pas d’accès direct aux machines depuis mon LAN. Aller plus loin - déployer ses propres images sur ses machines Ici, je tease un peu le(s) prochain(s) article(s). Ne vous attendez pas à lire la solution ici, il faudra attendre un peu ;-). Par défaut, les OS disponibles sur MAAS proviennent d’images qui sont stockées sur maas.io. On y retrouve toutes les LTS d’Ubuntu jusqu’à la 12.04 (!?!) ainsi que les non-LTS de la 20.10 à la 23.10, et pour plusieurs architectures. Dans la section “Other Images”, il n’y a malheureusement que CentOS 7 et 8. Pour utiliser d’autres images, on va pouvoir utiliser des registry customs depuis l’interface ou créer nos propres builds qu’on poussera sur l’interface. Si vous êtes trop curieux, je vous laisse quand même quelques liens qui devraient vous donner une bonne idée de ce qu’on va faire la prochaine fois. Documentation de Canonical MAAS - How to customise images Discourse de Canonical MAAS - How to build MAAS images En attendant, have fun !
Read more
It’s groundhog migration day, again Tous les 6 mois environ, une mouche me pique. Après avoir migré un nombre incalculable de fois mon blog wordpress à droite / à gauche, puis migré sur Hugo, autohébergé, utilisé du managé chez vercel, chez froggit, autohébergé encore… J’ai décidé (un peu sur un coup de tête) de migrer le blog chez les copain⋅es de chez Clever Cloud. Et je vous montre comment j’ai fait. Prérequis Je pars du principe que vous avez comme moi un dépôt git / site hugo déjà fonctionnel. Et je ne vais pas non plus détailler la procédure pour activer un compte chez Clever Cloud. Je commence par installer la CLI, les “clever tools”. Pour les installer, il nous faut npm. J’utilise rarement npm, mais quand je le fais, j’utilise un autre tool, nvm (Node Version Manager), qui va me permettre de choisir la version dont j’ai besoin $ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash Une fois installé, je peux télécharger la version qui m’intéresse de npm (18 par exemple, la version minimum pour installer les clever tools) $ nvm install 18 Downloading and installing node v18.19.0... [...] Now using node v18.19.0 (npm v10.2.3) Creating default alias: default -> 18 (-> v18.19.0) Je peux donc maintenant installer les clever tools : npm i -g clever-tools Puis me loguer depuis mon terminal $ clever login Opening https://console.clever-cloud.com/cli-oauth?cli_version=3.0.2&cli_token=xxxxxxxxxxxxxxxxx in your browser to log you in… Login successful as [unspecified name] Gardez en tête l’existence des CLEVER_TOKEN / CLEVER_SECRET, on pourrait en avoir besoin un jour :-p Denier prérequis, je vais ajouter une clé SSH dans ma console clever Création de l’application A partir de maintenant, je suis capable d’intéragir avec clever cloud en CLI. Je vais commencer par créer l’application qui va héberger mon site statique : $ clever create -t static-apache blog-zwindler Your application has been successfully created! Point intéressant, Clever Cloud permet de dissossier la taille des instances pour la partie run et la partie build. Je vais donc créer l’instance la plus petite possible pour le run (une nano), et une plus pêchue (une M) pour le build, histoire d’être plus réactif sur les commits de modifications : $ clever scale --build-flavor M App rescaled successfully $ clever scale --flavor nano App rescaled successfully Je peux ensuite configurer quelques variables d’environnement (trouvées sur la doc de clever cloud) pour générer mon site statique avec l’image static-apache de clever. $ clever env set CC_WEBROOT "/public" $ clever env set CC_OVERRIDE_BUILDCACHE "/public" $ clever env set CC_PRE_BUILD_HOOK "bash setup_hugo.sh" $ clever env set CC_POST_BUILD_HOOK "hugo --minify --gc" Pour finir, on crée le script setup_hugo.sh à la racine de notre site statique Hugo : cat > setup_hugo.sh << EOF HUGO_VERSION="0.121.1" HUGO_URL="https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz" DEST_BIN="${HOME}/.local/bin" FILENAME="hugo.tar.gz" # Download Hugo Extended and place it in a folder in the $PATH curl --create-dirs -s -L -o ${DEST_BIN}/${FILENAME} ${HUGO_URL} cd ${DEST_BIN} tar xvf ${FILENAME} -C ${DEST_BIN} rm ${FILENAME} EOF On commit les fichiers créés : git add . git commit -m "Add clever" Déployer notre code A partir de là, on a notre instance qui est prête à démarrer, dès qu’elle aura reçu du code. Ici, clever cloud attend un push sur un dépôt git. La méthode la plus “simple” pour pousser du code sur clever à ce moment-là est donc de créer un dépôt distance (remote) : git remote add clever git+ssh://git@push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git git push clever master Le “problème” dans mon cas est que (pour l’instant), le nom de la branche n’est pas configurable et est forcément “master”, ce qui ne m’arrange pas puisque je bosse habituellement sur “main”. remote: Error: You tried to push to a custom branch. This is not allowed. remote: error: hook declined to update refs/heads/main To git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git ! [remote rejected] main -> main (hook declined) error: impossible de pousser des références vers 'git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git' 2 manières de contourner ce problème : soit je force la branche master sur le remote clever dans git soit j’utilise la CLI clever deploy Dans un premier temps, je me contente de feinter git : git push clever main:master Énumération des objets: 30, fait. Décompte des objets: 100% (24/24), fait. Compression par delta en utilisant jusqu'à 16 fils d'exécution Compression des objets: 100% (16/16), fait. Écriture des objets: 100% (16/16), 287.70 Kio | 31.97 Mio/s, fait. Total 16 (delta 8), réutilisés 0 (delta 0), réutilisés du pack 0 remote: [SUCCESS] The application has successfully been queued for redeploy. To git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git 54ff42f..960ce62 main -> master On termine par la configuration du nom de domaine : $ clever domain add blog.zwindler.fr Your domain has been successfully saved Il ne nous reste plus qu’à mettre à jour le CNAME dans notre DNS (domain.par.clever-cloud.com. dans mon cas, mais la bonne configuration est visible dans l’onglet Domain names de l’application) Et avec clever deploy ? Et bien en fait, c’est “encore plus simple”. Il me suffit juste de faire une modif, de commit git add . git commit -m "test clever deploy" Puis de simplement lancer la commande clever deploy. $ clever deploy Remote git head commit is c4e3c283585cafff44f07c7d78d860065318cd68 Current deployed commit is c4e3c283585cafff44f07c7d78d860065318cd68 New local commit to push is 0b3536a9f1d61178a99f6238831ccb4197989ddf (from refs/heads/main) Pushing source code to Clever Cloud… Your source code has been pushed to Clever Cloud. Waiting for deployment to start… Deployment started (deployment_b5f841ff-a233-4bb4-8a16-f618ee69ef28) Waiting for application logs… [...] Quelle est donc cette diablerie ? En réalité, les informations nécessaires pour pousser le code sont en réalité simplement dans un fichier .clever.json qui a été créé à la racine lorsqu’on a lancé la commande clever create -t static-apache blog-zwindler au tout début du tuto. { "apps": [ { "app_id": "app_xxxxxxxxxxxxxxxxxxx", "org_id": "user_yyyyyyyyyyyyyyyyyyyyy", "deploy_url": "https://push-n3-par-clevercloud-customers.services.clever-cloud.com/xxxxxxxxxxxxxxxxxxxx.git", "name": "blog-zwindler", "alias": "blog-zwindler" } ] } Evidemment, je ne vais pas m’amuser à faire un clever login / clever deploy à chaque fois que je veux pousser une modif sur mon blog. Et c’est là où nos CLEVER_TOKEN / CLEVER_SECRET seront utiles ! Conclusion Après quelques heures d’usage, je peux dire que dans le cadre de l’hébergement de mon blog, j’aime bien utiliser Clever Cloud. Qu’on soit bien clair, c’est pour mon cas d’usage et comparé à : Vercel : l’expérience utilisateur est incroyable sur Vercel, mais j’ai toujours été un peu géné par le côté “boite noire” (on a pas accès à beaucoup plus que des variables d’environnement). Et je ne parle pas des problématiques de privacy… Deux serveurs physiques avec Proxmox VE en cluster étendu chez One-provider : à l’inverse héberger moi même mon blog sur une machine (en vrai, 2) louée résoud les problèmes de privacy et j’ai la main sur toute la stack, mais ça me demande de la maintenance pour des perfs minables. Ok, c’est pas cher, mais j’ai 2 à 3 minutes de rebuild avec le CPU à 100% sur mon Atom de 2010 chez Online… Froggit : c’était du Gitlab + gitlab pages et c’était très cool car c’est plus flexible que Vercel, mais j’avais du passer un peu de temps à configurer la pipeline et leur faire pousser les murs pour que mon site rentre (les 400 Mo de médias n’étaient pas supportés au début et les transferts gitlab => gitlab pages étaient un peu long). Avec Clever, mes 450 articles (3600 pages générées, 400 Mo de média) sont très rapidement générés, transférés, et enfin mis à disposition (< 1 minute tout compris, plus rapide que les 3 solutions précédentes). Le tout avec une disponibilité/fiabilité sans aucun doute bien meilleure que ce que j’aurais pu faire moi même en autohébergé avec un coût similaire, et en très peu de temps. J’ai passé beaucoup plus de temps à écrire cet article qu’à migrer le blog, puisque la doc est bien écrite, le site est intuitif, et je n’ai été bloqué à aucun moment. Il me reste encore à optimiser l’étape de déploiement, pour qu’un commit/push sur mon dépôt git déclenche automatiquement un déploiement côté clever. Objectivement, ça ne devrait pas prendre trop longtemps (github action / gitlab CI)… Et par contre, ça manque d’IPv6 natif, screugneugneu !
Read more