Infrastruktur (Bicep)

Aufbau des Bicep-Deployments: Module und Parameterfluss, Ressourcen, App-Settings der Function App, Managed Identity und Rollen, Alerts, Marketplace-Artefakte.

Themen:

Entwickler

Einstiegspunkt ist bicep/main.bicep. Das Deployment läuft im Scope einer bestehenden Resource Group (Bicep-Default, kein explizites targetScope), im Modus Incremental. Die Parameter aus Anwendersicht sind unter Installation beschrieben; hier geht es um den inneren Aufbau.

Module und Parameterfluss

flowchart TD
    MAIN["main.bicep"]

    SA["storageaccount.bicep"]
    AI["applicationinsights.bicep"]
    ASP["appserviceplan.bicep"]
    SB["servicebus.bicep"]
    ALERT["metricalerts.bicep<br/>if enableAlerts"]
    DASH["dashboard.bicep<br/>if enableGrafanaDashboard"]
    FUNC["azurefunction.bicep"]
    ROLES["roleassignments.bicep<br/>if enableManagedIdentity"]

    MAIN --> SA & AI & ASP & SB & ALERT & DASH & FUNC & ROLES

    SA -->|"id, name"| FUNC
    AI -->|"connectionString, id"| FUNC
    AI -->|"id"| DASH
    ASP -->|"id"| FUNC
    SB -->|"authorizationRuleId, name"| FUNC
    SB -->|"id"| ALERT
    FUNC -->|"principalId"| ROLES
    SA -->|"id"| ROLES
    SB -->|"id"| ROLES

Die Abhängigkeiten ergeben sich über Modul-Outputs, es gibt keine Zyklen. Zusätzlich legt main.bicep ein leeres Tracking-Deployment für die Microsoft-Partner-Attribution an.

Ressourcen

Ressource	Typ	SKU / Eigenschaften	Modul
Storage Account `st<name>`	`Microsoft.Storage/storageAccounts`	StorageV2, Standard_LRS, TLS 1.2	storageaccount
Table Service mit vier Tabellen	`…/tableServices/tables`	`connections`, `jobs`, `mappings`, `watermark`	storageaccount
Application Insights `appi<name>`	`Microsoft.Insights/components`	Retention 90 Tage, klassisch (ohne eigenen Log-Analytics-Workspace)	applicationinsights
App Service Plan `asp<name>`	`Microsoft.Web/serverfarms`	Y1 (`capacity 0`) oder EP1–EP3, Windows	appserviceplan
Service Bus Namespace `sb<name>`	`Microsoft.ServiceBus/namespaces`	Basic	servicebus
Sieben Queues	`…/namespaces/queues`	siehe unten	servicebus
Authorization Rule `sbexportFunction`	`…/authorizationRules`	Send + Listen	servicebus
Function App `func<name>`	`Microsoft.Web/sites`	kind `functionapp`, FTPS only, `netFrameworkVersion 10.0`, System-Identity immer aktiv	azurefunction
Grafana-Dashboard	`Microsoft.Dashboard/dashboards`	eingebettete JSON-Definition	dashboard
Action Group + fünf Metric Alerts	`Microsoft.Insights/actionGroups`, `metricAlerts`	nur mit `enableAlerts`	metricalerts, dlqmetricalert
Rollenzuweisungen	`Microsoft.Authorization/roleAssignments`	nur mit `enableManagedIdentity`	roleassignments

Queues

Alle Queues haben deadLetteringOnMessageExpiration = true, TTL defaultMessageTimeToLive (Default P14D) und lockDuration (Default PT30S).

Queue	Zweck	MaxDeliveryCount
`sbqhighexport`, `sbqexport`, `sbqlowexport`	Verarbeitung nach Priorität	`maxDeliveryCount` (Default 3)
`sbqtransitivehigh`, `sbqtransitivestandart`, `sbqtransitivelow`	Ablage bei Konflikten im Ziel (HTTP 409); kein Trigger	`maxDeliveryCount × 2`
`sbqignored`	Veraltete Nachrichten bei `SkipOutdatedMessages`; kein Trigger	`maxDeliveryCount`

Die Schreibweise standart ist in Code und Bicep konsistent und darf nicht geändert werden, weil bestehende Deployments die Queue unter diesem Namen besitzen.

App-Settings der Function App

