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.
Exécuté sur un cluster où Scrydon est déjà installé, l'installateur détecte la
release existante et bascule en mode mise à niveau. Il demande uniquement
vers quelle version aller — tout le reste est relu depuis le cluster :
Votre configuration
lue depuis la release active, reprise telle quelle
Identifiant de registre
récupéré depuis le pull secret déjà utilisé
Licence
déjà présente sur le cluster ; rien à ressaisir
Ce point est plus important qu'il n'y paraît. L'entretien d'installation porte
sur une dizaine de réglages ; une release en production en compte couramment
des dizaines — image de marque, e-mail, passkey, stockage, dimensionnement
StarRocks, CORS. Une mise à niveau ne doit pas réduire votre configuration aux
réponses d'un questionnaire : elle n'en repose donc aucune.
Avant toute modification, la nouvelle version est rendue côté serveur avec
votre configuration actuelle : une version qui exige un réglage absent échoue
au préflight en le nommant, plutôt qu'à mi-parcours.
L'installateur refuse également de revenir en arrière sans confirmation
explicite, et s'arrête si vous êtes déjà sur la version choisie.
Pour remplacer votre configuration par de nouvelles réponses, utilisez
--reconfigure. Cela écarte tout réglage que l'entretien ne couvre pas :
à utiliser délibérément.
Les étapes manuelles helm upgrade ci-dessous restent entièrement prises en
charge.
Les versions installables sont publiées sur get.scrydon.com/versions.json, que l'installateur guidé lit pour vous (bash setup.sh --list-versions affiche la même liste). Vos identifiants de registre ne peuvent toujours pas énumérer les tags eux-mêmes : 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.
Exception : Les retraits destructifs annoncés explicitement ne sont pas rétrocompatibles. Le retrait de l'ancien chat public Agentic ci-dessous supprime sa table avant le déploiement des nouveaux pods ; un rollback Helm seul ne peut restaurer ni cette fonctionnalité ni ses données.
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.
À partir de la v1.3.24, le chart expose Scrydon via la Gateway API Kubernetes — une
Gateway nommée gateway-frontdoor et une HTTPRoute par application — et ne génère
plus aucun objet Ingress. Un cluster qui exécutait une version antérieure sur un
contrôleur Ingress nécessite trois modifications du cluster et une modification des
valeurs avanthelm upgrade. Votre Ingress actuel continue de servir pendant les
trois premières, qui peuvent donc être appliquées avant la fenêtre de maintenance.
1. Installez les CRD de la Gateway API. Elles ne font pas partie d'un cluster
standard, et les charts Traefik récents ne les fournissent plus. Utilisez la version
prise en charge par votre contrôleur — pour Traefik v3.7 (chart Traefik 40.x), il s'agit
de la v1.5.1 :
2. Activez le provider Gateway de votre contrôleur et publiez sa GatewayClass. Pour
une release Traefik que vous avez installée vous-même, ajoutez à ses valeurs puis
exécutez helm upgrade avec la même version de chart :
providers: kubernetesGateway: enabled: truegateway: enabled: false # the Scrydon chart owns the Gateway; Traefik's own would compete with itgatewayClass: enabled: true # publishes the `traefik` GatewayClass that gateway.className names
Laissez le provider Ingress de Traefik activé (valeur par défaut). Votre Ingress actuel
continue de servir jusqu'à ce que la mise à niveau de Scrydon le remplace, et un
ClusterIssuer cert-manager existant avec un solver http01.ingress continue de
renouveler les certificats via la nouvelle Gateway. Vérifiez que la classe est acceptée
avant de continuer :
kubectl get gatewayclass traefik # ACCEPTED must be True
3. Activez la prise en charge Gateway API de cert-manager — config.enableGatewayAPI: true,
voir Prérequis TLS. Sans elle, aucun certificat n'est
jamais demandé pour la Gateway.
4. Renommez ingress: en gateway: dans votre fichier de valeurs. Les clés qu'il
contient restent inchangées. Le schéma de valeurs du chart n'accepte plus ingress : un
fichier qui l'utilise encore échoue à la validation avant toute modification du cluster.
Lancez ensuite la mise à niveau comme d'habitude. La Gateway reprend le même Secret de
certificat tls-frontdoor, le HTTPS n'est donc pas interrompu.
5. Vérifiez que cert-manager a repris le certificat. Le renouvellement dépend d'un
Certificate appartenant à la Gateway :
kubectl get certificate tls-frontdoor -n scrydon-platform \ -o jsonpath='{.metadata.ownerReferences[0].kind}{" "}{.status.renewalTime}{"\n"}'
Le résultat attendu est Gateway suivi d'une date de renouvellement. S'il n'existe aucun
Certificate, cert-manager a vu la Gateway alors que le Certificate de l'ancien Ingress
existait encore, a refusé de reprendre un certificat qui ne lui appartenait pas, et n'a
pas été relancé après la suppression de l'Ingress. Le HTTPS continue de fonctionner à
partir du Secret existant, mais rien ne le renouvellera. Redémarrez le contrôleur
cert-manager pour qu'il réconcilie à nouveau chaque Gateway :
Un helm rollback vers une révision antérieure à la v1.3.24 recrée l'Ingress ; les CRD
de la Gateway API et les réglages du contrôleur des étapes 1 à 3 peuvent rester en place.
La migration 0102_remove_legacy_chat supprime définitivement public.chat de la base de données Agentic. La page de chat publique hébergée, les routes /api/chat et /api/chat/:identifier, les API de gestion du chat et l'ancien client de streaming du SDK sont supprimés. Le chat Cortex, les publications A2A, l'exécution de workflows et client.chat.completions restent pris en charge.
Avant la mise à niveau, inspectez et exportez la table retirée, même si vous pensez qu'elle est vide :
psql "<agentic-database-url>" \ -c 'SELECT count(*) AS legacy_chat_rows FROM public.chat;'pg_dump "<agentic-database-url>" \ --data-only --table=public.chat --column-inserts \ > legacy-agentic-chat.sql
Protégez legacy-agentic-chat.sql comme une donnée sensible : les lignes historiques peuvent contenir une configuration d'accès, des adresses e-mail autorisées et des hachages de mots de passe. Stockez-le uniquement dans votre emplacement de sauvegarde chiffré approuvé, avec journalisation des accès et contrôles de rétention.
L'export de table est une aide d'archivage, pas une migration inverse prise en charge. Un snapshot PostgreSQL Agentic complet avant mise à niveau constitue le point de restauration de référence. helm rollback ou le redéploiement d'un ancien package Zarf ne recrée ni la table ni ses données, et les anciens pods Agentic ne peuvent plus servir les routes retirées après l'exécution du hook pré-mise à jour. La restauration de l'ancienne fonctionnalité exige de restaurer le snapshot complet de la base de données avant mise à niveau avec la révision précédente de l'application.
Les requêtes vers les routes supprimées reçoivent le 404 normal de la plateforme ; aucun shim de compatibilité n'est fourni. Traitez cette mise à niveau comme un retrait incompatible et migrez d'abord les appelants. Voir Migrations de base de données → Retrait de l'ancien chat public Agentic.
Le type de bloc de workflow sérialisé et masqué chat_trigger est supprimé dans
le cadre du même retrait. Les opérateurs autohébergés doivent inventorier
public.workflow_blocks, remplacer les blocs correspondants par le bloc Start
unifié et redéployer ces workflows avant la mise à niveau. Le panneau de
conversation de l'éditeur de workflow reste pris en charge via le bloc Start
unifié ; Cortex et A2A sont inchangés. Suivez la requête d'inventaire et les
instructions de remplacement dans Migrations de base de données → Retrait de
l'ancien chat public Agentic.
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.