Внутренности Docker
Тема дорожной карты · Docker & Containers
Внутри Docker — стек компонентов, связанных через gRPC: демон dockerd общается с containerd, тот через OCI-совместимый низкоуровневый рантайм runc запускает каждый контейнер. Контейнер — это обычный Linux-процесс, изолированный namespace-ами (pid, net, mnt, user, ipc, uts) и ограниченный cgroups; файловая система собрана из слоёв через OverlayFS. Понимание этого нужно, чтобы дебажить «почему dockerd жрёт CPU», писать профили seccomp / AppArmor, заменять рантайм на crun/youki. Новичку это не критично, продакшену — да.
Как это работает
Внутренности Docker — это namespaces (mount, network, PID, IPC, UTS, user, cgroup) + cgroups (cpu, memory, io, pids, devices) + container-aware ФС (overlay2, btrfs, zfs). Daemon Docker (dockerd) общается с low-level runtime (containerd → runc), который и делает clone() с правильными флагами. Образы хранятся как content-addressed tar-слои; docker save/load экспортит/импортит; daemon собирает rootfs стекуя слои через overlayfs.
Когда применять
Внутренности важны когда (а) дебажите "почему контейнер видит X", (б) выбираете storage driver (overlay2 — дефолт и почти всегда правильный), (в) оцениваете альтернативные runtime (Podman, containerd, CRI-O для Kubernetes), (г) строите что-то поверх Docker (CI-builder, sandboxing-тул). Прочтите docker info, runc spec, OCI image format spec хотя бы раз.
Типичные ошибки
Ловушки Внутренности Docker: выбор storage driver по старому блог-посту (overlay2 — ответ в 99% случаев); путаница Docker как компании с OCI-стандартом, который все теперь реализуют (docker pull работает с любым OCI registry); предположение, что Docker Desktop на macOS ведёт себя как Engine на Linux (нет — между ними VM с другими I/O perf и сетью). strace -f и lsns — для дебага runtime-мистики.