Runfold

Un vrai tuto, court, qui utilise chaque fonctionnalité du site. C'est la page où atterrit la visite guidée, et la référence quand on en écrit de nouveaux.

1. 01BrouillonSécuriser l'accès SSH d'un serveur neufDix minutes après la livraison, avant toute autre chose : un compte personnel, connexion par clé uniquement, un port non standard, un pare-feu, et un bannissement du brute force.débutant· ~10 min de manipulation

De quelques machines Linux à un petit cluster k3s digne de la prod, puis une vraie application web dessus — indicat, le prototype SaaS de thudal — avec base de données, TLS et déploiement continu.

1. 01BrouillonMonter un cluster k3sD'une à trois machines Ubuntu à un Kubernetes qui marche : k3s figé sur une version, kubectl et helm sur ton portable, l'ingress Traefik livré avec, cert-manager et un ClusterIssuer, puis un hello-world derrière HTTPS pour prouver toute la chaîne.intermédiaire· ~40 min de manipulation
2. 02BrouillonDéployer indicatUne vraie application web sur le cluster : un namespace, ses secrets, PostgreSQL (opérateur ou StatefulSet), le Deployment avec sondes et limites, les migrations, un Service, un Ingress avec TLS sur ton domaine, et un autoscaler.intermédiaire· ~50 min de manipulation
3. 03BrouillonDéployer à chaque push avec la CIUn ServiceAccount qui ne peut toucher qu'à ton namespace, son kubeconfig en secret de CI, et un pipeline qui construit l'image à chaque push, la tague avec le commit, et la déploie.intermédiaire· ~35 min de manipulation

NetBox est la source de vérité de ton réseau : équipements, IP, câbles, circuits. Cette série part d'un serveur vierge et va jusqu'au maintien et à l'automatisation.

1. 01BrouillonInstaller NetBox de zéroD'un serveur Linux vierge à une instance NetBox derrière HTTPS, prête pour les utilisateurs. PostgreSQL, Redis, NetBox lui-même, gunicorn, puis le serveur web de ton choix.intermédiaire· ~45 min de manipulation
2. 02BrouillonConfigurer NetBox pour ton équipeLes réglages à faire avant d'ouvrir NetBox aux collègues : fuseau et bandeaux, envoi de mail, groupes et permissions, premiers plugins, et les champs personnalisés dont tes données ont besoin.intermédiaire· ~40 min de manipulation
3. 03BrouillonMaintenir et mettre à jour NetBoxDes sauvegardes nocturnes que tu as restaurées au moins une fois, une mise à jour que tu sais annuler, la tâche d'entretien, la rotation des logs, et une sonde qui dit si NetBox est vivant.intermédiaire· ~35 min de manipulation
4. 04BrouillonAutomatiser NetBox par l'APIUn utilisateur d'automatisation aux droits bornés, pynetbox ou curl pour lire et écrire, un import CSV qui survit aux erreurs, des webhooks sur les changements d'équipements, et un script maison lancé par l'API.intermédiaire· ~45 min de manipulation

Un lab réseau que tu reconstruis en quelques minutes : une topologie containerlab, NetBox comme source de vérité, la configuration générée et poussée depuis lui, et un pipeline CI qui prouve chaque changement avant qu'il n'atteigne le lab.

1. 01BrouillonUn lab réseau avec containerlabDocker et containerlab sur une machine Linux, une image d'OS réseau, un spine et deux leaves câblés ensemble, une première configuration d'interface, et le tout dans un dépôt git.débutant· ~30 min de manipulation
2. 02BrouillonModéliser le lab dans NetBoxCe qui a sa place dans une source de vérité et ce qui n'y a pas, puis un script pynetbox qui crée le site, les équipements, leurs interfaces, adresses et câbles, et un config context avec les numéros BGP. Rejouable sans risque.intermédiaire· ~40 min de manipulation
3. 03BrouillonGénérer et pousser les configs depuis NetBoxUn inventaire lu depuis NetBox, un template Jinja2 par OS réseau, un rendu qui écrit un fichier par équipement, un push précédé d'un dry-run, et BGP établi entre le spine et ses leaves sans taper une seule adresse.intermédiaire· ~45 min de manipulation
4. 04BrouillonValider chaque changement en CIUne étape de lint sur un runner hébergé, une étape lab sur un runner auto-hébergé qui déploie la topologie, rend, pousse, lance un pytest avec scrapli et démonte toujours, des artefacts, et une branche main protégée qui ne fusionne que ce que le pipeline a prouvé.avancé· ~40 min de manipulation

D'un projet Next.js sur ton portable à un site servi en HTTPS depuis ton propre VPS Debian chez OVH, avec un domaine géré chez Infomaniak, des déploiements atomiques, des sauvegardes et une surveillance. Huit pages, dans l'ordre où tu les fais.

