Conteneurs

Un Container est l’option de gestion directe d’un environnement d’exécution Docker. Opfield stocke sa configuration et ses relations d’accès, tandis que le démon Docker sélectionné démarre et supervise le processus réel. Utilisez un Container lorsque des slots de publication blue/green ou une propriété de projet multiservice ne sont pas nécessaires. Les conteneurs qui s’exécutent déjà sur un nœud Docker sont listés et peuvent être exploités sans être recréés par Opfield ; voir Conteneurs qu’Opfield n’a pas créés.

Quand un Container est le bon propriétaire

Choisissez un Container pour un service unique dont le redémarrage, la mise à jour et la reprise peuvent être gérés comme un seul environnement d’exécution. Il convient bien aux outils internes, aux agents, aux services sans état et aux charges de travail avec une relation simple à un volume persistant. Le propriétaire de l’application reste responsable de décider si le remplacement du processus est sûr et si ses données nécessitent une sauvegarde ou une fenêtre de maintenance.

Choisissez plutôt un Deployment lorsqu’une version doit être préparée et vérifiée avant que le trafic ne bascule, avec un candidat au retour arrière conservé. Choisissez Compose lorsque plusieurs services, réseaux, variables et volumes doivent évoluer dans une même révision. Un Container est volontairement direct ; Opfield n’invente pas de stratégie de publication applicative autour de lui.

Le succès signifie davantage qu’un état running. La vérification de santé attendue doit réussir, l’application doit écouter sur le port sélectionné, sa Route ou sa connexion privée doit fonctionner, et les données persistantes doivent rester rattachées après une recréation. Définissez ces vérifications avant la première mise à jour en production.

Conteneurs qu’Opfield n’a pas créés

Le démon Docker signale chaque conteneur de son nœud, et pas seulement ceux créés via Opfield. Un conteneur lancé avec docker run ou par un autre outil, sans labels de projet Docker Compose, apparaît dans Docker > Containers comme un Container autonome ordinaire, avec une identité de ressource Opfield stable. Il n’y a pas d’étape d’adoption distincte : les utilisateurs disposant des scopes correspondants peuvent consulter ses journaux, statistiques et processus, le démarrer, l’arrêter, le redémarrer ou le tuer, ouvrir la console ou l’explorateur de fichiers, et le modifier ou le recréer.

Opfield n’accorde automatiquement à personne l’accès à un conteneur découvert. Les utilisateurs disposant de scopes Docker à l’échelle du nœud ou globaux le voient immédiatement ; les autres utilisateurs ont besoin d’un droit de groupe ou direct sur ce conteneur, son nœud ou un dossier Docker qui le contient. Voir Exploiter des charges de travail sans les adopter pour des exemples de droits.

Deux autres types de conteneurs sont traités différemment :

• Conteneurs Compose. Un conteneur portant un label com.docker.compose.project appartient à son projet Compose et n’est pas listé comme Container autonome. Les journaux, la supervision, la console et l’accès aux fichiers restent disponibles pour ses services. Le démarrage, l’arrêt, le redémarrage, la modification, la recréation, la duplication et la suppression sont refusés pour les conteneurs Compose individuels, que le projet soit externe ou géré par Opfield.
• Conteneurs internes d’Opfield. Les conteneurs de service qu’Opfield exécute pour lui-même sont masqués des API de cycle de vie des utilisateurs.

Les droits limités à une ressource suivent l’identité de la ressource Opfield. Opfield conserve cette identité, et les droits qui s’y rattachent, lors d’une recréation ou d’une mise à jour effectuée via Opfield. Si un conteneur est supprimé puis relancé hors d’Opfield, même sous le même nom, Opfield enregistre une nouvelle ressource et révoque les droits sur l’ancienne. Modifiez via Opfield les conteneurs qui portent des droits limités à la ressource, ou accordez l’accès au niveau du nœud ou du dossier.

Avant de commencer

