Senticor · Pilotbetrieb
openDesk: Multicloud-Betrieb und Absicherung von Änderungen
Ein Senticor-Pilot für openDesk, eine Open-Source-Suite für Büroarbeit und Zusammenarbeit. Die Umsetzung verbindet neu aufbaubare Anwendungen mit aufbewahrten Daten, unabhängigem Maileingang und Schutzmechanismen für Upgrades und Abschaltungen.
Ausgangslage: Softwareauswahl schafft Betriebsaufgaben
Ein Open-Source-Arbeitsplatz besteht aus mehreren Diensten mit gemeinsamen Abhängigkeiten von Identitätsverwaltung, Speicher und E-Mail. Auf die Produktauswahl folgt eine zweite Entscheidung: Wer verantwortet den Lebenszyklus, und wie bleiben bestehende Daten und Kommunikation bei Änderungen erhalten?
- Microsoft 365 und Google Workspace verbinden Büro- und Kommunikationsprodukte als Cloud-Dienste.
- Nextcloud Hub bündelt Dateien, gemeinsame Dokumentbearbeitung und Kommunikation, auch im Eigenbetrieb.
- openDesk integriert Open-Source-Anwendungen für den Arbeitsplatz. Community lässt sich selbst betreiben; öffentliche Verwaltungen erhalten auch Enterprise-Support und verschiedene Betriebsmodelle.
Der Senticor-Pilot sah geplante Anwendungspausen vor. Damit wurde die Abstimmung der Lebenszyklen zur konkreten Entwicklungsaufgabe: Anwendungskapazität ließ sich neu aufbauen; gespeicherte Dokumente, Identitäten und E-Mails durften dabei nicht wie austauschbare Infrastruktur behandelt werden.
Aufgabe und mein Beitrag
Meine Arbeit umfasste Lebenszyklus-Automation, Upgrade-Absicherung, Mailintegration und Störungsanalyse. Das Betriebsmodell trennte pausierbare Funktionen von solchen, die weiterlaufen mussten. Abbau und Löschung wurden an überprüfbare Bedingungen zum Schutz aufbewahrter Daten gebunden.
Dazu gehörten Infrastrukturkonfiguration, Anpassungen der Installation, Betriebsskripte, Prüfungen und Betriebsanleitungen. Der bewusst akzeptierte Kompromiss war eine begrenzte Anwendungsverfügbarkeit im Pilotbetrieb. Der Erhalt der Daten hatte Vorrang vor unterbrechungsfreiem Zugriff.
Maßnahmen: Änderungen über Dienstgrenzen hinweg steuern
Anwendungslaufzeit und dauerhaften Zustand trennen
openDesk-Anwendungen und Postfächer laufen auf Google Kubernetes Engine. Terraform beschreibt die GCP-Infrastruktur; Helmfile-Anpassungen und Skripte steuern Installation und Lebenszyklus. Aufbewahrte Anwendungsdisks und unabhängig geplante Snapshots überdauern Anwendungspausen. Ein mit Ansible verwalteter STACKIT-Host übernimmt Maileingang sowie Start und Stopp. Dieser dauerhaft benötigte Host liegt bewusst außerhalb des Terraform-Lebenszyklus.
Upgrades als Änderung bestehender Datenbeziehungen behandeln
Das Upgrade erfolgte über eine Zwischenversion. Vergleiche der erzeugten Deployment-Konfiguration prüften Speicherzuordnungen, Vorlagen für zustandsbehaftete Dienste und Mail-Schnittstellen. Ein geänderter Upstream-Standard hätte beim Kaltstart einen anderen Objektspeicher ausgewählt. Das ausdrückliche Beibehalten von MinIO hielt die Installation mit ihrem bestehenden Speicher verbunden, statt einen neuen leeren aufzubauen.
Mailkontinuität und Abschaltung getrennt entscheiden
Ein unabhängiger MX-Mailserver nimmt eingehende Nachrichten während der Anwendungspause an und hält sie zur Weiterleitung bereit. Das erhält die Annahme, nicht den Postfachzugriff. Vor dem Abschalten müssen die SMTP-Warteschlangen der Anwendungen geleert, schreibende Prozesse gestoppt und die tatsächlichen Warteschlangen als leer bestätigt sein. Fehlerhafte oder uneindeutige Prüfungen verhindern den Abbau; ein erfolgreich beendeter Befehl allein gilt nicht als Freigabe.
Nutzerzugriff über Abhängigkeiten hinweg untersuchen
Nach einem Neustart blieb eine gesunde Webmail-Anwendung hinter der öffentlichen Bereitschaftssperre verborgen. Korrekturen an Auswahlregeln und Zustandsübergängen stellten den Zugriff wieder her. Eine weitere Untersuchung führte Portal- und Mailstörungen auf Überlastung des gemeinsamen Identitätsdienstes zurück. Daraus entstanden Prüfungen von Anmeldung und Zustellung über den gesamten Weg, zusätzlich zur Komponentenüberwachung.
Ergebnisse: umgesetzte Kontrollen und belegtes Verhalten
Umgesetzt
Der Pilot besitzt einen dokumentierten Lebenszyklus über zwei Anbieter, abgesicherte Upgrade-Schritte, unabhängig geplante Disk-Snapshots und eine Mailprüfung vor dem Abbau der Laufzeit. Ein Beinahefehler bei der Bereinigung aufbewahrter Disks führte außerdem zu Bestandsprüfungen, die unklare Löschungen verweigern, und zu Regressionstests.
In den Betriebsunterlagen belegt
Dokumentiert sind ein durchgeführtes Upgrade, wiederhergestellter öffentlicher Zugriff samt Anmeldung nach der Korrektur der Sperre, ein vollständiger bereiter Snapshot-Satz sowie erfolgreiche Vorbereitung, Offline-Prüfung und Wiederaufnahme der Maildienste. Das sind einzelne nachgewiesene Vorgänge, keine pauschale Bestätigung aller Wiederherstellungsszenarien.
Betriebsgrenze
Es bleibt ein Pilot mit akzeptierten Unterbrechungen. Der einzelne MX-Server hat begrenzte Aufbewahrung und ist weder redundant noch durch die GCP-Disk-Snapshots gesichert. Diese sind Kopien einzelner Disks und belegen keine anwendungskonsistente Wiederherstellung. Ein vollständiger isolierter Wiederherstellungstest steht aus. GCP und Cloudflare bleiben Abhängigkeiten; vollständige Souveränität, Einsparungen oder höhere Verfügbarkeit werden nicht behauptet.
Erkenntnisse für Plattformentscheidungen
- Lebenszyklen vor dem automatisierten Löschen festlegen: Laufzeit, dauerhafte Daten, Mailwarteschlangen und Wiederherstellungsvoraussetzungen haben unterschiedliche Lebensdauern. Automation braucht ein eindeutiges Inventar und Bedingungen, unter denen sie stoppen muss.
- Schnittstellen bei Upgrades prüfen: Ein erfolgreiches Deployment reicht bei geänderten Speicherstandards oder Dienstschnittstellen nicht aus. Bestehende Daten müssen nach dem laufenden Upgrade ebenso erreichbar bleiben wie nach einem Neuaufbau.
- Dienstziele unterscheiden: Angenommene, weitergeleitete und lesbare E-Mails sind verschiedene Zustände. Eine einzelne Verfügbarkeitsanzeige verdeckt ihre Abhängigkeiten und Fehlerfälle.
- Wiederherstellung als Vorgang nachweisen: Vorhandene Snapshots, erfüllte Voraussetzungen und erfolgreich wiederhergestellte Anwendungen sind unterschiedliche Nachweise. Vor produktiver Nutzung braucht es den fehlenden Wiederherstellungstest und ausdrückliche Dienstziele.
Projekt und Hintergrund
Der Fall beschreibt eigene Betriebsaufzeichnungen des Senticor-Piloten. Die verlinkten Marktangebote dienen der Einordnung; es wurde kein vergleichender Produkttest durchgeführt.
Architektur: Betrieb, Daten und Abschaltbedingungen
Die Topologie trennt Mailannahme, Anwendungsbetrieb und dauerhafte Daten. Eine eigene Steuerungsebene macht sichtbar, welche Prüfungen vor dem Entfernen der Laufzeit erforderlich sind.
Textbeschreibung des Diagramms
- STACKIT betreibt den separaten Mailannahmedienst und die Laufzeitsteuerung. Die Mailwarteschlange kann Nachrichten während Anwendungspausen zurückhalten, solange dieser einzelne Dienst verfügbar ist.
- Google Kubernetes Engine führt die openDesk-Anwendungen und Postfächer aus. Identitätsdienste sind eine gemeinsame Abhängigkeit; Daten auf persistenten Datenträgern bleiben über die Laufzeit hinaus erhalten.
- Die Infrastruktur- und Deployment-Konfiguration hält Änderungen nachvollziehbar. Der beibehaltene STACKIT-Host hat einen getrennten Lebenszyklus. Unabhängige Snapshots sichern Datenträger, nicht automatisch den vollständigen Anwendungszustand.
- Vor dem Abschalten müssen die SMTP-Warteschlangen der Anwendung geleert, die zugehörigen SMTP-Schreibprozesse gestoppt und die tatsächlichen Warteschlangen offline geprüft werden.
- Nur ein bestätigter sicherer Zustand erlaubt das Entfernen der Laufzeit. Bei Fehlern oder Ungewissheit bleibt sie bestehen. Erreichbarkeit und Anmeldung sind zusätzlich zum Zustand einzelner Komponenten zu prüfen.