Je pense qu’on est nombreux à avoir des petits serveurs à la maison pour héberger des applications qu’on utilise au quotidien. Certains le font pour éviter de partager ses données, d’autres afin d’éviter de payer des services en ligne, ou pour le fun et l’apprentissage… On est tous capables de justifier notre besoin d’avoir un serveur à la maison.

Pendant très longtemps, et par simplicité, j’ai utilisé un serveur dédié OVH comme lab de test ou pour héberger des services (j’ai eu mon premier dédié en 2016). C’était peu couteux, facile à gérer et ça me permettait de faire des expériences infra sans avoir à gérer la partie hardware (petite fun fact : mon serveur était infiniment plus puissant que mon ordinateur personnel, impossible de pratiquer sur des VMs locales). C’était franchement pas mal, mais j’ai rapidement eu envie de pouvoir joindre directement mes machines virtuelles.

En arrivant à Lyon, en 2022, j’ai voulu me monter un petit lab à la maison. J’ai donc recyclé un vieux laptop, pour y mettre un Proxmox, c’était pas optimal (ni très puissant), mais ça me permettait de faire des tests et de pratiquer depuis chez moi. Je savais d’avance que je ne pourrais pas continuer comme ça, mais c’était un bon début.

(J’ai voulu retrouver des photos, mais faut croire que j’étais pas très content de le partager à l’époque, donc j’ai pas grand-chose à vous montrer).

Durant le passage de ma VAE, je m’intéressais à Kubernetes et j’ai eu envie de faire évoluer mon lab. J’ai donc acheté 2 Raspberry Pi 4 et 2 Rock64 pour installer K3s dans un premier temps et Talos dans un second (et oui, c’est à ce moment que j’ai développé mon obsession pour cet OS). Pour rendre ça “feng shui”, j’ai recyclé une vieille ampli Marshall dans laquelle j’ai enlevé les haut-parleurs et y ai posé mes cartes, ainsi qu’un switch et un petit ventilateur en PWM pour refroidir tout ça (il y avait même un capteur de température relié à mon home assistant).

Je vous laisse admirer le résultat de la première version de mon MarshallStack :

Plus tard, j’ai réarrangé tout ça pour que les cartes soient plus éloignées. Oui la présence du chat était obligatoire dans cet article.

Fonctionnel: oui, portable: aussi, pratique: non. Si je devais accéder à une carte, il me fallait déplacer les fils d’alimentation et le switch au milieu (ça m’arrivait souvent de casser le support en impression 3D). En plus, c’était vraiment pas très puissant et mes applications avaient vraiment le strict minimum pour tourner.

Après un déménagement, j’ai démonté le MarshallStack pour récupérer les cartes et jetter l’ampli. Je n’avais pas la patience de devoir le remonter. Au revoir le beau boitier, maintenant les cartes sont sur un meuble.

Je vire également les Rock64 pour les remplacer par d’autres raspberry pi 4 (dont un Pi 400, le clavier avec un Pi intégré).

(évidemment, le chat est toujours là)

Là, on peut dire que c’est un setup ⭐️minimaliste⭐️ ! Dieu merci : j’ai toujours mon Proxmox OVH pour les services qui ne peuvent pas être sur ARM ou qui nécessitent plus de ressources. 2 mois plus tard, j’achète 2 mini-machines n100 pour compléter le setup. Je délaisse peu à peu mon cluster de Raspberry Pi pour me concentrer sur mes n100 (avec surtout des VMs Talos). Les VMs sont plus puissantes, plus facile à réinstaller et le rapport consommation électrique/puissance est meilleur.

Bref, la deuxième version de mon cluster ARM n’est pas une réussite, un collègue récupèrera ces cartes pour son propre lab (cc lilian).

Un nouveau déménagement, un nouveau lab ! Il est toujours basé sur les mêmes n100 mais le “setup” est encore pire qu’avant : les machines sont dans un meuble Ikea, les câbles passent derrière le meuble pour se brancher directement sur la Freebox. C’est fonctionnel, mais ni beau, ni pratique.

(Petit photo-bomb de mon NAS)

