Docker

01Образы, контейнеры и чем они отличаются от VM

Образ — это шаблон только для чтения: снимок файловой системы плюс метаданные, например какую команду запускать. Контейнер — запущенный экземпляр образа с тонким записываемым слоем сверху. Представьте образ как карточку с рецептом, а контейнер — как блюдо, приготовленное по ней; по одной карточке можно приготовить много блюд. Виртуальная машина эмулирует целый компьютер со своим ядром, поэтому она загружает полноценную операционную систему и обычно занимает гигабайты и десятки секунд на старт. Контейнер же — обычный Linux-процесс, который ядро изолирует с помощью namespaces (что он видит: файлы, сеть, список процессов) и ограничивает через cgroups (сколько CPU и памяти он может использовать). Он делит ядро с хостом, поэтому стартует за миллисекунды и почти не добавляет накладных расходов. Обратная сторона: изоляция слабее, чем у VM, поэтому облака часто запускают контейнеры внутри виртуальных машин.

• Образ = неизменяемый шаблон, определяется именем name:tag и digest'ом содержимого.
• Контейнер = образ + записываемый слой + изолированный процесс.
• Контейнеры делят ядро хоста; у VM ядро своё.

02Слои и кэширование сборки

Каждая инструкция в Dockerfile (FROM, COPY, RUN) создаёт слой, а образ — это стопка слоёв, объединённых overlay-файловой системой. Слои кэшируются по содержимому: если инструкция и всё, что до неё, не изменились, Docker переиспользует слой из кэша, а не выполняет его заново. Как только меняется один слой, все последующие пересобираются. Это правило и определяет скорость ваших сборок. Сначала скопируйте манифест зависимостей (package.json и lockfile или composer.json и composer.lock), установите зависимости и только потом копируйте остальной код. Теперь правка компонента не запускает полный npm install. Файл .dockerignore не пускает в контекст сборки node_modules, .git, логи и .env-файлы — сборки становятся быстрее, а секреты не утекают в образы.

1# .dockerignore
2node_modules
3.next
4.git
5*.log
6.env*
7Dockerfile
8compose*.yaml

03Продакшен-Dockerfile: multi-stage, компактный, не от root

Multi-stage сборка использует один этап с компиляторами и dev-зависимостями, чтобы собрать приложение, а затем копирует только результат в чистый и маленький runtime-этап. В финальном образе нет случайных source map'ов, нет инструментов сборки и гораздо меньше пакетов, которые нужно патчить. Используйте slim- или Alpine-образы и фиксируйте мажорную версию вместо latest. Запускайте от непривилегированного пользователя: если кто-то взломает приложение, он окажется обычным пользователем, а не root. Пример ниже собирает Next.js-приложение с output: "standalone" в next.config — это даёт минимальный server.js и только те node_modules, которые реально нужны. Тот же подход работает и для Laravel: этап Composer, этап Node для ассетов и финальный этап PHP-FPM.

1FROM node:24-alpine AS deps
2WORKDIR /app
3COPY package.json package-lock.json ./
4RUN npm ci
5 
6FROM node:24-alpine AS build
7WORKDIR /app
8COPY --from=deps /app/node_modules ./node_modules
9COPY . .
10RUN npm run build
11 
12FROM node:24-alpine AS run
13WORKDIR /app
14ENV NODE_ENV=production
15COPY --from=build --chown=node:node /app/.next/standalone ./
16COPY --from=build --chown=node:node /app/.next/static ./.next/static
17COPY --from=build --chown=node:node /app/public ./public
18USER node
19CMD ["node", "server.js"]

04Volumes и сети

Записываемый слой контейнера исчезает вместе с контейнером, поэтому всё, что нужно сохранить (файлы базы данных, загрузки), должно жить в volume. Именованные volume'ы управляются Docker'ом — это правильный выбор для баз данных. Bind mount пробрасывает папку хоста внутрь контейнера и идеален для разработки, когда изменения в коде должны появляться мгновенно. Что касается сети: контейнеры в одной пользовательской сети находят друг друга по имени сервиса через встроенный DNS Docker'а — приложение подключается к db:5432, а не к localhost. Внутри контейнера localhost означает сам этот контейнер — это самая частая путаница у новичков. Публикуйте только те порты, которые действительно нужны внешнему миру, обычно только 80 и 443 на reverse proxy.

