Heiko Mamerow

In diesem vierteiligen Tutorial zeige ich, wie sich Docker als WordPress Entwicklungsumgebung – für Themes oder Plugins – auf einem lokalen Computer verwenden lässt. Mit dem Tutorial richte ich mich an Entwicklerinnen und Entwickler, die einen praktischen Einstieg suchen.

Die Teile meines Tutorials sind:

1. Grundlagen (Das ist dieser Beitrag.)
2. Installation und Konfiguration eines Hallo-Welt-WordPress-Stacks
3. Eine Entwicklungsumgebung für Theme- und Plugin-Entwicklung einrichten*
4. Mehrere WordPress Websites mit Docker parallel betreiben*

* Dieser Beitrag ist noch nicht veröffentlicht. Aber bald! ;-)

Übrigens am 25. Januar 2018 werde ich beim WordPress Meetup Berlin einen Vortrag zum Thema halten.

Teil 1: Grundlagen

In Teil 1 beginne ich mit dem „Urschleim“ und versuche zu erklären, was eine Entwicklungsumgebung ist, was das Konzept hinter Docker ist und wie sich das alles für die lokale Webentwicklung nutzen lässt.

1 Entwicklungsumgebung

Damit WordPress als Content-Management-System lauffähig ist, muss es in einer bestimmten Systemumgebung integriert sein.

Wenn wir WordPress herunter laden, haben wir nichts weiter als „ein paar Dateien“. Wenn wir die auf unserem Rechner ablegen, wird damit noch nichts passieren. Eine WordPress Website lässt sich damit noch nicht betreiben. Damit WordPress funktioniert, benötigt es mindestens folgende Umgebung:

1. Einen Webserver (meist Apache oder nginx)
2. Eine Skriptsrache auf dem Server: PHP (Am besten ab Version 7)
3. Eine Datenbank (MySQL oder MariaDB)
4. Last not least, ein Betriebssystem (meist Linux)

Diese Systemumgebung (Oft auch Softwarepaket, Softwarestack oder nur Stack genannt) kann sowohl auf dem lokalen Rechner angelegt werden, wo wir unsere Website entwickeln wollen, als auch auf dem Rechner des Providers, wo die Website letztendlich im Internet für alle erreichbar sein soll.

Im ersten Fall ist diese Umgebung unsere Entwicklungsumgebung. Im zweiten Fall ist es die Produktionsumgebung.

1.1 Wozu wird eine Entwicklungsumgebung benötigt?

Ganz egal ob es sich um einen kompletten Websiterelauch handelt, ein defektes Theme debuggt oder ein Plugin um eine Funktion erweitert werden soll. Alle diese Arbeiten sollten immer auf einer lokalen Entwicklungsumgebung ausgeführt und getestet werden, bevor der Code auf dem Livesystem zum Einsatz kommen. Erst wenn die Arbeiten auf der lokalen Entwicklungsumgebung abgeschlossen und getestet wurden, kann der Code mit ruhigem Gewissen auf die Produktionsumgebung überspielt werden.

Durch den Einsatz einer Entwicklungsumgebung kann sichergestellt werden, dass die Website immer erreichbar ist und auch funktioniert, wie sie soll. Neue Features und Bugfixes lassen sich von den Anwenderinnen und Anwendern unbemerkt im Hintergrund hochladen und es gibt keine Ausfallzeiten.

1.2 Entwicklungsumgebung == Produktionsumgebung

Der Unterschied zwischen einer Entwicklungsumgebung und der Produktionsumgebung ist in Bezug auf die Systemumgebung (siehe oben) nur nominell. Beide benötigen den gleichen Stack.

Aber warum dann zwei Namen für das Selbe?
Der Unterschied ergibt sich aus der praktischen Verwendung:

1.2.1 Entwicklungsumgebung

Die Entwicklungsumgebung benötigen wir, um dort beispielsweise frisch entwickelte Plugins zu testen oder um zu prüfen, ob das gerade geschriebene Stylesheet vom Theme in der Ausgabe das bewirkt, was wir möchten.

In einer Entwicklungsumgebung lässt sich prima spielen uns ausprobieren.