Bref, c’est pas sexy, je ne peux toujours pas accéder facilement aux ports des serveurs, mais ça fonctionne. Je rajoute également un JetKVM pour piloter mes serveurs à distance (et ça, c’est vraiment cool pour dépanner sans être à la maison). En janvier 2025, ça me saoule un peu de voir ces cables qui traînent, impossible non-plus de faire du cable-management sans me bloquer l’accès aux ports, Meh. Déjà le manque d’organisation ne me plaît pas, mais en plus de ça, il n’y a pas de place pour rajouter des cartes, donc aucune évolutivité. Il me faut un moyen de ranger mes serveurs comme… un rack !

Side-Story : En 2020, avec mon premier salaire (de stagiaire), j’avais acheté un rack 19" et un dell r610. C’était honnêtement un des pires achats que j’ai pu faire. Le r610 était bruyant, consommait beaucoup d’électricité et prennait une place folle. Aujourd’hui, j’ai aucune idée de comment m’en débarrasser et il prend la poussière dans un garage. Je ne veux surtout pas reproduire cette erreur : pas de gros serveurs, pas de gros racks en 19" !

C’est là que Jeff Geerling m’a inspiré avec son projet de MiniRack. J’ai découvert l’existence de racks 10 pouces, parfait pour mon usage. J’étais initialement tenté de le désigner moi-même comme certains makers (coucou Denis) qui font des racks à partir de meubles Ikea ou d’impression 3D, mais je me connais et la taille de mon backlog de projets personnels me fait peur. Je préfère acheter un rack tout fait, c’est peut-être plus onéreux, mais ça me prendra moins de temps.

Je commande donc le T1 RackMate de GeekPi, un rack 10" de 8U. Il est un peu cher mais il semble de bonne qualité (et en plus, il est évolutif, on peut les empiler).

Petite déception, il arrive déjà monté. J’ai pas eu le plaisir de le faire moi-même, sob.

Première étape pour le remplir : l’impression d’un support pour mon switch (un tp-link très classique). Aucune colle, aucune vis, le switch est bien maintenu par friction et le branchement des câbles ethernets ne pose pas de problème ! 

Mais oui, un switch sans serveurs, c’est inutile. Je profite alors de l’occasion pour acheter un nouveau joujou : un Turing Pi 2 (abrégé TP2). Le TP2 est une motherboard pouvant accueillir plusieurs cartes compute (jusqu’à 4) comme des Raspberry Pi 4 CM4. Je me suis entièrement fourni sur LeBonCoin : la carte Turing Pi 2, 2 modules RK1 (les cartes officielles pour le TP2) et 2 Raspberry Pi 4 CM4 de 8Go.

Manque plus qu’un support pour le TP2 dans mon Rack et il peut enfin partir en (home)production. Vive l’impression 3D !

Ce soir, c'est l'impression d'un boîtier mini-itx pour le turing-pi (et adapté au Rack)

[image or embed]

— Quentin - adorateur de ☕ (@une-tasse-de.cafe) March 7, 2025 at 10:04 PM

Le TP2 possède une prise HDMI pour piloter un des nœuds, comme je n’ai aucun écran à proximité, c’est là qu’intervient le JetKVM pour voir l’écran. Vous commencez à connaître la chanson, j’ai imprimé un support pour celui-ci. (spoiler : il va pas rester longtemps branché au TP2).

Ça devient sérieux là ! J’ai maintenant la troisième itération de mon cluster ARM (qui, pour le coup, est une réussite). On parlera un peu de ce qui tourne dessus plus bas. Je veux à présent ajouter mes serveurs actuels (les n100), sauf que le seul support livré avec le Rack est utilisé par le TP2. Je vais donc faire quelques économies et imprimer un support pour les n100.



[image or embed]

— Quentin - adorateur de ☕ (@une-tasse-de.cafe) March 12, 2025 at 7:08 PM

Voici ce que ça donne une fois monté dans le Rack :

Un n100 est couché pour laisser passer l’antenne zigbee, l’autre est debout pour économiser la place (je ne peux pas coucher les deux). Je suis assez content du résultat final, ça semble robuste, pratique à utiliser et surtout, ça me permet de rajouter des serveurs si besoin.

