Pour qu'une équipe informatique puisse construire un pipeline CI / CD complexe, une grande partie de la chaîne d'outils est nécessaire. Les équipes DevOps ont besoin d'un shell qui leur permet d'exécuter des tâches importantes avec des commandes simples.
PowerShell de Microsoft est un shell commun pour la gestion des pipelines CI / CD, y compris les pipelines spécifiques à PowerShell, tels que les modules PowerShell et les pipelines PowerShell DSC, ainsi que les distributions .NET et .NET Core.
PowerShell offre trois principaux avantages d'un pipeline CI / CD:
- C'est une plateforme.
- Tous les principaux fournisseurs de cloud disposent d'un module PowerShell pour la gestion de l'infrastructure.
- Il a des fonctionnalités de test intégrées.
Sommaire
PowerShell partout
Dans le cas des pipelines CI / CD, la caractéristique la plus importante de PowerShell est qu'il fonctionne sur toutes les principales plates-formes, de Linux à Apple MacOS en passant par Microsoft Windows. PowerShell est également open source. Cette compatibilité universelle permet de réduire les coûts et de simplifier les pipelines.
Par exemple, une équipe informatique déployant une application .NET Core n'a pas besoin d'exécuter son pipeline sur Windows. Étant donné que PowerShell n'est pas limité à Windows, votre organisation n'a pas besoin d'acheter des licences Windows Server supplémentaires pour le pipeline. Même les fils hôtes doivent être construits en tenant compte du coût. Par exemple, les actions GitHub facturent deux fois plus par minute pour Windows sur Linux, lorsqu'une organisation informatique dépasse l'autorisation de minutes gratuites.
Un autre avantage sur les plates-formes avec PowerShell est qu'il ne nécessite plus d'instructions conditionnelles dans une définition de pipeline pour exécuter différents scripts de langage sur différents systèmes d'exploitation. Par exemple, nous utilisons ici si instruction conditionnelle dans une définition de pipeline GitHub Actions pour appeler différents shells pour effectuer la même tâche, en fonction du système d'exploitation:
pas:
- nom: commande Bash
si: runner.os == & # 39; Linux & # 39;
exécuter: echo $ TOKEN
env:
PREBUILD_TOKEN: $ secrets.TOKEN
doit: bash
- nom: commande Pwsh
si: runner.os == & # 39; Windows & # 39;
run: Writ-Host $ env: TOKEN
env:
PREBUILD_TOKEN: $ secrets.TOKEN
doit: pwsh
Mais si les travailleurs GitHub Action ont tous PowerShell disponible en tant que shell, cette définition de pipeline peut être simplifiée à:
pas:
- nom: commande Pwsh
run: Writ-Host $ env: TOKEN
env:
PREBUILD_TOKEN: $ secrets.TOKEN
doit: pwsh
Bien que PowerShell soit conçu pour fonctionner sur plusieurs plates-formes, les scripts peuvent fonctionner différemment sur une plate-forme ou une autre. Il appartient à la personne qui réalise les automatisations sur PowerShell d'assurer la compatibilité multiplateforme. Par exemple, lorsque vous accédez à des fichiers ou à d'autres ressources système sous Linux, PowerShell est en majuscules et en minuscules, mais pas en majuscules et en minuscules sous Windows. Utilisez les noms de commande complets dans les scripts qui fonctionneront sur plusieurs plates-formes, au lieu de certaines des formes abrégées. Par exemple Objet de tri cmdlet a un alias de Trier dans PowerShell, mais sous Linux, Trier commande fait référence à une commande Linux. En conséquence, Trier dans PowerShell sur Linux appelle également Trier Commande Linux.
Gérez le cloud
En ce qui concerne les déploiements dans le cloud, les trois principaux fournisseurs de cloud – AWS, Microsoft et Google – ont des modules qui permettent aux équipes DevOps d'utiliser PowerShell pour interagir avec les API. Cela permet de distribuer et de gérer les ressources de manière interactive et via des scripts.
Nous pouvons exécuter un script PowerShell via un pipeline CI / CD pour obtenir des informations sur une ressource cloud, puis agir en fonction des résultats. Par exemple, un administrateur informatique souhaite déployer une application de fonctionnalités dans Azure, mais n'enregistrera que le nom du groupe de ressources dans son fichier yaml. À condition que l'administrateur ajoute des dépendances d'authentification avant ces étapes et configure le profil de publication, il peut le faire dans les actions GitHub avec:
- nom: exécuter le script Azure PowerShell
utilisateur: azure / powershell @ v1
avec:
azPSVersion: & # 39; 3.1.0 & # 39;
inlineScript: |
$ fa = Get-AzFunctionApp -ResourceGroupName "RgName" | Sélectionnez d'abord l'objet 1
Écrivez l'hôte ":: set-env name = fa_name :: $ ($ fa.name)"
- nom: & # 39; Exécuter l'action Azure Functions & # 39;
utilisateur: Azure / features-action @ v1
id: fa
avec:
nom de l'application: $ env.fa_name
paquet: $ env.AZURE_FUNCTIONAPP_PACKAGE_PATH
profil de publication: $ secrets.AZURE_FUNCTIONAPP_PUBLISH_PROFILE
Notez que je spécifie également une variable. Dans les pipelines CI / CD, tout shell qui peut être envoyé à l'hôte peut spécifier une variable – et qui inclut les actions PowerShell sur GitHub.
Tester l'infrastructure via Pester
Un autre scénario courant pour exécuter PowerShell dans un pipeline CI / CD est le déploiement de l'infrastructure, soit vers le cloud, soit vers un centre de données privé. Partout où l'organisation construit son infrastructure, les administrateurs informatiques peuvent tester la sortie avec PowerShell pour s'assurer qu'elle répond aux attentes de configuration.
Si votre organisation utilise un outil de gestion de la configuration, vous pouvez considérer ce processus PowerShell dans le pipeline CI / CD comme un processus complémentaire. Si votre organisation n'utilise aucun outil pour gérer la configuration de l'infrastructure, vous pouvez explorer les avantages de son adoption.
Pester est un module open source pour tester le code PowerShell et la configuration de l'infrastructure. En règle générale, avec un test Pester, les administrateurs stockent le code comme un .ps1 dans le magasin de codes à un endroit facilement référencé par le travailleur. Par exemple, nous distribuons un serveur Web et voulons nous assurer que les ports 80 et 443 sont ouverts. Enregistrez le script Pester suivant dans le dossier de test:
Décrivez le «serveur Web»
Contexte "Connexion"
Le & # 39; Port 80 devrait être ouvert & # 39; Devrait être $ true
La porte 443 devrait être ouverte & # 39;
Tester la connexion $ env: WEB_HOSTNAME -TcpPort 443
Ensuite, dans le pipeline, nous ajoutons une tâche pour exécuter Pester. Cet exemple utilise un pipeline Azure DevOps car il s'agit d'une tâche de marché de test Pester, et Azure DevOps dispose d'une fonctionnalité intégrée pour la publication et l'examen des résultats de test. Le fichier Yaml doit contenir quelque chose de similaire au script suivant:
- tâche: Pester @ 10
contributions:
scriptFolder: & # 39; $ (System.DefaultWorkingDirectory) / tests & # 39;
resultsFile: & # 39; $ (System.DefaultWorkingDirectory) /Test-Pester.XML'
usePSCore: vrai
- Tâche: PublishTestResults @ 2
contributions:
testResultsFormat: "NUnit"
testResultsFiles: "$ (System.DefaultWorkingDirectory) /Test-Pester.XML"
failTaskOnFailedTests: true
Nous publions également nos résultats de tests via PublishTestResults @ 2 tâche – de cette façon, nous obtenons un rapport qui devrait ressembler à la figure 1.
Commentaires
Laisser un commentaire