Von WordPress auf Hugo: Mein Weg zu einer deutlich einfacheren Website auf Azure

Viele Jahre lief meine private Website auf einer WordPress-Installation aus dem Azure Marketplace.

Die Lösung funktionierte grundsätzlich zuverlässig. Allerdings stellte ich irgendwann fest, dass der Aufwand für Betrieb und Wartung in keinem Verhältnis mehr zu meinem tatsächlichen Nutzungsverhalten stand.

Ich veröffentliche in der Regel nur wenige Artikel pro Jahr. Trotzdem musste ich mich regelmäßig mit Themen beschäftigen wie:

  • Linux-Updates
  • WordPress-Core-Updates
  • Plugin-Updates
  • Sicherheitsupdates
  • Datenbank-Backups
  • Azure VM-Wartung
  • SSL-Zertifikate
  • Überwachung und Absicherung des Systems

Für eine aktiv gepflegte Website oder einen Online-Shop ist das völlig normal. Für einen privaten Blog mit wenigen Beiträgen pro Jahr fühlte es sich jedoch zunehmend überdimensioniert an.

Die zentrale Frage

Irgendwann stellte ich mir eine einfache Frage:

Warum betreibe ich eigentlich einen kompletten Linux-Server mit MySQL, PHP und WordPress, wenn ich hauptsächlich statische Inhalte veröffentliche?

Die Antwort war ernüchternd:

Eigentlich gab es keinen technischen Grund mehr dafür.

Meine Website bestand fast ausschließlich aus:

  • Blogartikeln
  • Bildern
  • Kategorien
  • Tags

Es gab keine dynamischen Anwendungen, keine komplexen Formulare und keine speziellen Plugins, auf die ich zwingend angewiesen war.

Auf der Suche nach einer Alternative

Bei meiner Recherche stieß ich auf sogenannte Static Site Generatoren.

Die bekanntesten Vertreter sind:

  • Hugo
  • Jekyll
  • Astro

Entschieden habe ich mich für Hugo.

Ausschlaggebend waren:

  • sehr schnelle Build-Zeiten
  • einfache Installation
  • Markdown als Eingabeformat
  • große Community
  • zahlreiche Themes
  • einfache Hosting-Möglichkeiten

Der größte Vorteil:

Am Ende entstehen ausschließlich statische Dateien.

Keine Datenbank.

Kein PHP.

Kein laufender Anwendungsserver.

Migration der Inhalte

Der erste Schritt bestand darin, alle Inhalte aus WordPress zu exportieren.

Dafür nutzte ich den integrierten WordPress-Export unter:

Werkzeuge → Daten exportieren

Zusätzlich sicherte ich sämtliche Bilder aus dem Verzeichnis:

wp-content/uploads

Anschließend wurden die Inhalte in Hugo übernommen.

Die Bilder wanderten in die Hugo-Verzeichnisstruktur und konnten größtenteils ohne größere Anpassungen weiterverwendet werden.

Die ersten Erfahrungen mit Hugo

Der Einstieg verlief nicht vollständig reibungslos.

Insbesondere die Theme-Integration erforderte etwas Fehlersuche.

Anfangs meldete Hugo beispielsweise:

found no layout file for kind home

Die Ursache war letztlich schnell gefunden:

Das Theme war nicht korrekt eingebunden.

Nachdem das behoben war, erzeugte Hugo automatisch:

  • die Startseite
  • Beitragsübersichten
  • Kategorien
  • Tags
  • RSS-Feeds

ohne dass zusätzliche Entwicklung erforderlich war.

Warum ich auf GitHub und CI/CD verzichtet habe

Viele moderne Anleitungen empfehlen folgenden Aufbau:

Hugo
+
GitHub
+
CI/CD
+
Azure Static Web Apps

Für professionelle Projekte ist das durchaus sinnvoll.

Für meinen privaten Blog erschien es jedoch unnötig komplex.

Ich veröffentliche nur wenige Male pro Jahr einen neuen Artikel.

Daher wollte ich den einfachsten möglichen Veröffentlichungsprozess.

Meine finale Architektur

Am Ende fiel die Entscheidung auf folgende Architektur:

Markdown
        ↓
Hugo
        ↓
HTML-Dateien
        ↓
