Vue d'ensemble de Docker

Dans Opfield, une charge de travail Docker est une ressource, et pas seulement un conteneur en cours d’exécution. La ressource contient sa configuration, ses droits d’accès, l’historique de son cycle de vie, ses relations et son état souhaité, et Opfield réconcilie cet état après une interruption.

Choisissez le cycle de vie de plus haut niveau qui correspond à l’application :

Container : un environnement d’exécution géré directement, avec une configuration et un cycle de vie ciblés.
Deployment : une identité applicative stable avec deux slots d’exécution pour des publications blue/green conditionnées par la santé et le retour arrière.
Projet Compose : une application externe découverte ou une application mononœud gérée par Opfield, avec une configuration validée, des révisions immuables, des opérations de cycle de vie, des journaux, des Routes et des liaisons de bases de données.
Source Git : une entrée de livraison pour les Containers, les Deployments et Pages. Ce n’est pas une entité applicative distincte.

Workload Availability (HA) est disponible en Business et Enterprise pour les Containers et Deployments éligibles sans montages, ainsi que pour des projets Compose entiers. Elle ajoute à l’identité de ressource existante une réplication à nombre fixe ou un basculement à service unique entre des nœuds Docker indépendants.

Choisir le modèle d’exploitation

La décision porte avant tout sur la propriété et la reprise, et non sur le nombre de champs d’un formulaire.

Besoin	Modèle recommandé	Principal compromis
Un service avec un cycle de vie simple	Container	Direct et flexible, mais les publications et le retour arrière sont gérés par l’opérateur
Des publications conditionnées par la santé avec un candidat de retour arrière conservé	Deployment	Publications plus sûres, avec deux slots d’exécution gérés
Plusieurs services qui doivent évoluer comme une seule application	Projet Compose	Une seule frontière de révision et d’opération, un nœud par placement ; Availability facultative de tout le projet en Business/Enterprise
Des artefacts reproductibles à partir de la gestion de sources	Source Git plus une ressource propriétaire	Ajoute la provenance des builds ; la sécurité du déploiement vient toujours du Container, du Deployment, de Compose ou de Pages

Choisissez le propriétaire de plus haut niveau qui représente la façon dont l’application doit être modifiée lors d’une publication normale et rétablie lors d’un incident. Ne modélisez pas une application multiservice comme des Containers sans lien simplement pour éviter Compose, et ne choisissez pas un Deployment lorsque l’application possède un état partagé accessible en écriture qui ne peut pas exister sans danger entre plusieurs slots de publication.

Le responsable de la plateforme doit définir qui détient la ressource applicative, ses données, ses Routes publiques, son accès aux registres et sa décision de retour arrière. Opfield enregistre et applique ces frontières, mais ne peut pas décider si une migration de données au niveau applicatif est réversible.

Frontières de propriété

Opfield détient les métadonnées et l’état souhaité des ressources qu’il crée ou adopte. Le démon Docker cible détient le processus d’exécution, le cache d’images, l’implémentation du stockage local et le rattachement réseau. Une ressource gérée peut donc être indisponible alors que son état souhaité reste enregistré ; la reprise commence par le rétablissement de la connectivité du démon ou du nœud, puis Opfield réconcilie.

Certains objets Docker appartiennent à un propriétaire de plus haut niveau. Les slots d’un Deployment sont contrôlés via leur Deployment, et les conteneurs portant des labels Compose sont regroupés dans le contexte du projet découvert. Ne modifiez pas les enfants gérés par un propriétaire via un chemin de cycle de vie autonome : les modifications directes peuvent créer une dérive entre l’état d’exécution du démon et la configuration enregistrée par Opfield.

Les conteneurs qu’Opfield n’a pas créés restent visibles et exploitables. Un conteneur autonome lancé avec docker run peut être redémarré et examiné avec des permissions limitées à la ressource, sans adoption, tandis qu’un projet Compose externe reste en lecture seule jusqu’à son adoption. Voir Conteneurs qu’Opfield n’a pas créés et Adopter un projet externe.

Les ressources internes gérées par Opfield peuvent comprendre des labels, des noms d’exécution, des réseaux, des volumes, des identifiants, des artefacts de build et des enregistrements de tâches. Considérez-les comme des détails d’implémentation, sauf si une action dans Opfield les expose explicitement. Les supprimer ou les renommer avec les outils Docker peut casser la réconciliation, le routage ou un futur retour arrière.

Comment s’effectue le travail de cycle de vie

Les changements de longue durée sont représentés par des tâches ou des opérations. Une opération enregistre l’intention, progresse au fil du travail du démon et se termine par un succès ou un échec qui peut être examiné plus tard. Lancer une seconde action conflictuelle pendant qu’une autre est active peut être refusé ou différé ; attendez la fin de l’opération en cours avant de réessayer.

Avant de modifier une charge de travail, examinez ses Routes dépendantes, ses liaisons de bases de données, ses droits, ses volumes montés, ses paramètres de source et sa politique de redémarrage. Avant de la supprimer, décidez si ses données et ses points d’entrée publics doivent être conservés ailleurs. Un arrêt réussi de l’exécution n’équivaut pas à une suppression terminée.

Les charges de travail atteignent les bases de données de l’une de deux façons. Une base de données managée peut être liée à un Container, un Deployment ou un service Compose, et Opfield injecte les valeurs de connexion d’une identité dédiée dans le moteur. Une base de données externe est atteinte via des valeurs de connexion que vous stockez comme secrets de la charge de travail. Voir Bases de données managées et externes en un coup d’œil.

Séquence d’exploitation sûre

Confirmez que le nœud Docker sélectionné est en ligne et dispose de la capacité d’exécution requise.
Examinez le propriétaire de la ressource et les ressources liées avant de modifier la configuration.
Effectuez un seul changement de cycle de vie intentionnel et suivez sa tâche jusqu’au bout.
Vérifiez la santé, les journaux de l’application et la route ou la connexion privée attendue.
Conservez une image réputée saine ou le slot de Deployment précédent jusqu’à la fin de la fenêtre de reprise.

Si une opération échoue, utilisez ses diagnostics pour distinguer les échecs liés à l’image, à la configuration, au stockage, aux ports, aux permissions et à la connectivité du nœud. Corrigez le prérequis identifié et réessayez depuis Opfield. Ne supprimez pas d’objets Docker appartenant à Opfield comme étape de reprise générique.

Critères de réussite

Une charge de travail est prête lorsque ses états souhaité et observé concordent, que l’opération propriétaire est terminée, que la santé et les journaux sont acceptables et que le chemin d’accès réel fonctionne. Pour les applications publiques, il s’agit de la Route ; pour les applications privées, il peut s’agir d’un Secure Link ou d’une dépendance à une base de données. Un processus en cours d’exécution sans accès vérifié n’est pas un déploiement réussi.

Pour chaque charge de travail de production, conservez un artefact réputé sain, documentez les données persistantes et la responsabilité de la reprise, et définissez la fenêtre de retour arrière. Testez l’action de reprise avant un incident. Les détails des ressources et les règles de nettoyage au niveau opérateur sont traités dans les pages ci-dessous.