Statt die Installation einer einzelnen Website zu automatisieren, eine Architektur, die Runtime, Anwendungen, persistente Daten und Deployment-Mechanismus trennt — konzipiert, um den Lebenszyklus mehrerer Grav-Websites zu beherrschen, ohne deren Betrieb zu duplizieren.
Der erste Bedarf war recht einfach: das Deployment einer als interne Dokumentation genutzten Grav-Website automatisieren.
Doch diese Website sollte sich nach dem Deployment weiterentwickeln. Seiten würden über die Admin-Oberfläche bearbeitet, Bilder hinzugefügt, Konten angelegt.
Ein erneutes Deployment der Anwendung durfte die Website deshalb niemals in ihren Ausgangszustand zurückversetzen und die im Betrieb erzeugten Daten zerstören.
Eine erste Grenze wurde sichtbar:
Die Anwendung muss ersetzbar sein. Die Nutzerdaten müssen überleben.
Die persistenten Inhalte wurden daher vom Lebenszyklus des Containers getrennt.
Dann brauchten weitere Projekte Grav-Websites. Die Frage lautete nicht mehr: Wie stelle ich diese Website bereit? sondern:
Wie lässt sich ein Mechanismus schaffen, mit dem sich mehrere Grav-Websites bereitstellen und betreiben lassen, ohne die Betriebslogik zu duplizieren?
In diesem Moment wurde aus einem Deployment-Problem ein Architekturproblem.
Im Betrieb erzeugte Inhalte müssen das Ersetzen eines Containers, ein Redeployment und einen Versionswechsel überstehen.
Die gemeinsame Mechanik darf nicht für jedes neue Projekt kopiert und angepasst werden.
Runtime, Anwendung, Daten und Deployment entwickeln sich weder im gleichen Takt noch aus denselben Gründen. Ihre Trennung sollte diese Lebenszyklen widerspiegeln.
Die Rückkehr zu einer vorherigen Version sollte so weit wie möglich denselben Mechanismus nutzen wie ein normales Deployment.
Secrets und sensible Konfiguration bleiben außerhalb der Anwendungs-Images und des versionierten Codes.
Die Analyse des ersten Deployments und die Ankunft neuer Projekte machten vier unterschiedliche Bereiche sichtbar: Runtime, Anwendung / Website, persistente Daten und Deployment-Mechanismus. Sie nur deshalb zusammenzufassen, weil sie derselben Website dienen, hätte eine unnötige Kopplung geschaffen. Die Architektur zielt daher darauf ab, diese Grenzen explizit zu machen.
grav-runtime stellt das gemeinsame technische Fundament bereit: Grav, PHP, Nginx und den von den Anwendungen erwarteten Vertrag. Sie kennt kein einzelnes Fachprojekt.
projet-gites, projet-lavallee-website und künftige Websites fügen nur das hinzu, was ihnen eigen ist: Theme, Plugins, Anwendungskonfiguration und Ausgangsinhalte. Jede Anwendung bleibt unabhängig versioniert.
ansible-role-grav-site zentralisiert die gemeinsame Mechanik: Vorbereitung der Instanz, persistente Volumes, Konfiguration, Secrets, Start, Health-Checks, Updates und Rollback. Die Rolle bleibt auf eine Instanz pro Aufruf ausgerichtet.
Seiten, Bilder, Konten und andere persistente Daten leben unabhängig vom Anwendungs-Image. Eine neue Version kann die Anwendung daher ersetzen, ohne automatisch ihren Produktionszustand zurückzusetzen.
Das erste Deployment ermöglichte es, eine grundlegende Regel zu formalisieren: rekonstruierbare Elemente gehören zur Anwendung; im Betrieb erzeugte Daten müssen außerhalb des Containers leben.
Grav, PHP, Nginx und die gemeinsamen Abhängigkeiten wurden in grav-runtime isoliert. Anwendungsprojekte müssen diese technische Schicht dadurch nicht mehr selbst aufbauen.
Die Betriebsmechanik wurde in ansible-role-grav-site zusammengefasst: Volumes, Secrets, Konfiguration, Health-Checks, bereitgestellte Version, Update und Rollback.
projet-gites, dann lavallee.tech, ermöglichten es, das Modell an mehreren realen Anwendungen zu prüfen. Die zweite Website deckte insbesondere Annahmen auf, die noch an das erste Projekt gebunden waren — Namen, Pfade oder Instanzeigenschaften — und löste deren Verallgemeinerung aus.
Eine Anwendung wird nur einmal installiert. Danach muss sie über Jahre betrieben werden können. Das gesuchte Modell lautet daher nicht mehr:
installsondern:
deploy → update → rollback → migrateDieser Unterschied prägt die Architektur. Die Runtime ist versioniert. Jede Anwendung ist versioniert. Daten bestehen unabhängig fort. Der Deployment-Mechanismus setzt den gewünschten Zustand um.
Rollback ist nicht als eigenständiges Notfallverfahren konzipiert. Verursacht eine neue Version ein Problem, wird einfach eine zuvor als stabil bekannte Version wieder zur gewünschten Version.
version 1.3.2
│
▼
deploy 1.4.0
│
problem
│
▼
ziel = 1.3.2
│
▼
derselbe deployment-mechanismusDas begrenzt Sonderverfahren genau auf den Moment, in dem sie am riskantesten wären: während eines Vorfalls.
Die erste Website hat einen Bedarf gelöst. Die zweite hat begonnen, die Architektur zu testen. Die nächsten müssen dieselbe Basis wiederverwenden können, ohne die Betriebslogik zu vervielfachen.
Es ist leicht, eine Architektur als „wiederverwendbar“ zu bezeichnen, solange sie erst einem einzigen Projekt dient. Der zweite Nutzer deckt die Annahmen auf, die in Wirklichkeit spezifisch für das erste waren.
lavallee.tech ist inzwischen selbst auf dieser Architektur bereitgestellt. Ihre Ankunft ermöglichte es, die letzten Instanzparameter zu identifizieren, die verallgemeinert werden mussten, damit die Deployment-Rolle eine atomare, wiederverwendbare Komponente bleibt.
Der nächste Schritt besteht darin, denselben Mechanismus für eine neue technische Dokumentationswebsite zu nutzen. Wiederverwendbarkeit wird daher nicht als deklarierte Eigenschaft betrachtet.
Sie muss durch neue Nutzer bestätigt werden.
Dieselbe Basis — grav-runtime + ansible-role-grav-site — wird unverändert für diesen neuen Nutzer wiederverwendet, der einzig wirkliche Beweis dafür, dass eine Architektur wiederverwendbar ist.
Der Einsatz von Open-Source-Software ist nur ein Teil des Problems. Eine Infrastruktur bleibt schwer zu beherrschen, wenn ihr Deployment von manuellen Eingriffen abhängt, ihre Daten mit der Anwendung vermischt sind oder niemand genau weiß, welche Version in Produktion läuft.
Diese Architektur zielt daher darauf ab, Folgendes explizit zu machen:
Open Source ist ein Mittel. Die Beherrschung des Systems ist das Ziel.
Inhaltserstellung und redaktionelles Design bleiben Sache jeder einzelnen Anwendung.
Die Deployment-Rolle verwaltet weder DNS noch Reverse Proxy noch TLS-Zertifikate. Diese Zuständigkeiten liegen bei der gemeinsamen Infrastruktur.
Backups bleiben notwendig. Grav vermeidet den Betrieb eines zusätzlichen Datenbankdienstes, aber die persistenten Dateien sind Produktionsdaten und müssen gesichert werden.
Die Deployment-Rolle verwaltet eine Instanz pro Aufruf. Die Orchestrierung mehrerer Websites wird bewusst auf einer höheren Ebene behandelt.
Anwendungen mit komplexen Fachfunktionen, hohem Traffic oder fortgeschrittenen Datenmodellen können außerhalb des natürlichen Anwendungsbereichs eines Flat-File-CMS wie Grav liegen.
Diese Trennung entstand nicht aus einem theoretischen Entwurf. Sie ist das Ergebnis der Entwicklung eines konkreten Bedarfs: die Daten einer ersten Website zu erhalten und dann zu verstehen, wie mehrere Anwendungen betrieben werden können, ohne ihre Infrastruktur zu duplizieren.
Ein automatisiertes Deployment ist nur ein Teil des Problems. Die eigentliche Frage ist, wie das System aktualisiert, diagnostiziert, gesichert, wiederhergestellt und langfristig weitergegeben wird.
Lassen Sie uns zuerst über Ihre Rahmenbedingungen sprechen →