Gérer les instances SaaS

Le menu Instances SaaS (/hosting/instances) est réservé aux administrateurs et au groupe HOSTING_OPERATORS. Une instance SaaS est une instance du logiciel hébergée par ZAPP pour une organisation : une pile Docker (application et base de données) sur un hôte.

Déclarer un hôte

Écran Hôtes SaaS (/hosting/hosts) :

Code (ex. docker-prod1) et nom ;
adresse interne : nom ou adresse IP par lesquels la VM d'entrée joint les instances ;
interface de publication : adresse IP interne de l'hôte sur laquelle le port de chaque instance est publié, jamais une interface publique ;
domaine : les instances de l'hôte s'appellent identifiant.domaine ; vide, c'est le réglage global Hosting:DomainSuffix qui s'applique ;
agent Outpost : identifiant de l'agent installé sur l'hôte (écran Outposts) ; le Portail agit sur l'hôte uniquement par cet agent ;
capacité (nombre d'instances) et plage de ports attribués aux instances ;
reçoit de nouvelles instances : décoché, l'hôte garde ses instances mais n'en reçoit plus.

Contrôler l'hôte (liste des hôtes) vérifie la version de l'outil d'hôte et le stockage hors site des sauvegardes (S3 Scaleway, bucket zapp-hosting-backup, posé une fois sur l'hôte par son administrateur avec install.sh --s3). La colonne Dernier contrôle montre « Sauvegardes hors site » quand l'hôte a l'outil v8 et un stockage joignable ; chaque hôte est contrôlé de lui-même au moins une fois par jour. Sans ce contrôle réussi, une instance de client de l'hôte ne peut être ni mise à jour ni supprimée.

Déclarer la VM d'entrée

Écran VM d'entrée (/hosting/edges, bouton depuis Hôtes SaaS) : la VM d'entrée reçoit directement le trafic public des instances, sur sa propre adresse publique, porte les certificats et l'envoie au routeur de l'hôte de chaque instance.

Code (ex. zapp-edge1), nom et agent Outpost installé sur la VM ;
adresse IPv4 publique (IP failover de la VM) : cible des domaines personnalisés des clients ; vide, pas de domaine personnalisé ;
reçoit les routes des nouvelles instances : une seule VM d'entrée active à la fois.

Tant qu'aucune VM d'entrée n'est active, l'étape « Publier sur la VM d'entrée » est sautée : le nom public de l'instance n'est alors routé par aucune VM d'entrée. Resynchroniser les routes aligne la VM d'entrée sur toutes les instances dont l'adresse est publiée : à faire après sa mise en service (pour les instances déjà créées) ou après une intervention à la main. La colonne Dernière resynchronisation donne son issue et le nombre de routes en service.

Demander une instance

