Operations Center : déployer et piloter une flotte Incus OS

Gérer un nœud Incus OS se fait par son API. Gérer une flotte demande une console centrale. Operations Center est cette console : une appliance qui provisionne les serveurs, forme les clusters, distribue les mises à jour et inventorie instances, réseaux et stockage, même dans des environnements isolés d'internet. Ce guide déploie l'appliance, puis lui fait installer et clusteriser trois nœuds Incus OS de A à Z, sans jamais monter le cluster à la main. Public visé : administrateurs qui construisent un cloud privé Incus OS et cherchent l'équivalent souverain d'une console de virtualisation.

Ce que vous allez apprendre

Déployer l'appliance Operations Center et éviter le piège qui bloque son démarrage.
Installer et connecter le CLI de gestion.
Générer une ISO managée qui fait naître les nœuds déjà enrôlés.
Laisser l'OC former le cluster à partir des serveurs prêts.
Piloter le cluster (instances, réseaux) depuis la console.

Prérequis

La procédure d'installation par seed décrite dans Incus OS sans interface.
Un client de confiance (certificat) pour l'API et l'interface web.
De quoi provisionner quatre VM (l'appliance plus trois nœuds), 4 Go et 50 Go chacune pour un lab.

Operations Center dans la stack

Operations Center est une application primaire d'Incus OS, donc exclusive : un système fait tourner soit incus (un hyperviseur), soit operations-center (la console), jamais les deux. L'OC vit sur une appliance dédiée. Avec Migration Manager, il forme la couche de gestion de la stack FuturFusion, pensée comme une alternative libre aux plateformes fermées pour la sortie de VMware.

Le principe directeur, à retenir avant tout : c'est l'OC qui déploie les nœuds et forme le cluster, pas l'inverse. On ne monte jamais le cluster à la main pour le confier ensuite à l'OC, sujet sur lequel on revient à la fin.

Déployer l'appliance

L'appliance s'installe comme un nœud Incus OS, avec un seed qui diffère sur deux fichiers. Pas de seed incus, mais un applications.json qui demande operations-center, et un operations-center.json qui déclare au moins un certificat client de confiance (sans lui, aucune authentification possible ensuite).

{"applications":[{"name":"operations-center"}]}

{
  "version": "1",
  "apply_defaults": true,
  "trusted_client_certificates": ["-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n"]
}

Avec les install.json et network.json habituels, on construit l'ISO de seed et on installe la VM. Au démarrage, l'application écoute sur le port 8443 pour l'API comme pour l'interface web.

Installer et connecter le CLI

Toute la suite se pilote avec le CLI operations-center, à récupérer dans les releases du projet :

wget https://github.com/FuturFusion/operations-center/releases/download/v0.7.3/operations-center.linux.x86_64 \
  -O /usr/local/bin/operations-center && chmod +x /usr/local/bin/operations-center

On déclare l'appliance comme remote, puis on pointe le CLI vers le certificat de confiance (celui du seed), sans quoi l'authentification est refusée :

operations-center remote add opscenter https://192.168.10.135:8443 --accept-certificate
cp client.crt ~/.config/operations-center/client.crt
cp client.key ~/.config/operations-center/client.key
operations-center remote switch opscenter
operations-center provisioning server list

À ce stade, la liste ne contient que l'appliance elle-même, auto-enregistrée comme serveur, en état ready.

Générer l'ISO managée

C'est le cœur du modèle. On crée un token de provisionnement qui autorise un nombre d'installations, puis on demande à l'OC une ISO pré-seedée à partir de ce token :

operations-center provisioning token add --description "cluster lab" --uses 20
operations-center provisioning token list

operations-center provisioning token get-image <uuid> ./IncusOS-managed.iso \
  --application incus --architecture x86_64 --type iso

L'OC assemble une ISO (autour de 3 Go) à partir de ses mises à jour cachées, en y intégrant l'application incus et un seed qui rattache automatiquement le nœud à l'appliance. Un nœud installé depuis cette ISO naît géré, avec un certificat propre qui couvre son adresse : c'est ce détail qui rend la suite fluide.

Installer les nœuds et les voir passer ready

Pour chaque nœud du futur cluster, on installe la VM depuis l'ISO managée, sans seed séparé (tout est intégré). Après le premier boot, chaque nœud s'enregistre seul auprès de l'OC. On suit leur arrivée :

operations-center provisioning server list

| Name                                 | Connection URL              | Type  | Status |
| 5919fc58-f510-42dd-93d3-a1636d80ae01 | https://192.168.10.131:8443 | incus | ready  |
| 842513e1-4d46-4294-b063-acebd05d36ab | https://192.168.10.168:8443 | incus | ready  |
| 0be9d0be-bafd-41e5-9fc2-24a0c5d38b46 | https://192.168.10.184:8443 | incus | ready  |
| operations-center                    | https://192.168.10.135:8443 | operations-center | ready |

Les nœuds arrivent en ready directement, parce que l'OC les a lui-même provisionnés et connaît leur certificat. On peut ensuite leur donner des noms lisibles :

operations-center provisioning server rename 5919fc58-... IncusOS01
operations-center provisioning server rename 842513e1-... IncusOS02
operations-center provisioning server rename 0be9d0be-... IncusOS03

Former le cluster

Les serveurs sont prêts mais indépendants. On demande à l'OC de les rassembler en cluster. La commande prend un fichier de configuration d'application qui embarque le certificat client et l'adresse d'écoute :

certificates:
  - type: client
    name: incus-admin
    certificate: |-
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
config:
  core.https_address: ":8443"

operations-center provisioning cluster add lab-incusos https://192.168.10.131:8443 \
  --server-names IncusOS01 --server-names IncusOS02 --server-names IncusOS03 \
  --application-seed-config app-config.yaml

L'URL est celle du premier serveur, et l'on répète --server-names pour chaque nœud. L'OC configure alors le clustering sur les trois serveurs. On vérifie côté console :

operations-center provisioning cluster list

| Name        | Connection URL              | Status |
| lab-incusos | https://192.168.10.131:8443 | ready  |

Et côté Incus, le cluster est un vrai cluster haute disponibilité de trois voters :

incus remote add lab https://192.168.10.131:8443 --auth-type tls --accept-certificate
incus cluster list lab:

| IncusOS01 | database-leader | ONLINE | Fully operational |
| IncusOS02 | database        | ONLINE | Fully operational |
| IncusOS03 | database        | ONLINE | Fully operational |

Piloter depuis la console

Le cluster formé, tout ce qui s'y passe remonte dans l'inventaire de l'OC. Lancez une instance sur le cluster, et elle apparaît côté console avec son cluster et son nœud d'accueil :

incus launch images:debian/12 lab:demo01 --target IncusOS02
operations-center inventory instance list

| Name   | Project | Cluster     | Server    |
| demo01 | default | lab-incusos | IncusOS02 |

L'inventaire couvre aussi les réseaux (inventory network), les ACL, les répartiteurs de charge, les zones DNS et le stockage : c'est le point unique depuis lequel on observe et gouverne toute la flotte, ce que reflète l'interface web sous /ui/.

Ne pas greffer l'OC sur un cluster existant

La tentation est grande de monter un cluster à la main puis d'y rattacher l'OC après coup. Dans la version actuelle, cela ne fonctionne pas, et il faut le savoir pour ne pas perdre de temps.

Les membres d'un cluster présentent un certificat de cluster partagé dont les SAN ne couvrent pas leurs adresses IP. Quand l'OC teste la liaison retour vers un nœud, la vérification TLS échoue (certificate is valid for 127.0.0.1, not <ip>) et le serveur reste bloqué en pending (registering). Régénérer le certificat pour y ajouter les IP casse alors la confiance (certificate signed by unknown authority), et l'on ne peut pas revenir en arrière : la désinscription n'est pas supportée et l'état d'enregistrement d'un nœud est figé. La seule voie fiable est celle de ce guide : laisser l'OC provisionner les nœuds dès le départ.

Accéder à l'interface et diagnostiquer

L'interface web se sert sur https://<appliance>:8443/ui/, authentifiée par le même certificat client. Importez-le dans le navigateur au format PKCS#12 et présentez bien celui de confiance : un mauvais certificat donne une page blanche (l'UI se charge, mais chaque appel d'API est rejeté).

Comme l'appliance reste un système Incus OS, son API système est joignable sur le même port sous /os, ce qui donne les logs quand rien d'autre ne répond :

curl -sk --cert client.crt --key client.key https://192.168.10.135:8443/os/1.0/debug/log

En filtrant sur l'unité operations-center, on lit les vraies erreurs de l'application, même interface vide. C'est ainsi que se diagnostiquent le blocage du jeu de données et les rejets de certificat.

Dépannage

Symptôme	Cause probable	Solution
L'appliance ne répond pas sur 8443	Jeu de données ZFS bloqué après update au premier boot	Réinstaller depuis l'ISO de la version courante
Le CLI est refusé (`authentication mismatch`)	Certificat du CLI non approuvé	Pointer le CLI sur le certificat de confiance du seed
Un nœud reste `pending (registering)`	Cluster monté à la main, certificat sans IP	Repartir en OC-first : provisionner via l'ISO managée
`cluster add` échoue	`app-config.yaml` sans certificat ou adresse	Fournir `certificates` et `core.https_address`

À retenir

Operations Center est une application primaire : appliance dédiée, jamais sur un nœud.
Le modèle est OC-first : l'OC provisionne les nœuds puis forme le cluster.
L'ISO managée (token get-image) fait naître des nœuds déjà enrôlés, en ready.
La formation du cluster passe par cluster add avec un app-config.yaml.
Tout le cluster remonte dans l'inventaire de l'OC (instances, réseaux, stockage).
Greffer l'OC sur un cluster existant ne marche pas (certificat, désinscription).

Prochaines étapes

Incus OS sans interface La procédure d'installation par seed.

Rôles, quorum et haute disponibilité Le cluster que la console pilote.

Sauvegarde et supervision Exploiter les nœuds sans shell.

Mises à jour A/B et rollback Le mécanisme d'update piloté par la console.