Ergebnis 1 bis 9 von 9

Thema: Schritt für Schritt: Docker Nutzung

  1. #1
    Contao-Urgestein Avatar von Franko
    Registriert seit
    22.06.2009.
    Beiträge
    1.510
    Partner-ID
    6122

    Standard 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:
    Geändert von Franko (24.02.2021 um 15:21 Uhr)
    Freelancer, Digital Design Enthusiast, Contao Aficionado and Tutorial Junkie @MoinFranko - Carpe diem ...

  2. #2
    Contao-Urgestein Avatar von Franko
    Registriert seit
    22.06.2009.
    Beiträge
    1.510
    Partner-ID
    6122

    Standard

    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
    Freelancer, Digital Design Enthusiast, Contao Aficionado and Tutorial Junkie @MoinFranko - Carpe diem ...

  3. #3
    Contao-Urgestein Avatar von Franko
    Registriert seit
    22.06.2009.
    Beiträge
    1.510
    Partner-ID
    6122

    Standard

    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:

    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 ...

    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


    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
    Geändert von Franko (15.08.2018 um 11:13 Uhr)
    Freelancer, Digital Design Enthusiast, Contao Aficionado and Tutorial Junkie @MoinFranko - Carpe diem ...

  4. #4
    Contao-Urgestein Avatar von Franko
    Registriert seit
    22.06.2009.
    Beiträge
    1.510
    Partner-ID
    6122

    Standard

    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
    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


    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.

    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 ...
    Geändert von Franko (15.08.2018 um 11:18 Uhr)
    Freelancer, Digital Design Enthusiast, Contao Aficionado and Tutorial Junkie @MoinFranko - Carpe diem ...

  5. #5
    Contao-Urgestein Avatar von Franko
    Registriert seit
    22.06.2009.
    Beiträge
    1.510
    Partner-ID
    6122

    Standard

    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:
    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.

    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.
    Geändert von Franko (16.08.2018 um 08:22 Uhr)
    Freelancer, Digital Design Enthusiast, Contao Aficionado and Tutorial Junkie @MoinFranko - Carpe diem ...

  6. #6
    Contao-Urgestein Avatar von Franko
    Registriert seit
    22.06.2009.
    Beiträge
    1.510
    Partner-ID
    6122

    Standard

    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
    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.
    Geändert von Franko (23.12.2018 um 09:59 Uhr)
    Freelancer, Digital Design Enthusiast, Contao Aficionado and Tutorial Junkie @MoinFranko - Carpe diem ...

  7. #7
    Contao-Urgestein Avatar von Franko
    Registriert seit
    22.06.2009.
    Beiträge
    1.510
    Partner-ID
    6122

    Standard

    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
    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
    Geändert von Franko (15.08.2018 um 12:05 Uhr)
    Freelancer, Digital Design Enthusiast, Contao Aficionado and Tutorial Junkie @MoinFranko - Carpe diem ...

  8. #8
    Contao-Urgestein Avatar von Franko
    Registriert seit
    22.06.2009.
    Beiträge
    1.510
    Partner-ID
    6122

    Standard

    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
    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.
    Geändert von Franko (15.08.2018 um 12:15 Uhr)
    Freelancer, Digital Design Enthusiast, Contao Aficionado and Tutorial Junkie @MoinFranko - Carpe diem ...

  9. #9
    Contao-Urgestein Avatar von Franko
    Registriert seit
    22.06.2009.
    Beiträge
    1.510
    Partner-ID
    6122

    Standard

    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
    Geändert von Franko (15.08.2018 um 11:32 Uhr)
    Freelancer, Digital Design Enthusiast, Contao Aficionado and Tutorial Junkie @MoinFranko - Carpe diem ...

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •