Группируйте связанные ресурсы с помощью модулей

  • 6 мин

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

ИТ-менеджер видит, что ваш код Bicep становится более сложным и имеет все большее количество определенных ресурсов, поэтому он спросил, можете ли вы сделать код более модульным. Вы можете создавать отдельные файлы Bicep, называемые модулями, для различных частей вашего развертывания. Основной шаблон Bicep может ссылаться на эти модули. Незаметно для развертывания модули преобразуются в единый шаблон JSON.

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

Кроме того, часто необходимо выдавать выходные данные из модулей и шаблонов Bicep. Выходные данные — это способ для вашего кода Bicep отправлять данные обратно тому, кто или что бы то ни было, запустило развертывание. Давайте сначала посмотрим на результаты.

Примечание.

Команды в этом уроке демонстрируют основные понятия. На этом этапе не выполняйте команды. Вскоре вы поупражняетесь с полученными знаниями.

Выходные данные

Шаблоны Bicep могут быть развернуты вручную человеком или каким-то автоматическим процессом выпуска. В любом случае, обычно есть некоторые данные из шаблона, которые нужно отправить обратно пользователю или объекту, выполняющему развертывание шаблона.

Вот несколько примеров сценариев, в которых вам может потребоваться получить информацию из развертывания шаблона:

  • Вы создаете шаблон Bicep, который развертывает виртуальную машину, и вам нужно получить общедоступный IP-адрес, чтобы подключиться к машине по SSH.
  • Вы создаете шаблон Bicep, который принимает набор параметров, таких как имя среды и имя приложения. Шаблон использует выражение для имени развернутого приложения службы приложение Azure. Необходимо вывести имя приложения, развернутое шаблоном, чтобы его можно было использовать в конвейере развертывания для публикации двоичных файлов приложения.

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

output appServiceAppName string = appServiceAppName

Определение вывода включает в себя несколько ключевых частей:

  • Ключевое слово output сообщает Bicep, что вы определяете выход.
  • appServiceAppName — это имя выходных данных. Когда кто-то успешно развертывает шаблон, выходные значения будут включать указанное вами имя, чтобы пользователь мог получить доступ к ожидаемым значениям.
  • string — выходной тип. Выходы на Bicep поддерживают те же типы, что и параметры.
  • Значение должно быть указано для каждого выхода. В отличие от параметров, выходы всегда должны иметь значения. Выходные значения могут быть выражениями, ссылками на параметры либо переменными или свойствами ресурсов, развернутых в файле.

Совет

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

Вот еще один пример выходных данных. Для этого будет установлено значение полного доменного имени (FQDN) ресурса общедоступного IP-адреса.

output ipFqdn string = publicIPAddress.properties.dnsSettings.fqdn

Совет

Попробуйте использовать свойства ресурса в качестве выходных данных, а не делать предположения о том, как будут вести себя ресурсы. Например, если нужно иметь выходные данные для URL-адреса приложения Служба приложений, используйте свойство приложения defaultHostName вместо создания строки для URL-адреса самостоятельно. Иногда эти предположения не являются допустимыми в разных средах или ресурсы меняют способ работы, поэтому безопаснее, чтобы ресурс сообщал вам свои собственные свойства.

Внимание

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

Определите модуль

Модули Bicep позволяют организовать и повторно использовать код Bicep, создавая меньшие единицы, которые можно объединить в шаблон. Любой шаблон Bicep может использоваться как модуль другого шаблона. В этом модуле обучения вы создали шаблоны Bicep. Это означает, что вы уже создали файлы, которые можно использовать как модули Bicep!

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

Diagram that shows a template for solution A referencing three modules: application, database, and networking. The networking module is then reused in another template for solution B.

Если вы хотите, чтобы шаблон содержал ссылку на файл модуля, используйте ключевое слово module. Определение модуля похоже на объявление ресурса, но вместо включения типа ресурса и версии API вы используете имя файла модуля:

module myModule 'modules/mymodule.bicep' = {
  name: 'MyModule'
  params: {
    location: location
  }
}

Давайте внимательно рассмотрим некоторые ключевые части этого определения модуля:

  • Ключевое слово module сообщает Bicep, что вы собираетесь использовать другой файл Bicep в качестве модуля.
  • Как и ресурсы, модули нуждаются в символьном имени , например myModule. Вы используете символическое имя, когда обращаетесь к выходным данным модуля в других частях шаблона.
  • modules/mymodule.bicep — это путь к файлу модуля относительно файла шаблона. Помните, что файл модуля — это просто обычный файл Bicep.
  • Как и ресурсы, name свойство является обязательным. Azure использует имя модуля, так как оно создает отдельное развертывание для каждого модуля в файле шаблона. У этих развертываний есть имена, по которым можно их идентифицировать.
  • Вы можете указать любые параметры модуля с помощью ключевого слова params. Когда вы устанавливаете значения каждого параметра в шаблоне, вы можете использовать выражения, параметры шаблона, переменные, свойства ресурсов, развернутых в шаблоне, и выходные данные из других модулей. Bicep автоматически поймет зависимости между ресурсами.

Модули и выходные данные

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

Создавайте свои модули

Хороший модуль Bicep следует некоторым ключевым принципам:

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

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

  • У модуля должны быть понятные параметры и понятные выходные данные. Рассмотрим назначение модуля. Подумайте о том, должен ли модуль управлять значениями параметров или должен ли родительский шаблон обработать это, а затем передать одно значение в модуль. Точно так же подумайте о выходных данных, которые должен возвращать модуль, и убедитесь, что они полезны для шаблонов, которые будут использовать этот модуль.

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

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