Schritt für Schritt: Docker als XAMPP Alternative

Wer bisher unter Windows mit XAMPP [1] für die lokale Entwicklung mit Contao 4.x gearbeitet hat:
Hier eine alternative Vorgehensweise mit Docker Images/Container.

Grundsätzlich gehen die Angaben von einer funktionierenden Docker Umgebung aus - zumeist ein einfacher Installations-Aufruf.
Wer die "Docker Toolbox" mit Windows nutzt sollte zuvor [2|3|4] gelesen haben.

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.

Als Terminal/Konsole für die folgenden Beispiele unter Windows setze ich GitBash [5] ein.
Wer die "Docker Toolbox" nutzt kann auch das "Docker Quickstart Terminal" nutzen.

Übersicht:

• Short&Sweet
• Begrifflichkeiten
• Vorbereitungen
• Docker Image erstellen und nutzen
• Docker Container erstellen und nutzen
• Mit Contao arbeiten
• Mit PHP-Composer und der Konsole arbeiten
• Ein Backup der vollständigen Contao Installation erstellen
• Eine vollständige Contao Installation über das Backup wiederherstellen
• Backup/Restore Automatisierung
• Fazit und Ausblick: devilbox.org
• Info devilbox.org Release 1.0.1

Update:
Informationen zur lokalen Docker/devilbox Nutzung findet Ihr auch in der Contao Dokumentation:
https://docs.contao.org/manual/de/an...tion/devilbox/

[1] Schritt für Schritt: Installation 4.X mit Windows7 u. Xampp 7.2.1
[2] Schritt für Schritt: Docker Nutzung
[3] Die Docker-VM in einer anderen Partition nutzen: "D:\..."
[4] Die Docker-VM optimieren (f. docker volumes auf Laufwerk "D:" u. Hauptspeicher erweitern)
[5] GitBash für Windows

Short&Sweet

Damit die unteren, detaillierten Infos nicht abschreckend wirken - hier eine Kurzzusammenfassung um lokal mit einer o. mehreren Webseiten zu arbeiten.
Je Webseite erstellt man sich ein separates Verzeichnis mit unterer Verzeichnisstruktur/Dateien, wechselt auf der Konsole in das jeweilige Verzeichnis und dann:

• In der Console: Erstmalig "docker-compose up -d" später dann "docker-compose start"
• Mit Contao arbeiten - Im Anschluß:
• In der Console: "docker-compose stop"

...

Oder Short'nSweet 2:

Inkl. vollständiger Herstellung einer Contao Installation und anschließendem Backup:

• docker-compose start
• bash restore.sh
• Mit Contao arbeiten ...
• bash backup.sh
• docker-compose stop

... siehe unten ...

... und wenn man mal richtig Mist gebaut hat: "docker-compose down" / "docker volume prune" / "docker network prune" ...
Auf Ihren Host ( z.B. Ihr Windows ) hat das alles keinen Einfluß - dank Docker ...

Begrifflichkeiten

Ein Docker Image beinhaltet eine konkrete Funktionalität, z.B. mysql in einer bestimmten Version.
Ein Docker Image kann über eine "Dockerfile" Datei erzeugt werden oder man lädt sich bestehende Docker Images über Docker-Hub [1].

Mit einem Docker Image kann nicht direkt gearbeitet werden. Zur Nutzung des Docker Image erzeugt man einen Docker Container - zunächst ein genaues Abbild des jeweiligen Docker Image.
Zur Nutzung des Docker Container muß dieser zunächst gestartet werden um dann z.B. in mysql bel. Datenbanken und Tabellen zu erzeugen. Im Anschluß kann der Container wieder gestoppt werden.
Ein gestoppter Container existiert weiterhin und alle Änderungen bleiben erhalten. Erst wenn der Container gelöscht wird gehen auch die darin enthaltenen Inhalte verloren -
nicht aber das entsprechende Docker Image.
Es können mehrere, unterschiedliche Container von einem Docker Image herangezogen werden.

Über eine "docker-compose.yml" Datei können mehrere Container gleichzeitig erzeugt und konfiguriert werden.
Die Docker Conatiner können in Abhängigkeit gesetzt werden und miteinander über ein internes Docker Network kommunizieren.

Ein Container kann Docker Volumes (file/folder sync) [2] nutzen. Hierüber werden Verzeichnisse zwischen laufendem Docker Container und dem Host ( z.B. ein Windows Verzeichnis ) synchronisiert.
Wenn ein Container gestoppt o. gelöscht wird bleiben hierdurch die Dateien in dem Verzeichnis auf dem Host erhalten.

[1] Docker-Hub
[2] Docker Volumes

Vorbereitungen

Auf Github [1] bzw. Docker-Hub [2] findet man fertige Docker Images von z.B. ctsmedia mit denen man sofort loslegen könnte.

Basierend auf [1] habe ich jedoch Anpassungen vorgenommen. So wollte ich z.B nicht mit den ctsmedia Scripten arbeiten,
sondern Backup und Restore Vorgehensweisen mit Docker Mitteln lösen. Weiterhin wird eine Docker ".env" Datei zur einfachen Konfiguration benutzt.
Die Infos auf [1] sind daher weitgehend obsolet - Bitte weiterlesen ...

Man benötigt lediglich ein Verzeichnis je Webseite/Projekt mit folgender Struktur und drei Dateien:

Verzeichnisstruktur

• D:\tutorial
• D:\tutorial\.env
• D:\tutorial\Dockerfile
• D:\tutorial\docker-compose.yml
• D:\tutorial\src\files
• D:\tutorial\src\templates
• D:\tutorial\_backup

.env
https://gist.github.com/fkaminski/00...9e277e1a5b9281

Dockerfile
https://gist.github.com/fkaminski/55...bb819f595c30ce

docker-compose.yml
https://gist.github.com/fkaminski/4d...c293aeb1575fda


