Многоуровневое обеспечение

Интерфейс командной строки разработчика Azure (azd) поддерживает многоуровневую подготовку, которую можно использовать для определения нескольких уровней подготовки в azure.yaml файле. Каждый слой указывает на собственный набор шаблонов инфраструктуры в виде кода (IaC). Интерфейс командной строки подготавливает слои по одному за раз, упорядоченные зависимостями между ними. Вы также можете подготовить или разорвать отдельные слои независимо друг от друга.

Эта функция решает сложные сценарии зависимостей, в которых ресурсы в одном слое зависят от ресурсов другого уровня. Вместо смешивания IaC с императивными hook-скриптами многоуровневое создание инфраструктуры поддерживает декларативный подход.

Замечание

В настоящее время многоуровневое предоставление ресурсов является бета-версией функции. Дополнительные сведения о стратегии управления версиями.

Когда следует использовать многоуровневую подготовку

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

• Циклические зависимости. Некоторые ресурсы должны ссылаться на другие ресурсы, которые необходимо создать сначала, например виртуальную сеть, которая должна существовать перед настройкой частной конечной точки.
• Базовая инфраструктура отличается от инфраструктуры приложений: вы управляете общими сетями, безопасностью или ресурсами удостоверений отдельно от ресурсов каждого приложения.
• Требуется независимое управление жизненным циклом: вы обновляете и отключаете различные компоненты инфраструктуры в разное время. Например, сетевой уровень имеет длительное время существования, в то время как прикладной уровень периодически развертывается заново.
• Проекты Monorepo с различными группами инфраструктуры: один репозиторий содержит несколько независимых служб (таких как Концентратор событий, приложение контейнера и приложение-функция), каждый из которых содержит собственные шаблоны инфраструктуры.

Настройка слоев в azure.yaml

Определите слои в разделе infra вашего файла azure.yaml. Для каждого слоя требуется name и path указатель на каталог, содержащий шаблоны IaC для этого слоя.

name: my-app
infra:
  layers:
    - name: networking
      path: ./infra/networking
    - name: application
      path: ./infra/application
services:
  api:
    project: ./src/api
    language: js
    host: containerapp

Это важно

Порядок обработки слоев:azd provision обрабатывает слои на основе их зависимостей. Для слоёв Bicep, а также настраиваемых поставщиков или поставщиков расширений, azd определяет зависимости, сканируя файлы параметров (*.bicepparam и *.parameters.json) на наличие ссылок на переменные среды и выходные значения слоёв, и упорядочивает слои соответствующим образом вместо того, чтобы строго следовать порядку, указанному в azure.yaml. Слои, не имеющие автоматически определённых или объявленных зависимостей, выполняются в том порядке, в котором они перечислены. azd down выполняется в соответствующем обратном порядке, поэтому зависимые слои удаляются раньше слоёв, от которых они зависят. Используйте свойство dependsOn, чтобы задать порядок, который azd не может определить автоматически.

Свойства слоя

Каждый слой поддерживает следующие свойства:

Недвижимость	Обязательно	Description
name	Да	Уникальное имя слоя. Используйте это имя при выборе определенного слоя с помощью команд.
path	Да	Относительный путь к каталогу, содержашем шаблоны IaC для этого слоя.
module	нет	Имя модуля в каталоге слоя. По умолчанию — main.
provider	нет	Поставщик IaC для этого слоя (bicep или terraform). Наследует от корня infra.provider, если не указано.
dependsOn	нет	Имена других слоев, от которые зависит этот слой. Используйте это свойство при упорядочении вопросов, но azd не может определить зависимость от ссылок на параметры.

Это важно

При определении infra.layersнельзя объявлять другие свойства в infra разделе (path, module, ) deploymentStacksна корневом уровне. Необходимо указать всю конфигурацию инфраструктуры в каждом слое.

Структура каталогов

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

my-app/
├── azure.yaml
├── infra/
│   ├── networking/
│   │   └── main.bicep
│   └── application/
│       └── main.bicep
└── src/
    └── api/
        └── ...

Каждый каталог слоев содержит собственный полный набор шаблонов IaC, как и каталог стандартного azd проекта infra .

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

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

Настройка всех слоев

Запустите azd provision без аргументов, чтобы подготовить все уровни:

azd provision

azd обрабатывает слои поочередно, гарантируя, что обработка каждого слоя завершится до начала обработки любого зависящего от него слоя. Для слоёв Bicep и пользовательских или поставщиков расширений azd определяет зависимости на основе ссылок на переменные среды и выходные данные слоёв в файлах *.bicepparam и *.parameters.json, поэтому порядок выполнения может отличаться от порядка, указанного в azure.yaml. Слои, для которых не выведены и не объявлены зависимости, выполняются в указанном порядке. Этот процесс гарантирует, что зависимые ресурсы существуют до развертывания слоев, ссылающихся на них.

Подготовка определенного слоя

Чтобы подготовить только определенный слой, передайте имя слоя в качестве аргумента:

azd provision networking

Эта команда развертывает только те ресурсы, которые определены на уровне networking. Подготовка определенного слоя полезна при следующих случаях:

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

Снос всех слоев

Запустите azd down без аргументов, чтобы удалить ресурсы на всех уровнях. Когда существует несколько слоев, azd обрабатывает их в обратном порядке подготовки, поэтому зависимые ресурсы удаляются раньше, чем базовые ресурсы, от которых они зависят:

