Platformconfiguratie¶

Deze pagina is voor het platformteam. Ze beschrijft hoe de oplossing als code is opgebouwd, welke vereisten aanwezig moeten zijn en hoe de lagen worden geconfigureerd. Voor het ontwerp, zie Architectuur.

Referentieontwerp, jouw deployment kan afwijken

Variabelenamen en standaardwaarden hieronder zijn die van de code van de oplossing. De pipelines en de tfvars-bestanden van een deployment staan in een configuratierepository van die deployment, die geen deel uitmaakt van de bron van de oplossing.

Opbouw van de repository¶

De oplossing wordt geleverd als een Terraform-coderepository. Een deployment voegt zijn eigen configuratie (de tfvars-bestanden) en pipelines toe.

Pad	Doel
`infra/deploy/shared`	Root module van de gedeelde laag: capacities, custom role, auto-pause
`infra/deploy/workload`	Root module van de workloadlaag: gateway, workspaces, connections, data lake
`infra/deploy/governance`	Root module van de optionele Purview-laag
`infra/deploy/observability`	Root module van de optionele Grafana-laag
`infra/modules/fabric-workspace`	Workspace, roltoewijzingen, private link, scripts voor de network policy, Git, Lakehouses, Warehouses
`infra/modules/fabric-connections`	ADLS-, SQL-, Oracle Cloud Storage-connections, managed private endpoints, outbound connectieregels
`infra/modules/purview`, `infra/modules/grafana`	Modules van de optionele lagen
`docs/`	HLD, ADR en runbooks van de oplossing

Tooling. Terraform >= 1.13, < 2.0. Providers: azurerm (>= 4.0.0, < 5.0), azuread, azapi en de Microsoft fabric provider (>= 1.7.0, < 2.0, in preview) voor de workloadlaag, en grafana (>= 3.0.0, < 4.0) voor de observability- laag. De state staat in een Azure storage account (azurerm backend) met Entra ID-authenticatie. Verschillende stappen roepen Fabric REST API's aan via PowerShell-scripts, dus de agent die de pipeline draait heeft PowerShell (pwsh) en de Azure CLI met een aangemelde sessie nodig.

Vereisten¶

Sommige stappen kunnen niet worden geautomatiseerd en moeten vóór de eerste deployment worden gedaan.

Vereiste	Detail
Een spoke per omgeving en één gedeelde spoke	De spoke canvas levert het VNet, het private endpoint-subnet, Key Vault, storage account en Log Analytics (Spoke canvas). De workloadlaag heeft ook een subnet voor de VNet data gateway nodig.
Graph-rechten voor de service principal van de gedeelde spoke	`Application.Read.All`, `Directory.Read.All` en `User.Read.All`. Nodig om de capacity administrators in te stellen.
Fabric admin portal: netwerken op workspaceniveau	Ingeschakeld in de tenant settings
Fabric admin portal: toegang voor service principals	Ingeschakeld, zodat de deployment identity de Fabric API's kan gebruiken
Fabric admin portal: toegang voor gastaccounts	Ingeschakeld
Fabric admin portal: GitHub-toegang	Ingeschakeld, voor workspaces met een Git-koppeling
Fabric admin portal: Configure workspace-level outbound network rules	Ingeschakeld, zodat workspace-admins outbound protection kunnen gebruiken
Secrets in de Key Vault van de spoke	De client-ID en het secret van de service principal voor elke ADLS- of SQL-connection, gebruikersnaam en wachtwoord voor basic connections en Oracle Cloud Storage, en voor Git een personal access token in een secret met de naam `GitHub-PAT`
Entra ID-groepen	Eén per workspacerol die je wilt gebruiken, en de Grafana-groepen als de observability-laag wordt gebruikt

De bron toont de vier Fabric tenant settings als screenshots. Controleer de exacte namen van de instellingen in het Fabric admin portal van je tenant.

De deployment identity heeft ook rechten op de spoke nodig: hij maakt een key aan en leest secrets in de Key Vault van de spoke, wijst rollen toe op het storage account en maakt resources aan in de subscription. Wat de service principal van de spoke heeft, staat beschreven in Spoke canvas.

Variabelen die voor alle lagen gelden¶

