Integrationsmodule: Logic App, Function App, Container App, Data Factory¶

Die Integrationsmodule sind Terraform-Module, die einen Integrationsservice in deinem spoke deployen, bereits mit dem spoke verbunden (Netzwerk, Key Vault, Storage Account, Log Analytics) und auf einer sicheren Baseline aufgebaut. Du wählst einige Einstellungen, das Modul erledigt den Rest. Diese Seite beschreibt das Modulset, was jedes Modul deployt, seine Defaults und wie ein Workload- Team es verwendet. Wie du das Deployment ausführst: Integrationsressourcen deployen.

Optionales Angebot, Referenzdesign

Welche Module und Versionen deine Plattform anbietet, hängt von deiner Plattform ab. Die Defaults auf dieser Seite stammen aus dem Terraform der Module. Dein Plattform-Team kann sie geändert oder eine andere Version gepinnt haben.

Das Modulset¶

Ein Root-Modul nimmt pro Service-Typ eine Map entgegen. Du füllst nur, was du brauchst. Eine leere Map deployt nichts.

Service	Input-Map	Deployt (Zusammenfassung)
Logic App	`logic_apps`	Eine Standard Logic App auf einem gemeinsamen Workflow-Plan, nur Private Endpoint, eingebaute Authentifizierung, eigenes Storage Account
Function App	`function_apps` (und `service_plans`)	Eine Linux Function App, VNet-Integration, Private Endpoint, identitätsbasierter Zugriff auf das Storage Account des spokes
Container App	`container_apps_environment`	Ein Container Apps environment (intern), Container Apps und Jobs in T-Shirt-Größen
Data Factory	`data_factories`	Eine Data Factory mit Managed Virtual Network, Private Endpoint und Linked Services zum Key Vault und Storage des spokes

Zusammen bilden sie die Zutat Module der Plattform (Servicebeschreibung).

flowchart LR
    cfg["Your configuration<br/>logic_apps, function_apps,<br/>container_apps_environment, data_factories"] --> root["Root module"]
    out["spoke_config<br/>(spoke outputs)"] --> root
    root --> la["Logic App"]
    root --> fa["Function App + service plans"]
    root --> ca["Container Apps environment,<br/>apps and jobs"]
    root --> adf["Data Factory"]
    la & fa & ca & adf -->|"read"| spoke["Spoke: VNet and subnets,<br/>Key Vault, storage account,<br/>Log Analytics"]

Wie ein Modul deinen spoke verwendet¶

Jedes Modul braucht die Beschreibung deines spokes in einer Variable, spoke_config. Sie wird aus einer Datei mit den Outputs des spokes gefüllt (siehe Integrationsressourcen deployen).

Feld von `spoke_config`	Bedeutung
`name`, `environment`, `location`, `tags`	Name, Umgebung, Region und Tags des spokes. Module erben Tags. Das Container-App-Modul verlangt, dass die Umgebung `nonprod` oder `prod` ist (siehe unten).
`subscription_id`, `tenant_id`, `resource_group_name`	Wo der spoke liegt
`virtual_network_id`, `virtual_network_name`	Das Netzwerk des spokes
`subnet_ids`, `subnet_names`	Maps der Subnetze des spokes. Module wählen Subnetze per Name (zum Beispiel für Private Endpoints und für die ausgehende Integration).
`key_vault_id`, `key_vault_name`	Das Key Vault des spokes
`storage_account_id`, `storage_account_name`	Das Storage Account des spokes
`log_analytics_workspace_id`, `log_analytics_workspace_name`	Wohin die Logs gehen

Die Module lesen diese Ressourcen (Key Vault, Storage Account, Log-Analytics-Workspace) als bestehende Ressourcen. Sie erstellen sie nicht. Ein Modul, das ein benanntes Subnet nicht findet, schlägt fehl, prüfe also zuerst die Subnet-Namen in deinem spoke.

Private Endpoints: Die Module verwalten die privaten DNS Zone Groups ihrer Private Endpoints nicht. Die Namensauflösung für die Endpoints wird voraussichtlich von der Plattform geregelt, zum Beispiel per Azure Policy. Frag dein Plattform-Team.

Logic App¶

Eine Standard Logic App mit gehärteter Baseline.

