Что происходит после сборки Docker Image?

Обзор процесса после сборки Docker-образа

После успешной сборки Docker Image начинается критически важный этап жизненного цикла контейнеризации, который включает несколько ключевых стадий:

1. Сохранение образа в локальном реестре Docker

Собранный образ немедленно сохраняется в локальном хранилище Docker на машине, где выполнялась сборка. Docker использует content-addressable storage (CAS), где каждый слой идентифицируется хешем SHA256.

# Проверка локальных образов после сборки
$ docker images
REPOSITORY   TAG       IMAGE ID       CREATED         SIZE
myapp        latest    a1b2c3d4e5f6   2 minutes ago   345MB

2. Структура хранения образа

Образ сохраняется как набор иммутабельных слоёв (layers) в директории /var/lib/docker/overlay2 (для Linux). Каждый слой соответствует инструкции в Dockerfile:

# Пример Dockerfile с созданием слоёв
FROM alpine:3.18  # ← Слой 1: базовый образ
RUN apk add nodejs # ← Слой 2: установка пакетов
COPY . /app        # ← Слой 3: копирование файлов
CMD ["node", "/app"] # ← Метаданные (не создаёт слой)

3. Тегирование образа (опционально, но рекомендуется)

Для удобства управления образами выполняется их тегирование:

# Тегирование для различных целей
$ docker tag myapp:latest myapp:v1.2.3
$ docker tag myapp:latest registry.company.com/myapp:prod

4. Распространение образа в registry

Docker Registry (реестр) — централизованное хранилище для распространения образов. Наиболее распространённые варианты:

• Docker Hub — публичный реестр по умолчанию
• Amazon ECR, Google Container Registry, Azure Container Registry — облачные решения
• Harbor, Nexus, GitLab Container Registry — self-hosted решения

# Отправка образа в Docker Hub
$ docker push username/myapp:latest

# Отправка в приватный реестр
$ docker push private.registry.com:5000/myapp:v1.0

5. Скачивание и запуск образа на целевых хостах

На серверах развертывания выполняется:

# Получение образа из реестра
$ docker pull registry.company.com/myapp:prod

# Запуск контейнера из образа
$ docker run -d --name myapp-container -p 8080:80 registry.company.com/myapp:prod

6. Архитектура работы Docker при запуске образа

При запуске docker run происходит:

1. Извлечение слоёв образа из локального кэша или registry
2. Создание контейнерного слоя (container layer) — тонкий записываемый слой поверх имьютабельных слоёв образа
3. Инициализация namespaces и cgroups для изоляции процессов
4. Монтирование union filesystem (OverlayFS, AUFS, или devicemapper)
5. Запуск процесса, указанного в CMD или ENTRYPOINT

7. Управление жизненным циклом образа

• Версионирование — использование семантического версионирования для контроля изменений
• Очистка устаревших образов — регулярное удаление неиспользуемых образов для экономии дискового пространства
• Сканирование на уязвимости — проверка образов с помощью инструментов типа Trivy, Clair, или Docker Scout
• Подпись образов (Docker Content Trust) — гарантия целостности и происхождения образов

8. Интеграция с оркестраторами

В production-средах образы запускаются через оркестраторы контейнеров:

• Kubernetes — извлечение образов через kubelet
• Docker Swarm — распределение образов по нодам кластера
• Amazon ECS, Google GKE — managed-сервисы оркестрации

# Пример Kubernetes Deployment для запуска образа
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: registry.company.com/myapp:prod
        ports:
        - containerPort: 8080

9. Мониторинг и логирование

После запуска образов необходимо:

• Сбор логов через docker logs или централизованные системы (ELK, Loki)
• Мониторинг метрик (CPU, память, сеть) через cAdvisor, Prometheus
• Трассировка распределённых транзакций в микросервисной архитектуре

Ключевые принципы для production:

• Иммутабельность образов — образы никогда не изменяются после сборки
• Детерминированность сборки — одинаковый Dockerfile + одинаковые исходники = одинаковый образ
• Минимизация размера — использование multi-stage builds, Alpine-based образов
• Безопасность — запуск от непривилегированного пользователя, регулярное обновление базовых образов

Современные практики также включают CI/CD пайплайны, где сборка Docker-образов автоматизирована, а образы проходят через стадии тестирования и security-сканирования перед попаданием в production-реестры.