Modèle de cycle de vie et de sécurité

Opfield distingue une opération demandée de son résultat vérifié.

Cette distinction est importante chaque fois que le travail traverse le plan de contrôle, Relay, un démon géré et l’environnement d’exécution d’un hôte. Une réponse d’API peut confirmer qu’Opfield a validé et enregistré une instruction alors que le démon propriétaire est encore en train de l’appliquer. Utilisez l’état durable de la ressource, la tâche, les événements, l’état de santé et les journaux pour déterminer le résultat réel.

État souhaité et état observé

Le plan de contrôle enregistre la configuration souhaitée et l’état de l’opération avant la distribution. Les démons signalent l’inventaire observé, les capacités, l’état de santé et l’état d’exécution. Opfield compare ces vues et enregistre le travail nécessaire pour les faire converger.

L’état souhaité survit à un redémarrage de l’application, à une interruption temporaire de Relay, à une reconnexion d’un démon ou au redémarrage d’un hôte. L’état observé peut devenir périmé tant que le propriétaire est indisponible. Un instantané assaini du dernier état connu peut rester visible pour le diagnostic, mais il ne prouve pas que l’objet d’exécution existe encore ni qu’une modification est sûre.

Un résultat abouti exige des preuves venant du composant propriétaire. Pour une charge de travail, vérifiez l’état d’exécution, la santé, les journaux et sa Route ou sa dépendance privée. Pour un changement d’ingress, vérifiez que nginx a accepté la configuration et testez le nom d’hôte externe. Pour une liaison de base de données, vérifiez le lien de la liaison sur le connecteur secure-link du nœud, l’identité dans le moteur et une vraie requête applicative.

Cycle de vie des opérations

Le travail de longue durée est représenté par une tâche ou une opération durable. Les étapes habituelles comprennent la mise en file d’attente, la distribution au propriétaire, la préparation locale sur l’hôte, la validation, l’application ou la bascule, la vérification et le nettoyage. Les étapes exactes et le comportement d’annulation dépendent de la ressource.

Notez l’identifiant de la tâche ou de l’opération avant de quitter un changement. Recharger la page doit vous reconnecter au même enregistrement durable. Un délai dépassé dans le navigateur, une réponse perdue ou un flux interrompu ne prouvent pas que le propriétaire n’a jamais reçu la commande. Examinez à la fois la tâche et l’état actuel de la ressource avant d’envoyer en double une création, une recréation, une migration ou une suppression.

L’avancement est une preuve signalée par le worker ou le démon propriétaire, et non une animation du navigateur. Un succès final doit correspondre à la postcondition définie par l’opération. Un échec final doit conserver suffisamment d’informations sur la phase, l’erreur et le contexte de la requête pour identifier le prérequis manquant sans répéter l’action à l’aveugle.

Réconciliation

Opfield relance les travaux idempotents sûrs après des déconnexions transitoires et réconcilie les ressources après un redémarrage de l’application ou d’un démon. La réconciliation s’appuie sur le propriétaire durable, l’état souhaité, le rapport de capacités actuel et l’état d’exécution observé. Elle évite d’inventer un succès à partir d’un inventaire périmé ou d’adopter un objet sans rapport portant le même nom.

Lorsque la propriété, la capacité, le droit ou l’état actuel ne peuvent pas être prouvés, les modifications échouent de manière fermée. Rétablissez d’abord le prérequis manquant : reconnectez le nœud, rétablissez Relay, corrigez le registre ou le certificat, restaurez le stockage ou résolvez l’opération active. Laissez ensuite Opfield actualiser l’inventaire et réconcilier la ressource d’origine.

N’utilisez pas la suppression directe sur l’hôte comme outil de réconciliation générique. Supprimer un Container, un réseau, un écouteur, un rôle dans le moteur, un connecteur ou un marqueur de révision appartenant à Opfield peut détruire les éléments nécessaires pour terminer l’opération ou revenir en arrière. Utilisez les actions prises en charge de relance, de réparation, d’annulation ou de reprise du nettoyage lorsqu’elles sont disponibles.

Actions destructives

La suppression, la rotation des identifiants, la bascule d’une migration, l’import d’une archive, le démantèlement d’une base de données et le remplacement d’un certificat ont des effets plus larges que des modifications ordinaires. Avant de commencer, identifiez la ressource propriétaire, les Routes et liaisons dépendantes, les données persistantes, les clients externes, le candidat au retour arrière et le nettoyage attendu.

