Schritt für Schritt: Docker Nutzung

Wenn man sich das Video "Contao und DevOps [1]", der Contao Konferenz 2018, ansieht erhält man einen Einblick in die Möglichkeiten der lokalen Contao Installation via Docker Container
und dessen Vorteile z.B. gegenüber Yeoman Automatismen [2]. Also GoodBye Xampp? Wie auch immer -
Das Video [1] greift vor und setzt eine funktionierende Docker Umgebung voraus.

UPDATE Windows Nutzer:
Die unteren Angaben beziehen sich teilweise auf die "Docker Toolbox" welche mittlerweile nicht mehr gepflegt wird (Deprecated).
Die "Docker Desktop" Installation kann mittlerweile auf "Windows 10 Pro" und "Windows 10 Home" durchgeführt werden.

Für Docker Einsteiger wie mich geht es in diesem Beitrag daher um die eigentliche Docker
Installation/Konfiguration unter Windows mit einem Blick hinter die Kulissen.

[1] Youtube: Contao und DevOps
[2] Youtube: Supercharge Team Productivity


Übersicht:

• Grundlagen Teil 1: Hardware/Software Voraussetzung u. die Docker Versionen
• Grundlagen Teil 2: Die Docker-Toolbox Installation (Windows)
• Grundlagen Teil 3: Die Docker-VM in einer anderen Partition nutzen: "D:\..."
• Grundlagen Teil 4: Die Konsolen GitBash/CMD/Powershell und "docker-machine"
• Grundlagen Teil 5: Die Docker-VM optimieren (docker volumes auf Laufwerk "D:" u. Hauptspeicher erweitern)
• Praxis Übung Teil 1: "Dokerfile" u. "docker build"
• Praxis Übung Teil 2: "docker-compose.yml" u. "docker-compose" mit node.js/node-sass u. nginx Webserver
• Fazit und Links
• Update: Schritt für Schritt: Docker als XAMPP Alternative

Grundlagen Teil 1: Hardware/Software Voraussetzung

Hardware Voraussetzung
Zur Nutzung jedweder Virtualisierungs-Technologie werden bestimmte CPU Anforderungen (VT-x, SLAT etc.) gestellt. Die Terminologie ist bei jedem Hersteller etwas anders.
Es gibt zwei Möglichkeiten: Ihre CPU unterstützt die Technologie o. diese ist vorhanden aber deaktiviert und muß dann halt - aktiviert werden.
Um Ihre Hardware zu überprüfen könnte das Betriebssystem Auskunft [1] geben oder Sie nutzen entsprechende Check Tools der Hersteller [2].

Genügt die CPU den Anforderungen nicht, brauchen Sie jetzt nicht mehr weiterlesen ...

[1] Virtuaisierungs Check/Aktivierung
[2] Tools Intel/AMD


Software Voraussetzung
Die CPU Anforderungen sind OK?
Jetzt benötigen Sie entsprechende Software - Die Hypervisor. Es wird unterschieden zwischen Typ-II Hypervisor (z.B: Oracle Virtualbox [1]) und Typ-I Hypervisor.
Letztere sind native Umsetzungen die das jeweilige OS bereitstellt - Im Falle von Windows wäre dies "Hyper-V [2]".
Grundsätzlich können Sie Typ-I auf jedem OS nutzen. Prinzipiell auch auf einem Windows mit Hyper-V Unterstützung. Faustregel: Allerdings nicht pararllel!
In diesem Fall müßte Hyper-V dann zunächst deaktiviert werden. Warum sollte man?
Zu den Vor- und Nachteilen bemühen Sie die Suchmaschine.

[1] Oracle Virtualbox
[2] Microsoft Hyper-V


Docker Versionen
Was hat das alles mit Docker zun?
Wenn Sie "Docker für Windows [1]" o. "Docker für Mac [2]" installieren möchten, setzen diese auf entsprechende Hypervisor vom Typ-I.
Windows "Hyper-V" wird jedoch ab z.B. "Windows 10 Pro" o. "Enterprise" Versionen unterstützt. Sie haben nur "Windows 10 Home" o. "Windows 7" oder ältere Mac OS's?
Abhilfe für ältere OS Versionen liegt mit der "Docker-Toolbox [3]" vor.

[1] Docker für Windows
[2] Docker für Mac
[3] Docker-Toolbox


Die Docker-Toolbox
Warum soll ich eine "ältere" Docker Version nutzen?
Die Frage ist so schon falsch gestellt.
Bei der "Docker-Toolbox [1]" handelt es sich lediglich um eine andere Herangehensweise. Docker, genauer die Docker-Engine,
benötigt einen minimalen Linux-Kernel, der eben bei der Toolbox über eine virtuelle Maschiene via "Oracle Virtualbox" (Hypervisor Typ-II) bereitgestellt wird.
Die Docker Komponenten an sich (Docker-Machine, Docker-Compose etc.) entsprechen ansonsten dem normalen Release Plan [2] und werden auf Github [1] weiter aktuell gehalten.

[1] Download/Releases: Docker-Toolbox
[2] Docker CE release notes

