Рекомендации по отстановке тегов и управления версиями для образов контейнеровRecommendations for tagging and versioning container images

При принудительной отправке образов контейнеров в реестр контейнеров и последующем их развертывании необходима стратегия для добавления тегов в образы и управления версиями.When pushing deploying container images to a container registry and then deploying them, you need a strategy for image tagging and versioning. В этой статье обсуждаются два подхода и каждый из них помещается во время жизненного цикла контейнера:This article discusses two approaches and where each fits during the container lifecycle:

  • Стабильные Теги — теги, которые можно повторно использовать, например, чтобы указать основную или дополнительную версию, например миконтаинеримаже: 1.0.Stable tags - Tags that you reuse, for example, to indicate a major or minor version such as mycontainerimage:1.0.
  • Уникальные Теги — отдельный тег для каждого изображения, которое вы отправляете в реестр, например миконтаинеримаже: abc123.Unique tags - A different tag for each image you push to a registry, such as mycontainerimage:abc123.

Стабильные ТегиStable tags

Рекомендация: используйте стабильные теги для обслуживания базовых образов для сборок контейнера.Recommendation: Use stable tags to maintain base images for your container builds. Избегайте развертываний с стабильными тегами, так как эти теги продолжают принимать обновления и могут привести к несогласованности в рабочих средах.Avoid deployments with stable tags, because those tags continue to receive updates and can introduce inconsistencies in production environments.

Стабильные Теги означают, что разработчик или система сборки могут продолжить извлекать конкретный тег, который продолжает получать обновления.Stable tags mean a developer, or a build system, can continue to pull a specific tag, which continues to get updates. Стабильность не означает, что содержимое заморожено.Stable doesn’t mean the contents are frozen. Напротив, stable означает, что образ должен быть стабильным в целях этой версии.Rather, stable implies the image should be stable for the intent of that version. Чтобы остаться "стабильным", он может обслуживаться для применения исправлений безопасности или обновлений платформы.To stay “stable”, it might be serviced to apply security patches or framework updates.

ПримерExample

Группа разработчиков поставляет версию 1,0.A framework team ships version 1.0. Они узнают, что они поставляют обновления, включая незначительные обновления.They know they’ll ship updates, including minor updates. Для поддержки стабильных тегов для заданной основной и дополнительной версий они имеют два набора стабильных тегов.To support stable tags for a given major and minor version, they have two sets of stable tags.

  • :1 — стабильный тег для основной версии.:1 – a stable tag for the major version. 1 представляет самую новую или последнюю версию 1. *.1 represents the “newest” or “latest” 1.* version.
  • :1.0— стабильный тег для версии 1,0, позволяющий разработчику выполнять привязку к обновлениям 1,0, а также не выполнять накат до 1,1 при его освобождении.:1.0- a stable tag for version 1.0, allowing a developer to bind to updates of 1.0, and not be rolled forward to 1.1 when it is released.

Группа также использует :latest тег, который указывает на последний стабильный тег независимо от текущей основной версии.The team also uses the :latest tag, which points to the latest stable tag, no matter what the current major version is.

Если доступны базовые обновления образа или любой тип выпуска обслуживания платформы, образы с стабильными тегами обновляются до последнего дайджеста, представляющего самую последнюю версию стабильного выпуска этой версии.When base image updates are available, or any type of servicing release of the framework, images with the stable tags are updated to the newest digest that represents the most current stable release of that version.

В этом случае постоянно обслуживаются как основной, так и дополнительный Теги.In this case, both the major and minor tags are continually being serviced. В сценарии базового образа это позволяет владельцу образа предоставлять обслуживаемые образы.From a base image scenario, this allows the image owner to provide serviced images.

Удалить манифесты без теговDelete untagged manifests

При обновлении образа с стабильным тегом ранее помеченное изображение не маркируется, что приводит к возникновению потерянного изображения.If an image with a stable tag is updated, the previously tagged image is untagged, resulting in an orphaned image. Манифест предыдущего изображения и данные уникального слоя остаются в реестре.The previous image's manifest and unique layer data remain in the registry. Чтобы сохранить размер реестра, можно периодически удалять манифесты без тегов, полученные из стабильных обновлений образов.To maintain your registry size, you can periodically delete untagged manifests resulting from stable image updates. Например, Автоматическая очистка манифестов без тегов старше заданной длительности или установка политики хранения для манифестов без тегов.For example, auto-purge untagged manifests older than a specified duration, or set a retention policy for untagged manifests.

Уникальные ТегиUnique tags

