Topic: containers
-
Which image-retention rules keep a container registry small without deleting images that are still deployed?
Open question: registries garbage-collect only blobs no manifest references, and lifecycle policies expire images by age, count or tag pattern; which combination of rules have teams run for years without either unbounded growth or a rollback that failed because its image was gone?
-
cgroups v2 on the host: checking the mode and reading per-unit resource limits
Modern container runtimes and systemd both rely on cgroups v2 (the unified hierarchy) to enforce memory and CPU limits. This methodology covers confirming the host is in unified mode, browsing the tree with systemd-cgls/systemd-cgtop, and reading a unit's or container's actual limits.
-
docker/podman run exit codes: 125, 126, 127, and the signal codes that reach through them
docker run reserves 125, 126 and 127 for failures of Docker itself, an uninvokable command, and a not-found command respectively; any other code is passed through unchanged from the containerized process, including the 128+signal codes (137 for SIGKILL, often OOM; 139 for SIGSEGV; 143 for SIGTERM). The container's own OOMKilled flag, not the bare 137, is the documented way to confirm an out-of-memory kill, though on some cgroup-v2 hosts it reads false even after a kernel OOM kill.
-
Sandboxing agent actions: file system, network and credential boundaries
An agent that runs commands or code should do so inside a boundary that limits which files it can touch, which hosts it can reach and which secrets it can read; containers with dropped capabilities and a seccomp profile, user-space kernels such as gVisor, a deny-by-default network and short-lived scoped credentials are the building blocks.
-
Sizing a JVM inside a container: heap percentage, non-heap memory and CPU count
The JVM reads cgroup limits by default (UseContainerSupport) and sizes the heap as a percentage of the container's memory, not the host's; heap is only part of the footprint, so set MaxRAMPercentage to leave room for metaspace, thread stacks, direct buffers and code cache, check the CPU count the JVM sees, and verify with -Xlog:os+container and native memory tracking before trusting a limit.
-
Access to the Docker socket is root on the host: what mounting it into a container really grants
Whoever can talk to the Docker daemon can start a container that mounts the host's root file system with full access. Mounting /var/run/docker.sock into a container, adding a user to the docker group or exposing the API over TCP is therefore equivalent to granting root.
-
Godot Control Layout: Decide Who Owns Position and Size
Use anchors and offsets for parent-relative placement, let containers arrange their children, and inspect content-driven size constraints when an interface refuses the expected geometry.
-
Running Podman containers as systemd services with Quadlet
Quadlet lets systemd manage Podman containers directly from declarative .container unit files, replacing the deprecated podman generate systemd workflow. This methodology covers file locations for system and user services, activation, and the auto-update label.
-
Alpine Linux for agents: apk add/del/upgrade, --no-cache in containers, and pinning a package version
apk tracks explicitly requested packages in /etc/apk/world and repository sources in /etc/apk/repositories; apk add/apk del edit both files together with installing or removing files, apk upgrade re-syncs the index and updates everything in world, and a package can be pinned to an exact version or to a tagged repository. --no-cache skips the local package cache entirely, which is the form used in container image builds.
-
musl versus glibc on Alpine: why some prebuilt binaries, Python wheels and DNS behaviour differ
Alpine's musl libc is not binary-compatible with glibc, has a different (parallel, non-search-falling-back) DNS resolver, defaults to the C.UTF-8 locale rather than a full locale database, and does not support lazy symbol binding — differences that explain glibc-linked binaries failing to run, manylinux Python wheels being rejected, and some legacy DNS configurations behaving differently. gcompat can run some unmodified glibc binaries but cannot be used to build software that itself requires glibc headers.
-
Git's "detected dubious ownership in repository" error and the safe.directory fix
Git refuses to operate in a repository owned by a different user than the one running the command, quoting 'fatal: detected dubious ownership in repository at'. The article explains the CVE-2022-24765 fix behind it, when a per-repo safe.directory entry is right, and why chown is the better fix in containers and CI.
-
Docker Compose for local development: override files, profiles, healthy dependencies and watch
Keep one committed compose.yaml that mirrors production shape, add a compose.override.yaml for local ports and bind mounts, gate optional tooling behind profiles, make depends_on wait for service_healthy, and use develop.watch to sync or rebuild on file changes.
-
Container image tags versus digests: mutable names and content addresses
A tag is a human-readable pointer that can be moved to a different manifest at any time; a digest is the hash of the manifest bytes and identifies exactly one image forever. Build and test by tag, deploy and pin by digest, and record the digest in every release note.
-
Which memory metric should alerts and autoscalers use for a containerised service: RSS, PSS, working set or cgroup memory.current?
Open question: process RSS counts shared pages per process, cgroup memory.current includes page cache and kernel memory, and Kubernetes reports a heuristic working set; which of these has been used as the alerting and scaling signal for a long-running service without either paging on reclaimable cache or missing an approach to the OOM limit?
-
Podman rootless versus rootful on RHEL-family hosts: storage, subuid, and lingering
Podman runs containers as an ordinary user (rootless) or as root (rootful), with different storage locations and privilege boundaries. This methodology covers inspecting running containers, finding storage paths, setting up subordinate UID/GID ranges, and keeping rootless services alive without a login session.
-
Dev containers: devcontainer.json as a reproducible development environment
A devcontainer.json describes the container an editor, cloud workspace or CI runner should build for a repository: image or Dockerfile, features, forwarded ports, lifecycle commands and editor customisations. The open specification at containers.dev makes the same file usable locally, in hosted workspaces and in pipelines, so the toolchain is pinned with the code instead of living on each host.
-
Kubernetes resource requests and limits: scheduling, throttling and OOM kills
A request is what the scheduler reserves for a container and what the kubelet guarantees; a limit is what the kernel enforces. CPU limits throttle, memory limits kill, and the request-to-limit relationship decides the Pod's QoS class and therefore who is evicted first under node pressure.
-
LXC/Incus system containers: what they are and when to reach for one instead of an application container
Incus (a community fork of LXD) manages system containers and virtual machines with one tool. A system container runs a full init system and multiple services like a lightweight VM, unlike an application container built around one process — a distinction worth knowing before picking either for a host workload.
-
Troubleshooting containers from the host with lsns and nsenter
When a container's own tools are too minimal to debug a networking problem, entering its namespaces from the host with nsenter lets you run full host utilities such as ss or ip against the container's environment. This methodology covers finding the container's PID and namespace, and the difference between entering all namespaces and just one.
-
Docker Engine host administration: daemon.json, disk usage, and live-restore
Administering the Docker Engine on a host means the daemon's configuration file, not application Dockerfiles: log rotation defaults, where images and containers are stored, safely reclaiming disk space, and keeping containers running across a daemon restart.
Machine-readable: JSON