Grundlagen Teil 2: Die Docker-Toolbox Installation (Windows)

Die folgenden Angaben basieren auf einem älteren "DELL XPS/Intel Core i7", "Windows 7 Home Premium/64Bit" und
Administrator-Rechten mit folgender Verzeichnisstruktur:

• D:\docker
• D:\docker\toolbox
• D:\docker\vm

Die Docker-Toolbox Installation [1] ist eine normale Windows Installation und beinhaltet, neben den Docker-Komponenten, die "Virtualbox [2]", "Git für Windows [3]" -
zur Nutzung von u.a. "GitBash [4]". Was in welchem Release in welcher Version zur Verfügung steht entnehmen Sie den Release Angaben in [1].
Im Grunde laden Sie sich nur die, zu diesem Zeitpunkt, aktuelle "DockerToolbox-18.06.0-ce.exe" herunter und belassen die Default Einträge der Installation.

Ich hatte bereits sowohl die "Virtualbox v.5.2.16" und "Git/GitBash v.2.18.0" separat installiert und aktuell gehalten.
In diesem Fall deaktivieren Sie einfach diese Angaben während der Docker-Toolbox Installation.
Wichtig ist hierbei nur, das die Virtualbox nicht bereits eine VM namentlich "default" enthält.
Da wir ja Docker nutzen möchten, benötigen Sie grundsätzlich gar keine weiteren VM Einträge mehr in der Virtualbox.

Ich habe die Docker-Toolbox nach "D:\docker\toolbox" installiert. Ich beziehe mich im folgenden auf dieses Verzeichnis.
Sollten Sie ein anderes Verzeichnis bevorzugen - Pfade entsprechend übertragen ...
Anschließend: Rechner Neustart.

[1] Download/Releases: Docker-Toolbox
[2] Oracle Virtualbox
[3] Download: Git für Windows
[4] Was ist GitBash


Nach der Installation sollten Sie auf dem Desktop die folgenden Verknüpfungen sehen:

• Oracle VM VirtualBox
• Docker Quickstart Terminal
• Kitematic (Alpha)
• GitBash

Starten Sie die Virtualbox (GUI). Die Liste (linke Seite) sollte jungfräulich leer sein.
Damit Sie Docker nutzen können muß zunächst eine VM ( basierend auf einem minimalen Linux Kernel ) mit der Docker-Engine installiert werden.
Dies übernimmer das "Docker Quickstart Terminal". Letztlich nutzt diese lediglich eine GitBash Instanz
und ruft das Script "start.sh" - im Installations-Verzeichnis - bei mir:"D:\docker\toolbox" - auf.

Klicken Sie also auf "Docker Quickstart Terminal". Es öffnet sich ein Konsolen-Fenster mit diversen Hinweis Texten. Das kann etwas dauern.
Am Ende sollten Sie das Docker Symbol (Wal) sehen und eine Message der Art:

Zitat:

---

docker is configured to use the default machine with IP 192.168.99.100
For help getting started, check out the docs at https://docs.docker.com

---

Schließen Sie das Fenster und starten eine neue GitBash Konsole.
Geben Sie in der GitBash Konsole ein:

Code:

---


docker version

---

Starten Sie die Windows CMD-Konsole und geben hier "docker version" ein. Gleiche Ausgabe ...

Zitat:

---

Hinweis 1: Systemvariable setzen

Sollten Sie dabei sowas wie "command not found" erhalten:
Die Docker-Toolbox trägt ihren Installationspfad in den Windows Umgebungsvariablen als Benutzervariable mit Namen "DOCKER_TOOLBOX_INSTALL_PATH" ein.
Ich habe meinen Installationspfad "D:\docker\toolbox" dann zusätzlich unter Path der Systemvariablen hinzugefügt. Im Anschluß konnte ich die Docker Befehle überall nutzen.

---

Die Docker-VM: Starten/Beenden/Entfernen

In der Virtualbox:
- Markieren Sie die "default" VM / RechtsKlick / "Starten/Ohne GUI starten"
- Markieren Sie die "default" VM / RechtsKlick / "Schließen/Ausschalten" (Nie "Zustand sichern")
- Markieren Sie die "default" VM / RechtsKlick / "Entfernen/Alle Daten löschen"

Pendants in der Konsole wären:
- docker-machine start
- docker-machine stop
- docker-machine rm -f default

Zitat:

---

Hinweis 2: Docker-VM beenden

Wenn Sie nicht mehr mit Docker arbeiten vergessen Sie nicht die Docker-VM auszuschalten.
Ansonsten läuft diese auch nach einem Rechner Neustart weiterhin und verbraucht Ressourcen.

---

Doker-VM Pfade:
Was passiert im Hintergrund? Wo liegen meine Daten?
Die Folgen des Aufrufs "Docker Quickstart Terminal" kann unter "Windows 7" wie folgt nachvollzogen werden:

In der "C:\users\[DeinUsername]\.Virtualbox\VirtualBox.xml" sehen Sie die installierte Docker-VM ( Abschnitt <MachineRegistry> ).
Unterhalb von "C:\users\[DeinUsername]\.docker\machine" finden Sie diverse Ordner. Die aktuelle Docker-VM unter:
"C:\users\[DeinUsername]\.docker\machine\machines\default"

Und hier die jeweilige Konfiguration in:
"C:\users\[DeinUsername]\.docker\machine\machines\default\config.json"

Genau diese Angabe erhalten Sie auch über die Konsole mit Eingabe von:

Code:

---


docker-machine inspect

---

Einblick in die Doker-VM Einstellungen:
Wechseln Sie zur Virtualbox. Hier sehen die erzeugte VM mit Namen "defaul" - upundrunning. Es handelt sich also um eine "normale" VM innerhalb der Virtualbox.
Markieren Sie die VM und klicken auf "Ändern". Hier sehen Sie unter "Massenspeicher" wohin installiert wurde und unter "Netzwerk" welche Adpater Einstellungen vorgenommen worden sind.
Weitere Infos erhalten Sie über "Datei/Manager für virtuelle Medien" bzw. "Datei/Host-only Netzwerk Manager". Diese Angaben spiegeln die installierten Netzwerk-Adapter wieder.

Schauen Sie es sich an:
Unter "Systemsteuerung\Netzwerk und Internet\Netzwerkverbindungen" sehen Sie eben diese Netzwerk-Adapter die während der Virtualbox/Toolbox Installation eingerichtet wurden.
Vergewissern Sie sich das die Option "VirtualBox NDIS6 Bridged Networking Driver" in beiden Adaptern vorhanden und aktiviert ist.
Hierzu Adapter markieren und "rechte Maus/Eigenschaften" aufrufen.


Kitematic:
Die Docker Nutzung ist vielfälltig. Sie können Images lokal/manuell erstellen (Dockerfile u. docker build [1]),
aus einem fertig konfigurierten Container ein Image – also ein Abbild des Containers – erzeugen,
mehrere Container orchestrieren (docker-compose.yml u. docker-compose [2][3]) usw..
Wer fertige Container heranziehen möchte kann "Docker Hub [4]" nutzen.

"Docker Hub" ist das Pendant zu packagist.org - halt für Docker. Kitematic dann quasi der "Contao Manager" für "Docker Hub".
Vorweg: Die Kitematic (GUI) bietet nichts was Sie nicht auch auf der Konsole erreichen könnten. Die Suche auf "Docker Hub" könnten Sie zudem auch über einen normalen Browser anstoßen.
Da es aber da ist: Klicken Sie auf "Kitematic (Alpha)".

Beim ersten Start werden Sie nach einem "Docker Hub Account" gefragt. Den benötigen Sie nur wenn Sie auf "Docker Hub" publizieren möchten - dieser Schritt kann übergangen werden.
Im Anschluß sucht Kitematic nach einem native Setup, da wir dies nicht haben klicken Sie im Anschluß auf den "Use Virtualbox" Button.

Sie können dann innerhalb von Kitematic ihre lokalen Images/Container einsehen/pflegen oder sich einfach eine Übersicht verschaffen.
Unten links erreichen Sie noch Verknüpfungen zu weiteren Kitematic Einstellungen bzw. können eine Konsole starten.

[1] docker build
[2] docker-compose
[3] docker-compose Syntax Versions: file versions and upgrading
[4] Docker Hub


Docker Update:
Schauen Sie ab und an die aktuellen Docker-Toolbox Releases ein [1]. Sollten neuere Versionen vorliegen dann einfach downloaden und installieren.

[1] Download/Releases: Docker-Toolbox

Grundlagen Teil 3: Die Docker-VM in einer anderen Partition nutzen: D:\...

Die aktuelle Docker-VM liegt also auf Laufwerk "C:" unterhalb von "C:\users\[DeinUsername]\.docker".
Wenn Sie jetzt mit Docker arbeiten benötigen die Images/Container Speicherplatz.
Wo werden die abgelegt? Innerhalb der Docker-VM ...

Code:

---


docker system info

---

gibt Auskunft u.a.: Docker Root Dir: /mnt/sda1/var/lib/docker

Code:

---


docker system df

---

gibt einen Überblick über den Verbrauch. Da wir noch nichts gemacht haben gibt es hier nicht viel zu sehen.
Wie gesagt ändert sich das möglicherweise rapide sobald mit Docker gearbeitet wird.

In den meisten Fällen reicht dann möglicherweise der Speicherplatz auf "C:" nicht aus.
Im folgenden werden wir die Docker-VM nach "D:\docker\vm" installieren.


Vorbereitung: Aufräumen
Beenden Sie die laufende Docker-VM und entfernen diese anschließend:

Code:

---


docker-machine stop
docker-machine rm -f default

---

Zitat:

---

Achtung:
Hiermit entfernen Sie alle bereits vorhandene Docker Images/Container.

---

