Nœuds et démons

Pour créer des VM directement depuis Opfield, voir Hébergeurs. Les comptes connectés apparaissent sous Nodes > Providers. Ce guide couvre l’alimentation des VM, le pare-feu, les instantanés et les permissions de facturation.

Un nœud est l’identité durable, dans Opfield, d’un rôle d’hôte géré. Le démon signale le nom d’hôte, la version, la santé, l’inventaire, les métriques, les adresses de service et les capacités propres au rôle via une session authentifiée sortante.

Opfield sépare les responsabilités Ingress, Docker, Storage, Build Worker, Monitoring et Relay. Sélectionnez le rôle exact lors de l’enrôlement et ne réutilisez pas une identité de démon pour une autre frontière de confiance.

La page de détail du nœud est l’endroit principal pour examiner la connectivité, les incohérences de capacités, la préparation aux mises à jour, la pression sur les ressources, les opérations récentes et le dernier état synchronisé. Un instantané périmé peut servir au diagnostic en lecture seule, mais n’autorise jamais une modification.

Identité et état

La création d’un nœud crée d’abord une identité durable en attente. Le jeton d’enrôlement généré est à usage unique et lié à cette identité. Un enrôlement réussi installe un certificat de démon et fait passer le nœud à l’état d’hôte géré en ligne ; supprimer et recréer l’enregistrement crée intentionnellement une identité différente.

Opfield distingue plusieurs types d’état :

• état souhaité : ce que les opérateurs ont configuré dans Opfield ;
• état signalé : le dernier rapport d’inventaire et de capacités acquitté par le démon ;
• état d’exécution : la santé des services en direct et les opérations actives ;
• instantané en cache : le dernier modèle de lecture connu, utilisé lorsqu’un nœud est brièvement indisponible.

Les données en cache servent au diagnostic, mais n’autorisent jamais une modification. Les actions qui nécessitent l’état actuel de l’hôte échouent de manière fermée lorsque le démon est hors ligne ou que ses capacités sont périmées.

Frontières entre rôles

Rôle	Détient
Ingress	configuration nginx, certificats, Routes, télémétrie d’accès et de trafic
Docker	conteneurs, Deployments, Compose, images, volumes, réseaux, builds et points de terminaison de migration
Build Worker	exécution isolée des builds Git et admission des artefacts
Storage	moteurs PostgreSQL, clé-valeur et ClickHouse managés, stockage objet SeaweedFS managé (les anciens clusters MinIO continuent de fonctionner), images de stockage, points de terminaison directs, télémétrie des bases de données et tâches de sauvegarde et de restauration ; les charges de travail génériques sont refusées
Monitoring	métriques des hôtes sans accès au cycle de vie des charges de travail
Relay	transport authentifié des nœuds et tunnels privés pris en charge

Ne considérez pas les libellés de rôle comme cosmétiques. Chaque installateur, profil de démon, ensemble de capacités, artefact de mise à jour et frontière de permissions est différent.

Vérifications opérationnelles

Pour chaque nœud de production, confirmez que :

• le nom d’hôte et le nom affiché identifient le bon hôte physique ;
• les adresses de service sont joignables depuis leurs pairs prévus ;
• la version et l’état de compatibilité sont à jour ;
• les capacités attendues sont saines, et pas seulement présentes ;
• la pression sur le stockage, la mémoire, le CPU et le disque fait l’objet d’alertes ;
• les procédures de mise à jour et de reprise sont documentées ;
• le nœud appartient au bon dossier et aux bons scopes de permissions.

Propriété et frontière de confiance

L’enregistrement du nœud et le certificat du démon sont des identités du plan de contrôle, et non des alias d’une adresse IP. Réinstaller un hôte sous un nœud nouvellement créé produit un nouveau propriétaire, même si le nom d’hôte et l’adresse sont inchangés. Les ressources, droits, opérations et inventaires en cache rattachés à l’ancienne identité ne sont pas transférés simplement parce que le remplaçant porte le même nom d’affichage.

Protégez l’hôte en fonction de son rôle. Un nœud Docker ou Storage peut accéder aux données applicatives, un nœud Ingress détient du matériel de certificats privé, un Build Worker traite des entrées de dépôts potentiellement hostiles, et un relais transporte des flux de contrôle authentifiés et des flux privés. Évitez de combiner des rôles sur un même hôte lorsque cela ferait disparaître une frontière de sécurité ou de panne. Opfield présente des rôles distincts parce que leurs privilèges et leurs rayons d’impact opérationnels diffèrent.

Le démon initie la session gérée vers l’extérieur ; l’exploitation courante n’exige donc pas d’exposer un port d’administration général du démon. L’application des correctifs sur l’hôte, la politique de pare-feu, la synchronisation de l’heure, la santé du stockage et le chemin réseau vers Relay restent de votre ressort. Opfield signale ces dépendances et refuse les modifications en toute sécurité lorsqu’elles sont défaillantes ; il ne répare ni l’hôte ni le réseau.

Recette après l’enrôlement

Ne placez pas de ressources de production sur un nœud dès que son état passe en ligne. Attendez un nouvel instantané d’inventaire et de métriques, puis vérifiez les capacités du rôle et les adresses de service attendues. Effectuez une opération à faible risque propre au rôle : validez la configuration nginx sur un nœud Ingress, examinez une charge de travail de test sur un nœud Docker, exécutez un build de test admis sur un Build Worker ou confirmez les contrôles préalables de stockage sur un nœud Storage.

Consignez le chemin de reprise avant l’affectation : comment joindre l’hôte, où se trouvent les journaux du démon et des services du rôle, quelle identité persistante ou quelles données doivent survivre, et quelles ressources dépendantes doivent être vérifiées après un redémarrage.

Poursuivez avec Rôles et installation des nœuds avant l’enrôlement, et avec Mises à jour des nœuds et comportement hors ligne avant le déploiement en production.