Обновление образов Docker: руководство по безопасным апдейтам

Сервер с Docker и контейнерами в терминале

Быстрое содержание

Как подтянуть новый образ
Замена контейнеров через Docker Compose
Управление тегами образов
Пересборка собственных образов
Обновления ПО внутри контейнеров — почему это нежелательно
Автоматизация обновлений (Watchtower и альтернативы)
Когда не обновлять автоматически
Практическое руководство (SOP) и чеклисты
Дерево решений, матрица рисков и роль‑ориентированные задачи

Введение

Docker-контейнеры проектируются как заменяемые единицы: их запускают заново, а не «патчат» на лету. Когда базовый образ получает обновление (например — исправления безопасности), нужно подтянуть новый образ и создать новые экземпляры контейнеров. В статье показаны практические варианты — от ручных команд до автоматизации и процедур для команд разных ролей.

Подтягивание новых образов

Базовый подход — pull → удалить старый контейнер → запустить новый. Для образа nginx:latest это выглядит так:

# Pull new image  
docker pull nginx:latest  
  
# Delete old container by name  
docker rm example-nginx  
  
# Start a new container  
docker run -d -p 80:80 --name example-nginx nginx:latest

Важно: docker pull просто загружает образ в локальный кеш. Сам контейнер, запущенный из старого слоя, не изменится, пока вы не пересоздадите его.

Важное: никогда не удаляйте контейнеры с незадублированными данными. Для сохранения данных используйте Docker volumes.

Замена контейнеров через Docker Compose

Docker Compose даёт декларативный способ описать стек в docker-compose.yml и удобно управлять жизненным циклом стэка командами:

# Pull all images in the stack  
docker-compose pull  
  
# Restart the stack  
# If a new image version has been pulled, containers   
# using the old tag will be replaced with new instances.  
docker-compose up -d

Compose облегчает работу: не нужно помнить все флаги docker run или явно указывать имена образов. Частая практика — объединить команды в alias:

alias composePullUp="docker-compose pull && docker-compose up -d"

Пример docker-compose.yml

version: '3.8'
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./site:/usr/share/nginx/html:ro
  db:
    image: postgres:13
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Compose автоматически возьмёт теги, которые вы указали в файле.

Управление тегами образов

Тег указывает, какую версию образа вы получаете. Несколько рекомендаций:

Используйте семантические теги (например, postgres:13.9) для воспроизводимости.
Для оперативных окружений можно использовать minor‑теги (postgres:13) и контролировать обновления с помощью CI и тестов.
Тег latest — удобный для разработки, но опасный для продакшена, так как может содержать неожиданные мажорные обновления.

Пример: pull node:14 даст последний патч внутри 14‑й линии, а pull node:latest может поменять мажор.

Пересборка собственных образов

Если вы строите образ самостоятельно (Dockerfile), пересборка с опцией –pull гарантирует, что базовый образ будет обновлён перед сборкой:

docker build --pull -t my-image:latest .

Затем удалите и пересоздайте контейнеры:

# Delete old container by name  
docker rm my-container  
  
# Start a new container  
docker run -d --name my-container my-image:latest

Compose эквивалент:

docker-compose build --pull  
  
docker-compose up -d

ПО внутри контейнеров: почему не стоит запускать обновления напрямую

В отличие от bare metal, контейнеры не предназначены для длительной модификации файловой системы внутри инстанса. Запуск apt-get upgrade внутри запущенного контейнера ломает повторяемость и усложняет откат. Лучше включать обновления в процесс сборки образа (Dockerfile) и пересобирать образ централизованно.

Короткая рекомендация: патчи в образе — во время сборки; временные изменения — в volume или tmpfs.

Автоматизация обновлений

Можно автоматизировать проверку и замену контейнеров. Популярный представитель — Watchtower. Он же разворачивается как контейнер и использует Docker socket для управления хостом:

docker run -d -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower

Watchtower: мониторит образы на регистрах, подтягивает обновления и пересоздаёт контейнеры с теми же флагами, что и у исходных запусков.

Поддержка приватных регистров

По умолчанию Watchtower работает с Docker Hub. Для приватных регистров создайте JSON‑файл с auths и смонтируйте его внутрь контейнера:

{  
    "auths": {  
        "example.com": {  
            "auth": "credentials"  
        }  
    }  
}

Где credentials — Base64(username:password):

echo -n 'username:password' | base64

И затем запуск с монтированием конфигурации:

docker run -d   
    -v config.json:/config.json  
    -v /var/run/docker.sock:/var/run/docker.sock   
    containrrr/watchtower

Альтернативы автоматизации

Diun — нотификатор обновлений образов (предупреждает, не всегда обновляет).
CI/CD подход: пересобрать и задеплоить из пайплайна после прохождения тестов.
Orchestration (Kubernetes): kubelet/k8s controllers используют образы и обновления выполняются через Deployments/DaemonSets с возможностью стратегий обновления.

Выбор зависит от требований: простота (Watchtower), контроль и тестирование (CI), масштаб/автоматика (Kubernetes).

Когда не стоит включать автообновления

