Construire des pipelines Azure DevOps concrets pour les modèles ARM

Tutoriels
DevOps

Lorsque vous effectuez une recherche en ligne, vous trouverez divers articles de blog, documentation et tutoriels sur Azure DevOps. Tous ces éléments sont des ressources précieuses, mais rarement l’un d’entre eux vous guide à travers un scénario du monde réel. Beaucoup survolent l’aspect sécurité en laissant les mots de passe en texte clair pour des raisons de simplicité ou un produit final qui ne fait essentiellement rien. Changeons cela.

Dans cet article/tutoriel, vous allez apprendre de A à Z comment construire un pipeline de déploiement Azure DevOps réel qui automatise l’infrastructure. Plus précisément, vous allez apprendre comment utiliser Azure DevOps pour créer un pipeline de déploiement continu afin de provisionner des machines virtuelles Azure.

À la fin de ce projet, vous aurez un pipeline Azure entièrement fonctionnel. À partir d’un seul commit dans le référentiel GitHub, il effectuera les étapes suivantes :

  • Construire un groupe de ressources Azure temporaire
  • Provisionner une VM Azure via un modèle ARM
  • Configurer ledit modèle ARM dans un pipeline CI/CD
  • À chaque modification du modèle, déclencher un test de validation du modèle
  • Déployer le modèle ARM sur Azure
  • Tester l’infrastructure déployée
  • Démanteler toutes les ressources Azure

Plongeons directement dedans !

Présentation du projet

Ce projet sera divisé en six sections principales. Elles sont les suivantes :

Préparation des ressources Azure

Dans cette section, vous apprendrez à configurer toutes les ressources préalables dans Azure. Vous allez :

  • Créez un principal de service Azure pour diverses tâches dans le pipeline
  • Configurez un Azure Key Vault avec des secrets pour que le pipeline puisse les utiliser
  • Établissez des politiques d’accès appropriées pour les déploiements ARM et l’utilisation du pipeline

Préparation d’Azure DevOps

Une fois que tous les resources Azure sont configurés, il est temps de préparer Azure DevOps pour votre pipeline. Dans cette section, vous allez :

Aperçu du script/modèle

Il existe divers artefacts associés à ce projet, y compris le modèle ARM pour construire le serveur et les tests Pester. Dans cette section, nous couvrirons brièvement ce que le modèle provisionne et ce que Pester teste exactement dans le pipeline.

Création du pipeline

C’est ici que commence réellement le plaisir. Vous commencerez à mettre en place le pipeline réel. Vous apprendrez ici comment configurer toute cette orchestration via un seul fichier YAML.

Vous construirez le pipeline en utilisant l’expérience utilisateur Multi-Stage Pipeline. Au moment de la rédaction, cette fonctionnalité est en préversion.

Démonstration du pipeline

Une fois que le pipeline est construit, vous devez le voir s’exécuter ! Dans cette section, vous apprendrez comment déclencher le pipeline et simplement regarder la magie opérer.

Nettoyage

Et enfin, puisqu’il ne s’agit que d’une démonstration, vous aurez accès à un script pour tout démanteler ce qui a été construit pendant le tutoriel.

Cela semble-t-il beaucoup ? C’est le cas ! Mais ne vous inquiétez pas, vous apprendrez étape par étape en abordant chaque tâche une à une.

Si vous souhaitez un script avec toutes les commandes Azure CLI utilisées pour construire ce pipeline, vous pouvez le trouver dans le référentiel GitHub ServerAutomationDemo en tant que demo.ps1.

Prérequis

Vous allez apprendre beaucoup, mais on attend également de vous que vous apportiez quelques éléments. Si vous prévoyez de suivre, assurez-vous d’avoir ce qui suit :

ARM deployments allowed to access the key vault
  • Cloud Shell ou PowerShell 6+ si vous exécutez localement – Les exemples peuvent fonctionner dans Windows PowerShell mais n’ont pas été testés. Tous les exemples seront exécutés localement via une console PowerShell, mais le Cloud Shell fonctionnera tout aussi bien. Vous automatiserez la création du pipeline.
  • Azure CLI installé (si vous exécutez localement) – Vous apprendrez à effectuer des tâches dans cet article avec Azure CLI. Cependant, les mêmes procédures peuvent également être effectuées via le portail Azure, PowerShell ou le SDK Azure.

