Archiv des Autors: Heiko Mamerow

Über Heiko Mamerow

Buddhist, Vater, Freund, Internetseitenbauer, Sportler, Musikliebhaber & Verkehrsteilnehmer ;-)

WordPress Entwicklungsumgebung mit Docker – Teil 2: Hallo-Welt

Das ist der zweite Teil meines vierteiligen Tutorials WordPress Entwicklungsumgebung mit Docker.

Das bekommst Du bei Dir zu sehen, wenn Du diesen Beitrag durchgearbeitet hast.

Die Teile meines Tutorials sind:

  1. Grundlagen
  2. Installation und Konfiguration eines Hallo-Welt-WordPress-Stacks (Das ist dieser Beitrag.)
  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! ;-)


Teil 2: Installation und Konfiguration eines Hallo-Welt-WordPress-Stacks

In diesem Teil möchte ich einen simplen „Hallo-Welt-WordPress-Stack“ erstellen. Wenn Du Teil 1 gelesen und einigermaßen verstanden hast und bisher noch keine praktischen Erfahrungen mit Docker hattest, ist jetzt der Punkt, die ersten eigenen Gehversuche mit Docker zu machen. Also frisch ans Werk!

1 Vorbereitung

Stelle sicher, dass Du Docker und Docker Compose installiert hast. Die Installation für Linux, Mac oder Windows sollte kein Problem bereiten. Hier sind die Installationen ausführlich für jedes Betriebssystem erklärt:

  1. Installation Docker (Nimm die Community Edition = CE)
  2. Installation Docker Compose

Übrigens werde ich im Weiteren mit dem Terminal arbeiten. Falls das „Neuland“ für Dich ist, macht nichts. Learning by doing ist hier die beste Methode. Du kannst meine Kommandos kopieren und bei Dir in das Terminal eingeben. Der Sinn ergibt sich später im Laufe der Zeit.

Version ausgeben lassen
Wenn die Installation geklappt hat, lass Dir mal mit folgenden Kommandos die Versionen Deiner beiden Installationen ausgeben.

a) Version von Docker ausgeben lassen:

docker -v

Das sollte dann so aussehen:

b) Version von Docker Compose ausgeben lassen:

docker-compose

Das war ein kleiner Test, ob alles installiert wurde. Und es macht Dich gleich etwas mit der Kommandozeile vertraut.

2 Woher bekomme ich den Server, die Datenbank und WordPress?

Was wir wollen, ist ein WordPress-Stack mit Docker. Das bedeutet genauer: wir erstellen uns eine lokale Systemumgebung in der WordPress läuft. Diese Systemumgebung besteht aus folgenden Anwendungen: einer Datenbank, einen Server, PHP und last not least WordPress selbst. Um das Betriebssystem müssen wir uns nicht kümmern.

Achtung, gleich kommt es nochmal Dicke: Lass Dich durch die vielen neuen Begriffe nicht verwirren, das braucht seine Zeit. Aber das Gute ist: Docker klappt auch ohne, dass man das alles gleich genau versteht. ;-)

Wie im ersten Teil gelernt, läuft bei Docker jede Anwendung in einem eigenen Container. Jeder Container wiederum wird aus einem eigenen Image erzeugt. Das Image ist eine Art Blaupause für den Container. Wir laden z.B. ein WordPress Image herunter und aus diesem Image können wir dann so viele Entwicklungsumgebungen erstellen, wie wir wollen.

Wir könnten diese Images selber erstellen – müssen wir zum Glück aber nicht. Das haben andere für uns längst erledigt und die benötigten Images stehen uns kostenfrei auf sogenannten Registrys zur Verfügung. Das bekannteste Registry dürfte Docker Hub sein. Docker Hub verwende ich übrigens in meinem Tutorial.

Ein Registry kannst Du Dir wie „github für Docker Images“ vorstellen: ein (Online-)Service auf dem die Images gehostet sind, die wir für unsere lokale Entwicklungsumgebung benötigen. Unser lokal installiertes Docker lädt von dort via Internet die Images herunter und erstellt daraus die Container.