Сервисы с важной миграцией баз данных: автообновление может применить несовместимый код.
Системы с требованием к воспроизводимости релизов: нужен фиксированный набора тегов и деплой через CI.
Ограниченные сети или air-gapped окружения: невозможно автоматически подтянуть образы.

Если вы всё же автоматизируете, вводите стадию предварительного тестирования: pull → deploy в тест → smoke tests → deploy в прод.

SOP: пошаговая процедура обновления образов (обобщённая)

Планируйте окно обслуживания или используйте канареечный деплой.
Pull образ(ы): docker pull / docker-compose pull.
Соберите кастомные образы с –pull.
Разверните в тестовом окружении и выполните миграции и smoke tests.
Если тесты прошли, выполните перезапуск в production: docker-compose up -d или rolling update.
Наблюдайте метрики и логи 15–30 минут.
При проблемах — откат к предыдущему тегу и анализ.

Пример быстрого отката

# Предположим, предыдущий стабильный тег my-image:1.2.3
docker-compose stop
# в docker-compose.yml замените тег на my-image:1.2.3 или используйте override
docker-compose up -d

Роль‑ориентированные чеклисты

DevOps / SRE:
- Настроить backup volumes и бэкапы БД перед обновлениями.
- Настроить мониторинг и алерты на health checks.
- Определить стратегию отката.
Разработчик:
- Поддерживать Dockerfile и тесты для образа.
- Указывать семантические теги в CI.
QA:
- Написать smoke и regression тесты для контейнера.
- Поддерживать тестовый стенд, где применяются новые образы перед продом.
Безопасность:
- Отслеживать CVE и обновления базовых образов.
- Удостовериться, что секреты не попадают в образы.

Матрица рисков и mitigations

Риск: несовместимость мажорной версии → Митигирование: pinning тегов и тестирование в staging.
Риск: потеря данных при некорректном обновлении → Митигирование: snapshot/backup volumes перед апгрейдом.
Риск: уязвимости в новом образе → Митигирование: сканирование образов и канареечный релиз.

Дерево решений (Mermaid)

flowchart TD
  A[Появился новый образ] --> B{Это базовый образ или ваш?}
  B -->|Базовый| C[Запустить docker pull / docker-compose pull]
  B -->|Ваш Dockerfile| D[Пересобрать с --pull]
  C --> E[Развернуть в тестовом окружении]
  D --> E
  E --> F{Smoke тесты успешны?}
  F -->|Да| G[Развернуть в production]
  F -->|Нет| H[Откат и анализ]
  G --> I{Критичные миграции?}
  I -->|Да| J[Ручной апгрейд с контролем]
  I -->|Нет| K[Можно автоматизировать повторяемо]

Практические сценарии и когда подход ломается

Состояние, привязанное к файловой системе контейнера: замена приведёт к потере.
Образы, завязанные на специфичных сетевых конфигурациях: автоматический restart может изменить порядок запуска сервисов и вызвать зависимость.
Если образ содержит приватные ключи или секреты — это нарушает практику immutable‑infrastructure.

Советы по тегированию и CI

CI должен собирать и тестировать образ при каждом значимом коммите и пушить с уникальным тегом (commit SHA) и меткой latest/stable.
Для production используйте релизные теги (vX.Y.Z). Для отката храните теги и манифесты.

Краткий факт-бокс

Контейнеры должны быть кратковременными и заменяемыми.
Автоматизация даёт скорость, но требует тестов и стратегий отката.
Семантические теги повышают предсказуемость деплоя.

1‑строчный глоссарий

Образ (image): read-only шаблон для создания контейнера.
Контейнер: запущенный процесс, созданный из образа.
Tag: метка образа, указывающая версию.
Pull: операция загрузки образа в локальный кеш.

Критерии приёмки

Образ подтянут и контейнеры работают с тем же набором конфигурационных параметров.
Smoke tests проходят автоматически после обновления.
Есть план отката и бэкап данных.

Шаблон плейбука для обновления (коротко)

Создать задачу в трекере с указанием тегов и ожидаемых изменений.
Выполнить docker-compose pull / docker build –pull.
Развернуть в staging, запустить тесты.
Если успешно — промотать в production по канареечной стратегии.
Мониторинг 30–60 минут, подтверждение успешности.
Закрыть задачу и задокументировать инциденты.

Короткое объявление для команды (100–200 слов)

Мы внедряем регламент обновления Docker-образов: базовые образы подтягиваются и пересобираются с флагом –pull в CI, затем проходят smoke tests в staging и только после этого деплоятся в прод. Для непрерывной автоматизации можно использовать Watchtower, но для сервисов с миграциями обновления будут проходить через CI и ручную проверку. Каждое обновление должно иметь план отката и задокументированные теги образов.

Заключение

Docker не имеет встроенного механизма «вживления» обновлений образов в уже запущенные контейнеры — контейнеры нужно пересоздавать. Выбор способа обновления зависит от требований к контролю и скорости: ручной pull и run, Docker Compose для декларативности или Watchtower/CI для автоматизации. Для критичных сервисов добавляйте staging, smoke tests и чёткий план отката.

Сводка:

Всегда используйте –pull при сборке своих образов.
Для повторяемости применяйте семантическое тегирование.
Автоматизируйте осторожно: тесты и откат — обязательны.

Обновление и управление образами Docker: что и как