1. Глубокое погружение в архитектуру Docker и жизненный цикл контейнера
Глубокое погружение в архитектуру Docker и жизненный цикл контейнера
Когда вы выполняете команду docker run, за доли секунды происходит каскад событий: проверка локального кэша, запрос к удаленному реестру, аллокация изолированных ресурсов файловой системы, настройка виртуальных сетевых интерфейсов и, наконец, запуск процесса. Для новичка это выглядит как магия «легковесной виртуализации». Однако для инженера, готовящего систему к промышленной эксплуатации, Docker — это не «черный ящик», а слоистая абстракция над возможностями ядра Linux. Понимание того, как именно Docker взаимодействует с операционной системой, определяет вашу способность отлаживать сложные сбои, когда контейнер «внезапно» перестает отвечать или потребляет аномальное количество ресурсов.
Демон, клиент и API: анатомия управления
Архитектура Docker построена на классической клиент-серверной модели, но с важным нюансом: компоненты могут быть разнесены в пространстве и времени. Основным узлом управления является Docker Daemon (dockerd). Это долгоживущий процесс, который берет на себя всю тяжелую работу по управлению объектами: образами, контейнерами, сетями и томами.
Daemon не работает в вакууме. Он слушает запросы через Docker Engine API. Когда вы вводите команды в терминале, вы используете Docker CLI — стандартный клиент. Важно понимать, что CLI — это лишь тонкая обертка над HTTP-запросами. Вы можете управлять демоном, находящимся на другом сервере, просто перенаправив переменную окружения DOCKER_HOST.
Связь между клиентом и сервером обычно осуществляется через три типа сокетов:
/var/run/docker.sock): стандарт для локального взаимодействия. Именно доступ к этому файлу определяет, может ли пользователь управлять контейнерами без sudo.Путь команды: от ввода до исполнения
Представьте, что вы запускаете docker run -d nginx. CLI упаковывает этот запрос в JSON и отправляет POST-запрос на эндпоинт /containers/create. Демон принимает запрос, проверяет синтаксис и обращается к локальному хранилищу. Если образа nginx нет, демон инициирует общение с Docker Registry (по умолчанию Docker Hub).
Здесь кроется первое различие между образом и контейнером на архитектурном уровне. Образ — это статическая коллекция слоев «только для чтения» (read-only layers). Контейнер — это исполняемый экземпляр образа, к которому сверху добавлен тонкий записываемый слой (writable layer).
Фундамент изоляции: Namespaces и Cgroups
Docker часто называют «улучшенным chroot», но это упрощение опасно. На самом деле контейнер — это обычный процесс в основной операционной системе, который просто «видит» мир иначе благодаря двум механизмам ядра Linux.
Namespaces (Пространства имен)
Это инструмент, который обеспечивает изоляцию. Ядро предоставляет процессу персональную копию системных ресурсов. Если процесс находится в отдельном namespace, он не знает о существовании соседей.| Тип Namespace | Что изолирует | Эффект для контейнера |
| :--- | :--- | :--- |
| pid | Процессы | Контейнер видит свой основной процесс как PID 1, не видя процессов хоста. |
| net | Сеть | У контейнера свои виртуальные интерфейсы, IP-адреса и таблицы маршрутизации. |
| mnt | Точки монтирования | Контейнер имеет свою файловую систему, не имея доступа к /etc или /home хоста. |
| uts | Имя узла | Позволяет контейнеру иметь собственное имя хоста (hostname) и домен. |
| ipc | Межпроцессное взаимодействие | Изолирует очереди сообщений и разделяемую память. |
| user | Пользователи | Позволяет пользователю внутри контейнера иметь UID 0 (root), который на хосте будет соответствовать непривилегированному пользователю. |
Именно благодаря pid namespace вы можете запустить десять контейнеров Nginx, и каждый из них будет считать, что он — единственный важный процесс в системе с идентификатором 1. Однако, если вы выполните top на хостовой машине, вы увидите все эти процессы с их реальными, уникальными PID в рамках всей ОС.
Control Groups (Cgroups)
Если namespaces отвечают за то, что процесс видит, то cgroups отвечают за то, сколько ресурсов процесс может потребить. Это механизм ограничения. Без cgroups один «прожорливый» контейнер с утечкой памяти мог бы вызвать Kernel Panic или спровоцировать работу OOM Killer (Out of Memory Killer), который завершит критически важные системные процессы.Docker позволяет лимитировать:
Роль containerd и runc: почему Docker больше не монолит
До версии 1.11 Docker был монолитным демоном. Сегодня это модульная система, соответствующая стандартам OCI (Open Container Initiative). Это критически важно для понимания стабильности: если Docker Daemon упадет или будет перезапущен, сами контейнеры могут продолжать работать.
containerd мог перезапуститься, не убивая процессы в контейнерах, и чтобы корректно собирать логи (stdout/stderr) и коды выхода.runc завершает свою работу.Эта цепочка гарантирует, что Docker — это лишь надстройка над стандартными инструментами запуска контейнеров в Linux.
Жизненный цикл контейнера: от рождения до удаления
Понимание состояний контейнера — ключ к автоматизации деплоя. Контейнер — это не виртуальная машина, которая «грузится». Это процесс, который переходит из одного состояния в другое под управлением сигналов.
Создание и запуск (Created & Running)
Когда вы вызываетеcreate, Docker подготавливает файловую систему и ресурсы, но не запускает процесс. Состояние Running означает, что процесс внутри контейнера активен.
Важнейшее правило: Контейнер живет ровно столько, сколько живет его основной процесс (PID 1). Если вы запускаете скрипт, который отрабатывает за 2 секунды и завершается, контейнер немедленно перейдет в статус Exited.Остановка и сигналы (Stopping & Terminated)
Командаdocker stop действует деликатно. Она отправляет процессу PID 1 сигнал SIGTERM. У приложения есть время (по умолчанию 10 секунд), чтобы корректно закрыть соединения с базой данных, сохранить файлы и завершить работу. Если приложение игнорирует SIGTERM, Docker отправляет SIGKILL — немедленное принудительное завершение.> Инженерная тонкость: Если ваше приложение в контейнере запущено через shell-скрипт (например, CMD ./start.sh), то именно скрипт получит SIGTERM. Если скрипт не умеет пробрасывать сигналы своему дочернему процессу (вашему приложению), приложение будет убито жестко по таймауту. Это частая причина повреждения данных в БД при перезагрузке контейнеров.
Пауза и перезапуск (Paused & Restarting)
СостояниеPaused использует cgroups для «заморозки» процесса. Процесс не потребляет циклы CPU, но вся его память остается занятой. Это полезно для коротких пауз во время бэкапа, но редко применяется в продакшене.
Политики перезапуска (--restart) позволяют Docker автоматически возвращать контейнер в строй, если процесс упал с ненулевым кодом возврата или если сам демон Docker был перезагружен.Файловая система: слои и Copy-on-Write
Docker использует Union File System (UnionFS). Это технология, позволяющая объединять содержимое нескольких каталогов в одну общую иерархию.
Как работают слои
Каждая инструкция в Dockerfile (например,RUN apt-get update) создает новый слой. Эти слои неизменяемы. Когда вы запускаете контейнер, Docker добавляет сверху один пустой слой — Container Layer.Все изменения, которые делает приложение во время работы (логи, временные файлы), записываются только в этот верхний слой. Если приложению нужно изменить файл из нижнего (read-only) слоя, используется механизм Copy-on-Write (CoW):
Это объясняет, почему запуск 100 контейнеров из одного образа ubuntu (размером 70 МБ) не занимает 7 ГБ на диске. Все они используют одни и те же неизменяемые слои и имеют лишь крошечные индивидуальные записываемые слои.
Проблема эфемерности
Поскольку записываемый слой привязан к жизненному циклу контейнера, при выполненииdocker rm все данные в этом слое уничтожаются навсегда. Это фундаментальное свойство: контейнеры должны быть заменяемыми (cattle, not pets). Для хранения постоянных данных (базы данных, пользовательские загрузки) архитектура Docker предусматривает вынос данных за пределы UnionFS через Volumes и Bind Mounts, что мы детально разберем в следующих главах.Сетевой стек: мосты и трансляция адресов
По умолчанию Docker создает виртуальный мост docker0. Каждый новый контейнер получает виртуальную пару интерфейсов (veth pair). Один конец «втыкается» в мост docker0, второй — оказывается внутри net namespace контейнера под именем eth0.
Механизм NAT
Контейнеры получают IP-адреса из частного диапазона (например,172.17.0.0/16). Чтобы контейнер мог выйти в интернет, Docker настраивает правила iptables на хосте, выполняя маскарадинг (IP Masquerade).
Когда же вам нужно пробросить порт (-p 8080:80), Docker создает правило DNAT (Destination Network Address Translation). Пакет, пришедший на порт 8080 хоста, перенаправляется на IP контейнера и порт 80.Эта схема вносит небольшие задержки на обработку пакетов ядром. В высоконагруженных системах иногда используют режим --network host, который убирает изоляцию сети и заставляет контейнер использовать сетевой стек хоста напрямую, что дает максимальную производительность, но лишает изоляции портов.
Глубокая отладка: когда docker logs недостаточно
Понимая архитектуру, вы можете использовать инструменты, которые работают «под капотом».
docker inspect: возвращает полный JSON с конфигурацией. Здесь можно увидеть реальные пути к слоям на диске (обычно в /var/lib/docker/overlay2) и настройки cgroups.nsenter: утилита, позволяющая «войти» в пространство имен работающего процесса. Если в вашем контейнере нет curl, ip или других утилит отладки (что правильно для безопасности), вы можете использовать nsenter, чтобы запустить эти утилиты из хостовой системы, но внутри сетевого или mount-пространства контейнера./sys/fs/cgroup/ содержат текущую статистику потребления ресурсов. Если вы подозреваете, что лимит CPU работает некорректно, истина всегда находится в этих файлах, а не в выводе docker stats.Математическая модель ресурсов
Для планирования инфраструктуры важно понимать, как Docker рассчитывает доли CPU. Docker использует систему «весов» (shares) или жесткие лимиты в микросекундах.
Если мы задаем лимит CPU через --cpus="1.5", Docker настраивает cgroup так, чтобы процесс мог использовать секунды процессорного времени за каждую секунду реального времени.
Формально это выражается через параметры cpu-period и cpu-quota:
Где:
Если при , контейнер получит ровно ядра. Если приложение попытается потребить больше, планировщик ядра (CFS) просто «притормозит» (throttle) процесс до начала следующего периода. Это критически важно отслеживать в системах мониторинга: показатель CPU Throttling скажет вам о нехватке ресурсов гораздо раньше, чем средняя загрузка CPU.
Резюме архитектурного подхода
Docker — это не замена виртуализации, а способ управления изоляцией процессов. Его мощь заключается в стандартизации: благодаря containerd и OCI-образам, ваше приложение упаковывается один раз и запускается везде, где есть ядро Linux с поддержкой необходимых пространств имен.
Однако за этой простотой скрывается сложная координация между демоном, API, файловыми драйверами (Storage Drivers) и сетевыми правилами. Профессиональная работа с Docker требует понимания того, что контейнер — это всего лишь процесс, ограниченный рамками cgroups и видящий мир через призму namespaces. Любая проблема с контейнером — это либо проблема конфигурации этих ограничений, либо проблема самого процесса, который не умеет правильно обрабатывать сигналы жизненного цикла.