В чем фундаментальная разница между виртуализацией и контейнеризацией?

Виртуализация эмулирует аппаратное обеспечение с помощью гипервизора, на котором запускается полноценная гостевая ОС со своим независимым ядром. Контейнеризация изолирует процессы на уровне одного общего ядра хостовой ОС Linux с помощью пространств имен (namespaces) и контрольных групп (cgroups), обеспечивая запуск за миллисекунды и околонулевые накладные расходы на виртуализацию.

Что такое образ Docker (Image) и контейнер (Container)? В чем их различие?

Образ Docker — это неизменяемый (read-only) шаблон, состоящий из набора слоев файловой системы, метаданных и инструкции запуска. Контейнер — это исполняемый экземпляр образа, представляющий собой изолированный системный процесс с добавленным поверх тонким слоем записи (read-write layer). Из одного образа можно запустить неограниченное количество независимых контейнеров.

Что означает код завершения контейнера 137 (Exit Code 137)?

Код возврата 137 означает, что процесс был завершен сигналом SIGKILL (сигнал 9). В соответствии со стандартами Unix код вычисляется по формуле 128 + номер сигнала (128 + 9 = 137). Чаще всего это свидетельствует о срабатывании механизма ядра OOM (Out Of Memory) Killer из-за превышения контейнером лимита оперативной памяти, заданного в cgroups.

За что отвечают пространства имен (Namespaces) в ядре Linux при работе Docker?

Namespaces изолируют видимость системных ресурсов для группы процессов. Ядро поддерживает 6 основных пространств: PID (изолирует дерево процессов, делая главный процесс PID 1), NET (изолирует сетевые интерфейсы, IP и таблицы маршрутов), MNT (изолирует точки монтирования файловой системы), IPC (изолирует разделяемую память и семафоры), UTS (изолирует имя хоста), USER (проецирует внутренние UID/GID на непривилегированные внешние идентификаторы).

Что такое Control Groups (cgroups) и чем отличаются cgroups v1 от cgroups v2?

cgroups — это механизм ядра Linux для ограничения, учета и изоляции ресурсов (память, CPU, дисковый ввод-вывод) групп процессов. В cgroups v1 каждый тип ресурса управлялся отдельной несвязанной иерархией каталогов, что вызывало конфликты при взаимодействии подсистем памяти и ввода-вывода. В cgroups v2 реализована единая унифицированная древовидная иерархия, исключающая взаимоблокировки и обеспечивающая точный учет страничного кэша (Page Cache) и буферизованной записи.

Как работает механизм Copy-on-Write (CoW) в файловой системе OverlayFS?

OverlayFS объединяет директории нижних слоев образа (lowerdir, read-only) и директорию контейнера (upperdir, read-write) в общее виртуальное дерево (merged). При чтении файл берется из lowerdir. При попытке изменения файла ядро прозрачно для процесса делает полную копию этого файла в upperdir, где и фиксируются модификации. Исходные слои образа остаются неизменными и могут разделяться между множеством запущенных контейнеров.

Что такое OCI (Open Container Initiative) и какова роль runc и containerd?

OCI — это открытый отраслевой стандарт, определяющий формат образов контейнеров (image-spec) и интерфейс их запуска (runtime-spec). runc — это эталонная низкоуровневая CLI-утилита, взаимодействующая с ядром Linux (настраивает namespaces, cgroups, монтирует rootfs и запускает бинарник). containerd — это высокоуровневый системный демон, управляющий полным жизненным циклом: скачиванием образов из сети, распаковкой слоев и диспетчеризацией экземпляров runc.

Каковы риски выполнения контейнера с флагом --privileged в production?

Флаг --privileged отключает практически все механизмы изоляции безопасности ядра: предоставляет процессу контейнера полный набор всех Linux Capabilities, отключает фильтры системных вызовов Seccomp и AppArmor, а также открывает прямой доступ ко всем физическим устройствам хоста (/dev). Процесс с правами root внутри привилегированного контейнера может легко смонтировать физический диск хоста и получить абсолютный контроль над родительской операционной системой.

