Bouw Azure DevOps-pipelines voor ARM-sjablonen in de echte wereld

Handleidingen
DevOps

Wanneer je online zoekt, vind je verschillende blogposts, documentatie en tutorials over Azure DevOps. Al deze items zijn waardevolle bronnen, maar zelden leidt er een je door een real-world scenario. Velen gaan kort door de bocht met het beveiligingsaspect en laten wachtwoorden in duidelijke tekst achter voor eenvoud of een eindproduct dat in essentie niets doet. Laten we dat veranderen.

In dit artikel/deze tutorial ga je van a tot z leren hoe je een echte Azure DevOps release pipeline bouwt die infrastructuur automatiseert. Meer specifiek ga je leren hoe je Azure DevOps kunt gebruiken om een continue deployment pipeline te bouwen voor het voorzien van Azure virtuele machines.

Tegen het einde van dit project heb je een volledig functionerende Azure pipeline. Vanuit een enkele GitHub repo commit zal het:

  • Bouw een tijdelijke Azure resource groep
  • Voorzie een Azure VM via een ARM template
  • Zet het genoemde ARM template op in een CI/CD pipeline
  • Bij elke verandering aan het template, start een template validatietest
  • Implementeer het ARM template naar Azure
  • Test de geïmplementeerde infrastructuur
  • Breek alle Azure resources af

Laten we er meteen induiken!

Project Overzicht

Dit project wordt opgedeeld in zes hoofdsecties. Deze zijn:

Azure resource voorbereiding

In deze sectie leer je hoe je alle vooraf vereiste resources in Azure opzet. Hier zul je:

  • Maak een Azure service principal aan voor verschillende taken in de pipeline
  • Zet een Azure Key Vault op met geheimen die de pipeline kan gebruiken
  • Stel de juiste toegangsbeleidsregels in voor ARM-implementaties en het gebruik van de pipeline

Azure DevOps-voorbereiding

Zodra alle Azure-resources zijn ingesteld, is het tijd om Azure DevOps voor te bereiden op uw pipeline. In deze sectie zult u:

Overzicht van script/sjabloon

Er zijn verschillende artefacten die bij dit project horen, waaronder het ARM-sjabloon om de server te bouwen en de Pester-tests. In deze sectie zullen we kort bespreken wat het sjabloon aan het voorzien is en wat precies Pester test in de pipeline.

Pijplijncreatie

In deze sectie begint het echte plezier. Je begint met het opzetten van de daadwerkelijke pijplijn. Hier leer je hoe je deze hele orchestratie opzet via een enkel YAML-bestand.

Je zult de pijplijn bouwen met behulp van de Multi-Stage Pipeline UI-ervaring. Op het moment van schrijven is deze functie in voorbeeldweergave.

Pijplijndemonstratie

Zodra de pijplijn is gebouwd, moet je hem zien draaien! In deze sectie leer je hoe je de pijplijn kunt activeren en eenvoudig kunt kijken hoe de magie gebeurt.

Opruimen

En tot slot, omdat dit slechts een demonstratie is, krijg je toegang tot een script om alles af te breken wat tijdens de tutorial is gebouwd.

Klinkt dit als veel? Dat is het! Maar maak je geen zorgen, je leert stap voor stap terwijl je elke taak één voor één aanvalt.

Als je een script wilt met alle Azure CLI-commando’s die worden gebruikt om deze pijplijn te bouwen, kun je het vinden in de ServerAutomationDemo GitHub-repo als demo.ps1.

Vereisten

Je gaat veel leren, maar er wordt ook van je verwacht dat je met een paar dingen komt. Als je van plan bent om mee te doen, zorg er dan voor dat je het volgende hebt:

ARM deployments allowed to access the key vault
  • Cloud Shell of PowerShell 6+ indien lokaal uitgevoerd – Voorbeelden kunnen werken in Windows PowerShell, maar zijn niet getest. Alle voorbeelden worden lokaal uitgevoerd via een PowerShell-console, maar de Cloud Shell werkt even goed. Je gaat de pijplijn automatiseren.
  • Azure CLI geïnstalleerd (indien lokaal uitgevoerd) – Je leert hoe je taken in dit artikel kunt uitvoeren met de Azure CLI. Dezelfde procedures kunnen echter ook worden uitgevoerd via de Azure Portal, PowerShell of de Azure SDK.

