Mise à niveau Embedded cluster
Ne procédez pas à un rollback ou un downgrade sans consulter d'abord notre équipe de support. Certains scénarios peuvent nécessiter de restaurer la base de données depuis une sauvegarde pré-mise à niveau en raison de la complexité de l'inversion de certaines migrations de base de données.
Les preflight checks sont essentielles pour une installation réussie. Les règles suivantes s'appliquent :
- ❌ Échecs des preflight checks : si les preflight checks échouent, la mise à niveau ne doit pas continuer tant que l'environnement cible ne répond pas à toutes les exigences. Veuillez contacter notre équipe de support.
- ⚠️ Avertissements des preflight checks : si les preflight checks renvoient des avertissements, l'installation peut continuer, mais il est recommandé de traiter ces avertissements pour respecter nos recommandations.
Mise à niveau vers 2026.3
Si vous utilisez un déploiement Embedded cluster V2 (instances installées en 2025 ou après), vous devez supprimer manuellement le PodDisruptionBudget replicated avant de passer à 2026.3 :
- Vérifiez votre version actuelle. Ce problème n'affecte que les instances exécutant 2026.2.0. Si vous êtes sur une version plus ancienne, vous pouvez passer directement à 2026.3.0 sans étape manuelle.
- Connectez-vous au nœud via SSH et supprimez le PodDisruptionBudget :
kubectl delete -n kotsadm pdb replicated
- Ouvrez la console d'administration KOTS et lancez la mise à niveau vers 2026.3.0 depuis l'onglet « Version History ».
Mise à niveau vers 2026.1
Si vous utilisez un déploiement embedded cluster, cette release introduit de nouveaux subcharts pour PostgreSQL et Valkey (anciennement Redis) :
- Mise à niveau Valkey (anciennement Redis) : la migration de Redis vers Valkey est transparente et ne nécessite aucune action de votre part. Notez que le cache applicatif sera réinitialisé, sans affecter le fonctionnement normal de l'application.
- Mise à niveau PostgreSQL : cette opération nécessite une action manuelle obligatoire avant d'initier la mise à niveau.
En raison de la façon dont Kubernetes gère les objets StatefulSet, le StatefulSet PostgreSQL ne peut pas être mis à niveau automatiquement. Suivez ces étapes pour effectuer la migration en toute sécurité.
Étape 1 : Sauvegardez la base de données
Avant de procéder à la mise à niveau, vous devez sauvegarder votre base de données PostgreSQL via l'outil de migration fourni dans le dépôt postgresql-bitnami-migration.
-
Téléchargez le script de sauvegarde depuis le dépôt.
-
Lancez le script de sauvegarde pour créer un dump de la base :
./backup.sh --namespace gitguardian --output dump.sql.gz
- Stockez le fichier de sauvegarde (
dump.sql.gz) dans un emplacement sûr.
Étape 2 : Supprimez le StatefulSet PostgreSQL
Vérifiez que le StatefulSet PostgreSQL est présent dans votre namespace :
kubectl get sts -n gitguardian
Supprimez le StatefulSet avant de démarrer la mise à niveau :
kubectl delete sts postgresql -n gitguardian
Étape 3 : Lancez les preflight checks et procédez à la mise à niveau
Une preflight check pendant la mise à niveau vérifiera automatiquement que la suppression du StatefulSet a bien été effectuée. Si la preflight check passe, procédez à la mise à niveau via la console d'administration KOTS.
Étape 4 : Restaurez la base de données
Une fois la mise à niveau terminée et tous les pods en cours d'exécution, restaurez la base de données via le script de restauration :
./restore.sh --namespace gitguardian --input dump.sql.gz
Vérifiez que vos paramètres et données ont été préservés en consultant le tableau de bord GitGuardian.
Pour des instructions détaillées sur les scripts de sauvegarde et restauration, consultez le dépôt postgresql-bitnami-migration.
Mise à niveau de l'application GitGuardian
Avant de procéder à la mise à niveau, assurez-vous de sauvegarder votre base de données PostgreSQL. Pour des instructions détaillées, consultez la page Backup.
L'application GitGuardian peut être mise à jour via la console d'administration KOTS dans l'onglet « Version History ». Vous devez d'abord vérifier les mises à jour. Cela peut être fait manuellement ou automatiquement. Vous pouvez ensuite déployer une nouvelle version en cliquant sur le bouton « Deploy ».
Sur les Embedded clusters V2, mettre à jour l'application via la console d'administration KOTS met également à niveau le cluster Kubernetes si nécessaire.
Vous trouverez plus d'informations dans la documentation KOTS.
Pendant les mises à niveau, les workers sont arrêtés mais les nouveaux commits sont toujours mis en file et seront traités après la mise à niveau. Les mises à niveau n'arrêtent pas le tableau de bord, mais elles introduisent un délai temporaire dans le traitement des messages et l'envoi des alertes. Nous conseillons de réaliser les mises à niveau pendant une période de faible trafic.
Mise à niveau de l'application GitGuardian en air gap
Pour mettre à niveau l'interface d'administration KOTS, suivez les instructions d'installation : installez la dernière version du plugin KOTS sur votre machine, téléchargez le dernier bundle KOTS et uploadez ces images vers votre registre. Puis, au lieu de lancer la commande d'installation, vous devrez mettre à niveau l'application KOTS en cours d'exécution dans le cluster :
kubectl kots admin-console upgrade --namespace <namespace>
Si nécessaire, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé s'il n'est pas spécifié).
Pour mettre à niveau l'application GitGuardian, téléchargez d'abord le dernier bundle applicatif sur le portail de téléchargement. Puis allez dans votre console d'administration KOTS sur « Version History », et cliquez sur « Upload new version ». Uploadez le bundle et déployez-le.
Versions requises
La console d'administration KOTS affichera certaines versions comme « Required ».
Si vous avez plusieurs versions à mettre à niveau, vous devrez passer par chaque version requise entre votre version actuelle et votre version cible.
Après chaque déploiement, vous devriez attendre que l'application soit pleinement mise à niveau. Pour cela, vous pouvez monitorer le statut des pods et attendre que tous les pods soient vivants et que tous les jobs soient terminés.
watch kubectl get po -n <namespace>
L'application est redémarrée lorsque tous les pods sont en statut running :
Every 2.0s: kubectl get po -n default gitguardian-example: Thu Jul 4 06:11:24 2024
NAME READY STATUS RESTARTS AGE
beat-677d68bb9f-8f5lp 1/1 Running 0 23m
kotsadm-56dd9b7866-cv4jc 1/1 Running 0 30m
kotsadm-rqlite-0 1/1 Running 0 33m
kurl-proxy-kotsadm-7cdfc47bf4-nr55l 1/1 Running 0 33m
nginx-578786cd47-6ccfh 1/1 Running 0 23m
nginx-578786cd47-cx899 1/1 Running 0 23m
post-deploy-f77kq 0/1 Completed 0 23m
postgresql-0 1/1 Running 0 29m
pre-deploy-hnpbq 0/1 Completed 0 28m
redis-master-0 1/1 Running 0 29m
replicated-76bff7f9bb-zb2lb 1/1 Running 0 23m
webapp-hook-5745c9995-6p7ph 1/1 Running 0 23m
webapp-internal-api-55fdd98d4d-9x25r 1/1 Running 1 (22m ago) 23m
webapp-internal-api-long-b98b68fb-x6q7s 1/1 Running 0 23m
webapp-public-api-7d4b7f8956-2jvf4 1/1 Running 0 23m
worker-email-755dd6db6b-4drhj 1/1 Running 0 23m
worker-email-755dd6db6b-6lrhc 1/1 Running 0 23m
worker-long-tasks-54875654d8-jl57k 1/1 Running 0 23m
worker-long-tasks-54875654d8-mh47g 1/1 Running 0 23m
worker-realtime-ods-7b844db9c6-6rcsl 1/1 Running 0 23m
worker-realtime-ods-7b844db9c6-hb8lq 1/1 Running 0 23m
worker-scanners-55fc98d756-mrqsx 1/1 Running 0 23m
worker-scanners-55fc98d756-rz6xz 1/1 Running 0 23m
worker-worker-85bff7dc8f-6zs98 1/1 Running 0 23m
worker-worker-85bff7dc8f-vd5vx 1/1 Running 0 23m
Nous avons défini un TTL (Time To Live) de 30 jours pour les jobs pre-deploy et post-deploy afin de permettre la récupération des logs si nécessaire. Il est recommandé de ne pas supprimer ces pods, car ils peuvent être utiles pour le troubleshooting.
Mise à niveau de KOTS
Pensez aux mises à niveau régulières de KOTS qui sont nécessaires. Les releases GitGuardian sont rigoureusement testées avec la dernière release KOTS. Pour garantir le bon fonctionnement et la compatibilité, certaines fonctionnalités peuvent ne pas se comporter comme prévu sur des versions plus anciennes de KOTS. Nous recommandons fortement de rester à jour avec les releases les plus récentes.
Pour vérifier la version du plugin KOTS, lancez la commande suivante :
kubectl kots version
S'il y a une mise à jour disponible, suivez les instructions et lancez cette commande :
curl https://kots.io/install | bash
Pour un cluster existant, vous devrez mettre à niveau l'application KOTS en cours d'exécution dans le cluster :
L'installation KOTS sur cluster existant sera dépréciée et non supportée après la release de juin 2026 (version 2026.6.0). Veuillez migrer vers une installation Helm.
kubectl kots admin-console upgrade -n <namespace>
Pour les installations Embedded cluster (instances installées en 2025 ou après), KOTS est mis à niveau automatiquement avec l'application GitGuardian.
Pour les installations legacy Embedded cluster (kURL) (instances installées en 2024 ou avant), relancez simplement la même commande d'installation que celle décrite dans le guide d'installation.
⚠️ Pendant la mise à niveau, vous serez invité (potentiellement plus d'une fois) avec une question Y/N pour drainer le nœud et appliquer la mise à niveau. Vous devez répondre Y pour continuer. Comme cette étape supprime tous les pods sur le nœud, il y aura un bref temps d'arrêt pendant la mise à niveau et vous devez prévoir en conséquence.
🌐 Si vous utilisez un proxy HTTP, assurez-vous de suivre les instructions.
Pour des instructions supplémentaires sur la mise à niveau de KOTS, consultez la documentation Replicated.
Dans certains cas, les preflight checks peuvent ne pas détecter correctement le changement de version d'admin KOTS, entraînant des échecs même en utilisant la version minimale requise de KOTS. Pour résoudre ce problème, suivez ces étapes :
- Naviguez vers la console d'administration KOTS.
- Allez dans Config > Advanced Options.
- Ajustez le nombre de réplicas du worker email (par exemple, de 2 à 1).
- Déployez votre changement de configuration.
- Cliquez sur le lien Check for update.
- Lancez à nouveau les preflight checks.
- Une fois les preflight checks terminées, annulez le changement en restaurant le nombre de réplicas du worker email à sa valeur d'origine.
Mise à niveau de Kubernetes sur Embedded Cluster legacy (kURL) (instances installées en 2024 ou avant)
Pour mettre à niveau votre version Kubernetes pour le cluster embedded, suivez ces étapes :
- Relancez simplement la même commande d'installation que celle décrite dans le guide d'installation.
⚠️ Pendant la mise à niveau, vous serez invité (potentiellement plus d'une fois) avec une question Y/N pour drainer le nœud et appliquer la mise à niveau. Vous devez répondre Y pour continuer. Comme cette étape supprime tous les pods sur le nœud, il y aura un bref temps d'arrêt pendant la mise à niveau et vous devez prévoir en conséquence.
🌐 Si vous utilisez un proxy HTTP, assurez-vous de suivre les instructions.
- Pour vérifier la version Kubernetes, exécutez la commande suivante :
kubectl version
