Modèle de ressources et propriété

Les ressources Opfield ont des identités stables, distinctes des noms d’exécution modifiables ou des identifiants de conteneurs.

Identités stables

Les permissions, les liaisons, les paramètres de source, la configuration de santé, l’historique des opérations et l’état de migration se rattachent à l’identité d’une ressource Opfield. Les noms d’exécution, les identifiants de processus, les identifiants de conteneurs, les adresses IP et le placement peuvent changer sans créer de nouvelle ressource produit. Cette distinction permet à Opfield de recréer ou de déplacer les objets d’exécution éligibles tout en préservant les relations que les opérateurs ont configurées intentionnellement.

Recréer une charge de travail gérée préserve son identité Opfield et conserve donc les relations éligibles de Route, de liaison, de droit et de source. Dupliquer une charge de travail crée une ressource distincte, avec ses propres accès et son propre historique de cycle de vie. Une suppression explicite retire les droits appartenant à la ressource supprimée, de sorte qu’une ressource ultérieure portant le même nom d’affichage n’hérite pas accidentellement de ses autorisations.

Utilisez les identifiants stables de ressources et d’opérations pour corréler les réponses d’API, les tâches, les événements, les journaux et les enregistrements d’audit. Les noms sont destinés aux opérateurs et peuvent changer ou entrer en collision d’un nœud ou d’un dossier à l’autre. Une correspondance de nom ne suffit pas à prouver qu’un objet d’exécution nouvellement observé est la ressource qu’Opfield gérait auparavant.

Frontières de propriété

• Un projet Compose détient les conteneurs de ses services, ses volumes nommés et ses réseaux non externes.
• Un Deployment blue/green détient ses deux slots d’exécution et son état de déploiement.
• Une base de données managée détient son conteneur de base de données et l’identité du propriétaire dans le moteur.
• Une liaison de base de données détient une identité applicative distincte à privilèges minimaux.
• Une Route ou une Additional Route peut détenir sa liaison Secure Link.
• Les conteneurs internes appartenant à Opfield sont hors du champ des API de cycle de vie des utilisateurs.

Ces frontières empêchent une API de plus bas niveau de contourner le cycle de vie de plus haut niveau qui a créé la ressource. Un enfant peut être visible pour le diagnostic sans devenir modifiable indépendamment. Par exemple, les slots d’un Deployment s’inspectent via le Deployment, les services Compose via le projet Compose, et un Secure Link appartenant à une Route via la Route qui l’a créé.

La propriété ne s’étend pas automatiquement aux dépendances référencées. Une Route qui utilise un certificat ou une Access List réutilisables ne détient pas ces ressources et ne les supprime pas. Une charge de travail placée sur un nœud ne détient pas ce nœud. Une Route Pages pointe vers un tag sans détenir le Deployment immuable sélectionné par ce tag. Avant une suppression ou une migration, examinez à la fois les enfants détenus et les dépendances référencées, car leurs règles de nettoyage diffèrent.

Opfield crée aussi des objets d’exécution internes qui servent à implémenter le comportement du produit. Leurs labels, noms d’exécution, réseaux, volumes, identifiants, connecteurs et enregistrements de tâches sont des détails d’implémentation, sauf si une action prise en charge les expose explicitement. Les supprimer ou les renommer directement avec les outils Docker de l’hôte peut casser la réconciliation, le routage, la connectivité privée ou le retour arrière.

État souhaité, état signalé et état d’exécution

La ressource produit conserve un état souhaité durable dans Opfield. Son démon propriétaire signale l’inventaire, les capacités, l’état de santé et les résultats des opérations. L’environnement d’exécution de l’hôte contient le processus, la configuration, le stockage et le rattachement réseau réels. Ces vues peuvent temporairement diverger pendant une opération, un redémarrage, une déconnexion ou une panne.

Un enregistrement réussi signifie que l’état souhaité a été accepté, pas nécessairement que le propriétaire l’a appliqué. Suivez la tâche durable et attendez un nouvel état signalé. Si un nœud est hors ligne, Opfield peut afficher des données assainies du dernier état connu, mais il bloque les modifications qui nécessitent la propriété ou la capacité actuelles. Rétablissez le propriétaire et laissez la réconciliation se faire avant de décider qu’un objet d’exécution manquant doit être recréé manuellement.

Dossiers et navigation

Les dossiers organisent les ressources prises en charge et peuvent intervenir dans les accès limités. Ils ne modifient ni le réseau d’exécution, ni le placement, ni la propriété du cycle de vie. Déplacer ou regrouper une ressource dans la navigation ne déplace pas son exécution et ne transfère pas ses ressources dépendantes.

Les ressources qui appartiennent à une app se trouvent dans les environnements de l’app et sont exclues des listes générales ; ouvrez-les depuis l’app. Un utilisateur sans apps:view voit malgré tout une app lorsqu’il peut consulter l’un de ses membres grâce à ses propres droits, mais uniquement les environnements qui contiennent ces membres, et uniquement ces membres.

Les résultats de la recherche et de la palette de commandes renvoient vers la page canonique de la ressource Opfield plutôt que vers les enfants d’implémentation. Les actions, l’historique d’audit, les ressources liées et les contrôles de reprise restent ainsi ancrés à l’identité stable qui détient le cycle de vie.

Ressources externes

Les projets Compose créés en externe peuvent être découverts à partir des labels Docker canoniques. Opfield peut afficher leurs services, leur état, leur santé, leurs journaux et leur inventaire, mais les projets externes restent en lecture seule jusqu’à ce qu’un opérateur les adopte explicitement avec un YAML complet et les permissions requises. L’adoption ne transfère la gestion future à Opfield qu’après validation et préparation d’une révision immuable ; Opfield ne fait pas confiance à un chemin d’hôte fourni par un label comme configuration source.

Les bases de données externes restent gérées par l’opérateur. Opfield stocke leurs paramètres de connexion chiffrés, teste la connectivité et peut exposer les outils autorisés, mais il ne détient ni les mises à niveau du moteur, ni le stockage, ni la disponibilité, ni la suppression. À partir de Personal, les sauvegardes de bases de données peuvent les sauvegarder. De même, les images Docker globales et les ressources Compose intentionnellement externes ou partagées restent hors du nettoyage des enfants appartenant à un projet.

Modification et suppression en toute sécurité

Avant de modifier une ressource, identifiez son propriétaire, ses enfants détenus, ses dépendances référencées, l’opération active, le candidat au retour arrière et les données persistantes. Effectuez un seul changement de cycle de vie via le propriétaire de plus haut niveau et vérifiez l’état de santé, les relations et l’état signalé qui en résultent. Ne mélangez pas des modifications directes sur l’hôte avec une opération Opfield en cours.

La suppression n’est pas l’inverse de la création. Elle peut retirer des droits, des identités dans le moteur, des liens appartenant à une Route, l’historique des révisions ou des slots de retour arrière, tout en conservant intentionnellement les certificats réutilisables, les Access Lists, les ressources externes ou les volumes persistants. Lisez la confirmation, détachez ou migrez les dépendances, préservez les données requises et suivez la tâche de suppression jusqu’au bout du nettoyage. Si le nettoyage est interrompu, conservez l’enregistrement Opfield et utilisez son état d’opération pour la reprise au lieu de supprimer de force les objets enfants.