Waarschuwing: De handelingen die je gaat uitvoeren, kosten echt geld, tenzij je wat Azure-tegoed hebt. De meest kostbare bronnen die je in Azure zult implementeren, zijn een VM, maar slechts tijdelijk.

Voor je begint

Je gaat veel configuratiewerk doen in deze tutorial. Zorg ervoor dat je voordat je begint, de volgende items bij de hand hebt.

  • De naam van het Azure-abonnement waarop de resources worden geïmplementeerd – de voorbeelden zullen Adam the Automator gebruiken.
  • ID van het abonnement
  • De Azure AD tenant-ID
  • De naam van de DevOps-organisatie – de voorbeelden zullen adbertram gebruiken.
  • De regio waarin u resources plaatst – de voorbeelden zullen eastus gebruiken.
  • De naam van de Azure-resourcegroep om de tijdelijke key vault in te plaatsen – de voorbeelden zullen ServerAutomationDemo gebruiken.
  • A password to assign to the local administrator account on a deployed VM – the examples will use “I like azure.”.
  • De URL naar de GitHub-repository – de voorbeelden zullen https://github.com/adbertram/ServerAutomationDemo gebruiken.

Inloggen met de Azure CLI

Wees voorbereid om veel te werken met de Azure CLI in het artikel. Ik ben dol op de Azure PowerShell-cmdlets, maar de Azure CLI is momenteel in staat om meer DevOps-taken uit te voeren.

Uw eerste taak is om naar een PowerShell 6+ console te gaan. Eenmaal in de console, authenticeert u zich bij Azure met het commando az login. Dit commando opent een browservenster en vraagt u om uw accountgegevens.

Zodra u geauthenticeerd bent, zorg ervoor dat u uw abonnement instelt als standaard. Dit voorkomt dat u het constant moet specificeren.

az login
az account set --subscription 'Adam the Automator'

Voorbereiden van Azure-resources

Eenmaal ingelogd met de Azure CLI, is het tijd om aan de slag te gaan. Een Azure Pipeline heeft veel verschillende afhankelijkheden en verschillende instellingen om aan te passen. In dit eerste gedeelte ga je leren hoe je wat voorbereidingen treft en je omgeving gereedmaakt voor je pipeline.

Het installeren van de Azure CLI DevOps-extensie

Je hebt een manier nodig om de verschillende Azure DevOps-componenten te bouwen met behulp van de Azure CLI. Standaard is deze functionaliteit niet inbegrepen. Om Azure DevOps te beheren vanuit de Azure CLI, moet je de DevOps-extensie installeren.

Gelukkig is het installeren van de extensie slechts één regel, zoals hieronder getoond.

az extension add --name azure-devops

Zodra de extensie is geïnstalleerd, stel dan je organisatie in als de standaard om herhaaldelijk specificeren te voorkomen.

az devops configure --defaults organization=https://dev.azure.com/adbertram

Het aanmaken van de resourcegroep

Hoewel de pipeline een tijdelijke resourcegroep zal aanmaken, zou je er ook een moeten aanmaken voor eventuele resources die in deze demo worden gebruikt. Meer specifiek is deze resourcegroep waar je een Azure Key Vault zult aanmaken.

az group create --location "eastus" --name "ServerAutomationDemo"

Het aanmaken van de Azure Service Principal

De volgende taak is het maken van een Azure-serviceprincipe. U hebt een Azure-serviceprincipe nodig om te authenticeren bij de Azure Key Vault. U zult dit serviceprincipe ook gebruiken om een serviceverbinding te authenticeren. Maak het serviceprincipe aan voor zowel de sleutelkluis als voor de uiteindelijke ARM-implementatie zoals hieronder weergegeven.

$spIdUri = "http://ServerAutomationDemo"
$sp = az ad sp create-for-rbac --name $spIdUri | ConvertFrom-Json

Op dit punt is het een goed idee om de waarde van $sp.appId ergens op te slaan. Wanneer u later de pijplijn gaat bouwen, heeft u dit nodig!

U zult enkele PowerShell-opdrachten opmerken in de voorbeelden, bijv. ConvertFrom-Json. Aangezien de Azure CLI alleen JSON-strings retourneert, is het gemakkelijker om eigenschappen te refereren als ze zijn geconverteerd naar een PowerShell-object.

Het bouwen van de sleutelkluis

