Windows Server Container und Docker III

Dockerfile

Damit man nicht mit jedem Container alles neu machen muss, kann man sich über Dockerfiles eigene Images erzeugen. Die hier gezeigte Version ist mehr oder weniger die finale Version. Davor gab es natürlich diverse Fehlversuche sei es wegen eigener Fehler oder weil man manche Dinge auch einfach nicht vermutet hätte. Unter Windows Nanoserver gibt es beispielsweise gar kein msiexec und das msiexec vom Server Core schreibt die Registryeinträge gar nicht oder irgendwohin wo sie später nicht gefunden werden. Mit setx kann man zwar globale Umgebungsvariablen setzen, startet man den Apache aber als Dienst, wird die Pfadeinstellung dennoch nicht genutzt.

# Wir benutzen unser schon gepulltes Windows Servercore Image
FROM servercore:ltsc2019
COPY install /install
# Installiert die ODBC Treiber im Image
# Wer hier eine Ausgabe zum Debuggen will kann noch "/l! out13.log" anhängen
RUN ["msiexec", "/a C:\\install\\msodbcsql_13.msi", "/qn"]
RUN ["msiexec", "/a C:\\install\\msodbcsql_17.msi", "/qn"]
# Installation von VC Redist - 15 wird bei Server 2019 nicht benötigt
RUN ["C:\\install\\vc_17.exe", "/quiet", "/install"]
RUN ["C:\\install\\vc_13.exe", "/quiet", "/install"]
# Die Registry-Datei für die ODBC Treiber importieren
RUN "reg import C:\\install\\odbc.reg"
# install brauchen wir nicht mehr
RUN "RMDIR /S /Q C:\\install"
# /instantclient entspricht dann C:\instantclient im Image
COPY instantclient /instantclient
# einfach großartig - wenn jemand eine Idee hat wie ich Apache als Service erklären kann wo der instantclient liegt ...
ENV PATH="C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps;C:\instantclient"
# Apache usw. kopieren - *1
COPY webapp /webapp
WORKDIR /webapp
# wir möchten mit dem Container reden
EXPOSE 80
# kopieren von php und der php.conf ins Apache config Verzeichnis - *2
COPY php/php /webapp/php
COPY php/php.conf /webapp/Apache24/conf/extra
# zum Testen/Debuggen
#ENTRYPOINT ["cmd.exe"]
# und los geht’s
ENTRYPOINT ["C:\\webapp\\Apache24\\bin\\httpd.exe"]

Das Dockerfile kommt dann mit in das Build-Verzeichnis und das neue Image kann mit folgendem Befehl erzeugt werden.

PS E:\build\>docker build -t test .

Mit

PS E:\build\>docker run -it -p 80:80 --name test_container test

starten wir den Container und prüfen das alles wie gewünscht funktioniert. Ist das der Fall teilen wir das Dockerfile in 3 Dateien. Das Dockerfile wird dann bei *1 und *2 aufgeteilt. Der erste Teil bleibt wie er ist und wir nennen das Dockerfile core2019. Und bauen ein Image daraus.

PS E:\build\>docker image build -t core2019 -f .\core2019 .

Das zweite Dockerfile sieht dann so aus

FROM core2019:latest
COPY webapp /webapp
EXPOSE 80

und das dritte so

FROM apache_core2019:latest
COPY php/php /webapp/php
COPY php/php.conf /webapp/Apache24/conf/extra
WORKDIR /logodata
ENTRYPOINT ["C:\\webapp\\Apache24\\bin\\httpd.exe"]

Ich habe die Dockerfiles nach dem Image benannt das sie erzeugen. Die weiteren Images baue ich also mit

PS E:\build\>docker image build -t apache_core2019 -f .\apache_core2019 .
PS E:\build\>docker image build -t php_apache_core2019 -f .\php_apache_core2019 .

Damit hat man zwar etwas Overhead bei jedem Build, da jedesmal das komplette Verzeichnis zum Buildprozess übergeben wird. Allerdings können wir so sehr einfach andere PHP und/oder Apache Versionen in ein anderes Image packen ohne den Standard zu verlieren oder die grundlegende Installation wiederholen zu müssen.

Lauf Docker, Lauf!

Die entstandenen Images kann man nun wieder mit kürzeren Namen taggen und schließlich starten

PS> docker run --restart unless-stopped -d --name flamara -p 17000:80 -v E:\share\develop:C:\webapp\docroot -v E:\share\config:C:\webapp\docroot\config\ --dns=10.0.0.20 php2019:latest

Mit -p mappen wir einen Port des Hosts zu dem freigegebenen Port des Containers. Dann mappen wir mit -v zum einen die Webapplikation selbst ins docroot des Containers und auch die Konfiguration der Software.

So können wir beliebige Versionen der Software mit der gleichen Konfiguration (Benutzer, Rechte, Datenbankanbindung) in der gleichen Umgebung testen.

Die nächsten Schritte wären nun, das Ganze mit einem Linux Base-Image zur erstellen und danach automatisierte Builds.