Images, volumes et réseaux
Les images, les volumes et les réseaux sont des ressources du démon Docker qui peuvent être partagées par plusieurs charges de travail. Opfield signale et gère les ressources éligibles, mais un nettoyage sûr dépend toujours de la connaissance de leurs propriétaires et de leurs références. Considérez l’inventaire d’un nœud hors ligne comme une information du dernier état connu jusqu’à la fin de la synchronisation.
Définir la propriété avant le nettoyage
Section intitulée « Définir la propriété avant le nettoyage »Ces ressources ressemblent à de l’inventaire, mais elles comportent des risques différents. Les images conditionnent la capacité à démarrer un logiciel ou à revenir en arrière. Les volumes peuvent contenir l’unique copie des données d’une application. Les réseaux peuvent faire partie de la découverte de services ou de la connectivité privée. Le responsable de la plateforme doit définir des règles de conservation et de sauvegarde pour chaque catégorie au lieu d’appliquer une politique générique « inutilisé ».
Un libellé unused signifie que l’inventaire Docker synchronisé actuel ne contient aucun rattachement actif ; il ne prouve pas que la ressource peut être supprimée sans danger. Une charge de travail arrêtée, un slot de Deployment conservé, une migration en attente, un runbook de reprise ou un processus Compose externe peuvent encore en dépendre. Un nettoyage réussi signifie que du stockage a été récupéré sans supprimer un artefact de reprise, un jeu de données ou une frontière de connectivité nécessaires.
Les images font partie de l’inventaire local du nœud. Récupérez une image lorsqu’une charge de travail en a besoin, examinez son empreinte et sa provenance avant tout usage en production, et préférez des empreintes immuables pour les publications. Les artefacts construits à partir d’un dépôt doivent être suivis par empreinte plutôt que par un tag modifiable.
Avant de supprimer une image ou de lancer un élagage (prune), vérifiez les Containers actifs, les slots de retour arrière inactifs des Deployments, les tâches en cours et toute action de reprise prévue. Un nettoyage local au nœud peut faire échouer un redémarrage ultérieur jusqu’à ce que l’image soit récupérée à nouveau. Ne supprimez que les images dont l’inutilisation est confirmée, et attendez la synchronisation du démon avant de juger si un nettoyage est terminé. Les images qu’Opfield a construites depuis Git pour des Containers, Deployments et projets Compose qui n’existent plus sont retirées automatiquement du nœud ; une image de build inutilisée peut aussi être supprimée à la main, et la suppression d’une image encore utilisée par un conteneur du nœud est refusée avec 409 OPFIELD_INTERNAL_IMAGE.
Les volumes locaux gérés par Opfield sont la destination prise en charge pour les nouveaux montages persistants. Un volume survit à un Container, sauf s’il est supprimé séparément, ce qui est utile pour une recréation planifiée mais dangereux lorsque les données ne sont plus sauvegardées.
Renommer, réétiqueter, redimensionner et adopter un volume nécessitent docker:volumes:edit, qui peut être restreint à un volume, un nœud ou un dossier. Un chemin de l’hôte saisi là où un nom de volume est attendu est refusé avec un message clair, et chaque nom de volume est vérifié avant la création de tout volume.
Volumes sur image disque
Section intitulée « Volumes sur image disque »À partir de Personal, un volume peut être une Disk image : un stockage ext4 de capacité fixe qui peut être agrandi plus tard. Les nouveaux volumes sur image disque sont accessibles en écriture aux applications qui ne s’exécutent pas en root. Chacun occupe un périphérique loop sur son nœud Docker tant qu’il existe ; dimensionnez donc en conséquence l’ensemble de périphériques loop d’un nœud Docker LXC.
Le démon Docker monte les volumes sur image disque avant le démarrage de Docker, via une étape de démarrage nommée opfield-volume-images (qui remplace l’ancienne gateway-volume-images) qu’il installe pour systemd ou OpenRC. Si l’image d’un volume ne peut pas être montée au démarrage, son point de montage reçoit un substitut vide en lecture seule ; un conteneur n’écrit donc rien sur le système de fichiers racine du nœud et échoue à la place avec Read-only file system. Le démon monte l’image dès qu’il le peut, à son démarrage ou lors de sa vérification toutes les 10 minutes, puis redémarre les conteneurs qui utilisent le volume afin qu’ils voient leurs données. Un volume impossible à monter ne désactive plus les volumes sur image disque de tout le nœud.
Avant de déplacer, recréer, exporter ou supprimer une charge de travail, identifiez tous les volumes rattachés et effectuez une sauvegarde adaptée au moteur pour les données avec état. La suppression d’un volume est destructive et ne peut pas être annulée en recréant la charge de travail. Les exports d’archives de conteneurs n’incluent pas le contenu des volumes ; la restauration des volumes est donc une étape de reprise distincte.
Les réseaux assurent la connectivité entre charges de travail et peuvent être des ressources d’implémentation privées. Un réseau créé par une charge de travail gérée ou par un propriétaire de plus haut niveau ne doit pas être supprimé manuellement : les Routes, les liaisons de bases de données, la découverte de services et la réconciliation peuvent en dépendre.
Rattacher un conteneur à un réseau nécessite un droit de modification sur ce réseau. Les projets Compose et les archives de conteneurs importées ne peuvent pas utiliser le réseau de l’hôte ni les réseaux internes d’Opfield : opfield-secure-links, les réseaux de liens des bases de données managées opfield-db-*, les réseaux du stockage managé opfield-storage-* et les réseaux des liens entre conteneurs opfield-link-*. Les réseaux créés avant 2.12.1 conservent leurs noms gateway- et sont traités de la même manière. Ces réseaux internes sont masqués de la liste des réseaux : ils ne peuvent pas être connectés, déconnectés, supprimés ni utilisés par de nouveaux conteneurs, et un nouveau réseau ne peut pas prendre un nom de cette forme. Les réseaux non externes appartenant à Compose restent sous le processus Compose externe. Les réseaux externes ou intentionnellement partagés restent des ressources globales et ne doivent être supprimés qu’après le détachement de chaque charge de travail qui y fait référence. Vérifiez d’abord l’état du nœud et les références ; un réseau apparemment inutilisé sur un nœud hors ligne ne suffit pas à justifier une suppression.
Liste de contrôle pour un nettoyage sûr
Section intitulée « Liste de contrôle pour un nettoyage sûr »- Attendez que le nœud Docker soit en ligne et que l’inventaire actuel soit synchronisé.
- Identifiez le propriétaire de la ressource et chaque référence active, de retour arrière ou de reprise.
- Sauvegardez les données avant toute modification d’un volume.
- Effectuez une seule action de nettoyage via Opfield et suivez sa tâche.
- Vérifiez ensuite la santé attendue des charges de travail et le rattachement du stockage et des réseaux.
Si une tâche de suppression échoue, ne réessayez pas avec une suppression forcée au niveau du démon. Lisez l’échec, rétablissez le prérequis manquant ou détachez la dépendance enregistrée, puis relancez l’action Opfield prévue.
Détails pour l’opérateur : élagage et vérification
Section intitulée « Détails pour l’opérateur : élagage et vérification »N’exécutez l’élagage que sur un nœud en ligne disposant d’un inventaire récent, et examinez l’ensemble des candidats avant de confirmer. Les ressources internes d’Opfield et les ressources enfants gérées par un propriétaire sont masquées ou protégées lorsque le produit peut les identifier, mais les opérateurs doivent tout de même examiner la propriété externe et partagée. Ne planifiez pas un élagage large comme seul mécanisme de conservation pour les nœuds de production.
Après un nettoyage d’images, vérifiez que les charges de travail actives restent saines et que les artefacts de retour arrière réputés sains nécessaires peuvent encore être récupérés ou sont conservés. Après un nettoyage de volumes, comparez la taille récupérée et confirmez qu’aucun montage attendu n’a disparu. Après un nettoyage de réseaux, vérifiez la découverte de services, la santé de Compose, les Routes et les liaisons de bases de données qui traversent les frontières entre charges de travail.
Si un nettoyage a supprimé une image nécessaire par la suite, restaurez-la depuis le registre de confiance par son empreinte. Un volume supprimé nécessite une restauration à partir de la sauvegarde de l’application ; recréer le nom du volume ne restaure pas les données. Un réseau partagé supprimé peut nécessiter de recréer sa configuration prévue et de rattacher explicitement chaque propriétaire ; conservez donc ses paramètres avant la suppression.