KeeperOfCoffee

Hinweise
Dies wird keine Anleitung für Linuxanfänger. Es wird keine Patentrezepte zum Lösen von Problemen geben. In so gut wie jedem beschriebenem Fall wird es alternative Lösungen geben. An einigen Stellen wird etwas Vorwissen vorausgesetzt.
Motivation
Als begeisterter Windowsnutzer seit ca 15 Jahren mit etwas Langeweile, habe ich beschlossen mal etwas verrücktes zu versuchen. Die winzige 256 GB SSD meines Yoga 3 Pro war mal wieder übervoll, also wurde endlich mal eine neue gekauft auf die das Windows umziehen sollte. Was lag also näher als der kleinen SSD auf ihre alten Tage noch etwas Spaß zu gönnen. Nebenbei könnte ich auf die Art die Linuxkentnisse etwas vertiefen und sehen wie viel Spaß Linux auf dem Desktop beziehungsweise Laptop macht. Zum Einen ist dies nicht der erste Ausflug in die Linuxwelt. Erste Versuche wurden zu Zeiten von Debian 2/3 unternommen. Anfangs noch mit SuSE und Red Hat um dann recht schnell bei Debian zu landen und einige Jahre dabei zu bleiben. Zum Anderen habe ich auch beruflich ein paar Linuxserver, mit unterschiedlichen Distributionen, zu verwalten.
Fragen vor dem Anfang
Die wichtigste oder unwichtigste Frage am Anfang ist welche Distribution es werden soll. Schaut man bei Distrowatch vorbei versinkt man schnell in einer Unmenge an Varianten. Unter Hauptdistributionen findet man eine Liste der populärsten Distributionen mit einer groben Unterteilung nach Komplexität. Da schon etwas Erfahrung mit Linux vorhanden ist und ich auch nichts komplett vorgekautes benutzen wollte, hab ich mich für Arch Linux entschieden. Einige Server auf Arbeit laufen auch schon damit. Es ist also kein vollkommenes Neuland.
Die Installation
Zur Installation gibt es nicht viel zu sagen. Es gibt im Arch-Wiki eine ausführliche Anleitung, der man problemlos folgen kann sofern man lesen und tippen kann. Ein kleiner Stolperstein liegt in der Partitionierung. Früher hab ich beispielsweise /usr auf eine eigene Partition ausgelagert. Unter Arch funktioniert das nicht, da /bin und /sbin nur Symlinks auf /usr/bin und /lib sowie /lib64 Links auf /usr/lib sind. Danach fangen dann die Probleme an.
Das erste mal booten
Was zuerst auffällt ist die winzige Schrift in der Konsole, immerhin hat das Yoga 3 Pro ein QHD+ Display bei gerade mal 13 Zoll Diagonale. Zum Glück hatten schon viele ähnliche Probleme und es gibt auch dazu einen Artikel im Arch Wiki.
Danach möchte man eventuell noch etwas mehr Software installieren. Das wird aber erstmal nichts. Aus Gründen wird der "falsche" Treiber für das WLan-Modul geladen. Der falsche Treiber landet also auf der Blacklist. Ohne WLan wird es allerdings schwierig den richtigen Treiber zu bekommen. Eine Lösung dafür ist einfach nochmal das Installationsmedium zu booten und in das installierte System zu "chrooten". Im Installationssystem ist auch der richtige Treiber verfügbar und kann in das Zielsystem installiert werden. Ist das alles geschafft, darf man dann noch etwas lernen. Es gibt noch "rfkill", mit dem man Bluetooth und WLan ein- beziehungsweise ausschalten kann/darf/muss. Nun kann man das WLan mit "wifi-menu" oder "wpa_supplicant" konfigurieren und weitere Software installieren.

Vorbereitung
Als nächstes bereiten wir die Build-Umgebung vor. Wir laden Apache, PHP, passende vc_redist (17 und 13), Microsoft ODBC Treiber 13 und 17, SQLSRV5.3, und einen Oracle Instantclient herunter.
Ich überspringe an dieser Stelle einige Schritte und zeige nur die endgültige Version. Ihr verpasst aber nichts Dramatisches, der Buildprozess wurde nur einige Male verändert und die Verzeichnisstruktur entsprechend angepasst. Der Sinn oder Unsinn wird dann vermutlich klar, wenn wir uns die Dockerfiles ansehen.
Also legen wir erstmal folgende Struktur an:
Build ├───install ├───instantclient ├───webapp │   ├───Apache24 │   └───docroot └───php     └───php In install legen wir die VC Redist Installer und die ODBC Treiber MSI-Pakete ab. Ich habe die umbenannt um sie leichter unterscheiden zu können.
Den Instantclient kann man einfach entpacken und den Inhalt des instantclient_18_3-Verzeichnisses in instantclient ablegen.
In php/php wird das heruntergeladene PHP entpackt und in webapp/Apache24 der Webserver. Die httpd.conf nach Belieben anpassen, darauf achten das das DocumentRoot webapp/docroot sein soll und noch eine webapp/Apache/conf/extra/php.conf includieren. Die gibt es zwar nicht, das erledigt dann der Buildprozess.
Die php.conf kommt nach /php und sieht etwa so aus:
LoadModule php7_module "C:\webapp\php\php7apache2_4.dll" AddType application/x-httpd-php .php PHPIniDir "C:\webapp\php" DirectoryIndex index.php Nun noch PHP konfigurieren und dann sind die Vorbereitungen abgeschlossen.
Eigentlich ... also quasi schon ...
Aus irgendeinem Grund werden die Registry-Einträge für die ODBC-Treiber nicht geschrieben. Weder beim Build noch im laufenden Container. Also erstellen wir noch eine odbc.reg und legen die mit nach /install. Die Datei kann man erzeugen, indem man den Schlüssel exportiert. Dazu kann man kurzzeitig die ODBC Treiber auf dem Host installieren.

