Erstellen Sie virtuelle Netzwerkressourcen mit Bicep
Bei vielen Azure-Bereitstellungen müssen Netzwerkressourcen bereitgestellt und konfiguriert werden. 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 Gruppen von IP-Adressen innerhalb des virtuellen Netzwerks handelt. Es gibt zwei Möglichkeiten zum Definieren von Subnetzen in Bicep: mithilfe der subnets
Eigenschaft der virtuellen Netzwerkressource und durch Erstellen einer untergeordneten Ressource mit dem Typ Microsoft.Network/virtualNetworks/subnets
.
Warnung
Vermeiden Sie die Definition von Subnetzen als untergeordnete Ressourcen. Dieser Ansatz kann zu Ausfallzeiten für Ihre Ressourcen während nachfolgender Bereitstellungen oder fehlgeschlagenen Bereitstellungen führen.
Es ist am besten, die Subnetze innerhalb der Definition des virtuellen Netzwerks zu definieren, wie im folgenden Beispiel:
Das folgende Beispiel ist Teil eines umfassenderen Beispiels. Eine Bicep-Datei, die Sie bereitstellen können, finden Sie in der vollständigen Datei.
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
Obwohl beide Ansätze es Ihnen ermöglichen, Subnetze zu definieren und zu erstellen, gibt es einen wichtigen Unterschied. Wenn Sie Subnetze mithilfe von untergeordneten Ressourcen definieren, wird bei der ersten Bereitstellung Ihrer Bicep-Datei das virtuelle Netzwerk bereitgestellt. Nach Abschluss der Bereitstellung des virtuellen Netzwerks wird jedes Subnetz bereitgestellt. Diese Reihenfolge tritt auf, weil Azure Resource Manager jede einzelne Ressource separat bereitstellt.
Wenn Sie dieselbe Bicep-Datei erneut bereitstellen, erfolgt die gleiche Bereitstellungssequenz. Das virtuelle Netzwerk wird jedoch ohne dafür konfigurierte Subnetze bereitgestellt, da die Eigenschaft subnets
praktisch leer ist. Anschließend werden die Subnetzressourcen nach der Neukonfiguration des virtuellen Netzwerks neu konfiguriert, wodurch die einzelnen Subnetze neu erstellt werden. In einigen Fällen führt dieses Verhalten dazu, dass die Ressourcen in Ihrem virtuellen Netzwerk während der Bereitstellung nicht mehr verbunden sind. In anderen Fällen verhindert Azure, dass Sie das virtuelle Netzwerk ändern, und die Bereitstellung schlägt fehl.
Zugreifen auf Subnetz-Ressourcen-IDs
Häufig müssen Sie sich auf die Ressourcen-ID eines Subnetzes beziehen. Wenn Sie das Subnetz mit der Eigenschaft subnets
definieren, können Sie mit dem existing
Schlüsselwort auch einen stark typisierten Verweis auf das Subnetz abrufen und dann auf die Eigenschaft id
des Subnetzes zugreifen:
Das folgende Beispiel ist Teil eines umfassenderen Beispiels. Eine Bicep-Datei, die Sie bereitstellen können, finden Sie in der vollständigen Datei.
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
Da in diesem Beispiel das Schlüsselwort existing
für den Zugriff auf die Subnetzressource verwendet wird, anstatt die vollständige Subnetzressource zu definieren, treffen die im vorherigen Abschnitt aufgeführten Risiken nicht zu.
Sie können auch die Schlüsselwörter existing
und scope
kombinieren, um auf ein virtuelles Netzwerk oder eine Subnetzressource in einer anderen Ressourcengruppe zu verweisen.
Netzwerksicherheitsgruppen
Netzwerksicherheitsgruppen werden häufig verwendet, um Regeln zum Steuern des ein- und ausgehenden Datenverkehrsflusses aus einem Subnetz oder einer Netzwerkschnittstelle anzuwenden. Es kann umständlich werden, eine 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, daher können Sie ihn nicht direkt in Ihrem Bicep-Code ausführen. Sie können den Vorgang jedoch mithilfe eines Bereitstellungsskripts aufrufen. Alternativ können Sie den Vorgang außerhalb Ihrer Bicep-Datei aufrufen, z. B. in einem Pipelineskript.
Zugehörige Ressourcen
- Ressourcendokumentation
- Untergeordnete Ressourcen
- Schnellstartvorlagen