Partager via

Configurer un déploiement continu avec Chocolatey

  • Article

Remarque

Azure Automation State Configuration sera mise hors service le 30 septembre 2027. Veuillez passer à Azure Machine Configuration avant cette date. Pour en savoir plus, consultez l’annonce du billet de blog. Le service Azure Machine Configuration combine les fonctionnalités d’Extension DSC, d’Azure Automation State Configuration, ainsi que les fonctionnalités les plus couramment demandées selon les commentaires des clients. Azure Machine Configuration inclut également la prise en charge des ordinateurs hybrides via des serveurs avec Arc.

Attention

Azure Automation DSC pour Linux a été mis hors service le 30 septembre 2023. Pour plus d'informations, consultez Annonce.

L’univers des opérations de développement offre de nombreux outils conçus pour aider les développeurs à franchir plus facilement différents stades dans le pipeline de l’intégration continue. Le nouveau service Azure Automation State Configuration vient aujourd’hui enrichir la liste des options disponibles pour les équipes DevOps.

Azure Automation est un service géré dans Microsoft Azure qui vous permet d’automatiser différentes tâches à l’aide de Runbooks, de nœuds et de ressources partagées, notamment des informations d'identification, des planifications et des variables globales. Azure Automation State Configuration étend cette fonctionnalité d’automatisation pour intégrer les outils PowerShell Desired State Configuration (DSC). En voici une excellente présentation.

Cet article explique comment configurer le déploiement continu (CD) pour un ordinateur Windows. Vous pouvez facilement étendre la technique afin d’inclure autant d’ordinateurs Windows que vous le souhaitez dans le rôle, par exemple un site Web, puis dans d’autres rôles supplémentaires.

Déploiement continu pour machines virtuelles IaaS

À un niveau élevé

Il y aurait beaucoup à dire sur ce sujet, mais il est heureusement possible de décomposer toutes ces informations en deux grands processus :

  • Écrire du code et le tester, puis créer et publication des packages d’installation pour les versions majeures et mineures du système.
  • Créer et gérer des machines virtuelles qui installent et exécutent le code dans les packages.

Une fois ces deux processus en place, vous pouvez facilement mettre automatiquement à jour le package sur vos machines virtuelles à mesure que de nouvelles versions sont créées et déployées.

Vue d’ensemble des composants

S’ils sont communément employés dans l’univers Linux, les gestionnaires de packages tels que apt-get demeurent assez méconnus dans le monde de Windows. Chocolatey est un gestionnaire de packages pour Windows. Le billet de blog de Scott Hanselman sur Chocolatey est une excellente introduction. Chocolatey vous permet d’utiliser la ligne de commande pour installer des packages à partir d’un référentiel central sur un système d’exploitation Windows. Vous pouvez créer et gérer votre propre référentiel et Chocolatey peut installer des packages à partir de tous les référentiels que vous désignez, quel qu’en soit le nombre.

PowerShell DSC est un outil PowerShell qui vous permet de déclarer la configuration que vous souhaitez affecter à une machine. Par exemple, si vous souhaitez installer Chocolatey, IIS, ouvrir le port 80 et installer la version 1.0.0 de votre site Web, le gestionnaire de configuration locale DSC Local Configuration Manager (LCM) implémente cette configuration. Un serveur Pull DSC contient un référentiel des configurations de vos machines. Le LCM résidant sur chaque ordinateur vérifie régulièrement si sa configuration correspond à la configuration enregistrée. Il peut signaler l’état ou tenter de réaligner la configuration de la machine sur la configuration enregistrée. Vous pouvez modifier la configuration enregistrée sur le serveur Pull de manière à aligner la configuration d’une machine ou d’un ensemble de machines sur la configuration modifiée.

Une ressource DSC est un module de code qui présente des fonctionnalités spécifiques, telles que la gestion de mise en réseau, Active Directory ou SQL Server. La ressource DSC Chocolatey sait comment accéder à un serveur NuGet, télécharger des packages, les installer et effectuer d’autres tâches. Il existe de nombreuses autres ressources DSC dans la PowerShell Gallery. Vous installez ces modules sur le serveur Pull Azure Automation State Configuration afin qu’ils puissent être utilisés par vos configurations.

Les modèles Resource Manager fournissent un moyen déclaratif de générer des ressources pour votre infrastructure, par exemple :

  • réseaux et sous-réseaux
  • sécurité réseau
  • routage,
  • équilibreurs de charge,
  • cartes réseau, machines virtuelles et autres

