Ein Neustart für meine persönliche Website
Die Vorgeschichte
Im Jahr 2018 habe ich zur besseren Trennung meiner privaten und beruflichen Webseiten-Inhalte eine separate Website unter der Domain niels-langlotz.com gestartet und wie es sich für einen TYPO3-Entwickler gehört, natürlich mit dem Enterprise Content-Management-System TYPO3 aufgesetzt. Im Jahr 2019 stand für mich dann die Umstrukturierung meiner IT-Infrastruktur insbesondere der Umzug meiner Hosting-Pakete in die Cloud dem Plan. Da ich mich in diesem Zeitraum auch sehr intensiv mit der Serverless-Thematik auseinandergesetzt habe und den Wunsch hatte, Server-Ressourcen zu sparen bzw. effizienter einzusetzen, war für mich bei diesem doch recht kleinen Projekt das Betreiben eines separaten Webhosting-Paketes doch etwas überdimensioniert.
Was wird für die TYPO3-Instanz benötigt?
Im Detail benötigt man für eine TYPO3-Website nämlich einen Webserver z. B. Apache oder NGINX, eine Datenbank z. B. MySQL oder PostgreSQL und ein paar spezifische PHP-Module, die nicht unbedingt bei jedem günstigen Einsteiger-Hosting aktiviert sind. Zudem benötige ich in meinen TYPO3-Projekten in der Regel einen SSH-Zugang um Befehle auf der TYPO3 CLI auszuführen und mit dem PHP-Package Manager Composer zu interagieren. Dann sind da doch noch die Themen Updates, Sicherheit und Backups.
TYPO3-Instanzen bedürfen einer regelmäßigen Pflege, Updates für den Core und die eingesetzten Extensions (Erweiterungen) müssen eingespielt und getestet werden und Passwörter müssen regelmäßig geändert werden. Um Datenverlust zu vermeiden und bei Änderungen auch auf frühere Layout-Varianten zurückgreifen zu können, muss sich auch intensiv mit der Backup-Thematik beschäftigt werden. Im Allgemeinen also alles ein recht hoher Aufwand für ein kleinen Projekt, an dem aktuell keine Änderungen am Inhalt oder dem Layout durchgeführt werden.
Benötige ich für meine private Website wirklich TYPO3?
Im Zuge meiner Infrastruktur-Umstrukturierung habe ich mir natürlich auch Gedanken gemacht, wie ich mit meiner persönlichen Website verfahren soll. Zu diesem Zeitpunkt hatte ich mir überlegt, die Instanz einfach mit in eine andere TYPO3-Installation (die der Hauptseite) zu überführen, die schon über optimierte Mechanismen verfügte oder die Inhalte einfach wieder zusammenzuführen und keine weitere separate Website mehr zu betreiben. Am Ende habe ich mich dann schließlich für Möglichkeit Nr. 3 entschieden, die Website als statische Version abzuspeichern und ohne großartige Änderungen erst mal weiterzuführen.
So habe ich die Website kurzerhand in statische HTML-Templates umgewandelt und die Dateien wieder auf den Server, auf dem nun kein PHP und keine Datenbank mehr aktiviert waren, hochgeladen. Die Website funktionierte wieder einwandfrei und war jetzt sogar noch etwas schneller als vorher. Der einzige Nachteil für mich war es, dass bei allen Änderungen an den Inhalten von nun an ein Code-Editor und ein FTP-Client benötigt wurden. Am Anfang war das für mich noch vertretbar, mit der Zeit war die Arbeit an der Seite aber ziemlich frustrierend und das mobile Arbeiten war nicht mehr ohne Weiteres möglich. Jeder, der schon mal Inhalte direkt in HTML geschrieben hat, weiß sicher die Vorzüge eines WYSIWYG-Editor zu schätzen.
Statisch “JA”, Inhalte direkt im Code schreiben “Nein”
So entschied ich mich 2020 dafür das Projekt mittels eines Website-Generator zu reaktivieren. Wichtig war mir dabei die Inhalte gesondert vom eigentlichen Code erstellen und pflegen zu können. Als Lösung schien mir ein Website-Generator mit Markdown-Support die einfachste und beste Lösung. So konnte ich die Inhalte in Markdown-Files einfach auch am Notebook schreiben und das Tool übernimmt dann die Umwandlung in validen HTML-Code. Da mir das JavaScript-Framework React bereits aus anderen Projekten geläufig war fiel nach einer kurzen Recherche fiel meine Entscheidung auf das das auf React aufbauende Tool Gatsby, insbesondere da für Gatsby bereits eine große Fülle an kompatiblen Modulen z.B. für das Einbinden verschiedener Datenquellen vorhanden sind.
Der Start meines ersten Gatsby-Projektes und der Weg zu Gitlab Pages
So war für mich der erste Schritt mein Projekt ins Gitlab einzuchecken und Stück für Stück alle Komponenten mit Gatsby nachzubauen, die Inhalte wurden dabei stets in Markdown-Dateien ausgelagert und bei der Generierung der fertigen Seitenstruktur magisch von Gatsby eingefügt.
Da Gitlab zu diesem Zeitpunkt das neue Feature “Gitlab Pages” eingeführt hat und um das Veröffentlichen von neuen Websiten-Version zu vereinfachen und allgemein auch zu beschleunigen habe ich auch das Ausspielen der Website in die Verantwortung von Gitlab übertragen. Nach Einrichtung der Deployment-Pipelines konnte ich das Webhosting-Paket kündigen, die MX-Records auf meinen Gitlab-Server umstellen und Gitlab kümmert sich seit dem automatisch um das Mapping des Projektes mit der Domain.
Automatisierung der Zertifikat-Erstellung für Letsencrypt
Mit Ablauf meiner bisherigen SSL-Zertifikate habe ich dann den Deployment-Workflow noch um eine automatisierte Neuaustellung von Letsencrypt-Zertifikaten erweitert. Der Renew-Ablauf erfolgt dabei vollautomatisch und direkt über die DNS-API von Hetzner.
Perfekt alles funktioniert reibungslos
Doch 100% zufrieden mit dem Workflow war ich leider noch nicht. Warum ich mich dann dafür entschieden habe, Markdown-Dateien wieder aus meinem Projekt zu verbannen und die Inhalte jetzt über das Headless-CMS Cockpit zu beziehen, lesen Sie im nächsten Beitrag der Serie.