계층화된 프로비전

Azure 개발자 CLI(azd)는 파일에서 여러 프로비저닝 계층을 정의하는 데 사용할 수 있는 azure.yaml 계층화된 프로비저닝을 지원합니다. 각 계층은 자체 IaC(Infrastructure as Code) 템플릿 집합을 가리킵니다. CLI는 계층을 한 번에 하나씩 프로비전하며, 계층 간의 종속성에 따라 정렬됩니다. 개별 계층을 독립적으로 프로비전하거나 분해할 수도 있습니다.

이 기능은 한 계층의 리소스가 다른 계층의 리소스에 의존하는 복잡한 종속성 시나리오를 해결합니다. IaC를 명령적 후크 스크립트와 혼합하는 대신 계층화된 프로비전은 모든 것을 선언적으로 유지합니다.

비고

계층화된 프로비전은 현재 베타 기능입니다. 버전 관리 전략에 대해 자세히 알아봅니다.

계층화된 프로비저닝을 사용하는 경우

단일 azd provision 배포가 한 단계에서 인프라 요구 사항을 모두 처리할 수 없는 경우 계층화된 프로비저닝을 사용합니다. 다음과 같은 경우 계층화된 프로비저닝을 사용하는 것이 좋습니다.

순환 종속성: 일부 리소스는 프라이빗 엔드포인트를 구성하기 전에 존재해야 하는 가상 네트워크와 같이 먼저 만들어야 하는 다른 리소스를 참조해야 합니다.
기본 인프라는 애플리케이션 인프라와 다릅니다. 공유 네트워킹, 보안 또는 ID 리소스를 애플리케이션별 리소스와 별도로 관리합니다.
독립적인 수명 주기 관리가 필요합니다. 다른 시간에 다른 인프라 구성 요소를 업데이트하고 분해합니다. 예를 들어 네트워킹 계층은 수명이 길지만 애플리케이션 계층은 자주 다시 배포됩니다.
고유한 인프라 그룹이 있는 Monorepo 프로젝트: 단일 리포지토리에는 각각 자체 인프라 템플릿이 있는 여러 독립 서비스(예: 이벤트 허브, 컨테이너 앱 및 함수 앱)가 포함됩니다.

azure.yaml에서 계층 구성

infra 섹션의 azure.yaml 파일에서 레이어를 정의합니다. 각 계층에는 해당 계층의 IaC 템플릿이 포함된 디렉터리를 가리키는 name와 path가 필요합니다.

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 는 해당 역순을 따르므로 종속 계층이 종속 계층 앞에 제거됩니다. azd에서 유추할 수 없는 정렬 순서를 선언하려면 dependsOn 속성을 사용하세요.

계층 속성

각 계층은 다음 속성을 지원합니다.

재산	필수	Description
`name`	예	레이어의 고유한 이름입니다. 명령을 사용하여 특정 계층을 대상으로 지정할 때 이 이름을 사용합니다.
`path`	예	이 계층에 대한 IaC 템플릿을 포함하는 디렉터리의 상대 경로입니다.
`module`	아니오	레이어 디렉터리 내의 모듈 이름입니다. 기본값은 `main`입니다.
`provider`	아니오	이 계층(`bicep` 또는 `terraform`)에 대한 IaC 공급자입니다. 루트를 지정하지 않으면 루트 `infra.provider`로부터 상속됩니다.
`dependsOn`	아니오	이 계층이 의존하는 다른 레이어의 이름입니다. 순서 지정이 중요하지만 `azd` 매개 변수 참조에서 종속성을 유추할 수 없는 경우 이 속성을 사용합니다.

중요합니다

정의infra.layers할 때는 루트 수준에서 섹션(infra, path, module, deploymentStacks)에 다른 속성을 선언할 수 없습니다. 각 계층 내에서 모든 인프라 구성을 지정해야 합니다.

디렉터리 구조

계층화된 프로비저닝을 사용하는 일반적인 프로젝트에는 다음과 같은 디렉터리 구조가 있을 수 있습니다.

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

각 레이어 디렉터리에는 표준 azd 프로젝트의 infra 디렉터리처럼 고유한 전체 IaC 템플릿 집합이 포함되어 있습니다.

계층 프로비전 및 관리

모든 계층을 한 번에 프로비전하거나 이름으로 특정 계층을 대상으로 지정할 수 있습니다. 다음 섹션에서는 계층 상태를 프로비전, 중단 및 새로 고치는 일반적인 명령에 대해 설명합니다.

모든 계층 프로비저닝 수행

인수 없이 실행 azd provision 하여 모든 계층을 프로비전합니다.

azd provision

azd는 각 레이어를 한 번에 하나씩 처리하여, 해당 레이어에 종속된 다른 레이어가 시작되기 전에 먼저 완료되도록 합니다. Bicep 계층 및 사용자 지정 또는 확장 공급자의 경우 azd는 *.bicepparam 및 azure.yaml 파일에 있는 환경 변수와 계층 출력 참조를 바탕으로 종속성을 추론하므로, 실행 순서는 *.parameters.json에 나열된 순서와 다를 수 있습니다. 유추되거나 선언된 종속성이 없는 계층은 나열된 순서로 실행됩니다. 이 프로세스는 해당 리소스를 참조하는 계층이 배포되기 전에 종속 리소스가 존재할 수 있도록 보장합니다.

