Hébergeurs

Connectez un compte de fournisseur dans Settings > Integrations > Hosting pour créer et gérer des VM dans Opfield. L’enregistrement d’un connecteur ne crée pas de VM ; une commande nécessite une confirmation distincte.

Configuration des fournisseurs

Choisissez un fournisseur et dépliez ses instructions de configuration. L’ajout d’un connecteur nécessite les permissions Opfield integrations:hosting:view et integrations:hosting:manage ; les permissions du jeton du fournisseur se configurent séparément.

Proxmox VE

Créez des VM QEMU et gérez les VM et CT existants sur un hôte sélectionné. Nécessite un jeton d’API, des ACL et un profil de stockage et de réseau pour le provisionnement.

Configurer Proxmox VE

Créer l’identifiant

Dans Proxmox, ouvrez Datacenter > Permissions > Users > Add. Créez un utilisateur dédié, par exemple opfield@pve, dans le domaine d’authentification Proxmox VE. Ne réutilisez pas root@pam.
Sous Permissions > Roles > Create, créez des rôles contenant les privilèges du tableau ci-dessous. Gardez les privilèges de VM, de stockage et, en option, de pare-feu du cluster dans des rôles distincts afin que chacun puisse être attribué au bon chemin.
Sous Permissions, ajoutez des entrées User Permission pour opfield@pve sur les chemins que vous comptez gérer. N’utilisez la propagation que lorsque les descendants doivent hériter du droit. Pour la création, incluez les futurs VMID de la plage d’allocation configurée, et pas seulement les VM existantes.
Ouvrez Permissions > API Tokens > Add, sélectionnez opfield@pve, nommez le jeton hosting et laissez Privilege Separation activé. Définissez une expiration appropriée. Copiez immédiatement le secret ; il n’est affiché qu’une fois.
Ajoutez les entrées API Token Permission correspondantes pour opfield@pve!hosting. Avec la séparation des privilèges, les permissions effectives sont l’intersection des permissions de l’utilisateur et de celles du jeton. Un utilisateur administrateur ne fait pas automatiquement d’un jeton séparé un administrateur.

Privilèges et chemins d’ACL

N’accordez que les lignes nécessaires aux fonctionnalités prévues. Remplacez les espaces réservés des chemins par vos objets Proxmox réels ; un identifiant de nœud Opfield n’est ni un nom d’hôte Proxmox ni un VMID.

Opération	Privilèges Proxmox	Cible de l’ACL
Découvrir les hôtes et le stockage	`Sys.Audit`, `Datastore.Audit`	Respectivement le `/nodes/<host>` et le `/storage/<storage>` sélectionnés
Lire la configuration et l’état des VM	`VM.Audit`	`/vms/<vmid>`
Créer et configurer une VM	`VM.Allocate`, `VM.Config.CPU`, `VM.Config.Memory`, `VM.Config.Disk`, `VM.Config.Network`, `VM.Config.HWType`, `VM.Config.Options`, `VM.Config.CDROM`, `VM.PowerMgmt`	Chaque futur `/vms/<vmid>` autorisé ou le `/pool/<pool>` configuré
Allouer les disques des VM	`Datastore.AllocateSpace`	Le `/storage/<storage>` de disques sélectionné, avec le contenu `images`
Télécharger ou importer une image système et téléverser le support d’amorçage	`Datastore.AllocateTemplate`, `Datastore.Allocate`	Le stockage d’images sélectionné avec `import` et le stockage d’amorçage avec `iso`
Téléchargement d’image côté hôte	`Sys.AccessNetwork`	Le `/nodes/<host>` sélectionné
Rattacher un bridge ou un VNet	`SDN.Use`	Le chemin de permission du bridge ou du VNet dans Proxmox
Démarrer, arrêter, redémarrer	`VM.PowerMgmt`	`/vms/<vmid>`
Redimensionner	`VM.Config.CPU`, `VM.Config.Memory`, `VM.Config.Disk` ; l’agrandissement d’un disque nécessite aussi l’allocation de stockage	Chemins de la VM et du stockage de disques
Supprimer une VM	`VM.Allocate`	`/vms/<vmid>`
Lire les fichiers d’identité de l’invité	`VM.GuestAgent.FileRead` ou le plus large `VM.GuestAgent.Unrestricted` ; les versions plus anciennes utilisent `VM.Monitor`	`/vms/<vmid>`
Installer ou rétablir via QEMU Guest Agent	`VM.GuestAgent.Unrestricted` ; les versions plus anciennes utilisent `VM.Monitor`	`/vms/<vmid>`
Créer ou supprimer des instantanés	`VM.Snapshot`	`/vms/<vmid>`
Restaurer des instantanés	`VM.Snapshot.Rollback` ; le redémarrage nécessite aussi `VM.PowerMgmt`	`/vms/<vmid>`
Lire ou modifier le pare-feu de la VM et la participation des cartes réseau	`VM.Audit`, `VM.Config.Network`	`/vms/<vmid>`
Lire l’état du pare-feu du cluster	`Sys.Audit`	`/`
Gérer les groupes de sécurité du pare-feu du cluster appartenant à Opfield	`Sys.Modify`	`/` — facultatif, accès étendu au niveau du cluster

