Тема: containers
-
Какие правила хранения образов удерживают реестр контейнеров компактным, не удаляя при этом ещё развёрнутые образы?
Открытый вопрос: реестры собирают мусор только среди blob'ов, на которые не ссылается ни один манифест, а политики жизненного цикла помечают образы как устаревшие по возрасту, количеству или шаблону тега; какую комбинацию правил команды применяют годами без неограниченного роста реестра и без отката, сорвавшегося из-за того, что нужный образ уже удалён?
-
cgroups v2 на хосте: проверка режима и чтение ограничений ресурсов юнитов
Современные контейнерные среды и systemd используют cgroups v2 — единую иерархию — для ограничения памяти и процессора. Методика охватывает подтверждение единого режима на хосте, просмотр дерева через systemd-cgls/systemd-cgtop и чтение фактических ограничений юнита или контейнера.
-
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.
-
Изоляция действий агента: границы файловой системы, сети и учётных данных
Агент, выполняющий команды или код, должен работать внутри границ, ограничивающих доступные файлы, хосты и секреты. Основные элементы — контейнеры с урезанными capabilities и профилем seccomp, ядра в пользовательском пространстве вроде gVisor, сеть с запретом по умолчанию и короткоживущие учётные данные с ограниченной областью действия.
-
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.
-
Доступ к сокету Docker — это root на хосте: что на самом деле даёт его монтирование в контейнер
Тот, кто может обращаться к демону Docker, может запустить контейнер с корневой файловой системой хоста, смонтированной с полным доступом. Поэтому монтирование /var/run/docker.sock в контейнер, добавление пользователя в группу docker или открытие API по TCP равносильно предоставлению root.
-
Компоновка Control в Godot: определите владельца позиции и размера
Используйте якоря и отступы для размещения относительно родителя, поручайте контейнерам расположение детей и проверяйте ограничения содержимого при неожиданной геометрии интерфейса.
-
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.
-
Теги и дайджесты образов контейнеров: изменяемые имена и адреса содержимого
Тег — понятный человеку указатель, который в любой момент можно перенаправить на другой манифест; дайджест — хеш байтов манифеста, навсегда определяющий ровно один образ. Собирайте и тестируйте по тегу, развёртывайте и фиксируйте по дайджесту и записывайте дайджест в каждых примечаниях к выпуску.
-
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.
-
Контейнеры разработки: devcontainer.json как воспроизводимая рабочая среда
devcontainer.json описывает контейнер, который редактору, облачному рабочему пространству или исполнителю CI следует собрать для репозитория: образ или Dockerfile, features, перенаправляемые порты, команды жизненного цикла и настройки редактора. Открытая спецификация containers.dev позволяет использовать один файл локально, в размещённых рабочих пространствах и конвейерах, закрепляя инструментарий вместе с кодом, а не на каждом хосте.
-
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.
Машиночитаемо: JSON