Setting	Quelle
`APPLICATIONINSIGHTS_CONNECTION_STRING`	Output des AI-Moduls
`AzureWebJobsStorage` bzw. `AzureWebJobsStorage__accountName`	Key-basiert per `listKeys()` oder identitätsbasiert, je nach `enableManagedIdentity`
`ExportQueueServiceBus` bzw. `ExportQueueServiceBus__fullyQualifiedNamespace`	analog für den Service Bus
`TARGET_BASED_SCALING_ENABLED`	`0`, nur im schlüsselbasierten Modus (ohne `enableManagedIdentity`)
`WEBSITE_CONTENTAZUREFILECONNECTIONSTRING`	immer key-basiert (Content Share)
`FUNCTIONS_EXTENSION_VERSION`, `FUNCTIONS_WORKER_RUNTIME`	`~4`, `dotnet-isolated`
`WEBSITE_RUN_FROM_PACKAGE`	`1`
`GetChangesTimerExpression`	Parameter, Default `/15 * * * *`
`SkipOutdatedMessages`	Parameter, Default `false`
`TELEMETRY_CONTROL`, `TELEMETRY_INFO_SAMPLE_RATE`, `TELEMETRY_DEPENDENCY_SAMPLE_RATE`, `TELEMETRY_DEPENDENCY_SLOW_MS`	Parameter, siehe Logging
`AzureWebJobs.<Name>.Disabled`	aus dem Array `disabledFunctions`

alwaysOn wird nicht gesetzt. Für Premium-Pläne kann das manuell nachgezogen werden.

Managed Identity und Rollen

Die System-Identity der Function App wird immer angelegt. Mit enableManagedIdentity = true entfallen die Schlüssel in den App-Settings, stattdessen weist roleassignments.bicep folgende Rollen zu:

Rolle	Ressource	Grund
Storage Table Data Contributor	Storage Account	Konfigurationstabellen, Durable-Tabellen
Storage Blob Data Owner	Storage Account	Durable-Hub-Blobs
Storage Queue Data Contributor	Storage Account	Durable-Hub-Queues
Azure Service Bus Data Sender	Namespace	Enqueue
Azure Service Bus Data Receiver	Namespace	Dequeue
Azure Service Bus Data Owner	Namespace	Queue-Laufzeitdaten für die MCP-Tools `list_queue_statuses` und `get_queue_status`

SettingsService liefert Connection-Strings tolerant (null statt Exception); StorageService und ServiceBusService bauen ihre Clients aus dem Connection-String, wenn vorhanden, sonst über DefaultAzureCredential.

Alerts

Mit enableAlerts entstehen eine Action Group (E-Mail an notificationEmail), vier DLQ-Alerts auf DeadletteredMessages (Info ≥ 1, Warning > 50, Error > 200, Critical > 500, Schwellen parametrisierbar) und ein Queue-Längen-Alert auf ActiveMessages > 300000. Alle Alerts sind namespace-weit (EntityName = *). Anwendersicht: Monitoring & Alerts.

Netzwerk

Es gibt keine VNet-Integration, keine Private Endpoints und keine IP-Restriktionen. Storage, Service Bus und Function App sind öffentlich erreichbar; Transport ist TLS 1.2 bzw. HTTPS. Netzwerk-Isolation wäre eine Erweiterung des Bicep-Deployments.

Parameterdateien

bicep/params/databridge.sample.bicepparam ist die Vorlage mit allen Parametern. Kundenspezifische Parameterdateien liegen daneben im Repository und werden von cicd/manage/deploy_bicep.yml verwendet. storageKind erlaubt nur StorageV2; ältere Parameterdateien mit Storage schlagen an der Validierung fehl.

Marketplace-Artefakte

bicep/marketplace/mainTemplate.json wird mit GenerateMarketplace.sh aus main.bicep erzeugt und muss nach jeder Bicep-Änderung neu generiert und committet werden.
createUiDefinition.json ist Handarbeit und bildet die Parameter auf den Marketplace-Assistenten ab.

CI/CD

cicd/manage/build_and_deploy_functionapp.yml baut das Zip, setzt die Version (VersionMajor.VersionMinor.yyyy.MMdd) und veröffentlicht ein globales Artefakt.
cicd/manage/deploy_bicep.yml rollt Infrastruktur und Zip je Kunde aus.
cicd/manage/build_docfx_and_publish.yml baut und veröffentlicht diese Dokumentation (der Dateiname stammt noch aus der DocFX-Zeit).