Strukturierung von Bicep-Code in Azure-Infrastrukturprojekten

Erfahre, wie Du Bicep-Code in Azure-Infrastrukturprojekten effektiv strukturieren und organisieren kannst, um zwischen verschiedenen Infrastrukturzielen wie Test- und Produktivumgebungen zu unterscheiden.
‍

Im dritten Teil dieser Artikelserie wird auf Best Practices für die Strukturierung von Bicep-Code in Azure-Infrastrukturprojekten eingegangen. Ein effizientes Management der Infrastruktur für verschiedene Umgebungen (z. B. Test und Produktiv) ist entscheidend für eine reibungslose Zusammenarbeit und ein erfolgreiches Projekt. In diesem Artikel werden Ordnerstrukturen und Codebeispiele gezeigt, um diese Strukturierung zu verdeutlichen.
‍

Ordnerstruktur für Azure-Infrastrukturprojekte

Eine mögliche Ordnerstruktur für ein Azure-Infrastrukturprojekt mit Bicep könnte folgendermaßen aussehen:

bashCopy code

      
azure-infrastructure/
├── environments/
│   ├── dev/
│   │   ├── 01_main.bicep
│   ├── test/
│   │   ├── 01_main.bicep
│   └── prod/
│       ├── 01_main.bicep
├── modules/
│   ├── module1/
│   ├── module2/
│   └── ...
└── ...
      
    

‍

Diese Struktur teilt das Projekt in zwei Hauptbereiche auf:

1. Environments: Dieser Ordner enthält Unterordner für jede Umgebung (z. B. dev, test, prod), die jeweils eine Haupt-Bicep-Datei (z. B. 01_main.bicep) enthalten. Diese Haupt-Bicep-Datei ist für die Bereitstellung der Ressourcen in der jeweiligen Umgebung verantwortlich und referenziert wiederverwendbare Module aus dem modules-Ordner.
2. Modules: Hier werden wiederverwendbare Bicep-Module gespeichert, die Ressourcen definieren, die in verschiedenen Umgebungen bereitgestellt werden sollen. Jedes Modul kann als eigenständiger Baustein betrachtet werden, der in verschiedenen Umgebungs-Bicep-Dateien wiederverwendet werden kann.

Umgebungsvariable zur Unterscheidung von Infrastrukturzielen

Um zwischen verschiedenen Infrastrukturzielen wie Test- und Produktivumgebungen zu unterscheiden, können Umgebungsvariablen in den Bicep-Dateien verwendet werden. Zum Beispiel kann eine Variable environment in der Haupt-Bicep-Datei für jede Umgebung definiert werden:

bicepCopy code

      
// 01_main.bicep (dev)
param environment string = 'dev'
      
    

‍

bicepCopy code

      
// 01_main.bicep (dev)
param environment string = 'dev'

// 01_main.bicep (test)
param environment string = 'test'

// 01_main.bicep (prod)
param environment string = 'prod'
			
    

‍

Anschließend kann diese Variable in den Bicep-Dateien verwendet werden, um Ressourcen entsprechend der Umgebung zu konfigurieren. Beispielsweise könnte die environment-Variable verwendet werden, um den Namen einer Storage Account-Ressource zu konfigurieren:

bicepCopy code

       
        // 01_main.bicep
        resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = { 
          name: 'mystorage${environment}'  
          location: 'West Europe'  
          sku: { 
            name: 'Standard_LRS'  
          }  
          kind: 'StorageV2'
        }
      
    

‍

In diesem Beispiel wird der Name der Storage Account-Ressource basierend auf der environment-Variable erstellt, sodass für jede Umgebung (dev, test, prod) ein unterschiedlicher Storage Account erstellt wird.

‍

Verwendung von Modulen in verschiedenen Umgebungen

Bicep-Module können in verschiedenen Umgebungen wiederverwendet werden, indem sie in den Haupt-Bicep-Dateien der jeweiligen Umgebungen referenziert werden. Zum Beispiel könnte ein Modul network.bicep im modules-Ordner erstellt werden, das ein virtuelles Netzwerk und eine Subnetz-Ressource definiert:

bicepCopy code

      
// modules/network.bicep

param environment string
param location string

resource vnet 'Microsoft.Network/virtualNetworks@2020-07-01' = {
  name: 'vnet-${environment}'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
  }
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2020-07-01' = {
  name: 'vnet-${environment}/subnet1'
  properties: {
    addressPrefix: '10.0.1.0/24'
  }
}
      
    

Copy

‍

In der Haupt-Bicep-Datei jeder Umgebung kann das network.bicep-Modul dann wie folgt verwendet werden:

bicepCopy code

      
// 01_main.bicep
module network './modules/network.bicep' = {
  name: 'networkModule'
  params: {
    environment: environment
    location: 'West Europe'
  }
}
      
    

Copy

‍

In diesem Beispiel wird das network.bicep-Modul in der Haupt-Bicep-Datei der jeweiligen Umgebung referenziert und die environment-Variable sowie der Standort als Parameter übergeben.

Zusammenfassend ermöglicht eine gut strukturierte Ordnerstruktur und der Einsatz von Umgebungsvariablen und Modulen in Bicep eine effiziente Verwaltung von Azure-Infrastrukturprojekten über verschiedene Umgebungen hinweg. Die vorgestellten Best Practices und Codebeispiele helfen dabei, die Zusammenarbeit innerhalb von Teams zu verbessern und den Wartungsaufwand zu reduzieren. In den nächsten Artikeln dieser Serie werden weitere fortgeschrittene Bicep-Techniken und Anwendungsfälle vorgestellt. Bleibt dran, um mehr darüber zu erfahren, wie Bicep die Arbeit mit Azure-Ressourcen optimieren und die Produktivität von Entwicklern und IT-Administratoren steigern kann.

Vereinfachte IT Infrastruktur

Bicep

Dominic Böttger

Author

, 

INSPIRATIONLABS