Aller au contenu principal

Mettre à niveau Helm

danger

Ne procédez pas à un rollback ou à un downgrade sans consulter au préalable notre équipe support. Certains scénarios peuvent nécessiter la restauration de la base de données à partir d'une sauvegarde antérieure à la mise à niveau, en raison de la complexité de l'inversion de certaines migrations de base de données.

attention

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 Sauvegarde.

Chemin de mise à niveau et versions requises​

Certaines versions sont requises et ne peuvent pas être ignorées. Elles comportent des migrations de base de données et des changements d'infrastructure sur lesquels les versions ultérieures s'appuient, votre instance doit donc passer par chacune d'elles.

Les versions requises suivent un cycle trimestriel : janvier, avril, juillet et octobre. Toutes les autres versions sont facultatives. Vous pouvez reconnaître une version requise dans les notes de version self-hosted : son titre se termine par Required.

Si une ou plusieurs versions requises se situent entre votre version actuelle et la version que vous visez, mettez à niveau vers chacune d'elles dans l'ordre avant d'atteindre votre cible. Passer de 2025.6 à 2026.7, par exemple, nécessite cinq mises à niveau successives :

2025.6 ➔ 2025.7 ➔ 2025.10 ➔ 2026.1 ➔ 2026.4 ➔ 2026.7

Pour chaque étape du chemin :

  1. Consultez les breaking changes de la version cible et le changelog des valeurs Helm, puis mettez à jour votre fichier de valeurs en conséquence.
  2. Exécutez la mise à niveau.
  3. Attendez que l'application soit entièrement mise à niveau avant de démarrer l'étape suivante : tous les pods en cours d'exécution et tous les jobs terminés.
remarque

Vous ne pouvez pas ignorer une version requise par accident. Chaque mise à niveau commence par un job upgrade-path-check qui valide le chemin et arrête la mise à niveau avant qu'aucun changement ne soit appliqué si une version requise est manquante.

Exécuter les vérifications preflight​

Prérequis

Les vérifications preflight sont essentielles pour une installation réussie. Les règles suivantes s'appliquent :

  • ❌ Échecs des vérifications preflight : si les vérifications preflight échouent, la mise à niveau ne doit pas continuer tant que l'environnement ciblé ne remplit pas toutes les exigences. N'hésitez pas à contacter notre équipe support si nécessaire.
  • ⚠️ Avertissements des vérifications preflight : si les vérifications preflight renvoient des avertissements, l'installation peut se poursuivre, mais il est recommandé de traiter ces avertissements pour respecter nos recommandations.

Nous vous recommandons vivement d'exécuter notre script preflight pour vous assurer que votre existing cluster répond aux exigences de GitGuardian.

Récupérez le script depuis notre dépôt public ici

Spécifiez un namespace Kubernetes existant à l'aide de l'option -n. Si elle n'est pas spécifiée, le script s'exécutera dans votre namespace par défaut. Remplacez <release-name> par le nom de votre release helm existante.

./preflights.sh -r <release-name> -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian -f local-values.yaml

Mise à niveau de l'application GitGuardian​

Connectez-vous au registre à l'aide de la commande suivante :

helm registry login registry.replicated.com --username your.name@yourcompany.com

Mettez à niveau l'application GitGuardian vers la dernière version dans le cluster Kubernetes et le namespace où elle est installée :

helm upgrade <release-name> -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian -f local-values.yaml

Remplacez <release-name> par le nom utilisé lors de l'installation initiale (utilisez helm ls pour le trouver). Si nécessaire, spécifiez le namespace avec -n (le namespace par défaut est utilisé s'il n'est pas spécifié).

Cela mettra à niveau votre application vers la dernière version. Pour effectuer une mise à niveau vers une version spécifique, utilisez le flag --version :

helm upgrade <release-name> -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian --version 2024.x.y -f local-values.yaml

Mise à niveau de l'application GitGuardian en Airgap​

