Ga naar inhoud

De spoke canvas deployen

Deploy na de hub één test-spoke om te bewijzen dat de spoke pipeline, de spoke-identiteit en de verbinding met de hub werken. De test-spoke laat je ook zien bij de overdracht. Echte spokes volgen de standaardwijziging Nieuwe spoke; deze pagina behandelt wat de eerste keer anders is.

Achtergrond over wat de deployment aanmaakt en welke rechten hij nodig heeft: Spoke canvas. Over waarom subscriptions niet uit een pool komen: Subscription provisioning.

Voordat je begint

  • [ ] De hub is gedeployed in de platformomgeving die je target (Het platform deployen)
  • [ ] De spoke-identiteit heeft haar rechten en de Graph admin consent is gegeven (Identiteit voorbereiden)
  • [ ] SpokeCommon.tenantinfo in mcp.json bevat de administrative unit-ID, de voorvoegsels van groepen en service principals, de naamgevingstemplate voor subscriptions en de rotatieperiode van secrets. Bij de aparte spoke canvas-deployment staan de common settings in common.tf (Spoke common settings)
  • [ ] Gebruik je de aparte spoke canvas-pipeline: De spoke pipeline voorbereiden is gedaan
  • [ ] Maakt de test-spoke Azure DevOps- of GitHub-resources aan: Spoke-integraties voorbereiden is gedaan
  • [ ] Gebruik je IPAM-pools: de pools staan in de common settings (Spoke JSON-naslag)
  • [ ] De spoke-statecontainer bestaat (Agents voorbereiden)
  • [ ] Een lege (of test-)subscription is beschikbaar voor de spoke. De pipeline kan geen subscriptions aanmaken zonder een CSP-billingaccount.
  • [ ] De teamgroep die toegang krijgt bestaat in Entra ID (ProductTeamGroupNames)
  • [ ] De management group voor de spoke bestaat in de management_group_structure van de hub
  • [ ] Een IP-range voor de spoke is gereserveerd in het IP-plan

Stappen

  1. Maak het spoke-bestand aan in <env-folder>/spokes/<team>/, bijvoorbeeld canvas_<workload>_dev.json. Begin met het voorbeeld in Nieuwe spoke en de Spoke JSON-naslag. De blokken om in te vullen:

    Blok Inhoud voor de test-spoke
    workloadShortName, environment Een korte naam (maximaal 6 tekens) en een non-productieomgeving
    azureSubscriptionId, azureSubscriptionName, managementGroupId De testsubscription, de naam ervan en een landing zone management group
    tags Owner, department, workload, pii, cost centre, environment
    adInfo ProductTeamGroupNames en PIMGroupConfig (nopim, self-approve of approval per spoke-groep)
    targetRegions De primaire regio van de hub (en extra regio's als je die wilt testen)
    resourceconfiguration.network[] Een virtual network uit de gereserveerde range, met een default subnet, een NSG per subnet en peerHub: true

    Verwijder de voorbeeld-spokebestanden die met de template meekwamen, zodat ze niet draaien.

  2. Controleer de entry pipeline spoke: gepinde versie, agent pool, service connection (of federated credential), mcp.json van de juiste platformomgeving, environments en mode/whatIf. In de referentieconfiguratierepository heeft spoke.yaml whatIf: true en plant hij dus alleen de canvas (Pipelines).

  3. Maak de goedkeuringsenvironment voor productiespokes aan als je er een gebruikt, met approvers en zonder zelfgoedkeuring (Repositories voorbereiden).
  4. Draai spoke met spokeGlob ingesteld op het ene test-spokebestand, eerst als plan. Lees het plan: de eerste run maakt de resource group, het netwerk, de hubverbinding, groepen, service principal, Key Vault, storage account en role assignments aan (Wat er wordt aangemaakt).
  5. Apply, draai daarna opnieuw en controleer dat het tweede plan geen wijzigingen toont. Bekende plan-ruis voor spokes staat beschreven in Bekende problemen.
  6. Verifieer met de lijst in Nieuwe spoke: management group, tags, virtual network, hubverbinding, de vier spoke-groepen, PIM-activatie door een lid van de teamgroep.
  7. Merge het spoke-bestand via een pull request naar main. Als je build validation op de configuratierepository gebruikt, draaien de spoke config tests op die pull request.

Houd de test-spoke aan tot de validatie klaar is. Houd hem daarna als voorbeeld voor de overdracht, of verwijder hem met Een spoke verwijderen.

Veelvoorkomende problemen bij de eerste run

Symptoom Oorzaak
De backend initialiseert niet De spoke-statecontainer bestaat niet, of de identiteit heeft geen blob data-rol op het account
Het aanmaken van groepen of PIM-instellingen faalt met een permissiefout Ontbrekende Graph-permissie of admin consent, of de identiteit is geen Groups Administrator op de administrative unit
De config test weigert het bestand De managementGroupId staat niet in de management group-structuur van de hub, de environment staat niet in de environments van de pipeline, of de JSON voldoet niet aan het schema
De teamgroep wordt niet gevonden De groep in ProductTeamGroupNames bestaat niet in Entra ID (de weergavenaam moet overeenkomen)
De hubverbinding faalt De hub in die regio is nog niet gedeployed, of de adresrange overlapt met een ander netwerk

Een spoke later bijwerken

Na de eerste spoke volgen wijzigingen Spoke wijzigen: een branch, een aanpassing van het spoke-bestand, een pull request dat iemand anders reviewt, en een pipeline-run voor dat ene bestand. Sommige wijzigingen zijn niet mogelijk vanwege beperkingen in Terraform of Azure, bijvoorbeeld het wijzigen van een subnet dat door virtual machines wordt gebruikt.

Oudere opzet

In versies met aparte spoke-repositories zag hetzelfde werk er zo uit:

  • Het spoke-bestand stond in de spoke-configuratierepository op spokes/tfspokes/<workload>/canvas_<...>.json. De administrative unit-ID stond in common.tf, en spokeschema.json bevatte het schema.
  • De pipeline was SpokeDeployment.yaml (Azure DevOps) of de workflow Spoke Deployment (GitHub), en een aparte pipeline verifieerde spoke-bestanden bij elke pull request.
  • De pipeline wordt beschreven in De spoke pipeline voorbereiden. Spoke-bestanden moesten canvas_<...>.json heten en _prod_ of _nonprod_ bevatten.
  • Een variable group bevatte de service connection, de tenant-ID, de Terraform-versie, het state storage account, de resource group en subscription, de spoke-statecontainer, de logcontainer en het filter dat spoke-bestanden selecteert.
  • Op GitHub moest het repository secret voor de naam van de statecontainer worden gewijzigd naar de spoke-statecontainer, en de spoke-identiteit had Storage Blob Data Contributor nodig op het storage account.
  • De environment voor deployments van productiespokes had approvers, zonder zelfgoedkeuring.