Bouton Demander une instance : organisation, produit (il fixe l'image installée et le produit de la licence ; liste du réglage Hosting:ProductImages), nature (client, bac à sable de l'Académie, démonstration), identifiant (3 à 40 caractères, minuscules, chiffres et tirets, qui devient le sous-domaine et ne change plus), nom affiché, e-mail de l'administrateur (premier administrateur de l'instance : il recevra le lien pour choisir son mot de passe), hôte (automatique : l'hôte actif le moins chargé dont le domaine convient), canal et, au besoin, la version ou le digest exact de l'image. Une instance de client suit toujours le canal stable : elle est créée sur une version publiée (la version courante de son produit, ou celle choisie), jamais sur une nightly ; une démonstration ou un bac à sable suit le canal nightly, sauf choix contraire.

Le domaine dépend de la nature : une démonstration ou un bac à sable va sur un hôte dont le domaine commence par lab. (client.lab.zapphost.com), une instance de client sur l'hôte de production (client.zapphost.com). Un hôte qui ne convient pas est refusé.

La demande réserve l'identifiant, l'hôte, un port libre et l'adresse publique, puis pose le plan de création : épingler l'image, préparer l'hôte, émettre les certificats, écrire la pile, la démarrer, installer l'instance, publier l'adresse, la publier sur la VM d'entrée, la licence, contrôles de fin. Chaque étape apparaît sur la fiche de l'instance avec son état, ses tentatives et un message.

Une demande dont la création n'a pas commencé peut être annulée : l'identifiant et le port redeviennent libres.

Lancer la création

Sur la fiche d'une instance demandée, Lancer la création envoie les étapes à l'hôte par son agent Outpost, une à la fois ; la fiche se met à jour chaque minute. Aujourd'hui, le Portail exécute : épingler l'image (canal stable : la version publiée ; canal nightly : étiquette du réglage Hosting:ImageTag, nightly par défaut, sauf digest imposé), préparer l'hôte, émettre les certificats, écrire la pile et la démarrer jusqu'à l'état sain, installer l'instance (son administrateur est créé et son serveur d'envoi d'e-mails réglé), publier l'adresse (le routeur de l'hôte sert https://identifiant.domaine), la licence (l'instance est rattachée au Portail ; une démonstration ou un lab reçoit sa licence d'essai : tous les modules, 2 sièges, 5 € de crédit IA, 14 jours) puis les contrôles de fin : l'adresse publique doit répondre « sain », et l'administrateur reçoit l'e-mail pour choisir son mot de passe. L'instance est alors prête. Une démonstration ou un lab dont la licence n'est pas chargée (image d'un autre produit, par exemple) s'arrête en échec avant cet e-mail.

Si l'étape d'installation indique « SMTP non réglé », l'hôte n'a pas encore les identifiants du service d'envoi : l'instance fonctionne, mais l'administrateur ne reçoit pas d'e-mail. Une instance de client est seulement rattachée : sa licence vient de sa commande.

Si une étape échoue, l'instance passe en échec avec le message de l'hôte ; Réessayer reprend à l'étape qui a échoué.

L'hôte doit avoir été préparé une fois par son administrateur (outil zapp-hosting) ; sinon la première étape échoue avec « outil installé ? ». Un outil trop ancien pour les étapes d'installation et de publication est signalé avec la commande de mise à jour.

Mettre à jour l'image

Sur la fiche d'une instance prête ou en échec dont la pile a démarré, le cadre Mettre à jour l'image passe l'instance sur une autre image du même produit : pour une instance du canal nightly, soit un digest précis, soit la dernière image d'une étiquette (nightly par défaut) ; pour une instance du canal stable, une version publiée. Le Portail sauvegarde d'abord la base sur l'hôte, puis change l'image et attend que l'application soit saine ; si la nouvelle image ne l'est pas, l'hôte revient de lui-même à la précédente. Les étapes s'ajoutent au journal de la fiche, et l'image précédente reste affichée pour un retour arrière.

Si la création de l'instance s'était arrêtée en échec (une licence refusée par une image trop ancienne, par exemple), ses étapes restantes reprennent après la mise à jour. Pour une instance de client, la sauvegarde d'avant la mise à jour est copiée hors site (gardée 60 jours) : la mise à jour n'est acceptée que si l'hôte a prouvé ce stockage (Contrôler l'hôte), et elle s'arrête si la copie échoue.

Une instance du canal stable (toute instance de client) ne passe que sur une version publiée : le cadre propose la version courante de son produit et les deux précédentes (retour arrière), jamais une étiquette ni un digest libres.

Versions publiées et canaux

Écran Versions publiées (/hosting/releases, bouton depuis Instances SaaS) : une version est une image stable datée du registre (version-stable.AAAAMMJJ.commit), promue par le workflow du produit puis publiée par un administrateur ZAPP. Les images nightly sont purgées après deux nuits : elles ne sont jamais publiées.

Publier une version (administrateurs ZAPP seulement) : produit, numéro (par exemple 2026.11, unique par produit), image stable datée, notes de version en français, anglais et espagnol, et l'hôte qui télécharge l'image (automatique : le premier hôte enrôlé). Le Portail fige le digest de l'image et lit ses étiquettes de version si elle en porte ; la version passe alors publiée et devient la version courante de son produit. Une image déjà publiée sous un autre numéro est refusée.
Retirer la version : elle n'est plus proposée ; les instances qui l'ont la gardent.
Canal d'une instance : stable (versions publiées seulement, obligatoire pour un client) ou nightly (dernière image de l'étiquette du réglage Hosting:ImageTag, pour les démonstrations et les bacs à sable). La fiche d'une démonstration ou d'un bac à sable permet de changer de canal ; l'image en service ne change pas, c'est la prochaine mise à jour qui suit le canal.
La fiche de l'instance montre son canal, sa version (ou « hors version publiée ») et la version courante de son canal.