Suivez ces étapes pour mettre à niveau une installation basée sur Helm dans un environnement air-gapped :

  1. Connectez-vous au registre Helm :

    helm registry login registry.replicated.com --username your.name@yourcompany.com

  2. Téléchargez le chart Helm localement (remplacez par la version souhaitée si nécessaire) :

    helm fetch oci://registry.replicated.com/gitguardian/gitguardian
    # this will download a file like gitguardian-<version>.tgz

  3. Authentifiez Docker auprès du proxy Replicated pour extraire les images (remplacez <your_licenseID>) :

    LICENSE_ID="<your_licenseID>"; \
    echo "{\"auths\": {\"proxy.replicated.com\": {\"auth\": \"$(echo -n \"${LICENSE_ID}:${LICENSE_ID}\" | base64)\"}, \"registry.replicated.com\": {\"auth\": \"$(echo -n \"${LICENSE_ID}:${LICENSE_ID}\" | base64)\"}}}" > ~/.docker/config.json

  4. Extrayez les images requises pour la version cible, puis téléversez-les dans votre registre privé. Consultez la liste des images sur la page d'installation Airgap. Vous pouvez utiliser docker ou skopeo pour transférer les images.

    Architecture des images

    Toutes les images GitGuardian sont multi-architectures. Vous n'avez pas besoin de passer --platform lors de leur extraction ; la variante correcte est sélectionnée automatiquement en fonction de l'architecture de l'hôte.

  5. Exécutez les vérifications preflight sur l'archive de chart locale :

    ./preflights.sh -r <release-name> -n <namespace> gitguardian-<version>.tgz -f local-values.yaml

  6. Mettez à niveau à l'aide de l'archive de chart locale :

    helm upgrade <release-name> --timeout 30m -n <namespace> gitguardian-<version>.tgz -f local-values.yaml

Remplacez <release-name>, <namespace> et <version> en conséquence. Assurez-vous que votre local-values.yaml pointe vers votre registre d'images privé comme décrit sur la page d'installation Airgap.

Mise à jour de la configuration de l'application​

Modifiez la configuration de l'application avec un fichier de valeurs mis à jour à l'aide de la commande helm upgrade. Restez sur la même version à l'aide du flag --version :

helm upgrade <release-name> -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian --version 2024.x.y -f local-values.yaml

Remplacez <release-name> par le nom utilisé lors de l'installation initiale (utilisez helm ls pour le trouver). Si nécessaire, spécifiez le namespace Kubernetes avec -n (le namespace par défaut est utilisé s'il n'est pas spécifié).

Breaking changes​

Certaines versions nécessitent des changements manuels avant la mise à niveau. Vérifiez chaque version entre votre version actuelle et votre version cible, y compris celles par lesquelles vous passez sur votre chemin de mise à niveau.

2025.10​

Si vous utilisez un déploiement air gap : cette version utilise désormais un chart et une image Docker non-Bitnami pour le sous-chart MinIO (qui prend en charge la fonctionnalité de log collector). Ce changement implique des modifications mineures de votre fichier values.yaml :

Modifiez votre fichier de valeurs Helm :

  • Mettez à jour loki-minio.image.repository de gitguardian/wolfi/minio-bitnami vers gitguardian/wolfi/minio.
  • Mettez à jour loki-minio.image.tag de 0.20250723 vers 0.20250907.
  • Renommez le paramètre loki-minio.image.pullPolicy en loki-minio.image.imagePullPolicy.

2025.8​

Si vous utilisez un déploiement air gap : cette version introduit un nouveau paramètre image.registry dans les valeurs Helm pour prendre en charge le système Log Collector. Ce paramètre spécifie l'emplacement des images GitGuardian pour les composants du Log Collector (Loki, MinIO, Fluent Bit) et est distinct du paramètre principal imageRegistry.

Ajoutez le paramètre image.registry à votre fichier de valeurs Helm :

global:
  imageRegistry: docker.internal/example/path # Location of the GitGuardian images
  image:
    registry:  docker.internal/example/path # Location of the GitGuardian images (same as imageRegistry)

Retrouvez tous les noms d'images et de tags sur la page d'installation Air Gap.