azd down

Разрыв определенного слоя

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

azd down application

Эта команда удаляет только ресурсы, развернутые application слоем, оставляя другие слои нетронутыми.

Обновление состояния среды

Состояние среды можно обновить с определенного слоя с помощью флага--layer:azd env refresh

azd env refresh --layer networking

Эта команда обновляет переменные среды и выходные данные на основе последнего развертывания указанного слоя.

Пример: Monorepo с несколькими службами

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

name: logging-app
infra:
  layers:
    - name: eventhub
      path: ./infra/eventhub
    - name: aca
      path: ./infra/aca
    - name: functionapp
      path: ./infra/functionapp
services:
  functionapp:
    resourceName: ${site_name}
    language: dotnet
    project: ./src/function/functionapp.csproj
    host: appservice
    resourceGroup: ${rg_name}

Соответствующая структура каталогов:

logging-app/
├── azure.yaml
├── infra/
│   ├── eventhub/
│   │   └── main.bicep
│   ├── aca/
│   │   └── main.bicep
│   └── functionapp/
│       └── main.bicep
└── src/
    └── function/
        └── functionapp.csproj

С помощью этой конфигурации можно:

1. Подготовьте только инфраструктуру концентратора событий: azd provision eventhub
2. Предоставьте только инфраструктуру приложения-контейнера: azd provision aca
3. Упорядочьте всё: azd provision
4. Удалить только уровень Function App: azd down functionapp

Пример: Базовый и прикладные уровни

Общий шаблон отделяет общую или базовую инфраструктуру от инфраструктуры для каждого приложения:

name: my-app
infra:
  layers:
    - name: base
      path: ./infra/base
    - name: app
      path: ./infra/app
services:
  web:
    project: ./src/web
    language: js
    host: containerapp

Слой base создает общие ресурсы, такие как сеть, удостоверение и мониторинг. Слой app создает ресурсы для конкретных приложений (например, среду приложения контейнера и приложения-контейнеры), ссылающиеся на базовые ресурсы.

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

azd provision base
azd provision app
azd provision app  # re-provision only the app layer after changes

Пример: смешанные поставщики IaC

Каждый слой может использовать различного поставщика IaC. Например, можно использовать Bicep для сети и Terraform для уровня приложений:

name: my-app
infra:
  layers:
    - name: networking
      path: ./infra/networking
      provider: bicep
    - name: application
      path: ./infra/application
      provider: terraform

Встроенные поставщики, отличные от Bicep (Terraform, Pulumi, ARM и тестовый поставщик), непрозрачны для вывода зависимостей, поскольку azd не может анализировать их входные данные на наличие ссылок на другие слои. Используйте явное свойство dependsOn всякий раз, когда важен порядок между этими слоями или между этими слоями и другими слоями:

name: my-app
infra:
  layers:
    - name: networking
      path: ./infra/networking
      provider: bicep
    - name: application
      path: ./infra/application
      provider: terraform
      dependsOn:
        - networking

Соображения и ограничения

• При развертывании всех слоев azd обрабатывает их по одному с учетом их зависимостей. Для слоёв Bicep и пользовательских поставщиков или поставщиков расширений azd определяет зависимости на основе ссылок на переменные среды и ссылок на выходные данные слоёв в файлах *.bicepparam и *.parameters.json. Слои без подразумеваемых или объявленных зависимостей выполняются в том порядке, который вы задаёте.
• Встроенные поставщики, отличные от Bicep (Terraform, Pulumi, ARM и тестовый поставщик), не позволяют автоматически определять зависимости. Используйте явное свойство dependsOn, если важен порядок этих слоев.
• Явное указание dependsOn также требуется, когда важен порядок, но azd не может определить зависимость по ссылкам на параметры. Например, используйте dependsOn, когда хук одного слоя postprovision возвращает значение, которое использует другой слой, поскольку значения, возвращаемые хуком, не отображаются как выходные ссылки в файлах *.bicepparam или *.parameters.json.
• Когда вы удаляете все слои, azd обрабатывает их в порядке, обратном порядку подготовки.
  • Если несколько слоев развертывают ресурсы в одной группе ресурсов Azure и используете поведение удаления на основе группы ресурсов по умолчанию, общие ресурсы могут быть удалены при запуске azd down.
  • Чтобы разрешить независимое отслеживание и удаление многоуровневой инфраструктуры, включите стеки развертывания, выполнив команду azd config set alpha.deployment.stacks on.
• Нельзя использовать флаг --preview, если одновременно происходит подготовка нескольких слоев. <layer> Укажите имя для использования режима предварительного просмотра.
• Слои работают независимо с точки зрения IaC. Чтобы ссылаться на выходные данные из одного слоя в другом слое, используйте переменные среды, которые azd задаются после развертывания каждого слоя. Ссылка на эти переменные среды из *.bicepparam файла или *.parameters.json файла также позволяет azd определить порядок между слоями.
• Все стандартные средства распределения azd (кэширование состояния развертывания, хуки, параметры, Bicep или Terraform) работают на уровне каждого отдельного слоя.
  • Перехватчики уровня команд (например, preprovision, postprovision) вызываются один раз на слой. Когда определены несколько слоёв, перехватчики запускаются для каждого слоя в порядке обработки слоёв.

Дальнейшие шаги

Справочник по схеме azure.yaml

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