Lisez le texte de confirmation au lieu de supposer que les objets liés partagent une même politique de suppression. Supprimer un Container retire ses droits sur la ressource, mais ne supprime pas automatiquement un volume distinct. Supprimer une Route met hors service le Secure Link qui lui appartient, mais ne supprime pas les certificats ou Access Lists réutilisables. Retirer une connexion de source arrête les builds futurs, mais ne supprime pas automatiquement les artefacts déployés. La suppression d’une base de données exige d’avoir d’abord traité les liaisons et la conservation des sauvegardes.

Après une opération destructive, vérifiez l’absence prévue et les éléments censés subsister. Contrôlez le nettoyage des relations, la révocation des accès, la conservation du stockage, la joignabilité publique, l’attribution dans l’audit et la tâche finale. Si le nettoyage est interrompu, conservez l’enregistrement durable et reprenez via l’opération enregistrée plutôt que d’effacer manuellement les objets intermédiaires.

Comportement hors ligne sûr

Lorsqu’un nœud est hors ligne, Opfield peut afficher un instantané assaini du dernier état connu. Il n’autorise pas une modification qui reposerait sur un état actuel non vérifié. nginx, les Containers, les bases de données managées et les autres services déjà appliqués peuvent continuer à fonctionner indépendamment.

Commencez la reprise par l’alimentation et le réseau de l’hôte, l’heure système, le DNS, le service démon, l’identité du certificat et la joignabilité sortante de Relay. Évitez de supprimer l’enregistrement du nœud tant que l’ancien démon peut se reconnecter : la suppression crée une identité durable différente et peut empêcher une réconciliation sûre.

Après la reconnexion, attendez un nouveau rapport de capacités et d’inventaire. Examinez les opérations échouées ou interrompues avant de les relancer, puis vérifiez chaque famille de ressources détenue par le nœud. Un indicateur de connexion au vert ne prouve pas à lui seul que les Routes, les certificats, les charges de travail, les projets Compose, les liaisons de bases de données ou la supervision ont convergé.

L’état de la licence suit le même principe. Une clé expirée ou un service de licences injoignable bloque les nouvelles actions de gestion réservées aux plans payants après la période de grâce documentée, mais Opfield n’arrête pas, ne supprime pas et ne fait pas disparaître par réconciliation les charges de travail, les Routes, les bases de données managées ou les déploiements Pages publiés pour cette raison. Voir Rétrogradation et expiration.

Opérations de longue durée

Les builds, les migrations, les Deployments, les opérations sur les certificats, les mises à jour et le provisionnement des bases de données sont des tâches durables. Utilisez l’historique des opérations et des journaux limités plutôt que de répéter une action parce qu’une page semble lente. Lancer une seconde modification conflictuelle peut être refusé, différé ou compliquer la reprise.

Ne relancez que si le contrat de l’opération indique que le travail peut être relancé ou si la tentative précédente est connue pour être terminée. L’annulation est coopérative lorsque le propriétaire la prend en charge. Force Cancel peut empêcher Opfield d’attendre une opération abandonnée, mais ne prouve pas que l’action d’exécution sous-jacente n’a jamais eu lieu. Actualisez l’état du propriétaire et résolvez tout marqueur d’opération interrompue avant la modification suivante.

Discipline de vérification et de reprise

Pour chaque changement significatif, définissez la postcondition attendue avant l’exécution. Vérifiez depuis le chemin réel du consommateur : DNS/TLS/HTTP externes pour le trafic public, une requête applicative pour une liaison de base de données, une empreinte immuable récupérée et une vérification de santé pour une publication, ou la reconnexion et les capacités actuelles pour la mise à jour d’un nœud.

Lorsqu’un changement échoue, préservez l’identifiant de la tâche, l’identifiant de la requête, la phase, des journaux limités, l’état souhaité et l’état actuel du propriétaire. Corrigez le prérequis précis et reprenez via Opfield. Revenez en arrière via le propriétaire de plus haut niveau lorsqu’il existe une révision, un slot de Deployment, un tag ou un artefact source réputé sain. N’affirmez pas que la reprise est terminée tant que l’état d’Opfield et le comportement observé de l’extérieur ne concordent pas.