Löschen Sie das Verzeichnis "C:\users\[DeinUsername]\.docker".
In den "Systemeigenschaften/Umgebungsvariablen" löschen Sie - vorsichtshalber - unter "Benutzervariablen"
alles was mit Docker zu hat (COMPOSE_CONVERT_WINDOWS_PATHS, NO_PROXY, DOCKER_*.*) ...
bis auf "DOCKER_TOOLBOX_INSTALL_PATH" ( Normalerweise aber nicht notwendig ).

Wir haben wieder den ursprünglichen Ausgangszustand nach der "Docker-Toolbox" Installation erreicht.


Neue Systemvariable setzen
In den "Systemeigenschaften/Umgebungsvariablen" setzen Sie nun in den "Systemvariablen" einen neuen Eintrag:

• Name der Variablen: MACHINE_STORAGE_PATH
• Wert der Variablen: D:\docker\vm\machine

Zitat:

---

Hinweis:

Der erste Teil der Pfadangabe "D:\docker\vm" ist beliebig wählbar.
Die Angabe "\machine" aber zwingend!

---

(Erneute) Installation Docker-VM
Starten Sie wieder das "Docker Quickstart Terminal". Im Anschluß schließen Sie das Fenster.
Starten die GitBash-Konsole und die CMD-Konsole jeweils mit den Befehlen (nacheinander):

Code:

---


docker version
docker-machine ip
docker-machine ls

---

Checken Sie die Umgebungsvariablen in der GitBash-Konsole mit:

Code:

---

env | grep 'DOCKER_\|COMPOSE\|NO_PROXY'

---

Solange die Systemvariable "DOCKER_TOOLBOX_INSTALL_PATH" existiert werden fortan
Ihre lokalen Docker-VM's immer in das angegebene Laufwerk/Verzeichnis - hier unterhalb von "d:\docker\vm" - installiert.

Zitat:

---

Man könnte die Docker-VM auch via Konsole mit dem Flag --storage-path (s. docker-machine --help ) installieren.
Aber dann mußte ich dieses Flag bei jedem docker-machine Kommando mitschleppen und Kitematic wollte auch nicht mehr ...

---

Grundlagen Teil 4: Die Konsolen GitBash/CMD/Powershell und "docker-machine"

Ein kleiner Ausflug.
Die Installation einer Docker-VM via "Docker Quickstart Terminal" kann man auch manuell über die Konsole einleiten - "docker-machine create --help".

Also derart:

Code:

---


docker-machine create --driver virtualbox default

---

Der Aufruf "docker version" liefert im Anschluß einen Fehler. Warum? Die Umgebungsvariablen sind noch nicht gesetzt.
Den Docker-Clients muß mitgeteilt werden welche Docker-VM heranzuziehen ist.
Docker gibt hierbei selbst Auskunft was zu tun ist:

Code:

---


docker-machine env --no-proxy default

---

Ausgabe:

Zitat:

---

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.102:2376"
export DOCKER_CERT_PATH="C:\Users\[DeinUsername]\.docker\machine\machines\default"
export DOCKER_MACHINE_NAME="default"
export COMPOSE_CONVERT_WINDOWS_PATHS="true"
export no_proxy="192.168.99.100,192.168.99.102"
# Run this command to configure your shell:
# eval $("D:\docker\toolbox\docker-machine.exe" env --no-proxy default)

---

Die Ausgabe kann bei ihnen anders lauten - entsprechend Ihres "Docker-Toolbox" Installation-Pfads - bei mir also "D:\docker\toolbox\docker-machine.exe"

Der Befehl setzt nicht die Umgebungsvariablen sondern zeigt Sie nur an. Die Ausführung wie in den Kommentaren erwähnt muß man selber ausführen.
Machen wir also was uns gesagt wird und geben in der GitBash-Konsole ein:

Code:

---


eval $("D:\docker\toolbox\docker-machine.exe" env --no-proxy default)

---

Im Anschluß ein "docker version" und wir erhalten keinen Fehler mehr. Schließen Sie GitBash-Konsole und starten Sie neu.
Mit "docker version" erhalten wir wieder den Fehler.

Gleiches werden Sie in der CMD-Konsole erleben,
wobei die Ausgabe von "docker-machine env --no-proxy default" anders ist - passend zur jeweiligen Konsole/Shell.

Zitat:

---

Fazit:
Das Setzen der Umgebungsvariablen gilt nur für die jeweilige Konsole und nur für deren Laufzeit.

---

Um dies dauherhaft zu setzen geben Sie in der GitBash-Konsole folgendes ein:
(Verbreitern Sie das Konsolen Fenster - Der Befehl muß in einer Zeile stehen.)

Code:

---


eval "$("D:\docker\toolbox\docker-machine.exe" env --shell=bash --no-proxy default | sed -e "s/export/SETX/g" | sed -e "s/=/ /g")" &> /dev/null

---

Starten und Schließen Sie die CMD/GitBash Konsolen und testen mit "docker version".

Was der Befehl genau beinhaltet? Keinen Schimmer - bin kein Linux Fachmann.
Ich habe diesen lediglich dem "start.sh" Script entnommen. Irgendwo ab Zeile 79 wird genau dies aufgerufen und ist kommentiert.
Nutzen Sie also einfach weiter das "Docker Quickstart Terminal" ...


