docker 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.
0 Kommentare
Empfohlene Kommentare
Keine Kommentare vorhanden