Delen via

Virtuele netwerkresources maken met bicep

  • Artikel

Voor veel Azure-implementaties moeten netwerkresources worden geïmplementeerd en geconfigureerd. U kunt Bicep gebruiken om uw Azure-netwerkresources te definiëren.

Virtuele netwerken en subnetten

Definieer uw virtuele netwerken door een resource te maken met het type Microsoft.Network/virtualNetworks.

Subnetten configureren met behulp van de eigenschap subnetten

Virtuele netwerken bevatten subnetten. Dit zijn logische groepen IP-adressen binnen het virtuele netwerk. Er zijn twee manieren om subnetten in Bicep te definiëren: met behulp van de subnets eigenschap in de virtuele netwerkresource en door een onderliggende resource met het type Microsoft.Network/virtualNetworks/subnetste maken.

Waarschuwing

Vermijd het definiëren van subnetten als onderliggende resources. Deze aanpak kan leiden tot downtime voor uw resources tijdens volgende implementaties of mislukte implementaties.

U kunt het beste uw subnetten definiëren binnen de definitie van het virtuele netwerk, zoals in dit voorbeeld:

Het volgende voorbeeld maakt deel uit van een groter voorbeeld. Zie het volledige bestand voor een Bicep-bestand dat u kunt implementeren.

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

Hoewel u met beide methoden subnetten kunt definiëren en maken, is er een belangrijk verschil. Wanneer u subnetten definieert met behulp van onderliggende resources, wordt het virtuele netwerk geïmplementeerd wanneer uw Bicep-bestand voor de eerste keer wordt geïmplementeerd. Nadat de implementatie van het virtuele netwerk is voltooid, wordt elk subnet geïmplementeerd. Deze volgorde treedt op omdat Azure Resource Manager elke afzonderlijke resource afzonderlijk implementeert.

Wanneer u hetzelfde Bicep-bestand opnieuw implementeert, vindt dezelfde implementatievolgorde plaats. Het virtuele netwerk wordt echter geïmplementeerd zonder dat er subnetten zijn geconfigureerd, omdat de subnets eigenschap in feite leeg is. Nadat het virtuele netwerk opnieuw is geconfigureerd, worden de subnetresources opnieuw geïmplementeerd, waardoor elk subnet opnieuw tot stand wordt gebracht. In sommige situaties zorgt dit gedrag ervoor dat de resources in uw virtuele netwerk de verbinding verliezen tijdens de implementatie. In andere situaties voorkomt Azure dat u het virtuele netwerk wijzigt en mislukt de implementatie.

Toegang tot subnetresource-id's

U moet vaak verwijzen naar de resource-id van een subnet. Wanneer u de subnets eigenschap gebruikt om uw subnet te definiëren, kunt u het existing trefwoord gebruiken om ook een sterk getypte verwijzing naar het subnet te verkrijgen en vervolgens toegang te krijgen tot de eigenschap van id het subnet:

Het volgende voorbeeld maakt deel uit van een groter voorbeeld. Zie het volledige bestand voor een Bicep-bestand dat u kunt implementeren.

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

Omdat in dit voorbeeld het existing trefwoord wordt gebruikt om toegang te krijgen tot de subnetresource, heeft deze niet de risico's die in de vorige sectie zijn beschreven, in plaats van de volledige subnetresource te definiëren.

U kunt de existing trefwoorden en scope ook combineren om te verwijzen naar een virtueel netwerk of subnetresource in een andere resourcegroep.

Netwerkbeveiligingsgroepen

Netwerkbeveiligingsgroepen worden vaak gebruikt om regels toe te passen die de inkomende en uitgaande stroom van verkeer van een subnet of netwerkinterface beheren. Het kan lastig worden om grote aantallen regels in een Bicep-bestand te definiëren en regels te delen tussen meerdere Bicep-bestanden. Overweeg het bestandspatroon Gedeelde variabele te gebruiken wanneer u met complexe of grote netwerkbeveiligingsgroepen werkt.

Privé-eindpunten

Privé-eindpunten moeten worden goedgekeurd. In sommige situaties vindt goedkeuring automatisch plaats. Maar in andere scenario's moet u het eindpunt goedkeuren voordat het kan worden gebruikt.

Goedkeuring van een privé-eindpunt is een bewerking, dus u kunt deze niet rechtstreeks in uw Bicep-code uitvoeren. U kunt echter een implementatiescript gebruiken om de bewerking aan te roepen. U kunt de bewerking ook buiten uw Bicep-bestand aanroepen, zoals in een pijplijnscript.