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

Схема маркировки Docker-образов на примерах тегов

Быстрые ссылки

Добавление тегов
Непомеченные образы
Пуш образов с помощью тегов
Замена и модификация тегов
Удаление тегов
Практические рекомендации и чеклисты

Как работают теги (коротко)

Тег — это читаемый ярлык для конкретных данных образа (image layer set). Внутри Docker изображение идентифицируется по SHA256 digest, а теги просто указывают на этот digest. Одна и та же «физическая» версия образа может иметь несколько тегов.

Определение: Тег — человекочитаемая метка вида <имя>:<тег>, например example-image:1.1.0-apache.

Важно: тег — это не версия кода сам по себе, а ссылочный ярлык на набор слоёв образа.

Добавление тегов

Теги добавляются с помощью команды docker tag или при сборке через docker build с флагом -t.

Синтаксис:

# docker tag <исходный образ> <новый тег>

Пример:

docker tag example-image:1.1.0 example-image:1.1.0-apache

После этого оба тега указывают на один и тот же образ, и вы можете использовать их взаимозаменяемо локально. Однако команда docker pull example-image:1.1.0 не изменит локальный тег example-image:1.1.0-apache — привязка тега к конкретному образу обновляется только явно через команды CLI.

Замечание: если вы вызываете docker pull без указания тега (docker pull example-image), Docker по умолчанию подтянет тег latest.

Непомеченные (untagged) образы

Можно получить «непомеченные» образы, если тег был перемещён на новый digest (например, при повторном pull). Чтобы найти такие образы, пользуйтесь:

docker images

Если у вас есть ID непомеченного образа, присвойте ему новый тег:

docker tag 0e3e06b48755 example-image:latest

Пример того, как появляются непомеченные образы:

# уже есть example-image:latest

docker pull example-image:latest

После pull старый набор слоёв останется на диске, но без тега — он станет untagged. Если требуется очистка, используйте docker image prune или docker system prune с осторожностью.

Пуш образов в реестр с помощью тегов

При отправке образа в реестр (docker push) имя реестра и путь входят в тег. Чтобы отправить в частный реестр, добавьте hostname (и порт, если нужен) в тег:

docker tag example-image:latest registry.example.com/example-image:latest

Затем:

docker push registry.example.com/example-image:latest

Если вы пушите «голый» тег без URL (например, docker push example-image:latest), Docker будет использовать Docker Hub.

Важно: для приватного реестра необходима аутентификация (docker login registry.example.com).

Замена и модификация тегов

При повторном использовании цели (target) в docker tag старый ярлык будет перезаписан локально:

docker tag first-image:latest demo

docker tag second-image:latest demo

Теперь demo указывает на second-image. Это полезно для локальной организации, но опасно для публичных тегов.

Правило хорошей практики: не перезаписывайте публичные теги. Вместо этого создавайте новый тег версии (v1.0.1, v1.0.2) или используйте каналы, явно обозначенные (stable, beta), и уведомляйте пользователей.

Пример плохой практики (не делайте так для публичных релизов):

# Build and push v1

docker build -t example-image:v1 .

docker push example-image:v1

# v1 now refers to different image data

# This is fine for local use (tags in the

# registry are independent of your local tags).

docker build -t example-image:v1 .

# Don't do this - now the tag in the registry

# has been changed too, which could negatively

# impact existing users.

docker push example-image:v1

Совет: если требуется обновляемый указатель на последний стабильный релиз, заведите отдельный канал (например stable:latest) и применяйте его только после тестирования.

Удаление тегов

Чтобы удалить тег локально, используйте docker rmi с указанием тега:

docker rmi example-image:1.1.0-apache

Если этот тег был единственным для набора данных образа, Docker удалит и данные образа. Удаление тега локально не влияет на реестр:

# Does not remove the tag from the registry!

docker rmi registry.example.com/example-image:latest

Нельзя удалять отдельный тег через Docker Registry HTTP API у всех реализаций — спецификация по умолчанию не даёт простой конечной точки для удаления тега (это связано с идеей сохранения исторической воспроизводимости). Многие сторонние реестры (Artifactory, Nexus, Harbor) реализуют собственные механизмы удаления; обратитесь к документации вашего реестра.

Практические рекомендации и шаблоны именования тегов

