Sie geben einen Namen, eine Domain, den Cluster und Ihre MySQL-Instanz an. Clusterward legt Anwendung, Datenbank, Festplatte mit täglichen Snapshots, Cron-Job und Zertifikat an und rollt WordPress aus. Bis Sie die Installation abgeschlossen haben, schützt ein Passwort die Seite vor Fremden.
WordPress auf Kubernetes zu betreiben heißt normalerweise: ein Chart auswählen, Values schreiben, eine Datenbank anlegen, die Festplatte planen, Cron einrichten, ein Zertifikat besorgen und hoffen, dass niemand vor Ihnen den Installer aufruft. Der App-Katalog von Clusterward erledigt das mit einer Vorlage, die wir pflegen und vor der Aufnahme live testen. Das Ergebnis ist eine ganz normale Anwendung in Ihrem Cockpit: Jede Einstellung bleibt änderbar, nichts hängt danach an der Vorlage.
Name, Domain, Cluster und MySQL-Instanz – mehr fragt der Katalog nicht.
Anwendung, Datenbank, Festplatte, Service und DNS-Record entstehen, jeder Schritt sichtbar.
Hinter dem Einrichtungs-Passwort den WordPress-Installer durchlaufen und Ihr Admin-Konto anlegen.
„Open to everyone“ entfernt den Schutz, die Seite ist nach einer Minute für alle erreichbar.
Alles, was WordPress auf Kubernetes stabil macht, ist von Anfang an eingerichtet.
Eine MySQL-Datenbank mit eigenem Nutzer auf Ihrer Instanz. Das Passwort wird erzeugt und in den Values nur referenziert, nie hineingeschrieben.
WordPress, Themes, Plugins und Uploads liegen auf einer 10-GiB-Festplatte mit täglichen Snapshots, sieben Tage aufbewahrt, wiederherstellbar per Klick.
Ein Kubernetes-Cron-Job ruft WP-Cron alle fünf Minuten auf. Geplante Beiträge und Plugin-Aufgaben laufen pünktlich, auch wenn niemand die Seite besucht.
Eine frische WordPress-Seite gehört dem, der den Installer zuerst aufruft. Bis Sie fertig sind, fragt die Seite deshalb nach einem Einrichtungs-Passwort.
Die Domain bekommt ein Let’s-Encrypt-Zertifikat. Liegt die Zone in Clusterward, wird der DNS-Record gleich mit angelegt.
Scheitert ein Schritt, sagt die Lauf-Seite warum. „Retry“ macht dort weiter, „Roll back…“ entfernt alles, was der Lauf angelegt hat.
Ressourcen, Domains, Netzwerk, Values: Alles ist auf den gewohnten Seiten änderbar. Eine neue Domain trägt Clusterward in den Host des Charts ein, die Vorlage selbst schreibt nichts mehr hinein.
Logs aller Instanzen, Auslastung über 30 Tage und Uptime-Checks funktionieren für die WordPress-Seite wie für jeden Service.
Jede weitere Seite bekommt ihre eigene Anwendung und Datenbank auf derselben MySQL-Instanz – gut für Agenturen mit vielen Kundenseiten.
Die Seite läuft mit dem offiziellen WordPress-Container, nicht mit einem eigenen Build. Neue Seiten laufen mit der getesteten Hauptversion 6; ein Upgrade stellen Sie am Service über den Image-Tag ein.
Das Chart liegt als „WordPress (catalog)“ in Ihren Templates. Eine neue Chart-Version wird die nächste Version, bestehende Seiten behalten ihre.
Die Datenbank liegt auf Ihrer MySQL-Instanz im privaten Netz, mit den Backups von Scaleway.
Die Festplatte ist Scaleway Block Storage, gesichert als Snapshots in Ihrem Projekt.
Zwei Dinge brauchen Sie vorher im Cluster, alles andere entsteht im Lauf.
| Baustein | Wer | Hinweis |
|---|---|---|
| Cluster mit NGINX-Ingress-Controller | Sie, einmal | Clusterseite → Ingress-Controller |
| MySQL-Instanz im selben Cluster | Sie, einmal | Clusterseite → Managed Datenbanken, etwa zehn Minuten |
| DNS-Zone | Optional | Registriert: Record automatisch, sonst von Hand |
| Anwendung und Umgebung production | Katalog | Eigene Namespace auf dem Cluster |
| Datenbank, Festplatte, Cron, Zertifikat | Katalog | Snapshots täglich, sieben Tage |
| WordPress-Admin-Konto | Sie | Im Installer, hinter dem Einrichtungs-Passwort |
Uptime Kuma prüft Ihre Websites und Dienste von außen und zeigt Verfügbarkeit und Ausfälle auf Status-Seiten. Aus dem App-Katalog genügen Name, Domain und Cluster, eine Datenbank braucht es nicht. Wie bei WordPress hält ein Einrichtungs-Passwort Fremde fern, bis Sie Ihr Konto angelegt haben; danach öffnet „Open to everyone“ die Seite.
Wie die Festplatte gesichert und wiederhergestellt wird, zeigt Volumes & Snapshots; die Datenbank-Instanz legen Sie unter Managed Datenbanken an.
Wer viele Kundenseiten betreibt, findet unter Agenturen & Studios Rollen pro Kunde; Logs und Uptime-Checks für jede Seite beschreibt Logs & Monitoring.
Persistente Daten mit Snapshot vor jedem Löschen.
Zu Volumes & SnapshotsViele Kundenprojekte in einem Cockpit, Rollen pro Kunde.
Zu Agenturen & StudiosLogs aller Instanzen, Auslastung und Uptime-Checks am Service.
Zu Logs & MonitoringIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir legen gemeinsam eine WordPress-Seite an, durchlaufen den Installer hinter dem Einrichtungs-Passwort und sichern die Festplatte per Snapshot.
