Mises à jour

Cette page couvre la mise à jour de Scrydon, en mode connecté (Helm) comme isolé (Zarf). C'est vous qui décidez quand mettre à jour : Scrydon n'exécute aucun agent dans le cluster, donc rien ne change avant que vous lanciez la mise à jour.

Avant la mise à jour

• 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. Les migrations ne vont que vers l'avant : la sauvegarde est votre point de retour arrière. Une installation par défaut compte sept bases : auth, agentic, events, analytics, cortex, ontology et lakekeeper. Consultez Sauvegarde et restauration.
• Vérifiez votre licence. Ouvrez Settings → Organization → License et confirmez que le statut est valid et que l'expiration tombe après la fenêtre de mise à jour. Une mise à jour ne touche jamais à la licence : elle est stockée dans la base de données de la plateforme. Consultez Licences.
• 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.

Migrations de base de données

Vous n'exécutez jamais les migrations à la main. Chaque mise à jour les lance comme Jobs de hook Helm pre-upgrade, dans cet ordre, avant le démarrage de tout nouveau pod applicatif :

La mise à jour de vector s'exécute sur le PostgreSQL en service avant la mise à niveau : une version qui change l'image PostgreSQL fait évoluer l'extension à la mise à niveau suivante.

<revision> est la révision de la release Helm : chaque tentative obtient donc un nouveau Job. Un Job réussi est supprimé aussitôt ; un Job en échec reste disponible pour inspection et est remplacé à la tentative suivante. (Lors de la toute première installation, chaque Job s'exécute plutôt comme Job ordinaire, sans hook, nommé <service>-bootstrap-1 ; celui du schéma de collaboration garde son nom, collaboration-migration-1.)

Si une migration échoue, son Job se termine en BackoffLimitExceeded et helm upgrade signale la release comme failed. La version précédente continue de servir le trafic sans interruption. Lisez les journaux du Job :

bash

kubectl get jobs -n scrydon-platform | grep migration
kubectl 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.

Mise à niveau guidée (recommandée)

curl -fsSL https://get.scrydon.com | bash

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 :

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 :

FAIL    v1.4.0 needs settings your configuration does not have
   auth.secrets.NEW_THING must contain at least 32 characters

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.

Mises à jour connectées (Helm)

Découvrir les versions disponibles

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.

Mettre à jour

helm upgrade scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <new-version> \
  --values values.customer.yaml \
  -n scrydon-platform \
  --wait --timeout 15m

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.

Retour arrière

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 :

# List revision history
helm history scrydon -n scrydon-platform

# Roll back to revision N
helm 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.

Exception : À partir de 0171_ba175_account_issuer_relax (Better Auth 1.7.5), les comptes sont indexés d'une manière que la version précédente ne sait pas lire. Une version restaurée ne trouve pas les comptes créés après la mise à jour : effectuez le retour arrière en restaurant le snapshot auth pris avant la mise à jour. Consultez le runbook de mise à jour pour la vérification à exécuter avant et après cette mise à jour.

Récupération après un hook pré-mise à jour en échec

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. Inspect the failed job
kubectl get jobs -n scrydon-platform | grep migration
kubectl logs job/<job-name> -n scrydon-platform

# 2. Resolve the error (typically a data precondition — see the release notes
#    for any data fixes required by this version).

# 3. Retry the upgrade. It removes the failed Job and runs a fresh one.
helm upgrade scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon ...

Mises à jour isolées d'internet (Zarf)

Recevoir le nouveau package

Scrydon livre un nouveau package Zarf pour chaque version :

zarf-package-scrydon-amd64-<new-version>.tar.zst

Transférez le nouveau package dans votre environnement isolé via votre méthode de transfert approuvée.

Vérifier le nouveau package

Vérifiez-le côté connecté exactement comme pour une première installation, avec cosign verify-blob contre l'identité du workflow de release, puis contrôlez SHA256SUMS de l'autre côté. Les étapes se trouvent dans Déploiement isolé → Récupérer et vérifier.

Déployer par-dessus l'installation existante

Déployez le nouveau package par-dessus l'installation existante, avec les mêmes --set-variables que lors de la première installation :

zarf package deploy zarf-package-scrydon-amd64-<new-version>.tar.zst --confirm \
  --set-variables DOMAIN=app.example.gov \
  --set-variables TLS_ISSUER=internal-ca

Chaque déploiement repart des valeurs par défaut du package. Une variable omise reprend sa valeur par défaut : sans DOMAIN, la plateforme passe sur app.scrydon.com.

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.

Retour arrière (isolé d'internet)

Pour effectuer un retour arrière après une mise à jour isolée, redéployez le package Zarf précédent :

zarf package deploy zarf-package-scrydon-amd64-<previous-version>.tar.zst --confirm

Conservez l'archive du package précédent jusqu'à ce que la nouvelle version soit stable.

Vérification post-mise à jour

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.* :

# Check all pods are running (single-namespace default)
kubectl get pods -n scrydon-platform
# If you split namespaces via `namespaces.agentic` / `namespaces.analytics`,
# also check those namespaces.

# Check rollout status of key deployments
kubectl rollout status deployment/api-platform -n scrydon-platform
kubectl rollout status deployment/agentic -n scrydon-platform   # (or scrydon-agentic if split)

# Check the license: Settings → Organization → License should still say `valid`

# Confirm the running chart version matches what you intended
helm list -n scrydon-platform

Ouvrez https://<your-host>/platform, connectez-vous et vérifiez que vos workflows se chargent.

Modifications avec rupture de compatibilité

Modifié : le mot de passe du Postgres intégré est généré et conservé

infra.db.credentials.password valait par défaut la chaîne littérale postgres. La valeur par défaut est désormais vide : un vrai helm install génère un mot de passe aléatoire et le conserve dans le Secret secrets-infra, qui survit à helm uninstall avec db-pvc. Postgres fige le mot de passe dans son volume au premier démarrage : lors de chaque helm install/helm upgrade ultérieur, le mot de passe du secrets-infra actif l'emporte sur vos valeurs.

Conséquences pour une installation existante :

• helm upgrade direct, l'installateur, Zarf, Flux. Rien à faire. La mise à niveau relit dans secrets-infra le mot de passe que votre base utilise déjà, qu'il s'agisse de postgres, du REPLACE-WITH-SECURE-DB-PASSWORD des fichiers d'exemple ou de votre propre valeur.
• GitOps et autres rendus sans accès au cluster (ArgoCD, l'inflateur Helm de Kustomize, helm template | kubectl apply, helm diff, --dry-run). Un tel rendu ne peut pas lire secrets-infra : il garde exactement l'ancien comportement et utilise infra.db.credentials.password telle qu'écrite, valeur d'exemple comprise, ou postgres si elle est vide. Une installation qui n'a jamais défini la valeur continue de fonctionner avec postgres. Une nouvelle installation GitOps doit définir sa propre valeur depuis votre gestionnaire de secrets (compatible URL, ex. openssl rand -hex 16) ; voir Rendu sans cluster actif.

Faire tourner le mot de passe du Postgres intégré

Comme le Secret actif l'emporte, modifier la valeur dans votre fichier de valeurs est ignoré lors d'une mise à niveau active, et les notes d'installation affichent un avertissement. La rotation se fait en trois étapes, dans cet ordre :

NS=scrydon-platform   # your infra namespace (namespaces.infra)
NEW="$(openssl rand -hex 16)"

# 1. Change the password inside Postgres (postgres is the default
#    infra.db.credentials.user; use yours if you changed it).
kubectl exec -n "$NS" deploy/db -c postgres -- \
  psql -U postgres -c "ALTER USER postgres PASSWORD '$NEW'"

# 2. Record it in the Secret the chart reads back.
kubectl patch secret secrets-infra -n "$NS" --type merge \
  -p "{\"stringData\":{\"PG_DATABASE_PASSWORD\":\"$NEW\"}}"

# 3. Upgrade. Every DSN, migration Job and consumer pod picks up the new value.
helm upgrade scrydon <chart> -n "$NS" --reuse-values

Pour une installation GitOps, faites les étapes 1 et 2, puis définissez infra.db.credentials.password à la nouvelle valeur dans votre gestionnaire de secrets et laissez la synchronisation suivante la rendre.

Les notes d'installation avertissent aussi tant que le mot de passe reste une valeur connue (postgres ou la valeur d'exemple). Faites-le tourner avec les étapes ci-dessus.

Modifié : la Gateway API remplace Ingress (v1.3.24)

À 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 avant helm 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 :

kubectl apply --server-side \
  -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/standard-install.yaml

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: true
gateway:
  enabled: false   # the Scrydon chart owns the Gateway; Traefik's own would compete with it
gatewayClass:
  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.

# before                     # after
ingress:                     gateway:
  tls:                         tls:
    enabled: true                enabled: true

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 :

kubectl -n cert-manager rollout restart deployment/cert-manager

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.

Modifié : le marqueur de secret de l'exemple GitOps ne se rend plus

values.gitops.example.yaml livre chaque secret que vous devez fournir sous la forme REPLACE-ME-WITH-A-REAL-VALUE-FROM-YOUR-SECRET-STORE. La plupart de ces secrets ne sont vérifiés que sur leur longueur, et le marqueur est assez long : une copie de l'exemple se rendait donc et se déployait avec chacun d'eux réglé sur une valeur livrée avec le chart. Le chart refuse désormais de se rendre tant qu'une valeur est encore le marqueur, espaces autour compris, et l'erreur nomme le chemin de valeur à remplacer :

agentic.secrets.INTERFACE_VISITOR_TOKEN_SECRET is still the GitOps example's placeholder ...

Remplacez chacun d'eux depuis votre magasin de secrets avant la mise à jour. Pour lister ceux qui restent dans votre fichier de valeurs :

grep -n 'REPLACE-ME-WITH-A-REAL-VALUE-FROM-YOUR-SECRET-STORE' <your-values-file>.yaml

Si l'une de ces valeurs a déjà atteint votre cluster, c'était une valeur publique : faites tourner ce secret, pas seulement la ligne de votre fichier de valeurs.

api-agentic vérifie aussi INTERFACE_VISITOR_TOKEN_SECRET avant de démarrer. Il refuse désormais de démarrer quand la clé est absente, vide, plus courte que 32 caractères ou égale au marqueur, sauf si NODE_ENV vaut exactement development ou test. Le chart règle NODE_ENV à partir de global.environment : staging et tout autre nom suivent donc les règles de production. Une installation par le chart n'est pas concernée : le chart génère la clé si vous n'en fixez pas. Un déploiement qui exécute api-agentic hors du chart doit désormais fournir la clé (openssl rand -hex 32), là où il se rabattait auparavant sur BETTER_AUTH_SECRET pour tout NODE_ENV autre que production.

Supprimé : publications de formulaire

La migration 0141_drop_form_publication supprime définitivement public.form_publication et l'enum form_auth_type de la base de données Agentic. La publication de formulaires depuis la feuille de déploiement, /api/forms/... et l'API de gestion des publications de formulaire sont supprimées. Le déclencheur Form les remplace : recréez chaque formulaire publié sous la forme d'un workflow doté d'un déclencheur Form.

Avant la mise à niveau, inspectez et exportez la table, même si vous la pensez vide :

psql "<agentic-database-url>" \
  -c 'SELECT count(*) AS form_publications FROM public.form_publication;'

pg_dump "<agentic-database-url>" \
  --data-only --table=public.form_publication --column-inserts \
  > form-publications.sql

Protégez form-publications.sql comme un élément sensible : les lignes peuvent contenir des empreintes de mots de passe et des origines d'intégration autorisées.

La migration n'utilise pas CASCADE. Si vous avez créé une vue, une clé étrangère, une colonne de type form_auth_type ou un autre objet qui dépend de form_publication ou de son enum, la mise à niveau s'arrête avec une erreur de dépendance : supprimez d'abord votre objet. La migration utilise IF EXISTS : la rejouer une fois appliquée ne change rien. Un retour arrière exige l'instantané complet de la base d'avant la mise à niveau, avec la révision applicative précédente ; helm rollback ne recrée pas la table. Voir Migrations de base de données → Retrait des publications de formulaire.

Supprimé : ancien chat public Agentic

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.

Supprimé : valeur Helm license.product

La valeur Helm license.product a été supprimée. Si votre values.customer.yaml contient une clé license.product, supprimez-la avant la mise à jour : le schéma du chart la refuse, et la mise à jour échoue à la validation avec license: Additional property product is not allowed.

# Remove this line from your values file if present:
# license:
#   product: "scrydon-agentic"   # ← remove this

La licence porte désormais des droits en ressources (CPU, RAM et VRAM) au lieu d'un nom de produit. Consultez Licences.