Vous avez besoin d’un accès au nœud Docker cible et de la permission de créer ou de modifier le Container. Vérifiez que l’image est disponible dans un registre autorisé, que le nœud dispose de la capacité nécessaire et que l’environnement d’exécution demandé est pris en charge. Examinez les ports, les Routes, les liaisons de bases de données, les volumes managés et les secrets avant de choisir un nom : ces relations peuvent influer sur un renommage, une migration ou une suppression ultérieurs. Un Container peut être lié à une base de données managée ; une base de données externe est atteinte via des valeurs de connexion stockées comme secrets du Container. Voir Bases de données managées et externes en un coup d’œil.

Les nouveaux montages de répertoires de l’hôte sont refusés. Utilisez des volumes locaux gérés par Opfield pour les nouvelles données persistantes. Les anciens montages de répertoires peuvent subsister lors d’une mise à jour ordinaire, mais une fois retirés, ils ne peuvent pas être rajoutés via Opfield.

Une charge de travail dotée d’anciens montages de répertoires de l’hôte les conserve lors des changements qui ne modifient pas son image, comme les modifications d’environnement, les liens vers des bases de données ou du stockage et les bascules de slots de déploiement ; ceux-ci ne nécessitent pas docker:containers:mounts. Une nouvelle image obtient le même accès à l’hôte ; la modifier nécessite donc ce scope : de la part de la personne qui lance le changement et, pour les déploiements Git automatiques et les webhooks, de la part du compte qui a enregistré en dernier la source ou le webhook, vérifié au moment du déploiement. Les webhooks enregistrés avant 2.11 n’ont pas de compte enregistré et sont refusés sur de telles charges de travail jusqu’à ce qu’une personne détenant le scope les enregistre à nouveau.

L’environnement d’exécution Default est disponible sur les nœuds Docker pris en charge. L’environnement d’exécution sécurisé gVisor nécessite une capacité signalée saine et ne peut pas être combiné avec des GPU, des périphériques, des montages de répertoires de l’hôte, la migration ou l’export d’archives.

Créer et mettre à jour un Container

1. Sélectionnez le nœud Docker et l’image, de préférence une empreinte immuable pour une charge de travail de production.
2. Définissez la commande, le point d’entrée (entrypoint), l’environnement, les secrets chiffrés, les labels, les ports, la politique de redémarrage, les limites de ressources, les vérifications de santé et les volumes managés.
3. Examinez la configuration résolue et créez le Container.
4. Suivez la tâche de création jusqu’à ce que le démon signale l’état d’exécution.
5. Vérifiez la santé, les journaux et toute Route ou connexion privée à une base de données avant d’envoyer du trafic applicatif.

Certains espaces de noms de labels sont réservés, car Opfield et Docker Compose les utilisent pour placer, regrouper ou masquer des conteneurs : tout label commençant par com.docker.compose. ou net.opfield., ou par les préfixes antérieurs à Opfield wiolett.gateway., net.wiolett.gateway. et com.wiolett.gateway., ainsi que le label gateway.sandbox. La création d’un Container avec l’un d’eux est refusée dans la Console, l’API REST et MCP avec Labels <names> are reserved for Opfield and Docker Compose. La recréation ou la mise à jour d’un Container renvoie ses labels dans leur ensemble : les labels réservés qu’il possède déjà peuvent revenir inchangés, mais en ajouter ou en modifier un échoue avec 400 RESERVED_DOCKER_LABEL. Duplicate omet les labels réservés dans la copie, en ne conservant que les enregistrements propres au démon Docker concernant la configuration copiée, comme la provenance d’un groupe de GPU. Les démons Docker plus anciens copient tous les labels ; sur un nœud dont le démon n’a pas été mis à jour, la duplication d’un conteneur portant des labels réservés est donc refusée avec 409 UNSUPPORTED_DAEMON jusqu’à la mise à jour du démon. L’import d’une archive de conteneur supprime les labels Compose ainsi que les labels d’archive, de Deployment et de migration d’Opfield au lieu de refuser l’archive.

