Verwendung von Docker unter Windows im VSTS Build- und Release-Management

In meinem vorherigen Beitrag(fluentbytes.com/deploying-asp-net-4-5-to-docker-on-windows) habe ich Ihnen gezeigt, wie Sie ein Docker-Container-Image erstellen können, das eine ASP.NET 4.5-Website enthält, die auf dem vollständigen .NET-Framework läuft. In diesem Beitrag möchte ich Ihnen zeigen, wie Sie VSTS build V-next und die Release Management Tools nutzen können, um die Docker-Technologie zu nutzen.

Beginnen wir zunächst mit der Erstellung eines Docker-Images als Ergebnis unseres Builds, das wir später in der Deployment-Pipeline verwenden können, um die Website ganz einfach aus dem Container heraus zu starten und einige UI-Tests darauf auszuführen.

Erstellen des Docker-Images, das die Website enthält, aus dem Build

Wenn wir Docker als Teil unseres Builds verwenden möchten, muss der Build-Agent auf einem Host laufen, der die Docker-Funktionen eingebaut hat. Hierfür können wir entweder Windows 10 Anniversary Edition oder Windows Server 2016 Technical Preview 5 verwenden. In meinem Beispiel habe ich mich für Windows Server 2016 TP5 entschieden, da er in der Azure-Galerie verfügbar ist und eine sehr einfache Einrichtung ermöglicht. Sie wählen den Windows Server 2016 TP5 mit Containern als Basisserver und nachdem Sie diesen in Azure bereitgestellt haben, laden Sie den Build-Agent von VSTS herunter und installieren ihn auf dem lokalen Server. Nachdem der Agent ausgeführt wurde, können wir nun einen Build erstellen, der mehrere Befehle zur Erstellung des Container-Images enthält.

Zunächst müssen wir sicherstellen, dass der Build das erforderliche webdeploy-Paket und die dazugehörigen Artefakte erzeugt und diese im Artefakt-Staging-Bereich ablegt. Dazu fügen Sie einfach die folgenden msbuild-Argumente zur Build-Aufgabe der Lösung hinzu, die Teil einer standardmäßigen Visual Studio-Build-Vorlage ist.

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=$(build.stagingDirectory)

Nachdem wir das Paket erstellt und die Dateien in das Artefakt-Staging-Verzeichnis kopiert haben, fügen wir eine zusätzliche Kopieraufgabe hinzu, die die Docker-Dateien, die ich in meinem vorherigen Beitrag beschrieben habe, in das Artefakt-Staging-Verzeichnis kopiert, damit sie Teil der Ausgabe meines Builds werden. Ich lege die Dockerdateien in meinem Git-Repository ab, so dass sie Teil jedes Builds sind und versioniert werden.

Nachdem wir die Docker-Dateien kopiert haben, fügen wir ein paar Kommandozeilenaufgaben hinzu, die wir uns genauer ansehen werden.

Auf dem folgenden Screenshot sehen Sie die zusätzlichen Build-Schritte, die ich verwendet habe, damit dies funktioniert. Der erste zusätzliche Befehl, den ich hinzugefügt habe, ist der Befehl docker build, um das Image auf der Grundlage der Dockerdatei zu erstellen, die ich in meinem vorherigen Beitrag beschrieben habe. Ich habe die Dockerdatei einfach zum Git-Repository hinzugefügt, so wie Sie es normalerweise mit allen Infrastruktur-Skripten tun, die Sie haben. Die Dockerdatei enthält die korrekte Benennung des Pakets, das wir in der Aufgabe build solution erzeugen.

Sie sehen, dass ich die Argumente wie im vorherigen Beitrag übergebe, um dem Bild ein Tag zu geben, das ich später in meiner Release-Pipeline verwenden kann, um das Bild auszuführen.