Pour obtenir une comparaison du modèle de déploiement Resource Manager (déclaratif) avec le modèle de déploiement Azure Classic (impératif), consultez Déploiement Azure Resource Manager et déploiement Classic. Cet article inclut une discussion sur les fournisseurs de ressources de base : calcul, stockage et réseau.

Un modèle Resource Manager se distingue par sa capacité à installer une extension de machine virtuelle durant l’approvisionnement de la machine virtuelle. Une extension de machine virtuelle possède des fonctionnalités spécifiques, telles que l’exécution d’un script personnalisé, l’installation d’un logiciel antivirus et l’exécution d’un script de configuration DSC. Il existe de nombreux autres types d’extensions de machine virtuelle.

Tour d’horizon rapide du diagramme

Commençons par le point de départ : vous écrivez votre code, vous le générez, vous le testez, puis vous créez un package d’installation. Chocolatey peut gérer différents types de packages d’installation, tels que MSI, MSU ou ZIP. Et vous disposez de toute la puissance de PowerShell pour effectuer l’installation si les fonctionnalités natives de Chocolatey ne sont pas adaptées. Placez le package dans un endroit facilement accessible, tel qu’un référentiel de packages. Cet exemple utilise un dossier public dans un compte de stockage d’objets blob Azure, mais vous pouvez utiliser n’importe quel emplacement. Chocolatey fonctionne en mode natif avec des serveurs NuGet et quelques autres serveurs pour la gestion des métadonnées de packages. Cet article en décrit les options. Cet exemple utilise NuGet. Un Nuspec désigne les métadonnées concernant vos packages. Les informations Nuspec sont compilées dans un NuPkg et stockées sur un serveur NuGet. Lorsque votre configuration demande un package par son nom et fait référence à un serveur NuGet, la ressource DSC Chocolatey sur la machine virtuelle extrait le package et l’installe. Vous pouvez également demander une version spécifique d’un package.

Dans la partie inférieure gauche de l’image, vous verrez un modèle Azure Resource Manager. Dans cet exemple, l’extension de machine virtuelle enregistre la machine virtuelle auprès du serveur d’extension Automation State Configuration en tant que nœud. La configuration est stockée dans le serveur d’extraction à deux reprises : une fois en texte brut et une fois compilée sous forme de fichier MOF. Dans le portail Azure, la structure MOF est une configuration de nœud, et non une simple configuration.

Il est relativement simple de créer le Nuspec, de le compiler et de le stocker dans un serveur NuGet. L’étape suivante pour le déploiement continu nécessite les tâches ponctuelles suivantes :

  • Configurer le serveur Pull
  • Inscrire vos nœuds auprès du serveur
  • Créer la configuration initiale sur le serveur

Vous devez uniquement actualiser la configuration et la configuration du nœud sur le serveur Pull lorsque vous mettez à niveau et déployez des packages dans le référentiel.

Si vous ne commencez pas avec un modèle Resource Manager, il existe des commandes PowerShell pour vous aider à inscrire vos machines virtuelles auprès du serveur Pull. Pour plus d’informations, consultez Intégration des machines pour la gestion avec Azure Automation State Configuration.

À propos de l’exemple d’utilisation

Dans l’exemple d’utilisation de cet article, nous partons d’une machine virtuelle provenant d’une image Windows Server 2012 R2 générique de la galerie Azure. Vous pouvez démarrer à partir de n’importe quelle image stockée, puis la modifier avec la configuration DSC. Toutefois, la modification d’une configuration intégrée à une image est beaucoup plus difficile que la mise à jour dynamique de la configuration à l’aide de DSC.

Vous n’êtes pas obligé d’utiliser un modèle Resource Manager ou l’extension de machine virtuelle pour utiliser cette technique avec vos machines virtuelles. De même, il n’est pas nécessaire que vos machines virtuelles se trouvent sur Azure au niveau de la gestion des CD. Il vous suffit d’installer Chocolatey et de configurer le gestionnaire de configuration local sur la machine virtuelle afin qu’il sache où se trouve le serveur Pull.

Lorsque vous mettez à jour un package sur une machine virtuelle en production, vous devez sortir cette machine virtuelle pendant l’installation de la mise à jour. La procédure varie considérablement. Par exemple, avec une machine virtuelle placée derrière un équilibreur de charge Azure, vous pouvez ajouter une sonde personnalisée. Lors de la mise à jour de la machine virtuelle, faites en sorte que le point de terminaison de la sonde retourne un code 400. La solution nécessaire pour forcer cette modification peut se trouver à l’intérieur même de votre configuration, tout comme la solution qui lui permettra de retourner un code 200 une fois la mise à jour terminée.