Avertissement : Les actions que vous êtes sur le point d’effectuer coûtent de l’argent réel à moins que vous n’ayez un crédit Azure. Les ressources les plus coûteuses que vous allez déployer dans Azure sont une machine virtuelle, mais seulement temporairement.

Avant de commencer

Vous allez faire beaucoup de configurations dans ce tutoriel. Avant de commencer, assurez-vous d’avoir les éléments suivants à portée de main.

  • Le nom de l’abonnement Azure vers lequel les ressources seront déployées – les exemples utiliseront Adam the Automator.
  • Le ID de l’abonnement
  • Le ID du locataire Azure AD
  • Le nom de l’organisation DevOps – les exemples utiliseront adbertram.
  • La région dans laquelle vous placez les ressources – les exemples utiliseront eastus.
  • Le nom du groupe de ressources Azure où placer le coffre-fort de clés temporaire – les exemples utiliseront ServerAutomationDemo.
  • A password to assign to the local administrator account on a deployed VM – the examples will use “I like azure.”.
  • L’URL du référentiel GitHub – les exemples utiliseront https://github.com/adbertram/ServerAutomationDemo.

Connexion avec Azure CLI

Soyez prêt à travailler beaucoup avec Azure CLI dans l’article. J’adore les cmdlets Azure PowerShell mais la CLI Azure est actuellement capable d’accomplir plus de tâches DevOps.

Votre première tâche consiste à accéder à une console PowerShell 6+. Une fois dans la console, authentifiez-vous auprès d’Azure en utilisant la commande az login. Cette commande ouvrira une fenêtre de navigateur et vous demandera vos informations de compte.

Une fois authentifié, assurez-vous de définir votre abonnement par défaut. Le définir comme par défaut vous évitera d’avoir à le spécifier constamment.

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

Préparation des ressources Azure

Une fois connecté à Azure CLI, il est temps de passer aux choses sérieuses. Un pipeline Azure a de nombreuses dépendances différentes et divers boutons à actionner. Dans cette première section, vous allez apprendre comment effectuer quelques configurations et préparer votre environnement pour votre pipeline.

Installation de l’extension Azure CLI DevOps

Vous aurez besoin d’un moyen de construire les différents composants Azure DevOps avec Azure CLI. Par défaut, cela n’inclut pas cette fonctionnalité. Pour gérer Azure DevOps depuis Azure CLI, vous devrez installer l’extension DevOps.

Heureusement, l’installation de l’extension se fait en une seule ligne comme indiqué ci-dessous. 

az extension add --name azure-devops

Une fois l’extension installée, définissez votre organisation par défaut pour éviter de devoir la spécifier à chaque fois. 

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

Création du groupe de ressources

Bien que le pipeline créera un groupe de ressources temporaire, vous devriez également en créer un pour toutes les ressources mises en place dans cette démonstration. Plus précisément, ce groupe de ressources est l’endroit où vous allez créer un Azure Key Vault. 

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

Création du principal de service Azure

La prochaine tâche consiste à créer un principal de service Azure. Vous aurez besoin d’un principal de service Azure pour vous authentifier auprès du coffre de clés Azure. Vous utiliserez également ce principal de service pour authentifier une connexion de service. Créez le principal de service à la fois pour le coffre de clés et pour le déploiement ARM ultérieur comme indiqué ci-dessous.

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

À ce stade, ce serait une bonne idée de sauvegarder la valeur de $sp.appId quelque part. Lorsque vous construirez le pipeline plus tard, vous en aurez besoin !

Vous remarquerez quelques commandes PowerShell dans les exemples, par exemple ConvertFrom-Json. Étant donné que l’interface de ligne de commande Azure ne renvoie que des chaînes JSON, il est plus facile de faire référence aux propriétés si elles sont converties en un objet PowerShell.

