Bicep 모듈 만들기 및 사용하기

  • 10분

모듈은 독립적인 Bicep 파일입니다. 일반적으로 함께 배포되는 리소스 집합을 포함합니다. 모듈은 다른 Bicep 템플릿에서 사용할 수 있습니다.

모듈을 사용하여 Bicep 코드를 다시 사용할 수 있으며, Bicep 파일은 각각 특정 작업에 중점을 맞추고 있어 더 읽기 쉽고 이해하기 쉽게 만들 수 있습니다. 그러면 기본 템플릿이 여러 모듈을 함께 구성합니다.

모듈의 이점

장난감 회사에서 많은 개별 Bicep 파일을 사용하여 클라우드 리소스를 프로비저닝했습니다. 시간이 지나면서 관련 템플릿이 크게 증가합니다. 결국 읽고 탐색하기 어렵고 유지하기도 힘든 단일 코드를 가지게 됩니다.

이 접근 방식은 코드를 다른 템플릿에 사용할 때마다 여러 파트를 복제해야만 합니다. 변경 사항이 있는 경우 여러 파일을 검색하고 업데이트해야 합니다.

Bicep 모듈은 코드를 여러 템플릿에서 참조할 수 있는 더 작고 관리하기 쉬운 파일로 분할하여 관련 문제를 해결할 수 있습니다. 모듈은 몇 가지 주요 이점을 제공합니다.

재사용 가능성

모듈을 만들고 나면 여러 개의 Bicep 파일에서 사용할 수 있습니다. 다른 프로젝트 또는 워크로드용으로 만들어진 파일이더라도 마찬가지입니다. 예를 들어 솔루션 하나를 빌드할 때 앱 구성 요소, 데이터베이스 및 네트워크 관련 리소스에 대한 별도의 모듈을 만들 수 있습니다. 그런 다음 유사한 네트워크 요구 사항을 가진 다른 프로젝트 작업을 시작하는 경우 관련 모듈을 다시 사용할 수 있습니다.

애플리케이션, 데이터베이스, 네트워킹의 세 가지 모듈을 참조하는 템플릿을 보여 주는 다이어그램입니다. 그런 다음 네트워킹 모듈은 다른 템플릿에서 재사용됩니다.

팀, 조직 또는 Azure 커뮤니티에서 모듈을 공유할 수도 있습니다. 향후 Microsoft Learn 모듈에서 Bicep 모듈을 공유하는 방법에 대해 자세히 알아봅니다.

캡슐화

모듈은 관련 리소스 정의를 함께 유지하는 데 도움이 됩니다. 예를 들어 Azure Functions 앱을 정의하는 경우 일반적으로 앱을 배포하고, 앱에 대한 호스팅 계획을 배포하며, 앱의 메타데이터용 스토리지 계정을 배포합니다. 이러한 세 구성 요소는 별도로 정의되지만 리소스의 논리적 그룹을 나타내므로 모듈로 정의하는 것이 합리적일 수 있습니다.

이렇게 하면 기본 템플릿은 기능 앱을 배포하는 방식의 세부 사항을 인식할 필요가 없습니다. 이것은 모듈의 역할입니다.

Composability

모듈 집합을 만들고 난 후에 함께 구성할 수 있습니다. 예를 들어 가상 네트워크를 배포하는 모듈과 가상 머신을 배포하는 다른 모듈을 만들 수 있습니다. 각 모듈의 매개 변수와 출력을 정의하여 중요한 정보를 가져와서 다른 정보로 보낼 수 있습니다.

두 모듈을 참조하고 한 모듈에서 다른 모듈의 매개 변수로 출력을 전달하는 템플릿을 보여 주는 다이어그램.

팁

Bicep 모듈을 배포를 지원하기 위해 다양한 방식으로 결합할 수 있는 빌딩 블록으로 생각하면 이해하기 쉽습니다.

기능

때에 따라 특정 기능에 액세스하려면 모듈을 사용해야 할 수 있습니다. 예를 들어 모듈과 루프를 함께 사용하여 여러 리소스 집합을 배포할 수 있습니다. 모듈을 사용하여 단일 배포의 여러 범위에 있는 리소스를 정의할 수도 있습니다.

모듈 만들기

모듈은 기본 Bicep 파일입니다. 다른 Bicep 파일을 만드는 것과 마찬가지입니다.

