Ich hab mal eben die Blog-Engine gewechselt für die hier auftauchenden Inhalte. Ich mag PHP nicht, in erster Linie weil ich das hier alles auf meinem eigenen Server laufen habe und ich wenig Bock habe, jede Woche drei Sicherheitsupdates einzuspielen. Ohne PHP bleibt allerdings nicht wirklich viel übrig. Das Arbeitspferd in vielen Jahren war bisher Movable Type. Die Software fährt einen spannenden Ansatz und generiert statische HTML-Seiten, die dann ganz direkt und ohne viel Magie vom Webserver ausgeliefert wurden. Aber, Movable Type ist eine Perl-Software. Ich hatte in den letzten Jahren immer mehr das Gefühl ein antikes Museum zu betreiben. Es findet zwar nach wie vor Entwicklung statt, aber die Firma hinter dem Projekt hält es für eine clevere Idee, die aktuelle Version nicht länger unter einer OpenSource-Lizenz zu veröffentlichen. Ich melde daher seit einiger Zeit eine grundlegende Meinungsverschiedenheit an.
Da ich nicht vor habe viel mehr zu veranstalten als ein wenig rumgeblogge von Zeit zu Zeit, sehe ich keinen großen Sinn darin, jetzt irgend eines meiner für gut befundenen CMS / Frameworks auszupacken und an Kotti oder Django ein Blog-Plugin zu stricken. Für ein anderes Projekt hatte ich im letzten Jahr Pelican in der Hand.
Pelican ist witzig: Der Schwimmvogel läuft überhaupt nicht auf dem Server, sondern generiert lokal aus einem Haufen Markdown-Files eine Sammlung statisches HTML (also ähnlich wie Movable Type, nur lokal und ohne GUI). Für mich war an dieser Stelle die spannendste Frage, wie ich einen flüssigen Prozess auf die Füße gestellt bekomme, um fix Inhalte zu pushen, ohne jedes mal auf allen Geräten Pelican zu installieren, die Seite zu rendern und dann via SSH den ganzen Krempel zu pushen. Und das geht so:
Einfach vim aufmachen und eine Markdown-formatierte Textdatei schreiben. Meta-Daten in die Kopfzeile dumpen, speichern, fertig.
Der ganze Kram liegt in einem Git-Repository. Ich kann meine Änderungen daher einfach zu Github pushen, komme so von überall an den Content und habe sogar eine schicke Historie, wann ich was geschrieben oder geändert habe.
Sobald bei Github eine Änderung eingeht, legt Travis los, zieht sich das Repository und Pelican und rendert die Seite. Danke Travis!
Ich hab lange überlegt, was hier sinnvoll ist. Vor längerer Zeit hatte ich einen Ansatz mit Gitlab ausprobiert, bei dem ein Runner auf dem Zielsystem die Seite noch einmal rendert. Aber das ist ja eigentlich Blödsinn, die Seite ist ja bereits fertig. Wie kommt also der Content aus der Travis CI auf den Server?
Die Antwort: WebDAV. Auf dem Server läuft ein eigener nginx vhost für Travis, schick verschlüsselt dank Let's Encrypt und zugangsbeschränkt per Basic Auth. Travis bekommt von mir die Zugangsdaten und ein curl-Einzeiler pusht die gerenderte Seite. Fertig.
Das ist als Workflow natürlich weniger für Wordpress-Klicker:innen geeignet, aber für Menschen, die eh den ganzen Tag an Github hängen halte ich dieses Setup für einen ganz schicken Ansatz inklusive einem enormen Sicherheitsgewinn auf dem Zielsystem (vorausgesetzt ihr vertraut Travis CI).
Stefan Walluhn