Construction du coffre de clés

Le pipeline de ce tutoriel doit faire référence à quelques mots de passe. Plutôt que de stocker les mots de passe en clair, faisons les choses correctement. Toutes les informations sensibles seront stockées dans un coffre de clés Azure.

Pour créer le coffre de clés, utilisez la commande az keyvault create comme indiqué ci-dessous. Cette commande crée le coffre de clés dans le groupe de ressources précédemment créé. Remarquez également le commutateur enabled-for-template-deployment. Cela modifie la stratégie d’accès au coffre de clés pour permettre au futur déploiement ARM d’accéder au coffre de clés.

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

Création de secrets de coffre de clés

Une fois que le coffre-fort de clés est créé, il est temps de créer les secrets. Pour cette démonstration, créez deux secrets appelés ServerAutomationDemo-AppPw et StandardVmAdminPassword. Le mot de passe AppPw est le mot de passe pour le principal de service. Le mot de passe VM sera attribué au compte administrateur local sur la VM déployée.

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"

Notez que vous utilisez des variables PowerShell précédemment définies dans cet exemple. Ici, vous fournissez le mot de passe du principal de service ($sp.password) obtenu précédemment.

Autoriser le Pipeline à Accéder au Coffre-fort de Clés

Ensuite, le pipeline a besoin de permission pour accéder au coffre-fort de clés. Assouplissez un peu la politique d’accès au coffre-fort de clés. Fournissez au principal de service créé les autorisations get et list pour gérer les secrets du coffre-fort de clés.

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

Préparation d’Azure DevOps

Vous avez maintenant terminé toute la préparation des ressources Azure. Il est temps de faire un peu de travail de préparation dans Azure DevOps.

Installation de l’Extension Pester

La première tâche à effectuer est l’installation de l’extension Azure DevOps PesterRunner. Le pipeline va exécuter deux ensembles de tests Pester pour s’assurer que le déploiement ARM de la VM a réussi. L’un des moyens les plus simples d’exécuter des tests Pester est avec l’extension PesterRunner.

Installez l’extension en utilisant la commande ci-dessous.

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

Création du Projet Azure DevOps

Il est maintenant temps de créer le projet dans lequel le pipeline sera créé. La création d’un pipeline Azure DevOps est un jeu d’enfant avec Azure CLI. Il suffit d’exécuter les commandes ci-dessous pour créer le projet et le définir comme projet par défaut.

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

Création des connexions de service

Votre pipeline doit s’authentifier auprès de deux services – ARM et votre référentiel GitHub. Pour ce faire, deux connexions de service doivent être créées.

Tout d’abord, créez le point de terminaison de service ARM. La commande ci-dessous vous demandera le mot de passe du principal de service. Assurez-vous de l’afficher d’abord sur la console et de le copier dans le presse-papiers.

N’oubliez pas de remplir votre ID d’abonnement, votre ID de locataire et de remplacer le nom de l’abonnement ci-dessous.

## Exécutez $sp.password et copiez-le dans le presse-papiers
$sp.Password

## Créez le point de terminaison de service
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'

Ensuite, créez une connexion de service pour GitHub. Comme le pipeline sera déclenché par un commit Git, il devra être en mesure de lire le référentiel.

C’est à ce moment-là que le jeton d’accès personnel GitHub est pratique. Vous devrez également coller à nouveau le mot de passe du principal de service. Vous utilisez le même principal de service pour les deux connexions de service.

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

## Collez le jeton GitHub lorsque vous y êtes invité

Création du groupe de variables

Le pipeline fera référence à des secrets de key vault pour deux mots de passe. Pour le faire en toute sécurité, vous devez créer un groupe de variables et le lier au key vault.

Tout d’abord, créez le groupe de variables comme indiqué ci-dessous.

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

Notez la variable foo=bar ? Elle n’est pas utilisée, mais une seule variable est nécessaire pour créer le groupe de variables.

Lier le groupe de variables à un key vault

À ce stade, vous devrez malheureusement accéder au portail Azure DevOps. Au moment de la rédaction de cet article, Azure CLI n’a aucun moyen de lier un key vault à un groupe de variables.

