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

4 мин

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

Пути к модулю

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

Ниже приведен пример пути к модулю в частном реестре контейнеров Azure:

Схема, показывющая синтаксис для пути модуля.

Путь содержит четыре сегмента:

Схема. Bicep поддерживает несколько типов модулей, которые здесь называются схемами. При работе с реестрами Bicep используется схема br.
Реестр. Имя реестра, содержащего модуль, который требуется использовать. В приведенном выше примере имя реестра — toycompany.azurecr.io (имя реестра контейнеров).
Идентификатор модуля. Полный путь к модулю в реестре.
Тег. Теги обычно представляют версии модулей, так как для одного модуля может быть опубликовано несколько версий. Дополнительные сведения о тегах и версиях см. в следующем разделе.

При публикации идентификатора собственного модуля используйте понятный идентификатор, указывающий на назначение модуля. При необходимости для разграничения частей имени можно использовать пространства имен, в которых используется косая черта (/). К сожалению, реестр контейнеров Azure и Bicep не поддерживают иерархию. Идентификатор модуля обрабатывается как одно значение.

Теги и версии

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

Рекомендуется тщательно спланировать управление версиями модулей. Необходимо выбрать использование схемы управления версиями или политики управления версиями.

Схемы управления версиями

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

В качестве номеров версий используются основные целые числа. Например, первая версия может называться 1, вторая версия — 2 и так далее. Кроме того, к каждому номеру версии можно добавить префикс, например v1 и v2.
Для обозначения номеров версий можно использовать даты. Например, если вы публикуете первую версию модуля 16 января 2022 года, вы можете назвать версию 2022-01-16 (используя формат гггг-мм-дд). При публикации другой версии 3 марта можно назвать ее 2022-03-03.
Семантическое управление версиями — это система управления версиями, часто используемая в программном обеспечении, где один номер версии состоит из нескольких частей. Каждая часть обозначает разную информацию о характере изменения.

Хотя вы можете использовать любую схему управления версиями, которую вы хотите, рекомендуется выбрать то, что можно сортировать в понятном порядке. Числа и даты часто являются хорошим выбором.

Примечание.

В Реестре контейнеров Azure хранится дата создания каждого тега. Даже если вы не используете управление версиями по дате, по-прежнему можно видеть эту информацию.

Политика управления версиями

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

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

Ниже приведена политика управления версиями, которая является эффективной.

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

Совет

Представьте себя пользователем своего модуля и подумайте о том, чего бы вы ожидали от его использования. Если кто-нибудь использует ваш модуль несколько раз и получит один результат, а затем использует его снова после исправления и получит другой результат, он, вероятно, будет удивлен. Старайтесь не создавать неожиданные ситуации для пользователей.

Публикация модели

При создании модуля Bicep, к которому требуется предоставить общий доступ, файл Bicep создается как стандартный. Затем вы публикуете файл в реестре с помощью команды bicep publish. При публикации необходимо указать путь к модулю, в котором будет сохранен модуль:

az bicep publish \
   --file module.bicep \
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

bicep publish module.bicep `
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

Операция публикации выполняет те же шаги проверки, которые осуществляются при сборке или развертывании файла Bicep. Эти настройки включают:

проверка отсутствия синтаксических ошибок в коде;
проверка того, что указанные определения ресурсов допустимы;
запуск анализатора кода Bicep для проверки прохождения кодом ряда проверок качества.