Plattformkonfiguration¶

Diese Seite richtet sich an das Plattform-Team. Sie beschreibt, wie die Lösung als Code aufgebaut ist, welche Voraussetzungen erfüllt sein müssen und wie die Stufen konfiguriert werden. Das Design steht in der Architektur.

Referenzdesign, dein Deployment kann abweichen

Variablennamen und Standardwerte unten sind die des Lösungscodes. Die pipelines und die tfvars-Dateien eines Deployments liegen in einem Konfigurations-Repository dieses Deployments, das nicht Teil der Lösungsquelle ist.

Repository-Aufbau¶

Die Lösung wird als Terraform-Code-Repository geliefert. Ein Deployment fügt seine eigene Konfiguration (die tfvars-Dateien) und pipelines hinzu.

Pfad	Zweck
`infra/deploy/shared`	Root-Modul der Shared-Stufe: capacities, Custom Role, Auto-Pause
`infra/deploy/workload`	Root-Modul der Workload-Stufe: Gateway, workspaces, Verbindungen, Data Lake
`infra/deploy/governance`	Root-Modul der optionalen Purview-Stufe
`infra/deploy/observability`	Root-Modul der optionalen Grafana-Stufe
`infra/modules/fabric-workspace`	Workspace, Rollenzuweisungen, Private Link, Network-Policy-Skripte, Git, Lakehouses, Warehouses
`infra/modules/fabric-connections`	ADLS-, SQL-, Oracle-Cloud-Storage-Verbindungen, managed private endpoints, ausgehende Verbindungsregeln
`infra/modules/purview`, `infra/modules/grafana`	Module der optionalen Stufen
`docs/`	HLD, ADR und Runbooks der Lösung

Tooling. Terraform >= 1.13, < 2.0. Provider: azurerm (>= 4.0.0, < 5.0), azuread, azapi und der Microsoft-fabric- Provider (>= 1.7.0, < 2.0, im Preview-Modus) für die Workload-Stufe und grafana (>= 3.0.0, < 4.0) für die Observability- Stufe. Der state liegt in einem Azure Storage Account (azurerm-Backend) mit Entra-ID-Authentifizierung. Mehrere Schritte rufen Fabric-REST-APIs über PowerShell-Skripte auf, daher braucht der Agent, der die pipeline ausführt, PowerShell (pwsh) und die Azure CLI mit angemeldeter Sitzung.

Voraussetzungen¶

Manche Schritte lassen sich nicht automatisieren und müssen vor dem ersten Deployment erledigt sein.

Voraussetzung	Detail
Ein spoke pro Umgebung und ein Shared-spoke	Das Spoke canvas liefert VNet, Subnet für private endpoints, Key Vault, Storage Account und Log Analytics (Spoke canvas). Die Workload-Stufe braucht außerdem ein Subnet für das VNet data gateway.
Graph-Berechtigungen für den Service Principal des Shared-spokes	`Application.Read.All`, `Directory.Read.All` und `User.Read.All`. Nötig, um die capacity administrators zu setzen.
Fabric Admin Portal: Netzwerk auf workspace-Ebene	In den Tenant-Einstellungen aktiviert
Fabric Admin Portal: Zugriff für Service Principals	Aktiviert, damit die Deployment-Identität die Fabric-APIs nutzen kann
Fabric Admin Portal: Zugriff für Gastkonten	Aktiviert
Fabric Admin Portal: GitHub-Zugriff	Aktiviert, für workspaces mit Git-Verknüpfung
Fabric Admin Portal: Configure workspace-level outbound network rules	Aktiviert, damit workspace-Admins den Outbound-Schutz nutzen können
Secrets im Key Vault des spokes	Die Client-ID und das Secret des Service Principals für jede ADLS- oder SQL-Verbindung, Benutzername und Passwort für Basic-Verbindungen und Oracle Cloud Storage und für Git ein Personal Access Token in einem Secret namens `GitHub-PAT`
Entra-ID-Gruppen	Eine pro workspace-Rolle, die du nutzen willst, und die Grafana-Gruppen, wenn die Observability-Stufe genutzt wird

Die Quelle listet die vier Fabric-Tenant-Einstellungen als Screenshots. Bestätige die genauen Namen der Einstellungen im Fabric Admin Portal deines Tenants.

Die Deployment-Identität braucht außerdem Rechte auf dem spoke: Sie legt einen Key an und liest Secrets im Key Vault des spokes, weist Rollen auf dem Storage Account zu und legt Ressourcen in der subscription an. Was der Spoke-Service-Principal hat, steht in Spoke canvas.

Variablen, die allen Stufen gemeinsam sind¶

Variable	Hinweise
`location`	`westeurope`, `northeurope`, `swedencentral` oder `uksouth`
`environment`	`development`, `test`, `acceptance`, `production` (und `shared` für die Shared- und Governance-Stufe)
`workload_name`	Höchstens 8 Zeichen
`spoke_config`	Namen der spoke-Ressourcen, auf denen aufgebaut wird (siehe unten)

spoke_config für die Shared-Stufe: subscription_id, resource_group_name, log_analytics_name, key_vault_name, storage_account_name, vnet_name, snet_pe_name. Die Workload-Stufe fügt snet_gateway_name hinzu. Die Governance-Stufe nimmt eine kleinere Menge. Das sind die Namen von Ressourcen, die das Spoke canvas anlegt (Was du bekommst). Die Lösung liest sie mit Data Sources und legt sie nicht an.