특정 계층 프로비전

특정 계층만 프로비전하려면 레이어 이름을 인수로 전달합니다.

azd provision networking

이 명령은 계층에 정의된 리소스만 배포합니다 networking . 특정 계층 프로비전은 다음과 같은 경우에 유용합니다.

개발 중에 단일 계층에서 반복적으로 수정합니다.
다른 계층을 다시 배포하지 않고 한 계층을 업데이트해야 합니다.
기존 인프라를 기반으로 새 계층을 설정하고 있습니다.

모든 계층 분해

인수 없이 실행 azd down 하여 모든 계층에서 리소스를 제거합니다. 여러 계층이 있는 azd 경우 프로비저닝 순서의 반대로 처리하므로 종속 리소스는 종속 리소스가 종속된 기본 리소스 전에 제거됩니다.

azd down

특정 계층 분해

특정 계층만 분해하려면 레이어 이름을 인수로 전달합니다.

azd down application

이 명령은 계층에 의해 application 배포된 리소스만 제거하고 다른 계층은 그대로 둡니다.

환경 상태 새로 고침

다음과 같은 --layer플래그를 사용하여 azd env refresh 특정 계층에서 환경 상태를 새로 고칠 수 있습니다.

azd env refresh --layer networking

이 명령은 지정된 계층의 최신 배포에 따라 환경 변수 및 출력을 업데이트합니다.

예: 여러 서비스가 있는 Monorepo

다음 예제에서는 이벤트 허브, 여러 컨테이너를 실행하는 컨테이너 앱 및 Azure Function App을 포함하는 monorepo에 대한 계층화된 프로비저닝을 보여 줍니다.

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

이 구성을 사용하면 다음을 수행할 수 있습니다.

Event Hub 인프라만 프로비전합니다. azd provision eventhub
컨테이너 앱 인프라만 프로비전합니다. azd provision aca
모든 항목을 순서대로 프로비전합니다. azd provision
함수 앱 계층만 분해합니다. 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 네트워킹, ID 및 모니터링과 같은 공유 리소스를 만듭니다. 계층은 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의 종속성 추론에 대해 불투명합니다. 이는 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는 *.parameters.json 및 *.bicepparam 파일의 환경 변수와 레이어 출력 참조에서 종속성을 유추합니다. 유추 또는 선언된 종속성이 없는 계층은 정의한 순서대로 실행됩니다.
기본 제공 비 Bicep 공급자(Terraform, Pulumi, ARM 및 테스트 공급자)는 종속성 유추에 대해 불투명합니다. 이러한 레이어와 관련된 순서를 지정하는 경우 명시적 dependsOn 속성을 사용합니다.
명시적 azd은(는) 순서가 중요한 경우에도 필요하지만, dependsOn이(가) 매개변수 참조로부터 종속성을 유추할 수 없는 경우에 해당합니다. 예를 들어, 한 레이어의 postprovision 후크가 다른 레이어가 사용하는 값을 생성하는 경우에는 *.parameters.json를 사용합니다. 후크가 생성한 값은 *.bicepparam 또는 dependsOn 파일의 출력 참조로 표시되지 않기 때문입니다.
azd는 모든 계층을 해제할 때 프로비저닝된 순서의 역순으로 처리합니다.
- 여러 계층이 동일한 Azure 리소스 그룹에 리소스를 배포하고 기본 리소스 그룹 기반 삭제 동작을 사용하는 경우 azd를 실행할 때 공유 리소스가 삭제될 수 있습니다.
- 계층화된 인프라의 독립적인 추적 및 삭제를 허용하려면 명령을 azd config set alpha.deployment.stacks on실행하여 배포 스택을 사용하도록 설정합니다.
여러 계층을 --preview 한 번에 프로비전할 때는 플래그를 사용할 수 없습니다. 미리 보기 모드에서 사용할 이름을 지정하십시오.
레이어는 IaC 측면에서 독립적으로 작동합니다. 다른 계층의 한 계층에서 출력을 참조하려면 각 계층의 배포 후에 설정하는 환경 변수 azd 를 사용합니다. 또는 *.parameters.json 파일에서 이러한 환경 변수를 *.bicepparam 참조하면 azd 계층 간의 순서를 유추할 수도 있습니다.
모든 표준 azd 프로비저닝 기능(배포 상태 캐싱, 후크, 매개 변수, Bicep 또는 Terraform)은 각 개별 계층 내에서 작동합니다.
- 명령 수준 후크(예: preprovision, postprovision)는 계층당 한 번씩 호출됩니다. 여러 레이어가 정의되면 레이어가 처리되는 순서대로 각 레이어에 대해 후크가 실행됩니다.

다음 단계:

azure.yaml 스키마 참조

피드백

이 페이지가 도움이 되었나요?

2026-08-15 에 마지막으로 업데이트됨