Partager via

Créer des ressources de réseau virtuel à l’aide de Bicep

  • Article

De nombreux déploiements Azure nécessitent des ressources réseau pour être déployées et configurées. Vous pouvez utiliser Bicep pour définir vos ressources réseau Azure.

Des réseaux virtuels et des sous-réseaux

Définissez vos réseaux virtuels en créant une ressource du type Microsoft.Network/virtualNetworks.

Configurer des sous-réseaux à l’aide de la propriété subnets

Les réseaux virtuels contiennent des sous-réseaux, qui sont des groupes logiques d’adresses IP au sein du réseau virtuel. Il y a deux façons de définir des sous-réseaux dans Bicep : en utilisant la propriété subnets sur la ressource de réseau virtuel et en créant une ressource enfant avec le type Microsoft.Network/virtualNetworks/subnets.

Avertissement

Évitez de définir les sous-réseaux comme ressources enfants. Cette approche peut entraîner des temps d’arrêt pour vos ressources pendant les déploiements suivants ou l’échec de déploiements.

Il est préférable de définir vos sous-réseaux au sein de la définition de réseau virtuel, comme dans l’exemple ci-après :

L’exemple suivant fait partie d’un exemple plus développé. Pour découvrir un fichier Bicep que vous pouvez déployer, consultez le fichier complet.

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

Bien que les deux approches vous permettent de définir et de créer vos sous-réseaux, il y a une différence importante. Lorsque vous définissez des sous-réseaux à l’aide des ressources enfants, la première fois que votre fichier Bicep est déployé, le réseau virtuel est déployé. Ensuite, une fois le déploiement du réseau virtuel terminé, chaque sous-réseau est déployé. Cet ordre est le même, car Azure Resource Manager déploie chaque ressource séparément.

Lorsque vous redéployez le même fichier Bicep, la même séquence de déploiement se produit. Toutefois, le réseau virtuel est déployé sans aucun sous-réseau configuré, car la propriété subnets est vide. Ensuite, une fois le réseau virtuel reconfiguré, les ressources de sous-réseau sont redéployées, ce qui rétablit chaque sous-réseau. Dans certains cas, ce comportement entraîne la perte de connectivité des ressources au sein de votre réseau virtuel pendant le déploiement. Dans d’autres situations, Azure vous empêche de modifier le réseau virtuel et votre déploiement échoue.

ID de ressource du sous-réseau d’accès

Vous devez souvent faire référence à l’ID de ressource du sous-réseau. Lorsque vous utilisez la propriété subnets pour définir votre sous-réseau, vous pouvez utiliser le mot clé existing pour obtenir également une référence fortement typée sur le sous-réseau, puis accéder à sa propriété id :

L’exemple suivant fait partie d’un exemple plus développé. Pour découvrir un fichier Bicep que vous pouvez déployer, consultez le fichier complet.

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

Étant donné que cet exemple utilise le mot clé existing pour accéder à la ressource de sous-réseau, au lieu de définir la ressource de sous-réseau complète, les risques décrits dans la section précédente n’y sont pas associés.

Vous pouvez également combiner les mots clés existing et les mots clés scope pour faire référence à un réseau virtuel ou à une ressource de sous-réseau dans un autre groupe de ressources.

Groupes de sécurité réseau

Les groupes de sécurité réseau sont fréquemment utilisés pour appliquer des règles contrôlant le flux de trafic entrant et sortant à partir d’un sous-réseau ou d’une interface réseau. Il peut devenir laborieux de définir un grand nombre de règles dans un fichier Bicep et de partager des règles entre fichiers Bicep. Envisagez d’utiliser le modèle de fichier variable partagé lorsque vous travaillez avec des groupes de sécurité réseau complexes ou de grande taille.

Instances Private Endpoint

Les points de terminaison privés doivent être approuvés. Dans certains cas, l’approbation se produit automatiquement. Mais dans d’autres, vous devez approuver le point de terminaison avant qu’il ne soit utilisable.

L’approbation d’un point de terminaison privé est une opération et donc vous ne pouvez pas l’effectuer directement dans votre code Bicep. Cependant, vous pouvez utiliser un script de déploiement pour appeler l’opération. Vous pouvez également appeler l’opération en dehors de votre fichier Bicep, par exemple dans un script de pipeline.