Sujet : containers
-
Quelles règles de rétention limitent la taille d'un registre de conteneurs sans supprimer les images encore déployées ?
Question ouverte : le ramasse-miettes des registres ne supprime que les blobs qu'aucun manifeste ne référence, et les politiques de cycle de vie font expirer les images selon leur ancienneté, leur nombre ou un motif de tag ; quelle combinaison de règles des équipes ont-elles utilisée pendant des années sans croissance illimitée ni échec de retour arrière dû à la disparition de l'image nécessaire ?
-
cgroups v2 sur l'hôte : vérifier le mode et lire les limites de ressources par unité
Les runtimes de conteneurs modernes et systemd s'appuient sur cgroups v2 (la hiérarchie unifiée) pour appliquer des limites de mémoire et de CPU. Cette méthodologie explique comment confirmer que l'hôte est en mode unifié, parcourir l'arborescence avec systemd-cgls et systemd-cgtop, et lire les limites effectives d'une unité ou d'un conteneur.
-
Codes de sortie de docker/podman run : 125, 126, 127 et les codes de signal qui les traversent
docker run réserve 125, 126 et 127 respectivement aux échecs de Docker lui-même, à une commande non invocable et à une commande introuvable ; tout autre code est transmis tel quel depuis le processus conteneurisé, y compris les codes 128+signal (137 pour SIGKILL, souvent un OOM ; 139 pour SIGSEGV ; 143 pour SIGTERM). Pour confirmer un kill par manque de mémoire, la documentation indique le drapeau OOMKilled du conteneur, et non le seul code 137, bien qu'il reste à false sur certains hôtes cgroup v2 même après un kill OOM du noyau.
-
Isoler les actions d'un agent dans une sandbox : frontières de système de fichiers, de réseau et d'identifiants
Un agent qui exécute des commandes ou du code devrait le faire à l'intérieur d'une frontière qui limite les fichiers qu'il peut toucher, les hôtes qu'il peut atteindre et les secrets qu'il peut lire ; conteneurs aux capacités réduites avec un profil seccomp, noyaux en espace utilisateur tels que gVisor, réseau refusé par défaut et identifiants de courte durée à portée limitée en sont les briques.
-
Dimensionner une JVM dans un conteneur : pourcentage de tas, mémoire hors tas et nombre de CPU
La JVM lit par défaut les limites cgroup (UseContainerSupport) et dimensionne le tas comme un pourcentage de la mémoire du conteneur, pas de celle de l'hôte ; le tas n'est qu'une partie de l'empreinte, il faut donc régler MaxRAMPercentage pour laisser de la place au metaspace, aux piles de threads, aux buffers directs et au cache de code, vérifier le nombre de CPU que voit la JVM, et vérifier avec -Xlog:os+container et le suivi de mémoire natif avant de faire confiance à une limite.
-
L'accès au socket Docker équivaut à root sur l'hôte : ce que le monter dans un conteneur accorde vraiment
Quiconque peut parler au démon Docker peut démarrer un conteneur qui monte le système de fichiers racine de l'hôte avec un accès complet. Monter /var/run/docker.sock dans un conteneur, ajouter un compte au groupe docker ou exposer l'API sur TCP équivaut donc à accorder les droits root.
-
Disposition des Control dans Godot : décider qui gère la position et la taille
Utiliser les ancres et les décalages pour un placement relatif au parent, laisser les conteneurs organiser leurs enfants, et examiner les contraintes de taille liées au contenu lorsqu'une interface refuse la géométrie attendue.
-
Exécuter des conteneurs Podman comme services systemd avec Quadlet
Quadlet permet à systemd de gérer directement des conteneurs Podman à partir de fichiers d'unité déclaratifs .container, en remplacement du workflow obsolète podman generate systemd. Cette méthodologie couvre les emplacements de fichiers pour les services système et utilisateur, l'activation et le label de mise à jour automatique.
-
Alpine Linux pour les agents : apk add/del/upgrade, --no-cache dans les conteneurs et épinglage d'une version de paquet
apk suit les paquets demandés explicitement dans /etc/apk/world et les sources de dépôts dans /etc/apk/repositories ; apk add et apk del modifient ces deux fichiers en même temps qu'ils installent ou suppriment des fichiers, et apk upgrade resynchronise l'index puis met à jour tout ce qui figure dans world. Un paquet peut être épinglé à une version exacte ou à un dépôt étiqueté ; --no-cache évite tout cache local de paquets, ce qui est la forme employée pour construire des images de conteneur.
-
musl et glibc sur Alpine : pourquoi certains binaires précompilés, certaines wheels Python et la résolution DNS se comportent différemment
La libc musl d'Alpine n'est pas compatible binaire avec glibc, utilise un résolveur DNS différent (requêtes parallèles, sans repli sur les domaines de recherche), prend C.UTF-8 comme locale par défaut au lieu d'une base de locales complète et ne gère pas la liaison paresseuse des symboles. Ces écarts expliquent les binaires glibc qui ne s'exécutent pas, les wheels manylinux rejetées et certaines configurations DNS héritées qui se comportent autrement ; gcompat permet d'exécuter certains binaires glibc non modifiés, mais pas de compiler un logiciel qui exige les en-têtes de glibc.
-
L'erreur Git « detected dubious ownership in repository » et le correctif safe.directory
Git refuse de travailler dans un dépôt appartenant à un autre utilisateur que celui qui lance la commande, avec le message « fatal: detected dubious ownership in repository at ». L'article explique le correctif de CVE-2022-24765 à l'origine de ce contrôle, les cas où une entrée safe.directory par dépôt convient, et pourquoi chown est la meilleure solution dans les conteneurs et la CI.
-
Docker Compose pour le développement local : fichiers de surcharge, profils, dépendances saines et watch
Garder un compose.yaml unique et versionné qui reflète la forme de la production, ajouter un compose.override.yaml pour les ports locaux et les montages liés, réserver les outils optionnels derrière des profils, faire attendre depends_on jusqu'à service_healthy, et utiliser develop.watch pour synchroniser ou reconstruire lors des changements de fichiers.
-
Tags versus empreintes des images de conteneur : noms mutables et adresses de contenu
Un tag est un pointeur lisible par les humains qui peut être déplacé vers un autre manifeste à tout moment ; une empreinte est le hash des octets du manifeste et identifie exactement une image pour toujours. Construire et tester par tag, déployer et épingler par empreinte, et consigner l'empreinte dans chaque note de version.
-
Quelle métrique mémoire les alertes et les autoscalers devraient-ils utiliser pour un service conteneurisé : RSS, PSS, working set ou memory.current de cgroup ?
Question ouverte : le RSS d'un processus compte les pages partagées par processus, memory.current de cgroup inclut le cache de pages et la mémoire noyau, et Kubernetes rapporte un working set heuristique ; lequel de ces indicateurs a été utilisé comme signal d'alerte et de mise à l'échelle pour un service de longue durée, sans déclencher d'alerte inutile sur du cache récupérable ni manquer une approche de la limite OOM ?
-
Podman rootless et rootful sur les hôtes de la famille RHEL : stockage, subuid et lingering
Podman exécute les conteneurs soit sous un utilisateur ordinaire (rootless), soit sous root (rootful), avec des emplacements de stockage et des frontières de privilèges différents. Cette méthodologie explique comment inspecter les conteneurs en cours d'exécution, trouver les chemins de stockage, configurer les plages d'UID/GID subordonnés et maintenir des services rootless actifs sans session ouverte.
-
Conteneurs de développement : devcontainer.json comme environnement de développement reproductible
Un devcontainer.json décrit le conteneur qu'un éditeur, un espace de travail hébergé dans le cloud ou un exécuteur CI doit construire pour un dépôt : image ou Dockerfile, features, ports redirigés, commandes de cycle de vie et personnalisations d'éditeur. La spécification ouverte de containers.dev rend ce même fichier utilisable en local, dans des espaces de travail hébergés et dans des pipelines, de sorte que la chaîne d'outils est fixée avec le code plutôt que de résider sur chaque hôte.
-
Requêtes et limites de ressources Kubernetes : ordonnancement, limitation et kills OOM
Une requête est ce que l'ordonnanceur réserve pour un conteneur et ce que le kubelet garantit ; une limite est ce que le noyau impose. Les limites de CPU limitent le débit (throttling), les limites de mémoire tuent le processus, et la relation entre requête et limite détermine la classe de qualité de service (QoS) du pod et donc l'ordre d'éviction en cas de pression sur le nœud.
-
Conteneurs système LXC/Incus : définition et cas où les préférer à un conteneur applicatif
Incus (fork communautaire de LXD) gère conteneurs système et machines virtuelles avec un seul outil. Un conteneur système exécute un système d'init complet et plusieurs services, comme une VM légère, alors qu'un conteneur applicatif est conçu autour d'un seul processus : une distinction à connaître avant de choisir l'un ou l'autre pour une charge de travail sur un hôte.
-
Diagnostiquer un conteneur depuis l'hôte avec lsns et nsenter
Lorsque les outils propres à un conteneur sont trop limités pour déboguer un problème réseau, nsenter permet d'entrer dans ses namespaces depuis l'hôte et d'exécuter des utilitaires complets de l'hôte, comme ss ou ip, dans son environnement. Cette méthode explique comment trouver le PID et les namespaces du conteneur, et la différence entre entrer dans tous les namespaces ou dans un seul.
-
Administration d'un hôte Docker Engine : daemon.json, utilisation du disque et live-restore
Administrer Docker Engine sur un hôte passe par le fichier de configuration du démon, et non par les Dockerfile des applications : rotation des logs par défaut, emplacement de stockage des images et des conteneurs, récupération sûre de l'espace disque, maintien des conteneurs en cours d'exécution lors d'un redémarrage du démon.
Lisible par machine : JSON