Variabele	Opmerkingen
`location`	`westeurope`, `northeurope`, `swedencentral` of `uksouth`
`environment`	`development`, `test`, `acceptance`, `production` (en `shared` voor de gedeelde en governancelagen)
`workload_name`	Maximaal 8 tekens
`spoke_config`	Namen van de spoke-resources om op voort te bouwen (zie hieronder)

spoke_config voor de gedeelde laag: subscription_id, resource_group_name, log_analytics_name, key_vault_name, storage_account_name, vnet_name, snet_pe_name. De workloadlaag voegt snet_gateway_name toe. De governancelaag gebruikt een kleinere set. Dit zijn de namen van resources die de spoke canvas aanmaakt (Wat je krijgt). De oplossing leest ze met data sources en maakt ze niet aan.

Gedeelde laag¶

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 = []

Variabele	Doel
`capacity_administrators`	Principal-ID's die capacity administrator worden: de spoke-principals van de workloads die de capacity gebruiken, en optioneel gebruikers
`fabric_capacities`	Map van capacities. De key wordt onderdeel van de capacitynaam en is waar de workloadlaag naar verwijst. Minstens één capacity. SKU `F2`, `F4`, `F8`, `F16`, `F32`, `F64`, `F128`, `F256`, `F512`, `F1024` of `F2048`.
`capacity_auto_pause`	Zie Capacity auto-pause
`capacity_operator_group_ids`	Groepen die de rol Fabric Capacity Operator krijgen

De resource providers Microsoft.Fabric en Microsoft.Logic worden door de deployment geregistreerd.

Workloadlaag¶

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>"
      }
    }
  }
}

Instelling van een workspace	Opmerkingen
`capacity_key`	Moet een key van `fabric_capacities` zijn (gevalideerd)
`admins_`, `contributors_`, `members_`, `viewers_`	Elke rol heeft `_group_id` en `_group_name`. De ID wint.
`outbound_network_policy_enabled`	Standaard `false` (outbound deny). Zie Workspace network policy.
`git_config`	`github_url` is standaard `github.com`. Zie Connectiviteit.
`lakehouses`	`description`, `enable_schemas`
`warehouses`	`description`, `collation_type` (twee toegestane waarden)
`adls_connections`	Container en de twee namen van secrets. Per connection wordt een container aangemaakt.
`sql_connections`	Server, database, namen van de secrets voor client-ID en secret (service principal)
`sql_connections_basic`	Server, database, namen van de secrets voor gebruikersnaam en wachtwoord
`oracle_cloud_storage_connections`	API-endpoint, namen van de secrets voor gebruikersnaam en wachtwoord
`workspace_connections`	Key van de doelworkspace (een workspace van dezelfde deployment)
`managed_private_endpoints`	Resource-ID van het doel en het sub-resourcetype
`data_pipelines`	Wordt door de variabele geaccepteerd, maar niet doorgegeven door de root module

Validaties in de code: elke capacity_key moet bestaan, namen van Warehouses en Lakehouses moeten uniek zijn binnen een workspace en over beide typen heen, en collations moeten een van de twee toegestane waarden zijn. Een Fabric capacity moet worden gevonden via display_name (een data lookup), dus de gedeelde laag moet eerst worden gedeployd.

Wat de workloadlaag per run aanmaakt, staat in Architectuur. Opmerkelijk gedrag:

Er wordt één VNet data gateway aangemaakt voor elke capacity key van de deployment (1 member gateway, 30 minuten inactiviteit voor hij slaapt), in het gateway-subnet van de spoke. Alle workspaces van een capacity gebruiken hem.
De key expiration_date van het storage account wordt na het aanmaken genegeerd, en de private DNS zone groups van private endpoints worden genegeerd omdat policy ze instelt.
De stappen voor de network policy en Git draaien PowerShell-scripts als local-exec provisioners, getriggerd door wijzigingen in hun inputs.

Een wijziging deployen¶

Wijzigingen volgen Aanvragen en wijzigen. Kort gezegd: pas de configuratie aan, open een pull request, review het plan, deploy via de pipeline. Controleer het plan op:

alleen additieve wijzigingen bij het toevoegen van een rolgroep, connection of Lakehouse,
geen vervanging van een workspaceresource,
de 403-skips van de netwerkscripts op kleine SKU's (Workspace network policy).