Das Herunterladen der Images passiert übrigens normalerweise nur beim ersten Start. Wenn wir einen Container starten und es gibt noch kein Image dafür auf dem Rechner, holt sich Docker dieses Image vom Registry. Solche Images können zum Teil recht groß sein. Es ist also ratsam beim ersten Start mit einer ordentlichen DSL-Verbindung am Netz zu sein. So lange wir das Image nicht löschen oder updaten, bleibt es erhalten. Die künftigen Container Starts sind dann wesentlich schneller und können auch offline durchgeführt werden.

Auf meinen Computern startet Docker und die Container automatisch beim Einschalten. Dieser Startprozess ist so schnell, dass ich ihn beim Hochfahren nicht mal bemerke.

Nachdem Du nun ungefähr weißt, woher wir unsere Anwendungen bekommen, können wir Docker Compose einrichten:

3 Entwicklungsumgebung mit Docker Compose konfigurieren

Docker Compose wird durch die Datei docker-compose.yml konfiguriert. Das ist so ungefähr die „wp-config.php“ unserer Systemumgebung. Hier teilen wir Docker mit, wie unsere Systemumgebung werden soll.

Aber zuerst lege bitte ein Verzeichnis an, wo Du die Umgebung anlegen möchtest. z.B.:

# Wechsel in Dein Home-Verzeichnis 
# Du kannst natürlich irgend ein anderes Verzeichnis wählen.
cd ~

# Lege ein Verzeichnis "hallo-welt-wordpress" an. 
mkdir hallo-welt-wordpress

# Wechsel in das neue Verzeichnis
cd hallo-welt-wordpress

Dann legst Du in dieses Verzeichnis eine leere Datei mit dem Namen docker-compose.yml an:

touch docker-compose.yml

Nun kannst Du die Datei mit einem Editor öffnen. Ich verwende nano als Editor im Terminal.

nano docker-compose.yml

In die geöffnete Datei kopiere das Folgende hinein:

version: '3.1'

services:

  wordpress:
    image: wordpress
    restart: always
    ports:
      - 8080:80
    environment:
      WORDPRESS_DB_PASSWORD: example

  mysql:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: example

WICHTIG: Du musst unbedingt die Einrückungen beachten! Auf die Details, gehe ich beim nächsten Beitrag etwas ausführlicher ein.

Speichern nicht vergessen. Mit nano geht das so – drücke die Tasten(kombination):

STRG x
y
Leertaste

Nun hast Du schon alle nötigen Vorbereitungen vollendet.

4 Docker Compose starten

Falls Du nebenher einen anderen lokalen Server laufen haben solltest, fahre den besser runter, bevor Du hier weiter machst. So vermeidest Du Überschneidungen.

Jetzt kannst Du Docker Compose mit dem Folgenden Befehl von Deinem oben angelegten Verzeichnis aus starten und schon läuft Dein lokales WordPress:

docker-compose up -d

Beim ersten Start wird es noch eine Weile dauern bis WordPress wirklich startklar ist, weil erst alle nötigen Images vom Docker Hub heruntergeladen und eingerichtet werden müssen. Das kann selbst bei flotter DSL-Verbindung ein paar Minuten dauern.

Beim ersten Start dauert es eine Weile…

Hol Dir also nen Kaffee und warte ab. Bei mir hat der erste Start des obigen Beispiels ca. sieben Minuten gedauert – mit einer 16 MBit/s DSL-Verbingung. Später wird das Starten dann übrigens nur knapp drei Sekunden dauern, weil dann die o.g. Images nicht mehr heruntergeladen werden müssen.

Wenn Du wieder den blinkenden Cursor im Terminal wieder siehst, ist alles erledigt.

Nach ca. sieben Minuten war der Cursor ist wieder da. Später dauert das nur drei Sekunden.

Herzlichen Glückwunsch, Du hast nun Dein erstes lokales „Hallo-Welt-WordPress-Docker“ gestartet! Du glaubst es nicht, dann gib mal folgendes in Dein Terminal ein:

curl -v http://localhost:8080

Als Ausgabe erhälst Du das:

Curl gibt Daten unseres Hallo-Welt Beispiels aus.

Mit dem Programm curl lassen wir uns alle Infos von unserem Hallo-Welt-WordPress ausgeben. „HTTP/1.1 302 Fount“ – das sieht sehr gut aus… :-D

Falls Du Docker Compose stoppen möchtest:

