Рекомендации по использованию тегов и управлению версиями образов контейнеров

  • Статья

Чтобы отправлять образы контейнеров в реестр и развертывать их, нужно разработать стратегию по использованию тегов и управлению версиями. В этой статье описаны два вида тегов для разных этапов жизненного цикла контейнера:

  • Стабильные теги можно использовать повторно, например, чтобы указывать основную или дополнительную версию mycontainerimage:1.0.
  • Уникальные теги разные для каждого образа, который вы отправляете в реестр, например mycontainerimage:abc123.

Стабильные теги

Рекомендация: используйте стабильные теги для обслуживания базовых образов сборок контейнера. Мы не рекомендуем проводить развертывание со стабильными тегами, потому что они продолжают получать обновления и могут привести к несогласованности в рабочих средах.

Разработчики и системы сборки могут работать со стабильными тегами, которые продолжают получать обновления. Стабильность в этом случае не означает, что содержимое всегда остается одинаковым. Такие теги указывают на стабильность определенной версии образа, которая обеспечивается благодаря обновлениям систем безопасности и платформы.

Пример

Разработчики выпускают версию 1.0. В будущем для этой версии будут созданы обновления, в том числе незначительные. Существует две группы стабильных тегов для основного и вспомогательного номера версии.

  • :1 — стабильный тег для основного номера версии. 1 — для новой или последней версии 1.*.
  • :1.0 — стабильный тег для версии 1.0. С его помощью разработчики привязывают обновления к этой версии и не допускают наката до версии 1.1.

Когда появляются обновления для базового образа или выпуск для обслуживания платформы, образы со стабильными тегами обновляются до актуального стабильного выпуска версии.

В этом случае постоянно обслуживаются как основной, так и дополнительный номер версии. Такой подход позволяет владельцу предоставлять обслуживаемые базовые образы.

Удаление манифестов без тегов

Во время обновления образа со стабильным тегом тег из прежнего образа удаляется. Манифест предыдущего образа и данные уникального слоя остаются в реестре. Чтобы сохранить размер реестра, можно периодически удалять манифесты без тегов, полученные после обновления образов. Для этого включите автоматическую очистку манифестов без тегов, которые хранятся больше указанного срока, или установите для них политику хранения.

Уникальные теги

Рекомендация: используйте уникальные теги для развертываний, особенно в среде, которая может масштабироваться на нескольких узлах. Скорее всего, вам понадобится проводить принудительное развертывание актуальной версии компонентов. Во время перезагрузки контейнера или масштабировании оркестратора для нескольких экземпляров узлы не получают новую версию, которая не соответствует другим узлам.

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

  • Метка даты и времени. Этот популярный подход показывает, когда был создан образ. Но как снова сопоставить его с системой сборки? Искать ту, что была выполнена в это время? В каком часовом поясе вы находитесь? Откалиброваны ли все системы сборки по времени в формате UTC?

  • Фиксация в Git. Этот подход работает, пока вы не начали обновлять базовые образы. В это случае ваша система сборки отправляет ту же фиксацию Git, что и для прежней сборки. Но ведь у базового образа новое содержимое. Фиксация Git обычно используется для частично стабильных тегов.

  • Хэш манифеста. Все образы контейнера, отправляемые в реестр, связаны с манифестом, который обладает уникальным хэшем SHA-256. Этот хэш очень длинный, его трудно читать, а также он не связан со средой сборки.

  • Идентификатор сборки. Это самый удобный подход, потому что идентификатор его можно сопоставлять с определенной сборкой, чтобы находить артефакты и журналы. Но его трудно читать, как и хэш манифеста.

    Если у вашей организации несколько систем сборки, вы можете указывать префикс для тега с ее названием: <build-system>-<build-id>. Так вы сможете отличать сборки системы Jenkins команды API от сборок Azure Pipelines.

Теги для блокировки развернутых образов

Рекомендуется блокировать теги развернутых образов, установив для их атрибута write-enabled значение false. Так вы не сможете случайно удалить образ из реестра и создать проблемы с развертываниями. Процесс блокировки можно включить в конвейер выпуска.

Если вы заблокируете развернутый образ, то все равно сможете удалять неразвернутые образы из реестра с помощью Реестра контейнеров Azure. Для этого включите автоматическую очистку манифестов без тегов или незаблокированных образов, которые хранятся больше указанного срока, или установите для них политику хранения.

Следующие шаги

Подробную информацию по этой теме можно узнать в записи блога Теги в докере: рекомендации по использованию тегов и управлению версиями образов.

Чтобы максимально повысить производительность и снизить расходы на Реестр контейнеров Azure, изучите статью Рекомендации по работе с Реестром контейнеров Azure.