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

De integratiemodules zijn Terraform-modules die een integratieservice in je spoke deployen, al verbonden met de spoke (netwerk, Key Vault, storage account, Log Analytics) en gebouwd op een veilige baseline. Jij kiest een paar instellingen, de module doet de rest. Deze pagina beschrijft de set modules, wat elke module deployt, zijn standaardwaarden en hoe een workload team hem gebruikt. Hoe je de deployment draait: Integratieresources deployen.

Optioneel aanbod, referentieontwerp

Welke modules en versies je platform aanbiedt, hangt af van je platform. De standaardwaarden op deze pagina komen uit de Terraform van de modules. Je platformteam kan ze hebben gewijzigd of een andere versie hebben gepind.

De set modules¶

Eén rootmodule neemt per servicetype een map aan. Je vult alleen in wat je nodig hebt. Een lege map deployt niets.

Service	Input-map	Deployt (samenvatting)
Logic App	`logic_apps`	Een Standard Logic App op een gedeeld workflow plan, alleen private endpoint, ingebouwde authenticatie, eigen storage account
Function App	`function_apps` (en `service_plans`)	Een Linux Function App, VNet-integratie, private endpoint, op identity gebaseerde toegang tot het storage account van de spoke
Container App	`container_apps_environment`	Een Container Apps environment (intern), container apps en jobs in t-shirtmaten
Data Factory	`data_factories`	Een Data Factory met managed virtual network, private endpoint en linked services naar de Key Vault en storage van de spoke

Samen vormen ze het ingredient modules van het platform (Servicebeschrijving).

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

Hoe een module je spoke gebruikt¶

Elke module heeft de beschrijving van je spoke nodig in één variabele, spoke_config. Die wordt gevuld uit een bestand met de outputs van de spoke (zie Integratieresources deployen).

Veld van `spoke_config`	Betekenis
`name`, `environment`, `location`, `tags`	Naam, omgeving, regio en tags van de spoke. Modules erven tags. De Container App-module vereist dat de omgeving `nonprod` of `prod` is (zie hieronder).
`subscription_id`, `tenant_id`, `resource_group_name`	Waar de spoke staat
`virtual_network_id`, `virtual_network_name`	Het netwerk van de spoke
`subnet_ids`, `subnet_names`	Maps van de subnets van de spoke. Modules kiezen subnets op naam (bijvoorbeeld voor private endpoints en voor uitgaande integratie).
`key_vault_id`, `key_vault_name`	De Key Vault van de spoke
`storage_account_id`, `storage_account_name`	Het storage account van de spoke
`log_analytics_workspace_id`, `log_analytics_workspace_name`	Waar logs naartoe gaan

De modules lezen deze resources (Key Vault, storage account, Log Analytics workspace) als bestaande resources. Ze maken ze niet aan. Een module die een genoemd subnet niet kan vinden, mislukt, dus controleer eerst de subnetnamen in je spoke.

Private endpoints: de modules beheren de private DNS zone groups van hun private endpoints niet. Naamresolutie voor de endpoints wordt verwacht te worden geregeld door het platform, bijvoorbeeld met Azure Policy. Vraag het je platformteam.

Logic App¶

Een Standard Logic App met een geharde 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 = {}
  }
}

Instelling	Standaardwaarde en effect
Plan	Eén gedeeld workflow service plan voor alle Logic Apps van de spoke, Windows, aangemaakt door de rootmodule uit `default_logic_apps_plan`: grootte `S` (WS1; ook `M` = WS2, `L` = WS3), minstens 2 instances, zone balancing aan. Plannaam `asp-<spoke name>-logicapps` in een resource group `rg-<spoke name>-logicapps`, tenzij je namen opgeeft.
Resource group	Standaard wordt een groep per Logic App aangemaakt (`create_resource_group`, true). Je kunt een bestaande opgeven.
Netwerk	Public network access uit. Private endpoint in het subnet dat je noemt, uitgaand verkeer via het outbound-subnet (VNet-integratie). `vnet_private_ports_count` reserveert private poorten.
Authenticatie	Altijd aan. Niet-geauthenticeerde requests krijgen een 401. Toegestane audiences, groepen en identities stel je in met `authentication_settings`. `/runtime/*` is uitgesloten, zodat de runhistorie inputs en outputs kan tonen.
Storage	Een eigen storage account voor de Logic App, voor isolatie van performance en security, met een firewall die standaard weigert en alleen het outbound-subnet toestaat
Identity	System-assigned en een user-assigned managed identity
Hardening	Alleen HTTPS, FTPS uitgeschakeld, basic authentication voor FTP en web deploy uitgeschakeld, HTTP/2 aan
Monitoring	Application Insights gekoppeld aan de Log Analytics workspace van de spoke, diagnostic settings voor de app en zijn storage
Health check	Een workflow met de naam `HealthCheck` met trigger `Request` wordt voor de health check gebruikt. Beide namen kunnen worden gewijzigd (namen van maximaal 12 en 7 tekens).

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

