Что физически происходит

Когда ты делаешь docker run, никакой «машины» не создаётся. Демон разворачивает слои образа в overlay-файловую систему, создаёт набор namespace-ов (mnt, pid, net, uts, ipc, cgroup, с Docker 29.5 ещё и time; user-namespace по умолчанию не создаётся), кладёт процесс в cgroup с лимитами, делает pivot_root в подготовленный корень - и запускает твой бинарь обычным execve. В ps aux на хосте этот процесс прекрасно виден. Ядро одно на всех, системные вызовы идут напрямую, без прослойки.

Виртуальная машина эмулирует железо: свой BIOS/UEFI, свой загрузчик, своё ядро, свои драйверы, своя память, размеченная гипервизором. Гость не знает, что он гость (или знает и берёт паравиртуальные драйверы virtio, чтобы не платить за эмуляцию сетевой карты).

Гипервизоры

• Тип 1 (bare metal) работает прямо на железе и сам служит ядром: VMware ESXi, Microsoft Hyper-V, Xen, KVM (формально модуль Linux-ядра, но по факту превращает ядро в гипервизор первого типа). На этом стоят все облака.
• Тип 2 (hosted) идёт приложением поверх обычной ОС: VirtualBox, VMware Workstation, Parallels, QEMU без KVM. Удобно на ноутбуке, медленнее.
• Обе разновидности опираются на аппаратную виртуализацию (Intel VT-x / AMD-V, EPT/NPT для таблиц страниц), поэтому граница между «типами» сегодня во многом терминологическая.

Почему на Mac и Windows Docker всё-таки виртуалка

Контейнеру нужны Linux-namespaces, а их нет ни в XNU, ни в NT. Docker Desktop поднимает лёгкую Linux-ВМ (на macOS через Apple Virtualization framework или Docker VMM, раньше HyperKit; на Windows через WSL 2 или Hyper-V) и запускает контейнеры уже внутри неё. Отсюда и тормоза bind-mount-ов на маке: файлы ходят через границу ВМ.

Механика

Образ складывается из слоёв, объединённых overlayfs: нижние read-only, сверху тонкий writable-слой контейнера. Запись в существующий файл вызывает copy-up: файл целиком копируется в верхний слой. Отсюда правило «не пиши много в контейнер, монтируй том»: перезапись гигабайтного файла в overlay сначала его скопирует.

Кэш сборки работает цепочкой. У каждого слоя есть ключ: инструкция плюс идентификатор родителя, для RUN ещё и значения объявленных выше ARG, а для COPY/ADD - контрольная сумма содержимого и прав копируемых файлов (время изменения не в счёт). Промах в одном слое инвалидирует все последующие. Поэтому COPY . . в начале Dockerfile убивает кэш полностью: любая правка README заставляет заново качать модули.

# Плохо: кэш ломается от любой правки
FROM golang:1.27
WORKDIR /src
COPY . .
RUN go mod download
RUN go build -o /out/app ./cmd/app

# Хорошо: зависимости отдельным слоем
FROM golang:1.27 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o /out/app ./cmd/app

Чем ускорить дальше

• BuildKit cache mounts кэшируют каталоги между сборками, в образ это не попадает: RUN --mount=type=cache,target=/go/pkg/mod --mount=type=cache,target=/root/.cache/go-build go build ./.... Второй маунт держит кэш компиляции Go и даёт основной выигрыш на инкрементальной сборке.
• .dockerignore. Без него в контекст уезжают .git, vendor, бинари и локальные артефакты: и контекст тяжёлый, и хеш COPY . . меняется от мусора.
• Пины версий. FROM golang:1.27 вместо latest, в идеале по digest - иначе воспроизводимости нет.
• Объединять RUN с apt-get update && apt-get install в одну команду, иначе закэшированный update отдаёт устаревшие индексы (сам этот приём документация Docker называет cache busting).
• В CI кэш слоёв не переживает раннер, нужен внешний бэкенд: --cache-from type=registry,ref=..., GitHub Actions cache, локальный type=local.

Канонический Dockerfile