일반적으로 배포하는 모든 리소스에 대한 모듈을 만드는 것은 좋은 방법이 아닙니다. 일반적으로 훌륭한 Bicep 모듈은 여러 관련 리소스를 정의합니다. 그러나 많은 구성을 포함하는 복잡한 리소스가 있는 경우, 복잡성을 캡슐화하려면 단일 모듈을 만드는 것이 적합할 수 있습니다. 이 접근 방식은 기본 템플릿을 단순하고 깔끔하게 유지합니다.

기존 Bicep 템플릿을 모듈로 분할

큰 Bicep 템플릿을 만든 다음 모듈로 분할하고자 할 수 있습니다. 때로는 큰 Bicep 파일을 분할하는 명확한 방법이 있습니다. 모듈에 확실하게 함께 속하는 리소스 집합이 있을 수 있습니다. 다른 경우에는 모듈로 그룹화해야 하는 리소스를 결정하기가 쉽지 않습니다.

Bicep 시각화 도우미는 전체 Bicep 파일을 큐브 뷰에 배치하는 데 도움이 될 수 있습니다. 시각화 도우미는 Visual Studio Code용 Bicep 확장에 포함되어 있습니다.

시각화 도우미를 보려면 Visual Studio Code Explorer를 열고 Bicep 파일을 길게 선택하거나 마우스 오른쪽 단추를 클릭한 다음 Bicep 시각화 도우미 열기를 선택합니다. 시각화 도우미는 Bicep 파일의 리소스를 그래픽으로 표시합니다. Bicep이 검색하는 종속성을 표시하기 위해 리소스 간에 선을 포함합니다.

시각화 도우미를 사용하면 파일을 분할하는 데 도움이 됩니다. 시각화가 리소스 클러스터를 나타내는지를 살펴봅니다. 해당 클러스터를 모듈로 이동시키는 것이 적합할 수 있습니다.

예를 들어 Bicep 파일에 대해 다음 시각화를 살펴보세요. 두 개의 고유한 리소스 집합이 정의됩니다. 이 집합을 별도의 데이터베이스 및 네트워킹 모듈 그룹으로 묶는 것이 적합할 수 있습니다.

모듈 중첩

모듈은 다른 모듈을 포함할 수 있습니다. 이 중첩 기법을 사용하여 작은 리소스 집합을 배포하는 모듈을 만든 다음, 복잡한 리소스 토폴로지를 정의하는 더 큰 모듈을 구성할 수 있습니다. 템플릿은 해당 조각을 배포 가능한 아티팩트로 결합합니다.

팁

모듈을 여러 레이어로 중첩할 수 있지만 복잡해질 수 있습니다. 오류가 발생하거나 다른 문제가 발생하는 경우 중첩 레이어가 많다면 수정 작업을 수행하는 것이 더 어렵습니다.

복잡한 배포의 경우 때로는 중첩을 사용하여 모든 작업을 수행하는 단일 템플릿을 만드는 대신 여러 템플릿을 배포하는 배포 파이프라인을 만드는 것이 적합합니다. 향후 Microsoft Learn 모듈에서 배포 파이프라인에 대해 자세히 알아보세요.

적절한 파일 이름 선택

각 모듈에 맞는 파일 이름을 사용하도록 하십시오. 파일 이름은 사실상 모듈의 식별자가 됩니다. 파일 이름을 보는 것만으로 해당 모듈의 용도를 이해할 수 있도록 하는 것이 중요합니다.

Bicep 템플릿에서 모듈 사용

다음과 같이 module 키워드를 사용하여 Bicep 템플릿에서 모듈을 사용합니다.

module appModule 'modules/app.bicep' = {
  name: 'myApp'
  params: {
    location: location
    appServiceAppName: appServiceAppName
    environmentType: environmentType
  }
}

