Manuelle Bereitstellungen sind inkonsistent? Stelle ein Speicherkonto mit Bicep bereit

Ein Speicherkonto einmal im Azure-Portal zu erstellen, funktioniert. Werden dieselben Portalauswahlen für DEV, TEST und PROD wiederholt, können jedoch unterschiedliche Sicherheitseinstellungen, Tags, SKUs oder Regionen entstehen.

CloudTrips benötigt eine überprüfte Definition, die Azure konsistent anwenden kann. In diesem Trip verwendest du Bicep, um:

• ein sicheres DEV-Speicherkonto zu definieren
• die Azure-Änderung vor der Ausführung anzuzeigen
• die Ressource bereitzustellen
• das Ergebnis zu überprüfen
• durch eine zweite Vorschau die Wiederholbarkeit zu bestätigen

Azure-Zielbereich vorbereiten

Öffne Azure Cloud Shell oder ein Terminal mit Azure CLI. Melde dich an und wähle das CloudTrips-DEV-Abonnement:

az login

az account set \
  --subscription "<Name oder ID des CloudTrips-DEV-Abonnements>"

Bestätige das ausgewählte Abonnement:

az account show \
  --query "{name:name,id:id}" \
  --output table

Erstelle eine Ressourcengruppe für die Übung:

az group create \
  --name rg-cloudtrips-bicep-dev-weu \
  --location westeurope \
  --tags Application=CloudTrips Environment=DEV ManagedBy=Bicep

Die Ressourcengruppe ist der Bereitstellungsbereich. Bicep erstellt darin das Speicherkonto.

Gewünschte Ressource definieren

Erstelle main.bicep mit folgendem Inhalt:

targetScope = 'resourceGroup'

@description('CloudTrips deployment environment.')
param environment string = 'dev'

@description('Azure region for the storage account.')
param location string = resourceGroup().location

var storageAccountName = 'stct${environment}${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2025-06-01' = {
  name: storageAccountName
  location: location
  tags: {
    Application: 'CloudTrips'
    Environment: toUpper(environment)
    ManagedBy: 'Bicep'
  }
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: false
    minimumTlsVersion: 'TLS1_2'
    supportsHttpsTrafficOnly: true
  }
}

output storageAccountName string = storageAccount.name
output storageAccountId string = storageAccount.id

Dies ist der gewünschte Azure-Zustand. Der resource-Block legt fest, was existieren muss. uniqueString() erzeugt für dieselbe Ressourcengruppe denselben Suffix. Wiederholte Bereitstellungen richten sich daher an dasselbe global eindeutige Speicherkonto.

Bereitstellung anzeigen

Führe eine What-if-Operation aus:

az deployment group what-if \
  --resource-group rg-cloudtrips-bicep-dev-weu \
  --template-file main.bicep \
  --parameters environment=dev

Fahre erst fort, wenn die Ausgabe ein Speicherkonto mit dem Änderungstyp Create zeigt. What-if lässt Azure Resource Manager die Bicep-Datei auswerten, ohne die Ressource zu erstellen.

Wenn Azure Policy die geplante Konfiguration ablehnt, korrigiere die Deklaration vor der Bereitstellung. Umgehe die Richtlinie nicht für diese Übung.

Speicherkonto bereitstellen

Stelle dieselbe Datei bereit:

az deployment group create \
  --name deploy-cloudtrips-storage-dev \
  --resource-group rg-cloudtrips-bicep-dev-weu \
  --template-file main.bicep \
  --parameters environment=dev \
  --query "properties.{state:provisioningState,outputs:outputs}" \
  --output yaml

Bestätige den Bereitstellungsstatus Succeeded. Kopiere die Ausgabe storageAccountName; Bicep hat den Namen berechnet und aus der Bereitstellung zurückgegeben.

Ergebnis überprüfen

Setze den Ausgabewert ein und prüfe die bereitgestellte Konfiguration:

storage_account_name="<storageAccountName-Ausgabe>"

az storage account show \
  --resource-group rg-cloudtrips-bicep-dev-weu \
  --name "$storage_account_name" \
  --query "{name:name,location:primaryLocation,httpsOnly:enableHttpsTrafficOnly,minimumTlsVersion:minimumTlsVersion,allowBlobPublicAccess:allowBlobPublicAccess,tags:tags}" \
  --output yaml

Überprüfe:

httpsOnly: true
minimumTlsVersion: TLS1_2
allowBlobPublicAccess: false
tags.Application: CloudTrips
tags.Environment: DEV
tags.ManagedBy: Bicep

Diese Einstellungen wurden nicht manuell ausgewählt. Sie stammen aus der überprüften Bicep-Definition.

Wiederholbarkeit bestätigen

Führe dieselbe Vorschau erneut aus:

az deployment group what-if \
  --resource-group rg-cloudtrips-bicep-dev-weu \
  --template-file main.bicep \
  --parameters environment=dev

Azure sollte keine beabsichtigten Ressourcenänderungen melden. Das Template wird weiterhin in denselben Speicherkontonamen aufgelöst, und die bereitgestellten Eigenschaften entsprechen bereits der Deklaration.

Das ist der praktische Nutzen von Bicep: Die Datei dokumentiert das erforderliche Ergebnis, Azure Resource Manager wendet es an, und dieselbe Definition kann überprüft und wiederholt werden, anstatt die Ressource aus dem Gedächtnis neu aufzubauen.