Архитектура докера

Дocker — это платформа для создания, развертывания и управления контейнеризированными приложениями, которая изменила подход к разработке и эксплуатации программного обеспечения. Его архитектура основана на принципах изоляции, портативности и автоматизации, позволяя разработчикам упаковывать приложение вместе со всеми зависимостями в единый, воспроизводимый контейнер. Главная цель Docker — устранить проблему «а у меня на машине работает», обеспечивая идентичность среды от локальной машины до продакшена. Для эффективного использования Docker необходимо понимать его внутреннюю структуру: как взаимодействуют компоненты, как управляется ресурсами и почему именно такая архитектура стала стандартом индустрии.

Общая архитектура Docker

Docker работает по клиент-серверной модели. Клиент — это команда `docker`, которую вы вводите в терминале, а сервер — это Docker Daemon (демон), который выполняет все тяжелые задачи: создание, запуск, остановка контейнеров, управление образами, сетями и томами. Демон работает как системный сервис (в Linux — `dockerd`), слушает UNIX-сокет или TCP-порт и обрабатывает запросы от клиента. Это разделение позволяет управлять Docker удалённо — например, запускать контейнеры на удалённом сервере через SSH-туннель или API.

Представьте, что вы отправляете заказ в ресторан: вы (клиент) говорите, что хотите бургер, а повар (демон) готовит его, используя заранее подготовленные ингредиенты (образы), чистую кухню (изоляцию) и стандартные рецепты (Dockerfile). Вы не видите, как готовят, но получаете результат — и он всегда одинаковый.

Демон взаимодействует с ядром Linux через системные вызовы, используя неймспейсы для изоляции процессов, cgroups для ограничения ресурсов, а также Union File Systems для создания слоёв образов. В Windows и macOS Docker использует легковесную виртуальную машину (например, Linux VM в Hyper-V или VirtualBox), чтобы эмулировать Linux-окружение, поскольку контейнеры не могут работать напрямую на этих ОС без ядра Linux.

Компоненты Docker Engine

Docker Engine состоит из трёх основных компонентов: Docker Daemon, Docker CLI и Docker REST API. Все они работают в тесной интеграции, но каждый отвечает за свою зону.

Docker CLI — это интерфейс командной строки, который отправляет команды (например, `docker run`, `docker build`) через API к демону. Он не выполняет никаких операций сам — лишь передаёт инструкции. Это позволяет легко интегрировать Docker в CI/CD-пайплайны, скрипты и IDE.

Docker Daemon — сердце системы. Он управляет контейнерами, образами, сетями и томами. При старте системы демон автоматически запускается и слушает сокет `/var/run/docker.sock`. Все операции, включая создание контейнера, скачивание образа или монтирование тома, выполняются именно демоном. Он также отвечает за мониторинг ресурсов и логи.

Docker REST API — это HTTP-интерфейс, который позволяет управлять Docker программно. Он используется не только CLI, но и сторонними инструментами: Kubernetes, Docker Compose, Portainer, Terraform. API документирован и полностью открыт — вы можете отправить запрос через `curl` и получить ответ в JSON.

Контейнерный рантайм и OCI

С 2017 года Docker перешёл от собственного рантайма `docker-runc` к стандарту Open Container Initiative (OCI). Это означает, что Docker больше не привязан к одному движку — он использует совместимые рантаймы, такие как `containerd` и `runc`.

`containerd` — это демон, который управляет жизненным циклом контейнеров: загрузка образов, запуск, остановка, удаление. Он работает как промежуточный слой между Docker Daemon и `runc`. `runc` — это легковесный CLI-инструмент, который реализует спецификацию OCI и напрямую взаимодействует с ядром Linux, создавая контейнеры через неймспейсы и cgroups.

Такая архитектура позволила Docker стать частью более широкой экосистемы. Например, Kubernetes теперь использует `containerd` напрямую, минуя Docker Daemon. Это делает систему гибче: вы можете использовать один и тот же рантайм для Docker, Podman, cri-o и других инструментов.

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

Образ Docker — это не монолитный файл, а набор слоёв (layers), каждый из которых представляет собой изменение по сравнению с предыдущим. Каждая инструкция в Dockerfile создаёт новый слой: `FROM`, `RUN`, `COPY`, `ADD`. Слои кэшируются, что делает сборку образов невероятно быстрой: если вы изменили только последнюю строку Dockerfile, Docker пересобирает только её и использует кэшированные слои до неё.

Это ключевое преимущество: если вы добавили новую библиотеку в конец Dockerfile, а не в начало, то Docker не будет пересобирать все предыдущие слои — от `apt-get update` до установки Python. Это экономит десятки минут на CI-пайплайнах.

Однако есть ловушки. Например, если вы делаете `COPY . .` перед `RUN pip install`, то при любом изменении файла в директории — Docker пересобирает все слои после этого шага. Правильный подход — сначала копировать `requirements.txt`, затем устанавливать зависимости, а потом копировать весь код.