• Именованный volume: постоянные данные под управлением Docker (базы данных).
• Bind mount: папка хоста, отлично подходит для живого кода в разработке.
• Опубликованные порты во многих конфигурациях обходят правила ufw; привязывайте приватные порты к 127.0.0.1 или не публикуйте их вовсе.

05Docker Compose для целого приложения

Compose описывает несколько контейнеров, их сети и volume'ы в одном compose.yaml, а docker compose up -d запускает всё сразу. Ниже — типичное веб-приложение: nginx впереди как единственная публичная точка входа, контейнер приложения, воркер очереди из того же образа, но с другой командой, PostgreSQL с постоянным volume и health check'ом и Redis для кэша и очередей. depends_on с condition: service_healthy заставляет приложение ждать, пока база действительно начнёт принимать соединения, а не просто пока её контейнер стартует. Обратите внимание: база и Redis вообще не публикуют порты, снаружи доступен только nginx. Секреты берутся из env-файла, который не коммитится в Git.

1services:
2  nginx:
3    image: nginx:stable-alpine
4    ports: ["80:80", "443:443"]
5    depends_on: [app]
6  app:
7    build: .
8    env_file: .env
9    depends_on:
10      db: { condition: service_healthy }
11  worker:
12    build: .
13    command: php artisan queue:work --tries=3
14  db:
15    image: postgres:17
16    volumes: [db-data:/var/lib/postgresql/data]
17    healthcheck: { test: ["CMD", "pg_isready", "-U", "postgres"], interval: 5s }
18  redis:
19    image: redis:7-alpine
20volumes: { db-data: {} }

06Compose для разработки и для продакшена

Разработке и продакшену нужно разное. В разработке хочется код через bind mount, hot reload, инструменты отладки и, возможно, перехватчик почты. В продакшене — собранные образы с «запечённым» кодом, restart: unless-stopped, лимиты ресурсов, ротацию логов, TLS и мониторинг. Не поддерживайте два расходящихся файла. Держите базовый compose.yaml с общей частью и накладывайте сверху override-файлы: compose.override.yaml подхватывается автоматически в разработке, а продакшен запускается явно — базовый файл плюс продакшен-файл. Можно добавить и другие слои, например файл для TLS или для observability, который добавляет Prometheus, Grafana и Loki. Перед деплоем проверяйте итоговую склейку через docker compose config.

1# development: compose.yaml + compose.override.yaml (auto-loaded)
2docker compose up -d
3 
4# production: explicit files, no override
5docker compose -f compose.yaml -f compose.prod.yaml config --quiet
6docker compose -f compose.yaml -f compose.prod.yaml up -d --build
7 
8# useful day to day
9docker compose ps
10docker compose logs -f --tail=100 app
11docker compose exec app sh

07Что такое контейнер на самом деле: цепочка runtime и PID 1

Когда вы пишете docker run, CLI обращается к Docker daemon (dockerd), тот передаёт задачу containerd, а containerd через низкоуровневый OCI runtime, обычно runc, создаёт процесс. runc запрашивает у ядра новые namespace, привязывает процесс к cgroup, монтирует слои образа через overlayfs и уходит с дороги. Форматы образов и runtime — открытые стандарты OCI, поэтому Podman, Kubernetes и Docker могут запускать один и тот же образ. Одна деталь регулярно кусает в продакшене: первый процесс в контейнере — это PID 1. Ядро не даёт PID 1 обработчиков сигналов по умолчанию, поэтому процесс, который сам не установил обработчик SIGTERM, просто его игнорирует, а ещё от PID 1 ожидается, что он будет «прибирать» zombie-процессы. Крошечный init вроде tini, который в Compose включается через init: true, пробрасывает сигналы и собирает зомби за вас.

1services:
2  app:
3    image: registry.example.com/app:1.8.0
4    init: true               # tini as PID 1: forwards signals, reaps zombies
5    stop_grace_period: 30s   # time between SIGTERM and SIGKILL (default 10s)
6    stop_signal: SIGTERM

08Харденинг контейнера в рантайме