1. 01BrouillonPréparer ton portableAvant de commander quoi que ce soit : le site se construit proprement à partir de zéro, tu sais ce que tu vas envoyer, le dossier du projet (le seul original du site) est sauvegardé, et ssh sur ton Mac garde les phrases de passe dans le trousseau. La clé SSH du serveur se crée à la page suivante.débutant· ~20 min de manipulation
2. 02BrouillonCommander le VPS chez OVHUn VPS Debian 13 commandé dans l'espace client OVH, livré, et joignable sous l'utilisateur debian avec une clé SSH créée pour lui (~/.ssh/id_ed25519_vps), sa moitié publique dans le panneau des valeurs. Ses IPv4 et IPv6 sont notées, et le compte OVH qui le contrôle est protégé par une double authentification.débutant· ~15 min de manipulation
3. 03BrouillonSécuriser le serveur dans la première heureDu compte `debian` livré par OVH à ton propre compte admin avec une clé et un mot de passe sudo, SSH sur son propre port sans mot de passe ni root, un pare-feu, le bannissement du brute force, et des mises à jour de sécurité qui s'installent seules. Chaque verrou est testé avant de fermer l'ancienne porte.intermédiaire· ~30 min de manipulation
4. 04BrouillonPointer le domaine vers le serveur (DNS Infomaniak)Ton domaine et son www répondent avec le VPS en IPv4 et IPv6, seul Let's Encrypt (et ZeroSSL si tu veux) peut émettre des certificats pour lui, et personne ne peut envoyer d'email en son nom — ou ta boîte Infomaniak continue de marcher, avec DMARC en plus. Des clics dans le Manager, des vérifications avec dig.débutant· ~20 min de manipulation
5. 05BrouillonServir le site avec Caddy et HTTPSCaddy installé depuis son dépôt officiel, qui sert une page d'attente depuis la racine web en HTTPS, avec un certificat Let's Encrypt qu'il renouvelle tout seul. www et le HTTP simple redirigent vers le domaine nu (sans rien devant), HTTP/3 est actif, les en-têtes de sécurité et le cache sont réglés, les logs d'accès tournent.intermédiaire· ~20 min de manipulation
6. 06BrouillonDéployer des versions atomiques avec rsyncUne commande sur ton portable construit le site, envoie seulement ce qui a changé dans un nouveau répertoire de version, bascule le site en ligne dessus en une seule étape atomique, garde les dernières versions et vérifie le résultat. Le retour arrière tient aussi en une commande.intermédiaire· ~30 min de manipulation
7. 07BrouillonSauvegardes, surveillance et la routine mensuelleSavoir ce qui mérite d'être sauvegardé sur le serveur, et ce qui ne le mérite pas. Une copie chiffrée hors site faite chaque nuit par restic, avec une restauration réellement testée ; un email quand le site tombe ou que la sauvegarde n'a pas tourné ; des logs qui ne peuvent plus remplir le disque ; et dix minutes de vérification une fois par mois.intermédiaire· ~40 min de manipulation
8. 08BrouillonChecklist de lancementAvant d'annoncer le site : robots.txt et sitemap.xml générés par Next.js, les fichiers les plus lourds allégés, et tout ce que les pages précédentes ont mis en place vérifié depuis l'extérieur — redirections, 404, certificat, en-têtes, IPv6, HTTP/3, performance — avec un script qui affiche PASS ou FAIL.débutant· ~30 min de manipulation

D'un VPS Debian durci (pages 1 à 3 de « Un site statique sur un VPS OVH ») à un serveur qui ne répond à personne sur internet sauf à tes propres appareils, à travers un tunnel WireGuard que tu tiens toi-même : aucun tiers sur le chemin, un seul port UDP ouvert, chaque service joignable uniquement de l'intérieur.

1. 01BrouillonOuvrir un tunnel WireGuard vers le serveurWireGuard en marche sur le serveur sur un port UDP, ton Mac (et ton téléphone si tu veux) connecté avec des clés générées sur chaque appareil, et ssh qui atteint le serveur par le tunnel sous un nouveau raccourci. Le port SSH public reste ouvert : la page 2 le ferme.intermédiaire· ~25 min de manipulation
2. 02BrouillonFermer la porte publiqueSSH retiré d'internet et gardé sur le tunnel seulement, vérifié depuis l'extérieur, prouvé après un redémarrage, avec le chemin du retour écrit avant d'en avoir besoin. Le seul port ouvert du serveur est désormais celui de WireGuard, qui ne répond rien à qui n'a pas de clé.intermédiaire· ~15 min de manipulation