Schönen Dank - Wozu dann das ganze?
Testen Sie die Befehle "docker-machine active" bzw. "docker-machine ls". Letzterer gibt sowas aus wie:

Code:

---

NAME      ACTIVE  DRIVER      STATE    URL                        SWARM  DOCKER        ERRORS
default  *        virtualbox  Running  tcp://192.168.99.100:2376          v18.06.0-ce

---

Wichtig ist in diesem Zusammenhang das "Sternchen" unterhalb von "Active". Die Eingabe von "docker-machine active" sollte zum gleichen Ergebnis führen:
Dem Namen unserer bislang einzigen Docker-VM namentlich: "default". Hierzu gleich mehr ...

Im Normalfall reicht unsere aktuelle Umsetzung allemal aus.
Sie werden eigentlich nie in die Verlegenheit kommen mehr als eine Docker-VM zu nutzen.
Gleichwohl Docker hierbei durchaus unterschiedliche Möglichkeiten über die "Driver" - auch für clouds - vorhält [1].

[1] Docker Machine Drivers


Angenommen Sie hätten eine zweite VM mit Namen "dev" installiert. Die Ausgabe von "docker-machine ls" wäre z.B:

Code:

---

NAME      ACTIVE  DRIVER      STATE    URL                        SWARM  DOCKER        ERRORS
default  *        virtualbox  Running  tcp://192.168.99.100:2376          v18.06.0-ce
dev      -        virtualbox  Running  tcp://192.168.99.102:2376          v18.06.0-ce

---

Alle Befehle der Docker-Clients beziehen sich auf die als "aktiv" markierte VM. Wie wechselt man nun in der Konsole die VM?
Über die Umgebungsvariablen s.o.

In diesem Beispiel dann mit Befehl: "eval $("D:\docker\toolbox\docker-machine.exe" env --no-proxy dev)" in der Konsole.
Die Abfrage "docker-machine active" würde dann "dev" ausgeben.

Grundlagen Teil 5: Die Docker-VM optimieren (f. docker volumes auf Laufwerk "D:" u. Hauptspeicher erweitern)

Wir haben unsere Docker-VM nach Laufwerk "D:\..." ausgelagert und wir wissen wozu die "docker-machine" zuständig ist,
bzw. das das "Docker Quickstart Terminal" lediglich das "start.sh" Script u.a mit ensprechenden Befehlen abarbeitet.
Im folgenden noch ein, zwei Hinweise.

Vorbereitung für die Arbeit mit Docker Volumes auf Laufwerk "D:"

Wenn Sie mit Docker arbeiten werden Sie auf "Volumes" stoßen. Die ermöglichen u.a. die Synchronisierung zwischen Ihren
"lokalen" Host-Verzeichnissen und den Verzeichnissen in einem Docker Container.

Wenn Sie hier ebenfalls mit Verzeichnissen z.B. auf Laufwerk "D:" arbeiten möchten wird dies so zunächst nicht funktionieren.
Wir müssen der Docker-VM zunächst den Zugriff ermöglichen.

Starten Sie die Virtualbox GUI und markieren die "default" VM.

- Beenden Sie die VM über "Schließen/Ausschalten"
- Klicken Sie auf "Ändern/Gemeinsame Ordner"

Hier befindet sich bereits ein Eintrag für den Pfad "c:\Users". Erstellen Sie einen weiteren Eintrag:

- Ordner-Pfad: d:\
- Ordner-Name: d

- Aktivieren Sie "Automatisch einbinden"
- Aktivieren Sie "Permanent erzeugen"

- Starten Sie die VM über "Starten/Ohne GUI starten"

Im Anschluß können Sie sich auf den Ordnername unter Windows z.B. wie folgt beziehen:

Auf der Konsole z.B.:

Code:

---

docker run --rm -it --name=test0815 -v //d/docker/nginx/www:/usr/share/nginx/html nginx:latest

Oder innerhalb von "d:\docker\nginx" z.B.:
docker run --rm -it --name=test0815 -v //$PWD/www:/usr/share/nginx/html nginx:latest

---

Innerhalb einer "docker-compose.yml" z.B:

Code:

---

  volumes:
    - //d/docker/dev/ctsmedia/src/css:/var/www/share/project/files/theme
    - $PWD/src/templates:/var/www/share/project/templates

---

Update Hinweis: Symlink Probleme
Wer mit Symlinks ( ln ) Probleme hat o. Fehlermeldungen erhält:

Die Virtualbox - ab einer bestimmten Version / weiß nicht mehr genau - verhindert für hinzugefügte "shared volumes"/"Gemeinsame Ordner" per Default das symlinking:
Checken kann man dies via:

Code:

---

VboxManage getextradata default enumerate

Ausgabe:
Key: VBoxInternal2/SharedFoldersEnableSymlinksCreate/c/Users, Value: 1

---

Setzen kann man die Erlaubnis dann mit:

Code:

---

VBoxManage setextradata default VBoxInternal2/SharedFoldersEnableSymlinksCreate/d 1