De pijplijn in deze zelfstudie moet verwijzen naar een paar wachtwoorden. In plaats van wachtwoorden in platte tekst op te slaan, doen we het op de juiste manier. Alle gevoelige informatie wordt opgeslagen in een Azure Key Vault.

Gebruik de az keyvault create opdracht zoals hieronder weergegeven om de sleutelkluis te maken. Deze opdracht maakt de sleutelkluis aan in de eerder aangemaakte resourcegroep. Let ook op de enabled-for-template-deployment schakelaar. Hiermee wordt het toegangsbeleid voor de sleutelkluis gewijzigd om toekomstige ARM-implementaties toegang te geven tot de sleutelkluis.

az keyvault create --location $region --name "ServerAutomationDemo-KV" --resource-group "ServerAutomationDemo" --enabled-for-template-deployment true
Allowing ARM to access the keyvault

Het maken van sleutelkluisgeheimen

Zodra de sleutelkluis is aangemaakt, is het tijd om de geheimen aan te maken. Voor deze demo, maak twee geheimen aan genaamd ServerAutomationDemo-AppPw en StandardVmAdminPassword. Het wachtwoord AppPw is het wachtwoord voor de service-principal. Het VM-wachtwoord zal worden toegewezen aan het lokale beheerdersaccount op de gedeployde VM.

az keyvault secret set --name "ServerAutomationDemo-AppPw" --value $sp.password --vault-name "ServerAutomationDemo-KV"
az keyvault secret set --name StandardVmAdminPassword --value "I like azure." --vault-name "ServerAutomationDemo-KV"

Merk op dat je in dit voorbeeld eerder gedefinieerde PowerShell-variabelen gebruikt. Hier geef je het wachtwoord van de service-principal ($sp.password) door dat eerder is verkregen.

De pijplijn toegang geven tot de sleutelkluis

Als volgende stap heeft de pijplijn toestemming nodig om toegang te krijgen tot de sleutelkluis. Ontspan het toegangsbeleid van de sleutelkluis een beetje. Geef de aangemaakte service-principal get– en list-machtigingen om de geheimen van de sleutelkluis te beheren.

az keyvault set-policy --name "ServerAutomationDemo-KV" --spn $spIdUri --secret-permissions get list

Voorbereiden van Azure DevOps

Je hebt nu al het voorbereidende werk voor de Azure-resources gedaan. Het is tijd om wat voorbereidend werk te doen in Azure DevOps.

Installeren van de Pester-extensie

De eerste taak die moet worden uitgevoerd, is het installeren van de PesterRunner-Azure DevOps-extensie. De pijplijn gaat twee sets Pester-tests uitvoeren om ervoor te zorgen dat de VM ARM-implementatie succesvol was. Een van de gemakkelijkste manieren om Pester-tests uit te voeren, is met de PesterRunner-extensie.

Installeer de extensie met het onderstaande commando.

az devops extension install --extension-id PesterRunner --publisher-id Pester

Het Azure DevOps-project maken

Het is nu tijd om het project te maken waarin de pipeline zal worden aangemaakt. Het maken van een Azure DevOps-pipeline is een fluitje van een cent met de Azure CLI. Voer eenvoudigweg de onderstaande commando’s uit om het project te maken en het project als standaard in te stellen.

az devops project create --name "ServerAutomationDemo"
az devops configure --defaults project=ServerAutomationDemo

Het maken van de serviceverbindingen

Uw pipeline moet authenticeren bij twee services – ARM en uw GitHub-repo. Hiervoor moeten twee serviceverbindingen worden gemaakt.

Maak eerst de ARM-service-eindpunt aan. Het onderstaande commando zal vragen om het wachtwoord van de service principal. Zorg ervoor dat u het eerst op het console weergeeft en kopieert naar uw klembord.

Zorg ervoor dat u uw abonnements-ID, tenant-ID invult en de abonnementsnaam hieronder vervangt.

## Voer $sp.wachtwoord uit en kopieer het naar het klembord
$sp.Password

## maak het service-eindpunt aan
az devops service-endpoint azurerm create --azure-rm-service-principal-id $sp.appId --azure-rm-subscription-id "YOURSUBSCRIPTIONIDHERE" --azure-rm-subscription-name 'Adam the Automator' --azure-rm-tenant-id $tenantId --name 'ARM'

Vervolgens maakt u een serviceverbinding voor GitHub. Aangezien de pipeline wordt geactiveerd via een Git-commit, moet deze toegang hebben tot het lezen van het repo.

