Azure App Service en Functions op STACKIT

Een code-webapp en een function-app, beoordeeld

Een demo-omgeving die voor deze pagina is opgesteld en op 4 november 2026 door StackToIT is beoordeeld: een Linux App Service-plan met een Node.js-webapp, een container-webapp en een Python-function-app met een eigen storage account voor de host. Links: twee van de invoerblokken. Rechts: het enige resourceblok dat de engine voor beide schrijft; de beoordelingsopmerkingen erboven in het bestand zijn hier weggelaten. De invoerblokken staan in main.tf niet naast elkaar, dus elk heeft een eigen paneel, letterlijk weergegeven.

resource "azurerm_linux_web_app" "portal" {
  name                = "app-portal-gwc"
  resource_group_name = azurerm_resource_group.apps.name
  location            = azurerm_resource_group.apps.location
  service_plan_id     = azurerm_service_plan.apps.id
  https_only          = true

  site_config {
    always_on = true

    application_stack {
      node_version = "20-lts"
    }
  }

  app_settings = {
    "WEBSITE_RUN_FROM_PACKAGE" = "1"
    "ORDERS_API_URL"           = "https://orders.example.internal"
  }
}

resource "azurerm_linux_function_app" "jobs" {
  name                       = "func-jobs-gwc"
  resource_group_name        = azurerm_resource_group.apps.name
  location                   = azurerm_resource_group.apps.location
  service_plan_id            = azurerm_service_plan.apps.id
  storage_account_name       = azurerm_storage_account.func.name
  storage_account_access_key = azurerm_storage_account.func.primary_access_key

  site_config {
    application_stack {
      python_version = "3.11"
    }
  }

  app_settings = {
    "QUEUE_CONNECTION" = "stfuncappsgwc01"
  }
}

resource "stackit_scf_organization" "migrated_apps" {
  project_id = var.project_id
  name       = "migrated-apps"
}

• Een organisatie, geen app

  stackit_scf_organization is een Cloud Foundry-organisatie. De apps worden met cf push in een space daarvan uitgerold, met een manifest, een buildpack en omgevingsvariabelen; het concept genereert daar niets van. De NOT CARRIED-opmerking noemt de instellingen van de demo (app-instellingen, alleen HTTPS, always on, de planverwijzing en de runtimeversie) en vermeldt dat geen enkele App Service-instelling wordt gegenereerd: plan, runtimestack, app-instellingen, siteconfiguratie, authenticatie, identiteit, back-up, logs, slots.

• Twee bronnen, één organisatie

  De portal-webapp en de function-app delen het blok, omdat beide in dezelfde Cloud Foundry-organisatie terechtkomen. De opmerking boven het blok noemt beide onder replaces.

• Beoordelingspunten die de run aandraagt

  Voor de webapp vraagt de run u te controleren of een Cloud Foundry-buildpack de runtimestack en -versie dekt. De Cloud Foundry-FAQ van STACKIT geeft aan dat cf buildpacks de huidige ingebouwde buildpacks toont en dat alleen die volledig worden ondersteund; een community-buildpack kunt u opgeven met de GitHub-URL en de versietag, maar alleen als tijdelijke maatregel. Voor de function-app vraagt de run u de triggers en bindings uit host.json of function.json op te sommen, omdat de Terraform ze niet toont.

Een container-webapp, beoordeeld

Uit dezelfde run. De legacy webapp draait al een containerimage, dus de run classificeert die als CONTAINERIZE en stelt er een cluster voor op, niet de workload.

resource "azurerm_linux_web_app" "legacy" {
  name                = "app-legacy-gwc"
  resource_group_name = azurerm_resource_group.apps.name
  location            = azurerm_resource_group.apps.location
  service_plan_id     = azurerm_service_plan.apps.id
  https_only          = true

  site_config {
    always_on = true

    application_stack {
      docker_image_name   = "shop/legacy-api:2.4"
      docker_registry_url = "https://registry.example.com"
    }
  }
}

resource "stackit_ske_cluster" "containers" {
  project_id = var.project_id
  name       = "containers"
  node_pools = [{
    name               = "workloads"
    machine_type       = var.containers_machine_type
    minimum            = var.containers_nodes_min
    maximum            = var.containers_nodes_max
    availability_zones = var.availability_zones
  }]
}