docker-compose down

…Neustart dann wieder wie oben.

5 Hallo Welt!

Ok, aber so kryptisch hattest Du Dir die Entwicklungsumgebung vielleicht nicht vorgestellt. Du willst richtig was sehen und mit WordPress arbeiten. Dann wechsel mal in den Webrowser Deiner Wahl und tippe in die Adresszeile: http://localhost:8080

Fertig. Docker läuft und WordPress kann eingerichtet werden.

Unsere Docker-Entwicklungsumgebung ist nun fertig eingerichtet und WordPress kann eingerichtet werden. Ab hier kommst Du sicherlich alleine voran. ;-)

Wie geht es weiter?

In diesem Teil haben wir nun im Schnelldurchlauf „irgendwie“ eine fertige WordPress-Docker-Umgebung angelegt. Das ist schon mal sehr gut, um etwas vertrauter mit Docker zu werden. Aber natürlich reicht das Wissen hier noch nicht ganz für die tägliche Arbeit. Im nächsten Teil erkläre ich dann die nötigen Details, die es braucht, damit wir Docker genauer konfigurieren können um Themes oder Plugins zu entwickeln.

WordPress Entwicklungsumgebung mit Docker – Teil 1: Grundlagen

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.

Docker Logo

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:

 StacksStacks in virtueller Umgebung
 LAMP LEMP MAMP MEMP WAMPWEMPVagrantDocker
Für Linux xxxx
Für Mac OS xxxx
Für Windowsxxxx
Apachexxxxx
Nginx x x xxx
MariaDBxx
MySQLxx
Parallelbetriebxx

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… ;-)

WordPress Datenbank umziehen mit der Kommandozeile

Irgendwann trifft es alle einmal: Die Website muss umziehen. Vielleicht weil der Provider gewechselt werden soll oder weil ein Klon auf der lokalen Entwicklungsumgebung benötigt wird. Grundsätzlich lässt sich der Umzug a) mit Plugins oder b) mit der Kommandozeile erledigen.

In diesem Tutorial möchte ich den Umzug mit der Kommandozeile zeigen. Doch erst einmal möchte ich auf die Frage eingehen:

Warum überhaupt ein Umzug mit der Kommandozeile?

Die meisten entscheiden sich wahrscheinlich eher für ein Plugin. Jedenfalls gibt es schier unzählige Tutorials bei denen beschreiben wird, wie eine Website mit Hilfe eine Plugins umgezogen wird. Dagegen finden sich kaum Infos über den Umzug mit der Kommandozeile.

Die Umzugs-Plugins kommen der gewohnten Arbeitsweise entgegen. Sie sind schnell installiert und können zum Teil sogar von technisch eher unversierten Leuten verwendet werden. Es gibt ein Formular, wo die Umzugsdaten eingetragen werden. Ein Knopfdruck und ab geht die Post.
In einer idealen Welt…

In der Realität kann so ein Umzug mit einem Plugin sehr ernüchternd sein. Wer es nicht glaubt, schaue mal in die Supportforen von solchen Plugins. ;-)

Mein Argument für den Umzug mit der Kommandozeile ist Zuverlässigkeit. Ich hatte leider in der Vergangenheit viele Probleme beim Umzug von größeren WordPress-Datenbanken (>mehrere hundert MB groß) auf eng beschnittenen Webservern (v.a. wegen kurzer Laufzeiten von Scripten) Auf der Suche nach einer verlässlichen Alternative bin ich schließlich auf die Kommandozeile gestoßen. Seit zwei Jahren arbeite ich auf diese Weise. Ich transferiere fast täglich Datenbanken von meiner lokalen Entwicklungsumgebung zum Liveserver bei den Kunden und umgekehrt. Seit ich den Weg über die Kommandozeile nehme, ist mir beim Umzug noch nie ein Problem aufgetreten!

Darüber hinaus ist die Kommandozeile ein sehr mächtiges und nützliches Tool für das täglichen Arbeiten auf dem Rechner. Dazu vielleicht später mal mehr in einem anderen Beitrag.

Deine Kommandozeile, das unbekannte Wesen