Sur un nœud Docker dont le pilote de journalisation par défaut est json-file, Opfield limite les journaux de chaque conteneur qu’il crée ou recrée sans configuration de journalisation propre à trois fichiers de 50 Mo. Les projets Compose reçoivent la même limite pour chaque service sans section logging propre ; voir Configuration Compose prise en charge. Les autres pilotes de journalisation ne sont pas modifiés, et un nœud dont le fichier /etc/docker/daemon.json définit des log-opts par défaut les conserve. Lorsque le script de configuration du nœud Docker installe Docker lui-même, il écrit ce fichier avec la même rotation de 50 Mo × 3 ; les conteneurs créés hors d’Opfield sont donc aussi limités.

Pour trouver les conteneurs dont les journaux continuent de croître sans limite, créez une alerte de Container sur Log Size (MB). Elle compte le fichier journal du conteneur et ses copies issues de la rotation sur le nœud ; un démon Docker pas encore mis à jour signale zéro.

Utilisez Recreate lorsqu’un changement de configuration d’exécution nécessite un processus de remplacement. Opfield préserve l’identité stable de la ressource tout en recréant l’exécution prévue. Utilisez Duplicate lorsque vous avez besoin d’une ressource distincte avec des droits d’accès et un historique de cycle de vie indépendants. N’utilisez Rename qu’après avoir examiné les Routes, liaisons et intégrations dépendantes. Un nom détenu par une source Git dont le conteneur attend encore son premier build ne peut pas être pris en créant, dupliquant, renommant ou important un autre conteneur : la requête échoue avec 409 NAME_IN_USE. Supprimer un conteneur supprime aussi sa source Git, et le renommer déplace la source vers le nouveau nom.

Duplicate copie les secrets propres au conteneur, mais pas ses liens vers les bases de données ou le stockage : les variables injectées par ces liens sont omises de la copie. L’inspection, l’onglet Environment et l’export d’archive ne révèlent jamais les mots de passe des liens ni les clés des liens de stockage. La mise à jour de l’image d’un conteneur nécessite docker:containers:environment et docker:containers:secrets, car le nouvel environnement d’exécution reçoit l’environnement et les secrets du conteneur, et le rattachement d’un conteneur à des réseaux nécessite un droit de modification sur ces réseaux.

Vérifier et exploiter

La vue de détail est l’enregistrement opérationnel : confirmez l’état souhaité et l’état observé, le résultat de santé, l’identité de l’image, les tâches récentes et les journaux. La vue d’ensemble indique le profil d’exécution du conteneur, par exemple Secure · gVisor, et la supervision affiche ses limites de mémoire et de PID à côté de l’utilisation. Stop sur un conteneur qui n’exécute rien — créé, terminé ou mort — se termine immédiatement. N’utilisez l’accès à la console ou aux fichiers que dans le cadre des scopes qui vous sont accordés, et évitez d’utiliser une console interactive comme chemin de déploiement normal.

Après un redémarrage ou une reconnexion du démon, Opfield réconcilie l’état souhaité enregistré. Si le Container s’exécute mais ne peut pas servir de trafic, vérifiez dans cet ordre sa vérification de santé, le port d’écoute, la cible de la Route, l’environnement et le journal de l’application.

L’onglet Environment

L’onglet Environment contient trois blocs, de haut en bas :

• Links : les connexions privées du Container. Add link demande à quoi la charge de travail se connecte : une base de données managée (ses identifiants deviennent des variables, voir liaisons), un stockage managé (des identifiants de stockage objet privés pour les buckets choisis, définis comme variables), ou un port d’un autre conteneur, déploiement ou service Compose (un lien entre conteneurs). Les liens que d’autres charges de travail ouvrent vers celle-ci sont listés comme entrants. Les modifications des liens vers les bases de données et le stockage s’appliquent avec Save & Recreate, ou au prochain démarrage d’un Container arrêté.
• Environment Variables : un tableau de clés et de valeurs. Edit as text ouvre toutes les variables sous forme de lignes KEY=value, une par ligne ; Apply les replace dans le tableau, et elles sont stockées lors de l’enregistrement. Utilisez-le pour coller un fichier .env ou modifier de nombreuses valeurs à la fois.
• Secrets : des valeurs chiffrées injectées comme variables d’environnement au démarrage du Container ; elles ne sont plus jamais affichées après l’enregistrement.

