Integrationsressourcen deployen

Wie ein Workload-Team Integrationsressourcen (Logic Apps, Function Apps, Container Apps, Data Factory) mit den Integrationsmodulen in seinen spoke deployt: die Spoke-Outputs-Datei, die Konfiguration und der wiederverwendbare Deployment- Workflow mit seinen Sicherheitsregeln.

Referenzdesign

Die pipeline im Referenzdesign ist GitHub Actions mit einem wiederverwendbaren Workflow. Deine Plattform nutzt vielleicht anderes Tooling oder andere Namen. Frag dein Plattform-Team nach dem Template, der Runner-Gruppe und dem zu verwendenden Release.

Überblick

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

Schritt 1: Spoke-Outputs holen

Die Module brauchen die Fakten deines spokes: Ressourcengruppe, Netzwerk und Subnetze, Key Vault, Storage Account und Log- Analytics-Workspace. Sie liegen in einer Variablendatei mit einem spoke_config-Objekt, eine Datei pro Umgebung, zum Beispiel config/spoke-outputs-<environment>.tfvars. Sie basiert auf den Outputs des spoke-Deployments, sodass deine Konfiguration zum spoke passt und du keine Werte neu abtippen musst.

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

Die Feldliste steht unter Module. Frag dein Plattform-Team, wie dein spoke diese Datei erzeugt. Bearbeite die Werte nie von Hand, wenn sich der spoke ändert: Nimm die neuen Outputs.

Schritt 2: Konfiguration schreiben

Rufe das Root module auf und fülle die Maps, die du brauchst (logic_apps, function_apps mit service_plans, container_apps_environment, data_factories), siehe Module. Gib jeder Umgebung ihre eigenen Konfigurations- werte über die Variablendateien und halte den Code gleich.

Schritt 3: Review und Plan

Öffne einen pull request und lass ihn prüfen. Starte dann den Deployment-Workflow (Schritt 4) mit ausgeschaltetem Apply: Er führt terraform fmt, init, validate und plan aus und zeigt den Plan. Lies ihn. Du erwartest Ressourcen in deinem spoke, keine Änderungen an Ressourcen, die du nicht angefasst hast, und keine unerwarteten Löschungen.

Schritt 4: wiederverwendbaren Workflow ausführen

Deployments starten nicht automatisch. Eine Person startet den Deployment-Workflow von Hand und wählt die Umgebung und aus, ob angewendet wird.

Das Referenzdesign bietet einen wiederverwendbaren Workflow, sodass jedes Workload-Repository denselben, geprüften Deployment-Weg nutzt. Das Workload-Repository enthält einen kleinen Aufrufer:

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	Erforderlich	Zweck
environment	ja	Wählt dev, tst, acc oder prd und die passende Repository-Umgebung
runner_group	ja	Die selbst gehostete Runner-Gruppe (Runner im Netzwerk)
module_owner, module_repository	ja	Owner und Name des privaten Repositorys, das die Terraform-Module enthält
enable_apply	nein	Standard false. Apply ist nur vom Branch main aus erlaubt.
terraform_version	nein	Version der Terraform CLI. Der wiederverwendbare Workflow hat einen Standard.

Secrets und Berechtigungen:

• Der Aufrufer übergibt die Azure-Anmeldewerte (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID) aus der gewählten Umgebung. Die Anmeldung bei Azure nutzt OpenID Connect (die Berechtigung id-token: write), kein gespeichertes Passwort.
• Eine GitHub-App-Identität (ID und privater Schlüssel) lässt den Workflow die privaten Terraform-Module herunterladen. Konfiguriere die ID als Repository-Variable und den Schlüssel als Repository-Secret.
• Der aufgerufene Workflow kann keine Berechtigungen vergeben, die der Aufrufer zurückgehalten hat, deshalb müssen actions: read, contents: read und id-token: write im Aufrufer stehen. Das aufrufende Repository muss wiederverwendbare Workflows aus dem Repository nutzen dürfen, das sie hostet.

Sicherheitsregeln des Workflows

• Die gewählte Umgebung braucht eine Backend-Datei (config/<environment>.azurerm.tfbackend) und eine Spoke-Outputs-Datei (config/spoke-outputs-<environment>.tfvars) sowie eine vorhandene Repository-Umgebung.
• Format, init, validate und plan laufen immer vor einem Apply.
• Apply ist standardmäßig aus und wird abgelehnt, wenn der Workflow nicht von main läuft.
• Ein Apply auf acc oder prd verlangt außerdem mindestens einen Required Reviewer für diese Umgebung.
• Ein Aufruf deployt eine Umgebung. Promotion und Reihenfolge zwischen Umgebungen liegen bei dir.
• Pinne den Workflow auf einen Release-tag oder Commit, nicht auf einen beweglichen Branch. Dein Plattform-Team veröffentlicht und kündigt Releases an.

Schritt 5: Anwendung deployen

Terraform deployt den leeren Service. Deinen Code deployst du mit deiner eigenen pipeline: Workflows in eine Logic App, Code in eine Function App, Images in die Registry und danach eine neue Revision einer Container App. Die Ressourcen sind nur über private Pfade erreichbar, deshalb muss deine pipeline auf einem Runner im Netzwerk laufen (Build-Agents).

Nach dem Deployment

• Ressourcen können andere Ressourcen im spoke über VNet integration erreichen. Eingehender Zugriff läuft nur über private endpoints.
• Beantrage Firewallregeln für alles außerhalb deines spokes (Anfragen und Änderungen).
• Ändere Terraform-verwaltete Ressourcen nicht im Portal. Das nächste Deployment macht es rückgängig.

Siehe auch

• Module
• Anfragen und Änderungen
• Voraussetzungen