Die Kommandozeile – aka Terminal aka Konsole aka Befehlszeile aka CLI – ist auf jedem Betriebssystem zu finden. Aber genutzt wird sie wahrscheinlich nur von einer Minderheit. Es gibt sehr viele Vorbehalte selbst bei gestandenen Entwicklern und Entwicklerinnen.

Kommandozeile

Die Kommandozeile: nur ein unscheinbares Fenster mit einem blinkenden Cursor.

Die Kommandozeile ist der Ein-/Ausgabebereich zur textbasierten Steuerung des gesamten Computersystems. Es werden mit der Tastatur Befehle eingetippt und Ergebnisse ausgegeben.

Weil es keine grafische Oberfläche gibt, kommt die Kommandozeile bzw. die Programme, die darüber laufen, mit weniger Ressourcen aus als vergleichbare Programme mit einer grafischen Bedienoberfläche. Und sie sind dadurch vergleichsweise schneller.

Aber das ist längst nicht alles. Es gibt sehr viel kleine Kommandozeilenprogramme, die alle miteinander kombiniert werden können und sich automatisieren lassen.

Die Bash = Standard-Kommandozeile unter Linux

Es gibt viele Komandozeilenprogramme. ich verwende in meinem Beitrag das wohl verbreitetste: die Bash. Falls Ihr ein anderes Programm benutzt, sollten meine Beispiele genauso funktionieren.

Ich werde hier keine Einführung in die Bash geben. Die unten genannten Beispiele sind selbsterklärend und für alle nachvollziehbar. Allerdings kann es nicht schaden, sich mal grundsätzlich mit dem Konzept und Arbeitsweise auseinanderzusetzen.

Datenbank-Umzug

Im folgenden Beispiel erkläre ich, wie eine WordPress-Datenbank von einem Liveserver auf einen Server mit einer anderen Domain umgezogen wird.

Liveserver: http://wpdbash.test/

Testserver: http://local.wordpress.dev/

Für den Umzug ergeben sich folgende Schritte:

  1. Datenbank (Dump) vom Liveserver exportieren
  2. Dump komprimieren
  3. Transfer zum Testserver
  4. Dump dekomprimieren
  5. Dump importieren
  6. URLs im Dump an den Testserver anpassen

Zum Einsatz kommt dafür: Das Kommandozeilenprogramm Bash und die WP-CLI.

Eine wichtige Grundvoraussetzung ist außerdem, dass ein Zugriff per ssh auf die beiden Server möglich ist.

WP-CLI ist dein Freund

Die WP-CLI ist ein Kommandozeilenprogramm, das sehr viele nützliche Kommandos für die Arbeit mit WordPress bereit hält. Es erleichtert uns viele Arbeitsschritte und macht den Umzug ganz sicher.

Ich muss ehrlich gestehen, dass ich die WP-CLI bisher nicht ernsthaft verwendet hatte, weil ich mir die extra Installation zu aufwendig war und ich die URL-Anpassung mit einem vorhandenen Bash-Tool erledigt hatte. Dank eines freundlichen Hinweises von David Stingl weiß ich nun aber, dass ich ab jetzt und in aller Zukunft meine Faulheit überwinden und die WP-CLI einsetzen werde!

Auch auf die Einführung der WP-CLI möchte ich hier verzichten. Installation und Anwendung ist – wie man es bei WordPress nicht anders gewohnt ist – umfassend und verständlich.

Schritt 1: Datenbank vom Liveserver exportieren

Ich gehe davon aus, dass der Liveserver irgendwo bei einem Hoster steht. Der Testserver befindet sich auf einer Vagrant Entwicklungsumgebung auf dem eigenen Computer.

Um von der Bash auf dem lokalen Rechner zum Liveserver zu gelangen verwendet man ssh:

ssh user@wpdbash.test

ssh – Startet ssh
user – Loginname für ssh Zugriff
wpdash.test – die Adresse des Liveservers

Anschließend fragt die Kommandozeile noch nach dem Passwort. Nach der erfolgten Einwahl ist das „Innere“ des Liveservers erreicht. Jetzt kann die Datenbank vom Liveserver exportiert werden. Das wird im Schritt 2 erklärt.

Aber zuvor sollte erst mal ein Sicherheitsbackup von der Datenbank angefertigt werden:

wp db export sicherheitsbackup.sql

