Kürzlich bin ich auf ein noch nicht so populäres Tier in der Welt von DevOps gestoßen, die Azure DevOps-Pipelines. Sofort spürte ich das Fehlen einiger klarer Anleitungen oder Artikel zu diesem Thema, ich weiß nicht, woran das liegt, aber Microsoft hat offensichtlich noch einiges zu tun, um das Tool bekannter zu machen. Heute werden wir eine Pipeline für automatisierte Tests in der Azure-Cloud erstellen.

Also, die Aufgabe:
Es gibt eine Software, die mit Azure DevOps gebaut wird, die aus einem Projekt auf WIX zusammengestellt wird. Wenn es Interessierte gibt, kann ich auch über dieses Tool schreiben. Tatsächlich ist es eine optimierte Methode zur Automatisierung der Erstellung von Windows-Installationsprogrammen, die den standardmäßigen InstallShield ersetzt. Also, unsere Software wird erfolgreich erstellt und generiert ein Artefakt, ein gewisses setup.exe, das die Anwendung im Windows-System installiert. Diese Anwendung muss in eine ähnliche virtuelle Maschine wie die Produktionsumgebung installiert werden, dort automatisierte Tests, die vom Testteam vorbereitet wurden, kopiert werden, sie gestartet werden und dann müssen die Ergebnisse zurückgeholt werden, um zu entscheiden, ob der Branch gut oder schlecht ist, bevor wir mergen. Alles wie in GitLab, nur über den Tisch.

Als Virtualisierungsumgebung, in der wir unsere Tests durchführen werden, nutzen wir offensichtlich Azure DevTest Labs, eine Art Entität in den Azure-Abonnements, die genau dafür geschaffen wurde, um dort allerlei Testkram zu akzeptablen Preisen laufen zu lassen.

1. Integration auf der Cloud-Seite

Zunächst müssen wir unser DevTest Labs mit Azure DevOps integrieren, wozu wir einen Service Principal benötigen, der praktisch ein Dienstkonto ist, das es den Pipelines ermöglicht, in die Cloud zu gelangen und dort Ressourcen für sich selbst zu erstellen/löschen.

Wir gehen zu den Abonnements und finden den Dienst Azure Active Directory

Wir suchen die App-Registrierungen und klicken auf Neue Registrierung, dies wird unser Service Principal erstellen. Ich werde die Einstellungen beim Erstellen nicht im Detail erläutern, da diese je nach Abonnement variieren können.

Jetzt müssen wir unserem Service Principal die erforderlichen Berechtigungen erteilen. Dafür gehen wir zu den Abonnements, dem Schlüsselsymbol. Wir wählen unser Abonnement aus.

Dann klicken wir unter Zugriffskontrolle auf Rollenzuweisung und suchen in der Suche nach dem soeben erstellten Namen dieses Kontos. Wir geben ihm die Rolle des Mitwirkenden, das ist genug.

Dann kehren wir zu unserem Service Principal im Azure AD zurück und öffnen seine Eigenschaften. Später benötigten wir alle IDs, die dort vorhanden sind, also speichern wir sie.

Damit enden unsere Portal-Einstellungen und wir wechseln zu Azure DevOps.

2. Integration auf der Seite von Azure DevOps

Zuerst gehen wir zu den Projekteinstellungen und wählen den Punkt Service Connections. Wir erstellen ein neues Element des Typs Azure Resource Manager.

Jetzt benötigen wir alle IDs, die wir notiert haben. Klicken Sie auf "use the full version of the service connection dialog". Geben Sie alle Daten ein, die wir vom Service Principal erhalten haben. Klicken Sie auf "verify" und wenn alles in Ordnung ist, speichern Sie die Verbindung. Jetzt können unsere Pipelines sie zur Verbindung mit der Cloud verwenden.

3. Erstellung der Pipeline

Nun kommen wir zum Interessantesten, dem Aufbau der Pipeline. Wir öffnen das Menü Pipelines-Builds.

Uns begrüßt das Menü zur Erstellung eines neuen Builds, das standardmäßig versucht, eine YAML-Datei mit der passenden Konfiguration zu erstellen. Wir lehnen dies höflich ab und wählen die klassische Variante. Es ist verständlich, dass Microsoft alles benutzerfreundlich gestalten und die Verwendung von YAML zur maximalen Anpassung der Pipelines ermöglichen möchte, aber die spärliche Dokumentation und die einfach praktische Nichtfunktionalität vieler Module zeigen uns, dass es noch zu früh ist, diese Funktionalität zu nutzen.