L’enregistrement des variables recrée un Container en cours d’exécution, après confirmation ; attendez-vous donc à une brève interruption. Sur un Container arrêté, elles sont enregistrées et s’appliquent à son démarrage. Un Container qui appartient à une app reçoit aussi les variables et secrets de son environnement ; ces clés sont signalées dans cet onglet.

Gestion des échecs et nettoyage

Un échec de récupération d’image, un identifiant de registre indisponible, un conflit de ports, un montage invalide, une capacité d’exécution non prise en charge ou des ressources de nœud épuisées doivent être corrigés avant toute nouvelle tentative. Pendant le déploiement d’un build Git sur le Container, les changements de cycle de vie, de configuration et de secrets renvoient BUILD_ROLLOUT_IN_PROGRESS jusqu’à la fin du déploiement ; voir Sources Git et Build Workers. L’historique des tâches identifie l’étape qui s’est arrêtée ; réessayer sans modifier le prérequis répète généralement le même échec. Les erreurs que vous pouvez corriger reviennent sous forme d’erreurs client avec leur propre code, par exemple 409 HOST_PORT_IN_USE avec le port, 409 IMAGE_NOT_ON_NODE, 409 DISK_IMAGE_VOLUMES_UNSUPPORTED lorsque le nœud n’a plus de périphérique loop libre pour un volume sur image disque, et 404 CONTAINER_NOT_FOUND. La recréation d’un conteneur Secure Runtime avec un GPU est refusée avec 409 SECURE_RUNTIME_GPU_UNSUPPORTED avant l’arrêt du conteneur.

Avant la suppression, examinez les Routes, les liaisons de bases de données, les droits, les volumes, les paramètres de source et les données exportées. Supprimer le Container retire ses droits sur la ressource ainsi que ses liens vers les bases de données et le stockage ; un Container ultérieur portant le même nom n’hérite donc ni des accès ni des identifiants des liens. Un Container qui attend le premier build de sa source Git ne peut pas être supprimé seul (409 SOURCE_CONTAINER_NOT_BUILT) ; supprimez plutôt sa source Git. La suppression d’un volume est une action destructive distincte ; conservez ou sauvegardez les données persistantes avant de supprimer l’une ou l’autre ressource.

Détails pour l’opérateur : recréation et reprise

Un changement de configuration qui touche l’image, la commande, l’environnement, les montages, l’environnement d’exécution, les ports, les limites ou le comportement de redémarrage peut nécessiter une recréation. La recréation remplace l’exécution Docker tout en préservant l’identité stable du Container dans Opfield et les relations prises en charge. Les sessions en cours dans le processus sont interrompues ; planifiez donc l’opération ou utilisez un Deployment lorsqu’une interruption est inacceptable.

Avant la recréation, consignez l’empreinte d’image actuelle, le résultat de santé, les volumes rattachés, l’état des Routes et des liaisons, et toute exigence de vidage propre à l’application. Une fois la tâche terminée, comparez la nouvelle exécution avec l’état souhaité enregistré et testez le chemin client réel. Si le démarrage échoue, rétablissez la configuration ou l’image précédentes réputées saines et recréez à nouveau ; ne modifiez pas l’objet Docker en échec hors d’Opfield.

Si le nœud Docker se déconnecte pendant une opération, attendez un nouvel inventaire après la reconnexion avant de réessayer. L’hôte peut avoir terminé l’action d’exécution sans l’acquitter. Si un Container est manquant mais que son état souhaité existe toujours, utilisez le chemin de réconciliation ou de recréation pris en charge. Supprimer et recréer l’enregistrement Opfield modifie la propriété et les droits, et ne doit pas être la première action de reprise.

L’accès à la console et aux fichiers sert aux incidents et à l’inspection, et ne remplace pas une configuration reproductible. Les modifications effectuées uniquement à l’intérieur d’un conteneur en cours d’exécution peuvent disparaître à la prochaine recréation et doivent être déplacées dans l’image, la configuration gérée ou un volume persistant.