SyncDeploy
Ein lokales Cockpit für Betrieb und Deployment. Es bringt Builds von der Entwicklung über den Test bis in die Produktion, holt per Klick die Marktdaten aus Tokio auf den eigenen Rechner und zeigt den Zustand aller Server auf einer Seite.
Was es ist
SyncDeploy ist eine Web-App, die nur auf dem eigenen Rechner läuft. Sie ersetzt verstreute Shell- und PowerShell-Skripte durch eine Oberfläche mit einer Spalte je Umgebung: Entwicklung, Test, der lokale Rechner, der Server bei netcup und der Server in Tokio.
Wie es funktioniert
Deployment
Die CI baut bei jedem Push ein Image und legt es in der Registry ab. Das Cockpit zeigt je Umgebung, welcher Build läuft und ob er hinter dem neuesten liegt. Einen Build lädt man per Klick in die Entwicklungs- oder die Testumgebung. Für die Produktion gibt es vor dem echten Lauf einen Probelauf.
Auch diese Website kommt darüber auf den Server: bauen, per SHA-256 mit dem Server abgleichen, per SFTP hochladen, prüfen.
Crawler-Deploy in Tokio
Heikel ist das Update des Crawlers von Astraea. Er hört live am WebSocket der Börse. Was er während eines Neustarts verpasst, kann er später nicht nachholen. Deshalb läuft das Update in sieben Schritten, jeder mit eigenem Ergebnis:
- Das neue Image aus der Registry ziehen.
- Einen Canary starten, also eine zweite Instanz, die in eine eigene, getrennte Datenbank schreibt.
- Den Canary nach der Aufwärmzeit prüfen.
- Den Live-Crawler tauschen. Dabei migriert Flyway die Produktionsdatenbank.
- Den neuen Live-Crawler prüfen.
- Die Lücke aus der Umschaltzeit mit den Daten des Canary füllen.
- Den Canary beenden.
Schritt 6 muss vor Schritt 7 kommen. Der Canary ist die einzige Quelle für die Daten aus der Zeit der Umschaltung. Das Fenster der Lücke wird gemessen, nicht geschätzt: ein früherer Ablauf mit einem geschätzten Puffer ließ 27 Sekunden Daten offen und meldete trotzdem Erfolg. Beim ersten Lauf nach dem neuen Verfahren war der Crawler eine Sekunde lang aus, und es ging kein Datenpunkt verloren.
Datensync aus Tokio
Der Crawler von Astraea schreibt auf einen kleinen Server in Tokio mit begrenztem Speicher. Ein Klick holt die Daten automatisch auf den lokalen Rechner. SyncDeploy arbeitet dann alle offenen Tage ab, den ältesten zuerst: Export im Binärformat von PostgreSQL mit zstd-Kompression, Übertragung, Import, Prüfung, danach Aufräumen auf dem Server. Jeder Tag durchläuft dabei eine Zustandsmaschine. Scheitert ein Schritt, hält die Kette an, statt den nächsten Tag anzufangen.
Überblick
Die Seite zeigt die Container auf allen Servern, die Erreichbarkeit der Dienste und die Logs laufender Vorgänge live. Zustände haben in jeder Spalte dieselben Farben: grün für läuft, gelb für arbeitet, orange für Warnung, rot für Fehler. Fehlt einer Kachel eine Voraussetzung, nennt sie den Grund, statt leer zu bleiben.
Die Kachel „GPU / LLM“ zeigt, welche Modelle gerade in der Grafikkarte liegen und wie viel Speicher noch frei ist. Je Modell teilt ein Balken den Speicher in Gewichte, Start und laufenden Betrieb. Den Namen nennt der Dienst selbst, wenn er das kann. Sonst kommt er aus einer Liste und ist als deklariert markiert. Die Treiberreserve steht extra, und die Kachel rechnet die Summe gegen den Wert nach, den die Karte meldet.
Die Kachel „Bee-Arbeit“ zeigt meine KI-Agenten, die über Apiary Aufträge bekommen. Man sieht, welche Biene gerade arbeitet und ob ein Bericht auf Abnahme wartet.
Technik
Java mit Quarkus, die Oberfläche in TypeScript, Live-Daten über Server-Sent Events. Datenbankzugriffe auf den Server in Tokio laufen über einen SSH-Tunnel. Die Suite umfasst über 1.100 Java-Tests und über 270 Frontend-Tests.
Stand
SyncDeploy ist täglich im Einsatz. Die Instanz läuft als eigener Dienst und holt sich bei jedem Start den neuesten grünen Build aus der Registry.