Avant de fixer le TP2 pour de bon, je rajoute 4 SSD NVMe pour faire du stockage distribué avec Rook. Chaque noeud à son propre disque (en plus du stockage des cartes compute), ça me permet de faire du stockage distribué dédié au cluster ARM (spoiler : c’est évidemment du Kubernetes qui tourne dessus).

Petit drame : les cartes CM4 (Raspberry PI) ne sont pas compatibles avec l’adaptateur PCIe du TP2, je suis donc obligé de les remplacer par des cartes RK1 (qui sont bien plus chères mais plus puissantes). J’espère avoir l’occasion de les réutiliser un jour.

Maintenant, on peut passer au dernier serveur du rack : un ma…

Ça, c’est la boulette… Le support en 3D n’a pas supporté le poids des deux n100 et s’est cassé. Faute d’avoir des supports fiables à l’arrière, j’ai dû faire le sage choix d’acheter un VRAI support rack tout fait pour les n100 pour 15e sur Amazon. J’aurais pu modifier le modèle 3D ou l’imprimer dans le sens horizontal pour le rendre plus solide, mais je n’ai eu ni la patience de le faire, ni la capacité de l’imprimer à l’horizontal car le plateau de mon imprimante 3D est trop petit.

Par chance, aucune casse dans l’accident et les n100 sont toujours fonctionnels. J’ai donc pu les installer dans le rack sans problème.

Nous disions quoi avant l’incident ? Ah oui ! Le petit nouveau du rack : un Mac Mini M4. C’est le même que j’utilise durant les streams sur Twitch car plus fiable que mon PC tour (qui a tendance à perdre la connexion au WiFi, peu importe la carte réseau que j’utilise). Lorsque je ne m’en sers pas, il est dans le rack en tant que serveur (je parlerai de ce qu’il fait plus bas). Il est sur le même plateau que les n100 et rentre parfaitement dans le rack.

Vous devez déjà savoir qu’un Mac comme serveur, c’est pas très commun (ni adapté à cet usage). Le problème principal est le démarrage des services au boot. J’ai vu des articles proposant de désactiver le login au démarrage et de démarrer du VNC ou du Parsec pour le piloter à distance, mais je ne peux pas supporter l’idée d’une machine sans un mot de passe pour se connecter (d’ailleurs, mes autres machines demandent aussi une clé pour démarrer et déchiffrer le disque, j’en parle ici). Pour me simplifier la vie, je vais plutôt utiliser mon JetKVM (qui n’était pas si indispensable pour le TP2) pour piloter le Mac Mini à distance.

Voici les seuls paramètres que j’ai dû tweak pour que le Mac Mini soit utilisable en tant que serveur.

Bref, merci au JetKVM, sinon ça aurait été un peu plus compliqué.

Petit bonus : le JetKVM supporte mon layout de clavier (ergol) et je peux donc taper directement dessus sans me casser la tête à changer de layout lorsque je suis à distance.

Qu’est-ce qui tourne dessus ?

Si vous me suivez sur les réseaux, vous savez peut-être que je suis un fan inconditionnel de Talos, une distribution minimaliste pour installer des noeuds Kubernetes facilement, le tout via une API pour maintenir et administrer les machines. Si le sujet vous intéresse, je vous invite à lire mon article sur Talos ou un talk que j’ai pu donner à la TouraineTech 2025. Ainsi, j’utilise Talos sur : 

  • Mon dédié OVH (en single-node cluster).
  • Des VMs sur mes N100 pour des petits clusters de test (on en reparle juste après, ça a très récemment changé).
  • Chaque noeud de mon Turing Pi 2 (les RK1).

Bref, j’ai du Talos de partout ! Pour les administrer, j’auto-héberge un serveur Omni. C’est une application vers laquelle toutes mes machines Talos communiquent pour envoyer leurs logs, mais également pour recevoir des instructions. Ainsi, je peux installer un cluster sans toucher aux machines, directement via Omni. En plus de pouvoir piloter les machines, je peux aussi accéder à l’API-Server de mes clusters via des kubeconfig générés par Omni, ils sont exempts de certificats et ne fonctionnent qu’avec de l’OIDC (via Authentik dans mon cas). C’est d’ailleurs avec ça que je gère qui peut accéder à quel cluster et avec quel rôle.

