Docker-Windows-Container mit Ansible managen (1/2)
Vorwiegend im Java-Universum bekannte DevOps-Tools wie Ansible, Vagrant und Packer verwalten neuerdings auch Windows-Maschinen. Umgekehrt ermöglichen es Docker-Windows-Container, Spring-Boot-Anwendungen unter Windows laufen zu lassen.
Manchmal kann es sogar eingefleischten Java-Entwicklern passieren, dass sie ihre Anwendungen auf Windows laufen lassen müssen – zum Beispiel weil Legacy-Code oder native Visual-C-Bibliotheken einzubinden sind, die Windows voraussetzen. Wenn der erste Schreck verflogen ist, besinnt man sich schnell wieder auf wichtige Prinzipien moderner Softwareentwicklung wie Continuous Integration und Deployment (CI/CD) oder die Automatisierung sich wiederholender Aufgaben (Infrastucture as Code). Dazu sind CI-Server wie Jenkins nötig, die mit DevOps-Tools wie Ansible eine entsprechende Infrastruktur hochziehen. Und weil alle dazu benötigten Informationen im Versionskontrollsystem abgelegt sind, passiert das alles jederzeit vollständig für jeden im Team nachvollziehbar.
Auf derartige Annehmlichkeiten will man in der "Windows-Welt" ungern verzichten, was seit Kurzem auch nicht mehr nötig ist: Seit Version 1.7 unterstützt das aus der Unix-Welt bekannte Ansible das Management von Windows-Maschinen. Dazu kommt statt SSH natives PowerShell Remoting beziehungsweise das Windows Remote Management [1] (WinRM) zum Einsatz. Zusätzlich bieten Windows 10 beziehungsweise Windows Server 2016 seit dem Anniversary-Update (ab Version 1607) die Möglichkeit, Docker-Container zu nutzen, die ihrerseits eine Windows-Umgebung bereitstellen – also nicht wie bisher gewohnt ausschließlich auf Linux basieren.
Aller Anfang ist ...
In aktuellen Softwareentwicklungsprojekten greifen Teams gern auf die Hilfe von Vagrant zurück. Mit einer einfachen Beschreibungssprache in einem sogenannten Vagrantfile und leicht erlernbaren Befehlen wie vagrant up sind schnell virtuelle Maschinen (VM) hochgefahren – inklusive entsprechender Tools und Konfiguration. Ist man üblicherweise im Linux/Unix-Umfeld zu Hause, ist einem die Vielfalt an Vagrant-Boxes (wie die vorkonfigurierten VMs auch genannt werden) der Vagrant Cloud [2] vielleicht bekannt. Schwenkt man nun hinüber ins Microsoft-Universum, sieht es leider etwas anders aus. Immerhin bietet Microsoft mit der "Vagrant Box with Windows 10 from the Microsoft Edge developer [3]" eine eigene offizielle Vagrant-Box an. Wer später Docker-Windows-Container ausführen will, sollte aktuell allerdings die Finger davon lassen. Ein Grund ist die Build-Nummer beziehungsweise das Datum der letzten Aktualisierung der genannten Vagrant-Box. Um Docker-Windows-Container betreiben zu können, benötigt man mindestens Version 10.0.14393.206. Hier entscheidet der vierte Ziffernblock! 10.0.14393.67 wie in der bereitgestellten Vagrant-Box ist in jedem Fall nicht ausreichend.
Um zu gewährleisten, dass alle Schritte vollständig nachvollziehbar bleiben und keine inoffziellen Vagrant-Boxes zum Einsatz kommen, deren Vertrauenswürdigkeit nur schwer nachprüfbar ist, gibt es nur eine Möglichkeit: eine eigene Vagrant-Box zu erstellen. Obwohl das im ersten Moment vielleicht einschüchtert, mit dem richtigen Werkzeug ist es kein großes Problem. Die Firma hinter Vagrant steht beim Bereitstellen der Boxes auf app.vagrantup.com [4] vor der gleichen Herausforderung und hat deshalb mit Packer [5] ein weiteres DevOps-Tool veröffentlicht, das ebenso wie Vagrant auf GitHub entwickelt wird und unter einer Open-Source-Lizenz jedem zur freien Nutzung verfügbar ist.
Packer ermöglicht es, aus einer ISO-Datei eine Vielzahl an Zielformaten zu erstellen – darunter die von AWS, Microsoft Azure, OpenStack, VMware und VirtualBox. Letztere lassen sich in einem Post-Processing-Schritt wiederum in Vagrant Boxes weiterverarbeiten. Das fehlende Puzzlestück ist dann nur noch ein geeignetes ISO-Abbild als Basis für den Packer-Build. Und hier kommen die Evaluation-ISOs des Windows Server 2016 [6] beziehungsweise von Windows 10 Enterprise [7] gerade richtig. Beide bieten eine 180-tägige Evaluierungslizenz, die nach einer Registrierung automatisch in das ISO-Image eingebracht wird.
Windows 10 oder Server 2016?
An dieser Stelle ein Hinweis bezüglich der für Docker-Windows-Container aktuell zu empfehlenden Windows-Version: Wie im Artikel "Windows- und Linux-basierte Docker-Container auf Windows nutzen [8]" dargestellt, gibt es zwei Arten von Windows-Containern: Windows-Server-Container mit dem sogenannten Isolation Level "process" und einem gemeinsam genutzten Windows-Kernel sowie Hyper-V-Container mit Isolation Level "hyper-v", die sich eines Hypervisors bedienen und mehr Isolation bieten.
Windows 10 unterstützt dabei ausschließlich Hyper-V-Container. Sie sind weiter von der bekannten Docker-Philosophie entfernt, eben gerade auf einen Hypervisor zu verzichten und die Ressourcen einer Maschine optimal allen Containern zur Verfügung stellen zu können. Auch wenn es vielleicht im ersten Moment so scheint, als sei der Einstieg in das Thema mit Windows 10 leichter zu meistern, ist gerade für professionelle Entwicklungsvorhaben aktuell davon abzuraten.
Da der Windows Docker Host in den meisten Fällen virtualisiert zum Einsatz kommt, lässt sich nur mit Windows 10 oder Windows Server 2016 auf einen zweiten Hypervisor verzichten. Ein im Kundenprojekt betriebener Windows-Docker-Host in VMware ESXi konnte reibungslos mit Windows Server 2016 betrieben werden, wohingegen Windows 10 nicht zu einem sauberen Docker-Betrieb zu überreden war. Obwohl sich die weiteren Schritte für beide Windows-Versionen gleichermaßen nutzen lassen, ist eine klare Empfehlung für Windows Server 2016 in produktiv genutzten Umgebungen auszusprechen.
Packer baut eine Windows-Vagrant-Box
Um das Beispiel des vorliegenden Artikels vollständig nachvollziehbar zu gestalten, liegen alle dafür notwendigen Quellen in einem GitHub-Projekt [9] bereit. Es enthält mehrere aufeinander aufbauende Schritte, die im Verlauf des Artikels näher erläutert werden. Alles für das Erstellen einer Windows-Vagrant-Box mit Packer Nötige findet sich im Verzeichnis step0-packer-windows-vagrantbox [10].
Bevor mit dem Schritt begonnen wird, sollten VirtualBox, Vagrant, Packer und Git in der aktuellen Version installiert sein. Am einfachsten funktioniert das über ein Paketmanagementsystem wie Homebrew für den Mac (z.B. per brew install packer) oder chocolatey [11] für Windows. In einem Linuxsystem verwendet man einfach den jeweils mitgelieferten Paktetmanager. Außerdem empfiehlt sich der Download einer ISO-Abbilddatei von Windows Server 2016 [12]. Liegt dann noch das GitHub-Repository lokal vor, kann es losgehen. Auf einer Kommandozeile wechselt man in das Verzeichnis step0-packer-windows-vagrantbox [13] und startet den Packer-Build mit dem folgenden Befehl (Pfeile weisen im Folgenden auf dem Layout geschuldete Zeilenumbrüche hin):
packer build -var iso_url=14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_↵
X64FRE_EN-US.ISO -var iso_checksum=70721288bbcdfe3239d8f8c0fae55f1f ↵
windows_server_2016_docker.json
Idealerweise liegt die Windows-Server-Abbilddatei im selben Verzeichnis. Der Befehl übergibt Packer den Ort des ISOs, die entsprechende Checksumme und die Konfigurationsdatei, mit der sich der Packer-Build beeinflussen lässt. Der Windows-Installationsprozess dauert eine Weile, ist jedoch vollständig automatisiert, sodass keine einzelne Benutzerinteraktion notwendig ist. Die "Unattended Installation [14]" installiert Windows Server 2016 in eine virtuelle Maschine (siehe Abb. 1).
Die Konfigurationsdatei von Packer gibt Aufschluss darüber, wie der Vorgang abläuft. Im konkreten Beispiel beginnt die Datei windows_server_2016_docker.json [15] mit der Packer-Builder-Konfiguration [16]:
"builders": [
{
"vm_name":"WindowsServer2016Docker",
"type": "virtualbox-iso",
"communicator": "winrm",
...
Außer dem Namen der virtuellen Maschine können Entwickler mit dem Schlüsselwort type definieren, dass das Ergebnis ein VirtualBox-Image sein soll. Zur Kommunikation wird statt des im Linux-Umfeld üblichen SSH wie erwähnt WinRM beziehungsweise natives PowerShell Remoting eingesetzt. Im Detail ergeben sich noch ein paar weitere Konfigurationsparameter, die etwa das Nutzerkonto, den Betriebssystemtyp oder die Hardwareausstattung der virtuellen Maschine festlegen. In der folgenden "Provisioners Section [17]" ist die Ausführung eines wichtigen Skripts konfiguriert. Die Ansible-Entwickler stellen das Ansible PowerShell Configuration Script [18] direkt bereit und ermöglichen so das Einrichten der Netzwerkeinstellungen und Firewall-Regeln für die erfolgreiche Verbindung per WinRM.
Im Beispiel schafft ein vorgelagerter Schritt im Packer-Build nahezu alle Voraussetzungen: Die Datei Autounattend.xml [19] konfiguriert außer der komplett automatisierten Windows-Installation jene Netzwerkeinstellungen für WinRM, die Ansible nachher benötigt. Unter anderem sind in ihr die Windows-Version und der Nutzer vagrant festgelegt, der in allen Folgeschritten zur Anmeldung in Windows Verwendung findet. Diese Art XML-Dateien lässt sich mit dem Windows Assessment and Deployment Kit [20] (Windows ADK) erzeugen. Hierfür ist allerdings zwingend eine Windows-Installation erforderlich. Das Beispiel-Repository liefert eine vollständig nutzbare Variante [21], sodass man sich damit nur im Ausnahmefall beschäftigen muss.
Vagrant, Marsch!
Der letzte Schritt in der Packer-Konfigurationsdatei definiert sogenannte Post-Processors [22] und dient dem eigentlichen Ziel: Er weist Packer an, eine Vagrant-Box zu erstellen. Dafür wird ein Vagrantfile-Template benötigt. Im konkreten Beispiel ist das die Datei vagrantfile-windows_2016.template [23], die wie folgt aufgebaut ist:
Vagrant.configure("2") do |config|
config.vm.box = "windows_2016_docker"
config.vm.guest = :windows
config.windows.halt_timeout = 15
# Configure Vagrant to use WinRM instead of SSH
config.vm.communicator = "winrm"
# Configure WinRM Connectivity
config.winrm.username = "vagrant"
config.winrm.password = "vagrant"
config.vm.provider "virtualbox" do |vb|
vb.name = "WindowsServer2016Docker"
# Display the VirtualBox GUI when booting the machine
vb.gui = true
# More Power for the Windows Box with Docker
vb.memory = 8192
vb.cpus = 4
end
end
Da innerhalb der Vagrant-Box das Virtualisierungsprogramm VirtualBox zum Einsatz kommt, ist eine solche virtuelle Maschine entsprechend konfiguriert. Zur Kommunikation mit ihr sind beispielsweise das bekannte WinRM sowie der Nutzer vagrant zu verwenden. Im Abschnitt config.vm.provider "virtualbox" werden dann der Name, die Arbeitsspeichergröße und die Anzahl der Prozessorkerne konfiguriert.
Nachdem der Packer-Build erfolgreich abgeschlossen wurde, ist die neue Vagrant-Box der lokalen Installation nur noch mit dem folgenden Befehl bekannt zu machen:
vagrant init windows_2016_docker_virtualbox.box
Nun lässt sich die Vagrant-Box mit Windows Server 2016 mit dem einfachen Vagrant-Befehl vagrant up hochfahren (siehe Abb. 2).
Ansible öffnet Fenster
Ob alles funktioniert hat, lässt sich mit einem einfachen Ansible-Beispielprojekt überprüfen, dass ebenfalls im GitHub-Projektverzeichnis liegt. Dazu wechselt man in das Unterverzeichnis ansible-windows-simple [24] und führt den Testbefehl ansible windows-dev -i hostsfile -m win_ping aus. Liefert er SUCCESS zurück, kann einen Schritt weiter gegangen werden. Der folgende Befehl installiert Firefox in der Windows-Vagrant-Box:
ansible-playbook -i hostsfile windows-playbook.yml --extra-vars ↵
"host=windows-dev"
Dazu ist nicht viel Code notwendig (siehe windows-playbook.yml [25]):
- hosts: "{{host}}"
tasks:
- name: Install firefox
win_chocolatey:
name: firefox
Mithilfe der sogenannten Playbooks lässt sich das Verhalten von Ansible konfigurieren. Das YAML-Dateiformat führt zu einer einfach lesbaren Syntax – einer der vielen Vorteile von Ansible. Als eines der jüngsten Provisionierungswerkzeuge nutzen es besonders gern im DevOps-Umfeld angesiedelte Entwickler. Ein weiterer Vorteil gegenüber konkurrierenden Werkzeugen wie Puppet oder Chef besteht darin, dass Ansible keinerlei Agenten auf dem Zielsystem voraussetzt. Dadurch entfallen die in der Praxis oft als anfängliche Hürde wahrgenommene Installation sowie die weitere Wartung und Pflege des Agenten.
Windows fit für Docker
Die Installation von Docker ist – zumindest zum Zeitpunkt der Veröffentlichung noch – ungleich komplexer als die von Firefox. Allerdings ist sie hervorragend geeignet, um sich intensiver mit Ansible auseinanderzusetzen. Dazu empfiehlt sich wieder das Öffnen der Kommandozeile. Um die Docker-Installation in der Windows-Vagrant-Box auszuführen, ist zunächst in das Verzeichnis step1-prepare-docker-windows [26] zu wechseln. Damit alles funktioniert, ist eine möglichst aktuelle Ansible-Installation nötig:
ansible-playbook -i hostsfile prepare-docker-windows.yml --extra-vars ↵
"host=ansible-windows-docker-springboot-dev"
Das zentrale Playbook prepare-docker-windows.yml [27] vermittelt dabei direkt einen Eindruck einer wichtigen Ansible-Philisophie, die besagt, möglichst von den Details der Provisionierung zu abstrahieren und den Nutzer davon ins Bild zu setzen, was auf dem Zielsystem passiert. Das Stichwort include bindet jeweils weitere Playbooks ein:
tasks:
- name: Check the minimum Windows build number
include: check-build-number.yml
- name: Install Windows Containers and Hyper-V Windows Features (if not ↵
already present)
include: install-windows-container-features.yml
- name: Install Docker on Windows (always the newest version) and pull needed ↵
base images
include: install-docker.yml
- name: Run a Microsoft Docker Windows Testcontainer
include: run-test-container.yml
- name: Build the springboot-oraclejre-nanoserver Docker image
include: build-springboot-oraclejre-nanoserver-image.yml
vars:
image_name: springboot-oraclejre-nanoserver
java8_update_version: 121
java_build_version: b13
server_jre_name: server-jre-8u{{java8_update_version}}-windows-x64.tar.gz
Warum es wichtig ist, mit der korrekten Build-Nummer von Windows zu starten, unterstreicht der erste Task. Er prüft, ob mindestens Version 10.0.14393.206 vorliegt. Wenn nicht, bricht er die Skriptausführung direkt ab, da kein erfolgreiches Betreiben von Windows-Docker-Containern möglich wäre. Im zweiten Task erfolgt die Installation der zwei für die Docker-Ausführung notwendigen Windows-Features Container und Hyper-V. Wie in "Windows- und Linux-basierte Docker-Container auf Windows nutzen (Teil 1 von 2) [28]" beschrieben, kann danach die Installation von Docker beginnen.
Ob alles erfolgreich installiert ist, prüft der folgende Task. Wurde der Testcontainer erfolgreich ausgeführt, lässt sich von einer lauffähigen Docker-Installation ausgehen. Im letzten Schritt wird ein eigenes Docker-Image erzeugt, dass für das Ausführen der Java- beziehungsweise Spring-Boot-Anwendungen benötigt wird.
Einheitliche Installationsverfahren
Microsoft bietet zwei Installationsanleitungen für Windows Server 2016 [29] und Windows 10 [30] an. Allerdings haben beide mit Einschränkungen zu kämpfen und sind jeweils inkompatibel zueinander. Aktuell wird beispielsweise das InstallDocker.msi nicht auf Windows Server 2016 unterstützt. Auf der anderen Seite nutzt der Installationsprozess Befehle, die unter Windows 10 schlicht nicht zur Verfügung stehen. Obwohl Microsoft mit dem neuen Paketmanager OneGet und dem entsprechenden Modul DockerMsftProvider für die Docker-Installation aus der PowerShell Gallery einen begrüßenswerten Schritt in die richtige Richtung geht, ist das Modul leider derzeit nicht zu Windows 10 kompatibel.
Der Schlüssel zur Kompatibilität liegt in den PowerShell Commandlets rund um WindowsOptionalFeature, mit denen beide Windows-Varianten arbeiten können. Die konkrete Umsetzung zeigt das Playbook install-windows-container-features.yml [31]:
- name: Check if Containers are already installed as Windows Feature
win_shell: Get-WindowsOptionalFeature -Online -FeatureName Containers |↵
Where State -CContains "Enabled"
register: check_feature_container_installed
- name: Install Containers natively as Windows Feature (only, if not already ↵
installed)
win_shell: Enable-WindowsOptionalFeature -Online -FeatureName containers -All↵
-NoRestart
when: check_feature_container_installed.stdout == ''
ignore_errors: yes
register: feature_container_installation
- name: Check if Hyper-V is already installed as Windows Feature
win_shell: Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V ↵
| Where State -CContains "Enabled"
register: check_feature_hyperv_installed
- name: Install Hyper-V as Windows Feature (only, if not already installed)
win_shell: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-↵
Hyper-V -All -NoRestart
when: check_feature_hyperv_installed.stdout == ''
ignore_errors: yes
register: feature_hyperv_installation
- name: When Containers and/or Hyper-V had to be installed, we have to reboot ↵
the Machine to have them take effect
win_reboot:
reboot_timeout_sec: 60
shutdown_timeout_sec: 60
when: feature_container_installation.changed or ↵
feature_hyperv_installation.changed
ignore_errors: yes
Für alle Aufgaben kommen sogenannte Ansible-Module zum Einsatz. In der Ansible-Dokumentation [32] findet sich eine entsprechende Liste, die aktuell mit jedem Versionssprung von Ansible deutlich an Umfang zunimmt.
Im konkreten Playbook führt zuerst das win_shell [33]-Modul einen PowerShell-Befehl aus und das Get-WindowsOptionalFeature-Commandlet [34] prüft, ob das Containers-Windows-Feature installiert ist. Ist im Feld State kein Enabled gesetzt, ist das Feature noch nicht installiert, was beim ersten Ausführen des Playbook häufig der Fall ist. Das lässt sich im nächsten Schritt mit dem Enable-WindowsOptionalFeature-Commandlet [35] und dem Befehl Enable-WindowsOptionalFeature -Online -FeatureName containers -All -NoRestart auf Windows Server 2016 und Windows 10 nachholen. Beide Schritte werden für Hyper-V ebenfalls durchlaufen.
Der letzte Schritt im vorliegenden Playbook veranlasst die Windows-Vagrant-Box via win_reboot-Modul [36] zum Neustart. Allerdings findet der Reboot nur statt, wenn die Prüfung durch das Schlüsselwort when über per register definierte Variablen ergibt, dass eines der beiden Features zu installieren ist. Andernfalls lohnt ein erneutes Hochfahren nicht.
Vollautomatische Docker-Installation
Die eigentliche Docker-Installation ist mittels Paketmanager chocolatey oder einem entsprechenden Docker-Paket [37]vergleichsweise einfach. Lediglich auf die korrekte Registrierung des Windows-Services ist zu achten. Hierzu lohnt der Blick in das Playbook install-docker.yml [38] :
- name: Checking if Docker Windows Service is already configured (to always ↵
ensure a fresh Windows Docker installation)
win_service:
name: docker
register: docker_service_info
ignore_errors: yes
- name: Stop old Docker Windows Service if there
win_service:
name: docker
state: stopped
when: docker_service_info|succeeded
- name: Remove old Docker Windows Service if there
win_shell: "C:\\ProgramData\\chocolatey\\lib\\docker\\tools\\docker↵
\\dockerd.exe --unregister-service"
when: docker_service_info|succeeded
ignore_errors: yes
- name: Install (or upgrade) Docker via chocolatey
win_chocolatey:
name: docker
state: latest
- name: Register Docker as a Windows Service
win_shell: "C:\\ProgramData\\chocolatey\\lib\\docker\\tools\\docker↵
\\dockerd.exe --register-service"
ignore_errors: yes
- name: Start Docker as Windows Service
win_service:
name: docker
state: started
- name: Pull the small Windows Docker Base Image microsoft/nanoserver from ↵
hub.docker.com
win_shell: docker pull microsoft/nanoserver
Zuerst prüft das Programm mit dem win_service [39]-Modul, ob der Docker Windows Service installiert ist. Dieser und die beiden folgenden Schritte sind bei der ersten Ausführung des Playbook auf einer neuen Windows-Maschine nicht relevant. Da aber immer mit einer frischen Docker-Installation zu starten ist, beginnt das System stets mit einem entsprechenden Test. Gibt es eine ältere Docker-Installation, ist der Windows Service im zweiten Schritt mit dem win_service [40]-Modul zu stoppen und die Registrierung durch den Befehl
dockerd.exe --unregister-service
aufzuheben. Dafür kommt wieder das win_shell [41]-Modul zum Einsatz. Docker bietet die Funktion der Registrierung sowie deren Umkehrung durch dockerd.exe an, was tunlichst zu vermeiden ist. Ein etwaiger Versuch, den Windows-Docker-Service daran vorbei mithilfe des win_service [42]-Moduls zu registrieren, führt zu einer nicht funktionsfähigen Docker-Installation.
Nun folgt die Installation von Docker mittels win_chocolatey [43]-Modul. Da es die Einrichtung des Docker Windows Service außen vor lässt, folgt dessen Registrierung auf den Fuße – dieses Mal via dockerd.exe --register-service mit dem win_service [44]-Modul. Danach lässt sich der Docker-Service starten, der nun der Windows-Diensteverwaltung bekannt ist. Im letzten Schritt des Playbooks install-docker.yml [45] wird noch eines der beiden verfügbaren Docker-Basis-Images heruntergeladen. Damit steht alles für den ersten Testcontainer bereit.
Microsoft stellt zwei Basis-Images zur Verfügung: windowsservercore [46] und nanoserver [47]. Ersteres ist trotz des Namens mit circa 10 GByte vergleichsweise groß und bietet einen nahezu vollständigen Windows Server. Das Image muss allerdings nicht zwingend zum Einsatz kommen. Nur wenn die zu dockerisierende Anwendung beispielsweise sehr spezielle Windows-Bibliotheken nutzt, ist das Image herunterzuladen. Für die meisten Anwendungsfälle sollte das viel kleinere Nanoserver-Image völlig ausreichen. Es nutzt mit circa 600 MByte wesentlich weniger Downloadvolumen und ist auch später im Betrieb deutlich handlicher.
Der erste Container
Um zu überprüfen, ob die Docker-Installation erfolgreich war, lässt sich ein einfaches Beispiel-Image mit Microsofts Dotnet-Bot [48] verwenden. Wird ein davon abgeleiteter Container mit docker run microsoft/dotnet-samples:dotnetapp-nanoserver hochgefahren, schaut einem das unten gezeigte freche Kerlchen von der Kommandozeile aus entgegen, sofern Docker sauber installiert wurde. Der Test lässt sich auch automatisiert mit einem Ansible-Skript wie run-test-container.yml [49] steuern. Als vorletzter Task in prepare-docker-windows.yml führt es zu folgender Ausgabe:
TASK [Docker is ready on your Box and waiting for your Containers :)] **********
ok: [127.0.0.1] => {
"msg": [
"",
" Dotnet-bot: Welcome to using .NET Core!",
" __________________",
" \\",
" \\",
" ....",
" ....'",
" ....",
" ..........",
" .............'..'..",
" ................'..'.....",
" .......'..........'..'..'....",
" ........'..........'..'..'.....",
" .'....'..'..........'..'.......'.",
" .'..................'... ......",
" . ......'......... .....",
" . ......",
" .. . .. ......",
" .... . .......",
" ...... ....... ............",
" ................ ......................",
" ........................'................",
" ......................'..'...... .......",
" .........................'..'..... .......",
" ........ ..'.............'..'.... ..........",
" ..'..'... ...............'....... ..........",
" ...'...... ...... .......... ...... .......",
" ........... ....... ........ ......",
"....... '...'.'. '.'.'.' ....",
"....... .....'.. ..'.....",
" .. .......... ..'........",
" ............ ..............",
" ............. '..............",
" ...........'.. .'.'............",
" ............... .'.'.............",
" .............'.. ..'..'...........",
" ............... .'..............",
" ......... ..............",
" .....",
"",
"",
"**Environment**",
"Platform: .NET Core 1.0",
"OS: Microsoft Windows 10.0.14393 ",
""
]
}
Zwischenfazit
Mit dem Ausführen des ersten Docker-Containers ließen sich mehrere wichtige Ziele erreichen. So steht dem Entwicklungsteam nun eine jederzeit automatisch und vollständig nachvollziehbare Option zum Bereitstellen einer Windows-Vagrant-Box zur Verfügung. Sie basiert ausschließlich auf offiziellen Microsoft-Images und bietet trotzdem die notwendigen Vorraussetzungen für den späteren Betrieb von
Docker – inklusive der Mindest-Build-Nummer. Außerdem ist die Windows-Vagrant-Box sofort bereit
für die Provisionierung mit Ansible, was direkt in der Installation von Docker genutzt wird. Erweitert Microsoft später einmal die Möglichkeiten des günstigeren Windows 10, lassen sich die Ansible-Skripte sogar dafür wiederverwenden. Das Setup ist zudem vergleichsweise sicher: Sollte einmal etwas bei der Arbeit mit der noch sehr jungen Technik der Docker-Windows-Container schief gehen, können Nutzer jederzeit wieder bei Null anfangen.
Damit steht alles bereit, um fachliche Anwendungen innerhalb von Docker-Windows-Containern betreiben zu können. Diese lassen sich zum Beispiel mit dem in Enterprise-Entwicklungsteams sehr beliebten Java-Framework Spring Boot [50] entwickeln. Und genau diesem Thema widmet sich ein Folgeartikel, der die notwendigen Schritte zur Provisionierung von Spring-Boot-Anwendungen in Docker-Windows-Containern mit Ansible beleuchtet.
Jonas Hecht
führten die Überzeugung, dass Softwarearchitektur und Hands-on-Entwicklung zusammengehören, zu codecentric. Tiefgreifende Erfahrungen in allen Bereichen der Softwareentwicklung großer Unternehmen treffen bei ihm auf eine Leidenschaft für neue Technologien.
(jul [51])
URL dieses Artikels:
https://www.heise.de/-3824736
Links in diesem Artikel:
[1] https://technet.microsoft.com/en-us/library/ff700227.aspx
[2] https://app.vagrantup.com/boxes/search
[3] https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/#downloads
[4] https://app.vagrantup.com/boxes/search
[5] https://www.packer.io/
[6] https://www.microsoft.com/de-de/evalcenter/evaluate-windows-server-2016
[7] https://www.microsoft.com/de-de/evalcenter/evaluate-windows-10-enterprise
[8] http://heise.de/-3735148.html
[9] https://github.com/jonashackt/ansible-windows-docker-springboot
[10] https://github.com/jonashackt/ansible-windows-docker-springboot/tree/master/step0-packer-windows-vagrantbox
[11] https://chocolatey.org/
[12] https://www.microsoft.com/de-de/evalcenter/evaluate-windows-server-2016
[13] https://github.com/jonashackt/ansible-windows-docker-springboot/tree/master/step0-packer-windows-vagrantbox
[14] https://social.technet.microsoft.com/wiki/contents/articles/36609.windows-server-2016-unattended-installation.aspx
[15] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step0-packer-windows-vagrantbox/windows_server_2016_docker.json
[16] http://www.packer.io/docs/builders/index.html
[17] https://www.packer.io/docs/provisioners/index.html
[18] https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
[19] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step0-packer-windows-vagrantbox/scripts/Autounattend.xml
[20] https://developer.microsoft.com/de-de/windows/hardware/windows-assessment-deployment-kit
[21] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step0-packer-windows-vagrantbox/scripts/Autounattend.xml
[22] https://www.packer.io/docs/post-processors/index.html
[23] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step0-packer-windows-vagrantbox/vagrantfile-windows_2016.template
[24] https://github.com/jonashackt/ansible-windows-docker-springboot/tree/master/step0-packer-windows-vagrantbox/ansible-windows-simple
[25] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step0-packer-windows-vagrantbox/ansible-windows-simple/windows-playbook.yml
[26] https://github.com/jonashackt/ansible-windows-docker-springboot/tree/master/step1-prepare-docker-windows
[27] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step1-prepare-docker-windows/prepare-docker-windows.yml
[28] https://www.heise.de/developer/artikel/Windows-und-Linux-basierte-Docker-Container-auf-Windows-nutzen-Teil-1-von-2-3735148.html
[29] https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server
[30] https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-10
[31] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step1-prepare-docker-windows/install-windows-container-features.yml
[32] http://docs.ansible.com/ansible/list_of_windows_modules.html
[33] http://docs.ansible.com/ansible/win_shell_module.html
[34] https://technet.microsoft.com/itpro/powershell/windows/dism/get-windowsoptionalfeature
[35] https://technet.microsoft.com/en-us/itpro/powershell/windows/dism/enable-windowsoptionalfeature
[36] http://docs.ansible.com/ansible/win_reboot_module.html
[37] https://chocolatey.org/packages/docker
[38] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step1-prepare-docker-windows/install-docker.yml
[39] http://docs.ansible.com/ansible/win_service_module.html
[40] http://docs.ansible.com/ansible/win_service_module.html
[41] http://docs.ansible.com/ansible/win_shell_module.html
[42] http://docs.ansible.com/ansible/win_service_module.html
[43] http://docs.ansible.com/ansible/win_chocolatey_module.html
[44] http://docs.ansible.com/ansible/win_service_module.html
[45] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step1-prepare-docker-windows/install-docker.yml
[46] https://hub.docker.com/r/microsoft/windowsservercore/
[47] https://hub.docker.com/r/microsoft/nanoserver/
[48] https://hub.docker.com/r/microsoft/dotnet-samples/
[49] https://github.com/jonashackt/ansible-windows-docker-springboot/blob/master/step1-prepare-docker-windows/run-test-container.yml
[50] https://projects.spring.io/spring-boot/
[51] mailto:jul@heise.de
Copyright © 2017 Heise Medien