Multi-serveur

Rattachez d'autres serveurs que vous possédez à une installation sh0 et faites-y tourner une partie de vos applications. Le serveur principal garde le tableau de bord, les constructions et le routage.

Prérequis

• Une licence Business et le rôle admin ou owner : sans eux, toutes les routes des nœuds sont refusées.
• Sur le serveur distant : Docker installé et démarré. sh0 n'y installe rien.
• Un accès SSH du serveur principal vers le serveur distant, avec un utilisateur qui peut se servir du socket Docker (/var/run/docker.sock) : root, ou un membre du groupe docker.
• Soit une clé SSH enregistrée au préalable dans le tableau de bord (gestion des clés SSH), soit le mot de passe de l'utilisateur.

Fonctionnement

• Le serveur principal garde la base de données, le tableau de bord et Caddy. Un nœud ne fait qu'exécuter des conteneurs ; sh0 pilote son Docker à travers un tunnel SSH.
• Les images sont toujours construites sur le serveur principal, puis transférées au nœud (le déploiement affiche l'étape transferring).
• Les domaines pointent toujours vers le serveur principal. Son Caddy transmet chaque requête au conteneur du nœud par un relais porté par le même tunnel SSH.
• Les noms internes (my-api.internal) ne résolvent qu'à l'intérieur d'un même serveur : une application placée sur un nœud ne joint pas par ce nom un service du même projet situé sur un autre serveur. Le journal de construction le signale quand un projet s'étend sur plusieurs nœuds.

Ajouter un nœud

1. Dans le tableau de bord, ouvrez Nœuds, puis Ajouter un nœud.
2. Donnez un Nom (minuscules, chiffres et tirets, 64 caractères au plus) et le Nom d'hôte (adresse IP ou nom DNS ; localhost et les adresses de bouclage sont refusés).
3. Indiquez le Port SSH (22 par défaut), le Nom d'utilisateur (root par défaut) et l'Authentification : Clé SSH ou Mot de passe.
4. Enregistrez, puis utilisez Tester la connexion : sh0 vérifie la connexion SSH et Docker sur le nœud.

En ligne de commande (nodes create accepte --port pour un port SSH non standard, et --password à la place de --ssh-key) :

sh0 nodes create --name worker-1 --host 203.0.113.20 --ssh-user root --ssh-key <ssh-key-id>
sh0 nodes list
sh0 nodes info <node-id>
sh0 nodes test <node-id>

Par l'API :

curl -X POST https://panel.example.com/api/v1/nodes \
  -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"worker-1","hostname":"203.0.113.20","port":22,"username":"root","auth_method":"ssh_key","ssh_key_id":"<ssh-key-id>"}'

• port, username et auth_method sont facultatifs (22, root, ssh_key). Avec "auth_method":"password", envoyez password au lieu de ssh_key_id ; il est conservé chiffré.
• Depuis 1.10.3 : sh0 tente la connexion dès la création du nœud : le statut passe à online en cas de succès, à error avec le message en cas d'échec. La tentative est bornée à 15 secondes : sur une adresse qui ne répond pas, le nœud est enregistré en error et la CLI sort avec le code 1, en indiquant nodes test pour réessayer et nodes delete pour le retirer.
• La clé d'hôte SSH du nœud est enregistrée à la première connexion, puis vérifiée. Si le serveur est réinstallé, sa clé change et la connexion est refusée : réinitialisez l'empreinte (POST /api/v1/nodes/<id>/reset-fingerprint) pour que la connexion suivante enregistre la nouvelle clé.

Déployer sur un nœud

À la création d'une application depuis un dépôt Git, un Dockerfile, une image Docker, un framework ou une archive, le champ Nœud cible choisit le serveur ; par l'API, envoyez node_id (l'identifiant ou le nom du nœud). Une valeur vide désigne le serveur principal ; une valeur qui ne correspond à aucun nœud est refusée plutôt que déployée en silence sur le principal.

Déplacer une application

On déplace une application en changeant son node_id avec PATCH /api/v1/apps/<id>. L'application doit d'abord être arrêtée ; sinon le changement est refusé, car son conteneur resterait en marche sur l'ancien serveur. Une chaîne vide ramène l'application sur le serveur principal.

curl -X PATCH https://panel.example.com/api/v1/apps/<app-id> \
  -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
  -d '{"node_id":"worker-1"}'

Redéployez ensuite l'application : l'image est construite sur le principal et transférée au nouveau nœud. Le conteneur de l'ancien nœud n'est pas migré, et les données des volumes ne suivent pas : copiez-les vous-même.

État des nœuds

Nœuds liste chaque serveur avec son état (En ligne, En attente, Erreur, Hors ligne), sa version de Docker, son CPU et sa mémoire, et le dernier contact. Un moniteur revérifie les nœuds toutes les 30 secondes et rouvre les relais des applications en marche après une reconnexion.

Retirer un nœud

Un nœud ne se retire que lorsqu'aucune application ne lui est plus affectée : « Cannot delete node: N app(s) still assigned. Migrate them first. » Déplacez ou supprimez d'abord ces applications, puis supprimez le nœud depuis Nœuds, avec sh0 nodes delete <id-du-nœud> ou DELETE /api/v1/nodes/<id>.

Limites

• Le principal est un point de défaillance unique. S'il s'arrête, le tableau de bord, les constructions et le routage vers tous les nœuds s'arrêtent avec lui.
• Tout le trafic passe par le principal. Les requêtes atteignent un nœud par le relais SSH ; dimensionnez la bande passante du principal en conséquence.
• Pas de placement automatique. sh0 ne choisit pas de nœud à votre place et ne répartit pas les répliques entre les nœuds : chaque application tourne sur un seul serveur.
• Ni vidage ni migration automatique. Vider un nœud, c'est arrêter, déplacer et redéployer ses applications une à une.
• Pas de réseau entre serveurs. Voir les noms internes plus haut.
• Utilisez l'identifiant du nœud en ligne de commande. sh0 nodes test, info et delete annoncent « Node ID or name », mais en v1.10.2 seul l'identifiant est trouvé.