Wichtig: Konventionen
Die vorhandenen ctsmedia Images [3] bzw. ein über das "Dockerfile" selbst erzeugtes Image setzen den User "www-data" für das Verzeichnis "/var/www/share/project" im jeweiligen PHP/Contao Container.
In diesem Verzeichnis befinden sich dann die Contao Dateien.

Wenn man mit Docker Containern arbeitet ist man normalerweis als User "root" unterwegs.
Zur Vermeidung von Zugrifssrechten sollte daher als User "www-data" gearbeitet werden!


[1] GitHub: ctsmedia docker-contao
[2] Docker-Hub: ctsmedia Repo Info
[3] Docker-Hub: ctsmedia docker-contao Tags

Eigenes Docker Image erstellen und nutzen

Starten Sie Ihr Terminal ( ich nutze GitBash [1] unter Windows ) und wechseln in das obige Verzeichnis.

Wir erstellen einmalig ein Docker Image über das "Dockerfile".
Sie müssen lediglich den Image Namen und die zu installierende Contao Version angeben - Also etwa:

Code:

---


docker build -t my/contao:4.4.32 --build-arg CONTAO_VERSION=4.4.* .

---

Das kann etwas dauern - Am Ende sollten Sie ein Docker Image "my/contao:4.4.32" ...

Code:

---


docker image ls

---

... mit folgenden Features vorliegen haben:

• PHP Cli Version 7.2
• PHP mit memory_limit=-1
• PHP Composer ( Zum Zeitpunkt war es Version 1.8 )
• Contao LTS ( Zum Zeitpunkt war es Version 4.4.32 )
• Contao Manager ( Zum Zeitpunkt war es Version 1.1.2 )

Sie könnten sich z.B. auch gleich ein Image für die aktuelle Contao 4.6 Version erstellen:

Code:

---


docker build -t my/contao:4.6.11 --build-arg CONTAO_VERSION=4.6.* .

---

Der Docker Image Name ist frei wählbar ( xyz o. myimage etc. ), das Image Tag ebenso ( 4.4 o. LTS o. LATEST etc. ).
Da das Docker Image aber ein Abbild der Contao Version zum Zeitpunkt der Erstellung darstellt,
sollte dies auch aus dem Namen:Tag des Docker Image eindeutig hervorgehen.


[1] GitBash

Docker Container erstellen und nutzen

Editieren Sie die nun ".env" Datei. Hier finden Sie drei Variablen vor:

Code:

---


CONTAO_IMAGE=my/contao:4.4.32

COMPOSE_PROJECT_NAME=website

GLOBAL_PASS_NAME=devcontao

---

Sie müssen lediglich die Angabe hinter CONTAO_IMAGE, entsprechend des zuvor erstellen Docker Images setzen/aktualisieren.

Hinweis
Sie können hier auch ein auf Docker-Hub vorhandenes ctsmedia Docker Image [1] einsetzen - z.B: ctsmedia/contao:latest
Achten Sie dann aber darauf, das diese noch mit einem PHP memory_limit=512M laufen und im Contao Manager den Resolver nutzen müssen.

Die beiden anderen Variablen sind optional.

Die COMPOSE_PROJECT_NAME
wird als Prefix für die Docker Container Namen herangezogen.
Je Verzeichnis sollte hier der Eintrag geändert werden ( website1, website2, myprojecta usw.. ) damit eindeutige Docker Container Namen erstellt werden.

Die GLOBAL_PASS_NAME
wird grundsätzlich für z.B alle Angaben im Install Tool bzw. für die Datenbank ( wie DB-User / DB-Database / DB-Password ) einheitlich herangezogen.

Im folgenden beziehe ich mich immer auf die obigen Angaben/Namen. Sollten Sie diese geändert haben - bitte entsprechend anpassen.
Erstellen Sie die Docker Container anhand der "docker-compose.yml" mit:

Code:

---


docker-compose up -d

---

Der erstmalige Aufruf kann es etwas dauern da, sofern noch nicht vorhanden, auch die übrigen Docker Images wie z.B der Apache Server von ctsmedia o. phpMyAdmin gezogen werden.
Im Anschluß sollten Sie folgende, gestartete Container - entsprechend der Namen Konvention aus der ".env" vorliegen haben:

Code:

---


docker container ls

website.local
website_phpMyAdmin
website_contao
website_db

---

Sie können die Container stoppen und starten über

Code:

---


# Stoppt die Container
docker-compose stop

# Zeigt existierende Container
docker container ls -a

# Startet die vorhandenen Container
docker-compose start

# Zeigt laufende Container
docker container ls

# Stopt/Löscht die laufenden Container
docker-compose down

docker container ls
docker container ls -a

# Zeigt vorhandene Images
docker image ls

---

Wenn Sie Änderungen an der ".env" oder der "docker-compose.yml" machen, müssen Sie die Container wieder einmalig neu erstellen und starten: "docker-compose up -d"

Solange die Container existieren bleiben alle gemachten Änderungen ( über den CM/Composer, innerhalb von Contao usw. ) erhalten.
Erst wenn Sie die Container endgültig löschen - "docker-compose down" - sind auch Ihre bisherigen Arbeiten hinfällig.

Hinweis Backup und Restore
Wer ein Backup vorliegen hat könnte zu diesem Zeitpunkt eine vollständige Contao Installation wieder herstellen.
Weitere Vorgehensweisen zum einfachen Backup und Restore - weiter unten ...


[1] GitHub: ctsmedia docker-contao

Mit Contao arbeiten

Stellen Sie sicher, das Ihre Container gestartet sind: "docker container ls" bzw. "docker-compose start"
Starten Sie nun Ihren Browser. Normalerweise mit "localhost".
Wer mit der "Docker Toolbox" arbeitet muß die Docker-IP Adresse nutzen:

Code:

---


docker-machine ip

---

Bei mir daher im folgenden z.B. über den Aufruf http://192.168.99.100


Den Contao-Manager starten

Code:

---


http://192.168.99.100/contao-manager.phar.php

---

