Thema: containers
-
Welche Regeln zur Image-Aufbewahrung halten eine Container-Registry klein, ohne noch eingesetzte Images zu löschen?
Offene Frage: Registries räumen per Garbage Collection nur Blobs auf, auf die kein Manifest mehr verweist, und Lifecycle-Richtlinien lassen Images nach Alter, Anzahl oder Tag-Muster ablaufen; welche Kombination von Regeln haben Teams jahrelang betrieben, ohne unbegrenztes Wachstum oder einen fehlgeschlagenen Rollback, weil dessen Image nicht mehr vorhanden war?
-
cgroups v2 auf dem Host: Modus prüfen und Ressourcenlimits pro Unit auslesen
Moderne Container-Runtimes und systemd setzen für Speicher- und CPU-Limits auf cgroups v2 (die vereinheitlichte Hierarchie). Diese Methodik zeigt, wie sich der Unified-Modus des Hosts bestätigen, der Baum mit systemd-cgls/systemd-cgtop durchsuchen und die tatsächlichen Limits einer Unit oder eines Containers auslesen lassen.
-
Exit-Codes von docker/podman run: 125, 126, 127 und die durchgereichten Signal-Codes
docker run reserviert 125, 126 und 127 für Fehler von Docker selbst, für einen nicht ausführbaren Befehl und für einen nicht gefundenen Befehl. Jeder andere Code stammt unverändert vom Prozess im Container, auch die Codes 128+Signal (137 für SIGKILL, oft OOM; 139 für SIGSEGV; 143 für SIGTERM). Dokumentierter Nachweis eines Out-of-Memory-Kills ist das Flag OOMKilled des Containers, nicht die blosse 137; auf manchen cgroup-v2-Hosts bleibt es jedoch auch nach einem Kernel-OOM-Kill false.
-
Agentenhandlungen sandboxen: Grenzen für Dateisystem, Netzwerk und Zugangsdaten
Ein Agent, der Befehle oder Code ausführt, sollte dies innerhalb einer Grenze tun, die einschränkt, auf welche Dateien er zugreifen, welche Hosts er erreichen und welche Geheimnisse er lesen kann; Container mit entzogenen Capabilities und einem seccomp-Profil, User-Space-Kernel wie gVisor, ein standardmässig gesperrtes Netzwerk und kurzlebige, eng begrenzte Zugangsdaten sind die Bausteine dafür.
-
Eine JVM in einem Container dimensionieren: Heap-Prozentsatz, Non-Heap-Speicher und CPU-Anzahl
Die JVM liest standardmässig cgroup-Grenzen (UseContainerSupport) und bemisst den Heap als Prozentsatz des Container-Speichers, nicht des Host-Speichers; der Heap ist nur ein Teil des Speicherbedarfs, daher MaxRAMPercentage so setzen, dass Platz für Metaspace, Thread-Stacks, Direct Buffers und Code-Cache bleibt, die von der JVM gesehene CPU-Anzahl prüfen und mit -Xlog:os+container sowie Native Memory Tracking verifizieren, bevor einer Grenze vertraut wird.
-
Zugriff auf den Docker-Socket ist Root auf dem Host: was das Einbinden in einen Container wirklich gewährt
Wer mit dem Docker-Daemon sprechen kann, kann einen Container starten, der das Wurzeldateisystem des Hosts mit vollem Zugriff einbindet. Das Einbinden von /var/run/docker.sock in einen Container, das Hinzufügen einer nutzenden Person zur docker-Gruppe oder das Offenlegen der API über TCP ist deshalb gleichbedeutend mit der Vergabe von Root-Rechten.
-
Godot-Control-Layout: Festlegen, wer Position und Grösse bestimmt
Anchors und Offsets platzieren Elemente relativ zum Parent, Container ordnen ihre Kinder selbst an. Bei unerwarteter Geometrie lohnt ein Blick auf die inhaltsabhängigen Grössenbeschränkungen.
-
Podman-Container mit Quadlet als systemd-Dienste betreiben
Quadlet erlaubt es systemd, Podman-Container direkt aus deklarativen .container-Unit-Dateien zu verwalten, und ersetzt den veralteten Workflow mit podman generate systemd. Die Methodik behandelt Dateiorte für System- und Benutzerdienste, die Aktivierung und das Label für automatische Updates.
-
Alpine Linux für Agenten: apk add/del/upgrade, --no-cache in Containern und Pinning einer Paketversion
apk führt ausdrücklich angeforderte Pakete in /etc/apk/world und Repository-Quellen in /etc/apk/repositories. apk add und apk del ändern beide Dateien zusammen mit der Installation bzw. Entfernung der Paketdateien, apk upgrade aktualisiert den Index und alle Pakete in world, und ein Paket lässt sich auf eine exakte Version oder ein getaggtes Repository festlegen. --no-cache umgeht den lokalen Paket-Cache vollständig und wird in Container-Image-Builds verwendet.
-
musl versus glibc unter Alpine: Warum manche vorkompilierten Binaries, Python-Wheels und das DNS-Verhalten abweichen
Das musl libc von Alpine ist nicht binärkompatibel zu glibc, hat einen anderen DNS-Resolver (parallele Abfragen, kein Rückfall auf die Suchdomäne), verwendet standardmässig die Locale C.UTF-8 statt einer vollständigen Locale-Datenbank und unterstützt kein Lazy Binding von Symbolen. Daraus erklärt sich, warum glibc-Binaries nicht starten, manylinux-Python-Wheels abgelehnt werden und manche DNS-Altkonfigurationen anders reagieren. gcompat kann manche unveränderten glibc-Binaries ausführen, eignet sich aber nicht zum Bauen von Software, die selbst glibc-Header benötigt.
-
Gits Fehlermeldung „detected dubious ownership in repository“ und die Lösung mit safe.directory
Git verweigert die Arbeit in einem Repository, das einem anderen Benutzer gehört als dem, der den Befehl ausführt, und meldet 'fatal: detected dubious ownership in repository at'. Der Artikel erklärt die Korrektur für CVE-2022-24765 dahinter, wann ein repositoryspezifischer safe.directory-Eintrag richtig ist und warum chown in Containern und CI die bessere Lösung ist.
-
Docker Compose für die lokale Entwicklung: Override-Dateien, Profile, gesunde Abhängigkeiten und Watch
Eine einzige committete compose.yaml pflegen, die die Produktionsform widerspiegelt, eine compose.override.yaml für lokale Ports und Bind-Mounts hinzufügen, optionale Werkzeuge hinter Profile stellen, depends_on auf service_healthy warten lassen und develop.watch nutzen, um bei Dateiänderungen zu synchronisieren oder neu zu bauen.
-
Container-Image-Tags versus Digests: veränderliche Namen und Inhaltsadressen
Ein Tag ist ein menschenlesbarer Zeiger, der jederzeit auf ein anderes Manifest umgehängt werden kann; ein Digest ist der Hash der Manifest-Bytes und identifiziert für immer genau ein Image. Nach Tag bauen und testen, nach Digest deployen und pinnen, und den Digest in jeder Release-Notiz festhalten.
-
Welche Speichermetrik sollten Alarme und Autoscaler für einen containerisierten Dienst verwenden: RSS, PSS, Working Set oder cgroup memory.current?
Offene Frage: Der Prozess-RSS zählt gemeinsam genutzte Seiten je Prozess, cgroup memory.current umfasst Page-Cache und Kernel-Speicher, und Kubernetes meldet ein heuristisches Working Set; welche dieser Grössen wurde für einen langlaufenden Dienst als Signal für Alarmierung und Skalierung verwendet, ohne entweder wegen reklamierbarem Cache zu alarmieren oder eine Annäherung an das OOM-Limit zu verpassen?
-
Podman rootless und rootful auf Hosts der RHEL-Familie: Storage, subuid und Lingering
Podman startet Container als normaler Benutzer (rootless) oder als root (rootful), mit unterschiedlichen Storage-Pfaden und Privilegiengrenzen. Die Methodik zeigt, wie laufende Container inspiziert, Storage-Pfade gefunden, Subordinate-UID/GID-Bereiche eingerichtet und rootless Dienste ohne Login-Session am Laufen gehalten werden.
-
Dev Containers: devcontainer.json als reproduzierbare Entwicklungsumgebung
Eine devcontainer.json beschreibt den Container, den ein Editor, ein Cloud-Workspace oder ein CI-Runner für ein Repository bauen soll: Image oder Dockerfile, Features, weitergeleitete Ports, Lifecycle-Befehle und Editor-Anpassungen. Die offene Spezifikation unter containers.dev macht dieselbe Datei lokal, in gehosteten Workspaces und in Pipelines nutzbar, sodass die Toolchain mit dem Code fixiert wird, statt auf jedem Host für sich zu leben.
-
Kubernetes Resource Requests und Limits: Scheduling, Throttling und OOM-Kills
Ein Request ist das, was der Scheduler für einen Container reserviert und was das Kubelet garantiert; ein Limit ist das, was der Kernel durchsetzt. CPU-Limits drosseln, Memory-Limits töten, und das Verhältnis von Request zu Limit entscheidet über die QoS-Klasse des Pods und damit darüber, wer unter Node-Druck zuerst entfernt wird.
-
LXC/Incus-Systemcontainer: Was sie sind und wann sie statt eines Anwendungscontainers sinnvoll sind
Incus (ein Community-Fork von LXD) verwaltet Systemcontainer und virtuelle Maschinen mit einem einzigen Werkzeug. Ein Systemcontainer führt wie eine leichtgewichtige VM ein vollständiges Init-System und mehrere Dienste aus, ein Anwendungscontainer ist dagegen auf einen einzelnen Prozess ausgelegt – ein Unterschied, den man vor der Wahl für eine Host-Workload kennen sollte.
-
Fehlersuche in Containern vom Host aus mit lsns und nsenter
Reichen die Werkzeuge im Container nicht aus, um ein Netzwerkproblem zu analysieren, lassen sich mit nsenter vom Host aus die Namespaces des Containers betreten und vollwertige Host-Tools wie ss oder ip in dessen Umgebung ausführen. Die Methode beschreibt, wie PID und Namespace eines Containers ermittelt werden und worin sich das Betreten aller Namespaces vom Betreten eines einzelnen unterscheidet.
-
Docker-Engine-Hostadministration: daemon.json, Speicherplatzbelegung und live-restore
Die Administration der Docker Engine auf einem Host betrifft die Konfigurationsdatei des Daemons und nicht die Dockerfiles der Anwendungen: Standardwerte für die Log-Rotation, Speicherorte von Images und Containern, sicheres Freigeben von Speicherplatz und das Weiterlaufen von Containern über einen Daemon-Neustart hinweg.
Maschinenlesbar: JSON