logic_apps = {
  orders = {
    subnets = {
      private_endpoint_subnet_name   = "<private-endpoint-subnet>"
      logic_app_outbound_subnet_name = "<logic-app-outbound-subnet>"
    }
    authentication_settings = {
      client_id = "<entra-app-client-id>"
    }
    environment_variables = {}
  }
}

Einstellung	Default und Wirkung
Plan	Ein gemeinsamer Workflow Service Plan für alle Logic Apps des spokes, Windows, vom Root-Modul aus `default_logic_apps_plan` erstellt: Größe `S` (WS1; außerdem `M` = WS2, `L` = WS3), mindestens 2 Instanzen, Zone Balancing an. Plan-Name `asp-<spoke name>-logicapps` in einer Resource group `rg-<spoke name>-logicapps`, sofern du keine Namen setzt.
Resource group	Standardmäßig wird pro Logic App eine Gruppe erstellt (`create_resource_group`, true). Du kannst eine bestehende angeben.
Netzwerk	Öffentlicher Netzwerkzugriff aus. Private Endpoint im von dir benannten Subnet, ausgehender Verkehr über das Outbound-Subnet (VNet-Integration). `vnet_private_ports_count` reserviert private Ports.
Authentifizierung	Immer an. Nicht authentifizierte Anfragen erhalten ein 401. Erlaubte Audiences, Gruppen und Identities werden in `authentication_settings` gesetzt. `/runtime/*` ist ausgenommen, damit die Run History Inputs und Outputs zeigen kann.
Storage	Ein eigenes Storage Account für die Logic App, für Isolation bei Performance und Sicherheit, mit einer Firewall, die standardmäßig verweigert und nur das Outbound-Subnet erlaubt
Identity	System-assigned und eine User-assigned Managed Identity
Härtung	Nur HTTPS, FTPS deaktiviert, Basic Authentication für FTP und Web Deploy deaktiviert, HTTP/2 an
Monitoring	Application Insights, verbunden mit dem Log-Analytics-Workspace des spokes, Diagnoseeinstellungen für die App und ihr Storage
Health Check	Ein Workflow namens `HealthCheck` mit Trigger `Request` wird für den Health Check verwendet. Beide Namen können geändert werden (Namen mit höchstens 12 bzw. 7 Zeichen).

Ressourcennamen: logic-<name>, appi-<name>, pe-logic-<name>, id-<name>.

Die Workflows deployen. Das Modul-Repository enthält zwei kleine Bausteine für eine pipeline: Der eine verpackt das Logic- App-Projekt (er verwendet parameters.azure.json als parameters.json, wenn vorhanden, und lässt local.settings.json weg), der andere deployt das Paket in die Logic-App-Standard-Ressource. Dein Plattform-Team gibt dir das pipeline-Template.

Function App¶

Eine Function App auf einem Service Plan, den du definierst, mit identitätsbasiertem Zugriff auf das Storage Account des spokes.

service_plans = {
  shared-linux = {
    name     = "plan-<name>"
    sku_name = "EP1"
    os_type  = "Linux"
    tags     = {}
  }
}

function_apps = {
  processor = {
    name                      = "func-<name>"
    service_plan_key          = "shared-linux"
    virtual_network_subnet_id = "<integration-subnet-id>"
    app_settings              = { "ENV" = "dev" }
    private_endpoints = {
      default = { subnet_resource_id = "<private-endpoint-subnet-id>" }
    }
  }
}