Accédez au projet Azure DevOps et cliquez sur Bibliothèque. Vous devriez alors voir le groupe de variables ServerAutomationDemo comme indiqué ci-dessous. Cliquez sur le groupe de variables ServerAutomationDemo.

Available variable group

Une fois dans le groupe de variables, cliquez sur Lier les secrets d’un Azure key vault en tant que variables. Une fois que vous l’avez fait, vous serez averti que vous allez effacer toutes les variables, cliquez sur Confirmer. Vous verrez comment faire cela ci-dessous. Cette action est correcte car la variable foo était temporaire depuis le début.

Linking variable group to pipeline

Une fois confirmé, sélectionnez la connexion de service ARM et le key vault ServerAutomationDemo-KV créé précédemment, comme indiqué ci-dessous. Cliquez sur Ajouter.

Setting the service connection

Cochez maintenant les deux secrets créés précédemment, comme indiqué ci-dessous, et cliquez sur OK et Enregistrer pour enregistrer les modifications.

Selecting keyvault secrets for the pipeline to use

Vue d’ensemble des fichiers du projet

Si vous avez réussi jusqu’ici, félicitations ! Vous êtes maintenant prêt à commencer à construire le pipeline. Mais attendez… il y a plus !

Pour rendre la création d’un pipeline Azure plus concrète, ce tutoriel construit un pipeline complet avec des tests « unitaires » et des tests « d’acceptation ». Cela rend le tutoriel plus intéressant, mais nécessite également des explications supplémentaires sur ce qui se passe.

Dans le référentiel GitHub de ce tutoriel, vous trouverez quelques fichiers comme indiqué ci-dessous. C’est maintenant le moment idéal pour cloner ce référentiel ou construire le vôtre à partir des fichiers.

GitHub files list
  • azure-pipelines.yml – Le pipeline YAML final
  • connect-azure.ps1 – Script PowerShell pour s’authentifier auprès d’un abonnement Azure
  • server.infrastructure.tests.ps1 – Un simple test Pester pour confirmer que la configuration de la machine virtuelle est bonne
  • server.json – Un modèle ARM Azure pour provisionner une machine virtuelle
  • server.parameters.json – Un modèle de paramètres ARM Azure qui fournit au modèle ARM des valeurs de paramètres.

Assurez-vous de remplacer votre ID d’abonnement et le nom du coffre de clés pour le coffre de clés IT dans le fichier server.parameters.json.

  • server.templates.tests.ps1 – Tests « unitaires » Pester pour confirmer que le modèle ARM est valide

Vous verrez comment chacun de ces fichiers s’assemble dans le pipeline dans un instant.

Création du pipeline

En supposant que vous ayez cloné mon référentiel GitHub ou que vous en ayez créé un vous-même, il est temps de créer le pipeline ! Pour ce faire, exécutez la commande az pipelines create. La commande ci-dessous crée un pipeline appelé ServerAutomationDemo en utilisant le référentiel GitHub fourni comme déclencheur. Il examinera la branche master et utilisera la connexion de service créée précédemment.

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

Selon que vous avez ou non le fichier azure-pipelines.yml dans votre référentiel GitHub, vous pouvez ou non recevoir des commentaires similaires. Quoi qu’il en soit, votre console aura une apparence similaire. Assurez-vous d’avoir votre jeton d’accès personnel GitHub prêt !

Creating the Azure DevOps pipeline with the Azure CLI

Examen du pipeline YAML

À ce stade, votre pipeline est prêt à être exécuté, mais il est important de comprendre d’abord le pipeline YAML. Jetez un œil au fichier azure-pipelines.yml. Ce fichier est le pipeline lors de l’utilisation de la fonctionnalité de pipeline YAML multi-étapes.

Passons en revue les différents composants qui constituent ce pipeline YAML.

Le déclencheur

Étant donné que vous créez un pipeline CI qui s’exécute automatiquement, vous avez besoin d’un déclencheur. Le déclencheur ci-dessous indique au pipeline de s’exécuter lorsqu’une validation est détectée dans la branche principale Git.