De workflows deployen. De modulerepository bevat twee kleine bouwstenen voor een pipeline: de ene verpakt het Logic App-project (gebruikt parameters.azure.json als parameters.json als dat bestaat en laat local.settings.json weg), de andere deployt het pakket naar de Logic App Standard-resource. Je platformteam geeft je de pipelinetemplate.

Function App¶

Een Function App op een service plan dat je zelf definieert, met op identity gebaseerde toegang tot het storage account van de spoke.

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

Instelling	Standaardwaarde en effect
Plan	Kies met `service_plan_key` (een plan uit `service_plans`) of `service_plan_resource_id` (een bestaand plan). Meerdere apps kunnen een plan delen.
Flex Consumption (FC1)	Zet `sku_name = "FC1"` op het plan en `function_app_uses_fc1 = true` op de app, met `fc1_runtime_name` en `fc1_runtime_version` (standaard `node` en `20`). Eén app per FC1-plan, alleen Linux.
Netwerk	VNet-integratie via `virtual_network_subnet_id`, en een private endpoint is verplicht: geef altijd minstens één item in `private_endpoints`.
Storage	Geen sleutels. De app gebruikt zijn system-assigned identity op het storage account van de spoke: de module geeft hem Storage Blob Data Owner en Storage Blob Data Contributor op dat account, maakt een privé blob container met de naam van de app aan en stelt de op identity gebaseerde `AzureWebJobsStorage__...`-instellingen in. Stel `AzureWebJobsStorage` zelf niet in. De module verwijdert het.
Identity	System-assigned staat altijd aan. Je kunt user-assigned identities toevoegen via `managed_identities`.
Site-instellingen	Veilige standaardwaarden in `site_config`: alleen FTPS, minimaal TLS 1.3 (1.2 voor de SCM-site), always on, 32-bit worker uit. Authentication v2 en IP-restricties zijn beschikbaar.
Application Insights	Optioneel, via `application_insights`
Resource group	Standaard de resource group van de spoke. Een eigen groep met `create_resource_group_for_function_apps` en `function_apps_resource_group_name`.

Linux in de rootmodule

De modulerepository bevat een Linux- en een Windows-Function App-module. De input van de rootmodule accepteert de velden van de Linux-module. Overleg met je platformteam voordat je een Windows Function App plant.

Container App¶

Een Container Apps environment in je spoke met container apps en 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 }]
  }
}