Используйте семантическое версионирование для релизов: 1.2.3, 2.0.0-rc1.
Добавляйте маркеры базовых зависимостей: example-image:1.2.0-nginx или :1.2.0-apache.
Для CI/CD включайте метаданные (дату/хэш) в отдельные теги: ci-20230517-ab12c3.
Разграничивайте каналы: latest (только как метка по умолчанию), stable, beta, staging.
Не перезаписывайте публичные теги; вместо этого выпуск новой версии или добавление канального тега.
Документируйте формат тегов в README репозитория образа.

Факт-бокс: ключевые команды

docker tag
docker build -t .
docker push /
docker pull
docker rmi

Контрпримеры — когда схема тегов может не подойти

Когда вам нужна абсолютная неизменность: теги можно перезаписать; используйте digest (sha256:…) для точного указания.
Если реестр требует политики хранения метаданных, возможно, придётся управлять образами через UI реестра, а не через теги.
При многоплатформенных сборках (multi-arch) один тег может ссылаться на manifest list; следите, чтобы архитектура была понятна пользователям.

Пример использования digest вместо тега:

docker pull example-image@sha256:abcdef1234567890...

Это гарантирует, что вы подтянете именно тот набор слоёв.

Альтернативные подходы

Digest (sha256) для строгой идентификации образа.
Content-addressable manifests или подписи (например, Notary/OCI Content Trust) для верификации происхождения.
Использование реестров с политиками immutability для защищённых производственных каналов.

Чеклист ролей

Разделены на три роли: разработчик, CI/CD-оператор, администратор реестра.

Разработчик:

Дать понятные теги при локальной сборке.
Не перезаписывать публичные теги.
Документировать варианты образа (apache/nginx/…).

CI/CD-оператор:

Генерировать уникальные CI-теги (build id, date, commit).
Тегировать релизную сборку семантической версией.
Пушить в защищённый реестр с проверкой доступа.

Администратор реестра:

Настроить политики хранения и очистки образов.
При необходимости включить механизм удаления тегов или блокировать перезапись.
Обеспечить подписывание и проверку образов в prod.

Cheat sheet (шпаргалка)

Добавить локальный тег: docker tag src:tag target:tag
Сборка с тегом: docker build -t myapp:1.0 .
Пуш в реестр: docker push registry.example.com/myapp:1.0
Удаление локального тега: docker rmi myapp:1.0
Просмотр образов: docker images
Очистка: docker image prune

Решение: поток принятия решения (Mermaid)

flowchart TD
  A[Нужен новый образ?] -->|Да| B[Собрать образ с тегом]
  A -->|Нет| C[Использовать существующий тег]
  B --> D{Это публичный релиз?}
  D -->|Да| E[Тег semver и пуш]
  D -->|Нет| F[Использовать CI-идентификатор]
  C --> G{Нужна неизменность?}
  G -->|Да| H[Использовать digest]
  G -->|Нет| I[Использовать тег]
  E --> J[Не перезаписывать старые теги]
  F --> J
  H --> K[Документировать digest в релиз-нотах]
  I --> L[Документировать политику тегов]

Краткий словарь (1 строка)

Тег: человекочитаемый ярлык для образа (name:tag).
Digest: SHA-идентификатор набора слоёв образа (sha256:…).
Registry: сервис хранения образов (Docker Hub, Harbor и т.д.).

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

Документация образов содержит схему наименования тегов.
CI генерирует уникальные теги для каждой сборки.
Публичные теги не перезаписываются без регрессионного теста.
Production-распространение использует либо семантику версий, либо digest.

Безопасность и приватность

Теги могут содержать информацию (например, CI id); не включайте секреты в теги.
Для приватных реестров используйте защищённую аутентификацию и TLS.

Важно: изменения тегов локально не отражаются автоматически в реестре — требуется docker push.

Резюме

Теги — удобный механизм для идентификации и управления образами Docker. Они делают взаимодействие с образами понятным для людей, но не заменяют контроль целостности — для этого применяйте digest и подписи. Используйте семантические версии, избегайте перезаписи публичных тегов и документируйте выбранную схему тегирования. Следуя простым правилам и чеклистам, вы минимизируете риск неожиданного поведения пользователей и упростите CI/CD-процессы.

Примечание: при переходе между реестрами всегда помните про hostname в теге и про необходимость логина в целевой реестр.