Op dit punt komt die GitHub-persoonlijke toegangstoken van pas. Hieronder moet u ook het wachtwoord van de service principal opnieuw plakken. U gebruikt dezelfde service principal voor beide serviceverbindingen.

$gitHubServiceEndpoint = az devops service-endpoint github create --github-url 'https://github.com/adbertram/ServerAutomationDemo' --name 'GitHub' | ConvertFrom-Json

## Plak de GitHub-token in wanneer hierom wordt gevraagd

Het maken van de variabele groep

De pijplijn zal verwijzen naar sleutelkluisgeheimen voor twee wachtwoorden. Om dit veilig te doen, moet je een variabelengroep aanmaken en deze koppelen aan de sleutelkluis.

Eerst moet je de variabelengroep aanmaken zoals hieronder weergegeven.

az pipelines variable-group create --name "ServerAutomationDemo" --authorize true --variables foo=bar

Let op de foo=bar variabele? Deze wordt niet gebruikt, maar er is wel een enkele variabele nodig om de variabelengroep aan te maken.

De variabelengroep koppelen aan een sleutelkluis

Op dit punt moet je helaas naar het Azure DevOps-portaal gaan. Op het moment van schrijven heeft de Azure CLI geen manier om een sleutelkluis aan een variabelengroep te koppelen.

Navigeer naar het Azure DevOps-project en klik op Bibliotheek. Je zou dan de variabelengroep ServerAutomationDemo moeten zien zoals hieronder weergegeven. Klik op de variabelengroep ServerAutomationDemo.

Available variable group

Eenmaal in de variabelengroep, klik op Koppelen van geheimen uit een Azure-sleutelkluis als variabelen. Zodra je dit doet, krijg je een waarschuwing dat je alle variabelen zult wissen en klik op Bevestigen. Je zult zien hoe je dit hieronder kunt doen. Deze actie is prima omdat de foo variabele toch tijdelijk was.

Linking variable group to pipeline

Zodra bevestigd, selecteer de ARM serviceverbinding en de eerder aangemaakte ServerAutomationDemo-KV sleutelkluis zoals hieronder weergegeven. Klik op Toevoegen.

Setting the service connection

Controleer nu beide eerder aangemaakte geheimen zoals hieronder weergegeven en klik op OK en Opslaan om de wijzigingen op te slaan.

Selecting keyvault secrets for the pipeline to use

Overzicht van Projectbestanden

Als je het tot hier hebt gehaald, gefeliciteerd! Je bent nu klaar om te beginnen met het bouwen van de pipeline. Maar wacht… er is meer!

Om het bouwen van een Azure Pipeline realistisch te maken, bouwt deze tutorial een pipeline compleet met “unit” en “acceptance” tests. Dit maakt de tutorial interessanter, maar rechtvaardigt ook wat extra uitleg over wat er gebeurt.

In de GitHub repository voor deze tutorial vind je een paar bestanden zoals hieronder weergegeven. Nu is een goed moment om deze repository te klonen of je eigen versie te bouwen vanuit de bestanden.

GitHub files list
  • azure-pipelines.yml – De uiteindelijke YAML-pipeline
  • connect-azure.ps1 – PowerShell-script om aan te melden bij een Azure-abonnement
  • server.infrastructure.tests.ps1 – Een eenvoudige Pester-test om te bevestigen dat de VM-configuratie goed is
  • server.json – Een Azure ARM-sjabloon om een VM te provisioneren
  • server.parameters.json – Een Azure ARM-parametersjabloon die de ARM-sjabloon van parameterwaarden voorziet.

Zorg ervoor dat je je abonnements-ID en key vault-naam vervangt voor de key vault IT in het bestand server.parameters.json.

  • server.templates.tests.ps1 – Pester “unit” tests om te bevestigen dat de ARM-sjabloon geldig is

Je zult zien hoe elk van deze bestanden samenkomt in de pipeline zo meteen.

Het Aanmaken van de Pipeline

Als je mijn GitHub repo hebt gekloond of er zelf een hebt opgezet, is het tijd om de pipeline te maken! Voer hiervoor het az pipelines create commando uit. Het onderstaande commando maakt een pipeline genaamd ServerAutomationDemo aan met het opgegeven GitHub repo als trigger. Het zal kijken naar de master branch en de eerder gebouwde serviceverbinding gebruiken.