N’accordez pas Sys.Modify sur / simplement pour faire réussir un test de connexion. L’intégration actuelle du pare-feu en a besoin pour les groupes de sécurité du cluster ; ce n’est pas une permission locale à la VM. Si cet accès est inacceptable, laissez la gestion du pare-feu indisponible. Opfield n’active pas le pare-feu du cluster. Préférez un stockage dédié aux images et à l’amorçage : Datastore.Allocate est plus large que la permission de téléverser un fichier. VM.Backup ne remplace pas les privilèges d’instantanés.

Les versions de Proxmox diffèrent quant aux privilèges du Guest Agent. Sélectionnez les privilèges présents dans votre version installée et vérifiez la permission nommée par l’opération d’API en échec. Lorsque les appels d’informations du Guest Agent l’exigent, ajoutez VM.GuestAgent.Audit ; accorder seulement la lecture de fichiers ne permet pas les commandes d’installation.

Se connecter dans Opfield

Ouvrez Settings > Integrations et cliquez sur Add connector dans Hosting.
Sur Connection, choisissez Provider → Proxmox VE. Renseignez Connector name (par exemple Proxmox production), API origin (https://pve.example.com:8006, sans /api2/json), Token ID (opfield@pve!hosting) et API token (le secret uniquement). Cliquez sur Continue.
Sur Proxmox host, choisissez Certificate verification : System trust, Private CA certificate ou Verified certificate fingerprint. Pour les deux dernières options, fournissez le Trusted CA certificate au format PEM ou un Certificate SHA-256 pin vérifié de façon indépendante.
Cliquez sur Test Connection, puis choisissez Physical host parmi les hôtes découverts. Un connecteur est lié à un hôte physique ; les VMID restent uniques dans tout le cluster.
Laissez VM provisioning activé pour créer des VM. Désactivez-le pour l’inventaire et l’adoption des VM et CT existants uniquement ; cela ignore Infrastructure et Network. Cliquez sur Continue.
Sur Infrastructure, renseignez les champs suivants et cliquez sur Continue.

Champ	Valeur
Disk storage	Stockage existant sur l’hôte sélectionné, avec le contenu `images` pour les disques des VM
Image storage	Stockage avec le contenu `import` pour les images système
Seed storage	Stockage avec le contenu `iso` pour le support d’amorçage
Allowed VMIDs	Identifiants et plages, comme `9000-9010,9020` ; jusqu’à 1000 identifiants uniques. Les identifiants occupés sont ignorés
Maximum CPU budget (cores)	Budget global facultatif de vCPU, y compris les opérations en attente
Maximum memory budget (MiB)	Budget global facultatif de RAM
Maximum disk budget (GiB)	Budget global facultatif de disque
Resource pool	Le nom d’un pool Proxmox existant, ou laissez vide

Sur Network, choisissez Bridge et Address assignment. DHCP nécessite un service DHCP fonctionnel sur ce réseau. Pour Static IPv4 pool, renseignez IP pool, Subnet et Gateway. Fournissez au moins autant d’adresses que de VMID autorisés et réservez-les en dehors du DHCP et de l’allocation manuelle.
Ne définissez VLAN, DNS servers, Search domain et MTU que si nécessaire. Interface firewall contrôle la participation de la carte réseau ; il n’active pas le pare-feu du cluster et ne crée pas de règles. Cliquez sur Review.
Vérifiez Profile summary. Sous Synchronization and scope, configurez Automatic sync et Sync interval (seconds), de 60 à 86400. N’activez Automatic adoption que si vous souhaitez que les nœuds existants soient liés lorsque les preuves d’identité sont sans ambiguïté ; une correspondance d’IP ou de VMID seule ne suffit pas.
Cliquez sur Create connector. Avec VM provisioning désactivé, les paramètres de synchronisation apparaissent à l’étape finale Settings, sans résumé de provisionnement. L’enregistrement du connecteur ne crée pas de VM.
Ouvrez le compte enregistré depuis Nodes > Providers ou la liste des intégrations. Vérifiez la synchronisation et l’inventaire des ressources. Pour créer un nœud, cliquez sur Create VM, sélectionnez son rôle, son nom, son système et ses ressources, vérifiez Review node et sélectionnez Confirm and create VM. Attendez la fin de l’installation et la mise en ligne du nœud.

Si Test Connection ne charge pas les hôtes, vérifiez la confiance TLS et les ACL. Si un stockage manque, vérifiez son type de contenu et sa disponibilité sur l’hôte sélectionné. Create VM nécessite un profil de provisionnement et des permissions Opfield pour créer des nœuds et des ressources dans le compte sélectionné.

Vérifier les permissions

Si une requête d’API est refusée, examinez les permissions effectives du jeton depuis un shell Proxmox d’administrateur, en remplaçant les chemins d’exemple :

pveum user token permissions opfield@pve hosting --path /vms/9000
pveum user token permissions opfield@pve hosting --path /storage/opfield-images
pveum user token permissions opfield@pve hosting --path /

Ces commandes se contentent de lire les permissions. Pour un jeton à privilèges séparés, vérifiez à la fois les ACL de l’utilisateur et celles du jeton.

Documentation Proxmox.

DigitalOcean

Créez et gérez des Droplets, des pare-feu et des instantanés à l’aide d’un personal access token limité.

Configurer DigitalOcean

Créer un jeton d’API

Passez à l’équipe prévue dans le panneau de contrôle DigitalOcean. Ouvrez API > Tokens > Generate New Token.
Donnez au jeton un nom dédié et une expiration. Sélectionnez Custom Scopes et ajoutez les lignes nécessaires ci-dessous, y compris leurs scopes de dépendance requis. Le rôle d’équipe du créateur doit permettre ces opérations.
Générez le jeton et copiez son secret pour l’étape suivante.

Capacité	Scopes du jeton
Inventaire du compte et des VM	`account:read`, `droplet:read`
Emplacements, tailles, images	`regions:read`, `sizes:read`, `image:read`
Créer un Droplet	`droplet:create`, `droplet:read`, `tag:create`, `tag:read`, `regions:read`, `sizes:read`, `actions:read`, `image:read`, `snapshot:read`, `vpc:read`
Actions d’alimentation ; créer ou restaurer un instantané via les actions de Droplet	`droplet:update` plus `droplet:read`, `regions:read`, `sizes:read`, `actions:read`, `image:read`, `snapshot:read`
Redimensionner	Les scopes de mise à jour ci-dessus plus `droplet:create` et ses dépendances
Supprimer un Droplet	`droplet:delete`, `droplet:read`
Lister ou supprimer des instantanés	`snapshot:read` ; ajoutez `snapshot:delete` pour la suppression
Gérer et nettoyer les pare-feu	`firewall:read`, `firewall:create`, `firewall:update`, `firewall:delete`, `droplet:read`, `tag:read`
Solde et facturation	`billing:read`

Il n’existe pas de scope snapshot:create distinct dans cette API : la création d’un instantané de Droplet est une action de Droplet. Ne demandez pas de permissions sans rapport sur Kubernetes, Spaces ou les bases de données. Pour modifier les scopes d’un jeton, créez un jeton de remplacement, mettez à jour Opfield, vérifiez-le, et ne révoquez l’ancien jeton qu’ensuite.

Références : Créer un personal access token, Référence des scopes DigitalOcean.

Se connecter dans Opfield

Ouvrez Settings > Integrations et cliquez sur Add connector dans Hosting.
Sur Connection, sélectionnez Provider → DigitalOcean et saisissez un Connector name, comme DigitalOcean production. API origin est renseigné automatiquement avec https://api.digitalocean.com ; ne le modifiez pas.
Collez le secret du jeton dans API token. Cliquez sur Test Connection. Si vous voyez Connected with limited permissions, comparez les droits manquants aux exigences ci-dessus ; une authentification réussie n’active pas toutes les opérations.
Cliquez sur Continue. Sur Settings, configurez les champs suivants.

Champ	Valeur
Automatic sync	Active l’actualisation planifiée de l’inventaire du fournisseur
Sync interval (seconds)	Un intervalle de 60 à 86400 secondes
Automatic adoption	Ne lier les nœuds existants que lorsque les preuves d’identité sont sans ambiguïté
Node scope	Liste facultative, séparée par des virgules, d’UUID de nœuds Opfield restreignant l’adoption automatique, et non d’identifiants de VM du fournisseur. Vide inclut tous les nœuds éligibles à la liaison
Default location, Default size, Default image	Identifiants facultatifs du catalogue du fournisseur, présélectionnés dans l’assistant de VM. Laissez vide si vous ne les connaissez pas et choisissez les valeurs lors de la création de la VM

Cliquez sur Create connector. Cela enregistre la connexion sans commander de VM.
Ouvrez le compte enregistré depuis la liste des intégrations ou Nodes > Providers. Vérifiez la synchronisation, l’inventaire du compte ou de l’équipe prévus et les informations financières disponibles. Un solde inconnu n’est pas un solde nul.
Pour créer un nœud, cliquez sur Create VM et choisissez le rôle, le nom, l’emplacement, le système et la taille. Examinez la configuration et le prix sous Review node, puis sélectionnez Confirm and create VM — cela passe une commande facturable. Attendez la création de la VM, l’installation du démon et la mise en ligne du nœud.
Pour modifier les paramètres, ouvrez Configure dans le menu du compte, terminez l’assistant et cliquez sur Save. Laissez vide le champ d’identifiant de remplacement lors d’une modification pour conserver le secret enregistré.

Si Add connector n’est pas disponible, vérifiez les permissions Opfield d’administration des intégrations d’hébergeurs. Create VM nécessite en plus des permissions de création de nœuds et de ressources pour le compte sélectionné, ainsi que la capacité de création du fournisseur.

Hetzner Cloud

Gérez les serveurs Cloud d’un projet à l’aide de son jeton d’API. Hetzner Robot et les serveurs dédiés ne sont pas pris en charge.

Configurer Hetzner Cloud

Créer un jeton d’API

Ouvrez la Hetzner Console, sélectionnez le projet Cloud prévu, puis Security > API Tokens > Generate API Token.
Nommez le jeton et choisissez Read pour l’inventaire seul ou Read & Write pour la création de VM, l’alimentation, le redimensionnement, le pare-feu et les opérations d’instantanés. Hetzner n’expose pas de scopes distincts par opération comme DigitalOcean.
Générez le jeton et copiez son secret pour l’étape suivante.

Utilisez un projet dédié pour limiter la portée du jeton. Le connecteur actuel d’Opfield ne permet pas de remplacer sur place le jeton d’un projet Hetzner : créez un nouveau connecteur pour un jeton de remplacement et réconciliez explicitement les ressources dépendantes avant de retirer l’ancien connecteur. Il n’y a pas de scope de solde supplémentaire à activer ; cette intégration n’expose pas d’API de solde de compte.

Référence : Configuration de l’API Hetzner Cloud.

Se connecter dans Opfield

Ouvrez Settings > Integrations et cliquez sur Add connector dans Hosting.
Sur Connection, sélectionnez Provider → Hetzner Cloud et saisissez un Connector name, comme Hetzner production. API origin est renseigné automatiquement avec https://api.hetzner.cloud ; ne le modifiez pas.
Collez le secret du jeton dans API token. Cliquez sur Test Connection. Si vous voyez Connected with limited permissions, comparez les droits manquants aux exigences ci-dessus ; une authentification réussie n’active pas toutes les opérations.
Cliquez sur Continue. Sur Settings, configurez les champs suivants.

Champ	Valeur
Automatic sync	Active l’actualisation planifiée de l’inventaire du fournisseur
Sync interval (seconds)	Un intervalle de 60 à 86400 secondes
Automatic adoption	Ne lier les nœuds existants que lorsque les preuves d’identité sont sans ambiguïté
Node scope	Liste facultative, séparée par des virgules, d’UUID de nœuds Opfield restreignant l’adoption automatique, et non d’identifiants de VM du fournisseur. Vide inclut tous les nœuds éligibles à la liaison
Default location, Default size, Default image	Identifiants facultatifs du catalogue du fournisseur, présélectionnés dans l’assistant de VM. Laissez vide si vous ne les connaissez pas et choisissez les valeurs lors de la création de la VM

Cliquez sur Create connector. Cela enregistre la connexion sans commander de VM.
Ouvrez le compte enregistré depuis la liste des intégrations ou Nodes > Providers. Vérifiez la synchronisation, l’inventaire du projet prévu et les informations financières disponibles. Un solde inconnu n’est pas un solde nul.
Pour créer un nœud, cliquez sur Create VM et choisissez le rôle, le nom, l’emplacement, le système et la taille. Examinez la configuration et le prix sous Review node, puis sélectionnez Confirm and create VM — cela passe une commande facturable. Attendez la création de la VM, l’installation du démon et la mise en ligne du nœud.
Pour modifier les paramètres, ouvrez Configure dans le menu du compte, terminez l’assistant et cliquez sur Save. Créez un nouveau connecteur pour remplacer un jeton Hetzner ; le champ de jeton du connecteur existant est désactivé.

HOSTKEY

Commandez et gérez des VM à l’aide d’une clé d’API de compte Invapi. Une clé propre à un serveur ne peut pas servir à commander de nouvelles VM.

Configurer HOSTKEY

Créer une clé d’API

Connectez-vous à Invapi, ouvrez API keys et créez une clé nommée de client ou de compte. Une clé propre à un serveur n’est pas le bon identifiant pour commander d’autres VM ou lire la facturation du compte.
Définissez la liste d’accès IP sur l’adresse sortante du serveur Opfield, si vous utilisez une restriction par IP, et activez la clé. Il ne s’agit pas de l’adresse du navigateur utilisé pour configurer Opfield.
Copiez immédiatement le secret d’origine. Après la création, l’interface peut n’afficher que son empreinte ; cette empreinte ne peut pas authentifier Opfield. Si la création de clé n’est pas disponible pour le compte, réglez d’abord l’éligibilité du compte avec HOSTKEY.

Les clés de compte HOSTKEY n’utilisent pas de chaînes de scopes à la manière de DigitalOcean. Limitez l’accès à l’aide du type de clé et des restrictions IP du fournisseur ; un accès au niveau du compte peut autoriser des commandes facturables. Gardez la clé hors de portée des utilisateurs qui ne doivent qu’exploiter un nœud Opfield existant.

Référence : Authentification et clés de l’API HOSTKEY.

Se connecter dans Opfield

Ouvrez Settings > Integrations et cliquez sur Add connector dans Hosting.
Sur Connection, sélectionnez Provider → HOSTKEY et saisissez un Connector name, comme HOSTKEY production. API origin est renseigné automatiquement avec https://invapi.hostkey.com ; ne le modifiez pas.
Collez dans API key la clé d’API Invapi d’origine, et non son empreinte ni un jeton de session temporaire. Cliquez sur Test Connection. Si vous voyez Connected with limited permissions, comparez les droits manquants aux exigences ci-dessus ; une authentification réussie n’active pas toutes les opérations.
Cliquez sur Continue. Sur Settings, configurez les champs suivants.

Champ	Valeur
Automatic sync	Active l’actualisation planifiée de l’inventaire du fournisseur
Sync interval (seconds)	Un intervalle de 60 à 86400 secondes
Automatic adoption	Ne lier les nœuds existants que lorsque les preuves d’identité sont sans ambiguïté
Node scope	Liste facultative, séparée par des virgules, d’UUID de nœuds Opfield restreignant l’adoption automatique, et non d’identifiants de VM du fournisseur. Vide inclut tous les nœuds éligibles à la liaison
Default location, Default size, Default image	Identifiants facultatifs du catalogue du fournisseur, présélectionnés dans l’assistant de VM. Laissez vide si vous ne les connaissez pas et choisissez les valeurs lors de la création de la VM

Cliquez sur Create connector. Cela enregistre la connexion sans commander de VM.
Ouvrez le compte enregistré depuis la liste des intégrations ou Nodes > Providers. Vérifiez la synchronisation, l’inventaire du compte prévu et les informations financières disponibles. Un solde inconnu n’est pas un solde nul.
Pour créer un nœud, cliquez sur Create VM et choisissez le rôle, le nom, l’emplacement, le système et la taille. Examinez la configuration et le prix sous Review node, puis sélectionnez Confirm and create VM — cela passe une commande facturable. Attendez la création de la VM, l’installation du démon et la mise en ligne du nœud.
Pour modifier les paramètres, ouvrez Configure dans le menu du compte, terminez l’assistant et cliquez sur Save. Laissez vide le champ d’identifiant de remplacement lors d’une modification pour conserver le secret enregistré.

CloudBlast

Créez et gérez des serveurs cloud CloudBlast, leurs pare-feu et leurs sauvegardes avec un jeton d’API de compte. Opfield installe son démon sur les nouveaux serveurs via SSH.

Configurer CloudBlast

Créer un jeton d’API

Connectez-vous à la console CloudBlast et ouvrez Account Settings → API.
Créez un jeton avec un nom dédié et copiez-le pour l’étape suivante.

Le jeton agit pour l’ensemble du compte et peut commander des serveurs facturables. Gardez-le hors de portée des utilisateurs qui ne doivent qu’exploiter un nœud Opfield existant.

Se connecter dans Opfield

Ouvrez Settings > Integrations et cliquez sur Add connector dans Hosting.
Sur Connection, sélectionnez Provider → CloudBlast et saisissez un Connector name, comme CloudBlast production. API origin est renseigné automatiquement avec https://console.cloudblast.io ; ne le modifiez pas.
Collez le jeton dans API token et cliquez sur Test Connection.
Cliquez sur Continue. Sur Settings, configurez Automatic sync, Sync interval (seconds), Automatic adoption, Node scope et les valeurs par défaut facultatives comme pour les autres fournisseurs.
Cliquez sur Create connector. Cela enregistre la connexion sans commander de serveur.
Ouvrez le compte enregistré depuis la liste des intégrations ou Nodes > Providers. Vérifiez la synchronisation, l’inventaire et le solde du compte en EUR.
Pour créer un nœud, cliquez sur Create VM et choisissez le rôle, le nom, l’emplacement, le système et l’offre. CloudBlast propose des offres x86-64 ; Opfield liste ses modèles Ubuntu et Debian. Examinez la configuration et le prix, puis sélectionnez Confirm and create VM ; cela passe une commande facturable.
Pour modifier les paramètres, ouvrez Configure dans le menu du compte. Laissez vide le champ du jeton pour conserver le jeton enregistré.

CloudBlast ne prend pas en charge les données utilisateur (user data) ; Opfield installe donc via SSH. Pour chaque commande, il crée une clé SSH à usage unique, enregistre sa clé publique dans le compte CloudBlast et crée le serveur avec celle-ci. Il se connecte ensuite en tant que root, épingle la clé d’hôte du serveur lors de la première connexion, exécute l’installateur du nœud, puis supprime la clé du compte et la retire du serveur. La clé privée n’est conservée que chiffrée avec l’opération et est effacée à la fin de celle-ci.

CloudBlast ne signale pas l’emplacement d’un serveur via son API ; Opfield affiche donc l’emplacement choisi à la création. Les changements d’offre ne sont pas disponibles via l’API CloudBlast ; Resize n’est donc pas proposé.

Créer et enrôler un nœud

Ouvrez Nodes > Add Node et choisissez la création hébergée, ou créez une VM depuis le compte du fournisseur.
Sélectionnez le rôle, le nom, le compte, l’emplacement, un système compatible et les ressources de la VM.
Examinez la configuration et le prix disponible, puis confirmez la commande une seule fois.
Suivez l’état du provisionnement chez le fournisseur, de l’installation, de l’enrôlement et de la disponibilité du rôle.

Une VM en cours d’exécution n’est pas nécessairement un nœud Opfield en ligne. Attendez le démon et les capacités propres à son rôle. Voir Ajouter votre premier nœud et Rôles des nœuds.

Si l’installation échoue après la création de la VM, l’opération affiche les dernières lignes de la sortie de l’installateur, jetons d’enrôlement retirés. Utilisez Retry installation sur cette opération plutôt que de passer une nouvelle commande. Une installation SSH interrompue par un redémarrage d’Opfield est relancée une fois. Supprimer un serveur dont l’installation a laissé un nœud en attente supprime aussi ce nœud. Une réponse incertaine du fournisseur doit d’abord être réconciliée. L’installation sur une VM existante nécessite un canal Guest Agent pris en charge ou une connexion SSH de confiance vers cette VM. La correspondance d’un VMID ou d’une IP seule ne constitue pas une preuve suffisante pour l’adoption automatique.

Exploiter la VM

Alimentation et redimensionnement : les actions dépendent de l’état chez le fournisseur, des permissions et des ressources prises en charge. Les disques Proxmox peuvent être agrandis, pas réduits.
Pare-feu : l’onglet n’est disponible que pour les ressources prises en charge : DigitalOcean, CloudBlast et Proxmox. Sur Proxmox, la participation des interfaces et l’activation du pare-feu de la VM sont des paramètres distincts ; le pare-feu du cluster et les droits du jeton comptent aussi. Opfield n’active pas le pare-feu du cluster à votre place.
Instantanés : les ressources Proxmox, DigitalOcean, Hetzner et CloudBlast prises en charge exposent sur le nœud la création, la suppression, la restauration et les dossiers. Sur CloudBlast, les instantanés sont les sauvegardes complètes du disque du serveur faites par le fournisseur, restaurées sur place, avec des noms d’au plus 40 caractères. La création ne nécessite pas d’arrêter la VM. Proxmox peut, en option, capturer la RAM d’une VM en cours d’exécution et gère l’arrêt et le redémarrage pendant la restauration ; les autres intégrations exigent actuellement une VM arrêtée pour la restauration. HOSTKEY n’est pas présenté comme un fournisseur d’instantanés pris en charge.
Coûts et cohérence : le stockage des instantanés peut entraîner des frais. Le tableau affiche le coût de stockage estimé lorsqu’il est disponible ; un tiret signifie que la taille ou le prix n’est pas disponible. Les instantanés de VM ne sont pas des sauvegardes de bases de données cohérentes au niveau applicatif et peuvent exclure les volumes rattachés.

La création, la suppression et la restauration d’instantanés sont mutuellement exclusives avec les opérations conflictuelles sur la VM. La restauration remplace les données ; confirmez l’instantané sélectionné avant de poursuivre.

Permissions, alertes et reprise

Les permissions d’hébergement complètent l’accès au nœud lié ; elles ne rendent pas accessible un nœud par ailleurs masqué. L’inventaire du compte, les actions sur les VM, l’administration des connecteurs et la facturation sont des permissions distinctes. Restreignez la création aux comptes et fournisseurs prévus, et les actions aux nœuds et ressources prévus. La création d’un nœud hébergé nécessite aussi la permission de création de nœuds. Les jetons d’API et les autorisations OAuth ou MCP peuvent effectuer des actions d’hébergement lorsqu’ils détiennent les scopes integrations:hosting:* et hosting:* correspondants, toujours bornés par les permissions actuelles du propriétaire. Le consentement OAuth laisse décochées par défaut l’administration des connecteurs, la création et la suppression de VM et la restauration d’instantanés ; voir Scopes et jetons.

Configurez des notifications pour les changements d’alimentation des VM, les échecs d’opérations, la synchronisation et les seuils de solde lorsqu’ils sont pris en charge. Les règles de solde nécessitent un accès à la facturation et une devise explicite. Ne considérez pas des données périmées du fournisseur comme une opération réussie ou un solde nul.

Retirer un nœud Opfield n’équivaut pas à détruire sa VM. Examinez les dépendances et l’action du fournisseur sélectionnée avant la suppression. En cas d’échec, conservez l’enregistrement de l’opération et examinez les erreurs du fournisseur, les permissions du jeton, la compatibilité de l’image, la capacité et la connectivité d’enrôlement avant de réessayer.

Automatiser avec MCP ou l’API

Les jetons d’API et les agents MCP créent et gèrent des nœuds hébergés avec les mêmes contrôles que la Console. MCP utilise un seul outil, manage_hosting (ensemble d’outils hosting) ; REST utilise /api/integrations/hosting pour les comptes et /api/hosting pour les opérations, les nœuds et les VM. Un agent lit read_opfield_documentation({ topic: "hosting" }) pour chaque champ et chaque code d’erreur ; le prompt provision-hosted-node et le skill d’agent hosting-providers suivent les mêmes étapes.

La commande nécessite integrations:hosting:view et hosting:resources:create sur le compte (hosting:resources:create:<connectorId>) ainsi que nodes:create. Le groupe intégré admin ne dispose d’aucun scope d’hébergement : accordez-les explicitement.

Choisir le compte. connector_list renvoie chaque compte avec son fournisseur et ses paramètres. Un connecteur Proxmox sert un hôte physique, nommé dans settings.proxmoxHost.
Lire le catalogue. catalog avec le connectorId renvoie les emplacements, les tailles, les images et les prix ; Proxmox ajoute la capacité de l’hôte. 503 HOSTING_CATALOG_NOT_READY signifie que le catalogue est encore en cours de construction : exécutez connector_sync ou attendez la synchronisation en arrière-plan.
Confirmer avec l’utilisateur. Le rôle, le nom, l’emplacement, la taille ou les ressources, l’image et, pour les fournisseurs cloud, le prix exact.
Commander. provision (POST /api/hosting/operations) avec le compte dans le corps :
```
{
  "connectorId": "<account id>",
  "idempotencyKey": "<new random UUID>",
  "name": "docker-02",
  "role": "docker",
  "location": "<catalog location id>",
  "size": "<catalog size id>",
  "image": "<catalog image id>",
  "confirmedPrice": { "amount": "<catalog amount>", "currency": "<catalog currency>" }
}
```
Sur Proxmox, location est l’hôte du connecteur, size vaut "custom", et cpu, memoryMb et diskGb définissent les ressources ; il n’y a pas de prix. Un relais nécessite aussi relayAddress. Renvoyer la même requête avec le même idempotencyKey renvoie la même opération et ne commande jamais de seconde VM.
Suivre l’opération. operation_get (GET /api/hosting/operations/{id}) passe par pending, dispatching, provisioning, configuring, installing et enrolling jusqu’à ready ou failed. Vérifiez ensuite que le nœud est en ligne.
Gérer les échecs. Une installation en échec sur une VM créée : operation_retry_install avec un nouveau idempotencyKey. Un résultat incertain : operation_reconcile. Ne commandez jamais une seconde VM pour réparer la première.

VM existantes : adoption_candidates et adopt lient une VM à un nœud qui s’y exécute déjà ; provision avec existingResourceId installe un nœud sur une VM qui n’en a pas. Les actions sur les VM (resource_action : start, shutdown, reboot, resize, recover, delete), les instantanés et les modifications du pare-feu prennent l’expectedIncarnation actuel de la VM, confirmed: true et un nouveau idempotencyKey.