모듈 정의는 다음 구성 요소를 포함합니다.

  • module 키워드.
  • 심볼 이름(예: appModule). 이 이름은 모듈을 참조할 때마다 이 Bicep 파일 내에서 사용됩니다. 이 심볼 이름은 Azure에서 표시되지 않습니다.
  • 모듈 경로(예: modules/app.bicep). 이것은 일반적으로 로컬 파일 시스템에 있는 Bicep 파일의 경로입니다. 이후 Microsoft Learn 모듈에서는 고유 모듈 경로 형식이 있는 레지스트리 및 템플릿 사양을 사용하여 모듈을 공유하는 방법에 대해 알아봅니다.

    팁

    JSON ARM(Azure Resource Manager) 템플릿을 모듈로 사용할 수도 있습니다. 이 기능은 Bicep으로 마이그레이션하지 않은 템플릿 집합이 있는 경우에 유용합니다.

  • 배포 이름을 지정하는 name 속성. 배포에 관한 자세한 내용을 다음 섹션에서 설명합니다.
  • 모듈에 필요한 매개 변수의 값을 지정할 수 있는 params 속성. 모듈 매개 변수에 관한 자세한 내용은 다음 단원에서 설명합니다.

모듈 작동 방식

모듈을 사용하기 위해 반드시 모듈의 작동 방식을 이해해야 하는 것은 아니지만 배포 관련 문제를 알아보거나 예기치 않은 동작을 설명하는 데 도움이 될 수 있습니다.

배포

Azure에서 배포는 배포 작업을 나타내는 특수한 리소스입니다. 배포는 Microsoft.Resources/deployments 리소스 유형을 포함하는 Azure 리소스입니다. Bicep 배포를 제출하는 경우 배포 리소스를 만들거나 업데이트합니다. 마찬가지로 Azure Portal에서 리소스를 만들 때 포털은 사용자를 대신하여 배포 리소스를 만듭니다.

그러나 Azure에 대한 모든 변경 사항이 배포를 만들거나 사용하는 것은 아닙니다. 예를 들어 Azure Portal을 사용하여 기존 리소스를 수정하는 경우 일반적으로 변경을 위해 배포를 생성하지 않습니다. Terraform 같은 타사 도구를 사용하여 리소스를 배포하거나 구성하는 경우 배포를 만들지 못할 수 있습니다.

Azure CLI 또는 Azure PowerShell을 사용하여 Bicep 파일을 배포하는 경우 배포 이름을 선택적으로 지정할 수 있습니다. 이름을 지정하지 않으면 Azure CLI 또는 Azure PowerShell이 템플릿의 파일 이름에서 자동으로 배포 이름을 만듭니다. 예를 들어 main.bicep이라는 이름의 파일을 배포하는 경우 기본 배포 이름은 main입니다.

모듈을 사용하는 경우 Bicep은 모든 모듈에 대해 별도의 배포를 만듭니다. 모듈에 대해 지정하는 name 속성은 배포 이름이 됩니다. 모듈이 포함된 Bicep 파일을 배포하면 여러 배포 리소스가 생성됩니다. 하나는 부모 템플릿용이고 다른 하나는 각 모듈용입니다.

예를 들어 main.bicep이라는 Bicep 파일을 만든다고 가정합니다. myApp이라는 모듈을 정의합니다. main.bicep 파일을 배포하면 두 개의 배포가 생성됩니다. 첫 번째 배포 이름은 main이며, 애플리케이션 리소스를 포함한 myApp이라는 또 다른 배포를 만듭니다.

각각 별도의 배포 이름을 가진 두 개의 Bicep 파일을 보여 주는 다이어그램.

배포 리소스의 세부 정보를 나열하고 확인하여 Bicep 배포의 상태를 모니터링하거나 배포 기록을 볼 수 있습니다. 그러나 같은 배포 이름을 사용하는 경우 Azure는 같은 이름을 가진 마지막 배포를 덮어씁니다. 배포 기록을 유지해야 하는 경우 배포마다 고유한 이름을 사용해야 합니다. 이름에 배포 날짜 및 시간을 포함하여 고유한 이름을 만들 수 있습니다.

생성된 JSON ARM 템플릿

Bicep 파일을 배포하면 Bicep은 이를 JSON ARM 템플릿으로 변환합니다. 해당 변환을 트랜스파일링이라고도 합니다. 템플릿에서 사용하는 모듈은 JSON 파일에 포함됩니다. 템플릿에 포함된 모듈 수에 관계없이 단일 JSON 파일만 생성됩니다.

이전 섹션에서 설명한 예제에서 Bicep은 원래 두 개의 Bicep 파일이 있었더라도 단일 JSON 파일을 생성합니다.

단일 JSON 파일로 트랜스파일링된 두 개의 Bicep 파일을 보여 주는 다이어그램.