Какие механизмы Linux обеспечивают работу Docker

Механизмы Linux, лежащие в основе Docker

Docker не является самостоятельной виртуализационной технологией в классическом понимании. Это высокоуровневая платформа, которая для своей работы интенсивно использует встроенные механизмы ядра Linux, объединяя их в единый, удобный интерфейс. Основу составляют три ключевые группы технологий: namespaces, cgroups и layered filesystem.

1. Пространства имён (Namespaces)

Namespaces — это механизм изоляции, который позволяет процессу (или группе процессов) иметь собственное изолированное представление системных ресурсов. Docker использует несколько типов пространств имён для создания контейнера, который "видит" только свою выделенную среду.

• PID namespace (Процессы): Изолирует дерево процессов. Процессы внутри контейнера не видят процессы хост-системы и других контейнеров. PID 1 внутри контейнера — это его главный процесс (например, nginx), а не systemd или init хост-машины.
• Network namespace (Сеть): Создает изолированный стек сетевых интерфейсов, таблиц маршрутизации, firewall правил (iptables/nftables) и сокетов. Docker создает виртуальные интерфейсы (veth pair) и связывает их с bridge-интерфейсом (например, docker0) для обеспечения сетевого взаимодействия.
• Mount namespace (Файловая система): Обеспечивает контейнеру собственное изолированное дерево файловых систем и точек монтирования. Это основа для работы с образами.
• UTS namespace (Хостнейм и домен): Позволяет контейнеру иметь собственное имя хоста (hostname) и домена (domainname), независимое от хостовой системы.
• IPC namespace (Межпроцессное взаимодействие): Изолирует объекты межпроцессного взаимодействия, такие как сегменты разделяемой памяти (SHM), семафоры и очереди сообщений.
• User namespace (Пользователи и группы): Позволяет отображать UID/GID внутри контейнера на другие UID/GID на хосте. Это критически важный механизм для повышения безопасности, так как процесс root внутри контейнера может быть отображен на непривилегированного пользователя на хосте.

Команда, иллюстрирующая создание простейшей изоляции с помощью namespaces (аналог "контейнера вручную"):

# Запуск изолированного процесса bash с собственными PID, Mount, UTS и IPC namespaces
sudo unshare --pid --mount --uts --ipc --fork /bin/bash
# Внутри нового пространства:
hostname mycontainer # Меняем hostname только внутри namespace
ps aux # Видим сильно урезанный список процессов

2. Группы управления (Control Groups - cgroups)

Если namespaces отвечают за изоляцию, то cgroups отвечают за учет и ограничение ресурсов. Это механизм ядра для ограничения, учета и изоляции потребления ресурсов (CPU, память, дисковый I/O, сеть) коллекцией процессов.

• Ограничение памяти (memory): Задает жесткий лимит (memory.limit_in_bytes) и soft-лимит (memory.soft_limit_in_bytes) использования RAM. При превышении жесткого лимита процесс может быть завершен OOM Killer'ом.
• Ограничение CPU (cpu, cpuset): Позволяет выделять долю времени CPU (cpu.shares) или привязывать процессы к конкретным ядрам процессора (cpuset.cpus).
• Ограничение дискового I/O (blkio): Управляет пропускной способностью и IOPS для операций с блочными устройствами.
• Учет ресурсов: cgroups предоставляет детальную статистику по использованию ресурсов конкретной группой, которую Docker использует в командах docker stats.

Пример просмотра cgroups процесса контейнера:

# Находим ID контейнера
docker run -d --name test-nginx nginx
# Находим PID основного процесса контейнера
CONTAINER_PID=$(docker inspect test-nginx --format '{{.State.Pid}}')
# Смотрим, в какие контрольные группы он входит
cat /proc/$CONTAINER_PID/cgroup

Вывод покажет пути в иерархии cgroup, относящиеся к Docker, например: .../docker/<CONTAINER_ID>/.

3. Файловые системы с поддержкой слоёв (Union Filesystems)

Это ключевой механизм для эффективности работы с образами. Он позволяет создавать образы на основе слоев, что обеспечивает непревзойденную скорость развертывания, минимальный расход диска и повторное использование общих компонентов.

• Принцип работы: Файловая система объединяет несколько каталогов (слоев) в единое представление. Каждый слой — это набор изменений (дифф) относительно предыдущего слоя. При записи файла используется механизм Copy-on-Write (CoW).
• Драйверы хранения: Docker поддерживает несколько реализаций:

    *   **Overlay2 (рекомендуемый):** Современный, производительный драйвер, используемый по умолчанию. Создает два директивных слоя: `lowerdir` (образы, только для чтения) и `upperdir` (контейнерный слой для записи), объединяя их в `merged`.
    *   **AUFS:** Был основным драйвером в ранних версиях Docker.
    *   **devicemapper, btrfs, zfs:** Альтернативные варианты с разными характеристиками.

• Преимущества:

    *   **Экономия места:** Общий базовый образ (например, `alpine`) используется всеми контейнерами на хосте.
    *   **Быстрое развертывание:** Запуск контейнера — это монтирование слоев, а не копирование гигабайтов данных.
    *   **Иммutability образа:** Слой образа доступен только для чтения. Изменения в контейнере записываются в отдельный тонкий writable-слой.

Пример структуры Overlay2 можно найти на хосте:

# Просмотр информации о драйвере хранения и слоях контейнера
docker inspect <container_id> --format='{{.GraphDriver.Data}}'

Взаимодействие механизмов при запуске контейнера

1. Подготовка файловой системы: Драйвер Overlay2 подготавливает слои образа и создает upperdir и merged для контейнера.
2. Создание namespaces: Ядро создает новое изолированное окружение (PID, Network, Mount и т.д.).
3. Создание cgroups: Для будущих процессов контейнера создается контрольная группа с заданными лимитами ресурсов.
4. Инициализация сети: Создается network namespace, внутри него — виртуальный интерфейс, который связывается с docker0 bridge.
5. Запуск процесса: В созданном изолированном окружении и с ограничениями cgroups запускается процесс, указанный в Dockerfile (CMD или ENTRYPOINT).

Таким образом, Docker выступает как мощный менеджер и оркестратор низкоуровневых функций ядра Linux. Он инкапсулирует сложность работы с namespaces, cgroups и union mount, предоставляя пользователю простой API для управления контейнерами. Без этих встроенных механизмов ядра существование Docker в его современном виде было бы невозможным.