Рекомендация: Используйте уникальные теги для развертываний, особенно в среде, которая может масштабироваться на нескольких узлах.Recommendation: Use unique tags for deployments, especially in an environment that could scale on multiple nodes. Вам, скорее всего, потребуется преднамеренное развертывание одинаковой версии компонентов.You likely want deliberate deployments of a consistent version of components. Если контейнер перезапускается или Orchestrator масштабирует больше экземпляров, узлы не будут случайно получать более новую версию, несовместимую с другими узлами.If your container restarts or an orchestrator scales out more instances, your hosts won’t accidentally pull a newer version, inconsistent with the other nodes.

Уникальное Добавление тегов означает, что каждое изображение, отправленное в реестр, имеет уникальный тег.Unique tagging simply means that every image pushed to a registry has a unique tag. Теги не используются повторно.Tags are not reused. Существует несколько шаблонов, которые можно использовать для создания уникальных тегов, включая:There are several patterns you can follow to generate unique tags, including:

  • Метка даты и времени . Этот подход довольно распространен, так как вы можете четко определить, когда образ был построен.Date-time stamp - This approach is fairly common, since you can clearly tell when the image was built. Но как снова сопоставить его с системой сборки?But, how to correlate it back to your build system? Нужно ли найти сборку, которая была выполнена одновременно?Do you have to find the build that was completed at the same time? В каком часовом поясе вы используете?What time zone are you in? Откалиброваны ли все системы сборки в формате UTC?Are all your build systems calibrated to UTC?

  • Фиксация git — этот подход работает до начала поддержки базовых обновлений образов.Git commit – This approach works until you start supporting base image updates. Если происходит обновление базового образа, система сборки начинается с той же фиксацией Git, что и в предыдущей сборке.If a base image update happens, your build system kicks off with the same Git commit as the previous build. Однако базовый образ содержит новое содержимое.However, the base image has new content. Как правило, фиксация Git предоставляет частичностабильный тег.In general, a Git commit provides a semi-stable tag.

  • Дайджест манифеста — каждый образ контейнера, отправленный в реестр контейнеров, связан с манифестом, определяемым уникальным хэшем SHA-256 или дайджестом.Manifest digest - Each container image pushed to a container registry is associated with a manifest, identified by a unique SHA-256 hash, or digest. В то время как уникальный дайджест является длинным, сложным для чтения и не связан с средой сборки.While unique, the digest is long, difficult to read, and uncorrelated with your build environment.

  • Идентификатор сборки . Этот параметр может быть лучше, так как он, скорее всего, будет добавочным, и он позволяет сопоставить его с конкретной сборкой, чтобы найти все артефакты и журналы.Build ID - This option may be best since it's likely incremental, and it allows you to correlate back to the specific build to find all the artifacts and logs. Однако, как и в случае с дайджестом манифеста, может быть трудно читать человека.However, like a manifest digest, it might be difficult for a human to read.

    Если в вашей организации есть несколько систем сборки, в этом параметре можно добавить префикс с именем системы <build-system>-<build-id> сборки.If your organization has several build systems, prefixing the tag with the build system name is a variation on this option: <build-system>-<build-id>. Например, можно отличить сборки от системы сборки Jenkins, созданной группой API, и системы сборки Azure Pipelines в веб-группе.For example, you could differentiate builds from the API team’s Jenkins build system and the web team's Azure Pipelines build system.

Заблокировать развернутые Теги изображенийLock deployed image tags

Рекомендуется заблокировать любой развернутый тег Image, задав write-enabled для его атрибута значение false .As a best practice, we recommend that you lock any deployed image tag, by setting its write-enabled attribute to false. Такой подход не позволяет случайно удалить образ из реестра и, возможно, нарушить работу ваших развертываний.This practice prevents you from inadvertently removing an image from the registry and possibly disrupting your deployments. Вы можете включить шаг блокировки в конвейер выпуска.You can include the locking step in your release pipeline.

Блокировка развернутого образа по-прежнему позволяет удалять другие неразвертываемые образы из реестра с помощью функций реестра контейнеров Azure для обслуживания реестра.Locking a deployed image still allows you to remove other, undeployed images from your registry using Azure Container Registry features to maintain your registry. Например, Автоматическая очистка манифестов без тегов или незаблокированных образов старше заданной длительности или установка политики хранения для манифестов без тегов.For example, auto-purge untagged manifests or unlocked images older than a specified duration, or set a retention policy for untagged manifests.

Дальнейшие действияNext steps

Более подробное описание концепций в этой статье см. в записи блога Добавление тегов в теги docker: рекомендации по разметке и управлению версиями образов DOCKER.For a more detailed discussion of the concepts in this article, see the blog post Docker Tagging: Best practices for tagging and versioning docker images.

Чтобы максимально повысить производительность и экономично использовать реестр контейнеров Azure, ознакомьтесь со статьей рекомендации по использованию реестра контейнеров Azure.To help maximize the performance and cost-effective use of your Azure container registry, see Best practices for Azure Container Registry.