FROM golang:1.27 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod go mod download
COPY . .
ARG VERSION=dev
RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    CGO_ENABLED=0 GOOS=linux go build \
      -trimpath \
      -ldflags="-s -w -X main.version=${VERSION}" \
      -o /out/server ./cmd/server

FROM gcr.io/distroless/static-debian13:nonroot
COPY --from=build /out/server /server
USER 65532:65532
ENTRYPOINT ["/server"]

• -trimpath убирает абсолютные пути сборки и делает сборку воспроизводимой.
• -ldflags="-s -w" выкидывает таблицу символов и DWARF: минус треть размера. Платишь тем, что delve к такому бинарю толком не прицепится; стек-трейсы не пострадают: имена функций, файлы и строки живут в отдельной таблице и не выкидываются.
• -X main.version зашивает версию внутрь бинаря; можно и наоборот, читать runtime/debug.ReadBuildInfo(), куда Go сам пишет VCS-ревизию, если каталог .git попал в контекст сборки.

scratch vs distroless vs alpine

Что ломается без cgo

Коротко: DNS остаётся только на чистом Go-резолвере (он и с cgo работает по умолчанию, но ради LDAP, mDNS и прочих NSS-модулей из nsswitch.conf уходил в glibc, а теперь уходить некуда), а библиотеки на C (тот же mattn/go-sqlite3) собираются в заглушку и падают при первом обращении. Остальное ломает не сам cgo, а пустая база вроде scratch: исчезают корневые сертификаты (любой HTTPS падает с x509: certificate signed by unknown authority), time.LoadLocation не находит зону без _ "time/tzdata", user.Current() без /etc/passwd держится только на переменных USER и HOME, а их в scratch нет.

ENTRYPOINT и CMD

Итоговая команда склеивается так: ENTRYPOINT + CMD. Аргументы docker run image --foo заменяют только CMD. Отсюда идиома: ENTRYPOINT ["/server"], CMD ["--config=/etc/app/config.yaml"]. Конфиг переопределяется одной строкой запуска, а бинарь остаётся тем же. Полностью подменить точку входа можно только флагом --entrypoint.

PID 1 - главный подвох

Shell-форма ENTRYPOINT /server разворачивается в /bin/sh -c "/server". PID 1 достаётся sh (так в Debian и Ubuntu, где sh - это dash; busybox в Alpine и bash сами делают exec, и там PID 1 - уже сервер); он не пересылает сигналы потомкам, а ядро для PID 1 не применяет действия по умолчанию - сигнал без обработчика просто пропадает. Итог: docker stop ждёт 10 секунд (в Docker Desktop - 3: он прописывает демону default-stop-timeout) и присылает SIGKILL, все in-flight запросы обрываются, а в k8s это выглядит как «при каждом деплое ловим 502». Exec-форма ["/server"] снимает вопрос. Если shell-обвязка нужна, добавляй exec перед командой и запускай с --init (tini), который ещё и зомби пожинает.

EXPOSE

Не открывает и не публикует ничего. Это метаданные: подсказка человеку и источник для docker run -P (публикация всех EXPOSE на случайные порты). Реально порт наружу отдаёт -p 8080:8080 (правило DNAT в iptables), а в кластере за это отвечает Service.

USER

По умолчанию процесс в контейнере работает от root, и это root того же ядра: без user-namespace uid 0 внутри равен uid 0 снаружи. Любой пробой рантайма или неудачный bind-mount - и ты хозяин ноды. Правильно: непривилегированный пользователь в образе (distroless :nonroot даёт uid 65532), а в k8s продублировать это в securityContext: runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, capabilities: drop: [ALL]. Порт ниже 1024 root не требует: Docker с 20.10 и containerd 2.0 под Kubernetes и так пускают на него непривилегированный процесс (sysctl ip_unprivileged_port_start=0), а где это не так, бери порт выше 1024 (правильный ответ) или capability NET_BIND_SERVICE.

HEALTHCHECK

