Installation
Ce guide vous accompagne dans une installation HA de production. Il suppose que vous avez complété les Prérequis.
Les installations sur site sont réalisées conjointement avec l'ingénierie DuoKey. Les commandes ci-dessous illustrent le flux de référence ; votre package de livraison inclut les manifestes et les valeurs Helm exacts pour votre environnement.
Installation en un coup d'œil
Phase 1 — Préparer le cluster
Créez les espaces de noms (projets) et appliquez la sécurité de base :
# Application + platform namespaces
oc new-project duokey
oc new-project duokey-observability
# Label for pod anti-affinity / zone spreading is applied via the
# application manifests in later phases.
Confirmez que le stockage et l'entrée (ingress) sont prêts :
oc get storageclass
oc get ingresscontroller -n openshift-ingress-operator
Phase 2 — Déployer OpenBao (niveau de VM externe)
Sur les VM OpenBao dédiées, initialisez un cluster HA avec le stockage intégré Raft, puis descellez et activez la méthode d'authentification Kubernetes :
# On each OpenBao node (illustrative)
bao operator init # capture unseal keys + root token securely
bao operator unseal # repeat on each node to form the Raft quorum
# Enable Kubernetes auth so OpenShift pods can authenticate
bao auth enable kubernetes
bao write auth/kubernetes/config \
kubernetes_host="https://<openshift-api>:6443"
Stockez les clés de descellement et le jeton racine (root token) dans un emplacement hors ligne sécurisé (ou utilisez le descellement automatique adossé à votre HSM). La perte de ceux-ci empêche la récupération du moteur de secrets.
Phase 3 — Câbler les secrets (External Secrets Operator)
Installez ESO depuis OperatorHub, puis connectez-le à OpenBao avec un SecretStore
et un rôle basé sur ServiceAccount :
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: openbao
namespace: duokey
spec:
provider:
vault:
server: "https://openbao.duokey.example.local:8200"
path: "secret"
version: "v2"
auth:
kubernetes:
mountPath: "kubernetes"
role: "duokey"
serviceAccountRef:
name: "duokey"
Les secrets sont ensuite matérialisés à la demande dans des Secrets Kubernetes
adossés à tmpfs via des ressources ExternalSecret (livrées avec les manifestes
d'application).
Phase 4 — Déployer le niveau de données
Provisionnez PostgreSQL (HA) et Redis. En utilisant un opérateur PostgreSQL dans le cluster :
oc apply -f postgres-cluster.yaml # CloudNativePG / Patroni Cluster CR
oc apply -f redis-cluster.yaml # sharded Redis StatefulSet
Ou pointez l'application vers le cluster de VM PostgreSQL externe via la chaîne de connexion stockée dans OpenBao (recommandé pour l'architecture de référence).
Phase 5 — Amorcer GitOps (ArgoCD)
Installez OpenShift GitOps, puis enregistrez le dépôt d'application DuoKey afin qu'ArgoCD réconcilie tous les changements ultérieurs :
oc apply -f argocd-application-duokey.yaml
argocd app sync duokey # initial sync
À partir de ce point, tous les changements passent par Git — ArgoCD détecte la dérive et maintient le cluster aligné sur l'état déclaré.
Phase 6 — Déployer l'application DuoKey
Les manifestes d'application déploient le frontend Cockpit et le backend de l'API Rust avec l'anti-affinité de pods et la route d'entrée :
# Typically reconciled by ArgoCD; shown here for clarity
oc apply -k manifests/duokey/overlays/on-prem
oc get pods -n duokey -o wide # confirm spread across nodes/zones
Phase 7 — Déployer l'observabilité
oc apply -f victoria-metrics-stack.yaml -n duokey-observability
oc apply -f victoria-logs.yaml -n duokey-observability
oc apply -f grafana.yaml -n duokey-observability
Importez les tableaux de bord Grafana de DuoKey (inclus dans votre package de livraison).
Phase 8 — Vérifier et première connexion
Parcourez la liste de contrôle de vérification :
# All pods Running and Ready
oc get pods -n duokey
# Ingress route resolves and serves TLS
oc get route -n duokey
curl -I https://cockpit.duokey.example.local
# Secrets are being injected (no plaintext on disk)
oc get externalsecret -n duokey
Liste de contrôle d'intégrité
- Tous les pods applicatifs sont
Runninget répartis sur ≥ 3 nœuds/zones - OpenBao est descellé et accessible depuis le cluster
- Le primaire PostgreSQL + les répliques sont sains et en réplication
- ArgoCD affiche l'application comme
Synced/Healthy - Les tableaux de bord Grafana reçoivent des métriques et des journaux
- L'UI Cockpit se charge en HTTPS et vous pouvez vous authentifier
Lorsque toutes les vérifications réussissent, remettez l'environnement à votre équipe des opérations et continuez vers Surveillance et Sauvegarde et reprise après sinistre.
Conservez vos clés de descellement OpenBao initiales, les identifiants administrateur ArgoCD et le premier compte administrateur dans le coffre d'accès à privilèges de votre organisation.