Integratieresources deployen

Hoe een workload team integratieresources (Logic Apps, Function Apps, Container Apps, Data Factory) in zijn spoke deployt met de integratiemodules: het spoke outputs-bestand, de configuratie en de herbruikbare deploymentworkflow met zijn veiligheidsregels.

Referentieontwerp

De pipeline in het referentieontwerp is GitHub Actions met een herbruikbare workflow. Jouw platform kan andere tooling of andere namen gebruiken. Vraag je platformteam om de template, de runner group en de te gebruiken release.

Overzicht

flowchart LR
    a["1. Spoke outputs<br/>one file per environment"] --> b["2. Your configuration<br/>module call + maps"]
    b --> c["3. Review and plan<br/>pull request, plan-only run"]
    c --> d["4. Manual run<br/>reusable workflow: apply"]
    d --> e["5. Deploy your application code"]

Stap 1: haal de spoke outputs op

De modules hebben de gegevens van je spoke nodig: resourcegroep, netwerk en subnets, Key Vault, storage account en Log Analytics workspace. Die staan in een variabelenbestand met één spoke_config-object, één bestand per omgeving, bijvoorbeeld config/spoke-outputs-<environment>.tfvars. Het is gebaseerd op de outputs van de spoke-deployment, zodat je configuratie op één lijn blijft met de spoke en je geen waarden overtypt.

spoke_config = {
  name                         = "<workload>-<environment>"
  subscription_id              = "<subscription-id>"
  resource_group_name          = "<resource-group>"
  location                     = "West Europe"
  tenant_id                    = "<tenant-id>"
  environment                  = "<environment>"
  key_vault_id                 = "<key-vault-resource-id>"
  key_vault_name               = "<key-vault-name>"
  storage_account_id           = "<storage-account-resource-id>"
  storage_account_name         = "<storage-account-name>"
  virtual_network_id           = "<vnet-resource-id>"
  virtual_network_name         = "<vnet-name>"
  subnet_ids                   = { "<subnet-name>" = "<subnet-resource-id>" }
  subnet_names                 = { "<subnet-name>" = "<subnet-name>" }
  log_analytics_workspace_id   = "<workspace-resource-id>"
  log_analytics_workspace_name = "<workspace-name>"
}

De lijst met velden staat op Modules. Vraag je platformteam hoe je spoke dit bestand maakt. Pas de waarden nooit met de hand aan als de spoke verandert: neem de nieuwe outputs over.

Stap 2: schrijf de configuratie

Roep de root module aan en vul de maps die je nodig hebt (logic_apps, function_apps met service_plans, container_apps_environment, data_factories), zie Modules. Geef elke omgeving haar eigen configuratiewaarden via de variabelenbestanden, en houd de code gelijk.

Stap 3: review en plan

Open een pull request en laat die reviewen. Start daarna de deploymentworkflow (stap 4) met apply uitgeschakeld: die draait terraform fmt, init, validate en plan en toont het plan. Lees het. Je verwacht resources in je spoke, geen wijzigingen aan resources die je niet hebt aangeraakt en geen onverwachte deletes.

Stap 4: draai de herbruikbare workflow

Deployments starten niet automatisch. Een persoon start de deploymentworkflow met de hand en kiest de omgeving en of er wordt toegepast.

Het referentieontwerp biedt een herbruikbare workflow, zodat elke workloadrepository hetzelfde, gereviewde deploymentpad gebruikt. De workloadrepository bevat een kleine aanroeper:

name: Terraform deployment

on:
  workflow_dispatch:
    inputs:
      environment:
        description: Environment to plan or deploy
        required: true
        type: choice
        options: [dev, tst, acc, prd]
        default: dev
      enableApply:
        description: Apply the plan
        required: true
        type: boolean
        default: false
      runnerGroup:
        description: Self-hosted runner group
        required: true
        type: string
        default: <runner-group>

permissions:
  actions: read
  contents: read
  id-token: write

jobs:
  deploy:
    uses: <organisation>/<platform-repository>/.github/workflows/terraform-deploy.yml@<release-tag>
    with:
      environment: ${{ inputs.environment }}
      enable_apply: ${{ inputs.enableApply }}
      runner_group: ${{ inputs.runnerGroup }}
      module_owner: <organisation>
      module_repository: <module-repository>
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      MODULE_GITHUB_APP_ID: ${{ vars.<module-app-id-variable> }}
      MODULE_GITHUB_APP_PRIVATE_KEY: ${{ secrets.<module-app-key-secret> }}

Input	Verplicht	Doel
environment	ja	Kiest dev, tst, acc of prd en de bijbehorende repository-omgeving
runner_group	ja	De self-hosted runner group (runners binnen het netwerk)
module_owner, module_repository	ja	Eigenaar en naam van de privé-repository met de Terraform-modules
enable_apply	nee	Standaard false. Apply is alleen toegestaan vanaf de main branch.
terraform_version	nee	Versie van de Terraform CLI. De herbruikbare workflow heeft een standaardwaarde.

Secrets en permissies:

• De aanroeper geeft de Azure-aanmeldwaarden (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID) door uit de gekozen omgeving. Aanmelden bij Azure gebeurt met OpenID Connect (de permissie id-token: write), niet met een opgeslagen wachtwoord.
• Een GitHub App-identity (ID en private key) laat de workflow de privé Terraform-modules downloaden. Configureer de ID als repositoryvariabele en de key als repositorysecret.
• De aangeroepen workflow kan geen permissies verlenen die de aanroeper heeft onthouden, dus actions: read, contents: read en id-token: write moeten in de aanroeper staan. De aanroepende repository moet herbruikbare workflows mogen gebruiken uit de repository die ze host.

Veiligheidsregels van de workflow

• De gekozen omgeving heeft een backendbestand (config/<environment>.azurerm.tfbackend) en een spoke outputs-bestand (config/spoke-outputs-<environment>.tfvars) nodig, plus een bestaande repository-omgeving.
• Format, init, validate en plan draaien altijd vóór een apply.
• Apply staat standaard uit en wordt geweigerd tenzij de workflow vanaf main draait.
• Een apply naar acc of prd vereist daarnaast minimaal één required reviewer op die omgeving.
• Eén aanroep deployt één omgeving. Promotie en volgorde tussen omgevingen zijn aan jou.
• Pin de workflow op een release tag of commit, niet op een bewegende branch. Je platformteam publiceert en kondigt releases aan.

Stap 5: deploy je applicatie

Terraform deployt de lege service. Jij deployt je code met je eigen pipeline: workflows naar een Logic App, code naar een Function App, images naar de registry en daarna een nieuwe revision van een Container App. De resources zijn alleen via private paden bereikbaar, dus je pipeline moet draaien op een runner binnen het netwerk (Build agents).

Na de deployment

• Resources kunnen via VNet integration andere resources in de spoke bereiken. Inkomende toegang loopt alleen via een private endpoint.
• Vraag firewallregels aan voor alles buiten je spoke (Aanvragen en wijzigen).
• Wijzig resources die Terraform beheert niet in de portal. De volgende deployment maakt dat ongedaan.

Gerelateerd

• Modules
• Aanvragen en wijzigen
• Randvoorwaarden