# Лекция 4: Контейнеризация в Docker: архитектура изоляции и оптимизация слоев

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

Архитектурно Docker построен по клиент-серверной модели. **Docker daemon (dockerd)** отвечает за управление объектами: образами (images), контейнерами (containers), томами (volumes) и сетями. **Docker client** взаимодействует с демоном через REST API, что позволяет управлять контейнерами как локально, так и удаленно. Ключевое преимущество такой архитектуры — возможность интеграции с оркестраторами (Kubernetes, Swarm) через стандартизированный интерфейс.

![Alt](docker.png)
### Таблица 1. Компоненты архитектуры Docker
| Компонент | Назначение | Взаимодействие | Особенности |
| -------- | -------- | -------- | -------- |
| **Docker daemon** | Управление объектами | REST API, containerd | Фоновый процесс, orchestration |
| **Docker client** | Интерфейс пользователя | CLI → daemon | Кроссплатформенность |
| **Docker registry** | Хранение образов | push/pull | Публичные/приватные реестры |
| **containerd** | Жизненный цикл контейнера | Промышленный стандарт | Выделен из dockerd |

Фундаментальная концепция Docker — **слоистая файловая система (UnionFS)**. Каждая инструкция в **Dockerfile** создает новый read-only слой. При сборке образа слои кешируются; при запуске контейнера поверх них монтируется read-write слой. Это обеспечивает эффективное использование дискового пространства и ускоряет развертывание — скачиваются только измененные слои. Однако разработчику важно понимать, что каждая инструкция `RUN`, `COPY` или `ADD` создает отдельный слой, и их оптимизация напрямую влияет на размер итогового образа.

Критическим аспектом production-эксплуатации является управление **persistent data**. Контейнеры по умолчанию stateless — все данные, записанные в read-write слое, уничтожаются при удалении контейнера. Для постоянного хранения Docker предоставляет **тома (volumes)**, управляемые демоном, и **bind mounts**, монтирующие директории хоста. Тома предпочтительнее, так как они полностью изолированы от хостовой файловой системы и могут управляться через Docker API.

Сетевая модель Docker абстрагирует коммуникации через драйверы: **bridge** (изоляция контейнеров на хосте), **host** (прямой доступ к сетевому стеку хоста), **overlay** (связь между хостами в кластере). По умолчанию каждый контейнер получает виртуальный сетевой интерфейс и IP-адрес из приватного пула, а проброс портов осуществляется через правила iptables.

Для промышленной разработки критически важно следовать **best practices**: использовать минимальные базовые образы (alpine), объединять команды `RUN` для уменьшения числа слоев, запускать процессы от непривилегированного пользователя и всегда явно указывать теги версий для воспроизводимости сборок . Это превращает Docker из инструмента упаковки в фундаментальный компонент DevOps-пайплайна, обеспечивающий идентичность окружений на всех этапах: от рабочей станции разработчика до production-кластера.