---

wobei "default" hier der VM Name und "d" der shared volume Name ist.

Code:

---

VboxManage getextradata default enumerate

Ausgabe dann:
Key: VBoxInternal2/SharedFoldersEnableSymlinksCreate/c/Users, Value: 1
Key: VBoxInternal2/SharedFoldersEnableSymlinksCreate/d, Value: 1

---

Siehe auch:
- https://www.virtualbox.org/ticket/10085
- https://ahtik.com/fixing-your-virtua...symlink-error/
- http://jessezhuang.github.io/article/virtualbox-tips/



Mehr Hauptspeicher für die Docker-VM
Wenn Sie sich die "System-Anzeigen" für "Hauptspeicher" u. "Processor" der Docker-VM ansehen, werden Sie feststellen,
das diese hier nicht verändert werden können. Diese wurden beim Anlegen der VM auf die Standardwerte festgelegt.

Sie können diese Werte nachträglich verändern. Starten Sie die GitBash-Konsole und geben nacheinander ein:

Code:

---


docker-machine stop
VboxManage modifyvm default --memory 4096
docker-machine start

---

Zitat:

---

Hinweis:

Wenn Sie sowas wie "command not found" erhalten. Starten Sie den Befehl "VboxManage" entweder innerhalb Ihres
"Oracle Virtualbox" Installations Verzeichnisses oder tragen dieses einfach in den Pfad der Systemvariablen ein.

---

Damit haben Sie die Größe des "Hauptspeichers" für die Docker-VM erhöht.
Wenn Sie Probleme z.B: mit dem Laden von Paketen über den Contao-Manager haben sollten,
erhöhen Sie den Hauptspeicher wie beschrieben oder nutzen ansonsten die Contao-Manager Cloud.

Die Größenangabe ist selbstverständlich abhängig von den vorhandenen Ressourcen und
kann Ihren Host beeinträchtigen solange die VM läuft ...

Sie können dies auch direkt über die "docker-machine" beim Erstellen der Docker-VM (s.o.) erreichen:

Code:

---


docker-machine create --driver virtualbox  --virtualbox-memory=4096 default

---

Ergänzen Sie die Direktive "--virtualbox-memory=4096" z.B. im "start.sh" Script.
Im Anschluß steht der angegebene Hauptspeicher auch immer bei Ausführung des "Docker Quickstart Terminal" zur Verfügung.

Praxis Übung Teil 1: "Dokerfile" u. "docker build"

Erstellen Sie sich ein Verzeichnis "docker-test" auf Laufwerk "D:". Starten Sie die GitBash-Konsole und wechseln Sie in dieses Verzeichnis.
Erstellen Sie eine Datei "Dockerfile" (case sensitive / ohne Endung) mit folgendem Inhalt:

Code:

---

FROM alpine:3.7

RUN apk add --update
RUN apk add nodejs
RUN rm -rf /var/cache/apk/*

---

Wir erstellen uns ein neues Image "dev/alpine-nodejs" in der Version 1.0 mit:

Code:

---

docker build . -t dev/alpine-nodejs:1.0
docker images

---

Wir haben hiermit ein Image via "Dockerfile" erstellt, welches lediglich "nodejs" installiert.
Das Beispiel erhebt keinen Anspruch auf eine vollwertig, konfigurierte node.js Umgebung!
Es dient lediglich als Beispiel zur generellen "Dockerfile" Nutzung ...


Das "Dockerfile" und die Layers
Jedes einzelne Kommando in einem "Dockerfile" erzeugt einen sogenannten Layer. Stellen Sie sich den einzelnen Layer wie z.B. ein jeweiliges "git commit" vor.
Je mehr Layer vorhanden sind, desto größer wird auch das Image. Wenn Dateigröße eine Rolle spielt, sollte man die Befehle im "Dockerfile" möglichst zusammenfassen.

Um dies zu checken geben Sie ein:

Code:

---

docker history dev/alpine-nodejs:1.0

---

Wir könnten jetzt im "Dockerfile" die Kommandos wie folgt zusammenfassen:

Code:

---

FROM alpine:3.7

RUN apk add --update \
    nodejs \
    && rm -rf /var/cache/apk/*

---

Noch einfacher für dieses Beispiel wäre:

Code:

---

FROM alpine:3.7

RUN apk --no-cache add nodejs

---

( Siehe: GitHub: docker-alpine )

Speichern Sie die Änderungen im "Dockerfile" ab,
erstellen Sie ein neues Image in der Version 1.1 und vergleichen die Dateigrößen:

Code:

---

docker build . -t dev/alpine-nodejs:1.1

docker images
docker history dev/alpine-nodejs:1.0
docker history dev/alpine-nodejs:1.1

---

Zitat:

---

Hinweis:

Best practices for writing Dockerfiles - s.: [1]
Noch einen Schritt weiter könnten Sie mit Nutzung der docker Multi-Stage Builds [1] gehen ...

[1] Doku: Best practices for writing Dockerfiles
[2] Doku: Use multi-stage builds

---

Praxis Übung Teil 2: "docker-compose.yml" u. "docker-compose" mit node.js/node-sass u. nginx Webserver

Wir haben Docker Images mit einer exemplarischen "nodejs" Installation erstellt. Diese liegt zum Glück bereits fertig konfiguriert vor [1].
Löschen Sie die bestehenden Images ("docker rmi --help") oder räumen komplett auf mit "docker system prune -a --volumes":
Vorsicht: Das löscht sämtliche, bestehenden docker Umsetzungen ...

[1] DockerHub: node

Im folgenden werden wir "node.js" mit einem "node-sass" Modul zur Kompilierung von .scss Daten erstellen
und unsere Ergebnisse gleich über einen "nginx" Webserver zur Anzeige bringen.
Legen Sie sich auf Laufwerk "D:" folgende Verzeichnisstruktur an:

• D:\docker-nodejs
• D:\docker-nodejs\src
• D:\docker-nodejs\src\scss
• D:\docker-nodejs\src\css
• D:\docker-nodejs\src\www

Erstellen Sie in "D:\docker-nodejs\src\scss" eine "theme.scss":

Code:

---

@charset "UTF-8";

// scss Comment ...
$bgcolor: yellow;

/* CSS Comment ... */
body {
  background: $bgcolor;
  margin: 0;
  padding: 0;
}