Что такое Docker: контейнеризация vs виртуализация, namespaces и cgroups — Deployments, Docker & CI/CD

Архитектурная база#

Исторически главной проблемой развертывания веб-приложений была проблема дрейфа окружения (Environmental Drift), формулируемая разработчиками как «На моем локальном компьютере все работало!». Приложение, успешно протестированное на машине разработчика под macOS или Windows, при попадании на production-сервер Linux падало из-за несовпадающих версий системной библиотеки glibc, отсутствующих системных пакетов, различий в конфигурации часовых поясов или иных прав доступа.

Для решения проблемы изоляции окружений индустрия десятилетиями использовала аппаратную виртуализацию (Virtual Machines, VM). В модели виртуализации специальная программа — гипервизор (Hypervisor) — эмулирует физическое оборудование (виртуальный процессор, память, сетевую карту, дисковый контроллер). Внутри каждой виртуальной машины устанавливается и запускается полноценная независимая гостевая операционная система (Guest OS) со своим собственным ядром, системными демонами и таблицами страниц памяти.

Технология контейнеризации (Containerization) и платформа Docker предложили принципиально иную парадигму: изоляцию на уровне процессов внутри единого разделяемого ядра Linux. Контейнер — это не виртуальная машина. Контейнер — это обычный изолированный процесс операционной системы хоста, чьи права, видимость ресурсов и потребление памяти ограничены встроенными механизмами ядра Linux: Namespaces, Control Groups (cgroups) и слоистой файловой системой OverlayFS.

Ментальная модель#

Сравним физическое устройство виртуальной машины и легковесного контейнера в оперативной памяти сервера:

text

+-------------------------------------------------------------------------+
|             ВИРТУАЛИЗАЦИЯ (VM) VS КОНТЕЙНЕРИЗАЦИЯ (DOCKER)              |
+-------------------------------------------------------------------------+
| ВИРТУАЛЬНЫЕ МАШИНЫ (Hypervisor):       КОНТЕЙНЕРЫ (Docker Engine):      |
|                                                                         |
| ┌──────────────┐ ┌──────────────┐      ┌──────────────┐ ┌──────────────┐|
| │ App 1 (Node) │ │ App 2 (Postg)│      │ App 1 (Node) │ │ App 2 (Postg)│|
| ├──────────────┤ ├──────────────┤      ├──────────────┤ ├──────────────┤|
| │ Libs / Bins  │ │ Libs / Bins  │      │ Libs / Bins  │ │ Libs / Bins  │|
| ├──────────────┤ ├──────────────┤      ├──────────────┴─┴──────────────┤|
| │ Гостевая ОС  │ │ Гостевая ОС  │      │   Изоляция cgroups/namespaces  │|
| │ (Свое ядро!) │ │ (Свое ядро!) │      ├───────────────────────────────┤|
| ├──────────────┴─┴──────────────┤      │     Docker Engine (runc)      │|
| │  Гипервизор (KVM / ESXi)      │      ├───────────────────────────────┤|
| ├───────────────────────────────┤      │      Ядро хоста Linux         │|
| │       Оборудование (CPU/RAM)  │      │      Оборудование (CPU/RAM)   │|
| └───────────────────────────────┘      └───────────────────────────────┘|
| (Сотни МБ памяти на ядро ОС;           (0 МБ накладных расходов на ядро;|
|  минуты на запуск виртуальной машины)   старт процесса за миллисекунды) |
+-------------------------------------------------------------------------+

Три столпа контейнеризации в ядре Linux:

Namespaces (Пространства имен): отвечают за изоляцию того, что процесс может видеть. Процесс внутри контейнера видит только свою таблицу процессов (PID 1), свой сетевой интерфейс (eth0), свои точки монтирования и свое имя хоста.
cgroups (Control Groups, Контрольные группы): отвечают за ограничение того, сколько ресурсов процесс может потребить. Задают жесткие лимиты на оперативную память (memory.max), такты процессора (cpu.max) и дисковые операции ввода-вывода (I/O).
OverlayFS (Union Filesystem): объединяет неизменяемые слои образа (Read-Only) и тонкий временный слой записи контейнера (Read-Write) в единое виртуальное дерево каталогов через механизм Copy-on-Write (CoW).

