Comment mettre à jour et effectuer un retour arrière de la plateforme Scrydon
Cette page couvre la mise à jour de Scrydon pour les déploiements connectés (Helm) et isolés d'internet (Zarf). Les mises à jour sont pilotées par le client — Scrydon n'exécute pas d'agent dans le cluster, donc les mises à jour se déroulent selon votre planning lorsque vous exécutez helm upgrade.
Avant de procéder à la mise à jour, effectuez ces étapes :
Lisez les notes de version. Chaque version est accompagnée de notes couvrant les modifications avec rupture de compatibilité, les changements de configuration requis et les éventuelles étapes manuelles. Les notes de version ne sont pas publiées sur un site public — demandez-les à votre équipe de compte Scrydon pour la version cible avant de procéder à la mise à jour.
Sauvegardez vos bases de données. Exécutez pg_dump sur toutes les bases de données Scrydon activées — par défaut il y en a cinq : auth, agentic, analytics, cortex, ontology. Les migrations sont unidirectionnelles.
Vérifiez que votre licence est toujours valide. Dans l'interface de la plateforme, ouvrez Paramètres → Licence et confirmez que la date d'expiration est postérieure à la fenêtre de mise à jour planifiée. La licence se trouve dans la ligne platform_config, pas dans un init container — il n'y a pas de conteneur license-check contre lequel consulter les journaux.
Notez votre version actuelle du chart. Exécutez helm list -n scrydon-platform pour avoir une révision de référence fonctionnelle vers laquelle revenir si nécessaire.
Confirmez que les identifiants du registre fonctionnent toujours.helm registry login scrydonops.azurecr.io --username <acr-token-name> doit réussir avant de démarrer la mise à jour.
Scrydon exécute les migrations de base de données en tant que Jobs de hook Helm — un par service (auth-migration, agentic-migration, analytics-migration, cortex-migration, api-ontology-migration). Ils se déclenchent en post-install lors de la première installation et en pre-upgrade à chaque mise à jour, de sorte que tout changement de schéma s'exécute avant le déploiement des nouveaux pods d'application. Vous n'avez pas besoin d'exécuter les migrations manuellement.
Important : Si une migration échoue, le Job correspondant entre dans l'état BackoffLimitExceeded et helm upgrade signale la version comme failed. La révision de l'application précédente continue de traiter le trafic sans interruption. Consultez les journaux du Job pour diagnostiquer :
kubectl get jobs -n scrydon-platform | grep migrationkubectl logs job/<job-name> -n scrydon-platform
Certaines migrations incluent également des préconditions d'intégrité des données — elles échouent rapidement avec un message clair si vos données ne les satisfont pas, et nécessitent une action de l'opérateur avant nouvelle tentative. Voir Récupération après un hook pré-mise à jour en échec ci-dessous.
Il n'existe pas de liste publique des versions de chart disponibles, et vos identifiants de registre ne peuvent pas non plus lister les tags : il s'agit d'un token ACR en lecture seule (autorisation content/read sur un ensemble fixe de dépôts), qui peut donc exécuter helm pull sur un tag connu mais ne peut pas énumérer ce qui est publié. La source du chart et les notes de version se trouvent dans un dépôt Scrydon privé.
Pour savoir quoi installer, contactez votre équipe de compte Scrydon. Ils partageront le tag « dernière version en production » actuel, les éventuels tags de pré-version plus récents, et les notes de version correspondantes.
Les tags de production utilisent le format vMAJEUR.MINEUR.CORRECTIF (par exemple v1.3.6). Les tags se terminant par -rc.N, -alpha.N, -beta.N ou -staging.N sont des pré-versions et ne doivent pas être déployés en production.
Une fois que vous avez un tag de votre équipe de compte, vous pouvez vérifier qu'il est actuellement publié sur ACR en récupérant uniquement son Chart.yaml :
helm show chart oci://scrydonops.azurecr.io/scrydon/charts/scrydon --version v1.3.6
Une erreur 404 signifie que le tag n'est pas actuellement dans le registre — les anciens tags de production expirent selon une politique de rétention. Demandez à votre équipe de compte de le republier si vous avez besoin d'un tag qui ne se résout plus.
Helm effectue une mise à jour progressive. Les anciens pods continuent de s'exécuter jusqu'à ce que les nouveaux soient en bonne santé. Utilisez le même values.customer.yaml qui a été utilisé pour l'installation précédente — les surcharges sont conservées.
Format du tag : Les tags du chart Scrydon conservent le v en préfixe (v1.3.6), contrairement à la plupart des registres OCI. Passez --version v1.3.6, et non 1.3.6.
Si la mise à jour introduit un problème, effectuez un retour arrière vers la version précédente :
helm rollback scrydon -n scrydon-platform
Pour revenir à une révision spécifique :
# Lister l'historique des révisionshelm history scrydon -n scrydon-platform# Revenir à la révision Nhelm rollback scrydon <revision-number> -n scrydon-platform
Remarque : Effectuer un retour arrière d'une version Helm n'annule pas les migrations de base de données. Si une migration a ajouté des colonnes ou des tables, elles restent après le retour arrière. Les migrations Scrydon sont conçues pour être rétrocompatibles, donc la version de l'application après retour arrière continuera de fonctionner.
Si la mise à jour échoue pendant une migration pré-mise à jour (statut failed dans helm history), les workloads ne sont pas touchés et la révision précédente est toujours active. Pour réessayer :
# 1. Inspecter le job en écheckubectl get jobs -n scrydon-platform | grep migrationkubectl logs job/<job-name> -n scrydon-platform# 2. Résoudre l'erreur (généralement une précondition de données — voir les notes de version# pour les éventuelles corrections de données requises par cette version).# 3. Supprimer le job en échec pour que la prochaine mise à jour puisse le recréer.kubectl delete job <job-name> -n scrydon-platform# 4. Réessayer la mise à jour.helm upgrade scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon ...
Zarf chargera les nouvelles images dans le registre interne au cluster et mettra à jour la version Helm. Les pods existants sont remplacés selon une stratégie de mise à jour progressive.
Après toute mise à jour, vérifiez que le déploiement est en bonne santé. La disposition par défaut du chart place chaque service dans scrydon-platform ; ajustez uniquement si vous avez remplacé namespaces.* :
# Vérifier que tous les pods s'exécutent (espace de noms unique par défaut)kubectl get pods -n scrydon-platform# Si vous avez séparé les espaces de noms via `namespaces.agentic` / `namespaces.analytics`,# vérifiez également ces espaces de noms.# Vérifier l'état du déploiement des services cléskubectl rollout status deployment/api-platform -n scrydon-platformkubectl rollout status deployment/agentic -n scrydon-platform # (ou scrydon-agentic si séparé)# Vérifier que la licence est toujours valide — charger Paramètres → Licence dans l'interface de la plateforme# (la licence se trouve dans la ligne DB platform_config, pas dans un init container)# Confirmer que la version du chart en cours d'exécution correspond à ce que vous aviez prévuhelm list -n scrydon-platform
Ouvrez https://app.yourdomain.com et vérifiez que vous pouvez vous connecter et accéder aux workflows.
La valeur Helm license.product a été supprimée. Si votre values.customer.yaml contient une clé license.product, supprimez-la pour éviter toute confusion — la valeur n'a aucun effet et est silencieusement ignorée par Helm.
# Supprimez cette ligne de votre fichier de valeurs si elle est présente :# license:# product: "scrydon-agentic" # ← à supprimer
La licence utilise désormais un modèle basé sur les ressources (CPU/RAM/VRAM) au lieu d'un modèle basé sur les produits.