다음을 통해 공유

Bicep를 사용하여 가상 네트워크 리소스 만들기

  • 아티클

많은 Azure 배포에는 네트워킹 리소스를 배포하고 구성해야 합니다. Bicep를 사용하여 Azure 네트워킹 리소스를 정의할 수 있습니다.

가상 네트워크 및 서브넷

Microsoft.Network/virtualNetworks 형식을 사용하여 리소스를 만들어 가상 네트워크를 정의합니다.

서브넷 속성을 사용하여 서브넷 구성

가상 네트워크에는 가상 네트워크 내 IP 주소의 논리 그룹인 서브넷이 포함되어 있습니다. Bicep에서 서브넷을 정의하는 방법은 가상 네트워크 리소스에서 subnets 속성 사용 및 Microsoft.Network/virtualNetworks/subnets 유형의 자식 리소스 만들기의 두 가지가 있습니다.

Warning

서브넷을 자식 리소스로 정의하지 않습니다. 이 접근 방식은 후속 배포 또는 실패한 배포 중에 리소스에 대한 가동 중지 시간이 발생할 수 있습니다.

이 예제와 같은 가상 네트워크 정의 내에서 서브넷을 정의하는 것이 가장 최선입니다.

다음 예제는 더 큰 예제의 일부입니다. 배포할 수 있는 Bicep 파일은 전체 파일을 참조하세요.

param location string = resourceGroup().location

var virtualNetworkName = 'my-vnet'
var subnet1Name = 'Subnet-1'
var subnet2Name = 'Subnet-2'

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: virtualNetworkName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: subnet1Name
        properties: {
          addressPrefix: '10.0.0.0/24'
        }
      }
      {
        name: subnet2Name
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
    ]
  }

  resource subnet1 'subnets' existing = {
    name: subnet1Name
  }

  resource subnet2 'subnets' existing = {
    name: subnet2Name
  }
}

output subnet1ResourceId string = virtualNetwork::subnet1.id
output subnet2ResourceId string = virtualNetwork::subnet2.id

두 방법 모두 서브넷을 정의하고 만들 수 있지만 중요한 차이점이 있습니다. 자식 리소스를 사용하여 서브넷을 정의하는 경우 Bicep 파일이 처음 배포될 때 가상 네트워크가 배포됩니다. 그런 다음 가상 네트워크 배포가 완료되면 각 서브넷이 배포됩니다. 이 차이는 Azure Resource Manager가 각 개별 리소스를 개별적으로 배포하기 때문에 발생합니다.

동일한 Bicep 파일을 다시 배포하면 동일한 배포 시퀀스가 발생합니다. 그러나 subnets 속성이 효과적으로 비어 있기 때문에 가상 네트워크는 구성된 서브넷 없이 배포됩니다. 그런 다음 가상 네트워크가 다시 구성된 후 서브넷 리소스가 다시 배포되어 각 서브넷이 다시 설정됩니다. 일부의 경우 배포 중 이 동작으로 인해 가상 네트워크 내의 리소스 연결이 끊어질 수 있습니다. 다른 경우 Azure에서 가상 네트워크를 수정하지 못하게 하여 배포가 실패합니다.

서브넷 리소스 ID 액세스

서브넷의 리소스 ID를 참조해야 하는 경우가 많습니다. subnets 속성을 사용하여 서브넷을 정의하는 경우 existing키워드를 사용하여 서브넷에 대한 강력한 형식 참조를 얻은 후 서브넷의 id 속성에 액세스할 수도 있습니다.

다음 예제는 더 큰 예제의 일부입니다. 배포할 수 있는 Bicep 파일은 전체 파일을 참조하세요.

param location string = resourceGroup().location

var virtualNetworkName = 'my-vnet'
var subnet1Name = 'Subnet-1'
var subnet2Name = 'Subnet-2'

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: virtualNetworkName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: subnet1Name
        properties: {
          addressPrefix: '10.0.0.0/24'
        }
      }
      {
        name: subnet2Name
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
    ]
  }

  resource subnet1 'subnets' existing = {
    name: subnet1Name
  }

  resource subnet2 'subnets' existing = {
    name: subnet2Name
  }
}

output subnet1ResourceId string = virtualNetwork::subnet1.id
output subnet2ResourceId string = virtualNetwork::subnet2.id

이 예제에서는 existing 키워드를 사용하여 서브넷 리소스에 액세스하기 때문에 전체 서브넷 리소스를 정의하는 대신 이전 섹션에 설명된 위험이 없습니다.

existing 및 scope 키워드를 결합하여 다른 리소스 그룹의 가상 네트워크 또는 서브넷 리소스를 참조할 수도 있습니다.

네트워크 보안 그룹

네트워크 보안 그룹은 서브넷 또는 네트워크 인터페이스에서 트래픽의 인바운드 및 아웃바운드 흐름을 제어하는 규칙을 적용하는 데 자주 사용됩니다. Bicep 파일 내에서 많은 수의 규칙을 정의하고 여러 Bicep 파일에서 규칙을 공유하는 작업은 번거로울 수 있습니다. 복잡하거나 큰 네트워크 보안 그룹으로 작업할 때 공유 변수 파일 패턴을 사용하는 것이 고려됩니다.

프라이빗 엔드포인트

프라이빗 엔드포인트는 승인되어야 합니다. 경우에 따라 승인이 자동으로 수행됩니다. 그러나 다른 시나리오에서는 엔드포인트를 사용하려면 먼저 엔드포인트를 승인해야 합니다.

프라이빗 엔드포인트 승인은 작업이기 때문에 Bicep 코드 내에서 직접 수행할 수 없습니다. 그러나 배포 스크립트를 사용하여 작업을 호출할 수 있습니다. 또는 파이프라인 스크립트와 같이 Bicep 파일 외부에서 작업을 호출할 수 있습니다.