La source complète de cet exemple se trouve dans ce projet Visual Studio sur GitHub.

Étape 1 : configurer le serveur Pull et le compte Automation

Exécutez les commandes suivantes dans une session PowerShell authentifiée (Connect-AzAccount) :

New-AzResourceGroup -Name MY-AUTOMATION-RG -Location MY-RG-LOCATION-IN-QUOTES
$newAzAutomationAccountSplat = @{
    ResourceGroupName = 'MY-AUTOMATION-RG'
    Location = 'MY-RG-LOCATION-IN-QUOTES'
    Name = 'MY-AUTOMATION-ACCOUNT'
}
New-AzAutomationAccount @newAzAutomationAccountSplat

Cette étape prend quelques minutes pendant que le serveur Pull est configuré.

Vous pouvez créer votre compte Automation dans l’une des régions Azure suivantes :

  • USA Est 2
  • États-Unis - partie centrale méridionale
  • Gouvernement américain - Virginie
  • Europe Ouest
  • Asie Sud-Est
  • Japon Est
  • Inde centrale
  • Sud-Australie Est
  • Centre du Canada
  • Europe Nord

Étape 2 : ajuster l’extension de machine virtuelle au modèle Resource Manager

Voir les détails de l’enregistrement d’une machine virtuelle (à l’aide de l’extension PowerShell DSC VM) fournis dans ce modèle de démarrage rapide d’Azure. Cette étape consiste à inscrire votre nouvelle machine virtuelle auprès du serveur d’extraction dans la liste des nœuds State Configuration. Une partie de cette inscription consiste à spécifier la configuration du nœud à appliquer au nœud. Il n’est pas encore nécessaire que cette configuration de nœud existe dans le serveur Pull, mais vous devez choisir le nom du nœud et le nom de la configuration. Pour cet exemple, le nœud est isvbox et le nom de configuration est ISVBoxConfig. Le nom de configuration du nœud que vous spécifiez dans DeploymentTemplate.json est ISVBoxConfig.isvbox.

Étape 3 : ajouter des ressources DSC nécessaires au serveur Pull

La PowerShell Gallery peut installer les ressources DSC dans votre compte Azure Automation. Accédez à la ressource souhaitée et sélectionnez Déployer sur Azure Automation.

Exemple de la PowerShell Gallery

Une autre technique récemment ajoutée au portail Azure vous permet d’extraire de nouveaux modules ou de mettre à jour des modules existants. Sélectionnez ensuite l’icône Parcourir la galerie pour afficher la liste des modules de cette galerie, explorer les détails et effectuer l’importation dans votre compte Automation. Vous pouvez utiliser ce processus pour tenir vos modules à jour. De plus, la fonctionnalité d’importation vérifie les dépendances avec d’autres modules pour garantir que rien n’est désynchronisé.

Il existe également une approche manuelle, utilisée une seule fois par ressource, à moins que vous ne souhaitiez la mise à niveau ultérieurement. Pour plus d’informations sur la création de modules d’intégration PowerShell, consultez Création de modules d’intégration pour Azure Automation.

Remarque