wp – startet WP-CLI
db export – exportiert die Datenbank
sicherheitsbackup.sql – der Dateiname des Sicherheitsbackups

Das Sicherheitsbackup bleibt unangetastet. Für den „Fall der Fälle“ lässt es sich später so zurückspielen:

wp db import sicherheitsbackup.sql

Jetzt weiter mit dem eigentlichen Export:

wp db export wpdbash.sql

Es wurde nun also die Kopie der Datenbank (Dump) angelegt, die im weiteren für den Umzug verwendet wird.

Schritt 2: Dump komprimieren

Dieser Schritt ist zwar für den eigentlichen Umzug nicht notwendig. Aber durch die Komprimierung wird der Dump kleiner und lässt sich somit schneller über das Internet übertragen.

gzip wpdbash.sql

Vom gzip-Programm wurde der Dump umbenannt in: wpdbash.sql.gz

Schritt 3: Transfer zum Testserver

Die Arbeit auf dem Liveserver ist getan. Die ssh-Verbindung kann abgebrochen werden:

exit

Nun geht es in der Bash auf dem lokalen System weiter. Der Dump wird transferiert:

scp user@wpdbash.test:/liveserver/pfad/wpdbash.sql.gz /lokaler/pfad/wpdbash.sql.gz

scp – startet den Transfer
user – Loginname für ssh Zugriff
wpdbash.test – die Adresse des Liveservers
:/liveserver/pfad/wpdbash.sql.gz – Pfad auf dem Liveserver zum Dump
/lokaler/pfad/wpdbash.sql.gz – Pfad auf dem lokalen Rechner, wo der Dump hin soll

Schritt 4: Dump dekomprimieren

gzip -d wpdbash.sql.gz

-d – Dekomprimiert den Dump und benennt ihn wieder um: wpdbash.sql

Schritt 5: Dump importieren

wp db import wpdbash.sql

Schritt 6: URLs an den Testserver anpassen

Der Dump wurde nun in die WordPress Datenbank des Testservers importiert. Im letzten Schritt müssen noch die Pfade an die Testumgebung angepasst werden. Dazu reicht es, die URLs zu ersetzen:

wp search-replace 'wpdbash.test' 'local.wordpress.dev'

wp – startet WP-CLI
search-replace – startet das Suchen und Ersetzen Programm der WP-CLI
‚wpdbash.test‘ – das zu ersetzende (Liveserver)
‚local.wordpress.dev‘ – das Ersetzende (Testserver)
–export=wpdbash.sql – Die Datenbank wird in die Datei wpdbash.sql exportiert

Fertig! Die Datenbank wurde damit auf den Testserver übertragen. :-)

Performance Vergleich: WordPress vs. statische Webseite

Mit diesem Beitrag möchte ich klären, welchen Einfluss WordPress auf die Web-Performance einer Webseite hat. Und ich mache auch noch einen Verbesserungsvorschlag. ;-)

Hintergrund

Letzte Woche hatte das Smashing Magazine eine Preview der neuen Website veröffentlicht. Dabei wurde bekannt gegeben, dass es eine Abkehr von WordPress geben soll. Was mich überraschte, war die Begründung: Es geht – neben der Zusammenführung von unterschiedlichen Plattformen – um die Verbesserung der Performance.

Das führte mich zur Frage:

Gibt es einen Unterschied in der Performance zwischen WordPress getriebenen Webseiten und statischen Webseiten?

Methode

Um der obigen Frage nachzukommen, hatte ich mir folgende Methode überlegt: Ich vergleiche die Web-Performance von identischen Webseiten, die mit und ohne WordPress angetrieben werden.

Natürlich ist klar, dass eine dynamisch generierte Webseite – wie es z.B. bei WordPress – von Hause aus langsamer sein muss als eine statische Webseite. Denn die Seiten werden erst beim Seiten Aufruf generiert. Die Generierung benötigt Zeit und kostet Performance. Darum kommen sinnvollerweise Caching Plugins zum Einsatz, die generierte Seiten archivieren. So dass sie nicht bei jedem Aufruf neu erzeugt werden müssen. Entsprechend habe ich auch das Page Caching berücksichtigt.

