Betrieb und Wartung der Labud-Informatik-Webseite

Betriebsphilosophie

Der Betrieb der Labud-Informatik-Webseite folgt einem klaren Leitsatz

So einfach wie möglich – so stabil wie nötig.

Da die Webseite überwiegend statisch ist, existieren zwei Deployment-Varianten. Welche genutzt wird, hängt davon ab, ob maximale Einfachheit (GitHub Pages) oder maximale Kontrolle (Docker/Nginx) erforderlich ist.

Variante A Deployment über GitHub Pages

Wann GitHub Pages sinnvoll ist

GitHub Pages ist geeignet, wenn

• die Seite überwiegend statisch ist
• kein eigenes Server-Setup gewünscht ist
• die Betriebsverantwortung bewusst klein bleiben soll
• Deployments reproduzierbar direkt aus dem Repository erfolgen sollen

Technisches Prinzip

• Der Build läuft in GitHub Actions
• Das Ergebnis ist ein statisches Artefakt aus HTML, CSS und JavaScript
• Dieses Artefakt wird auf GitHub Pages veröffentlicht

Konzeptionell handelt es sich um einen klaren Build-zu-Publish-Ablauf ohne Laufzeit-Serverbetrieb.

Betrieb und Wartung

• Deployment erfolgt automatisch bei Push (typischerweise auf den Branch main) oder manuell per Workflow-Dispatch
• Rollbacks werden durch erneutes Deployen eines früheren Commits durchgeführt
• Monitoring beschränkt sich auf HTTP-Verfügbarkeit und den Status der GitHub Actions
• Trade-offs bestehen in eingeschränkter Kontrolle über HTTP-Header und Server-Konfiguration sowie dem Verzicht auf Containerisierung

Variante B Deployment als Docker-Container mit Nginx

Wann Docker und Nginx sinnvoll sind

Docker mit Nginx ist geeignet, wenn

• die Webseite in eigener Infrastruktur betrieben wird, etwa auf einer VM, einem Root-Server, in Kubernetes oder auf einem NAS
• volle Kontrolle über HTTP-Header, Caching oder Reverse-Proxy-Verhalten erforderlich ist
• eine einheitliche Container-Strategie im Betrieb verfolgt wird

Technisches Prinzip

• Der Build erzeugt statische Assets
• Diese Assets werden in ein unveränderliches Container-Image integriert
• Die Auslieferung erfolgt über Nginx innerhalb des Containers

Merkmale dieses Ansatzes sind ein einzelner Container, ein immutable Image, keine Laufzeit-Builds und keine externen Abhängigkeiten zur Runtime.

Deployment-Strategie

Der Betrieb ist bewusst pragmatisch ausgelegt

• Ein kurzer Service-Neustart beim Deploy ist akzeptabel
• Die Restart-Policy restart: unless-stopped sorgt für robustes Verhalten nach Host-Neustarts
• Auf zusätzliche Zero-Downtime-Komplexität wird bewusst verzichtet, da sie für eine statische Webseite keinen Mehrwert bringt

Konfigurationsstrategie

• In Production ist die Konfiguration Teil des Images und damit reproduzierbar und unveränderlich
• In Development wird Konfiguration gemountet, um schnelle Iteration zu ermöglichen

Vergleich der Deployment-Varianten

GitHub Pages steht für einen Low-Ops-Ansatz mit minimalem Wartungsaufwand und schneller Bereitstellung.
Docker mit Nginx bietet mehr Kontrolle und Flexibilität beim Hosting, erfordert jedoch eigene Infrastruktur.

Beide Varianten folgen demselben Grundsatz

Grundsatz Build-time statt Runtime-Komplexität

Security- und Verantwortungsabgrenzung

Unabhängig von der gewählten Deployment-Variante gilt

• Es werden keine sensiblen Daten im Frontend verarbeitet
• Die Webseite ist kein Applikations-Backend
• Die Verantwortlichkeiten zwischen Hosting-Plattform, Auslieferung und Code sind klar getrennt

Beim Betrieb mit Docker erfolgt die HTTPS-Terminierung bewusst außerhalb des Containers, abhängig von der jeweiligen Hosting-Umgebung.