2025.7​

Le moteur Machine Learning est désormais activé par défaut. Assurez-vous que votre infrastructure répond aux exigences ML.

2025.6​

GitGuardian 2025.6 nécessite désormais Kubernetes 1.28 comme version minimale prise en charge. Cependant, Kubernetes 1.28 ne reçoit plus de support actif ou de maintenance de la part du projet Kubernetes (le support a pris fin en octobre 2024).

Nous vous recommandons vivement de passer à Kubernetes 1.32 pour une sécurité et une stabilité optimales. Kubernetes 1.32 est activement pris en charge jusqu'en décembre 2025 et recevra un support de maintenance jusqu'en février 2026.

Pour plus d'informations :

2025.5​

Déploiement air gap ? Nous avons renommé des images dans cette version. Voir ci-dessous et retrouvez tous les noms d'images et de tags sur la page d'installation Air Gap.

Ce changement implique de renommer les images suivantes :

  • gitguardian/prm-static-chainguard-fips en gitguardian/prm-static-chainguard
  • gitguardian/prm-app-fips en gitguardian/prm-app-chainguard

2025.4​

Veuillez installer l'extension PostgreSQL pgvector pour activer la recherche de similarité vectorielle. Ceci est essentiel pour les fonctionnalités à venir exploitant notre moteur de machine learning interne. Suivez les instructions d'installation pour garantir la compatibilité.

Déploiement air gap ? Nous avons ajouté de nouvelles images dans cette version. Les nouvelles images concernent le système de collecte de logs, qui comprend :

  • Fluent Bit (log collector)
  • Loki (agrégation de logs)
  • MinIO (stockage objet pour les logs)

Retrouvez tous les noms d'images et de tags sur la page d'installation Air Gap.

2025.3​

La version 2025.3 introduit un breaking change dans l'URL du registre de nommage, y compris le chemin et les noms d'images. Si vous téléchargez nos images dans un registre privé (consultez notre documentation air gap), assurez-vous de mettre à jour votre outillage, ainsi que les noms et chemins des images dans votre fichier de valeurs Helm.

Changement de l'URL du registre

  • Ancien : proxy.replicated.com/proxy/gitguardian/513715405986.dkr.ecr.us-west-2.amazonaws.com
  • Nouveau : proxy.replicated.com/proxy/gitguardian/docker.io

Changements des chemins et noms d'images

  • /prm/static-chainguard ➔ /gitguardian/prm-static-chainguard-fips
  • /prm/app-chainguard ➔ /gitguardian/prm-app-chainguard-fips
  • /prm/helm-tooling ➔ /gitguardian/prm-helm-tooling
  • /services/nginx-unprivileged ➔ /nginxinc/nginx-unprivileged
  • /ml-detector/ml-secret-engine/app-chainguard ➔ /gitguardian/ml-secret-engine-app-chainguard-fips

Changement de l'URL du registre

  • Ancien : registry.replicated.com
  • Nouveau : proxy.replicated.com/proxy/gitguardian/docker.io

Changements des chemins et noms d'images

  • /gitguardian/replicated-sdk ➔ /replicated/replicated-sdk

Notes supplémentaires​

Stratégie de mise à jour des pods​

L'objectif est de trouver un équilibre entre la continuité de service et les ressources disponibles sur le cluster. Vous pouvez définir quelle stratégie de mise à jour utiliser lors d'une mise à niveau / mise à jour.

Cette configuration est possible pour les celeryWorkers (celeryWorkers.worker.updateStrategy) et les webapps (webapps.app.updateStrategy).

Si elle n'est pas définie, cette stratégie par défaut s'applique :

  • Si moins de 3 réplicas
type: RollingUpdate
rollingUpdate:
	maxUnavailable: 50%
	maxSurge: 50%
  • Sinon
type: RollingUpdate
rollingUpdate:
	maxUnavailable: 25%
	maxSurge: 25%
Dernière mise à jour le

Il manque quelque chose ?

Voir notre feuille de route
S'abonner sur GitHub
Soumettre une demande
Statut de l’API