Der Manager sollte die korrekte PHP-CLI autom. erkennen. In der "Systemprüfung" unter "Serverkonfiguration" setzen Sie unter "Konfiguration" auf "Andere".
Den "Composer Cloud Resolver" können Sie eigentlich deaktivieren, da unser PHP memory_limit auf -1 gesetzt ist ( s. Dockerfile ).

Hinweis
Haben Sie in der ".env" ein vorhandenes Docker-Hub ctsmedia Image gesetzt liegt das PHP memory_limit bei 512M und im Contao Manager muß dann der Resolver genutzt werden.
Weiterhin wird dann für den CM der Aufruf "contao-manager.php" benötigt.


Das Contao-Installtool

Code:

---


http://192.168.99.100/contao/install

---

Bei der Datenbankabfrage geben Sie folgendes ein ( entsprechend der Konvention aus der ".env" ):

• Host: db
• Portnummer: 3306
• Benutzername: devcontao
• Passwort: devcontao
• Datenbankname: devcontao

Normalerweise setzen Sie für "Host" den Eintrag "localhost".
Da bei der "Docker Toolbox" Nutzung kein "localhost" zur Verfügung steht tragen wir bei "Host" "db" ein.
Das ist der Service Name unter dem mysql im internen Docker Netzwerk erreichbar ist ( s. "docker-compose.yml" ).


phpMyAdmin

Code:

---


http://192.168.99.100:8080

---

• Benutzername: devcontao
• Passwort: devconato
• Oder:
• Benutzername: root
• Passwort: devconato

Entsprechend der Konvention aus der ".env" bzw. "docker-compose.yml".


Contao templates/files Verzeichnisse
Alle Änderungen die innerhalb von Contao in diesen Verzeichnissen gesetzt werden,
werden mit den lokalen Host Verzeichnissen "src/templates" und "src/files" synchronisiert -
da diese in der "docker-compose.yml" als Docker Volume gesetzt werden.

Sie können auch direkt in diesen lokalen Verzeichnissen Änderungen vornehmen,
die dann wieder innerhalb von Contao ( bzw. im jeweiligen Container ) zur Verfügung stehen.

Auch wenn Sie die Container stoppen/löschen bleiben die Daten dieser beiden lokalen Verzeichnisse erhalten!

Mit PHP-Composer und der Konsole arbeiten

Entsprechend der obigen Namen Konventionen heißt unser Contao/PHP Container z.B. "website_contao".
Haben Sie in der ".env" Datei für COMPOSE_PROJECT_NAME einen anderen Eintrag gesetzt heißt Ihr Container halt anders - bitte dies bei folgenden Angaben berücksichtigen.

Öffnen Sie Ihr Terminal ( ich nutze GitBash ), wechseln in das Projekt Verzeichnis ( hier z.B. D:\tutorial ) und falls noch nicht geschehen starten die existierenden Container mit "docker-compose start".
Das u.a. hier benutzte PHP Image von ctsmedia [1] installiert bereits den PHP-Composer. Wir können diesen daher ohne weiteres auf der Konsole nutzen.

Mit dem Docker "exec" Befehl können Sie sich - quasi SSH like - in einen laufenden Container einklinken:

Code:

---

docker exec -ti -u www-data website_contao bash

---

Zitat:

---

Hinweis:
Wenn Sie hier eine Ausgabe erhalten 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 exec -ti -u www-data website_contao bash

[1] Git Konfiguration: MinTTY Git Bash

---

Wichtig
Wichtig ist hier die Option "-u www-data" (s. auch Beitrag "Vorbereitungen"). Ohne die Option sind Sie im Container als User "root" unterwegs.
Wenn Sie als "root" User Änderungen z.B. an der "composer.json" speichern würden, kann es u.a. über den Contao-Manager zu Zugriffsproblemen führen!

Sie befinden sich also somit im Container "website_contao" als User "www-data" im Verzeichnis "/var/www/share/project/" und können hier bel. Befehle absetzen:

Code:

---

pwd
php -v
php -i | grep memory_limit
vim composer.json
composer update
exit

---

Sie müssen nicht unbedingt direkt über die Bash-Shell des Containers arbeiten.
Mit Docker "exec" können Sie auch einzelne Befehle in der GitBash Konsole separat ausführen:

Code:

---

docker exec -t -u www-data website_contao pwd
docker exec -t -u www-data website_contao php -v
docker exec -t -u www-data website_contao composer require erdmannfreunde/euf_grid:^2.2

---

Kleiner Ausflug - die composer.json lokal editieren
Manchmal kann es notwendig werden die "composer.json" manuell zu editieren. Wer dies nicht im Container via "vim" erledigen möchte - hier ein Beispiel.
Laut dem Issue #238 [2] konnte es notwenig sein zwischenzeitlich den Eintrag

Code:

---

"conflict": {
        "doctrine/dbal": "2.9.1"
 }

---

in der "composer.json" zu setzen, damit das Installtool in der Contao Version 4.4.31 wieder funktioniert.
Wir kopieren uns die "composer.json" aus dem Container "website_contao" in das lokale Verzeichnis "_backup" mit:

Code:

---

docker cp website_contao:var/www/share/project/composer.json _backup

---

In unserem lokalen Verzeichnis "_backup" existiert nun die "composer.json" und wir tragen hier die Änderung ein.
Wir kopieren die geänderte Datei wieder in den Container und führen ein Composer update aus:

Code:

---

docker exec -u www-data website_contao cp _backup/composer.json .
docker exec -u www-data website_contao composer update

---

Hintergrund
Wir benutzen in der ersten Zeile nicht wieder den eigentlichen "Docker cp" Befehl, da wir hierüber nicht den User "www-data" mitschleifen können.

Stattdessen haben wir, analog z.B. zum Verzeichnis "src/templates", das Verzeichnis "_backup" in der "docker-compose.yml" als Volume eingetragen.
Entsprechend liegt also unsere lokal geänderte Datei auch wieder im Verzeichnis "_backup" innerhalb des Container vor.

Mit dem Befehl kopieren wir also die "composer.json" im Verzeichnis "_backup" des Containers in das Arbeitsverzeichnis "/var/www/share/project/" -
aber halt unter dem User "www-data"!