Aus der Vielzahl der Vorlagen benötigen wir eine einfache leere Pipeline. Nach der Erstellung begrüßt uns ein leeres Bearbeitungsfenster, in dem wir ziemlich viel Zeit verbringen werden.

Also klicken wir auf + und gelangen in eine Art Modulgeschäft, aus dem wir folgende Komponenten benötigen.

Bevor wir mit der Konfiguration der Aufgaben der Pipeline beginnen, müssen wir einige Dateien im Projekt erstellen und ablegen. Dazu gehören die ARM-Vorlage unserer virtuellen Maschine, die wir in Azure DevTest Labs generieren werden, ein Skript zum Abrufen der IP der Maschine, nachdem sie erstellt wurde, und nach Wunsch Skripte für unsere Tests oder das, was wir auf dem Host ausführen möchten.

4. Erstellung des ARM-Templates

Um eine virtuelle Maschine zu erstellen, müssen wir zunächst ein Template generieren, eine JSON-Datei, die wir in den Projektcode legen, damit die Pipeline sie dort lesen kann.

Wir gehen in unser Labor und finden das Menü Formulas (wiederverwendbare Grundlagen), klicken auf erstellen, um eine neue zu erstellen.

Wir werden von einer langen Liste von Images als Basis begrüßt, der Auswahl der Maschinen-Größe, alles genauso wie beim Erstellen einer virtuellen Maschine. An dieser Stelle werden wir nicht verweilen, sondern direkt zum letzten Punkt der Maschinen-Eigenschaften übergehen, nämlich zu den Artefakten. Sie können beliebige Konfigurationen verwenden, die für Ihre Umgebung erforderlich sind. Zum Beispiel füge ich eine Maschine hinzu in Domain haben und füge ihr ein Servicekonto als Administrator hinzu, damit die Pipeline später auf diese Maschine mit diesem Benutzerkonto zugreifen kann. Das kann variieren, aber für erfolgreiche Code-Tests benötigen wir ein Artefakt, bei dem wir genauer schauen müssen. Um die neueste Version der Software, die wir testen, auf unserer Maschine zu installieren, verwenden wir das Artefakt „Download Azure Pipelines Artifact and Run Script“. Erinnern Sie sich, dass ich zu Beginn sagte, dass irgendwo ein Build mit dem Anwendungsinstaller erstellt wird? Jetzt müssen wir der virtuellen Maschine, genauer gesagt der Vorlage, sagen, dass sie dieses Artefakt abholen soll. Und nicht nur abholen, sondern auch installieren, wozu wir spezielle Felder mit Angabe des Projekts, des Build-Namens und des geheimen Schlüssels ausfüllen. Der geheime Schlüssel wird, wie in allen ähnlichen Systemen, im Benutzerkonto generiert, in diesem Fall in Azure DevOps, und in den Secrets in Ihrem Lab gespeichert. Hier gibt es eine kleine Anmerkung: In den Secrets speichern wir ihn, aber für die Vorlage ändert sich dadurch nichts, sie wird bereits von einem anderen Benutzer im Rahmen der Pipeline gestartet, daher müssen wir den geheimen Schlüssel noch einmal manuell in die Vorlage einfügen.

Ein weiteres Artefakt, das unbedingt enthalten sein muss, ist „Configure WinRM“, das benötigen wir für den späteren Zugriff auf die Maschine. Es gibt nur einen Parameter, hostname. Da wir diesen im Voraus nicht wissen, verwenden wir die Variable %COMPUTERNAME%.

Also haben wir alle erforderlichen Artefakte hinzugefügt, jetzt kommen wir zu dem Grund, warum wir überhaupt hier sind. Wir ziehen die generierte ARM-Vorlage im Tab 'Erweitert' des gleichen Fensters zur Erstellung des Templates hervor.

Wir kopieren den Inhalt der Seite in die Datei VMtemplate.json und legen sie in das Wurzelverzeichnis des Projekts. Mehr benötigen wir von der Cloud nicht, wir kehren zur Pipeline zurück.

5. Konfiguration der Pipeline

Lassen Sie uns mit dem Wichtigsten und Interessantesten beginnen, der Erstellung einer virtuellen Maschine. Dafür haben wir all diese Integrationen und Templates erstellt. Im Punkt Azure RM Subscription wählen wir unsere Serviceverbindung aus, die wir im Punkt 2 konfiguriert haben. Danach sollte die für uns verfügbare Laborumgebung angezeigt werden. Anschließend wählen wir das JSON aus, das wir generiert haben, und definieren einige erforderliche Variablen. Den Login und das Passwort für die Maschine kann man direkt oder über Variablen angeben, aber ich bin mir überhaupt nicht sicher, ob das funktioniert. Egal, was ich eingegeben habe, ich konnte mich später mit diesen Zugangsdaten nicht bei der Maschine anmelden. Wichtig ist, dass der Name der Maschine möglichste immer eindeutig ist. Dafür verwende ich eine Build-Umgebungsvariable.

