Ga naar inhoud

Driftdetectie van spoke-configuratie

Nadat een spoke is gedeployd, belet niets de eigenaren om de baseline-resources te wijzigen. Dat is bewust: zo blijven de rollen eenvoudig en de spoke flexibel. Workload teams zijn niet bedoeld om de baseline-resources van het spoke canvas te wijzigen (Wat je krijgt, Beperkingen). De pipeline voor spoke driftdetectie laat zien wat er toch is gewijzigd.

Hij werkt zoals de wekelijkse driftcontrole van de hub (Onderhoudskalender), voor elk spoke-bestand: de pipeline plant elke spoke en rapporteert of het plan resources wil wijzigen. Een geplande wijziging betekent dat Azure niet meer overeenkomt met de code.

Wat het detecteert

De detectie is beperkt. Ze vindt wat een Terraform plan vindt: een verschil tussen de state en de code, in de baseline-resources van het spoke canvas. Ze controleert niet wat het workload team bovenop de baseline in de spoke deployt.

Herkomst van deze pagina

De pipeline komt uit het spoke canvas van eerdere versies en is een Azure DevOps-pipeline. Controleer of jouw codeversie hem meelevert voordat je hem inricht. De bestandsnamen en variabelenamen hieronder zijn die van de starterbestanden en kunnen in jouw platform afwijken.

Vereisten: waar de rapporten heen gaan

De pipeline schrijft zijn rapporten naar een storage account. Kies een van twee opties.

Optie 1: het storage account van een spoke (voorkeur)

Een volledig gedeployde spoke heeft een storage account dat past. Maak een spoke voor het platformteam, of gebruik een bestaande, en stel een groep van de mensen die de rapporten nodig hebben in als ProductTeamGroupNames in het spoke-bestand (Spoke-JSON-referentie). Dan, na de spoke-deployment:

  1. Maak een container in het storage account, bijvoorbeeld driftdetection.
  2. Geef de Readers-groep van de spoke de rol Storage Blob Data Reader op het storage account, zodat ze de bestanden kunnen lezen. Hebben meer mensen toegang nodig, maak dan een groep voor hen en geef die groep de rol.
  3. Controleer de netwerktoegang van het storage account. Die is normaal beperkt tot het private endpoint. Mogelijk moet je haar aanpassen zodat de lezers erbij kunnen, wat op zijn beurt een policy-uitzondering kan vragen.

Optie 2: een ander storage account

Gebruik een gewoon storage account (geen data lake, geen hierarchical namespace):

  1. Maak een container, bijvoorbeeld driftdetection.
  2. Zorg dat de deployment-agents het storage account kunnen bereiken, direct of bij voorkeur via een private endpoint.
  3. Geef de service principal van de spoke-deployment de rol Storage Blob Data Contributor erop.

De pipeline aanmaken

Het pipelinebestand maakt deel uit van de configuratierepository van de spokes (starternaam SpokeConfigurationDriftReporter.yaml in de map pipelines).

  1. Maak in het Azure DevOps-project een nieuwe pipeline van een bestaand YAML-bestand in de configuratierepository, branch main, en het pad van dat bestand. Sla hem op zonder te draaien.
  2. Hernoem hem, bijvoorbeeld Spoke Configuration-drift Detection.

  3. Stel de agent pool in het bestand in op de pool die je gebruikt:

    pool: <agent-pool>

  4. Maak de hieronder beschreven variable library aan.

  5. Draai de pipeline één keer met de hand. Azure DevOps vraagt toestemming om de pool en de library te gebruiken. Een geplande run kan daar niet om vragen, dus hij faalt totdat de eerste handmatige run is goedgekeurd.

Variable library

De pipeline leest het storage account en de container uit een variable group. De starterpipeline verwacht de naam xms-spoke-driftdetection.

Sleutel Waarde
DriftDetectionStorageAccountName De exacte naam van het storage account. Kleine letters, geen spaties aan het begin of einde.
DriftDetectionStorageContainerName De container. Voorstel: driftdetection. Dezelfde regels.

Schema

Het schema staat in het pipelinebestand:

schedules:
  - cron: "<minutes> <hours> <days> <months> <days-of-week>"
Veld Bereik
minuten 0 tot 59
uren 0 tot 23
dagen 1 tot 31
maanden 1 tot 12 (namen worden ook geaccepteerd)
dagen van de week 0 tot 6, waarbij 0 zondag is (namen worden ook geaccepteerd)

* betekent elke waarde. Azure DevOps rekent de tijd in UTC. Draai hem minstens wekelijks, in lijn met de Onderhoudskalender.

Een rapport ophalen

Elke run slaat het rapport twee keer op in de container:

Gebruik Naam
Historie: een unieke naam per run ConfigurationDriftReport_<yyyy-MM-dd HHmm>.json
Automatisering: altijd het nieuwste rapport ConfigurationDriftReport_lastest.json (zo gespeld in de bron)

Om er een te lezen, open je het storage account in de Azure portal, dan Storage browser, Blob containers en de container driftdetection. Je hebt de rol Storage Blob Data Reader nodig. Automatisering kan het latest-bestand lezen.

Handelen op een rapport

Voor elke spoke in het rapport die wijzigingen toont:

  1. Zoek uit wie wat heeft gewijzigd (Azure activity log) en waarom.
  2. Is de wijziging nodig, breng hem dan in code: een spoke-wijziging.
  3. Zo niet, draai dan de spoke-deployment, die hem terugdraait (Spoke-deployment).
  4. Neem het aantal driftende spokes mee in de maandelijkse health check.