Dies ist entspricht dann auch der Vorgehensweise zum Backup und Restore vollständiger Contao Installation und Inhalte - siehe unten ...


[1] GitHub: ctsmedia PHP
[2] Installtool broken after update to 4.6.11 #238

Ein Backup der vollständigen Contao Installation erstellen

Update: Neue Symfony 4-Ordnerstruktur mit Contao 4.8 s.: https://contao.org/de/news/contao_4-8-0.html
Bitte die Pfade für die Konfigurationsdateien dann entsprechend anpassen

Sie sind mit der lokalen Arbeit der Contao Seite fertig.
In den lokalen Verzeichnissen "src/templates" und "src/files" sind Ihre Daten bereits permanent vorhanden.

Wir müssen für ein Backup noch die Dateien "composer.json", "composer-lock", "app/config/parameters.yml", "system/config/localconfig.php"
aus dem Container "website_contao" und ein Datenbank Dump aus dem Container "website_db" erstellen:

Diese Dateien werden in das lokale Verzeichnis "_backup" kopiert, welches ebenfalls als Volume in unserer "docker-compose.yml" definiert ist.
Öffnen Sie die GitBash Konsole und wechseln in Ihr Projekt-Verzeichnis mit den laufenden Containern:

Code:

---

docker cp website_contao:var/www/share/project/composer.json _backup
docker cp website_contao:var/www/share/project/composer.lock _backup

docker cp website_contao:var/www/share/project/app/config/parameters.yml _backup
docker cp website_contao:var/www/share/project/system/config/localconfig.php _backup

docker exec website_db mysqldump -u devcontao --password=devcontao devcontao > _backup/db_website.sql

---

Im Anschluß befinden sich die Dateien ebenfalls permanent im lokalen Verzeichnis "_backup".
Sie könnten nun die Container löschen "docker-compose down".

Wer möchte kann sich hierzu für "GitBash" ein Bash Script erstellen oder ein ensprechendes Windows CMD/Powershell Pendant - s.a.: "Backup/Restore Automatisierung"

Eine vollständige Contao Installation über das Backup wiederherstellen

Update: Neue Symfony 4-Ordnerstruktur mit Contao 4.8 s.: https://contao.org/de/news/contao_4-8-0.html
Bitte die Pfade für die Konfigurationsdateien dann entsprechend anpassen

Sie haben ein Backup erstellt und die Container gelöscht.
Öffnen Sie die GitBash Konsole und wechseln in Ihr Projekt-Verzeichnis. Erzeugen und starten Sie die Container mit "docker-compose up -d".

Kopieren Sie Ihre Sicherung aus dem "_backup" Verzeichnis und importieren den Datenbank Dump:

Code:

---

docker exec -u www-data website_contao cp _backup/composer.json .

docker exec -u www-data website_contao mkdir -p app/config/
docker exec -u www-data website_contao cp _backup/parameters.yml app/config/'
docker exec -u www-data website_contao cp _backup/localconfig.php system/config/'

###  Option 1: A composer update - will install/update extensions but possibly a wohle Contao Update too

docker exec -t -u www-data website_contao composer update

### Option 2: For clearing cache only - possible extension(s) must be manually installed via CM

docker exec -t -u www-data website_contao php vendor/bin/contao-console cache:clear
docker exec -t -u www-data website_contao php vendor/bin/contao-console cache:warmup
docker exec -t -u www-data website_contao php vendor/bin/contao-console contao:symlinks

docker exec -i website_db mysql -u devcontao --password=devcontao devcontao < _backup/db_website.sql

---

Cache Clear oder Composer Update
Wenn in der "composer.json" Erweiterungen eingetragen sind müssen Sie ein composer update durchführen um diese autom. zu installieren.
Allerdings würde damit möglicherweise auch auf eine neuere Contao Version upgedatet - Evtl. nicht was man möchte.

Wenn Sie lediglich die "Cache Clear" Variante ausführen, müssen Sie die Erweiterungen im Anschluß noch über den Contao-Manager installieren.
Der Contao-Manager erkennt die Einträge und weist darauf hin. Vorteil: Es wird nicht die gesamte Contao Version dabei aktualisiert.

Im Anschluß ist Ihre Contao Version vollständig hergestellt.
Wer möchte kann sich hierzu für "GitBash" ein Bash Script erstellen oder ein ensprechendes Windows CMD/Powershell Pendant - s.a.: "Backup/Restore Automatisierung"

Hinweis
Alle Angaben wurden unter Windows 7/10 Home mit der "GitBash"/"Docker Quickstart Terminal" Konsole getestet.
Diese sollten auch für "Docker für Mac"/"Docker für Windows (Hyper-V)" Anwender funktionieren, zumal bei den "docker exec" Befehlen die Host Pfade relativ gesetzt werden.
Konnte ich aber nicht testen.

Einzig "Powershell" Nutzer könnten evtl. bei der mysql Import Anweisung einen Fehler ala: "Der Operator "<" ist für zukünftige Versionen reserviert." erhalten.
Diese könnten das Datenbank Backup file dann direkt im Container sichern lassen und von dort auch dann direkt importieren mit:

• docker exec website_db bash -c "mysqldump -u devcontao --password=devcontao devcontao > db_website.sql"
• docker exec website_db bash -c "mysql -u devcontao --password=devcontao devcontao < db_website.sql"

Backup/Restore Automatisierung

Update: Neue Symfony 4-Ordnerstruktur mit Contao 4.8 s.: https://contao.org/de/news/contao_4-8-0.html
Bitte die Pfade für die Konfigurationsdateien dann entsprechend anpassen

Wer mit der "GitBash" Konsole o. dem "Docker Quickstart Terminal" ( o. einer anderen Bash-Shell ) arbeitet kann folgende Bash-Scripts ( .sh ) zum Backup/Restore nutzen.
Kopieren Sie sich die drei Dateien in Ihr Projekt Verzeichnis:

vars.sh
https://gist.github.com/fkaminski/7d...530f30ce505239

