Minihubs et mmh · 3. Déployer
Le même catalogue,
sur votre machine.
On choisit une application, on choisit une machine. Le Hub pousse l’ordre dans le tunnel ; le minihub tire l’image et démarre le conteneur, chez vous.
Installer une application sur le Hub, c’est un catalogue et quelques champs. L’installer sur une machine distante, c’est le même geste. La différence est invisible pour l’utilisateur : l’ordre voyage dans le tunnel que le minihub a ouvert, et le conteneur tourne sur sa machine.
À quoi ça sert
- Rapprocher le calcul des données. Le programme tourne sur la machine qui a les fichiers, la base ou la carte graphique.
- Garder un seul catalogue. Pas de procédure à part pour les machines distantes.
- Publier sans exposer. L’adresse publique pointe vers le Hub ; la machine reste invisible.
Ce qu’on voit à l’écran
Relevée le 2026-09-23. Le titre dit la cible : Déployer sur minihub-mini001. Dessous, l’identifiant technique de la machine, flouté.
Le cadre « Catalogue d’apps ». À droite, 32 apps disponibles. La consigne : « Cliquez sur une app pour pré-remplir le formulaire ci-dessous. » Le formulaire est plus bas, hors de la capture.
Les cartes. Chacune donne le nom, une ligne de description, l’identifiant de catalogue en gris à droite, et trois étiquettes :
3rd-partyousocle: une application tierce (WordPress, Gitea, Grafana, Nextcloud, pgAdmin, phpMyAdmin, n8n, Uptime Kuma…) ou une application construite sur le Socle (Mon Espace, Suite Office, NotionSocle, DataApp, AgentIA, AppDemo, ReverseProxyTheSocle…).db: postgresoudb: mysql: la base dont l’application a besoin. Grafana ou Uptime Kuma n’en déclarent pas.- le port du conteneur :
:80,:3000,:5678,:3001,:8080.
C’est le même catalogue que celui du Hub. Le menu de gauche le rappelle : Deployer installe sur le Hub, Mini-hubs mène ici.
Comment ça marche
On choisit l’application et son exposition
Trois modes. Interne : l’application n’est joignable que par le tunnel. Publiée : elle reçoit une adresse publique. Les deux. Le Hub vérifie d’abord que le sous-domaine est libre.
Le Hub prépare l’adresse
Pour une application publiée, il crée l’entrée DNS, demande le certificat, puis la route de son proxy. Cette route ne vise pas une adresse IP : elle vise un minihub et un nom de conteneur.
Le Hub pousse l’ordre d’installation
Un InstallAppCommand part dans le flux de commandes du minihub. Chaque ordre porte un numéro de version qui ne fait que croître : un ordre rejoué est refusé.
Le minihub installe
Il publie l’ordre sur son NATS JetStream local. Son worker Docker se connecte au registre, tire l’image, crée et démarre le conteneur, et inscrit l’application dans sa base locale.
L’application est servie par le Hub
Une requête arrive sur l’adresse publique. Le proxy du Hub pousse la requête dans le tunnel ; le minihub appelle le conteneur sur son réseau Docker interne et renvoie la réponse. Sans réponse en 30 secondes, le Hub répond 504.
Elle se pilote à distance
Arrêter, redémarrer, désinstaller, lire l’état : depuis la console du Hub, par le même tunnel.
Un exemple réel. En juin 2026, une application de démonstration tournait dans un seul conteneur sur minihub-mini001, servie à la fois sous thesocle.net et sous thesocle.io. Le minihub était rattaché aux deux Hubs. Il tient un compteur : désinstaller depuis un Hub retire ce Hub ; le conteneur n’est détruit qu’au départ du dernier.
Sous le capot
| Écran | /hub/minihubs/<id>/deploy |
| API | POST /api/minihub/install (minihub_id, app_id, app_version, docker_image, target_mode = internal_only, published_only ou dual, subdomain, ports, env_vars) ; GET /api/minihub/check-hostname |
| Pipeline publié | réservation, DNS, certificat ACME, InstallAppCommand, route target_type = minihub, finalisation |
| Anti-rejeu | version de configuration monotone par minihub |
| Sur la machine | NATS JetStream, worker Docker, table apps_local.tr_deployed_app, volumes et commande passés par le manifeste |
| Multi-Hub | referencing_hubs[] : une référence par Hub, destruction au dernier retrait |
À savoir : les actions MCP install_app et update_app du docker_worker visent le Hub lui-même. Pour une machine distante, c’est l’API ci-dessus, ou l’écran.
Les limites, aujourd’hui
- L’image doit être dans un registre que la machine peut lire : le minihub la tire toujours.
- Une application lancée à la main sur la machine, hors de ce chemin, n’apparaît pas dans la console et ne se pilote pas. Elle peut être adoptée ensuite.
- Pas d’ouverture de port sur la machine : c’est voulu, et une application ne doit pas en publier.