Пользователь без root — это первый шаг, а не последний. По умолчанию контейнер всё равно получает набор Linux capabilities, доступную для записи корневую файловую систему и возможность повысить привилегии через setuid-бинарники. Уберите все capabilities и верните только нужные (веб-серверу, который слушает порт 80, нужен NET_BIND_SERVICE; большинству Node- и PHP-приложений за прокси не нужно ничего). Сделайте корневую файловую систему read-only и дайте приложению небольшой tmpfs для временных файлов, чтобы атакующий не мог закинуть свои инструменты на диск. Включите no-new-privileges, чтобы трюки с setuid не срабатывали. Стандартный seccomp-профиль Docker уже блокирует десятки опасных системных вызовов — никогда не отключайте его через seccomp=unconfined. И главное: никогда не монтируйте /var/run/docker.sock в контейнер приложения — доступ к сокету равносилен root на хосте. Для дополнительного слоя защиты rootless-режим запускает сам daemon от обычного пользователя.

1services:
2  app:
3    user: "1000:1000"
4    read_only: true
5    tmpfs: [/tmp]
6    cap_drop: [ALL]
7    security_opt: ["no-new-privileges:true"]
8    deploy:
9      resources:
10        limits: { cpus: "1.0", memory: 512M }
11    pids_limit: 200

09Docker, iptables и сюрприз с файрволом

Когда вы публикуете порт через ports: "5432:5432", Docker прописывает в iptables NAT-правила, чтобы трафик на порт хоста перенаправлялся в контейнер. Эти правила обрабатываются в цепочках PREROUTING и FORWARD — раньше, чем цепочка INPUT, где ufw хранит свои правила. В итоге ufw status говорит, что порт 5432 закрыт, а база при этом отвечает из интернета. Есть три безопасных решения. Вообще не публикуйте внутренние сервисы: контейнерам в одной сети это не нужно. Если какой-то утилите на хосте нужно достучаться до контейнера, привяжите порт к loopback: 127.0.0.1:5432:5432. Если действительно нужно фильтровать опубликованные порты, пишите правила в цепочку DOCKER-USER — Docker проверяет её до своих правил и никогда не перезаписывает. После любого изменения проверяйте снаружи сканированием портов, а не доверяйте отчёту самого файрвола.

1services:
2  db:
3    image: postgres:17
4    # reachable only from the host itself, never from the internet
5    ports: ["127.0.0.1:5432:5432"]
6  redis:
7    image: redis:7-alpine
8    # no ports at all: only containers on the same network can connect
9 
10# from another machine: nmap -Pn -p 5432,6379 203.0.113.10

10Более быстрые и безопасные сборки с BuildKit

BuildKit, сборщик по умолчанию в актуальных версиях Docker, умеет то, чего не даёт обычное кэширование слоёв. Cache mount сохраняет кэш загрузок пакетного менеджера между сборками, не помещая его ни в один слой, поэтому после изменения lockfile пакеты ставятся из тёплого кэша, а не из сети. Secret mount открывает токен (для приватного npm registry или Composer auth) только одному шагу RUN; он никогда не попадает в историю образа, в отличие от значений ARG или ENV, которые любой может прочитать через docker history. В CI раннеры стартуют пустыми, поэтому экспортируйте кэш в registry и импортируйте его при следующем запуске. Для воспроизводимости закрепляйте базовые образы не только по тегу, но и по digest, и пусть автоматика вроде Renovate или Dependabot открывает pull request, когда digest меняется. BuildKit также умеет прикладывать SBOM и provenance attestation, которые сканеры безопасности и аудиторы ожидают всё чаще.

1# syntax=docker/dockerfile:1
2FROM node:24-alpine AS deps
3WORKDIR /app
4COPY package.json package-lock.json ./
5RUN --mount=type=cache,target=/root/.npm \
6    --mount=type=secret,id=npmrc,target=/root/.npmrc \
7    npm ci
8 
9# build: docker build --secret id=npmrc,src=$HOME/.npmrc .
10# CI:    docker buildx build --cache-from type=registry,ref=registry.example.com/app:cache \
11#          --cache-to type=registry,ref=registry.example.com/app:cache,mode=max --push .