Windows- und Linux-basierte Docker-Container auf Windows nutzen (Teil 1 von 2)

Seite 2: Image beschaffen & Container starten

Inhaltsverzeichnis

FĂĽr einen weitergehenden Test soll nun ein von Microsoft ĂĽber Dockers offizielle Registry Docker Hub bereitgestelltes Docker-Image mit Namen microsoft/dotnet-samples geladen werden. Es verwendet Windows Nano Server als Basisbetriebssystem-Image.

Der PowerShell-Befehl dafĂĽr lautet:

Pull-ContainerImage -Repository microsoft/dotnet-samples ↵
-Tag dotnetapp-nanoserver

Alternativ ist in der klassischen Eingabeaufforderung der docker.exe folgendes einzugeben:

docker pull microsoft/dotnet-samples:dotnetapp-nanoserver

Die Befehle sind jeweils "elevated", das heiĂźt, mit vollen Administratorrechten auszufĂĽhren.

Das Tag dotnetapp-nanoserver ist dabei sehr wichtig, denn ohne es wĂĽrde im Standard das "Latest"-Tag verwendet, das auf ein Linux-basiertes Image verweist, was wiederum zur Fehlermeldung "Image operating system linux cannot be used on this platform" fĂĽhren wĂĽrde. Da das Image rund zwei Gigabyte groĂź ist, kann der Download einige Zeit dauern. Die Datei landet in C:\ProgramData\docker\windowsfilter, und im Anschluss fĂĽhrt der Befehl Get-Containerimage beziehungsweise docker images sie in der Liste der installierten Images auf.

Eine Liste aller von Microsoft auf Docker Hub zur VerfĂĽgung gestellten Images ist unter https://hub.docker.com/u/microsoft/ zu finden. Hier gibt es neben den Basisbetriebssystem-Images Windows Nano Server und Windows Server Core auch welche mit installierten Anwendungen wie Internet Information Services, MySQL, Apache, .NET, .NET Core, Node.js und Ruby on Rails.

Um einen Container auf Grundlage des geladenen Docker-Images zu starten, ist einer der folgenden Aufrufe nötig:

Invoke-ContainerImage -ID microsoft/dotnet-samples:dotnetapp-nanoserver ↵
-RemoveAutomatically

oder:

Run-ContainerImage -ID microsoft/dotnet-samples:dotnetapp-nanoserver ↵
-RemoveAutomatically

oder:

docker run --rm microsoft/dotnet-samples:dotnetapp-nanoserver  

An der Konsole sieht man dann eine Begrüßung von sogenannten "dotnet-bots" in Form einer ASCII-Grafik. Die Zusätze -RemoveAutomatically beziehungsweise -rm sorgen dafür, dass der Container nach der Ausführung wieder entfernt wird. Ohne sie würden Nutzer mit den Anfragen Get-Container beziehungsweise docker ps -a einen Container im Zustand "Exited" sehen. Zu beachten ist, dass es aufgrund eines Bugs leider zu keiner Ausgabe in der PowerShell ISE kommt. Bei Invoke-ContainerImage ist folglich die normale PowerShell-Konsole zu verwenden.

Während Invoke-ContainerImage und Run-ContainerImage nach einem Image immer nur auf dem lokalen System suchen, startet docker run das Herunterladen aus dem Docker-Hub-Repository, falls das Image lokal nicht vorhanden ist.

Spannend an den PowerShell-Commandlets ist, dass sich durch die objektorientierten Pipelines auch mehrere Container aus verschiedenen Images in einem Befehl erzeugen lassen, etwa so:

Get-ContainerImage | Where-Object RepoTags -like "*dotnetapp*" | ↵
Invoke-ContainerImage

Ein Container besitzt immer zwei Identifikationsnummern: eine hexadezimale ID und einen Namen, der aus einer Zeichenkette besteht, die der Regel [a-zA-Z0-9][a-zA-Z0-9_.-] folgen muss. Wenn man einen Container anlegt, kann man ihn mit dem Parameter -Name beziehungsweise --name benennen. Sonst erzeugen die Docker-Werkzeuge einen Fantasienamen, der aus einem Adjektiv und dem Namen einer Persönlichkeit der Wissenschafts- und IT-Szene besteht (vgl. Namensgenerator), beispielsweise eager_goldstine. Zur Identifikation eines Containers kann man immer wahlweise den Namen, die ID oder auch nur einen beliebigen ersten, aber eindeutigen Teil der ID angeben. Der Name lässt sich auch bei den PowerShell-Commandlets verwenden, obwohl der Parameter dort -ID und nicht wie in der Dokumentation beschrieben -ImageIdOrName heißt. Bei Namen und ID ist die Groß- und Kleinschreibung immer relevant.

Um die Docker-Werkzeuge in Visual Studio nutzen zu können, reichen die installierten Hilfsmittel leider nicht, weshalb Entwickler auch noch "Docker for Windows" (InstallDocker.msi) installieren müssen, selbst wenn die Verwendung von Linux-Containern nicht beabsichtigt ist. "Docker for Windows" läuft ab Windows 10 November 2015 Update (alias "Threshold 2").

"Docker for Windows" verewigt sich mit einem Docker-Symbol in der Windows-Taskleiste, der virtuellen Hyper-V-Maschine MobyLinuxVM (C:\Users\Public\Documents\Hyper-V\Virtual hard disks\MobyLinuxVM.vhdx) und dem Systemdienst "Docker for Windows Service" (C:\Program Files\Docker\Docker\com.docker.service). Aufgrund einer guten Abstimmung zwischen Docker und Microsoft kann man fĂĽr Microsofts Windows Container und die Linux-basierten Container bei "Docker for Windows" die gleichen Werkzeuge, also docker.exe und die PowerShell-Commandlets fĂĽr Docker, verwenden.

"Docker for Windows" geht davon aus, dass man tatsächlich mit Linux-Containern arbeiten will. Für die Arbeit mit Windows-basierten Containern muss man daher mit dem Kontextmenüpunkt "Switch to Windows Containers" im Taskleistensymbol umschalten. Alternativ geht das an der Kommandozeile mit C:\Program Files\Docker\Docker\DockerCli.exe -SwitchDaemon.

In Visual Studio 2017 können Entwickler nun ein beliebiges Web- oder Konsolen-Projekt Docker-fähig machen. Dazu ist in einem bestehenden Projekt "Add/Docker Support" zu wählen. In diesem Beitrag wird das zunächst für das ASP.NET-Projekt "World Wide Wings" durchgespielt, das die klassische Variante dieses Webframeworks auf Basis von .NET Framework 4.x verwendet. Dadurch entsteht im Webprojekt eine Datei mit Namen Dockerfile und in der Projektmappe ein neuer Ast docker-compose (s. Abb. 2). docker-compose umfasst fünf YAML-Dateien ("YAML Ain't Markup Language"), die das Deployment und Debugging festlegen. Sie nutzen "Docker Compose File" Version 2.0, obwohl es schon eine Version 3.0 gibt.

Im Beispiel wurde die Docker-UnterstĂĽtzung fĂĽr ein bestehendes ASP.NET-4.x-Webprojekt in Visual Studio 2017 aktiviert (Abb. 2).