Versuchsaufbau

  • Server: Varying Vagrant Vagrants in der Standardkonfiguration.
  • WordPress
    • Plugins
    • Theme: Twenty Seventeen
      • Header-Image
      • Google Fonts entfernt, um Ladzeiten von externen Dateien auszuschliessen
    • Permalinks: Post name
  • Statische Seite
    • 1:1 Kopie der WordPress Startseite als HTML Dokument in einem eigenen Verzeichnis
    • Alle Assets ebenfalls in eigenes Verzeichnis kopiert und die entsprechenden Links auf die Assets im HTML Dokument angepasst.

Ich hatte eine exakt gleiche Dummy Webseite auf drei verschiedene Arten generiert und gemessen. Sie sahen alle so aus:

image-582141

Screenshot der Dummy Webseite

Ergebnisse

Gemessen hatte ich mit dem Developer Tool von Chrome. Hier die Screenshots der Ergebnisse:

1) Webseite mit WordPress

image-582142

2) Webseite mit WordPress und Page Caching

image-582143

3) Statische Webseite

image-582144

Auswertung

Die Ladezeiten für die Assets liegen bei allen drei Seiten auf dem selben Niveau und können somit vernachlässigt werden. Sie haben keinen Einfluss auf die Unterschiede in der Performance.

Die drei Messungen unterscheiden sich lediglich bei den Ladezeiten für das Document. Wie zu erwarten ist die Ladezeit der Webseite mit WordPress am höchsten: 63 ms. Wenn diese Seite im Page Cache vorgeladen wird, gibt es schon eine ordentliche Performance Verbesserung: 15 ms. Aber diese Zeit liegt trotzdem noch deutlich hinter der Ladezeit für die statische Webseite: 8 ms.

Woher kommt der Unterschied beim Caching vs. Statisch?

Page Caching bedeutet, dass die Webseite als statische HTML Datei generiert wird. Webseite 2) und 3) sind also identisch. Trotzdem wird 2) von WordPress langsamer ausgeliefert. Der Grund ist klar: anders als bei 3) liegt die vom Cashing Plugin vorgenerierte Datei nicht an dem Ort, der in der URL angegeben ist. Der URL Aufruf muss erstmal auf das Caching-Archiv umgeleitet werden. Dieser Prozess dauert seine Zeit und dass macht den Unterschied zwischen 2) und 3).

Zusammengefasst: Der Unterschied in der Performance zwischen mit WordPress gecachten und statischen Webseiten ergibt sich aus der Charakteristik der Cache-Archivierung und des Mappings. Dem geschuldet ist der kleine Verlust in der Performance.

Schlussfolgerung

Aus den obigen Messungen lässt sich schließen, dass WordPress generierte Webseiten tatsächlich langsamer sind als Ihre statischen Pendants.

ABER ! ! !

Allerdings sind die Performance Einbussen durch WordPress relativ gering, wenn Page Caching zum Einsatz kommt. Und selbst diese relativ geringe Performance Einbusse ließe sich noch weg bekommen, …

Verbesserungsvorschlag

…wenn das Page Caching anders gelöst würde. Indem die generierten Seiten nicht irgendwo in einem Cache Archiv umgeleitet werden, wäre der kleine Performance Nachteil zu den rein statischen Webseiten aufgehoben.

Prinzip des Page Cachings, wie es mit den WordPress Plugins bisher umgesetzt wird:

/
- index.php
- wordpress/
            - cache-archive/
                             - index.html
                             - blog.html
                             - products.html
                             - portfolio.html
                             - contact.html
                             - about-us.html
            - wp-admin/
            - wp-content/
            - wp-includes/
            - etc...

Der Seitenaufruf muss erst in das Cache Archiv weitergeleitet werden. Das kostet Zeit.

Neuer Ansatz für ein Page Caching mit „echten“ Seiten, deren HTML-Dokumente vom Caching Plugin direkt in die Root gelegt werden:

/
- index.html
- blog.html
- products.html
- portfolio.html
- contact.html
- about-us.html
- index.php
- wordpress/
            - wp-admin/
            - wp-content/
            - wp-includes/
            - etc...

Hier würde der Seitenaufruf direkt bei der Seite landen, weil sie schon dort liegt. Eine Weiterleitung erübrigt sich. Mit diesem Ansatz gäbe es keine Nachteile.

 