La seule limitation d’Omni face à ClusterAPI est qu’il ne peut pas déployer lui-même des machines Talos en se connectant à un Cloud ou à un hyperviseur… pour l’instant ! Sidero (Talos) travaillent sur des “infra-providers” pour répondre à ce besoin. Nous avons en setup un en live sur la chaine CuistOps pour controller un KubeVirt. À présent, je peux déployer des VMs Talos automatiquement depuis Omni pour des clusters de test (et c’est vraiment cool), plus besoin d’utiliser mes N100 pour ça.

Kubernetes

Je ne vais pas faire la liste des services que j’auto-héberge (ça risque d’être ennuyant, vous retrouverez les classiques : Bitwarden, adguard…), mais vous pouvez directement checker mon dépôt GitOps. Il contient toutes les configurations de mes clusters (modulo quelques applications gérées ailleurs), il comprend :

  • Les configurations de mes clusters Talos via Omni (CNI, IPPool, Manifests de Bootstrap, etc).
  • Les applicationSets ArgoCD pour créer automatiquement les “applications” pour chaque cluster (chacun ayant son propre répertoire).
  • Les applications ArgoCD couplées à un plugin pour la gestion des secrets (Vault).

Chaque cluster a son propre Vault pour stocker ses secrets. La création de ces instances est documentée dans le dépôt. J’utilise ArgoCD-Vault-Plugin pour injecter les secrets dans les manifests avec une syntaxe spécifique.

L’intérêt de tout ça est de diminuer la charge de travail pour maintenir mes clusters, je n’ai qu’à push sur le dépôt pour déployer une nouvelle application ou mettre à jour une application existante. Renovate me propose régulièrement des Pull-Requests pour modifier les versions de mes charts.

Réinstaller un cluster me prends 20min (le bottleneck est surtout le téléchargement des images).

Mac Mini

Comme vu dans l’installation du Rack, il y a un Mac Mini au milieu de tout ça. C’est le serveur que j’utilise pour héberger un LLM local avec OLLaMa qui fonctionne très bien sur des modèles de taille moyenne. Même si j’ai beaucoup de mal avec Apple, je dois avouer que le Mac Mini semble mettre la barre très haute pour un serveur IA domestique (largement mieux que les cartes Nvidia Jetson qui, pourtant, coutent plus cher). Grâce à lui, j’ai pu reprendre mes projets sur Langchain.

Ce qui est incroyable avec cette machine, c’est l’ARM. La consommation électrique est très faible, presque négligeable par rapport à un serveur classique (on est entre 7 et 15W).

Full offline et suffisamment puissant pour faire tourner deepseek-r1 ou Gemma.

Je vais également l’utiliser pour faire du transcoding mais je n’ai pas encore eu le temps de faire des benchs.

Le futur

Avec mes 2 N100, mon Turing Pi 2 et mon Mac Mini, je pense avoir un setup qui me suffit très largement pour mes besoins actuels. Je n’ai pas non-plus parlé de mon NAS ou de ma configuration réseau, mais ça arrivera peut-être dans un prochain article. Les différents déménagements m’ont permis de tester différentes configurations et de voir ce qui me convenait le mieux, on verra ce qui change au prochain ! 😇

Petit bonus : le awtrix

L’année dernière, j’avais présenté le Awtrix. Il s’agit d’une matrice LED pouvant afficher un peu ce que l’on veut. Dans le cadre du MiniRack, j’y affiche la puissance electrique consommée par les appareils (via Home-Assistant) et le nombre de pod sur le cluster du TuringPi (via un petit cron en Golang). C’est pas grand-chose pour le moment, mais c’est toujours marrant de voir ces informations en un coup d’oeil. De plus, j’ai toujours en tête de continuer le développement d’un petit script pour afficher mes alertes Prometheus sur le Awtrix (Lien du git).