Einstellung	Default und Wirkung
Plan	Wähle mit `service_plan_key` (ein Plan aus `service_plans`) oder `service_plan_resource_id` (ein bestehender Plan). Mehrere Apps können sich einen Plan teilen.
Flex Consumption (FC1)	Setze `sku_name = "FC1"` am Plan und `function_app_uses_fc1 = true` an der App, mit `fc1_runtime_name` und `fc1_runtime_version` (Defaults `node` und `20`). Eine App pro FC1-Plan, nur Linux.
Netzwerk	VNet-Integration über `virtual_network_subnet_id`, und ein Private Endpoint ist erforderlich: Gib immer mindestens einen Eintrag in `private_endpoints` an.
Storage	Keine Keys. Die App verwendet ihre System-assigned Identity auf dem Storage Account des spokes: Das Modul gibt ihr Storage Blob Data Owner und Storage Blob Data Contributor auf diesem Account, erstellt einen privaten Blob-Container mit dem Namen der App und setzt die identitätsbasierten Einstellungen `AzureWebJobsStorage__...`. Setze `AzureWebJobsStorage` nicht selbst. Das Modul entfernt es.
Identity	System-assigned ist immer an. Über `managed_identities` kannst du User-assigned Identities hinzufügen.
Site-Einstellungen	Sichere Defaults in `site_config`: nur FTPS, mindestens TLS 1.3 (1.2 für die SCM-Site), Always On, 32-Bit-Worker aus. Authentication v2 und IP-Einschränkungen sind verfügbar.
Application Insights	Optional, über `application_insights`
Resource group	Standardmäßig die Resource group des spokes. Eine eigene Gruppe mit `create_resource_group_for_function_apps` und `function_apps_resource_group_name`.

Linux im Root-Modul

Das Modul-Repository enthält ein Linux- und ein Windows-Function-App-Modul. Der Input des Root-Moduls akzeptiert die Felder des Linux-Moduls. Kläre mit deinem Plattform-Team, bevor du eine Windows Function App planst.

Container App¶

Ein Container Apps environment in deinem spoke mit Container Apps und Container Jobs.

container_apps_environment = {
  main = {
    resource_name                = "<name>"
    environment                  = "nonprod"
    vnet_integration_subnet_name = "<container-apps-subnet>"
    container_registry_server    = "<registry>.azurecr.io"
    container_registry_identity  = { name = "<pull-identity>", resource_group_name = "<resource-group>" }
    container_apps = [
      { name = "api", image = "<registry>.azurecr.io/<repository>/api", size = "S", min_replicas = 1, max_replicas = 3 }
    ]
    scheduled_container_jobs = [
      { name = "nightly", image = "<registry>.azurecr.io/<repository>/job", schedule_cron = "0 2 * * *" }
    ]
    storage_queues = [{ name = "work", alert_on_message_added_to_queue = false }]
  }
}

Einstellung	Default und Wirkung
Environment	Name `cae-<name>-<np or p>-<region code>`. `environment` muss `nonprod` oder `prod` sein. Wenn du es nicht setzt, wird die Umgebung aus `spoke_config` verwendet, die dann eine der beiden sein muss. Das Environment ist intern (interner Load Balancer) im von dir benannten Subnet, auf dem Consumption-Workload-Profil. Logs gehen an den Log-Analytics-Workspace des spokes.
Images	Du gibst pro App oder Job den Image-Namen an. Ein gemeinsamer Tag `container_image_tag` (Default `latest`) wird angehängt. Der Pull erfolgt mit einer User-assigned Managed Identity, die du benennst (`container_registry_identity`), auf der Registry `container_registry_server`. Hier kommt die gemeinsame Container Registry zum Einsatz (Shared Services).
Größen	`S` 0,25 vCPU, 0,5 GiB. `M` 0,5 vCPU, 1 GiB. `L` 1 vCPU, 2 GiB. `XL` 2 vCPU, 4 GiB. `XXL` 4 vCPU, 8 GiB. Default `S`.
Container Apps	Pro App: Größe, Health Check, `min_replicas` (Default 0), `max_replicas` (Default 1), Umgebungsvariablen, Ingress (Default an), optional Dapr
Container Jobs	Drei Arten: manual, event (startet, wenn eine Nachricht in einer Azure-Storage-Queue des Storage Accounts des spokes eintrifft, jeweils eine Ausführung, Polling alle 30 Sekunden) und scheduled (Cron-Ausdruck). Defaults pro Job: Timeout 600 Sekunden, 3 Wiederholungen, Parallelität 1.
Storage-Helfer	`storage_containers`, `storage_queues` und `storage_tables` erstellen diese Elemente im Storage Account des spokes
Secrets	Eine User-assigned Identity des Environments erhält Key Vault Certificate User auf dem Key Vault des spokes. Der Connection String von Application Insights wird als Secret im Key Vault des spokes abgelegt.
Application Insights	Eines pro Environment, 30 Tage Aufbewahrung
Alerts	Optional, über `monitoring_config`: fehlgeschlagene Requests, Exceptions und Nachrichten, die zu gewählten Queues hinzugefügt werden. Benachrichtigungen per E-Mail und/oder in einen Teams-Kanal (über dessen E-Mail-Adresse) werden pro Environment eingeschaltet. Alle sind standardmäßig aus.