Sie sehen, dass ich eine Variable $(GitVersion.NugetVersionV2) verwende. Diese Variable steht mir zur Verfügung, weil ich die Aufgabe GitVersion verwende, die Sie auf dem Marktplatz erhalten können. GitVersion bestimmt die semantische Version des aktuellen Builds auf der Grundlage Ihrer Verzweigung und Änderungen und kann durch die Verwendung von Git-Commit-Meldungen überschrieben werden. Weitere Informationen zu dieser Aufgabe und ihrer Funktionsweise finden Sie hier

Nachdem ich das Image erstellt habe, möchte ich es auch auf allen meinen Rechnern verwenden können, indem ich den Dockerhub als Repository für meine Images verwende. Der nächste Schritt ist also die Anmeldung bei dockerhub

Nachdem ich mich bei dockerhub angemeldet habe, kann ich nun das neu erstellte Image in das Repository pushen.

Und nun sind wir mit unserem Build fertig. Als nächstes verwenden wir das Image in unserer Release-Pipeline

Ausführen eines Docker-Images in der Release-Pipeline

Jetzt gehe ich zur Versionsverwaltung und erstelle eine neue Versionsdefinition. Um den Docker-Container auszuführen, muss der Release Agent auf dem Docker-fähigen Rechner ausgeführt werden, genau wie bei der Erstellung. Dann können wir auf diesem Rechner Befehle zum Ausführen des Images erteilen und es von dockerhub abrufen, wenn es auf dem lokalen Rechner nicht gefunden wird. Hier sehen Sie die Release-Pipeline mit zwei Umgebungen, Test und Produktion.

Wie Sie sehen können, ist der erste Schritt nichts anderes als das Ausführen des Befehls docker run und das Zuordnen des Ports 80 des Containers zu 80 auf dem Rechner. Außerdem verwenden wir die Option -detach, da wir nicht wollen, dass der Agent bei der Ausführung des Containers blockiert wird. Dadurch wird der Container gestartet und die Kontrolle an den Release Agent zurückgegeben. Ich übergebe auch einen Namen, damit ich später denselben Namen verwenden kann, um das Image anzuhalten und zu entfernen.

Als Nächstes führe ich eine Reihe von CodedUI-Tests durch, um zu überprüfen, ob meine Website wie erwartet läuft, und dann verwende ich den folgenden Docker-Befehl, um den Container zu stoppen:

docker stop $(docker.Prozessname)

die Variable $(docker.processname) ist nur eine Variable, die ich für diese Veröffentlichungsvorlage definiert habe und die einfach einen beliebigen Namen enthält, den ich dann schrittübergreifend verwenden kann.

Schließlich führe ich den Befehl zum Entfernen des Containers nach der Verwendung aus. Dadurch wird sichergestellt, dass ich die Pipeline nach dem nächsten Build erneut mit einem neuen Image ausführen kann

Hierfür verwende ich den Befehl docker:

docker rm -f $(docker.Prozessname)

Ich habe die Flagge -f verwendet und die Aufgabe so eingestellt, dass sie immer ausgeführt wird, so dass ich sicher sein kann, dass dieses Image auch nach einer nicht erfolgreichen Freigabe entfernt wird. Dies gewährleistet die Wiederholbarkeit des Prozesses, was natürlich sehr wichtig ist.

Zusammenfassung

Wie Sie sehen können, ist es ganz einfach, Container während des Builds zu erstellen und sie in der Release-Pipeline zu verwenden. Ich habe jetzt einfache Kommandozeilen-Tasks verwendet, um die Arbeit zu erledigen. Ich nehme an, dass es nur eine Frage der Zeit ist, bis wir einige Docker-spezifische Tasks auf dem Markt sehen werden, die wir verwenden können. Microsoft hat Docker-Tasks auf dem Markt, aber diese sind nur auf Linux ausgerichtet (zum Zeitpunkt, an dem ich dies schreibe) und erfordern eine Verbindung zu einer Linux-Docker-Maschine, um zu funktionieren. In meinem Beispiel hier konzentriere ich mich auf die Nutzung von Docker unter Windows und ich hoffe, dass wir dafür in Zukunft Tasks sehen werden.