Cette infrastructure héberge plusieurs applications web sur une seule machine, avec une règle de fonctionnement unique : on ne lui donne pas des ordres, on lui décrit un état. Voici comment elle est agencée, et ce que cette règle change concrètement.
Trois couches, trois rôles
L'ensemble tient sur une machine physique, découpée en trois niveaux qui ne se mélangent jamais.
- L'hyperviseur isole la plateforme du reste de la machine : elle vit dans une machine virtuelle, sur un réseau privé, avec ses propres ressources. Le poste hôte peut faire autre chose sans jamais interférer.
- Le système invité ne sert qu'à une chose : faire tourner l'orchestrateur. Adresse fixe, aucun service applicatif installé directement dessus.
- L'orchestrateur — une distribution Kubernetes allégée — porte les applications. C'est lui qui démarre les conteneurs, leur attribue du stockage, les redémarre s'ils tombent et les expose au réseau.
Cette séparation a une conséquence pratique : une application n'est jamais « installée » sur le serveur. Elle est déclarée, puis exécutée dans un conteneur que l'orchestrateur peut détruire et recréer à l'identique à tout moment.
Une seule porte d'entrée pour toutes les applications
Les applications n'ont pas d'adresse propre. Toutes les requêtes arrivent sur un même point d'entrée — un reverse-proxy qui écoute les ports web de la machine — et c'est lui qui décide de la destination.
Son critère de décision est le nom demandé par le navigateur. Une requête vers wiki.k3s.ev1.fr et une autre vers supervision.k3s.ev1.fr arrivent sur la même adresse IP, sur le même port ; le proxy les distingue par leur en-tête, puis relaie chacune vers le bon conteneur.
Deux conséquences en découlent :
- ajouter une application ne demande ni nouvelle adresse IP, ni nouveau port ;
- côté DNS, un seul enregistrement générique — *.k3s.ev1.fr — suffit pour toutes les applications, y compris celles qui n'existent pas encore. Le DNS n'a plus jamais à être modifié.
Une application déployée par simple copie de fichier, servie sur https://wiki-guillaume.k3s.ev1.fr — sans configuration de proxy ni certificat dédié.
Le chiffrement, propriété de l'infrastructure
Puisque toutes les requêtes passent par le même point d'entrée, c'est là que le chiffrement est traité — et non dans chaque application. Le proxy détient un certificat unique valable pour tout le domaine, présente ce certificat quel que soit le sous-domaine demandé, et renvoie systématiquement vers HTTPS toute requête arrivée en clair.
Autrement dit, une application n'a pas à « savoir faire » du HTTPS, ni à disposer d'un certificat : elle est chiffrée parce qu'elle est hébergée ici. Ce n'est plus une tâche, c'est une propriété.
Le principe central : la boucle de réconciliation
C'est le cœur du fonctionnement. Un répertoire de la machine contient un fichier par application : quelques lignes qui disent quelle image exécuter, sur quel port, avec quel stockage. Ce répertoire est la référence — la vérité de ce qui doit tourner.
Un composant compare en permanence deux choses :
- l'état décrit par les fichiers ;
- l'état réel du cluster.
Dès qu'ils divergent, il agit pour les faire coïncider. Un fichier ajouté ? L'application est créée, avec tout ce qu'elle suppose : son espace isolé, son stockage, ses conteneurs, son service interne et sa règle de routage. Un fichier modifié ? L'application est mise à jour. Un fichier supprimé ? L'application disparaît, proprement.
La comparaison est déclenchée immédiatement à chaque modification du répertoire, et rejouée périodiquement — la seconde n'étant que le filet de sécurité de la première.
La différence avec un script d'installation est essentielle : un script s'exécute une fois et son résultat se dégrade avec le temps. Une boucle de réconciliation, elle, ramène en permanence le système vers l'état voulu. Elle ne se contente pas d'installer : elle répare.
Ce que produit une déclaration de quelques lignes
Le fichier déposé par l'utilisateur reste volontairement pauvre : un nom, une image de conteneur, un port, éventuellement un volume et quelques variables. Tout le reste en est déduit :
- un espace isolé propre à l'application ;
- un espace de stockage persistant, qui survit à la destruction et à la mise à jour des conteneurs ;
- les conteneurs eux-mêmes, surveillés et redémarrés en cas de défaillance ;
- un service interne, adresse stable à l'intérieur du cluster ;
- une règle de routage qui publie l'application en HTTPS sous son propre nom.
Le nom du fichier joue un double rôle : il identifie l'application dans le cluster et détermine son adresse publique. Nommer, c'est publier.
Pourquoi ça tient tout seul
Tout l'état de la plateforme se résume à un répertoire de fichiers texte. Cela explique trois comportements :
- Au redémarrage, rien n'est à refaire : l'orchestrateur redémarre avec le système, la boucle relit les fichiers et republie les applications.
- En cas de dérive — une ressource supprimée par erreur, une modification manuelle —, la réconciliation suivante rétablit l'état décrit.
- En cas de sinistre, reconstruire consiste à réinstaller la plateforme, puis à restaurer ce répertoire et les données. L'historique des commandes tapées un jour sur la machine n'a aucune importance.
L'idée à retenir
Aucune des briques employées n'est exotique : virtualisation, orchestrateur, reverse-proxy, certificat. Le fonctionnement tient à la manière dont elles sont articulées : une seule porte d'entrée qui route par nom, un domaine générique qui absorbe toutes les nouveautés, un chiffrement porté par l'infrastructure, et une boucle qui fait converger le réel vers l'écrit. C'est ce qui permet de ramener la mise en ligne d'un service à la rédaction de quelques lignes — et surtout de ne pas avoir à s'en souvenir six mois plus tard.