backup.sh
https://gist.github.com/fkaminski/b7...58f122e2bfdabe

restore.sh
https://gist.github.com/fkaminski/c5...fc5307e8913863

Öffnen Sie die GitBash Konsole und wechseln in Ihr Projekt-Verzeichnis.

Backup Aufruf:

Code:

---

bash backup.sh

---

Restore Aufruf:

Code:

---

bash restore.sh
oder
bash restore.sh -u

---

Hinweis restore.sh Parameter
Per Default Aufruf wird u.a. nur ein Contao Cache Clear/Warmup ausgeführt.

Mit Übergabe von "bash restore.sh -u" oder "bash restore.sh --update" wird stattdessen ein "composer update" ausgeführt ( s.a.: Eine vollständige Contao Installation über das Backup wiederherstellen ).
( Geändert am 20.12.18 - wer eine vorherige Version hat - bitte das Gist neu herunterladen. )

Short'nSweet 2:
Eine bel. lokale Contao Version/Nutzung, je Projekt-Verzeichnis, mit Docker inkl. Restore/Backup könnte also so aussehen:

• docker-compose start
• bash restore.sh
• Mit Contao arbeiten ...
• bash backup.sh
• docker-compose stop

Update: Einfacher SQL-Import mit Docker
Eine andere .sql Import Vorgehensweise: Einfacher SQL-Import mit Docker

Fazit und Ausblick: devilbox.org

Die lokale Contao Nutzung mit Docker basierend auf vorhandenen, für Contao korrekt konfigurierten Images, ist nicht aufwendig.
Anspruchsvoll ist eher die einmalige, korrekte Konfiguration von PHP, Apache, NGINX Images etc..
Mit den hier vorgestellten, fertigen Lösungen basierend auf den ctsmedia Images kann man also gut arbeiten.

Eine weitere Alternative wäre die devilbox.org [1].
Das Projekt wird gut gepflegt [2] und ist detailliert dokumentiert [3].


[1] devilbox.org
[2] Github: devilbox
[3] Dokumentation: devilbox

Danke für Deine fleißige Beschreibung.

Obwohl ich bisher mit XAMPP immer ausreichend gut zurechtgekommen bin animiert die Beschreibung dazu, mal Docker zu testen.

Wer unter Windows mit der "Docker Toolbox" bzw. der "Virtualbox" unterwegs ist und Fehler bei der symlink Erstellung im Container erhält:

Lösung: https://community.contao.org/de/show...l=1#post491161

Danke für das schöne Tutorial!

Ich hab heute mal ein bisschen mit der devilbox gespielt - sehr, sehr angenehm.

Ein paar Hinweise, die mir so aufgefallen sind:

• Die Umleitung auf den web-Ordner soll man lt. Doku mittels Symlink machen (von htdocs auf web). Das klappt leider nicht. Ich habe daraufhin die .env geändert. Bei mir die globale, aber das kann man auch je vhost machen. Damit geht's.
• Ausserdem hatte ich ein Problem mit Unterstrichen in den vhost-Namen. Da klappt die Installation, aber danach nichts mehr. Da wird der Unterstrich entweder von Contao (routing, eher unwahrscheinlich), oder eben der Devilbox raus genommen. Ausserdem klappen die Symlinks nicht mehr (nur die von /web/assets nach /assets und /web/files nach files, alle anderen z.B. bei Erweiterungen sind ok). Das muss ich mir nochmal ansehen und evtl. einen bug melden.

Macht man hingegen die Umstellung auf web in der .env, dann ist ein frisches Contao 4.6 mittels composer auf der CLI (Manager hab ich nicht mehr probiert) in knapp zweieinhalb Minuten installiert!

Von mir eine klare Empfehlung für die devilbox, das Ding spart mal richtig Arbeit und läuft schön stabil!

Was ich als mega-angenehm empfinde, ist die E-Mail-catch-all Funktion. Endlich muss ich da nix mehr konfigurieren und kann das notification_center in Ruhe testen.

Hi, danke für Deine Hinweise.
Ich mache auch gerade meine Gehversuche mit der devilbox v0.14 mit Windows u. Docker-Toolbox.

Zitat:

---

Zitat von PaddySD

[*]Die Umleitung auf den web-Ordner soll man lt. Doku mittels Symlink machen (von htdocs auf web). Das klappt leider nicht. Ich habe daraufhin die .env geändert.

---

Ja, mit der Änderung der HTTPD_DOCROOT_DIR in der .env auf "web" geht es auch bei mir - Allerdings z.Z. nur mit Apache.
Für NGINX muß ich noch die passende Konfiguration finden. Oder hast Du eine lauffähige ...

Zitat:

---

Zitat von PaddySD

[*]Ich habe daraufhin die .env geändert. Bei mir die globale, aber das kann man auch je vhost machen. Damit geht's.

---

Wie kann man denn die .env je Projekt heranziehen?

Weiterhin liefen in der Version v.0.14 bei mir mysql und phpmyadmin nicht auf Anhieb. Erst nach diesen Änderungen:
https://github.com/cytopia/devilbox/issues/382
https://github.com/cytopia/devilbox/issues/342

Wie war das bei Dir?

Der Composer auf der Console bzw. der CM ohne Resolver laufen auch - wenn man für die entsprechende PHP Version das memory_limit auf -1 setzt.
Diese Konfigurationsmöglichkeiten sind in der devilbox wirklich einfach und schön gelöst.

Allerdings finde ich die momentan die Nutzung der docker volumes mit der devilbox überdimensioniert.
Beispielsweise wird ja hier der gesamte Projektordner herangezogen. Hat man also hierunter mehrere Projekte laufen werden alle Daten mit dem Host synchronisiert.
Im Falle von Contao also alle Dateien/Verzeichnisse - inkl. der Cache Verzeichnisse. Das kann einiges verlangsamen ...

Die Aussicht auf das 1.0.0 Release macht es in dieser Hinsicht nicht besser: https://github.com/cytopia/devilbox/pull/383
Diese Vorgehensweise ist wahrscheinlich den möglichen Kompatibilitätsproblemen geschuldet:

Zitat:

---

This PR will move all data directories (MySQL, PostgreSQL, MongoDB and others) to Docker volumes for best-practice and compatibility reasons on different operating systems.

---

Einfacher SQL-Import mit Docker

Habe eben gelernt das bei Nutzung der offiziellen DB Images wie MariaDB o. mySql ein .sql dump über die docker-compose.yml autom. importiert werden kann.
Beispiel:

Code:

---

services:
  db:
    image: mariadb:10.3
    environment:
      MYSQL_ROOT_PASSWORD: myrootpassword
      MYSQL_DATABASE: mydatabase
      MYSQL_USER: myuser
      MYSQL_PASSWORD: mypassword
    ports:
      - 3306:3306
    volumes:
      - ./sql/dump.sql:/docker-entrypoint-initdb.d/dump.sql

---

In der letzten Zeile wird ein SQL-Dump aus dem Projekt-Verzeichnis im Container Ordner /docker-entrypoint-initdb.d verfügbar gemacht.

Das in den Images als ENTRYPOINT angegebene docker.entrypoint.sh macht es möglich.
Hier wird auf Dateien mit den Endungen .sh, .sql und .sql.gz geachtet und diese importiert.

Hi,

ich hatte das Problem, das ich weder Template-Dateien noch Ordner in der Dateiverwaltung anlegen konnte. Die Ordner files/, templates und _backup/ waren bei mir noch dem Owner root und der Gruppe root zugeordnet. Ich habe mich dann mittels:

Code:

---

docker exec -ti website_contao bash

---

verbunden und über chown und chgrp die Rechte angepasst. Danach konnte ich auch Dateien erstellen.

Kann man das eventuell automatisieren?

Viele Grüße
René

Zitat:

---

Zitat von Fehrmann

Hi,
Kann man das eventuell automatisieren?
René

---

Hinsichtlich der Zugriffsrechte kommt es halt auch auf das jeweilige Image an. Die ctsmedia Leute setzen dazu den User www-data - siehe ersten Beitrag:

Zitat:

---

Wichtig: Konventionen
Die vorhandenen ctsmedia Images [3] bzw. ein über das "Dockerfile" selbst erzeugtes Image setzen den User "www-data" für das Verzeichnis "/var/www/share/project" im jeweiligen PHP/Contao Container.
In diesem Verzeichnis befinden sich dann die Contao Dateien.

Wenn man mit Docker Containern arbeitet ist man normalerweis als User "root" unterwegs.
Zur Vermeidung von Zugrifssrechten sollte daher als User "www-data" gearbeitet werden!

---

Bei der devilbox wird dies über die gid und uid Angaben realisiert - siehe:

https://devilbox.readthedocs.io/en/l...et-uid-and-gid
https://devilbox.readthedocs.io/en/l...er-permissions

Seit einiger Zeit steht die devilbox in der Version 1.0.0 bzw. 1.0.1 [1] mit zahlreichen Änderungen/Verbesserungen ( z.B. echte Docker Volumes für Datenbanken etc. ) bereit.

Nach der grundsätzlichen Konfiguration mittels der ".env" ( NEW_UID, NEW_GID etc. ) kann man prinzipiell sofort loslegen.
Einzig die "HTTPD_SERVER" Variable sollte auf Apache zeigen. Wer nginx benutzen möchte ( Voreinstellung ) muß dazu zuvor die .conf anpassen [2].

In der Dokumentation ist nun auch Contao aufgeführt [3].
Unter Punkt 4 der Dokumentation "Symlink web" wird die Vorgehensweise für das "web" Verzeichnis mittels Symlink beschrieben.
Das habe ich so nicht ausprobiert. Stattdessen habe ich gleich in der ".env" die Variable "HTTPD_DOCROOT_DIR" auf das "web" Verzeichnis gesetzt ( also HTTPD_DOCROOT_DIR=web ).

Weiterhin habe ich bez. der Contao Dokumentation ein paar zusätzliche Hinweise hinterlassen [4].
Ich denke der Entwickler wird diese bald in die Doku einfließen lassen.

[1] devilbox Releases
[2] devilbox nginx.conf
[3] devilbox Contao Dokumentation
[4] Ergänzugen devilbox Contao Dokumentation

Für die Devilbox existiert auch ein CLI-Tool zur Bearbeitung der .env.
Damit könnten die verschiedenen Konfigurationen z.B. auch via NPM Scripts ausgeführt werden - siehe:

https://devilbox.readthedocs.io/en/l...ilbox-cli.html
https://github.com/louisgab/devilbox-cli

Wer mit der devilbox die neue Contao Version 4.8 einsetzt und die WebP Konvertierung nutzen möchte
erhält möglicherweise unter "Bildgrößeneinstellungen/Experteneinstellungen" die Meldung:

"WEBP wird auf Ihrem Server nicht unterstützt".

Zur Zeit muß man dann in Contao auf das PHP-Modul "gd" umstellen/forcieren.
In der "config/config.yml" den Eintrag setzen:

Code:

---

contao:
    image:
        imagine_service: 'contao.image.imagine.gd'

---

Im Anschluß via CM/Console den Cache neu aufbauen.
Danke an @xchs für den Hinweis.

Hintergrund: s.: https://github.com/contao/contao/iss...ment-522223065

Den Contao Cache mit der devilbox über die Konsole zu clearen ist zumeist schneller als via CM.
Daher einfach "bash shell.sh" ( im devilbox Hauptverzeichnis ) aufrufen um in den PHP-Container zu gelangen.

Wer die Docker-Toolbox mit GitBash nutzt erhält möglicherweise dann:

Code:

---

$ bash shell.sh
the input device is not a TTY.  If you are using mintty, try prefixing the command with 'winpty'

---

Dann eben einfach der Aufruf mit: winpty docker-compose exec --user devilbox php bash -l