Демон периодически выполняет команду внутри контейнера и метит его healthy/unhealthy. Полезно в docker compose (depends_on: condition: service_healthy), но сам докер контейнер не перезапустит, это умеет swarm. Kubernetes инструкцию HEALTHCHECK игнорирует целиком: там свои liveness/readiness/startup probes. И ещё: в distroless нет curl, так что healthcheck придётся делать самим бинарём (/server healthcheck подкомандой).

Хранилище

• Writable layer контейнера умирает вместе с контейнером и работает через copy-up в overlayfs. Для интенсивной записи не годится.
• Named volume (-v pgdata:/var/lib/postgresql/data; образ postgres 18+ ждёт том уровнем выше, в /var/lib/postgresql) докер держит у себя в /var/lib/docker/volumes. Переживает пересоздание, нормальная производительность, работает драйверами (можно NFS). Выбор для БД.
• Bind mount (-v $(pwd):/src) кладёт каталог хоста внутрь. Для hot-reload при разработке. В проде плохо: жёсткая привязка к хосту, конфликты uid/gid и SELinux, на macOS ещё и медленно (проброс через ВМ).
• tmpfs живёт в RAM, на диск ничего не пишется. Хорош в паре с read_only: true: контейнер с неизменяемым корнем, но рабочим /tmp.

Сети

• bridge по умолчанию (docker0): у контейнера свой net-namespace, veth-пара в мост, выход наружу через SNAT.
• user-defined bridge (её и создаёт compose) добавляет к этому встроенный DNS на 127.0.0.11: контейнеры находят друг друга по имени контейнера или алиасу, а compose добавляет алиасом имя сервиса. На дефолтном мосте этого нет - там были устаревшие --link.
• host выключает сетевую изоляцию совсем, порты контейнера = порты хоста. Быстро (нет NAT), но конфликтует и ломает переносимость.
• none оставляет loopback.
• -p 8080:8080 нужен, только чтобы попасть внутрь с хоста. Внутри одной сети контейнеры общаются напрямую, публикация не требуется - и не надо публиковать порт БД наружу «чтобы посмотреть», это дыра.

Compose: что ценят на собесе

Не знание синтаксиса, а понимание, что depends_on без condition: service_healthy гарантирует лишь порядок старта, но не готовность: Postgres поднимается несколько секунд, и приложение падает с «connection refused». Здоровая практика: healthcheck у зависимостей и ретраи подключения в самом приложении, потому что в Kubernetes никакого depends_on нет вообще и сервис обязан переживать недоступность соседей на старте.

CPU

limits.cpu: 1 задаёт не «одно медленное ядро», а квоту cpu.max = 100000 100000: 100 мс процессорного времени суммарно по всем потокам за каждые 100 мс реального. Если GOMAXPROCS равен 64, рантайм запускает 64 потока, они выжигают квоту за первые полторы миллисекунды - и вся cgroup замирает до конца периода. Средняя утилизация выглядит скромно, а p99 растёт на десятки миллисекунд из ниоткуда. Метрика-улика: container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total; если больше 1–2 %, уже больно.

До Go 1.25 лечили библиотекой go.uber.org/automaxprocs или пробросом GOMAXPROCS через resourceFieldRef: limits.cpu. Начиная с Go 1.25 (если та же версия или новее указана в go.mod) рантайм сам читает cpu.max своей cgroup, учитывает и дробные лимиты, и меняет GOMAXPROCS на лету при изменении лимита (отключается через GODEBUG=containermaxprocs=0,updatemaxprocs=0).

Память

GC по умолчанию управляется только GOGC=100: «собери, когда живая куча удвоится». Про memory.max он не знает. Живых 300 МиБ, лимит 512 МиБ, а GC спокойно даст куче дорасти до 600, cgroup-OOM убивает процесс, kubelet показывает OOMKilled и код выхода 137. GOMEMLIMIT вводит мягкий предел: при приближении GC работает чаще и активнее возвращает память ядру. Берут 80–90 % от limits.memory, потому что предел мягкий, а cgroup считает не только память рантайма (куча, стеки и метаданные в пределе уже учтены), но и сам бинарь, не-Go аллокации и память ядра под процесс.