az pipelines create --name "ServerAutomationDemo" --repository "https://github.com/adbertram/ServerAutomationDemo" --branch master --service-connection $gitHubServiceEndpoint.id --skip-run

Afhankelijk van of je het bestand azure-pipelines.yml in je GitHub repo hebt, krijg je wel of geen feedback zoals hieronder. Hoe dan ook, je console zal er vergelijkbaar uitzien. Zorg ervoor dat je je GitHub persoonlijke toegangstoken gereed hebt!

Creating the Azure DevOps pipeline with the Azure CLI

YAML Pipeline Beoordeling

Op dit punt is je pipeline klaar om te draaien, maar het is belangrijk om eerst de YAML pipeline te begrijpen. Bekijk het azure-pipelines.yml bestand. Dit bestand is de pipeline bij het gebruik van de multi-stage YAML pipeline functie.

Laten we de verschillende componenten die deze YAML pipeline vormen eens nader bekijken.

De Trigger

Aangezien je een CI pipeline aan het bouwen bent die automatisch wordt uitgevoerd, heb je een trigger nodig. De onderstaande triggerinstructie geeft aan dat de pipeline moet worden uitgevoerd wanneer er een commit wordt gedetecteerd in de Git master branch.

Let ook op de paden sectie. Standaard wordt de pipeline uitgevoerd wanneer een commit wordt gedaan op een bestand, tenzij specifiek bestanden of mappen zijn in- of uitgesloten in de CI-build. Omdat dit project volledig is gebouwd rond een ARM-template, wil je de pipeline niet uitvoeren als je bijvoorbeeld een aanpassing hebt gemaakt aan een Pester-test.

trigger:
  branches:
    include:
      - master
  paths:
    include:
      - server.json
      - server.parameters.json

De Pool

Elke build heeft een agent nodig. Elke build-agent moet worden uitgevoerd op een VM. In dit geval maakt de VM gebruik van de ubuntu-latest VM-image. Deze image is de standaardimage die werd gedefinieerd toen de build oorspronkelijk werd gemaakt. Het is niet gewijzigd vanwege de “eenvoud” van deze pipeline.

pool:
  vmImage: "ubuntu-latest"

Variabelen

Hierna hebben we alle variabelen en de variabelengroep. De verschillende taken in deze pipeline vereisen het lezen van waarden zoals het Azure-abonnements-ID, tenant-ID en de toepassings-ID voor de service principal enzovoort. In plaats van statische waarden te repliceren in elke taak, worden ze gedefinieerd als variabele.

Let ook op het group-element. Dit element verwijst naar de variabelengroep die je eerder hebt gemaakt. Zorg ervoor dat je op dit moment de waarden van subscription_id en tenant_id vervangt.

Herinner je je nog dat je in de sectie Het maken van de Azure-serviceprincipaal werd herinnerd om de waarde van $sp.appId ergens op te slaan? Hier heb je die nodig. Wijs de waarde van die toepassings-ID van de service principal toe aan application_id zoals hieronder weergegeven.

variables:
    - group: ServerAutomationDemo
    - name: azure_resource_group_name
      value: "ServerProvisionTesting-$(Build.BuildId)"
    - name: subscription_id
      value: "XXXXXXXXXXXXX"
    - name: application_id
      value: "XXXXXXXXXXXXX"
    - name: tenant_id
      value: "XXXXXXXXXXXX"

Merk de waarde op van de variabele azure_resource_group_name. Binnen die waarde ziet u $(Build.BuildId). Dit is een systeemvariabele die het build-ID van de huidige taak vertegenwoordigt. In deze context wordt het gebruikt om ervoor te zorgen dat de tijdelijke resourcegroep die wordt gemaakt uniek is.

PowerShell voorbereidingstaken

De volgende set taken roept PowerShell-code aan. Dit pijplijnvoorbeeld gebruikt PowerShell om een tijdelijke resourcegroep te maken en te verwijderen voor testdoeleinden. In deze implementatietaken ziet u twee voorbeelden van het aanroepen van PowerShell-code.

De eerste taak roept een script aan met de naam connect-azure.ps1 dat zich in de GitHub-opslagplaats bevindt. Deze taak verifieert de Azure-abonnement voor de daaropvolgende Azure PowerShell-opdrachten.