Remarquez également la section paths. Par défaut, si vous n’incluez pas spécifiquement ou n’excluez pas des fichiers ou des répertoires dans une construction CI, le pipeline s’exécutera lorsque vous effectuez un commit sur n’importe quel fichier. Comme ce projet est entièrement basé sur un modèle ARM, vous ne voulez pas exécuter le pipeline si, par exemple, vous avez apporté une modification à un test Pester.

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

Le Pool

Chaque construction a besoin d’un agent. Chaque agent de construction doit s’exécuter sur une machine virtuelle. Dans ce cas, la machine virtuelle utilise l’image de VM ubuntu-latest. Cette image est l’image par défaut qui a été définie lorsque la construction a été créée à l’origine. Elle n’a pas été modifiée en raison de la « simplicité » de ce pipeline.

pool:
  vmImage: "ubuntu-latest"

Variables

Ensuite, nous avons toutes les variables et le groupe de variables. Les différentes tâches de ce pipeline nécessitent la lecture de valeurs telles que l’ID d’abonnement Azure, l’ID du locataire et l’ID de l’application pour le principal de service, etc. Plutôt que de reproduire des valeurs statiques dans chaque tâche, elles sont définies comme des variables.

Remarquez également l’élément group. Cet élément fait référence au groupe de variables que vous avez créé précédemment. Assurez-vous de remplacer les subscription_id et tenant_id à ce moment-là.

Rappelez-vous dans la section Création du principal de service Azure que vous avez été invité à enregistrer la valeur de $sp.appId quelque part ? C’est là que vous en aurez besoin. Attribuez la valeur de cet ID d’application principal de service à application_id comme indiqué ci-dessous.

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"

Notez la valeur de la variable azure_resource_group_name. À l’intérieur de cette valeur, vous verrez $(Build.BuildId). Il s’agit d’une variable système qui représente l’ID de génération du travail en cours. Dans ce contexte, elle est utilisée pour garantir que le groupe de ressources temporaire créé est unique.

Tâches de préparation PowerShell

Le prochain ensemble de tâches invoque du code PowerShell. Cet exemple de pipeline utilise PowerShell pour créer et supprimer un groupe de ressources temporaire à des fins de test. Dans ces tâches de déploiement, vous verrez deux exemples d’invocation de code PowerShell.

La première tâche invoque un script appelé connect-azure.ps1 qui existe dans le dépôt GitHub. Cette tâche s’authentifie auprès de l’abonnement Azure pour que les commandes Azure PowerShell ultérieures s’exécutent.

Cette tâche de connexion Azure PowerShell appelle le script et transmet une valeur secrète du coffre de clés (ServerAutomationDemo-AppPw) et les variables de pipeline subscription_id, application_id et tenant_id.

La deuxième tâche exécute du code PowerShell en ligne, ce qui signifie qu’un script n’existe pas déjà. Au lieu de cela, le code PowerShell est défini dans le YAML du pipeline en utilisant la valeur de la variable de pipeline 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

Test de modèle Pester

Ensuite, nous avons le premier test Pester. Dans un pipeline CI/CD comme celui-ci, il est important d’avoir plusieurs couches de tests différentes. Si vous créez un pipeline pour un projet logiciel, vous pouvez créer divers tests unitaires.

Depuis cet exemple de pipeline est construit autour d’un déploiement unique de VM ARM, les premiers tests « unitaires » seront pour tester la validité du modèle JSON. À l’intérieur du fichier server.templates.tests.ps1, vous pouvez ajouter autant de tests différents sur le fichier de modèle ARM que vous le souhaitez.

Remarquez ci-dessous, le pipeline utilise diverses variables système. Ces variables font référence à l’emplacement du fichier une fois qu’ils sont sur l’agent de construction.

La tâche PesterRunner envoie les résultats des tests dans un fichier XML qui sera ensuite lu plus tard dans le pipeline.

- 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

Le déploiement de VM ARM

