Deployment
Wie Cockpit v2 ausgeliefert und betrieben wird — ein einziges, in sich geschlossenes Deployment, Container, Migrationen, Health-Probes, Hochverfügbarkeit und Observability.
Eine einzige bereitstellbare Einheit
Cockpit v2 wird als ein in sich geschlossenes Artefakt bereitgestellt. Ein einzelner Dienstprozess bedient die REST-API, den KMIP-Listener und die Hintergrundjobs gemeinsam. Es wird als minimales, non-root Container-Image ausgeliefert, das nur die Anwendung und ihre Laufzeitdaten enthält.
REST-API
Die vollständige Management- und kryptografische API-Fläche, die von der Benutzeroberfläche, dem PKCS#11-Provider und externen Clients genutzt wird.
KMIP-Listener
Der KMIP-Endpunkt läuft im selben Prozess neben der REST-API — kein separater Dienst zum Bereitstellen oder Skalieren.
Hintergrundjobs
Geplante und aufgeschobene Arbeiten (Outbox-Zustellung, Wartungsaufgaben) laufen innerhalb derselben Binärdatei.
Container
Für lokale und Entwicklungszwecke wird ein Docker-Compose-Stack bereitgestellt; die Produktion läuft auf Kubernetes.
| Umgebung | Form |
|---|---|
| Lokal / Entwicklung | Ein Docker-Compose-Stack: API + UI + HTTPS-Ingress + PostgreSQL + Redis. |
| Produktion | Kubernetes, mit demselben minimalen, non-root Image. |
Migrationen
Schemaänderungen werden beim Start automatisch angewendet. Cockpit v2 verwendet ein konsolidiertes, idempotentes Init-Skript zusammen mit nummerierten inkrementellen Migrationen. Angewendete Migrationen werden in der Datenbank nachverfolgt, sodass jede Version genau einmal angewendet wird und der Start gefahrlos wiederholt werden kann.
Migrationen laufen, wenn der Dienst startet. Das Init-Skript ist idempotent, und die inkrementellen Migrationen werden in der Datenbank nachverfolgt — das Hochfahren eines neuen Knotens oder das Vorwärtsrollen einer neuen Version erfordert keinen separaten Migrationsschritt.
Hochverfügbarkeit und Resilienz
Cockpit v2 ist darauf ausgelegt, als zustandslose API-Knoten hinter einem L7/TLS-Load-Balancer zu laufen. Der gesamte Authentifizierungszustand liegt im JWT, sodass jeder Knoten jede Anfrage bedienen kann und Knoten beliebig hinzugefügt oder entfernt werden können.
Zustandslose API-Knoten
Der gesamte Auth-Zustand wird im JWT transportiert; Knoten sitzen hinter einem L7/TLS-Load-Balancer und skalieren horizontal.
Connection-Pooling
Datenbank-Connection-Pooling hält den Datenbankzugriff unter Last begrenzt und effizient.
Circuit-Breaker pro Vault
Jedes Vault-Backend wird durch einen eigenen Circuit-Breaker geschützt, um Fehler einzudämmen und zu isolieren.
Retry mit Jitter
Vorübergehende Fehler werden mit Jitter-Backoff wiederholt, um synchronisierte Retry-Stürme zu vermeiden.
Graceful Shutdown
Laufende Anfragen dürfen sauber auslaufen, wenn ein Knoten gestoppt oder ausgetauscht wird.
Exactly-once-Effekte
Eine transaktionale Event-Outbox plus Idempotenzschlüssel halten Nebeneffekte über Wiederholungen hinweg konsistent.
Cache-Fallback
Lesevorgänge fallen von Redis auf die Datenbank zurück, sodass ein Cache-Ausfall zu einer Verschlechterung statt zu einem Ausfall führt.
HA der Datenschicht
Für die Produktion werden ein PostgreSQL-Primary mit Replikaten und eine hochverfügbare Redis-Bereitstellung empfohlen.
Betreiben Sie für die Produktion einen PostgreSQL-Primary mit Replikaten und eine hochverfügbare Redis-Bereitstellung. Die API-Schicht bleibt zustandslos, sodass sich die Resilienz auf die Datenschicht und den Load-Balancer konzentriert.
Health-Probes
Cockpit v2 stellt zwei Endpunkte bereit, über die Kubernetes Liveness und Readiness steuert:
| Probe | Endpunkt | Zweck |
|---|---|---|
| Liveness | /health/live | Signalisiert, dass der Prozess läuft; ein Fehlschlag löst einen Neustart aus. |
| Readiness | /health/ready | Signalisiert, dass der Knoten bereit ist, Traffic zu empfangen; ein Fehlschlag entfernt ihn aus dem Load-Balancer. |
Observability
Cockpit v2 gibt strukturierte JSON-Logs aus, die bei jedem Eintrag Anfrage-, Mandanten- und Benutzerkontext enthalten. Metriken und Alerting lassen sich in gängige Betriebswerkzeuge integrieren.
Strukturierte Logs
Strukturierte JSON-Logs, angereichert mit Anfrage-/Mandanten-/Benutzerkontext.
Metriken
Ein Prometheus-Metrik-Endpunkt zum Abgreifen von Laufzeit- und Anfragemetriken.
SIEM-Weiterleitung
Log-Weiterleitung an Splunk, Azure Sentinel oder Elastic.
Alerting
Webhook- und E-Mail-Alerting für Betriebs- und Sicherheitsereignisse.
Konfiguration
Cockpit v2 wird vollständig über Umgebungsvariablen konfiguriert. Das hält die Konfiguration explizit, container-nativ und über Kubernetes-Secrets und -ConfigMaps leicht verwaltbar.
# Cockpit v2 reads all configuration from the environment.
DATABASE_URL=postgres://...
REDIS_URL=redis://...
# See the full reference for the complete set of variables.Die vollständige Umgebungsvariablen-Referenz und ein Produktions-.env-Beispiel finden Sie in der Cockpit-v2-Konfigurationsreferenz.
Alle für Cockpit v2 genannten Durchsatz-, Latenz- oder Footprint-Werte sind richtungsweisende Zielwerte, keine gemessenen Garantien. Validieren Sie diese in Ihrer eigenen Umgebung, bevor Sie sich für die Kapazitätsplanung darauf verlassen.