Слои объединяются через Union File System (например, overlay2 — стандартный драйвер в Linux). Это позволяет читать несколько слоёв как один файловую систему, но при этом только верхний слой (внутри контейнера) доступен для записи. Все изменения в работающем контейнере записываются в этот верхний слой, а базовые слои остаются неизменными — это обеспечивает воспроизводимость и безопасность.

Сетевая модель Docker

Docker предоставляет несколько сетевых драйверов, каждый из которых решает разные задачи. По умолчанию используется `bridge` — изолированная сеть, в которой контейнеры могут общаться друг с другом, но не с хостом напрямую. Каждый контейнер получает свой IP-адрес в подсети (например, `172.17.0.0/16`), и Docker настраивает NAT для выхода в интернет.

Для микросервисов чаще всего используют `user-defined bridge networks` — они позволяют контейнерам находить друг друга по имени, а не по IP. Например, если у вас есть контейнеры `web` и `db`, вы можете подключить их к одной сети и обращаться к базе как `http://db:5432` — Docker автоматически разрешает имя через встроенный DNS.

Для публичного доступа используется `host`-сеть (контейнер использует сеть хоста) или `port mapping` (`-p 8080:80`). Первый вариант быстрее, но менее безопасен — второй — стандартный для большинства приложений.

Если вы разворачиваете приложение в продакшене, используйте `docker network create myapp-net` и подключайте все сервисы к одной пользовательской сети. Это изолирует ваше приложение от других контейнеров и делает его конфигурацию предсказуемой.

Драйверы хранения и volumes

Docker использует драйверы хранения для управления слоями образов и данными контейнеров. Самый популярный — `overlay2`: он работает поверх ext4/xfs, поддерживает копирование при записи (Copy-on-Write), и обеспечивает высокую производительность. Другие драйверы — `aufs`, `btrfs`, `zfs` — устарели или используются редко.

Для хранения данных, которые должны сохраняться после остановки контейнера, используются volumes и bind mounts. Volumes — это директории, управляемые Docker, они хранятся в `/var/lib/docker/volumes/` и лучше подходят для баз данных, логов, конфигов. Bind mounts — это привязка к произвольной директории на хосте, например, `~/project:/app`. Они удобны для разработки, но менее безопасны и портативны.

Безопасность и изоляция

Docker обеспечивает изоляцию на уровне ядра Linux: неймспейсы (PID, NET, MNT, UTS, IPC, USER) изолируют процессы, файловые системы и сетевые интерфейсы. Cgroups ограничивают использование CPU, памяти, диска и I/O. Это не виртуализация, а изоляция процессов — потому контейнеры легковесны и быстры.

Однако это не значит, что контейнеры абсолютно безопасны. Уязвимости в ядре Linux (например, Dirty COW) могут позволить «выход из контейнера». Поэтому применяйте следующие меры:

— Не запускайте контейнеры от root — используйте `USER` в Dockerfile.
— Ограничьте привилегии: `—cap-drop=ALL —cap-add=NET_BIND_SERVICE`.
— Используйте `—read-only` для корневой файловой системы.
— Применяйте seccomp-профили и AppArmor/SELinux.
— Сканируйте образы на уязвимости через `docker scan`.

Лучшие практики архитектурного проектирования

Проектируя архитектуру на Docker, избегайте распространённых ошибок:

1. Не используйте `latest` в продакшене — фиксируйте версии образов: `nginx:1.25-alpine`.
2. Используйте многоэтапные сборки — в одном Dockerfile собирайте приложение и копируйте только бинарник в финальный образ. Это уменьшает размер в 10–20 раз.
3. Не храните секреты в образах — используйте Docker Secrets или Kubernetes Secrets.
4. Монтируйте конфиги через volumes, а не копируйте их в образ — это упрощает обновление.
5. Ограничивайте ресурсы — `—memory=512m —cpus=0.5` предотвратят «шумных соседей».
6. Используйте .dockerignore — исключайте `node_modules`, `.git`, логи, чтобы ускорить сборку.

Представьте, что вы строите дом. Docker — это конвейер, где вы собираете стены из готовых блоков (образов), а не лепите их из глины. Каждый блок должен быть стандартизирован, проверен и не содержать скрытых дефектов. Только тогда дом будет прочным.

Заключение

Архитектура Docker — это не просто инструмент для упаковки приложений, а фундамент современной облачной инфраструктуры. Её сила — в сочетании лёгкости контейнеров, стандартизации через OCI, гибкости сетей и безопасности на уровне ядра. Понимание слоёв образов, работы демона, драйверов хранения и сетевых моделей позволяет не просто запускать контейнеры, а проектировать отказоустойчивые, масштабируемые и безопасные системы.

Без знания архитектуры Docker вы рискуете столкнуться с нестабильными сборками, утечками данных, неоптимальным использованием ресурсов и уязвимостями, которые легко предотвратить. Docker — это не «чёрный ящик». Это инструмент, требующий осознанного подхода.

• Используйте многоэтапные сборки для минимизации размера образов.
• Всегда запускайте контейнеры от непривилегированного пользователя.
• Применяйте user-defined сети для изоляции микросервисов.
• Храните данные только в volumes, никогда не доверяйте файловой системе контейнера.
• Сканируйте образы на уязвимости и фиксируйте версии всех зависимостей.