Kategorie: Code

Viele Jahre habe ich meine WordPress-Entwicklung mit dem MAMP-Projekt erledigt. Das ganze geht aber auch mit docker und das um einiges einfacher.

Das damp – Projekt liefert genau das und ist beim Aufsetzen einer neuen WordPress-Instanz zum Testen um vieles einfacher. Die Installation und Verwendung wird auf den Seiten ganz gut beschrieben und funktioniert.

Das einzige kleine Problem war, dass WordPress keine Schreibberechtigung auf den wp-content – Ordner hatte. Das merkt man spätestens, wenn man ein Plugin installieren oder aktualisieren oder aber ein Bild in einen Post hinzufügen möchte.

Das Problem hatten auch andere und nach 38 Stunden Internetrecherche hatte mir diese Github-Antwort geholfen. Es kann sein, dass das ein OSX-Problem ist und auf anderen Host-Betriebssystemen gar nicht auftritt. Ohne weiter ins Detail zu gehen wieso und weshalb, ist die Lösung für das Problem relativ einfach.

Man meldet sich auf der WordPress-Maschine an und führt die folgenden Befehle aus und startet die Maschine dann neu:

usermod -u 1000 www-data
chown -R www-data:www-data .

Im Detail geht es so:

Auf einer Konsole wurde damp gestartet.

damp up

Die Docker-Umgebung von damp einstellen

eval $(docker-machine env damp)

Die entsprechende WordPress-Maschine heraussuchen

docker ps

Die Liste mit den Docker-Maschinen-Ids und Namen wird angezeigt.

Nun eine interaktive Shell auf der entsprechenden WordPress-Maschine öffnen

docker exec -it <docker-wordpress-maschine-id> bash

Und dort die magischen Befehle zum Ändern des Besitzers der WordPress-Installation eingeben

usermod -u 1000 www-data
chown -R www-data:www-data .

Nun mit exit wieder von der Maschine abmelden.

Damit die Änderungen nun auch wirksam werden, muss der docker-container neu gestartet werden.

docker restart <docker-wordpress-maschine-id>

Voilá

Wenn irgendwann alle Tests für eine Webseite abgeschlossen sind, muss sie auf den Webserver deployt werden. Das erfolgt in der Regel über FTP. Es geht aber auch einfacher, wenn man auf dem Webserver git installiert hat.

Auf dem Webserver wird ein bare-Repository angelegt. In diesem gibt es einen Branch production, der die Produktionsversion der Webseite hält. Nach jedem push in das Repository auf dem Webserver wird der production-Branch automatisch in das Webseitenverzeichnis ausgecheckt.

Das Bare-Repository

Auf dem Webserver wird das leere Repository angelegt.

cd repositories
mkdir webseite.git
cd webseite.git
git init --bare

Das lokale Repository

Als nächstes wird das Bare-Repository in ein lokales Verzeichnis geklont. Der Vorteil ist, dass damit die remotes bereits konfiguriert werden:

git clone ssh://..../webseite.git

Nun kann man erstmal auf dem Repository arbeiten und dann den Arbeitsstand comitten bzw. pushen.

z.B.

git add "index.php"
git commit -m"Initialisierung"

Der Branch production muss noch angelegt werden:

git branch production

Hat man irgendwann einen Produktionsstand erreicht, kann in den Branch production gewechselt werden und der Stand vom master-Branch (oder einem Tag etc.) gemergt werden.

git checkout production
git merge master

Dann wird alles auf den Webserver in das Bare-Repository gepusht.

git push origin master production

Das Repository auf dem Webserver

Zuerst wird das repository in das Verzeichnis geklont. Anschließend wird der aktuelle Stand des production-Branches ausgecheckt.

git clone ../../repositories/webseite.git
cd webseite
git pull origin production

Der Hook

Nun soll genau das automatisch passieren. Dafür gibt es in jedem repository einen post-receive-hook. Hierbei wird die Datei webseite.get/hooks/post-receive nach einem push ausgeführt. Der Inhalt sieht also so aus:

#!/bin/sh

cd ~/webseite || exit
unset GIT_DIR
git pull origin production

Es ist wichtig, dass diese Datei auch als ausführbar markiert ist.

Nach dem Anlegen des Hooks muss noch kontrolliert werden, ob er tatsächlich funktioniert.