Namen: ca-<...> für Apps, cj-<...> für manuelle Jobs, cj-event-<...> für Event-Jobs und cj-cron-<...> für geplante Jobs.

Data Factory¶

Eine Data Factory für Batch-ETL, mit einem privaten Netzwerkmodell.

data_factories = {
  main = {
    resource_name                = "<name>"
    private_endpoint_subnet_name = "<private-endpoint-subnet>"
    team_members                 = ["<alert-recipient>"]
    enable_alert_failed_pipeline = true
  }
}

Einstellung	Default und Wirkung
Netzwerk	Öffentlicher Netzwerkzugriff aus, Managed Virtual Network an, ein Private Endpoint im von dir benannten Subnet
Integration Runtime	Eine Azure Integration Runtime im Managed Network: 8 Cores (erlaubte Werte 8, 16, 32, 48, 64, 80, 128, 144, 256, 272), Compute-Typ `General` (oder `MemoryOptimized`), Time to Live 10 Minuten
Linked Services	Zum Key Vault des spokes und zum Storage Account des spokes (blob), authentifiziert mit der Managed Identity der Factory. Sie werden von Terraform verwaltet, Änderungen an diesen beiden in der Factory werden daher überschrieben.
Managed Private Endpoints	Zum Key Vault (`vault`) und zum Storage Account (`blob`). Das Modul genehmigt sie: über die API beim Key Vault und beim Storage über einen Azure-CLI-Aufruf beim Deployment. Das Deployment braucht daher die Azure CLI und das Recht, Private-Endpoint-Verbindungen auf diesen Ressourcen zu genehmigen.
Zugriff	Die Identity der Factory erhält Key Vault Secrets User auf dem Key Vault und Storage Blob Data Contributor auf dem Storage Account
Git-Integration	Optional `vsts_configuration` (ein Azure-DevOps-Git-Repository) und `global_parameters`, beide von Terraform verwaltet
Monitoring	Diagnose-Logs (pipeline-Läufe, Trigger-Läufe) an den Log-Analytics-Workspace des spokes. Eine Action Group `DefaultActionGroup` schickt E-Mails an `team_members`. Ein Alert für fehlgeschlagene pipelines, wenn `enable_alert_failed_pipeline` true ist (Default false).
Resource group	Eine neue Resource group pro Data Factory

Die private DNS Zone Group des Private Endpoints der Data Factory wird vom Modul nicht verwaltet. Sie soll von Azure Policy kommen.

Monitoring¶

Modul	Was das Modul einrichtet	Was bei dir bleibt
Logic App	Application Insights, Diagnoseeinstellungen an den Workspace des spokes, ein Name für den Health-Check-Workflow	Alerts auf deine Workflows, ein `HealthCheck`-Workflow in deiner App
Function App	Optional Application Insights	Alert Rules und das Logging deines Function-Codes
Container App	Application Insights, optionale Alerts und Action Groups	Auswahl, welche Alerts eingeschaltet werden, Application Logging
Data Factory	Diagnose, optionaler Alert für fehlgeschlagene pipelines, eine Action Group	Empfänger, Alerts zur Datenqualität

Monitoring auf Plattformebene: Betrieb.

Verantwortlichkeiten¶

	Plattform-Team	Workload-Team
Modulcode, Defaults, neue Versionen, pipeline-Templates	Ja
Auswahl der Module, Größen, Pläne und Optionen in deiner Konfiguration		Ja
Spoke, Subnetze, Key Vault, Storage Account, Log Analytics	Ja
Die Anwendung: Workflows, Function-Code, Container-Images, pipelines		Ja
DNS für Private Endpoints, Firewallregeln	Ja (auf Anfrage)	Stellt die Anfrage
Sicherheit der Data Plane		Ja

Die allgemeine Aufteilung ist unter Verantwortlichkeiten beschrieben.