Déploiement
Comment Cockpit v2 est livré et exécuté — un déploiement unique et autonome, conteneurs, migrations, sondes de santé, haute disponibilité et observabilité.
Unité de déploiement unique
Cockpit v2 se déploie sous la forme d'un seul artefact autonome. Un unique processus de service sert l'API REST, l'écouteur KMIP et les tâches d'arrière-plan ensemble. Il est livré sous la forme d'une image de conteneur minimale et non-root ne contenant que l'application et ses données d'exécution.
API REST
La surface complète de l'API de gestion et cryptographique consommée par l'interface, le fournisseur PKCS#11 et les clients externes.
Écouteur KMIP
Le point de terminaison KMIP s'exécute dans le même processus que l'API REST — aucun service séparé à déployer ou faire évoluer.
Tâches d'arrière-plan
Le travail planifié et différé (livraison de l'outbox, tâches de maintenance) s'exécute au sein du même binaire.
Conteneurs
Une stack Docker Compose est fournie pour un usage local et de développement ; la production s'exécute sur Kubernetes.
| Environnement | Forme |
|---|---|
| Local / développement | Une stack Docker Compose : API + interface + entrée HTTPS + PostgreSQL + Redis. |
| Production | Kubernetes, exécutant la même image minimale et non-root. |
Migrations
Les changements de schéma sont appliqués automatiquement au démarrage. Cockpit v2 utilise un script d'initialisation consolidé et idempotent, accompagné de migrations incrémentales numérotées. Les migrations appliquées sont suivies dans la base de données, de sorte que chaque version est appliquée exactement une fois et que le démarrage peut être répété sans risque.
Les migrations s'exécutent au démarrage du service. Le script d'initialisation est idempotent, et les migrations incrémentales sont suivies dans la base de données — mettre en service un nouveau nœud ou faire avancer une nouvelle version ne nécessite aucune étape de migration séparée.
Haute disponibilité et résilience
Cockpit v2 est conçu pour s'exécuter sous forme de nœuds API sans état derrière un équilibreur de charge L7/TLS. Tout l'état d'authentification vit dans le JWT, de sorte que n'importe quel nœud peut servir n'importe quelle requête et que les nœuds peuvent être ajoutés ou retirés librement.
Nœuds API sans état
Tout l'état d'authentification est porté dans le JWT ; les nœuds se trouvent derrière un équilibreur de charge L7/TLS et s'étendent horizontalement.
Pooling de connexions
Le pooling de connexions à la base de données maintient l'accès à la base de données borné et efficace sous charge.
Disjoncteurs par coffre
Chaque backend coffre est protégé par son propre disjoncteur pour contenir et isoler les pannes.
Nouvelle tentative avec gigue
Les échecs transitoires sont retentés avec un backoff gigué pour éviter les vagues de nouvelles tentatives synchronisées.
Arrêt gracieux
Les requêtes en cours sont autorisées à se terminer proprement lorsqu'un nœud est arrêté ou remplacé.
Effets exactement-une-fois
Un outbox d'événements transactionnel associé à des clés d'idempotence maintient les effets de bord cohérents à travers les nouvelles tentatives.
Repli du cache
Les lectures se replient de Redis vers la base de données, de sorte qu'une panne du cache dégrade le service plutôt que de le faire échouer.
HA de la couche données
Un PostgreSQL primaire avec des répliques et un Redis en HA sont recommandés pour la production.
Pour la production, exécutez un PostgreSQL primaire avec des répliques et un déploiement Redis hautement disponible. La couche API reste sans état, de sorte que la résilience se concentre dans la couche de données et l'équilibreur de charge.
Sondes de santé
Cockpit v2 expose deux points de terminaison pour que Kubernetes puisse piloter la vivacité et la disponibilité :
| Sonde | Point de terminaison | Objectif |
|---|---|---|
| Vivacité | /health/live | Signale que le processus est vivant ; un échec déclenche un redémarrage. |
| Disponibilité | /health/ready | Signale que le nœud est prêt à recevoir du trafic ; un échec le retire de l'équilibreur de charge. |
Observabilité
Cockpit v2 émet des journaux JSON structurés, portant le contexte de requête, de tenant et d'utilisateur à chaque entrée. Les métriques et les alertes s'intègrent aux outils opérationnels standard.
Journaux structurés
Journaux JSON structurés, enrichis du contexte requête / tenant / utilisateur.
Métriques
Un point de terminaison de métriques Prometheus pour le scraping des métriques d'exécution et de requêtes.
Transfert SIEM
Transfert des journaux vers Splunk, Azure Sentinel ou Elastic.
Alertes
Alertes par webhook et par email pour les événements opérationnels et de sécurité.
Configuration
Cockpit v2 est configuré entièrement via des variables d'environnement. Cela garde la configuration explicite, native aux conteneurs et facile à gérer via les secrets et config maps Kubernetes.
# Cockpit v2 reads all configuration from the environment.
DATABASE_URL=postgres://...
REDIS_URL=redis://...
# See the full reference for the complete set of variables.Pour la référence complète des variables d'environnement et un exemple de fichier .env de production, consultez la référence de configuration Cockpit v2.
Tout chiffre de débit, de latence ou d'empreinte cité pour Cockpit v2 constitue des cibles indicatives, et non des garanties mesurées. Validez-les dans votre propre environnement avant de vous en servir pour un dimensionnement de capacité.