Deze Azure PowerShell-verbindingsopdracht roept het script aan en geeft een key vault-geheime waarde (ServerAutomationDemo-AppPw) en de pijplijnvariabelen subscription_id, application_id en tenant_id door.

De tweede taak voert PowerShell-code inline uit, wat betekent dat er geen script bestaat. In plaats daarvan wordt PowerShell-code gedefinieerd in het YAML-pijplijnbestand zelf met behulp van de waarde van de pijplijnvariabele azure_resource_group_name.

- task: PowerShell@2
  inputs:
    filePath: "connect-azure.ps1"
    arguments: '-ServicePrincipalPassword "$(ServerAutomationDemo-AppPw)" -SubscriptionId $(subscription_id) -ApplicationId $(application_id) -TenantId $(tenant_id)'
- task: PowerShell@2
  inputs:
    targetType: "inline"
    script: New-AzResourceGroup -Name $(azure_resource_group_name) -Location eastus -Force

Pester Template Test

Als volgende hebben we de eerste Pester-test. In een CI/CD-pijplijn zoals deze is het belangrijk om verschillende lagen van tests te hebben. Als u een pijplijn voor een softwareproject zou maken, kunt u verschillende unit tests maken.

sinds deze voorbeeld-pijplijn is opgebouwd rondom een enkele implementatie van een ARM VM, zullen de eerste “unit”-tests dienen om de geldigheid van het JSON-sjabloon te testen. In het bestand server.templates.tests.ps1 kunt u zoveel verschillende tests toevoegen aan het ARM-sjabloonbestand als u wilt.

Let op, de pijplijn gebruikt verschillende systeemvariabelen. Deze variabelen verwijzen naar de bestandslocatie van de bestanden zodra ze op de build-agent zijn beland.

De PesterRunner-taak stuurt de testresultaten naar een XML-bestand dat later in de pijplijn zal worden gelezen.

- task: Pester@0
  inputs:
    scriptFolder: "@{Path='$(System.DefaultWorkingDirectory)/server.template.tests.ps1'; Parameters=@{ResourceGroupName='$(azure_resource_group_name)'}}"
    resultsFile: "$(System.DefaultWorkingDirectory)/server.template.tests.XML"
    usePSCore: true
    run32Bit: False

De implementatie van de ARM VM

We zijn nu aangekomen bij de implementatie van ARM. Aangezien de hele pijplijn is gebouwd rond de mogelijkheid om een VM te implementeren, is deze taak belangrijk! Deze taak implementeert het ARM-sjabloon met alle vereiste attributen die nodig zijn om dit te laten gebeuren.

Merk op de deploymentOutputs: arm_output attribuut. In de volgende stap moet een taak verbinding maken met de zojuist geïmplementeerde VM. Een goede manier om de DNS-naam of het IP-adres van deze VM te verkrijgen, is door het via de ARM-implementatie terug te geven. De deploymentOutputs optie maakt een pijplijnvariabele aan die kan worden geraadpleegd in andere taken.

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    deploymentScope: "Resource Group"
    azureResourceManagerConnection: "ARM"
    subscriptionId: "1427e7fb-a488-4ec5-be44-30ac10ca2e95"
    action: "Create Or Update Resource Group"
    resourceGroupName: $(azure_resource_group_name)
    location: "East US"
    templateLocation: "Linked artifact"
    csmFile: "server.json"
    csmParametersFile: "server.parameters.json"
    deploymentMode: "Incremental"
    deploymentOutputs: "arm_output"

Pester “Acceptance” Test

Zodra de VM is geïmplementeerd, moet u ervoor zorgen dat dit correct is gebeurd met een “integratie” of “acceptatie” test. Deze PesterRunner-taak roept Pester op en voert een andere reeks infrastructuur-gerelateerde tests uit om ervoor te zorgen dat de VM succesvol is geïmplementeerd.

Let op dat we de waarde van de uitvoer van de ARM-implementatie doorgeven via de parameter ArmDeploymentJsonOutput. Het Pester-testscriptbestand heeft een gedefinieerde parameter die de waarde ontvangt en de DNS-hostnaam van de VM leest.

 - task: Pester@0
    inputs:
      scriptFolder: "@{Path='$(System.DefaultWorkingDirectory)/server.infrastructure.tests.ps1'; Parameters=@{ArmDeploymentJsonOutput='$(arm_output)'}}"
      resultsFile: "$(System.DefaultWorkingDirectory)/server.infrastructure.tests.XML"
      usePSCore: true
      run32Bit: False