Instelling	Standaardwaarde en effect
Environment	Naam `cae-<name>-<np or p>-<region code>`. `environment` moet `nonprod` of `prod` zijn. Als je het niet instelt, wordt de omgeving van `spoke_config` gebruikt, dus die moet een van de twee zijn. De environment is intern (interne load balancer) in het subnet dat je noemt, op het Consumption workload profile. Logs gaan naar de Log Analytics workspace van de spoke.
Images	Je geeft de imagenaam per app of job op. Een gedeelde tag `container_image_tag` (standaard `latest`) wordt toegevoegd. Het ophalen gebeurt met een user-assigned managed identity die je noemt (`container_registry_identity`) op de registry `container_registry_server`. Hier wordt de gedeelde container registry gebruikt (Gedeelde services).
Maten	`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. Standaard `S`.
Container apps	Per app: grootte, health check, `min_replicas` (standaard 0), `max_replicas` (standaard 1), omgevingsvariabelen, ingress (standaard aan), optioneel Dapr
Container jobs	Drie soorten: manual, event (start als er een bericht binnenkomt in een Azure Storage-queue van het storage account van de spoke, één uitvoering tegelijk, pollt elke 30 seconden) en scheduled (cron-expressie). Standaardwaarden per job: timeout 600 seconden, 3 retries, parallelism 1.
Storage-helpers	`storage_containers`, `storage_queues` en `storage_tables` maken die onderdelen aan in het storage account van de spoke
Secrets	Een user-assigned identity van de environment krijgt Key Vault Certificate User op de Key Vault van de spoke. De connection string van Application Insights wordt als secret in de Key Vault van de spoke opgeslagen.
Application Insights	Eén per environment, 30 dagen retentie
Alerts	Optioneel, via `monitoring_config`: mislukte requests, exceptions en berichten die aan gekozen queues zijn toegevoegd. Meldingen per e-mail en/of naar een Teams-kanaal (via het e-mailadres ervan) worden per environment ingeschakeld. Alles staat standaard uit.

Namen: ca-<...> voor apps, cj-<...> voor manual jobs, cj-event-<...> voor event jobs en cj-cron-<...> voor scheduled jobs.

Data Factory¶

Een Data Factory voor batch-ETL, met een privé netwerkmodel.

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

Instelling	Standaardwaarde en effect
Netwerk	Public network access uit, managed virtual network aan, een private endpoint in het subnet dat je noemt
Integration runtime	Een Azure integration runtime in het managed netwerk: 8 cores (toegestane waarden 8, 16, 32, 48, 64, 80, 128, 144, 256, 272), compute type `General` (of `MemoryOptimized`), time to live 10 minuten
Linked services	Naar de Key Vault van de spoke en het storage account van de spoke (blob), geauthenticeerd met de managed identity van de factory. Ze worden door Terraform beheerd, dus wijzigingen die je in de factory aan deze twee maakt, worden overschreven.
Managed private endpoints	Naar de Key Vault (`vault`) en het storage account (`blob`). De module keurt ze goed: via de API voor de Key Vault, en voor storage via een Azure CLI-aanroep tijdens de deployment. De deployment heeft daarom de Azure CLI nodig en het recht om private endpoint-connections op die resources goed te keuren.
Toegang	De identity van de factory krijgt Key Vault Secrets User op de Key Vault en Storage Blob Data Contributor op het storage account
Git-integratie	Optioneel `vsts_configuration` (een Azure DevOps Git-repository) en `global_parameters`, beide beheerd door Terraform
Monitoring	Diagnostische logs (pipeline runs, trigger runs) naar de Log Analytics workspace van de spoke. Een action group `DefaultActionGroup` stuurt e-mail naar `team_members`. Een alert voor mislukte pipelines als `enable_alert_failed_pipeline` true is (standaard false).
Resource group	Een nieuwe resource group per Data Factory

De private DNS zone group van de private endpoint van de Data Factory wordt niet door de module beheerd. Die wordt verwacht uit Azure Policy te komen.

Monitoring¶

Module	Wat de module inricht	Wat bij jou blijft
Logic App	Application Insights, diagnostic settings naar de workspace van de spoke, de naam van een health check-workflow	Alerts op je workflows, een `HealthCheck`-workflow in je app
Function App	Optioneel Application Insights	Alert rules en de logging van je functiecode
Container App	Application Insights, optionele alerts en action groups	Kiezen welke alerts je inschakelt, applicatielogging
Data Factory	Diagnostics, optionele alert voor mislukte pipelines, een action group	Ontvangers, alerts op datakwaliteit

Monitoring op platformniveau: Beheer.

Verantwoordelijkheden¶

	Platformteam	Workload team
Modulecode, standaardwaarden, nieuwe versies, pipelinetemplates	Ja
De modules, maten, plannen en opties in je configuratie kiezen		Ja
Spoke, subnets, Key Vault, storage account, Log Analytics	Ja
De applicatie: workflows, functiecode, container images, pipelines		Ja
DNS voor private endpoints, firewallregels	Ja (op aanvraag)	Vraagt aan
Beveiliging van het data plane		Ja

De algemene verdeling staat bij Verantwoordelijkheden.