Sie befinden sich dann im PHP-Container.
Mit "ls" sehen Sie die vorhanden Verzeichnisse Ihrer Webseite(n).
Wechseln Sie in das jeweilige Webseiten Verzeichnis z.B.: cd meineSeite und darin dann:

php vendor/bin/contao-console cache:clear
und
php vendor/bin/contao-console cache:warmup

( php ist hier bereits der korrekte alias der jeweiligen PHP-Cli Version - siehe auch: php -v )

Verlassen Sie den PHP-Container wieder über: exit

Das devilbox Release 1.2.0:
https://github.com/cytopia/devilbox/releases/tag/v1.2.0

Wer mit der "Docker Toolbox" und dem aktuellen devilbox.org release Probleme mit den virtualhosts bzw. dem "Auto DNS" feaure hat.

Laut Doku muß in der .env die Variable "HOST_PORT_BIND" auf (Port) 53 gesetzt werden (Default Wert ist 1053)
und die devilbox dann neu gestartet werden. Der Port 53 darf nicht anderweitig belegt sein.

Bei mir (mit der Docker Toolbox) reichte dies nicht aus.

Ohne jetzt direkte Änderungen an den Einstellungen der entsprechenden Windows Netzwerkadapter vorzunehmen,
habe ich stattdessen in der VM der Virtualbox folgende Port Weiterleitungen gesetzt (s.Grafik):
In den Einstellungen der VM unter Netzwerk/Adapter 1/Erweitert/Port-Weiterleitung.

Anhang 23101

Damit sollte das devilbox Dashboard u.a. jetzt auch unter 127.0.0.1 erreichbar sein.
Bei mir klappte es dann auch mit dem "Auto DNS" feauture ...

devilbog SSL - Zertifikat:

Der Aufuf/Klick auf die jeweiligen virtualhost Einträge (z.B. testcontao48.loc) im Dashboard erfolgt leider via http, obwohl https von vorn herein unterstützt wird -
Also einfach mit https aufrufen.

In den Browsern muß dann noch das Zertifikat importiert werden - siehe: https://devilbox.readthedocs.io/en/l...lid-https.html

Das Dashboard der devilbox bietet einen "Catch All" E-Mail Service zum testen des lokalen E-Mail Versands (Im Dashboard Reiter Emails).

Allerdings können hierüber keine bestehenden E-Mail Einträge gelöscht werden.
Wird die Anzeige/Liste unübersichtlich kann man diese wie folgt entfernen:
In den docker PHP Container einklinken mit:

Code:

---

bash shell.sh (befindet sich im entsprechenden devilbox Verzeichnis)
bzw. mit
docker-compose exec --user devilbox php bash -l

---

Man befindet sich dann im Verzeichnis "/shared/httpd" (das entsprechend im Host gemounted wird).
Hier dann wechseln nach:

Code:

---

cd ../../var/mail
ls -a

---

Existieren Mail Einträge findet man hier den entsprechenden devilbox Eintrag.
Diesen dann einfach löschen und den Container verlassen:

Code:

---

rm devilbox
exit

---

Im Dashboard (Browser Refresh) sollten die Mail Einträge nicht mehr auftauchen ...

Zitat:

---

Zitat von Franko

Wer mit der devilbox die neue Contao Version 4.8 einsetzt und die WebP Konvertierung nutzen möchte
erhält möglicherweise unter "Bildgrößeneinstellungen/Experteneinstellungen" die Meldung:

"WEBP wird auf Ihrem Server nicht unterstützt".

Zur Zeit muß man dann in Contao auf das PHP-Modul "gd" umstellen/forcieren.
In der "config/config.yml" den Eintrag setzen:

Code:

---

contao:
    image:
        imagine_service: 'contao.image.imagine.gd'

---

Im Anschluß via CM/Console den Cache neu aufbauen.
Danke an @xchs für den Hinweis.

Hintergrund: s.: https://github.com/contao/contao/iss...ment-522223065

---

