Ga naar inhoud

Het platform (hub) deployen

Deze pagina beschrijft de eerste deployment van de hub: eerst canary, dan prod. Ze gaat ervan uit dat de voorbereidingsfase klaar is (identiteit, repositories, state storage, job runners en de mcp image). De technische volgorde staat in de platform deploy flow; de layers staan in Deployment layers.

Voordat je begint

  • [ ] Vereisten gecontroleerd, identiteit aanwezig
  • [ ] Repositories aangemaakt; de configuratie staat op de branch initial
  • [ ] State storage account, hub- en spoke-statecontainers bestaan (Agents voorbereiden)
  • [ ] infrastructure en container zijn succesvol gedraaid voor canary (en later voor prod)
  • [ ] Het IP-plan is definitief
  • [ ] PIM is geactiveerd voor de engineer die de deployment uitvoert

1. Vul de configuratie voor canary in

In de configuratierepository, op de branch initial:

  1. Stel environments/canary/mcp.json in (Config): tenant, state backends, job runner, DevOps- organisatie of GitHub App, service principal-ID's, SpokeCommon.tenantinfo.
  2. Stel global.auto.tfvars (regio's, namen, subscription-ID's) en de tfvars van regio en layer in, met behulp van de mapping.
  3. Zoek in de hele repository naar waarden uit de template (de klantnaam, subscription-ID's en resource-ID's ervan). Policy- bestanden bevatten Azure resource-ID's.
  4. Controleer elke map firewall_rule_configuration: er moet minstens één JSON-bestand bestaan, ook als het platform nog geen regels heeft.
  5. Controleer dat het DNS-serveradres van de firewall policy overeenkomt met het adres van het inbound endpoint van de DNS private resolver van dezelfde platformomgeving.
  6. Controleer in de entry pipelines de gepinde versie, de agent pool, de service connections of environments, en op welke mcp.json elke entry is gericht.

Controleer mode en whatIf in de entry pipelines. De referentieconfiguratierepository past de hub toe zonder goedkeuring (Pipelines). Gebruik voor de eerste run Plan.

2. Registreer resource providers

Zorg dat alle resource providers die het platform nodig heeft zijn geregistreerd in elke platformsubscription. Als je versie het script scripts/register-az-providers.ps1 in de coderepository bevat, draai het dan nadat je met de tenant bent verbonden:

Connect-AzAccount -TenantId <tenant-id>

Registreer anders de providers die in de fouten van het eerste plan worden genoemd. Deze stap maakt ook deel uit van Vereisten.

3. Plan en apply de hub in canary

Draai hub vanaf de branch initial voor de canary-platformomgeving, eerst in de modus Plan.

  1. Lees het plan van elke layer. Bij een eerste deployment wordt alles aangemaakt. Controleer namen, regio's, adresranges en de feature switches tegen het ontwerp. Een plan dat bij een eerste deployment iets wil vernietigen, betekent een verkeerd pad of een verkeerde waarde. Stop en zoek uit waarom (Config: een verkeerd pad verwijdert resources).
  2. Draai hub opnieuw in de modus Apply (of ApproveModifications).
  3. De pipeline draait de layers in de vaste volgorde: foundation en connectivity in de primaire regio, daarna in de andere regio's, daarna firewall, identity en management in alle regio's, en postdeployment in de primaire regio (Deploy flow).
  4. Draai de pipeline opnieuw als hij klaar is. Een tweede plan moet geen wijzigingen tonen. Verschillen die steeds terugkomen (bijvoorbeeld attributen van policies of de Application Gateway) staan in Bekende problemen.

Waarom de volgorde bij een eerste deployment telt

