Je souhaite utiliser le module Azure PowerShell (alias module Az) dans un pipeline de versions Azure DevOps. Cependant, les options PowerShell existantes ne semblent pas fonctionner. J'ai essayé diverses choses, mais l'installation du nouveau module Az ne fait que générer une tonne d'erreurs, y compris les modules Az et AzureRM ne peuvent pas être importés dans la même session ou utilisés dans le même script ou runbook.
La tâche PowerShell standard ne comporte aucun module Azure intégré. Et la tâche Azure PowerShell utilise Module Azure RM PowerShell , qui a été retiré (c'est-à-dire qu'il est toujours pris en charge, mais aucune nouvelle fonctionnalité ne sera ajoutée).
L'erreur ci-dessus est probablement due au fait que lorsque la tâche Azure PowerShell démarre, elle effectue les opérations suivantes avant d'exécuter mon script:
2019-01-13T13:34:14.5416432Z ============================================================================== 2019-01-13T13:34:14.5416555Z Task : Azure PowerShell 2019-01-13T13:34:14.5416623Z Description : Run a PowerShell script within an Azure environment 2019-01-13T13:34:14.5416705Z Version : 3.1.18 2019-01-13T13:34:14.5416762Z Author : Microsoft Corporation 2019-01-13T13:34:14.5416831Z Help : [More Information](https://go.microsoft.com/fwlink/?LinkID=613749) 2019-01-13T13:34:14.5416969Z ============================================================================== 2019-01-13T13:34:20.3546127Z ##[command]Import-Module -Name C:\Modules\AzureRm_6.7.0\AzureRM\6.7.0\AzureRM.psd1 -Global 2019-01-13T13:34:58.4365259Z ##[command]Clear-AzureRmContext -Scope Process 2019-01-13T13:34:59.2732327Z ##[command]Disable-AzureRmContextAutosave -ErrorAction SilentlyContinue 2019-01-13T13:35:00.1691359Z ##[command]Add-AzureRMAccount -ServicePrincipal -Tenant *** -Credential System.Management.Automation.PSCredential -Environment AzureCloud @processScope 2019-01-13T13:35:01.5702545Z ##[command] Select-AzureRMSubscription -SubscriptionId d5eaaba3-2968-456a-98a4-e53e961fc896 -TenantId *** 2019-01-13T13:35:02.1592660Z ##[command]& 'D:\a\r1\a\ws-build\tools\install-dependencies.ps1'
Naturellement, sur un nouveau projet que je ne fais pas. Je veux créer des scripts PowerShell avec un module qui ne sera plus avancé.
Et en pensant à l'avenir, même si j'arrive à surmonter cela, je devrai m'authentifier d'une manière ou d'une autre avec Azure, ce qui L'interface utilisateur Azure DevOps fait pour moi, et je ne vois pas encore comment faire cela avec le module Az.
La recherche sur Google ne semble pas aider, car la plupart des informations concernent toujours le module AzureRM obsolète. Alors ... En résumé.
Comment utiliser le module Azure (Az) Powershell dans un pipeline de versions Azure DevOps?
5 Réponses :
La tâche a une dépendance sur un module spécifique. Si vous souhaitez utiliser la tâche, vous ne pouvez rien y faire d'autre que d'attendre qu'ils la mettent à jour.
Si vous le souhaitez, vous pouvez créer un fork du référentiel de tâches et le mettre à jour toi même. Ou vous pouvez écrire votre propre logique pour l'authentification Azure.
Vous pouvez écrire vos scripts avec un alias inversé (Az -> AzureRM) par opposition aux alias fournis par le module Az (AzureRM -> Az), afin que vous puissiez écrire vos scripts en utilisant les noms d'applet de commande qui seront pris en charge, ainsi vous-même à l'épreuve du futur.
Merci - cela m'a donné quelques idées sur la façon de procéder. Bien que je puisse télécharger et installer / importer des modules dans ma tâche, c'est l'aspect authentification qui m'a échappé. J'espère que je vais comprendre comment cela fonctionne dans la tâche Azure Powershell actuelle quelque part dans le code source.À défaut, l'alias inversé peut être une bonne solution provisoire.
@ColinMackay FWIW, j'ai dû faire une solution provisoire similaire pour certains éléments hébergés dans Azure Automation sur lesquels je travaille. Azure Automation ne prend pas encore en charge les modules Az non plus, mais il y a un désir pour un certain degré de pérennité.
Pour contourner ce problème, j'utilise le pool d'agents hébergé VS2017 car ils ont préparé le module Az
Cela fonctionne si vous choisissez Powershell version 4 qui est actuellement en préversion
Et si vous souhaitez tirer parti de l'alias pour rendre votre migration initiale moins pénible, utilisez: Enable-AzureRmAlias -Scope LocalMachine dans votre script PowerShell appelé par ADO.
En développant simplement le commentaire @Josh, l'aperçu V4 de la tâche Azure PowerShell contient le module AZ, quelle que soit la version de l'agent hébergé
J'ai emprunté la route du hack, mais j'ai fini par créer un module AzureRM factice à installer sur mes agents auto-hébergés, puis j'ai modifié les scripts de la tâche Azure PowerShell sur mes agents pour charger les alias AzureRM. Le résultat final est que Az est installé sur mes agents et qu'ils peuvent exécuter des noms d'applet de commande de style AzureRM et / ou des noms d'applet de commande de style Az sur la version 3 ou 4 de la tâche Azure PowerShell. Cela m'a permis de passer à Az sur les agents de build et de permettre aux équipes de migrer progressivement leurs scripts pour utiliser les noms des applets de commande Az.
Ma solution est sur Github: https://github.com/brendonthiede/dummy-AzureRM a>
Une mise en garde est que cela peut nécessiter de «remodifier» les scripts Azure PowerShell sur les agents chaque fois que la tâche est mise à jour.
Essayez d'utiliser Azure Powershell Task version 4. * (préversion). Cette fonctionnalité est toujours en préversion. Utilisez-le avec les agents auto-hébergés. Ce sera bientôt disponible pour l'agent hébergé Microsoft.
4. * L'aperçu est disponible pour les agents hébergés à partir de maintenant. J'ai résolu le problème
Impressionnant. Bon à entendre
Cela arrive bientôt. D'après ce commentaire GitHub, les modules Az seront disponibles en février 2019: github.com/Microsoft/azure-pipelines-tasks/issues/...
J'ai essayé de jouer avec les modules Az dans les devops Azure. J'ai écrit un bref à ce sujet ici - medium. com / @ harioverhere /…