Automatisiertes Web-Performance Monitoring mit SpeedTracker

Die Grundlage für die Web-Performance Optimierung (WPO) sind Messdaten. Zum einen weil durch Messwerte die Schwachstellen in der Performance bestimmbar (und lokalisierbar) werden und zum anderen, weil die Messungen den Erfolg (oder Misserfolg) der Optimierungsmaßnahme zeigt.

Von Methoden- und Messfehlern einmal abgesehen, sind bei der Performance Optimierung auf Grundlage einer Datenbasis „alternative Fakten“ nicht möglich. Diese Ehrlichkeit macht mir WPO sehr sympathisch. :-)

Messdaten aber wie?

Der Quasi-Standard für die Performancemessung von Internetseiten ist WebPagetest.

image-582126

Hiermit lassen sich alle wichtigen Daten messen – wie zum Beispiel Ladezeiten, Rendering, Anfragen, Dateigrößen usw. Darüber hinaus werden die Messungen – in einem persönlichen Account – bis zu einem Jahr vorgehalten und lassen sich historisch vergleichen.

Für die schnelle IST-Stand-Analyse ist WebPagetest neben den Developer Tools in den Browsern meiner Meinung nach das beste „Messwerkzeug“ überhaupt.

Messdaten grafisch aufbereitet – Monitoring

Zugegeben die Möglichkeit des historischen Vergleichs von Messdaten bei WebPagetest sind schon enorm. Allerdings sind sie relativ umständlich zu abzufragen und nicht geeignet um z.B. dauerhaft Entwicklungen (Trends) aufzuzeigen. Vor allem deshalb, weil die Daten manuell gemessen werden müssen. Es wäre also gut, wenn die Messungen a) automatisiert und b) grafisch aufbereitet werden.

Dank der WebPagetest RESTful API lassen sich alle Messungen „remote“ ausführen und dadurch steuern (Automatisierung), grafisch aufbereiten und archivieren.

Bis hierhin klingt das alles einleuchtend und ganz gut. ABER: Das Messen und Auswerten von Daten über einen längeren Zeitraum wird sehr aufwändig und unübersichtlich. Ohne geeignete Software oder -Service wird das Monitoring von mehreren Websites ganz schnell unübersichtlich und artet in sehr viel Arbeit aus.

Auf dem Markt gibt es bereits entsprechende Tools, die diese Arbeit leisten. Allerdings – und ganz zu Recht! – sind diese Services nicht umsonst. Das macht den Einstieg in die Performance Optimierung unmöglich. Auch für gemeinnützige Web-Projekte mit schmalen Budgets war da nichts zu machen. Bisher fehlte eine kostenlose Alternative.

Aber Rettung ist da: SpeedTracker

Performance Monitoring mit SpeedTracker – Open Source und kostenlos

SpeedTracker ist ein Werkzeug, mit dem sich die Web-Performance von Websites über längere Zeit automatisiert messen lässt. Die Daten werden grafisch aufbearbeitet und auf einer Übersichtsseite ausgegeben:

image-582127

Um SpeedTracker zu betreiben wird lediglich ein GitHub Account benötigt. Wer einen Free Account hat, sollte bedenken, dass die Messdaten dann natürlich öffentlich einsehbar sind. Mit einem Premium Account sind die Daten – bzw. das gesamte Repository – öffentlich nicht sichtbar.

Keine Installationsanleitung!

Ich spare mir die Anleitung für die Installation bzw. Konfiguration. Das ist alles sehr gut bei SpeedTracker beschrieben: https://speedtracker.org/docs

Wer SpeedTracker auf einem eigenen Server betreiben möchte, kann dies natürlich auch. Dazu muss die API angepasst werden. Ich selber habe damit allerdings noch keine Erfahrung.

Performance Budget

Viel Interessanter als die Auslagerung auf einen eigenen Server finde ich die Möglichkeit, ein Performance Budget zu bestimmen. Damit können „Limits“ für bestimmte Messwerte gesetzt werden. Wird so ein Limit überschritten, dann lässt dieses Ereignis ganz praktisch per E-Mail oder Slack mitteilen.

Einschränkung