---

Erstellen Sie in "D:\docker-nodejs\src\www" eine "index.html":

Code:

---

<html>
<head>
<link rel="stylesheet" href="css/theme.css">
</head>
<body>
<h1>Willkommen</h1>
</body>
</html>

---

Erstellen Sie in "D:\docker-nodejs" eine "package.json":

Code:

---

{
  "name": "boilerplate",
  "version": "1.0.0",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "sass": "node-sass src/scss -o src/css --recursive ",
    "dev:sass": "npm run sass -- --output-style expanded --source-map true ",
    "predev:watch": "npm run dev:sass",
    "watch": "npm run dev:sass -- -w",
    "prod:sass": "npm run sass -- --output-style compressed"   
  },
  "license": "MIT",
  "dependencies": {
    "node-sass": "^4.9.3"
  }
}

---

Erstellen Sie in "D:\docker-nodejs" ein "Dockerfile":

Code:

---

# Base Image
FROM node:8.11.3-alpine

# Copy package.json - relative from current directory to /nodeapp folder in container
COPY /$PWD/package.json /nodeapp/package.json

# Set working directory in container
WORKDIR /nodeapp

# Install node modules from package.json in working directory
RUN npm install

---

Erstellen Sie in "D:\docker-nodejs" eine "docker-compose.yml":

Code:

---

# Syntax Version - see https://docs.docker.com/compose/compose-file/compose-file-v2/
version: '2.2'
 
services:
  # service "nodejs": Use node.js with node-sass
  nodejs:
    container_name: node-sass
    build:
      context: .
      dockerfile: Dockerfile
    image: dev/nodejs:1.0
    working_dir: /nodeapp
    environment:
      - NODE_ENV=production
    volumes:
      - $PWD/package.json:/nodeapp/package.json
      - $PWD/src:/nodeapp/src
    init: true
   
    # [1] Possible Start Command - Better ommit and use in console:
    # "docker-compose run --rm nodejs sh"
    # or "winpty docker-compose run --rm nodejs sh"
    # Here we can then work with npx / npm as usual ...
    # [2] Using "exec form" here:
    # to process running as PID 1
    #command: ["npm", "run", "watch", "--silent"]
   
  # service "web": Use nginx webserver
  web:
    container_name: webserver-nginx
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - $PWD/src/www:/usr/share/nginx/html
      - $PWD/src/css:/usr/share/nginx/html/css

---

Starten Sie die GitBash-Konsole und wechseln in das Verzeichnis "D:\docker-nodejs".
Geben Sie "docker-machine ip" ein und merken Sie sich die IP-Adresse - in meinem Fall: 192.168.99.100

Wenn Sie jetzt zum ersten Male den Befehl "docker-compose up" eingeben passiert folgendes:

- Es werden unsere Images erzeugt/geladen
- Es werden Container "node-sass"/"webserver-nginx" erstellt - entsprechend den Angaben in Services "nodejs" und "web"
- In der letzten Zeile erhalten Sie eine Ausgabe der Art: "node-sass exited with code 0"

Starten Sie Ihren Browser und geben ein: http://[Ihre docker-machine IP-Adresse]:8080
- Sie erhalten unsere "index.html" - aber mit weißen Hintergrund.
- Sie erhalten in der GitBash-Konsole die logs des nginx Webservers

Beenden Sie in der GitBash-Konsole die Ausgabe via "CTRL+C" (Strg + c auf der Tastatur).
Dies beendet den Container "webserver-nginx" - also unseren Webserver. Sehen Sie sich die vorhandenen Container an: "docker ps -a"

Es wurde durchaus ein Container "node-sass" angelegt - dieser aber sofort beendet.
Genau dies wurde uns mit der Angabe "node-sass exited with code 0" mitgeteilt. Warum?