Контейнеризация (Containerization)
Гипервизор (Hypervisor)
Пространства имен (Namespaces)
Контрольные группы (cgroups)
Слоистая файловая система (OverlayFS)
Образ Docker (Docker Image)
Контейнер Docker (Docker Container)

Конвейер запуска контейнера движком Docker#

Как вызов команды 'docker run' разворачивается в ядре Linux

1. Проверка и скачивание образа (Docker Client -> Daemon)registry pull

Docker Daemon проверяет локальный кэш образов. Если образ отсутствует, он скачивает неизменяемые слои с Docker Hub или реестра.

2. Создание пространств имен (Namespaces)namespaces

Низкоуровневый рантайм runc выполняет системные вызовы clone() и unshare(), изолируя PID, сетевой стек, точки монтирования и IPC.

3. Наложение слоев OverlayFSoverlayfs mount

Ядро монтирует слои образа (lowerdir) в режиме 'только чтение' и прикрепляет пустую директорию контейнера (upperdir) для записи.

4. Назначение квот ресурсов в cgroupscgroups limits

Рантайм создает директорию в псевдофайловой системе /sys/fs/cgroup и записывает туда лимиты оперативной памяти и процессорного времени.

5. Запуск целевого бинарника (execve)execve (PID 1)

Основной процесс приложения запускается внутри изолированного окружения, получая статус PID 1 в своем локальном дереве процессов.

CHECKPOINT #1

Проверка понимания: Природа контейнера в ядре Linux

+15 XP

Что физически происходит в операционной системе Linux при запуске команды `docker run -d node:alpine`?

На практике применяется#

Единая среда разработки и продакшена (Dev/Prod Parity): исключение сбоев несовместимости версий Node.js, компиляторов и системных пакетов — один и тот же бинарный образ запускается на ноутбуке разработчика, в CI/CD и на production-нодах.
Плотная утилизация серверов (Microservices Density): благодаря отсутствию накладных расходов на гостевые ОС, на одном физическом сервере можно запускать сотни независимых микросервисов, тогда как запуск сотен VM привел бы к мгновенному исчерпанию оперативной памяти.
Мгновенное автоматическое масштабирование (Horizontal Pod Autoscaling): запуск нового экземпляра контейнера занимает от десятков до сотен миллисекунд (по сравнению с 2-5 минутами на загрузку виртуальной машины), что позволяет мгновенно парировать пиковые нагрузки веб-трафика.
Неизменяемая инфраструктура (Immutable Infrastructure): обновление приложения происходит путем развертывания свежего, проверенного образа, а не ручной правкой файлов на работающем сервере, что гарантирует воспроизводимость и легкий откат на предыдущую версию.

Как это работает#

1. Шесть фундаментальных пространств имен Linux (Namespaces)#

Ядро Linux изолирует окружение контейнера через 6 ключевых пространств имен:

bashИсследование пространств имен процессов в Linux

# 1. Просмотр всех пространств имен активного процесса Node.js
# Каждое пространство имеет свой уникальный inode в ядре
ls -la /proc/$$/ns/

# Вывод покажет ссылки вида:
# lrwxrwxrwx 1 root root 0 Oct 19 12:00 pid -> 'pid:[4026531836]'
# lrwxrwxrwx 1 root root 0 Oct 19 12:00 net -> 'net:[4026531992]'
# lrwxrwxrwx 1 root root 0 Oct 19 12:00 mnt -> 'mnt:[4026531840]'

# 2. Список пространств имен в системе через утилиту lsns
lsns -t pid

# 3. Ручной запуск изолированного процесса без Docker через команду unshare
# Создаем изолированное пространство имен PID и монтирования:
unshare --pid --net --mount-proc /bin/bash
# Внутри новой оболочки ps aux покажет только один процесс — ваш текущий bash как PID 1!

Назначение пространств имен:

PID Namespace: процесс видит себя как PID 1 внутри контейнера, однако на хосте этот же процесс имеет реальный системный идентификатор (например, PID 18420).
NET Namespace: контейнер получает виртуальный сетевой интерфейс (eth0), собственную таблицу маршрутизации и собственный изолированный стек портов.
MNT (Mount) Namespace: процесс имеет собственное дерево точек монтирования корневой файловой системы / без доступа к диску хоста.
IPC Namespace: изолирует очереди сообщений POSIX и разделяемую память (Shared Memory), не позволяя чужим процессам перехватывать данные.
UTS Namespace: позволяет контейнеру иметь собственное доменное имя и имя хоста (hostname).
USER Namespace: проецирует суперпользователя root (UID 0) внутри контейнера на непривилегированного пользователя на хосте (например, UID 10001), повышая безопасность.

2. Ограничение ресурсов через Control Groups (cgroups v2)#

Если контейнер не ограничен по ресурсам, утечка памяти в коде Node.js может потребить всю физическую RAM сервера, вынудив ядро аварийно уничтожить критические системные процессы (SSH, базу данных). Для предотвращения катастрофы Docker настраивает подсистему cgroups:

bashУправление лимитами cgroups при запуске контейнера

# Запуск контейнера с лимитом 512 Мегабайт памяти и 1.5 ядра процессора
docker run -d \
  --name payment-service \
  --memory="512m" \
  --cpus="1.5" \
  --restart=on-failure:5 \
  node:alpine node server.js

# Как ядро Linux отслеживает этот лимит под капотом (в cgroups v2):
cat /sys/fs/cgroup/system.slice/docker-<CONTAINER_ID>.scope/memory.max
# Выведет точное число байт: 536870912 (512 МБ)

cat /sys/fs/cgroup/system.slice/docker-<CONTAINER_ID>.scope/memory.current
# Текущее фактическое потребление оперативной памяти контейнером

3. Механизм Copy-on-Write (CoW) в файловой системе OverlayFS#

Образ Docker состоит из набора неизменяемых слоев (Read-Only Layers). Когда контейнер стартует, Docker создает тонкий слой записи (Writable Container Layer).

text

+-------------------------------------------------------------------------+
|                  АНАТОМИЯ СЛОИСТОЙ ФАЙЛОВОЙ СИСТЕМЫ                     |
+-------------------------------------------------------------------------+
| [Слой контейнера]  (Read-Write, верхний слой / upperdir):               |
|   Файлы логов, временные файлы кэша, измененные конфиги                 |
|   (Существует только пока жив контейнер!)                               |
| ─────────────────────────────────────────────────────────────────────── |
| [Объединенный вид] (Merged View: то, что видит процесс внутри):         |
|   /app/server.js  /usr/local/bin/node  /etc/hosts  /var/log/app.log     |
| ─────────────────────────────────────────────────────────────────────── |
| [Слои образа]      (Read-Only, нижние слои / lowerdir):                 |
|   Слой 3: Исходный код приложения (COPY . /app)                         |
|   Слой 2: Установленные npm-пакеты (RUN pnpm install)                   |
|   Слой 1: Базовый дистрибутив Alpine (FROM node:alpine)                 |
|   (Разделяются между сотнями контейнеров без дублирования памяти!)      |
+-------------------------------------------------------------------------+

Если процесс внутри контейнера читает файл из слоя образа, он читает его напрямую. Если процесс пытается изменить файл, ядро Linux мгновенно копирует этот файл из нижнего неизменяемого слоя (lowerdir) в верхний записываемый слой (upperdir) и модифицирует копию. Это и есть принцип Copy-on-Write (копирование при записи).

4. Архитектурный конвейер изоляции ядра при вызове container runtime#

Архитектурный конвейер

Конвейер низкоуровневой изоляции процесса утилитой runc

4 этапов

1. Получение OCI Bundle

containerd / runcЯдро / Core

Демон containerd распаковывает образ в спецификацию OCI: корень файловой системы (rootfs) и манифест config.json.

Инженерная сноска рантайма:

Стандарт OCI (Open Container Initiative) гарантирует совместимость образов с любыми рантаймами (Docker, Podman, CRI-O).

2. Системный вызов clone(CLONE_NEW*)

kernel syscallЯдро / Core