• Het cluster, zonder manifests

  Het concept maakt één SKE-cluster met één node pool. Deployments, Services, Ingress en Secrets voor de workload worden niet gegenereerd; de opmerking vermeldt dat image, CPU, geheugen, omgeving, probes, schaalregels en registry-inloggegevens nergens in het concept zijn ingesteld.

• Waarden die alleen u kunt geven

  Het machinetype en de nodelimieten hebben geen standaardwaarde. Het maximale aantal nodes moet minstens gelijk zijn aan het aantal zones, omdat de SKE-API een pool weigert waarvan het maximum lager is; het concept dwingt dat af in een validatie.

• Eén cluster voor alle container-apps

  Als uw concept al een SKE-cluster heeft, vermeldt de opmerking dat de architect de workloads daar kan draaien en dit cluster kan laten vervallen.

De validatie die de node pool beschermt

Overgenomen uit terraform/variables.tf van de run. Het laat zien hoe het concept een platformlimiet omzet in een controle voordat iets wordt toegepast.

variable "containers_nodes_max" {
  type        = number
  description = "Maximum nodes of the node pool hosting the migrated container workloads."
  validation {
    condition     = var.containers_nodes_max >= length(var.availability_zones)
    error_message = "At least the number of zones in var.availability_zones: the SKE API refuses a node pool whose maximum node count is below the number of its zones (\"maximum node count should be greater than or equal to the number of zones specified for this pool\"). Set the maximum to at least that number, or list fewer zones."
  }
}

Hoe de vier eenheden zijn geclassificeerd

Klassen zoals de run ze heeft bepaald, uit assessment.json. Het zekerheidsniveau is MEDIUM voor alle vier de eenheden, omdat de providerversie niet door een lockbestand is vastgezet.

Het doel kiezen: Cloud Foundry of SKE

De engine stelt per app één doel voor. De keuze tussen de twee platforms is aan u en hangt af van de app, niet van de Azure-dienst waarvan die afkomstig is.

Zo beslist u per app

1. 01

   Begin bij het hostingplan

   Op Azure vertelt het hostingplan van de functie hoe de app zich gedraagt: Flex Consumption, Premium, Dedicated, Container Apps of het legacy Consumption-plan. Een app op een Dedicated-plan draait al op App Service-infrastructuur tegen vaste kosten; een app die afhankelijk was van scale-to-zero verliest die eigenschap.

2. 02

   Controleer of er een containerimage is

   App Service kan eigen containers uitrollen. Als de app al een image is, voorkomt SKE of een Cloud Foundry-Docker-app een nieuwe build; is het code, dan is Cloud Foundry de kortere weg.

3. 03

   Som de triggers en bindings op

   De run zegt dat de Terraform ze niet toont. Lees host.json en function.json en maak een tabel: trigger, brondienst, vervanging op STACKIT, bijvoorbeeld RabbitMQ voor een queue.

4. 04

   Verplaats identiteit en secrets expliciet

   Managed identity en Key Vault-verwijzingen worden niet overgenomen. Elk gebruik wordt expliciete inloggegevens, en dat is een wijziging in code en configuratie.

5. 05

   Kies de volgorde

   De run plaatst beide webapps in golf 1 en de function-app in golf 2, na het storage account. Begin met de app met de minste bindings.

Wat geen enkele instelling overneemt

• Deployment slots

  Slots horen bij het App Service-model; Cloud Foundry en SKE hanteren eigen uitrolstrategieën, dus plan het releaseproces opnieuw.

• Always on, plangrootte, schaalregels

  De plangrootte en de regels hebben geen directe koppeling. Dimensioneer de Cloud Foundry-quota of de SKE-node pool op gemeten belasting.

• Registry-inloggegevens

  Voor de container-app opent de run de registry-inloggegevens als beoordelingspunt: de gebruiker en het wachtwoord, of de managed identity, worden cf push --docker-username voor Cloud Foundry of een image pull secret op SKE, gericht op de gemigreerde registry.

• Authenticatie en logs

  Ingebouwde authenticatie, loginstellingen en back-ups van de webapp worden niet gegenereerd en worden opnieuw opgebouwd in de applicatie of het platform.

Vragen van applicatieteams

Bronnen

• STACKIT Cloud Foundry
• STACKIT Kubernetes Engine (SKE)
• Microsoft Learn: overzicht van Azure App Service
• Microsoft Learn: schaal en hosting van Azure Functions
• STACKIT-documentatie: Cloud Foundry-FAQ