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

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

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

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

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

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

Example

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

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

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

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

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

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

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

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

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

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

• Коммит Git — этот подход работает до тех пор, пока не начинают поддерживать обновление базового образа. Если происходит обновление базового образа, система сборки запускается с той же фиксацией Git, что и предыдущая сборка. Однако базовый образ содержит новое содержимое. Как правило, коммит Git предоставляет полу-стабильный тег.

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

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

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

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

Мы рекомендуем заблокировать любой развернутый тег изображения, задав для его атрибута write-enabled значение false. Эта практика запрещает непреднамеренно удалять образ из реестра и, возможно, нарушать развертывание. Вы можете включить шаг блокировки в конвейер выпуска.

Блокировка развернутого образа по-прежнему позволяет удалять другие неразвернутые образы из реестра с помощью функций Azure Container Registry для управления реестром. Например, автоматическая очистка не помеченных тегами манифестов или образов старше указанной длительности или установка политики хранения для непомеченных тегами манифестов.

Связанный контент

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