Hieronder zie je hoe het PowerShell-script server.infrastructure.tests.ps1 eruitziet. Merk op dat het de DNS-hostnaam van de VM leest om vervolgens een eenvoudige open poortcontrole uit te voeren.

$ArmDeploymentOutput = $ArmDeploymentJsonOutput | convertfrom-json

## Voer de tests uit
describe 'Network Connnectivity' {
    it 'the VM has RDP/3389 open' {
        Test-Connection -TCPPort 3389 -TargetName $ArmDeploymentOutput.hostname.value -Quiet | should -Be $true
    }
}

“Acceptance” Testopruiming

De enige reden dat de pijplijn infrastructuur implementeerde, was om de geldigheid van het ARM-sjabloon te testen. Omdat deze infrastructuur slechts tijdelijk is, moet deze worden opgeruimd. In de laatste PowerShell-taak verwijdert de pijplijn de eerder aangemaakte resourcegroep en alles daarin.

- task: PowerShell@2
  inputs:
    targetType: "inline"
    script: Get-AzResourceGroup -Name $(azure_resource_group_name) | Remove-AzResourceGroup -Force

Pester Testpublicatie

En tot slot zijn we aangekomen bij de laatste reeks taken. Azure Pipelines heeft een taak genaamd Publiceer testresultaten. Deze taak leest een XML-bestand op de build-agent en toont testresultaten in Azure DevOps. Dit is een handige manier om eenvoudig de resultaten van alle uitgevoerde tests te zien.

- task: PublishTestResults@2
  inputs:
    testResultsFormat: "NUnit"
    testResultsFiles: "$(System.DefaultWorkingDirectory)/server.infrastructure.tests.XML"
    failTaskOnFailedTests: true

- task: PublishTestResults@2
  inputs:
    testResultsFormat: "NUnit"
    testResultsFiles: "$(System.DefaultWorkingDirectory)/server.template.tests.XML"
    failTaskOnFailedTests: true
The Tests section of a pipeline run

Gebruik van de Azure DevOps-pijplijn

Ten slotte, zijn we klaar om de pijplijn uit te voeren en te zien hoe het werkt. In de Azure DevOps-web-UI, zorg ervoor dat je in het project ServerAutomationDemo bent. Klik hier op Pijplijnen en dan zou je de pijplijn ServerAutomationDemo moeten zien.

Een manier om de pijplijn uit te voeren, is door te klikken op de drie puntjes aan de uiterste rechterkant, zoals hieronder weergegeven. Klik vervolgens op Pijplijn uitvoeren. Dit zal de automatiseringsmogelijkheden starten.

Running a pipeline

De pijplijn zal voortbewegen en elke taak uitvoeren zoals geïnstrueerd. Tegen het einde zou je voor elke taak die door de job is uitgevoerd, groene vinkjes moeten zien, zoals hieronder weergegeven.

Successful job task execution

Opschonen

Zodra je wat hebt geëxperimenteerd met de pijplijn en alles wat je hier hebt bereikt, moet je de zaken opruimen. Per slot van rekening was dit slechts bedoeld als een tutorial en niet als een productietaak!

Hieronder vind je enkele commando’s om alles op te ruimen wat in dit artikel is opgebouwd. Deze code verwijdert de service principal, Azure AD-toepassing, de resourcegroep en alles daarin, en het Azure DevOps-project.

$spId = ((az ad sp list --all | ConvertFrom-Json) | ? { '<https://ServerAutomationDemo>' -in $_.serviceprincipalnames }).objectId
az ad sp delete --id $spId

## Verwijder de resourcegroep
az group delete --name "ServerAutomationDemo" --yes --no-wait

## Verwijder project
$projectId = ((az devops project list | convertfrom-json).value | where { $_.name -eq 'ServerAutomationDemo' }).id
az devops project delete --id $projectId --yes

Samenvatting

Deze tutorial was bedoeld om je een kijkje te geven in het bouwen van een echte Azure DevOps-infrastructuurautomatiseringspijplijn. Hoewel er ontelbare andere manieren zijn om pijpleidingen te bouwen zoals deze, zouden de vaardigheden die je in deze tutorial hebt geleerd je moeten helpen bij veel verschillende configuraties.

Nu eropuit gaan en beginnen met meer automatiseren!

Source:
https://adamtheautomator.com/azure-devops/