Теги в первую очередь предназначены для управления версиями, как предполагает тег по умолчанию latest. Если вы используете его для других целей без информации о версиях, например, для обозначения среды как my_app:dev и my_app:prod, строгого правила, запрещающего это, нет, но это может вызвать проблемы при развертывании контейнеров.
Представьте, что вы иметь контейнер, определенный в docker-compose.yml, который определяет my_app:prod как изображение. Это нормально, когда вы разрабатываете локально, но при развертывании в производственной среде с помощью Docker Compose или службы оркестрации, такой как Kubernetes, в зависимости от политики контроллер может выбрать повторное использование изображений из своего локального кеша вместо того, чтобы каждый раз извлекать из реестра. Теперь вы только что завершили создание новой версии образа и отправили ее на Docker Hub, чувствуя себя уверенно. Жаль, что он по-прежнему под тем же именем и тегом, поэтому контроллер считает его тем же и использует кэшированный образ, в результате чего развертывается ваша старая версия.
Это могло быть хуже. Не все узлы или кластеры настроены одинаково, некоторые будут извлекать последнюю версию из реестра, а некоторые нет. Ваш рой или развертывание теперь содержит смешанный набор старых и новых версий контейнера, что в лучшем случае приводит к ошибочному c поведению.
Теперь вы знаете лучше и sh ваша новая версия my_app/prod:v2.0 и обновите config. Все контроллеры видят новую версию и раскрывают ее, чтобы использовать для замены и масштабирования контейнеров. Все согласовано.
Простой тег с номером версии может показаться слишком простым, поскольку на практике у вас может быть много свойств, которые вы сочтете полезными для добавления к изображению, чтобы помочь с документацией или запросом. Или вам нужно указать c имя и тег, чтобы вы могли отправить sh определенному облачному провайдеру. К счастью, для этого не нужно жертвовать версией, так как Docker позволяет вам применять столько тегов, сколько вам нужно:
docker build -t my_app:latest -t my_app:v2.0 -t my_app:prod -t cloud_user/app_image_id:v2.0 .