Nous en sommes maintenant au déploiement ARM. Étant donné que l’ensemble du pipeline est basé sur la capacité de déployer une VM, celui-ci est important ! Cette tâche déploie le modèle ARM en fournissant tous les attributs nécessaires pour que cela se produise.

Remarquez l’attribut deploymentOutputs: arm_output. À l’étape suivante, une tâche doit se connecter à la VM qui a été déployée. Une excellente façon d’obtenir le nom DNS ou l’adresse IP de cette VM est de le retourner via le déploiement ARM. L’option deploymentOutputs crée une variable de pipeline qui peut être référencée dans d’autres tâches.

- 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"

Test « Acceptance » Pester

Une fois la VM déployée, vous devez vous assurer qu’elle a été correctement déployée avec un test « d’intégration » ou « d’acceptance ». Cette tâche PesterRunner invoque Pester et exécute un autre ensemble de tests liés à l’infrastructure pour s’assurer que la VM a été déployée avec succès.

Remarquez que nous transmettons la valeur de la sortie du déploiement ARM via le paramètre ArmDeploymentJsonOutput. Le fichier de script de test Pester a un paramètre défini qui prend la valeur et lit le nom d’hôte DNS de la machine virtuelle.

 - 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

Vous pouvez voir ci-dessous à quoi ressemble le script PowerShell server.infrastructure.tests.ps1. Remarquez qu’il lit le nom d’hôte DNS de la machine virtuelle pour ensuite effectuer une simple vérification de port ouvert.

$ArmDeploymentOutput = $ArmDeploymentJsonOutput | convertfrom-json

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

Nettoyage des tests « Acceptance »

La seule raison pour laquelle le pipeline a déployé une infrastructure était de tester la validité du modèle ARM. Comme cette infrastructure est temporaire, elle doit être nettoyée. Dans la dernière tâche PowerShell, le pipeline supprime le groupe de ressources créé précédemment et tout ce qu’il contient.

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

Publication des tests Pester

Et enfin, nous en sommes aux dernières tâches. Azure Pipelines a une tâche appelée Publish Test Results. Cette tâche lit un fichier XML sur l’agent de build et affiche les résultats des tests dans Azure DevOps. C’est un moyen pratique de voir facilement les résultats de tous les tests exécutés.

- 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

Utilisation du pipeline Azure DevOps

Enfin, nous sommes prêts à exécuter le pipeline et voir comment il fonctionne. Dans l’interface web Azure DevOps, assurez-vous d’être dans le projet ServerAutomationDemo. Une fois ici, cliquez sur Pipelines, puis vous devriez voir le pipeline ServerAutomationDemo.

Une façon d’exécuter le pipeline est de cliquer sur les trois points à l’extrême droite comme indiqué ci-dessous. Ensuite, cliquez sur Run pipeline. Cela lancera l’automatisation.

Running a pipeline

Le pipeline continuera son cours et exécutera chaque tâche comme indiqué. À la fin, vous devriez voir toutes les coches vertes pour chaque tâche effectuée par la tâche, comme indiqué ci-dessous.

Successful job task execution

Nettoyage

Une fois que vous avez bidouillé avec le pipeline et tout ce que vous avez accompli ici, vous devriez nettoyer les choses. Après tout, il s’agissait simplement d’un tutoriel et pas d’une tâche de production!

Vous trouverez ci-dessous quelques commandes pour nettoyer tout ce qui a été construit dans cet article. Ce code supprime le principal de service, l’application Azure AD, le groupe de ressources et tout ce qu’il contient, ainsi que le projet Azure DevOps.

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

## Supprimer le groupe de ressources
az group delete --name "ServerAutomationDemo" --yes --no-wait

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

Résumé

Ce tutoriel avait pour but de vous donner un aperçu de la construction d’un véritable pipeline d’automatisation de l’infrastructure Azure DevOps. Même s’il existe d’innombrables autres façons de construire des pipelines comme celui-ci, les compétences que vous avez apprises dans ce tutoriel devraient vous aider dans de nombreuses configurations différentes.

Maintenant, sortez et commencez à automatiser davantage !

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