Vor Kurzem bin ich auf ein noch nicht sehr populäres Thema im DevOps-Bereich gestoßen: Azure DevOps-Pipelines. Sofort fiel mir das Fehlen klarer Anleitungen oder Artikel zu diesem Thema auf. Ich weiß nicht, woran das liegt, aber Microsoft hat eindeutig Nachholbedarf in der Popularisierung dieses Tools. Heute bauen wir eine Pipeline für automatisierte Tests in der Azure-Cloud.

Also, die Aufgabe:
Es gibt Software, die mit derselben Azure DevOps-Umgebung gebaut wird, erstellt aus einem WIX-Projekt. Falls Interesse besteht, kann ich auch über dieses Tool schreiben. Tatsächlich handelt es sich um eine optimierte Methode zur Automatisierung der Erstellung von Windows-Installationsprogrammen, die den herkömmlichen InstallShield ersetzt. Unsere Software wird erfolgreich erstellt und generiert ein Artefakt, eine Art setup.exe, die die Anwendung im Windows-System installiert. Es ist notwendig, diese Anwendung auf eine ähnliche virtuelle Maschine wie in der Produktion zu installieren, automatisierte Tests, die vom Testteam vorbereitet wurden, dorthin zu kopieren, sie auszuführen und die Ergebnisse abzurufen, um zu bestimmen, ob der Branch gut oder schlecht ist, bevor wir zusammenführen. Alles wie in GitLab, nur über den Umweg.

Als Virtualisierungsumgebung, in der wir unsere Tests durchführen werden, nutzen wir offensichtlich Azure DevTest Labs, eine bestimmte Entität innerhalb der Azure-Abonnements, die dafür geschaffen wurde, um verschiedene Testaktivitäten zu einem angemessenen Preis auszuführen.

1. Integration auf der Cloud-Seite

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

Navigieren Sie zu Ihrem Abonnement und suchen Sie den Dienst Azure Active Directory.

Suchen Sie nach App Registrierungen und klicken Sie auf Neu registrieren, um unseren Service Principal zu erstellen. Ich werde nicht im Detail darauf eingehen, welche Einstellungen beim Erstellen ausgewählt werden sollten, da dies je nach Abonnement variieren kann.

Jetzt müssen wir unserem Service Principal Berechtigungen erteilen. Gehen Sie dazu zu Abonnements, das Symbol mit dem Schlüssel. Wählen Sie unser Abonnement aus.

Im Bereich Zugriffssteuerung klicken wir auf Rollen-Zuweisung und suchen im Suchfeld nach dem gerade erstellten Namen dieses Kontos. Wir gewähren die Rolle Contributor, das ist ausreichend.

Danach kehren wir zu unserem Service Principal im Azure AD zurück und öffnen dessen Eigenschaften. Später benötigen wir alle IDs, die dort vorhanden sind, also speichern wir diese.

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

2. Integration in Azure DevOps

Zunächst gehen wir zu den Projekteinstellungen und wählen die Serviceverbindungen aus. Wir erstellen ein neues Element vom Typ Azure Resource Manager.

Jetzt benötigen wir alle IDs, die wir notiert haben. Klicken Sie auf 'die vollständige Version des Dienstverbindungsdialogs verwenden'. Geben Sie alle Daten ein, die Sie von Service Principal erhalten haben. Klicken Sie auf 'Überprüfen' und wenn alles gut ist, speichern Sie die Verbindung. Jetzt können unsere Pipelines diese zur Verbindung mit der Cloud verwenden.

3. Erstellen einer Pipeline

Jetzt kommen wir zum spannendsten Teil, dem direkten Aufbau der Pipeline. Öffnen Sie das Menü Pipelines-Bauten.

Wir werden mit dem Menü zur Erstellung eines neuen Builds begrüßt, das standardmäßig versucht, eine YAML-Datei mit der passenden Konfiguration zu erstellen. Wir lehnen höflich ab und wählen die klassische Variante. Es ist verständlich, dass Microsoft alles so menschenfreundlich wie möglich gestalten möchte und den Benutzern die maximale Anpassung der Pipelines über YAML ermöglichen möchte, aber die spärliche Dokumentation und einfach die nicht funktionierenden Module zeigen uns, dass es noch zu früh ist, um diese Funktionalität zu nutzen.

Von der Vielzahl an Vorlagen benötigen wir eine einfache leere Pipeline. Nach ihrer Erstellung erwartet uns ein leeres Bearbeitungsfenster, in dem wir eine beträchtliche Zeit verbringen werden.

Also klicken wir auf + und gelangen in einen Modulshop, aus dem wir folgende Komponenten benötigen.

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

4. Generierung der ARM-Vorlage

Um eine virtuelle Maschine zu erstellen, müssen wir zuerst eine Vorlage generieren, eine JSON-Datei, die wir in den Projektcode einfügen, damit die Pipeline sie lesen kann.

Gehen Sie zu unserem Labor und finden Sie das Menü Formeln (wiedernutzbare Basen), klicken Sie auf neu erstellen.