Weil niemand fehlerfrei entwickeln kann und außerdem zu Beginn nie ganz genau klar ist, wie ein bestimmte Aufgabe zu entwickeln ist, braucht es eine Systemumgebung zum Testen uns Ausprobieren. Das ist so eine Art „Sandkasten“ oder „Testgelände“ auf dem mal etwas schief gehen kann und keinen Schaden anrichtet.

Darüber hinaus ist es auch für die Entwicklung ganz nützlich, Fehlermeldungen anzuzeigen. Diese Meldungen würden normalerweise auf der Produktionsumgebung nicht ausgegeben werden.

Kurz: Alles, was wir den „End-Usern“ nicht zumuten wollen, aber zum Entwickeln irgendwie dazu gehört, passiert auf der Entwicklungsumgebung.

1.2.2 Produktionsumgebung

Die Produktionsumgebung ist die Umgebung auf der die Website „wirklich“ läuft. Hier sollte niemals getestet oder entwickelt werden. Selbstverständlich sollte hier auch die Ausgabe von Fehlermeldungen nicht sichtbar sein.

Darum ist es sehr wichtig – mindestens – diese beiden Umgebungen (Entwicklung/Produktion) zu haben! Es gibt darüber hinaus noch andere Arten von Umgebungen.

1.3 Entwicklungsumgebung === Produktionsumgebung

Wer kennt das nicht: Auf der Entwicklungsumgebung funktioniert die neue Website einwandfrei und auf der Produktionsumgebung klappt gar nichts….

Client: It don't work on my webserver!
Dev:    Mmmmh, but works on my machine.
¯\_(ツ)_/¯

Die Entwicklungsumgebung und die Produktionsumgebung sollten identisch sein. Oft ist es so, dass die Systemumgebung beim Provider (=Produktionsumgebung) als gegeben hingenommen werden muss. Dann ist es ratsam, die lokale Entwicklungsumgebung der Produktionsumgebung- so gut es geht – detailliert anzupassen.

Wenn der Provider z.B. einen LAMP-Stack anbietet, dann sollte unsere Entwicklungsumgebung ebenfalls ein LAMP-Stack sein. Doch das ist noch nicht genug. Wichtig sind auch identische Versionen und ggfl. Servermodule und -Konfigurationen. Unter Umständen können schon Unterschiede in der MySQL-Version bei Entwicklungs- und Produktionsumgebung zu unliebsamen Ergebnissen führen. Diese Gleichheit auf den Umgebungen lässt sich mit Docker sehr gut erstellen.

Je penibler wir unsere Entwicklungsumgebung der Produktionsumgebung anpassen, desto geringer ist die Gefahr, dass eine Funktion auf der Entwicklungsumgebung zwar läuft, aber auf dem Produktionsumgebung nicht.

…Dafür musste ich schon eine Menge Lehrgeld zahlen… ;-)

1.4. Eine kleiner Vergleich von Entwicklungsumgebungen

Es gibt bereits sehr viele Umgebungen, die für die lokale Entwicklung verwendet werden können. Für einen schnellen Vergliech habe ich die mir bekanntesten mal nebeneinander gestellt:

Wer einen ausführlicheren Vergleich zwischen MAMP, Vagrant und Docker haben möchte, sollte sich unbedingt Bernhards Vortrag „Local developement with Docker“ beim WordCamp Köln 2017 anschauen. Da geht er im ersten Teil seines Vortrages genauer auf die Unterschiede, Pros und Cons ein.

2 Docker

Docker ist eine Softwaretechnologie, bei der die Softwareanwendungen in jeweils eigenen geschlossenen Umgebungen isoliert laufen. So eine geschlossene Umgebung wird Container genannt. Das kann man sich im Falle von WordPress so vorstellen:

Wie oben schon beschreiben, wird Jede WordPress-Website im wesentlichen mit folgenden Anwendungen betrieben:

1. Server
2. Datenbank
3. Serverseitige Scriptsprache

(Das Betriebssystem habe ich vernachlässigt.)

Bei Docker ist jede dieser Anwendungen in einem eigenen Container isoliert. Wir hätten dann also drei Container.