Als nächstes richten wir noch einen weiteren wichtigen Punkt ein. Nachdem die Maschine hochgefahren ist, müssen wir ja irgendwie ihre Parameter kennen, besser gesagt, der Pipeline. Dafür erstellen wir ein Skript, zum Beispiel GetLabVMParams.ps1, und legen es ebenfalls im Projekt ab. Den Text des Skripts habe ich von der Microsoft-Website, jedoch ein wenig für meine Umgebung angepasst, da es die PublicIP und den FQDN der Maschine abgerufen hat. Beides habe ich nicht, aber ich habe eine PrivateIP, die nicht gerade einfach zu bekommen ist, daher habe ich einen weiteren Abschnitt hinzugefügt.

Param( [string] $labVmId)

$labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId

# Hole den Namen der Ressourcengruppe der Labor-VM
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Hole den Namen der Labor-VM
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Hole die öffentliche IP-Adresse der Labor-VM
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Hole den FQDN der Labor-VM
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Hole die private IP-Adresse der Labor-VM
$VmNetworkdetails= (((Get-AzureRmVM -ResourceGroupName $labVmRgName -Name $labVmName).NetworkProfile).NetworkInterfaces).Id
$nicname = $VmNetworkdetails.substring($VmNetworkdetails.LastIndexOf("/")+1)
$labVMnetwork = (Get-AzureRmNetworkInterface -Name $nicname -ResourceGroupName $labVmRgName)|Select-Object -ExpandProperty IPConfigurations 
$labVMIpAddress = $labVMnetwork.PrivateIpAddress

# Setze eine Variable labVmRgName, um den Namen der Ressourcengruppe der Labor-VM zu speichern
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Setze eine Variable labVMIpAddress, um die IP-Adresse der Labor-VM zu speichern
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Setze eine Variable labVMFqdn, um den FQDN-Namen der Labor-VM zu speichern
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Von allem, was das Skript ausliest, benötigen wir nur die Variable labVMIpAddress. Mir könnte auch etwas anderes nützlich sein, deswegen habe ich nichts gelöscht, sondern nur das Überflüssige auskommentiert.

Ich erkläre auch die letzte Zeile des Skripts, sie erlaubt unserer Build-Maschine den Zugriff auf jeden Host über WinRM.

Im nächsten Schritt starten wir unser wunderbares Skript. Es benötigt dieselbe Verbindung zur Cloud und die Eingabevariable mit der ID der Maschine, die zu diesem Zeitpunkt aus dem vorherigen Schritt bereits bekannt sein wird. Wie? Hier muss auf eine bemerkenswerte Sache hingewiesen werden, wie die Ausgabewerte. Jeder Schritt kann eine Liste von Variablen haben, die an die nächsten Schritte der Pipeline weitergegeben werden. Daher wird für unser Super-Skript die Variable labVMIpAddress benötigt, vergessen Sie nicht, dies anzugeben.

Dann mache ich ziemlich einfache Dinge, die außerdem von Fall zu Fall variieren können. Ich führe ein entferntes Skript mit der Erstellung eines Shares aus, in das ich dann meine Skripte hochladen werde.

New-Item "C:test" –typ Verzeichnis
New-SMBShare –Name "test" –Path "C:test"  –FullAccess everyone

Aus den Aufgabennamen ist klar, dass wir als Nächstes ein bestimmtes Beispielskript auf die Maschine kopieren und es in einem weiteren Schritt ausführen. Für die Adresse der entfernten Maschine benötigen wir unsere Variable $(labVMIpAddress). Anschließend verwenden wir die Aufgabe "Artefakt vom Share holen" und kopieren die Ergebnisse der Skriptausführung in unsere Build-Umgebung. Danach sichern wir diese Dateien mit der gleichen Standardaufgabe im Build-Artefakt. Nachdem die Maschine nicht mehr benötigt wird, beenden wir sie im letzten Schritt. Die Hauptschwierigkeit, wie aus dem Umfang des Artikels hervorgeht, ist es, sich mit der Cloud zu integrieren und Kontakt zu der virtuellen Maschine aufzunehmen, die Sie erstellt haben. Danach kann man so viel Spaß haben, wie man möchte.

Das ist mein erster Artikel, also urteilen Sie nicht zu hart, Kommentare sind willkommen.

Quelle: habr.com