Wir werden mit einer umfangreichen Liste von Images konfrontiert, die als Basis dienen, und können die Maschinenhöhe auswählen – alles ähnlich wie bei der Erstellung einer virtuellen Maschine. An dieser Stelle werden wir nicht verweilen und sofort zum letzten Punkt der Eigenschaften der Maschine übergehen, nämlich zu den Artefakten. Sie können jegliche Konfigurationen verwenden, die für Ihre Umgebung erforderlich sind. Zum Beispiel füge ich eine Maschine hinzu in Hosting und füge einen Service-Account als Admin hinzu, damit die Pipeline später auf diese Maschine über dieses Konto zugreifen kann. Das kann variieren, aber für das erfolgreiche Testen des Codes benötigen wir ein Artefakt, auf das wir näher eingehen werden. Damit die neueste Version der Software, die wir testen, auf unsere Maschine installiert wird, verwenden wir das Artefakt „Download Azure Pipelines Artifact and Run Script“. Erinnern Sie sich, dass ich zu Beginn gesagt habe, dass irgendwo der 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 es auch installieren, wozu wir spezielle Felder mit Angaben zum Projekt, dem Namen des Builds und dem geheimen Schlüssel ausfüllen. Der geheime Schlüssel wird wie in allen ähnlichen Systemen in dem Account generiert, in diesem Fall in Azure DevOps, und in den Secrets in Ihrem Labor gespeichert. Es gibt hier eine kleine Einschränkung: In Secrets werden wir ihn speichern, aber die Vorlage bleibt davon unberührt, denn sie wird von einem anderen Benutzer im Rahmen der Pipeline gestartet. Daher müssen wir den geheimen Schlüssel nochmals manuell in die Vorlage eintragen.

Ein weiteres Artefakt, das unbedingt enthalten sein muss, ist „WinRM konfigurieren“. Dieses benötigen wir für den späteren Zugriff auf die Maschine. Hier gibt es nur einen Parameter, den Hostnamen. Da wir ihn im Voraus nicht kennen, verwenden wir die Variable %COMPUTERNAME%.

Nachdem wir alle notwendigen Artefakte hinzugefügt haben, kommen wir zu dem Grund, warum wir hier sind. Holen wir uns die generierte ARM-Vorlage im Reiter 'Erweitert' des gleichen Formularerstellungsfensters.

Wir kopieren den Inhalt der Seite in die Datei VMtemplate.json und legen sie im Stammverzeichnis des Projekts ab. Das Cloud-Angebot benötigen wir nicht mehr, wir kehren zum Pipeline zurück.

5. Pipeline-Konfiguration

Lassen Sie uns mit dem Wichtigsten und Interessantesten beginnen: der Erstellung einer virtuellen Maschine, für die wir all diese Integrationen und Vorlagen vorgenommen haben. Im Abschnitt Azure RM Subscription wählen wir unsere Service-Verbindung aus, die wir in Punkt 2 konfiguriert haben. Dann sollte die verfügbare Laborumgebung angezeigt werden. Anschließend wählen wir die JSON-Datei aus, die wir generiert haben, und definieren einige erforderliche Variablen. Der Benutzername und das Passwort für die Maschine können entweder direkt oder über Variablen eingegeben werden, aber ich bin mir nicht sicher, ob das funktioniert. Egal, was ich dort eingebe, ich konnte mich später nicht mit diesen Zugangsdaten bei der Maschine anmelden, aber es ist wichtig, den Namen der Maschine so zu wählen, dass er möglichst einzigartig ist. Dafür verwende ich eine Umgebungsvariable des Builds.

Nun richten wir einen weiteren wichtigen Punkt ein. Nachdem die Maschine gestartet ist, müssen wir schließlich ihre Parameter kennen, und besser nicht wir selbst, sondern der Pipeline. Dazu 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 entnommen, allerdings etwas an meine Umgebung angepasst, da es die PublicIP und den FQDN der Maschine abgerufen hat. Beides steht mir nicht zur Verfügung, aber ich habe eine PrivateIP, die nicht ganz einfach zu beschaffen ist, daher habe ich ein Stück kodiert.

Param( [string] $labVmId)

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

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

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

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

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

# Holen Sie sich 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

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

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

# Setzen Sie eine Variable labVMFqdn, um den FQDN 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. Für mich reicht das, vielleicht benötigen Sie noch etwas anderes, deshalb habe ich nichts gelöscht, sondern nur das Überflüssige kommentiert.

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 großartiges Skript. Es benötigt die gleiche Verbindung zur Cloud sowie die Eingabevariable mit der Maschinen-ID, die zu diesem Zeitpunkt bereits aus dem vorherigen Schritt bekannt sein wird. Wie? Hier ist es wichtig, die wunderbare Sache namens Output Variables zu erwähnen. Jeder Schritt kann eine Liste von Variablen haben, die an die folgenden Schritte im Pipeline-Prozess übergeben werden. Für unser super Skript wird die Variable labVMIpAddress sein. Vergessen Sie nicht, dies anzugeben.

Anschließend führe ich recht einfache Dinge aus, die von Fall zu Fall variieren können. Ich führe ein Remote-Skript aus, das einen Share erstellt, in den ich später meine Skripte hochladen werde.

New-Item “C:test" –type directory
New-SMBShare –Name “test” –Path “C:test”  –FullAccess everyone

Aus dem Titel der Aufgaben lässt sich erkennen, 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 verwenden wir unsere Variable $(labVMIpAddress). Anschließend nutzen wir die Aufgabe „Artefakt von der Freigabe abrufen“ und kopieren die Ergebnisse der Skriptausführung in unsere Build-Umgebung. Danach speichern wir diese Dateien mit derselben standardmäßigen Aufgabe als Artefakt des Builds. Sobald die Maschine nicht mehr benötigt wird, beenden wir sie in einem letzten Schritt. Die größte Herausforderung, wie im Umfang des Artikels zu sehen, besteht darin, sich mit der Cloud zu integrieren und Kontakt mit der von Ihnen erstellten virtuellen Maschine herzustellen. Danach können Sie so viel experimentieren, wie Sie möchten.

Das ist mein erster Artikel, also urteilen Sie bitte nicht zu streng, Rückmeldungen sind willkommen.

Quelle: habr.com