De layers zijn van elkaar afhankelijk, bijvoorbeeld van het virtual network. De pipeline regelt de volgorde. Als je layers of regio's met de hand draait, houd je dan aan die volgorde: bij een schone deployment eerst foundation en connectivity in de primaire regio, dan in de andere regio's, en pas daarna firewall, identity en management, en als laatste postdeployment. (Oudere runbooks draaiden eerst foundation in alle regio's en daarna connectivity, primaire regio eerst.)

Volledige of gedeeltelijke runs

Wat is gewijzigd Draai
Een nieuwe layer, een globale instelling, meerdere layers of een nieuwe platformversie De volledige hub (alle layers, alle regio's)
Eén layer Alleen die layer, als je entry pipeline dat biedt, of de volledige hub en lees dat de andere layers geen wijzigingen plannen
Regiospecifieke instellingen Alleen die regio, als je entry pipeline dat biedt

Oudere entry pipelines hebben de runtimeparameters Environment, Region en Layer, elk met een waarde all. Controleer welke parameters je entry pipelines aanbieden (Pipelines).

4. Laat de agents door de firewall

Nadat de hub bestaat, bereiken de job runners Azure en de pakketbronnen via de hubfirewall. Als je deployment_agents_private_network_range instelt, maakt het platform de rule collection group voor ze aan. Voeg anders met de hand regels toe voor het agentsubnet (zie Netwerktoegang van de agents). Bij oudere layer-voor-layer-runs draaien de eerste layers op tijdelijke runners en de rest pas nadat deze regels bestaan.

5. Bereid prod voor vanuit canary

Als canary werkt, kopieer je de canary-configuratie naar prod en wijzig je de waarden die moeten verschillen:

  • elke omgevingsnaam en korte naam (canary / cnry) naar de prod-naam,
  • alle subscription-ID's en management group-ID's,
  • alle IP-adressen en ranges,
  • de service connection of credential, de state backend en de agent pool in mcp.json,
  • goedkeuringen en branch protection (die gelden alleen voor prod, zie Repositories voorbereiden).

Draai hub voor prod in de modus Plan, lees alle plannen en voer ze dan uit. Productie heeft altijd een goedkeuring nodig: gebruik een Approve*- modus of een environment met verplichte reviewers.

6. Merge en ruim op

  1. Maak een pull request van initial naar main, laat die reviewen en merge hem. Zet de standaardbranch (GitHub) terug op main en werk de federated credential voor de branch bij.
  2. Draai hub nog eens vanaf main voor canary en prod en controleer dat er geen wijzigingen worden gepland.
  3. Zet de beveiligingen aan voor main en voor prod (Repositories voorbereiden).
  4. Deploy een test-spoke: De spoke canvas deployen.

Oudere layer-voor-layer-runs

Pipelines van vóór de hub pipeline (één pipelines/main.yaml of .github/workflows/main.yaml, met de platformcode als repositoryresource xms-landing-zone-core) draaiden één layer tegelijk. Dezelfde voorbereiding geldt. In die versies:

  • De pipeline wees naar de pool (AzureDevOpsAgents_Prod of _Canary in de oudere agentopzet) en las de state- locatie uit een variable group (service connection, container, resource group, storage account, Terraform-versie en subscription van de state).
  • Voor de eerste deployment draaide je, in canary: de foundation layer voor alle regio's, de connectivity layer (hoofdregio, daarna de andere regio's), de volledige canary-run voor alle regio's en (op GitHub) de ghrunners layer. Daarna zette je de pipeline om naar de self-hosted of netwerkgeïntegreerde runners en draaide je firewall, identity, management en postdeployment, en daarna nog één keer alles.
  • Prod volgde dezelfde volgorde nadat de canary-config was gekopieerd en aangepast.
  • Updates draaiden layer voor layer in de volgorde foundation, connectivity, identity, management, firewall, postdeployment (op GitHub eerst ghrunners), voor canary en dan prod, en eindigden met een volledige run vanaf main.

Voor het updaten van een tenant op zo'n versie, zie Wat te doen als een nieuwe versie wordt gereleased (legacy-opmerking) en Migreren vanaf een oudere platformversie.