Spoke extensions: Shared Services konfigurieren

Eine spoke extension verbindet einen spoke beim Deployment mit einem Shared Service, etwa einer gemeinsamen API-Management-Instanz oder einer Container-Registry. Das spoke-Deployment gibt den richtigen Identitäten Zugriff und richtet ein, was das workload-Team braucht, sodass das Team den Shared Service direkt nach der Übergabe des spokes nutzen kann. Niemand muss auf eine separate Änderung warten.

Diese Seite ist für das Plattform-Team: wie du die Shared Services konfigurierst, was jede Extension erstellt und wie du eine neue Extension hinzufügst. Die Sicht des workload-Teams steht unter Shared Services.

Herkunft dieser Seite

Spoke extensions wurden mit spoke canvas 2.9.0 eingeführt (Release-Historie). Die Shared Services liegen in einem eigenen spoke, der mit demselben spoke canvas deployt und mit dem hub verbunden wird. Der Traffic dorthin läuft über die Hub-firewall. Prüfe die Bekannten Probleme, bevor du eine Extension aktivierst: Das spoke-Schema akzeptiert nicht jedes Feld, das Terraform liest.

So funktioniert es

flowchart LR
    spoke["Workload spoke<br/>(spoke JSON: extensions.*.enabled)"] -->|"spoke deployment"| ext["Extension code<br/>(pinned to a version tag)"]
    ext -->|"role assignments, groups,<br/>managed identities"| shared["Shared services spoke<br/>APIM, ACR, Service Bus, Event Hub"]
    team["Workload team"] -->|"uses the service"| shared

Zwei Dinge steuern das Verhalten:

1. Generische Konfiguration, einmal pro Plattform: wo die Shared Services sind.
2. Spoke-spezifische Konfiguration, pro spoke: welche Extensions aktiv sind.

1. Generische Konfiguration

In der aktuellen Plattform stehen die Shared Services in SpokeCommon.shared_services von mcp.json (Konfigurationsreferenz). Im älteren eigenständigen spoke canvas stand derselbe Block in common.tf (Upgrade-Leitfäden). Der Block enthält die subscription der Shared Services und pro Region die Resource-IDs:

shared_services = {
  subscription_id = null                       # string, subscription of the shared services
  weu = {                                      # one block per region
    eventhub_resourceid        = null          # resource ID of the Event Hub namespace
    apim_resourceid            = null          # resource ID of the API Management instance
    acr_resourceid             = null          # resource ID of the container registry
    acr_pull_group_object_id   = null          # object ID of the main AcrPull group (needed for the ACR extension)
    acr_push_group_object_id   = null          # object ID of the main AcrPush group (needed for the ACR extension)
    acr_administrative_unit_id = null          # optional, administrative unit for the spoke ACR sub-groups
                                               #   (default: tenantinfo.AdministrativeUnitId)
    servicebus_resourceid      = null          # resource ID of the Service Bus namespace
    acs_resourceid             = null          # resource ID of the Communication Services resource
  }
}

Trage nur die Services ein, die du betreibst. Verwende den Region-Key, den deine Plattform nutzt (im Beispiel weu).

2. Spoke-spezifische Konfiguration

Im spoke-JSON wird jede Extension ein- oder ausgeschaltet:

"extensions": {
  "apim":       { "enabled": false },
  "acr":        { "enabled": false },
  "servicebus": { "enabled": false },
  "eventhub":   { "enabled": false }
}

Um eine einzuschalten, setze enabled in einem pull request auf true (Spoke ändern) und führe das spoke-Deployment aus (Spoke-Deployment). Der Extension-Code läuft als Teil dieses Deployments. Das Feld ist in der Spoke-JSON-Referenz beschrieben.

Was jede Extension erstellt

Die Rollen werden den Gruppen des spokes (Owners, Contributors, Readers) und dem Deployment-Principal des spokes zugewiesen. Siehe das Identitätsmodell.