Wir haben in der "docker-compose.yml" für den Servcie "nodejs" kein Start Kommando hinterlegt. Es gibt also nichts was auszuführen wäre.
Sie könnten jetzt hier die Zeile #command: ["npm", "run", "watch", "--silent"] auskommentieren und "docker-compose up" erneut ausführen.
Es würde unser "watch" Script aus der "package.json" ausgeführt und eine "theme.css" im Verzeichnis "src/css" erstellt
und weiterhin auf Änderungen in der "src/scss/theme.scss" gewartet.

Wenn wir dann allerdings wieder mit "CTRL+C" den npm watch Task beenden möchten, würde auch gleichzeitig unser Webserver gestoppt.
Nicht unbedingt was wir möchten. Gehen Sie folgendermaßen vor:

Code:

---

docker-compose up -d"
bzw./oder
docker-compose start

---

Dies startet zumindest wieder unseren Webserver - im detached Modus. Im Anschluß können wir weitere Befehle in der Konsole eingeben:

Code:

---

docker-compose run --rm nodejs sh

---

Zitat:

---

Hinweis:

Wenn Sie hier keinen Prompt sehen oder Sie erhalten Ausgaben wie: "the input device is not a TTY. If you are using mintty, try prefixing the command with 'winpty'"
Dies ist bedingt durch die Auswahl während der "Git für Windows" Installation [1]. Dann probieren Sie es so:

winpty docker-compose run --rm nodejs sh

[1] Git Konfiguration: MinTTY Git Bash

---

Wir befinden uns jetzt im Container "node-sass" und können machen was wir wollen ...
Starten Sie das npm Script aus der "package.json": "npm run watch --silent".

- Es wird eine "src/css/theme.css" erstellt.
- Starten Sie Ihren Browser: http://[Ihre docker-machine IP-Adresse]:8080
- Unsere Webseite hat jetzt einen gelben Hintergrund
- Ändern Sie die "theme.scss" auf Ihrem Rechner/Host im Verzeichnis "src/scss" und refreshen den Browser
- Ihre Änderungen wurden übernommen
- Beenden Sie den npm watch Task via "CTRL+C"
- Starten Sie ein anderes npm Script: "npm run prod:sass"
- Refreshen Sie den Browser - Die CSS Angaben wurden komprimiert
- Verlassen Sie den Container mit: "exit"
- Stoppen Sie den Webserver mit: "docker-compose stop"

Innerhalb des Containers könnten Sie auch weitere, bel. npm Module installieren. Diese existieren solange wie der Container "node-sass"
ebenfalls existiert. Löschen Sie den Container "node-sass" gehen auch die Änderungen verloren.
Sie müßten dann das Image "dev/nodejs" mit den aktuellen Direktiven der "package.json" neu builden: "docker-compose up" bzw. "docker-compose build" ...

Die Änderungen in "src/scss/theme.scss" bzw. "src/css/theme.css" bleiben - auf Ihrem Host/Rechner - in jedem Fall vorhanden.

Fazit und Links

Auch wer Windows Versionen einsetzt die keine Hyper-V Unterstützung mit sich bringen kann Docker einsetzen.

Wer aus der Windows Welt kommt und einfach gefahrlos Konsolen Kommandos testen will bevor er diese via ssh auf dem realen Webhosting einsetzt,
pulled einfach eine der offiziellen Docker Distributionen wie ubuntu [1], centos [2] o. debian [3].

[1] Docker-Hub: ubuntu
[2] Docker-Hub: centos
[3] Docker-Hub: debian
[4] Node.js: File System


Sie werden immer häufiger auf Alpine Linux [1] stoßen - weil es gegenüber den übrigen Kandidaten erheblich kleiner ist.
Daher finden Sie fast immer auch eine fertige Alpine Umsetzung auf Docker-Hub vor. Für ein mögliches Contao-Stack allemal:
apache/nginx [2][3], PHP-FPM [4], mysql/mariadb [5][6].

[1] Docker-Hub: Alpine
[2] Docker-Hub: Apache
[3] Docker-Hub: nginx
[4] Docker-Hub: PHP
[5] Docker-Hub: mysql
[6] Docker-Hub: mariadb (Noch ohne Alpine)


Wenn Sie im Netz stöbern treffen Sie öfters auf "bin/bash" o. "apt/apt-get".
In Alpine können Sie auf "bin/sh" zurückgreifen oder sich "bash" installieren [1].
Das Gegenstück zu "apt" in Alpine ist "apk" [2] für die Alpine Packages [3].

[1] How to install bash shell in Alpine Linux
[2] 10 Alpine Linux apk Command Examples
[3] Alpine Packages


Als lokale Entwicklungsungebung für Contao bietet sich Docker an - Und es existieren fertige Lösungen [1],
wobei wir dann wieder beim Ausgangspunkt hinichtlich des Vortrages auf der Contao Konderenz 2018 sind [2]:

[1] GitHub: ctsmedia docker-contao
[1] Docker-Hub: ctsmedia Contao Docker Releases
[2] Youtube: Docker u. Contao