Docker selber verbindet bzw. steuert diese Container und sorgt dafür, dass die Anwendungen – im Zusammenspiel mit dem Betriebssystem – das tun, was von ihnen erwartet wird: eine WordPress-Website bereit stellen.

Jede Anwendung läuft für sich in einem Container. Dadurch können Container miteinander verbunden werden.

Dieses „Container-Prinzip“ bringt gewaltige Vorteile gegenüber dem altbackenen statischem Ansatz wie z.B. bei LAMP, MAMP oder WAMP:

1. Jedes Projekt kann mit einer ganz individuellen Systemumgebung laufen.
   z.B. Eine Website soll auf nginx mit PHP 5.6 und MYSQL 5.5 laufen und eine andere Website auf dem selben Computer soll mit Apache und noch mit nginx als Reverse Proxy unter PHP 7.1 und MariaDB laufen. Mit Docker ist das kein Problem. Mit einem herkömmlichen statischem Softwarestack dagegen ein ziemlicher „Klimmzug“.
2. Es lassen sich mehrere Projekte parallel betreiben.
   Es ist möglich mehrere unterschiedliche Websiteprojekte gleichzeitig laufen zu lassen. Ein wahrer Segen, wenn z.B. ein Plugin auf mehreren unterschiedlichen Plattformen getestet werden soll.
3. Die Entwicklungsumgebung lässt sich klonen und auf anderen Rechnern einsetzen.
   Damit lässt sich die Arbeit im Team vereinheitlichen. Außerdem kann der Klone z.B. auch auf dem Liveserver verwendet werden.

Damit genug der Docker-Einführung. In Wirklichkeit war meine Einführung nur sehr ungenau und es fehlt noch sehr viel. Aber mehr müsst Ihr zum Anfang wirklich nicht wissen, um Docker benutzen zu können. ;-)

2.1 Hinweis zur Installation

Damit Docker verwendet werden kann, muss es natürlich auf dem Computer installiert sein. Inzwischen gibt es Docker für alle wichtigen Betriebssysteme und Cloud(s). Die Installation wird in der Docker Dokumentation bestens erklärt und sollte keine Probleme bereiten. Darum erspare ich mit hier die Details.

Übrigens gut zu wissen, dass es Docker in zwei Varianten gibt: 1) als Community Edition (CE) und 2) als Enterprise Edition (EE). Der für uns relevante Unterschied ist, dass die Community Edition kostenlos ist und die Enterprise Variante kostenpflichtig. Wenn es hier (und in den folgenden Beiträgen) um Docker geht, ist also immer die Community Edition gemeint.

2.2 Docker Compose

Wir haben Docker installiert und könnten theoretisch loslegen. Aber wir sollten auch noch etwas anderes installieren: Docker Compose

Mit Docker Compose wird die Konfiguration und Steuerung von Docker vereinfacht, weil sich damit alle Container in einer Konfigurationsdatei zusammenfassen lassen. Ohne Docker Compose müssten wir jede Anwendung einzeln Starten und konfigurieren und zwar jedes mal von Hand. Mit Docker Compose können wir alle Container in einer einzigen Datei festlegen und unser Projekt mit einem einzigen Befehl starten.

Die Installation ist genauso simpel wie vorher bei Docker. Die genaue Anleitung findet sich in der Dokumentation.

In meinen anderen Beiträgen werde ich ausgiebig Gebrauch von Docker Compose machen. Im Prinzip reicht es erstmal zu wissen, dass wir unser gesamte WordPress-Umgebung in einer Datei docker-compose.yml konfigurieren und diese dann mit einem Befehl aus der Kommandozeile starte. Dazu später mehr.

Wie geht es weiter?

Bis hier war alles graue Theorie. Und vielleicht hast Du noch nicht wirklich viel verstanden. Aber keine Panik. Es reicht, wenn Du erstmal nur eine ungefähre theoretische Vorstellung vom Arbeiten mit Docker hast.

im nächsten Teil wird die Vorstellung klarer. Dann zeige ich, wie sich ein ganzer WordPress-Stack mit Docker Compose erstellen lässt. Das kannst Du dann schon selber auf Deinem Computer ausprobieren. Dann fällt auch langsam der Groschen… ;-)