Extension	Was sie einrichtet
API Management, zentrales Modell (Default)	API Management Service Contributor für den Deployment-Principal des spokes, die Owners-Gruppe und die Contributors-Gruppe. API Management Service Reader für die Readers-Gruppe.
API Management, dezentrales Modell	Ein API Management Workspace pro spoke. API Management Workspace Contributor auf dem Workspace für den Deployment-Principal des spokes, Owners und Contributors. API Management Workspace Reader für Readers.
Azure Container Registry	Keine Rollenzuweisungen pro spoke auf der Registry. AcrPull und AcrPush werden einmal den Hauptgruppen der gemeinsamen Registry zugewiesen. Pro spoke erstellt die Extension zwei Entra-ID-Untergruppen, <main AcrPull group name>-<spoke> und <main AcrPush group name>-<spoke>, die in den Hauptgruppen verschachtelt sind und dem Service Principal des spokes gehören, sowie zwei Managed Identities, <prefix>-acrpull-mi und <prefix>-acrpush-mi, die Mitglieder der passenden Untergruppe sind.
Event Hub	Ein neuer Event Hub im gemeinsamen Namespace. User Access Administrator für den Deployment-Principal des spokes. Azure Event Hub Data Owner und Owner für Owners, Contributor für Contributors, Reader für Readers, alle auf diesem Event Hub.
Service Bus	Eine Gruppe für Data Sender and Receiver access to Service Bus messaging entities mit den Rollen Azure Service Bus Data Sender und Azure Service Bus Data Receiver auf dem Namespace. Mitglieder: Owners und Contributors. Eine Gruppe für Reader access to the Service Bus Namespace mit Service Bus Namespace Reader. Mitglieder: Readers und die Sender/Receiver-Gruppe. Der Deployment-Principal des spokes erhält Service Bus Namespace Manager und User Access Administrator, Letzteres beschränkt auf das Zuweisen der beiden Data-Rollen an Gruppen.
Communication Services	Derzeit nicht verfügbar.

Hinweise:

• ACR. Die Gruppen Owners, Contributors und Readers des spokes erhalten über die Extension keinen Registry-Zugriff. Mitglieder, die jemand von Hand zu den Untergruppen hinzufügt, bleiben erhalten. Das Löschen von Images ist bewusst nicht erlaubt, damit Teams die Images anderer nicht löschen können, weder absichtlich noch versehentlich.
• Dedizierte Gruppen. Um allen Team-Gruppen Zugriff auf eine zentrale Ressource zu geben, etwa den Bastion-Host oder eine Registry mit den Managed Templates, nutze eine dedizierte Gruppe statt vieler Rollenzuweisungen. Siehe Dedicated group manager.

Integration Platform

Die Integration Platform baut auf dieser Extension eine Service-Bus-Automatisierung pro Entität auf (Service-Bus-Automatisierung). Ihre Quelle beschreibt die Service-Bus-Rollen anders als die Tabelle oben. Prüfe die Version der Extension, die du einsetzt, bevor du dich auf eines von beiden verlässt.

Eine Extension aktivieren: Checkliste

1. Der Shared Service existiert und seine Resource-ID steht im Block shared_services der Region.
2. Für ACR: Die Hauptgruppen AcrPull und AcrPush existieren und ihre Object-IDs sind gesetzt.
3. Das spoke-JSON setzt enabled für die Extension auf true. Führe die Config-Tests aus (Tests lokal ausführen).
4. Nach dem Review läuft das spoke-Deployment. Lies den Plan: Du erwartest neue Rollenzuweisungen und Gruppen, keine Löschungen.
5. Prüfe das Ergebnis in Azure (die Rollenzuweisungen und die Gruppen aus der Tabelle oben) und informiere das workload-Team.

Eine neue Extension beisteuern

Eine Extension ist Code, den ein spoke-Deployment einbindet. Um eine hinzuzufügen, stelle sicher, dass:

• die Extension in einem Git-Repository liegt, das das spoke-Deployment lesen kann;
• das Repository Versions-Tags nutzt, damit ein spoke-Deployment eine Version fixieren kann;
• der Shared Service, den du erweiterst, verfügbar ist;
• das Warum und Wie der Extension dokumentiert sind.

Bei einem neuen Shared Service prüfen die Funktionen Architektur, Betrieb und Security die Anfrage zuerst (Service-Typen).

Verwandte Seiten

• Shared Services für workload-Teams
• Spoke-JSON-Referenz, Spoke-Konfiguration
• Bekannte Probleme