Azure Storage Static Website
        ↓
Azure Front Door
        ↓
www.richardts.com

Die gesamte Infrastruktur besteht heute aus:

  • Hugo
  • Azure Storage Account
  • Azure Front Door

Mehr wird nicht benötigt.

Azure Storage Static Website

Azure Storage bietet die Möglichkeit, statische Websites direkt aus einem Blob Container auszuliefern.

Nach Aktivierung der Funktion wird automatisch ein Container namens:

$web

angelegt.

Die Veröffentlichung besteht daher nur noch aus zwei Schritten:

Website generieren:

hugo

Anschließend den Inhalt des Verzeichnisses:

public

in den Container:

$web

hochladen.

Fertig.

Die unerwartete Herausforderung: SSL

Während der Migration stellte sich heraus, dass Azure Storage zwar automatisch eine HTTPS-Adresse bereitstellt:

https://myblogstatichugo.z6.web.core.windows.net

eine eigene Domain jedoch eine zusätzliche Lösung benötigt.

Mein Ziel war:

https://www.richardts.com

mit gültigem Zertifikat.

Die Lösung: Azure Front Door

Für die SSL-Terminierung und die Verwendung einer eigenen Domain habe ich Azure Front Door eingesetzt.

Die finale Architektur sieht damit so aus:

www.richardts.com
          │
          ▼
Azure Front Door
          │
          ▼
Azure Storage Static Website

Azure Front Door übernimmt:

  • SSL/TLS
  • Zertifikatsverwaltung
  • globale Auslieferung
  • Performanceoptimierungen

Besonders angenehm:

Das SSL-Zertifikat wird vollständig von Microsoft verwaltet und automatisch verlängert.

DNS-Konfiguration

Meine Domain wird bei Strato verwaltet.

Für die Einrichtung waren letztlich zwei Schritte erforderlich.

www.richardts.com

Die Subdomain verweist per CNAME auf den Azure Front Door Endpoint:

www.richardts.com
        ↓
<mein-frontdoor-endpoint>.azurefd.net

richardts.com

Die Hauptdomain wird dauerhaft weitergeleitet:

https://richardts.com
        ↓
301 Redirect
        ↓
https://www.richardts.com

Dadurch existiert nur eine öffentliche URL für die gesamte Website.

Vorteile der neuen Lösung

Der Unterschied zur ursprünglichen WordPress-Lösung ist deutlich.

Früher

Azure VM
Linux
PHP
MySQL
WordPress
Plugins

Heute

Markdown
Hugo
Azure Storage
Azure Front Door

Vorteile im Alltag

Geringere Kosten

Keine virtuelle Maschine.

Keine Datenbank.

Keine laufenden Serverprozesse.

Weniger Wartungsaufwand

Keine Linux-Patches.

Keine WordPress-Updates.

Keine Plugin-Updates.

Bessere Sicherheit

Es gibt:

  • keine Login-Seite
  • kein PHP
  • keine Datenbank
  • keine Plugins

Viele klassische Angriffsflächen verschwinden dadurch vollständig.

Höhere Performance

Da alle Seiten bereits als HTML-Dateien vorliegen, muss nichts dynamisch erzeugt werden.

Die Inhalte werden direkt ausgeliefert.

Mein neuer Veröffentlichungsprozess

Einen neuen Beitrag anzulegen ist heute denkbar einfach.

Neuen Artikel erstellen:

hugo new posts/mein-neuer-artikel/index.md

Lokal testen:

hugo server

Website erzeugen:

hugo

Anschließend die Dateien aus:

public

nach Azure Storage hochladen.

Mehr ist nicht erforderlich.

Fazit

WordPress bleibt für viele Szenarien eine hervorragende Lösung.

Für meinen persönlichen Blog war die Plattform jedoch längst größer geworden als die eigentliche Aufgabe.

Mit Hugo, Azure Storage Static Website und Azure Front Door habe ich heute genau das, was ich ursprünglich gesucht habe:

  • minimale Betriebskosten
  • kaum Wartungsaufwand
  • hohe Sicherheit
  • sehr gute Performance
  • volle Kontrolle über die Inhalte

Vor allem aber muss ich mich wieder auf das konzentrieren, worum es ursprünglich ging:

Artikel schreiben statt Server administrieren.