Выполняется системный вызов clone с набором флагов CLONE_NEWPID, CLONE_NEWNET, CLONE_NEWNS для создания новых пространств имен.

Инженерная сноска рантайма:

Дочерний процесс рождается изолированным от системного окружения хоста.

3. Монтирование pivot_root

VFS isolationЯдро / Core

Процесс вызывает pivot_root, делая директорию rootfs своим новым корнем файловой системы и отмонтируя старый корень хоста.

Инженерная сноска рантайма:

Безопаснее устаревшего chroot: предотвращает атаки выхода из изолированного каталога (chroot jailbreak).

4. Ограничение cgroups и seccomp

security filterЯдро / Core

Ядро применяет фильтр системных вызовов Seccomp (блокирует опасные вызовы вроде reboot) и устанавливает лимиты памяти в cgroups.

Инженерная сноска рантайма:

По умолчанию в профиле seccomp Docker заблокировано более 40 опасных системных вызовов ядра.

5. Сравнение виртуальных машин и контейнеров#

Сравнение характеристик аппаратной виртуализации и контейнеризации

Критерий	Виртуальные машины (VMware / KVM)	Контейнеры (Docker / OCI)
Уровень изоляции	Аппаратная изоляция через гипервизор; собственное ядро ОС.	Изоляция на уровне ядра Linux (namespaces и cgroups).
Время запуска	Минуты (полный цикл инициализации BIOS и загрузки ядра ОС).	Миллисекунды (запуск обычного процесса в пространстве имен).
Накладные расходы по памяти	Высокие: от 500 МБ до нескольких ГБ RAM на одну гостевую ОС.	Практически нулевые: память расходуется только на само приложение.
Кросс-платформенность ядра	Можно запустить Windows на Linux-хосте или Linux на Windows.	Требует совместимого ядра хоста (Linux-контейнеры требуют ядра Linux).

CHECKPOINT #2

Проверка понимания: Поведение OOM Killer при превышении лимита cgroups

+15 XP

Контейнеру Node.js задан жесткий лимит памяти `--memory='256m'`. В коде возникла утечка памяти, и потребление достигло 260 МБ. Что произойдет с контейнером?

Распространённые ошибки#

Ошибка: Восприятие контейнера как 'легкой виртуальной машины'

Начинающие разработчики часто пытаются установить внутрь одного контейнера SSH-сервер (sshd), планировщик cron, базу данных и веб-сервер. Это фундаментальный антипаттерн: контейнер спроектирован для запуска ровно одного главного процесса (PID 1). Нарушение принципа «один контейнер — одна ответственность» ломает сбор логов (stdout), препятствует автоматическому масштабированию и делает невозможным мониторинг работоспособности через Healthcheck.

Ошибка: Запуск контейнеров в продакшене без жестких лимитов памяти

Запуск команды docker run -d my-app без флагов --memory опасен. В случае неконтролируемой утечки памяти процесс Node.js начнет вытеснять память хоста. Сработает глобальный хостовый OOM Killer, который с высокой вероятностью убьет не виновный контейнер, а СУБД PostgreSQL или процесс Docker Daemon. Решение: Всегда задавайте --memory="512m" и лимиты CPU для каждого контейнера.

Ошибка: Хранение постоянных данных в слое записи контейнера (Writable Layer)

Файлы, создаваемые приложением внутри контейнера (загруженные пользователями аватары, данные базы данных), записываются в тонкий временный слой OverlayFS. При удалении контейнера (docker rm -f) этот слой безвозвратно удаляется с диска вместе со всеми данными. Решение: Для любых сохраняемых данных обязательно используйте постоянные хранилища — Docker Volumes или Bind Mounts.

Ошибка: Попытка запустить Windows-бинарники в Linux-контейнере

Так как контейнеры разделяют ядро хостовой операционной системы, невозможно запустить нативный 64-битный исполняемый файл .exe Windows внутри Linux-контейнера без эмулятора. Контейнеризация изолирует окружение, но не эмулирует чужую архитектуру процессора или системные вызовы чужого ядра.

Собеседование: Вопросы и ответы#

Interview Questions8 questions