Tout en entier, pas la première moitié.
Chaque guide prend une instance vide et la transforme en un service vers lequel vous pouvez envoyer du trafic réel. Les commandes s'exécutent de haut en bas dans l'ordre où elles sont imprimées, les espaces réservés sont marqués comme tels, et la dernière section est toujours un test. Aucun guide ici ne se termine par « puis configurez le reste à votre goût ».
Un guide n'est pas une entrée de base de connaissances
Les deux formats existent parce que chacun est mauvais pour le travail de l'autre. Mélangez-les et vous obtenez le genre de documentation qui explique ce que fait chaque drapeau sans jamais vous dire de quels drapeaux vous avez besoin.
La base de connaissances répond à une question en une minute. Un guide vous coûte un après-midi et laisse un serveur en fonctionnement à la fin.
Une entrée de base de connaissances commence par quelque chose que vous avez déjà et quelque chose qui ne va pas : un montage qui ne revient pas après le redémarrage, un certificat qui s'est renouvelé mais n'a pas rechargé, une console de secours dont vous ne pouvez pas obtenir d'invite. Elle est courte car le contexte est déjà dans votre tête. Vous arrivez avec le problème et repartez avec la réponse.
Un guide commence avec rien. Vous avez payé une facture, vous avez les identifiants root, et la machine est une image non configurée dans une ville que vous avez choisie pour vos propres raisons. À la fin, vous avez un serveur de messagerie qui réussit les contrôles d'authentification, ou un hyperviseur qui exécute des invités imbriqués, ou deux téraoctets situés dans un pays différent de celui où ils étaient ce matin. Le contexte se construit au fur et à mesure, c'est pourquoi ces guides font quelques milliers de mots plutôt que deux cents.
Les écrire de cette façon demande plus de travail et attrape plus d'erreurs. Chaque guide de cette page a été exécuté de bout en bout sur une instance fraîchement déployée avant publication, et réexécuté chaque fois qu'un projet en amont a publié quelque chose qui le cassait. La date en haut de chacun est la date de la dernière exécution, pas la date à laquelle quelqu'un l'a parcouru.
Une chose complète
Pas un tour d'horizon de six options et un haussement d'épaules. Chaque guide choisit une approche, explique pourquoi, et construit cela. Lorsqu'une alternative réelle existe, elle a droit à une phrase et un lien, puis le guide continue.
Des commandes qui s'exécutent en séquence
Copiez-les dans l'ordre imprimé sur une image fraîche et elles fonctionnent. Si l'étape neuf a besoin d'un paquet installé à l'étape deux, l'étape deux l'installe. Rien ne dépend d'un état que vous n'avez jamais été invité à créer.
Une machine nommée
Chaque construction indique la gamme sur laquelle elle a été écrite et ce qui se passe si vous utilisez quelque chose de plus petit. Un réglage Postgres qui suppose 64 Go d'ECC est un conseil inutile sur une machine de 16 Go, alors nous le disons en haut.
Le milieu ennuyeux
Propriété des fichiers, durcissement des unités systemd, règles de pare-feu, rotation des journaux. C'est la partie que la plupart des tutoriels sautent et la partie qui décide si le service est toujours debout en mars.
Un test à la fin
Chaque guide se termine par des commandes dont la sortie vous dit sans ambiguïté si la construction a fonctionné. Pas « vous devriez maintenant voir la page de connexion ». Quelque chose avec un code de sortie ou un en-tête que vous pouvez lire.
“Si la dernière ligne de la page est « et ensuite configurez votre pare-feu », ce n'est pas un guide, c'est une liste de courses.”
Comment suivre un guide sans y perdre une soirée
Ils sont écrits pour des personnes qui lisent toute la page avant de taper quoi que ce soit. Cette habitude vaut environ une heure par construction.
Partez d'une image Debian 13 fraîche et d'un shell root, sauf indication contraire. Tout le reste est précisé dans les deux premiers paragraphes.
- 01
Déployez quelque chose de neuf
Adapter un guide à une machine qui fait déjà tourner trois services, c'est ainsi qu'on découvre lequel utilisait silencieusement le port 8080. Une instance fraîche est à moins d'une minute et vous pouvez la détruire ensuite.
- 02
Lisez-le une fois en entier
En particulier les étapes DNS. La moitié des constructions ici nécessitent qu'un enregistrement ait été propagé avant qu'une commande ultérieure ne réussisse, et le meilleur endroit pour apprendre cela est à la première lecture plutôt qu'à l'étape onze.
- 03
Remplacez les espaces réservés
Tout ce qui ressemble à example.com, 2001:db8: ou <chevrons> est à remplacer. Les plages de documentation sont utilisées délibérément afin qu'une erreur de copier-coller échoue bruyamment au lieu d'atteindre silencieusement le réseau d'un inconnu.
- 04
Faites un instantané avant la partie irréversible
Repartitionnement, dist-upgrade, tout ce qui implique le mot « effacer ». Un pack d'instantanés vous donne cinq emplacements et une restauration qui se termine en quelques secondes, ce qui est moins cher que de répéter les étapes une à neuf.
- 05
Exécutez la vérification
C'est la dernière section de chaque guide et elle existe parce que « cela a semblé démarrer » n'est pas la même chose que « cela fonctionne ». Deux minutes de vérification valent mieux que de l'apprendre d'un utilisateur.
Rien sur cette page ne pipe un script distant dans un shell. Là où un projet en amont ne fournit son installateur que de cette façon, le guide montre comment le récupérer, le lire et l'exécuter comme fichier — vous devriez savoir ce qui s'est installé sur votre machine, et nous aussi.
Quelle machine chaque construction demande
La plupart de ces guides tournent sans problème sur l'instance Ryzen la plus petite. Quatre d'entre eux non, et choisir la mauvaise ligne pour ces quatre vous fait perdre un après-midi avant d'arriver à la partie intéressante.
Lorsqu'un guide nomme un plan, c'est celui sur lequel il a été testé. Choisir plus petit est généralement possible, et c'est signalé lorsque ce n'est pas le cas. Choisir plus grand ne change rien, sauf les chiffres que vous mettez dans les fichiers de configuration, et les guides qui tiennent compte de ces calculs les montrent.
| Build | Gamme | Pourquoi celle-ci |
|---|---|---|
| WireGuard, relais Tor, Matrix, surveillance | Ryzen R-4 | Monothread, lié au réseau, espace de travail minuscule. Plus de cœurs ne changent rien. |
| Serveur mail, runner CI, Nextcloud | Ryzen R-8 | Les étapes de compilation et l'antispam aiment tous deux les cœurs rapides. Les builds d'images sont ce qu'il y a de plus lourd ici. |
| Postgres | EPYC E-8 et au-delà | Le réglage de ce guide suppose 64 Go de mémoire ECC et un épinglage NUMA. |
| Inférence locale | GPU G-L40S | Quarante-huit gigaoctets de VRAM, en accès direct. Une carte partagée, c'est la file d'attente de quelqu'un d'autre. |
| Seedbox | Storage S-50 | Cinquante téraoctets de stockage de masse derrière un niveau d'écriture NVMe, sur un port assez large pour l'écouler. |
| Proxmox avec invités imbriqués | Bare metal BM-E | La virtualisation imbriquée nécessite la machine physique. Aucun de nos hyperviseurs ne s'interpose. |
| Déplacer deux téraoctets entre des sites | Deux instances quelconques | Rédigé pour un nœud de stockage et une machine Ryzen, mais la méthode est la même quelle que soit la taille. |
Chaque guide suppose le /64 IPv6 routé fourni avec chaque instance. Deux d'entre eux demandent le /48, car distribuer des sous-réseaux par client depuis un seul /64 implique de proxifier la découverte de voisins, et une IPv6 proxifiée est un outil de travail, pas quelque chose qu'on fait tourner.
Confidentialité
03Infrastructure
04Développement
02Réseau
02Questions sur les guides, plutôt que sur les builds
En grande partie, oui. Ce qui nous appartient, ce sont les étapes du panneau, le préfixe routé et l'hypothèse de cœurs dédiés. Tout le reste est du Debian standard et des logiciels amont, donc les commandes s'adaptent facilement à tout environnement où vous avez root et où le CPU n'est pas sur-vendu.
Parce que réécrire douze guides cinq fois de suite, c'est comme ça que la documentation devient obsolète. Debian 13 est notre image par défaut, les noms de paquets sont stables pendant des années, et traduire une étape vers AlmaLinux ou Alpine est une substitution de gestionnaire de paquets plutôt qu'une réécriture. La liste complète des images se trouve sur la page des systèmes d'exploitation.
Prévenez-nous. Les guides sont re-testés avec une image propre lorsque nous apprenons une panne, et la version corrigée sort la même semaine, avec la date du haut mise à jour. Un ticket avec la commande et l'erreur suffit ; vous n'avez pas besoin de diagnostiquer le problème pour nous.
Nous supportons la machine, le réseau et le stockage qui se trouvent dessous. Déboguer vos fichiers de configuration Postfix à trois heures du matin ne fait pas partie de cette liste, et nous serions de toute façon mauvais dans ce domaine. Le durcissement managé existe en option si vous voulez que quelqu'un d'autre maintienne la base.
Pour huit des douze, oui, et le R-4 est celui sur lequel plusieurs ont été rédigés. Les builds Postgres, inférence, seedbox et Proxmox nécessitent la ligne nommée dans le tableau ci-dessus ; le reste est confortable sur quatre cœurs dédiés et 16 Go.
Choisissez une ville, déployez, suivez le guide.
L'instance dont vous avez besoin pour la plupart de ces guides coûte moins cher que le café que vous boirez en la construisant. Payez en crypto, attendez environ quarante-sept secondes, puis commencez à l'étape une.