Sauvegardes

Le cadre Sauvegardes de la fiche liste les sauvegardes de l'instance : date, motif (quotidienne, à la demande, avant mise à jour, finale), état, copie hors site et échéance. Une sauvegarde comprend la base de données et les fichiers de l'instance ; l'hôte garde les trois dernières, et la copie hors site est envoyée sur S3.

Chaque instance de client prête est sauvegardée chaque nuit (réglage Hosting:Backup:HourUtc, une instance à la fois par hôte) ; les démonstrations aussi si le réglage Hosting:Backup:Kinds les cite.
Sauvegarder maintenant lance une sauvegarde hors site de l'instance prête.
Échéances : 30 jours (quotidienne, à la demande), 60 jours (avant mise à jour), 90 jours (finale) ; la dernière sauvegarde réussie d'une instance est toujours gardée.
Les exploitants de l'hébergement sont prévenus d'une sauvegarde quotidienne en échec, et d'une instance de client sans sauvegarde hors site réussie depuis 36 heures.
La restauration (base et fichiers remplacés par ceux d'une sauvegarde) se fait par l'API, réservée aux administrateurs ZAPP : l'hôte fait d'abord une sauvegarde de sécurité et revient de lui-même à l'état d'avant si l'instance ne repart pas. L'instance est en restauration pendant l'opération.

Domaine personnalisé

Un client peut servir son instance sous son propre nom de domaine (par exemple support.client.com). C'est l'administrateur du client qui le saisit dans son instance ; le Portail vérifie le DNS et fait le reste. Le cadre Domaine personnalisé de la fiche montre le domaine, son état, l'enregistrement DNS à créer et, en cas de problème, le motif ; ZAPP peut aussi y saisir le domaine à la demande du client.

Enregistrement à créer chez le client : un CNAME du domaine vers le nom technique de l'instance (identifiant.domaine), ou, pour un domaine sans sous-domaine, un A vers l'adresse publique de la VM d'entrée.
Activation : vérification du DNS (par des résolveurs publics), second nom sur le routeur de l'hôte, domaine et certificat sur la VM d'entrée, puis contrôle de https://domaine/health depuis l'Internet. L'instance passe ensuite d'elle-même sur ce nom (liens des e-mails compris). Le nom technique reste toujours actif.
Vérifier et réessayer relance la vérification du DNS en attente, ou reprend une activation arrêtée (certificat pas encore émis, par exemple). Retirer le domaine l'enlève de la VM d'entrée puis du routeur de l'hôte.
Un domaine n'appartient qu'à une instance ; les domaines de l'hébergeur sont refusés ; 10 vérifications par heure au plus. Les exploitants de l'hébergement sont prévenus de chaque activation et de chaque retrait.
Il faut une VM d'entrée active avec son adresse IPv4 publique (écran VM d'entrée) ; la suppression d'une instance retire aussi son domaine.

Supprimer une instance

Sur la fiche d'une instance prête, en échec ou suspendue, le cadre Supprimer l'instance supprime sur l'hôte la pile, ses données et son adresse, puis retire l'instance du module Licences (ses licences sont révoquées). C'est irréversible : saisissez l'identifiant de l'instance pour confirmer.

Les étapes de la suppression s'ajoutent au journal de la fiche : sauvegarde finale, suppression sur l'hôte, retrait de la licence. Une démonstration ou un bac à sable n'a pas de sauvegarde finale. Pour une instance de client, la sauvegarde finale est obligatoire et copiée hors site (gardée 90 jours) : la suppression n'est acceptée que si l'hôte a prouvé ce stockage, et rien n'est supprimé si la copie échoue.

Si une étape échoue, l'instance reste en suppression avec le message de l'hôte ; Réessayer reprend à l'étape qui a échoué. Une fois supprimée, l'instance libère son identifiant et son port ; sa fiche et son journal restent consultables (filtre « Supprimée » de la liste).

États d'une instance

Demandée, en création, prête, en échec, suspendue, en mise à jour, en restauration, en suppression, supprimée. Une instance supprimée libère son identifiant et son port.