Mit dem aktuellen devilbox release (s.:https://github.com/cytopia/devilbox/releases), bzw. aktuellen devilbox images ist das nicht mehr notwendig.
Die webp Unterstützung klappt damit auch ohne weitere Konfiguration ...

Ich hatte gerade das Problem zwecks lokalen Contao Update einen (mysql 5.7) Datenbank Export (von ionos) in der devilbox (mariadb) zu importieren:

Code:

---

Row size too large ...

---

(in der tl_content)

In diesem Fall hat es mir geholfen den Wert der Variablen "innodb_strict_mode" über devilbox/phpMyAdmin zwischenzeitlich auf "OFF" zu setzen.
Danach funktionierte der Import ...

Hallo,
werde in Kürze einen neuen Rechner bestellen und würde da dann Windows 10 PRO kaufen.

Habt Ihr Erfahrungen mit Hyper-V/Docker unter Windows 10 PRO im Gegensatz zur Docker Toolbox Installation?
Gibt es da Besonderheiten/Fallstricke zur Contao Installation zu beachten (Symlinks etc.) ...

Danke

Hallo,
ich wollte einige cron jobs in dem devilbox PHP Container testen und wunderte mich das meine jobs gar nicht ausgeführt wurden.
Es hat sich heraus gestellt, das der cron service per default gar nicht gestartet ist. Also:

Code:

---

docker-compose exec --user devilbox php bash -l;

---

und dann

Code:

---

service cron status

---

Man kann den Service dann starten mit:

Code:

---

sudo service cron start
service cron status

---

Wen man das gleich beim Container Start ausführen möchte kann man dies in einer .sh Datei im devilbox "autostart" Verzeichnis hinterlegen - s.:
https://devilbox.readthedocs.io/en/l...ight=autostart

... Nachtrag:
Die eigentlichen cronjobs können in der devilbox dann analog wie bei meinem Hoster hostingwerk.de angelegt werden.

Einen Artikel hierzu findet Ihr hier:
https://www.webdecker.de/artikel/ite...stingwerk.html

Zitat:

---

Zitat von Franko

Hallo,
werde in Kürze einen neuen Rechner bestellen und würde da dann Windows 10 PRO kaufen.

Habt Ihr Erfahrungen mit Hyper-V/Docker unter Windows 10 PRO im Gegensatz zur Docker Toolbox Installation?
Gibt es da Besonderheiten/Fallstricke zur Contao Installation zu beachten (Symlinks etc.) ...

Danke

---

Funktioniert soweit mit Windows 10 Pro und Docker-Desktop/devilbox.
Habe hierbei die Hyper-V default Einstellungen belassen (Pfade für virtuelle Festplatte etc. - alles auf Laufwerk C).
Gleiches für die Docker-Desktop Settings. Einzig hier dann unter Resources/File-Sharing ebenfalls das Laufwerk C aktiviert ...

Ich klinke mich mal ein, da ich seit letzter Woche auch mit Docker arbeite. Nach einer kurzen Einarbeitung habe ich folgendes für mich und Contao 4.9.3 erstellt. Es handelt sich hier um eine reine Dev-Umgebung - nix zum Deployen :D

Code:

---

################################################################################
# Contao 4.x Docker Development Container
# running Apache 2,4, phpfpm@latest, mysql@latest
################################################################################
version: '3'
services:
    web:
        image: "webdevops/php-apache-dev"
        environment:
            DOCKER_DOMAIN: &hostname localhost
            PROJECT_NAME: &project contao
            DEFAULT_PASSWORD: &password contaodocker
            DOCROOT: web
            PHP_DISPLAY_ERRORS: 1
            PHP_MEMORY_LIMIT: "256M"
            PHP_MAX_EXECUTION_TIME: 30
            WEB_DOCUMENT_ROOT: '/app/www'
        ports:
            # access with http://localhsot:8080
            - "8080:80"
            # phpfpm Debugging
            - "9000:9000"
        volumes:
            - ./_www:/app
    db:
        image: mysql:5.7
        environment:
            MYSQL_ROOT_PASSWORD: *password
            MYSQL_DATABASE: *project
            MYSQL_USER: *project
            MYSQL_PASSWORD: *project
        volumes:
            - ./_mysql:/var/lib/mysql

---

Wir nutzen ein paar fertige Pakete aus dem Docker-Hub. Das ist alles. Die Datenbank wird zwar noch lokal gespeichert, aber da geht definitiv nix verloren. Wenn man es mit einem Dump macht, müsste man diesen immer neu erstellen, bevor man den Container beendet. Ich denke das geht eleganter, aber mit dem Verfahren da ist der MySQL-Server auch direkt einsatzbereit.

Ich empfehle eine kurze Recherche zu *:yml damit die & und * klar werden - der Rest ist recht simpel.

Legt bitte euer Projekt wie folgt an:

Code:

---

/<root>
    /_www
    /_mysql
    /docker-compose.yml

---

Das Projekt liegt dann im _www Verzeichnis und kann beliebig versioniert werden. Erreichen könnt ihr den Webserver unter http://localhost:8080/

Das ist alles. Ich hoffe ich konnte noch einmal ein wenig Hilfe zum Thema leisten.

PS: Ich nutze docker-desktop auf Win10-pro und es läuft soweit einwandfrei.

Nur zur Info:
Nachdem ich nicht mehr mit der "Docker Toolbox" arbeite sondern jetzt mit Win10-Pro und Docker (Hyper-V) + devilbox unterwegs bin:

Wer hierüber lokal via Konsole/Composer o. CM OHNE die Cloud arbeiten möchte muss evtl. das f. Docker zugewisene Memory auf ca. 4GB erhöhen (über die Win10 Docker/Dashboard Einstellungen).

Die aktuellen Speicher Peaks könnte man sich zuvor über die Composer Option --profile ausgeben lassen: https://getcomposer.org/doc/03-cli.md#global-options

Sofern die neue PHP Composer version 2.0 (s.: https://blog.packagist.com/composer-...now-available/) noch nicht integraler Bestandteil ist (https://github.com/cytopia/devilbox/issues/736),
kannst du dir diese zwischenzeitlich in den laufenden devilbox Containern wie folgt aktualisieren:

Über die »shell.sh« der devilbox kannst du dich in den laufenden PHP Container anbinden - allerdings mit den Rechten entsprechend der .env Konfiguration.
Diese reichen für das compser Update nicht aus: s.: https://devilbox.readthedocs.io/en/l...to-become-root

Daher dann wie folgt:

Code:

---

composer -V
sudo composer selfupdate --2
composer -V

---

Nur zur Info.
Das devilbox Release v.1.8.0 steht bereit. Hier u.a. mit PHP Composer 2.x:
https://github.com/cytopia/devilbox/pull/743

FYI docker/devilbox und composer 2.x:

Wegen: https://contao.org/de/news/contao-manager-1-4.html

Wer in seinem existierenden devilbox Container noch eine ältere composer Version vorfindet kann diese updaten:
- https://getcomposer.org/doc/03-cli.m...te-selfupdate-
- https://devilbox.readthedocs.io/en/l...to-become-root - s.o.
- Info: https://github.com/cytopia/devilbox/issues/736

Ansonsten beinhaltet die devilbox seit der Version 1.8.0 die composer v.2.x Version:
- https://github.com/cytopia/devilbox/pull/743

UPDATE Windows Nutzer:
Die obigen 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.

Grundsätzlich wird die "Docker Desktop" Nutzung/Installation mit "Windows 10 Home" via WSL2 möglich.
Unterschiede bzw. Begriffsdefinitionen im Vergleich zur "Windows 10 Pro" werden u.a. hier verdeutlichet:
https://superuser.com/questions/1561...per-v-vs-wsl-2

In Zusammenhang mit der devilbox sind dann z.B. die Konfigurationsangaben für UID/GID in der .env hinfällig - s.a.:
https://devilbox.readthedocs.io/en/l...id-on-win.html

Fehler nach Docker-Desktop Update:
s.a.: https://community.contao.org/de/show...l=1#post541590

GELÖST: s.a.:
https://community.contao.org/de/show...l=1#post541758