Einleitung
Die grundlegende Frage gleich vornweg: Warum sollte man Docker auf einem Windows Server betreiben?
Nunja, weil man es kann. Außerdem besteht die Infrastruktur bei den meisten unserer Kunden aus MS SQL-Server und Windows Servern auf denen unsere Software installiert wird. Hier könnte man nun argumentieren, dass unsere Software "nur" PHP und Apache benötigt und das zusammen mit PostGreSQL oder ORACLE durchaus auf Linux laufen könnte. Ja, ist richtig, wir möchten aber nicht auch noch irgendwelche Linux Installationen bei unseren Kunden pflegen.
Sucht man, naiv wie man ist, einfach mal nach "docker windows", landet man früher oder später bei "Docker CE for Window". Hat man das installiert und den ersten Container gestartet, wird einem auffallen das die Container nicht beim Booten starten. Da ist auch nichts falsch konfiguriert, das soll so sein. Dafür gibt es sicherlich Gründe. Diese Version ist für Entwickler gedacht, die Docker auf ihrem Windows 10 PC betreiben wollen. Wollen wir aber gar nicht …
Installation
Also installieren wir mal das richtige
PS> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force PS> Install-Module -Name DockerMsftProvider -Force PS> Install-Package -Name docker -ProviderName DockerMsftProvider -Force Danach möchte der Server einmal neu starten und wir können mit docker version schauen ob das funktioniert hat.
PS C:\> docker version Client: Version: 18.09.0 API version: 1.39 Go version: go1.10.3 Git commit: 33a45cd0a2 Built: unknown-buildtime OS/Arch: windows/amd64 Experimental: false Server: Engine: Version: 18.09.0 API version: 1.39 (minimum version 1.24) Go version: go1.10.3 Git commit: 33a45cd0a2 Built: 11/07/2018 00:24:12 OS/Arch: windows/amd64 Experimental: true An der Stelle konfigurieren wir den Dienst erstmal ein wenig. Das kann man prinzipiell auch über eine json-Datei erledigen. Anleitungen dazu findet man genug. Man kann die Parameter aber auch direkt dem Dienst übergeben.
PS E:\> Stop-Service Docker PS E:\> Remove-Service Docker PS E:\> New-Service -Name Docker -DisplayName "Docker Engine" -StartupType Boot -BinaryPathName "C:\Program Files\Docker\dockerd.exe --run-service -H npipe:// -H 0.0.0.0:2375 --data-root=E:\docker --experimental" PS E:\> Start-Service Docker Für Remove-Service benötigt man allerdings PowerShell Version 6. Die gibt es zwar seit August 2018, ist dennoch nicht im Server 2019 enthalten. Nach dem Neustart des Dienstes legt Docker nun seine benötigte Verzeichnisstruktur unter E:\docker an. Und durch –experimental können wir später –plattform=linux nutzen.
Nun ist es endlich soweit, wir holen unser erstes Image. Normalerweise würde man das einfach mit
PS> docker pull microsoft/nanoserver erledigen. Das funktioniert zwar, aber ...
Das was man dann bekommt ist ein Server 2016 SAC Image. Was per se zwar nicht verkehrt ist, aber im ersten Moment auf einem Server 2019 nicht funktioniert. Hier müsste man dem docker run noch ein --isolation=hyperv mitgeben oder man holt ein neues Image. Für Images die zum Server 2019 passen benötigt man spezifische Tags und kann sich nicht auf den Standard :latest verlassen. Images vom Nanoserver und Windows Server Core holen wir mit.
PS> docker pull mcr.microsoft.com/windows/nanoserver:1809 PS> docker pull mcr.microsoft.com/windows/servercore:ltsc2019 Anschließend verpassen wir den Images noch neue Tags
PS> docker image tag mcr.microsoft.com/windows/nanoserver:1809 nanoserver:1809 An dieser Stelle können wir auch schon mal einen Container mit einem der Images starten.
PS> docker run -it --name testdings microsoft/nanoserver powershell Damit bekommen wir eine PowerShell Instanz in dem laufenden Container und können Dinge tun. Updates installieren, wäre eines dieser Dinge. Das erledigt man normalerweise mit sconfig auf der geöffneten PowerShell.
In den nächsten Teilen bereiten wir die Build-Umgebung vor, basteln uns ein Dockerfile und bewundern das Ergebnis