La structure de dossier d’un module d’intégration PowerShell pour un ordinateur Windows est un peu différente de celle à laquelle s’attend Azure Automation.

  1. Installez Windows Management Framework v5 (inutile pour Windows 10).

  2. Installer le module d’intégration.

    Install-Module -Name MODULE-NAME`    <—grabs the module from the PowerShell Gallery

  3. Copiez le dossier de module situé dans le répertoire C:\Program Files\WindowsPowerShell\Modules\MODULE-NAME dans un dossier temporaire.

  4. Supprimez les modèles et la documentation dans le dossier principal.

  5. Compressez le dossier principal en attribuant au fichier ZIP le même nom que celui du dossier.

  6. Placez le fichier ZIP dans un emplacement HTTP accessible, par exemple un stockage d’objets blob dans un compte de stockage Azure.

  7. Exécutez la commande suivante :

    $newAzAutomationModuleSplat = @{
    ResourceGroupName = 'MY-AUTOMATION-RG'
    AutomationAccountName = 'MY-AUTOMATION-ACCOUNT'
    Name = 'MODULE-NAME'
    ContentLinkUri = 'https://STORAGE-URI/CONTAINERNAME/MODULE-NAME.zip'
}
New-AzAutomationModule @newAzAutomationModuleSplat

L’exemple fourni implémente ces étapes pour cChoco et xNetworking.

Étape 4 : ajouter la configuration de nœud au serveur Pull

L’importation et la compilation initiales de votre configuration dans le serveur Pull ne présentent aucune difficulté particulière. Toutes les importations ou compilations ultérieures de la même configuration auront exactement le même aspect. Chaque fois que vous mettez à jour votre package et que vous devez le mettre en production, vous devez effectuer cette étape après avoir vérifié que le fichier de configuration est correct et qu’il comporte la nouvelle version de votre package. Voici le fichier de configuration ISVBoxConfig.ps1 :

Configuration ISVBoxConfig
{
    Import-DscResource -ModuleName cChoco
    Import-DscResource -ModuleName xNetworking

    Node 'isvbox' {

        cChocoInstaller installChoco
        {
            InstallDir = 'C:\choco'
        }

        WindowsFeature installIIS
        {
            Ensure = 'Present'
            Name   = 'Web-Server'
        }

        xFirewall WebFirewallRule
        {
            Direction    = 'Inbound'
            Name         = 'Web-Server-TCP-In'
            DisplayName  = 'Web Server (TCP-In)'
            Description  = 'IIS allow incoming web site traffic.'
            Enabled       = 'True'
            Action       = 'Allow'
            Protocol     = 'TCP'
            LocalPort    = '80'
            Ensure       = 'Present'
        }

        cChocoPackageInstaller trivialWeb
        {
            Name      = 'trivialweb'
            Version   = '1.0.0'
            Source    = 'MY-NUGET-V2-SERVER-ADDRESS'
            DependsOn = '[cChocoInstaller]installChoco','[WindowsFeature]installIIS'
        }
    }
}

Le script New-ConfigurationScript.ps1 suivant a été modifié pour utiliser le module Az PowerShell :

$importAzAutomationDscConfigurationSplat = @{
    ResourceGroupName = 'MY-AUTOMATION-RG'
    AutomationAccountName = 'MY-AUTOMATION-ACCOUNT'
    SourcePath = 'C:\temp\AzureAutomationDsc\ISVBoxConfig.ps1'
    Published = -Published
    Force = -Force
}
Import-AzAutomationDscConfiguration @importAzAutomationDscConfigurationSplat

$startAzAutomationDscCompilationJobSplat = @{
    ResourceGroupName = 'MY-AUTOMATION-RG'
    AutomationAccountName = 'MY-AUTOMATION-ACCOUNT'
    ConfigurationName = 'ISVBoxConfig'
}
$jobData = Start-AzAutomationDscCompilationJob @startAzAutomationDscCompilationJobSplat

$compilationJobId = $jobData.Id

$getAzAutomationDscCompilationJobSplat = @{
    ResourceGroupName = 'MY-AUTOMATION-RG'
    AutomationAccountName = 'MY-AUTOMATION-ACCOUNT'
    Id = $compilationJobId
}
Get-AzAutomationDscCompilationJob @getAzAutomationDscCompilationJobSplat

Étape 5 : créer et maintenir les métadonnées de package

Pour chaque package que vous placez dans le référentiel de packages, vous avez besoin d’un Nuspec descriptif. Il doit être compilé et stocké sur votre serveur NuGet. Pour plus d’informations, consultez [Créer un package NuGet avec l’interface de ligne de commande nuget.exe].

Vous pouvez utiliser MyGet.org comme serveur NuGet. Vous pouvez acheter ce service, mais il existe un SKU gratuit destiné aux débutants. Pour obtenir des instructions sur l’installation de votre propre serveur NuGet pour vos packages privés, consultez la documentation sur Nuget.org.

Étape 6: tout assembler

Chaque fois qu'une version passe l'assurance qualité et est approuvée pour le déploiement, le package est créé, nuspec et nupkg sont mis à jour et déployés sur le serveur NuGet. Vous devez mettre à jour la configuration (étape 4) avec le nouveau numéro de version. Envoyez-la ensuite au serveur Pull et compilez-la.

À ce stade, les machines virtuelles qui dépendent de cette configuration doivent extraire la mise à jour et l'installer. Chacune de ces mises à jour est simple et ne nécessite qu’une ou deux lignes PowerShell. Pour Azure DevOps, certaines d’entre elles sont encapsulées dans des tâches de génération que vous pouvez chaîner dans une build. Cet article fournit plus de détails. Ce référentiel GitHub détaille les tâches de génération disponibles.

Étapes suivantes