Das ganze Monitoring bis hin zu GitHub lässt sich kostenlos betreiben. Aber natürlich bringt das auch gewisse Grenzen. Die Messungen pro Tag und Profil sind eingeschränkt:

  1. Je Profil kann maximal zweimal täglich gemessen werden.
  2. Es können insgesamt (also alle Profile zusammen) nur 200 Messungen pro Tag durchgeführt werden.

Die Beschränkung hat mir bisher nie in Probleme gemacht, obwohl ich das recht intensiv nutze.

Allerdings gab es mal eine Ausnahme: In Vorbereitung auf meinen Performance-Vortrag beim WordCamp Köln wollte ich 202 Websites von den Teilnehmerinnen und Teilnehmern auf Performance messen. Mit den obigen Einschränkungen hätte das zwei Tage gedauert. Weil ich aber nur einen Tag Zeit hatte, hatte ich einen Trick angewendet: Einfach einen weiteren API-Key von einem anderen Account (wichtig: andere E-Mail-Adresse!) anfordern… ;-)

WebPerformance / DevOps

Die Hielscher Ultrasonics GmbH ist mein ältester „Dauerkunde“. Die Website ist das wichtigste Marketinginstrument der Firma. Damit vertreibt sie weltweit Ihre Produkte (Made in Germany!).

Die größte Herausforderung ist ganz klar die Web Performance und die weltweite Erreichbarkeit. Also auch für Länder mit eher langsamen Internet und alten Browsern.

Projekt:Relaunch Website, Performance Optimierung und regelmäßiger Support der Firmenwebsite
Kunde:Hielscher Ultrasonics GmbH
Leistung:Theme Entwicklung (Custom Theme), Web Performance Optimierung, WordPress, Serveradministration
Herausforderung:
  • Responsive Webdesign
  • Browserkompatibilität auch für Internet Explorer 9
  • fortlaufend Erweiterung und Umbau
  • Mehrsprachigkeit: 79 Sprachen (z.T. automat. Übersetzung)
  • Aufbereitung für Content Delivery Network
  • Minifizierung der Bilder und des Codes
  • SSL
  • HTTP/2
  • Server Push
  • Security
Online seit:2012 (1. Relaunch), 2014 (2. Relaunch)
URL:www.hielscher.com

WordPress Integration

Bei diesem Projekt wurde ich von der RapidComp GmbH als „WordPress Fachmann“ eingesetzt. Es galt für mich, aus bestehenden „HTML-Klick-Dummys“ ein Theme zu erstellen und lauffähige Website(s) mit Dummy-Content. Denn genau genommen war es nicht nur eine Website, sondern mehrere regionalisierte Website-Varianten: mit eigener Domain je Land und länderspezifisch angepassten Content und Sprache.

Die größte Herausforderung war für mich die Umsetzung von Mehrsprachigkeit, Multidomain und Regionalisierung mit nur einer WordPress-Installation. Normalerweise wäre das nämlich ein klassischer Fall für Multisite-WordPress. Aber das war hier leider nicht möglich.

Projekt:Relaunch einer Website der BillPay GmbH
Kunde:RapidComp GmbH
Leistung:Theme Entwicklung (Custom Theme)
Herausforderung:
  • Responsive Webdesign
  • Mehrspachigkeit: vier Sprachen
  • Multidomain: 4x
  • Regionalisierung: vier Länder – je zweisprachig
  • Single-Installation (!!!)
  • sehr viele Custom Fields, Post Types, Taxonomies, Custom Walker
Online seit:November 2016
URL:www.billpay.de

WordPress.tv – Das Video zum Vortrag über Datenkompression

Am 26.01.2017 hatte ich beim WP Meetup Berlin einen Vortrag zum Thema Datenkompression gehalten. Meinen Beitrag dazu gibt es hier. Aber das Video möchte ich natürlich nicht vorenthalten.

Es ist übrigens der erste Videomitschnitt beim Berliner Meetup. Das Ganze wird ermöglicht durch Bernhard Kau. Dazu hat er sich eigens ein komplettes Aufnahmeequipment zugelegt, erledigt die Aufzeichnung, schneidet und lädt alles hoch. Er will ab jetzt immer die Vorträge in Ton und Bewegtbild festhalten und auf WordPress.tv veröffentlichen.

DANKE BERNHARD! :-)