Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Viele Azure Bereitstellungen erfordern die Bereitstellung und Konfiguration von Netzwerkressourcen. Sie können Bicep verwenden, um Ihre Azure Netzwerkressourcen zu definieren.
Virtuelle Netzwerke und Subnetze
Definieren Sie Ihre virtuellen Netzwerke, indem Sie eine Ressource mit dem Typ Microsoft.Network/virtualNetworks erstellen.
Konfigurieren von Subnetzen mithilfe der Subnetz-Eigenschaft
Virtuelle Netzwerke enthalten Subnetze, bei denen es sich um logische Gruppierungen von IP-Adressen innerhalb des Netzwerks handelt. Subnetze sollten immer als untergeordnete Ressourcen verwaltet werden, und die Eigenschaft Subnets sollte niemals innerhalb der VNET-Ressource definiert werden. Dieser Ansatz gewährleistet einen sicheren und unabhängigen Lebenszyklus für beide Ressourcentypen.
Hinweis
Die Azure Virtual Network-API wird aktualisiert, um Änderungen an virtuellen Netzwerken zuzulassen, ohne dass die Subnetzeigenschaft in PUT-Anforderungen einbezogen werden muss. Zuvor führte das Weglassen der Subnetzeigenschaft zum Löschen vorhandener Subnetze. Wenn die Subnetzeigenschaft nicht in einer PUT-Anforderung enthalten ist, bleiben die vorhandenen Subnetze mit dem neuen Verhalten unverändert. Wenn Sie die Subnetzeigenschaft explizit auf einen leeren Wert festlegen, werden alle vorhandenen Subnetze gelöscht, während bei der Bereitstellung bestimmter Subnetzkonfigurationen Subnetze entsprechend erstellt oder aktualisiert werden. Diese Änderung vereinfacht die Verwaltung virtueller Netzwerke, indem unbeabsichtigte Löschungen von Subnetzen während Updates verhindert werden. Weitere Informationen finden Sie unter Azure Virtual Network unterstützt jetzt Updates ohne Subnetzeigenschaft.
Es empfiehlt sich, Ihre Subnetze als untergeordnete Ressourcen zu definieren, wie im folgenden Beispiel:
param location string = resourceGroup().location
var virtualNetworkName = 'my-vnet'
var subnet1Name = 'Subnet-1'
var subnet2Name = 'Subnet-2'
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2025-01-01' = {
name: virtualNetworkName
location: location
properties: {
addressSpace: {
addressPrefixes: [
'10.0.0.0/16'
]
}
}
resource subnet1 'subnets' = {
name: subnet1Name
properties: {
addressPrefix: '10.0.0.0/24'
} }
resource subnet2 'subnets' = {
name: subnet2Name
properties: {
addressPrefix: '10.0.1.0/24'
}
}
}
output subnet1ResourceId string = virtualNetwork::subnet1.id
output subnet2ResourceId string = virtualNetwork::subnet2.id
Um auf eine verschachtelte Ressource außerhalb der übergeordneten Ressource zu verweisen, muss sie mit dem Namen der enthaltenden Ressource und dem ::-Operator qualifiziert werden, wie im vorhergehenden Beispiel gezeigt.
Netzwerksicherheitsgruppen
Netzwerksicherheitsgruppen werden häufig verwendet, um Regeln zum Steuern des ein- und ausgehenden Datenverkehrsflusses aus einem Subnetz oder einer Netzwerkschnittstelle anzuwenden. Es kann mühsam werden, große Anzahl von Regeln in einer Bicep Datei zu definieren und Regeln für mehrere Bicep Dateien gemeinsam zu verwenden. Erwägen Sie die Verwendung „Datei mit freigegebenen Variablen (Muster)“, wenn Sie mit komplexen oder großen Netzwerksicherheitsgruppen arbeiten.
Private Endpunkte
Private Endpunkte müssen genehmigt werden. In einigen Fällen erfolgt die Genehmigung automatisch. In anderen Szenarien müssen Sie jedoch den Endpunkt genehmigen, bevor er verwendet werden kann.
Die Genehmigung privater Endpunkte ist ein Vorgang, sodass Sie ihn nicht direkt in Ihrem Bicep Code ausführen können. Sie können den Vorgang jedoch mithilfe eines Bereitstellungsskripts aufrufen. Alternativ können Sie den Vorgang außerhalb der Bicep-Datei aufrufen, z. B. in einem Pipelineskript.
Verwandte Ressourcen
- Ressourcendokumentation
- Untergeordnete Ressourcen
- Schnellstartvorlagen