Décrire tout votre serveur dans un seul fichier avec NixOS
Votre serveur tourne, mais sa description n'existe nulle part : qui peut s'y connecter, ce qui tourne dessus, quels ports sont ouverts, où vit la vraie donnée. Tout est dans votre tête ou dans un historique de commandes. Le jour où il faut recréer la machine ailleurs, ou simplement l'expliquer à quelqu'un d'autre, vous administrez de mémoire.
Cette masterclass vous donne la méthode des cinq blocs : décrire l'intégralité de votre serveur dans un seul fichier de configuration NixOS, lisible par un humain non spécialiste, que vous pouvez relire, versionner et rejouer pour recréer la machine à l'identique.
Ce que cet exercice ne peut pas casser
Tout l'exercice se fait sur une feuille. Le prompt, lui, rédige un fichier que vous relisez avant de l'appliquer : rien ne touche votre serveur tant que vous n'avez pas validé le récapitulatif et lancé vous-même la commande. Au pire, vous repartez avec une liste de questions sans réponse, et c'est déjà précieux.
Ce que vous saurez faire à la fin
- Découper n'importe quel serveur en cinq blocs : l'accès, les services, le réseau, les paquets, les données et la sauvegarde.
- Poser sur une page le plan complet de votre machine, y compris les trous que vous ne savez pas encore remplir.
- Obtenir un fichier de configuration relisible, versionnable et rejouable, qui devient la mémoire écrite de votre serveur.
- Niveau membre· le prompt prêt à coller qui transforme votre plan des cinq blocs en fichier de configuration complet, commenté en français, sans inventer une seule valeur.
- Niveau Pro· je relis votre plan et votre fichier avec vous, bloc par bloc, avant que vous ne l'appliquiez.
Un seul fichier, cinq blocs : chacun répond à une question précise sur votre machine.
Cinq blocs, cinq doutes, un seul fichier
Décrire un serveur entier semble impossible. La méthode tient en une idée : toute machine, quel que soit l'hébergeur, se décrit en cinq blocs, et chaque bloc répond à un doute précis. Quand les cinq blocs sont couverts, le fichier est complet : il se relit, se versionne, et se rejoue pour recréer le serveur à l'identique. La règle d'or qui traverse tout : aucune valeur inventée, jamais. Ce qui manque devient une question, pas un trou comblé au hasard.
1L'accès : qui se connectedoute : « qui peut entrer chez moi ? »
Le premier bloc déclare qui se connecte : votre nom d'utilisateur et votre clé SSH publique, rien d'autre. La règle est stricte : accès par clé uniquement, jamais de mot de passe, et jamais de clé inventée ou recopiée d'un exemple. À la main : notez le nom d'utilisateur que vous utilisez réellement et localisez votre clé publique. Si vous ne savez pas où elle est, c'est déjà une découverte utile.
2Les services : ce qui tournedoute : « qu'est-ce qui tourne vraiment ? »
Le deuxième bloc liste tout ce qui doit tourner en permanence : serveur web, base de données, tâches planifiées. Chaque service est déclaré de façon native quand c'est possible, avec son nom et ses réglages essentiels. À la main : listez chaque programme dont l'arrêt se remarquerait. Si vous hésitez sur un nom ou un réglage, c'est une question à poser, pas une valeur à deviner.
3Le réseau : ouvert ou fermédoute : « qu'ai-je laissé ouvert ? »
Le troisième bloc applique une règle simple : tout est fermé par défaut, et seuls les ports explicitement autorisés s'ouvrent. Chaque port ouvert s'explique en une ligne. À la main : pour chaque port que vous croyez ouvert, écrivez à quoi il sert. Un port que vous ne savez pas expliquer n'a rien à faire ouvert.
4Les paquets : les outils disponiblesdoute : « d'où vient cet outil ? »
Le quatrième bloc déclare les outils disponibles sur la machine : la liste que vous donnez, rien d'office. Un outil indispensable qui manquerait peut vous être proposé, mais jamais ajouté sans votre accord. À la main : listez les outils que vous utilisez vraiment quand vous vous connectez au serveur, pas ceux qui traînent par habitude.
5Les données et la sauvegarde : ce qui doit survivredoute : « qu'est-ce qui doit survivre ? »
Le cinquième bloc sépare ce qui se recrée en rejouant le fichier de ce qui doit survivre : les chemins qui contiennent de la vraie donnée. La stratégie de sauvegarde s'écrit en clair, en commentaire, jamais inventée. À la main : notez chaque chemin dont la perte serait irrécupérable, et comment il est sauvegardé aujourd'hui. Si la réponse honnête est « il ne l'est pas », écrivez-le tel quel.
À vous de jouer : le plan des cinq blocs
Prenez une feuille, cinq sections, une par bloc. C'est la matière exacte que le prompt attend.
Le résultat, en 30 secondes
À partir de votre plan (ou de l'interview bloc par bloc si vous partez de zéro), le prompt produit quatre choses : un récapitulatif des cinq blocs pour validation, le fichier complet commenté en français, la liste de ce que vous devez vérifier vous-même, et la commande exacte pour appliquer le fichier.
Récapitulatif : Accès, un utilisateur, clé uniquement. Services, un serveur web et une base de données. Réseau, deux ports ouverts, expliqués. Paquets, six outils. Données, deux chemins à sauvegarder. Puis le fichier, bloc par bloc, chaque bloc précédé d'une phrase en français qui dit à quoi il sert. En bas : trois valeurs à confirmer avant d'appliquer, et la commande à lancer, expliquée en une phrase.
Le prompt prêt à coller
# RÔLE Tu es un ingénieur système expert de NixOS, rigoureux et pédagogue. Tu écris des fichiers de configuration déclaratifs lisibles par un humain non spécialiste. Tu ne t'appuies QUE sur ce que je te donne. Tout ce qui manque (une clé, un nom de service, un port), tu me le demandes explicitement : tu n'inventes jamais une valeur, et tu signales clairement chaque endroit où tu as fait une hypothèse. # CONTEXTE Je veux décrire l'intégralité de mon serveur dans un seul fichier de configuration, organisé en cinq blocs : l'accès (qui se connecte), les services (ce qui tourne), le réseau (ce qui est ouvert ou fermé), les paquets (les outils disponibles), les données et la sauvegarde (ce qui doit survivre). L'objectif est un fichier que je peux relire, versionner, et rejouer pour recréer mon serveur à l'identique. Ma matière (si j'en ai) : [collez ici votre plan des cinq blocs, vos services actuels, votre nom d'utilisateur, votre clé SSH publique, le nom de domaine, le nom de votre hébergeur. Laissez vide si vous partez de zéro.]
Le prompt transforme votre plan des cinq blocs en fichier de configuration NixOS complet, commenté en français, sans inventer une seule clé, un seul port ni un seul nom, et vous interroge bloc par bloc si vous partez de zéro. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Vous reprenez le serveur d'un confrère : un port est ouvert et personne ne sait pourquoi. Avec la méthode des cinq blocs, où cette information aurait-elle dû vivre, et selon quelle règle ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
En une phrase, à un confrère qui administre son serveur commande par commande : qu'est-ce que ça change de décrire toute la machine dans un seul fichier qu'on peut relire et rejouer ? Si vous savez le dire simplement, c'est à vous.
Ce que vous savez faire maintenant
- Décrire n'importe quel serveur en cinq blocs : accès, services, réseau, paquets, données et sauvegarde.
- Transformer les trous de votre configuration en questions explicites plutôt qu'en valeurs inventées.
- Tenir un fichier unique, relisible et versionnable, qui recrée votre serveur à l'identique.
Ce fichier devient la mémoire vivante de votre serveur, celle qu'Arnaud n'avait pas.
Faites-le avec moi
Je construis le fichier avec vous, bloc par bloc, et nous le relisons ensemble avant de l'appliquer sur votre serveur. Vous arrêtez d'administrer de mémoire.