Shared-Stufe¶

capacity_administrators = ["<spoke service principal object id>"]

fabric_capacities = {
  development = { sku = "F4" }
  production  = { sku = "F8" }
}

capacity_auto_pause         = { enabled = false }  # see Capacity auto-pause
capacity_operator_group_ids = []

Variable	Zweck
`capacity_administrators`	Principal-IDs, die capacity administrators werden: die spoke-Principals der workloads, die die capacity nutzen, und optional Benutzer
`fabric_capacities`	Map der capacities. Der Key wird Teil des capacity-Namens und ist das, worauf sich die Workload-Stufe bezieht. Mindestens eine capacity. SKU `F2`, `F4`, `F8`, `F16`, `F32`, `F64`, `F128`, `F256`, `F512`, `F1024` oder `F2048`.
`capacity_auto_pause`	Siehe Capacity Auto-Pause
`capacity_operator_group_ids`	Gruppen, die die Rolle Fabric Capacity Operator bekommen

Die Resource Provider Microsoft.Fabric und Microsoft.Logic werden vom Deployment registriert.

Workload-Stufe¶

fabric_capacities = {
  development = { display_name = "<name of the capacity from the shared tier>" }
}

workspaces = {
  engineering = {
    capacity_key                    = "development"
    admins_group_id                 = "<entra group object id>"
    contributors_group_name         = "<entra group display name>"
    viewers_group_id                = "<entra group object id>"
    outbound_network_policy_enabled = true      # outbound protection off, see Workspace network policy

    git_config = {
      owner_name      = "<organisation>"
      repository_name = "<repository>"
      branch_name     = "<branch>"
      directory_name  = "<directory>"           # must exist in the repository
    }

    lakehouses = {
      bronze = { description = "Raw data", enable_schemas = true }
    }
    warehouses = {
      silver = { description = "Business entities", collation_type = "Latin1_General_100_BIN2_UTF8" }
    }

    adls_connections = {
      landing = {
        container_name            = "landing"
        client_id_secret_name     = "<secret name>"
        client_secret_secret_name = "<secret name>"
      }
    }

    workspace_connections = {
      to-reporting = { workspace_key = "reporting" }
    }

    managed_private_endpoints = {
      sql = {
        target_private_link_resource_id = "<resource id>"
        subresource_type                = "<sub-resource>"
      }
    }
  }
}

Einstellung eines workspaces	Hinweise
`capacity_key`	Muss ein Key von `fabric_capacities` sein (wird validiert)
`admins_`, `contributors_`, `members_`, `viewers_`	Jede Rolle hat `_group_id` und `_group_name`. Die ID gewinnt.
`outbound_network_policy_enabled`	Standard `false` (Outbound deny). Siehe Workspace Network Policy.
`git_config`	`github_url` ist standardmäßig `github.com`. Siehe Konnektivität.
`lakehouses`	`description`, `enable_schemas`
`warehouses`	`description`, `collation_type` (zwei erlaubte Werte)
`adls_connections`	Container und die zwei Secret-Namen. Pro Verbindung wird ein Container angelegt.
`sql_connections`	Server, Datenbank, Namen der Secrets für Client-ID und Secret (Service Principal)
`sql_connections_basic`	Server, Datenbank, Namen der Secrets für Benutzername und Passwort
`oracle_cloud_storage_connections`	API-Endpoint, Namen der Secrets für Benutzername und Passwort
`workspace_connections`	Key des Ziel-workspaces (ein workspace desselben Deployments)
`managed_private_endpoints`	Resource-ID des Ziels und der Sub-Resource-Typ
`data_pipelines`	Wird von der Variable akzeptiert, aber vom Root-Modul nicht weitergereicht

Validierungen im Code: Jeder capacity_key muss existieren, Namen von Warehouses und Lakehouses müssen innerhalb eines workspaces und über beide Typen hinweg eindeutig sein, und Collations müssen einer der zwei erlaubten Werte sein. Eine Fabric capacity muss über display_name gefunden werden (ein Data Lookup), die Shared-Stufe muss also zuerst deployt werden.

Was die Workload-Stufe pro Lauf anlegt, steht in der Architektur. Bemerkenswertes Verhalten:

Pro capacity-Key des Deployments wird ein VNet data gateway angelegt (1 Member-Gateway, 30 Minuten Inaktivität bis zum Schlafen), im Gateway-Subnet des spokes. Alle workspaces einer capacity nutzen es.
Der expiration_date des Storage-Account-Keys wird nach dem Anlegen ignoriert, und die Private-DNS-zone-Gruppen von private endpoints werden ignoriert, weil eine policy sie setzt.
Die Schritte für Network Policy und Git führen PowerShell-Skripte als local-exec-Provisioner aus, ausgelöst durch Änderungen ihrer Inputs.

Eine Änderung deployen¶

Änderungen folgen Anfragen und Änderungen. Kurz: Konfiguration bearbeiten, pull request öffnen, den Plan prüfen, über die pipeline deployen. Prüfe im Plan:

nur additive Änderungen, wenn du eine Rollengruppe, Verbindung oder ein Lakehouse hinzufügst,
keinen Austausch einer workspace-Ressource,
die 403-Skips der Netzwerk-Skripte auf kleinen SKUs (Workspace Network Policy).