Helm

Voici la référence de configuration du chart Helm Scrydon. Ce document présente une installation condensée, puis détaille chaque groupe de valeurs exposé par le chart — ce que fait chaque clé, pourquoi la modifier et comment procéder. Si vous souhaitez simplement démarrer un cluster le plus rapidement possible, commencez par la page Localisation (On-Premise, Azure (AKS), Air-Gapped) et revenez ici pour les options.

Pour un cluster air-gapped (sans internet sortant), consultez le Déploiement Air-Gapped — le même chart est livré dans un bundle Zarf.

Fonctionnement de la configuration

Trois couches, de la priorité la plus basse à la plus haute :

1. Valeurs par défaut du chart — le chart fournit des valeurs de production sensées pour tout. La liste de référence est le values.yaml du chart lui-même (voir Inspecter le chart localement).
2. Votre values.customer.yaml — le fichier que vous passez avec -f. Ne surchargez que ce dont vous avez besoin ; tout le reste hérite de la valeur par défaut.
3. Flags --set — priorité maximale, utile pour injecter des secrets au moment de l'installation depuis un gestionnaire de secrets.

helm install scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> -n scrydon-platform \
  -f values.customer.yaml \
  --set apiTable.secrets.STARROCKS_PASSWORD="$(vault kv get -field=password kv/scrydon/starrocks)"

Les secrets vivent dans votre fichier de valeurs. values.customer.yaml et helm get values <release> reproduisent toutes les valeurs fournies par l'utilisateur. Ne placez pas ce fichier dans un dépôt de code source, ou gérez-le via Sealed Secrets / SOPS / External Secrets Operator, et restreignez le RBAC du cluster sur le Secret de la release.

Inspecter le chart localement

Le chart est un artefact OCI dans scrydonops.azurecr.io — il n'existe pas de miroir Git public. Téléchargez-le pour lire chaque template et le values.yaml par défaut complet :

helm pull oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> --untar
less scrydon/values.yaml   # la valeur par défaut de référence pour chaque clé ci-dessous

Installation rapide

Le minimum pour obtenir un cluster opérationnel. Chaque étape est développée avec des notes spécifiques à l'environnement sur les pages Localisation.

# 1. Se connecter au registre (nom d'utilisateur = nom du token ACR fourni par votre équipe)
helm registry login scrydonops.azurecr.io --username <acr-token-name>

# 2. Créer le namespace de la release + un secret d'extraction d'image dans ce namespace.
#    Le chart cible par défaut scrydon-platform pour chaque service ; la séparation en
#    namespaces est optionnelle via namespaces.* (créer le secret dans chaque namespace ciblé).
kubectl create namespace scrydon-platform 2>/dev/null || true
kubectl create secret docker-registry scrydon-registry --namespace scrydon-platform \
  --docker-server=scrydonops.azurecr.io \
  --docker-username=<acr-token-name> --docker-password=<acr-token-password>

# 3. values.customer.yaml — l'installation minimale complète.
global:
  imageRegistry: scrydonops.azurecr.io   # récupérer les images depuis l'ACR connecté
  imagePullSecrets:
    - name: scrydon-registry
  storageClass: <your-storage-class>     # nom de classe cloud par défaut, ou votre provisionneur on-prem

routing:
  host: app.example.com                  # le nom d'hôte vers lequel pointe votre DNS

ingress:
  tls:
    enabled: true                        # le navigateur accède à Scrydon via HTTPS — voir Ingress ci-dessous

infra:
  db:
    credentials:
      password: REPLACE-WITH-DB-PASSWORD          # openssl rand -hex 16
auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET         # openssl rand -hex 32
apiTable:
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PW # openssl rand -hex 24

# 4. Installer
helm install scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> --namespace scrydon-platform \
  -f values.customer.yaml --wait

Lancer l'assistant de configuration

Ouvrez https://app.example.com/platform/setup (ou /setup si vous avez monté platform à la racine). Cinq étapes :

Pré-injecter la licence

Évitez l'étape licence de l'assistant en injectant le bundle lors de la première installation. Les valeurs sont lues une seule fois pour initialiser la base de données ; ensuite la licence vit dans platform_config et est gérée depuis l'interface :

auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET
    LICENSE: |                              # le champ `jwt` du bundle (une ligne)
      eyJhbGciOiJSUzI1NiIs...
    LICENSE_PUBLIC_KEY: |                    # le champ `publicKey` du bundle (PEM)
      -----BEGIN PUBLIC KEY-----
      MIIBIjANBgkqhkiG9w0BAQEFA...
      -----END PUBLIC KEY-----

Lorsque les deux valeurs sont définies, l'étape Licence de l'assistant s'ouvre déjà vérifiée.

Référence de configuration

Chaque groupe ci-dessous correspond à une clé de premier niveau dans le values.yaml du chart, dans l'ordre du fichier. Les valeurs par défaut indiquées sont celles du chart ; ne surchargez que ce dont vous avez besoin.

global — registre, images, stockage

Paramètres à l'échelle du cluster, hérités par chaque service.

global:
  imageRegistry: scrydonops.azurecr.io
  imagePullSecrets:
    - name: scrydon-registry
  storageClass: managed-csi

namespaces — placement des charges de travail

Chaque service cible par défaut scrydon-platform. Surchargez par service pour un isolement multi-namespace ; le chart aligne automatiquement les politiques ACL Dapr et le RBAC de lecture des secrets.

namespaces:
  infra: scrydon-infra
  platform: scrydon-platform
  agentic: scrydon-agentic
  analytics: scrydon-platform
  cortex: scrydon-platform

ingress — exposition et schéma TLS

routing — sous-chemin vs sous-domaine

Choisit comment les applications sont exposées. Discussion complète : Modes de routage.

routing:
  mode: subpath
  host: app.example.com
  paths:
    cortex: /scrydon/cortex      # personnaliser les préfixes si nécessaire
    platform: /scrydon/platform

dapr — maillage de services et identité

Les appels de service à service utilisent Dapr avec mTLS ; les politiques ACL du chart sont basées sur le domaine de confiance SPIFFE.

Apporter votre propre Dapr requiert ≥ 1.17.7, le domaine de confiance scrydon sur dapr-sentry (ou faire correspondre via dapr.trustDomain), et un injecteur de sidecar opérationnel. Voir Installations Dapr existantes.

Base de données — Postgres intégré ou BYO

infra.db contrôle le Postgres intégré (pgvector). Pour une instance externe/managée, la recette complète — notes par fournisseur, clés infra.db.external.*, pré-création des bases — est sur BYO Database.

# Intégré (défaut) — définir juste un mot de passe fort :
infra:
  db:
    credentials:
      password: REPLACE-WITH-DB-PASSWORD
# Postgres managé BYO :
infra:
  db:
    enabled: false
    external:
      existingSecrets:
        auth: scrydon-auth-db
        agentic: scrydon-agentic-db
      sslMode: require

StarRocks — Tables managées (OLAP)

Pod unique allin1-ubuntu. Alimente l'interface Tables et le fallback d'inférence de schéma agentique. Associé à apiTable.

L'image intégrée livre root sans mot de passe. Définissez apiTable.secrets.STARROCKS_PASSWORD dans les valeurs, puis appliquez-le dans StarRocks après l'installation — voir Identifiants StarRocks. Pour une production multi-AZ, passez à l'starrocks-kubernetes-operator (séparation FE/BE) et pointez apiTable.starrocks.host vers son Service FE.

SeaweedFS — stockage objet

Stockage compatible S3 en pod unique pour les téléversements.

Services applicatifs

Les applications produit — auth (api-platform), platform, cortex, analytics, apiOntology, apiTable, agentic (app + realtime). Chaque bloc partage une forme commune :

Clés notables spécifiques aux applications :

auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET   # signature de session — openssl rand -hex 32
  auditLog:
    enabled: true                           # transfert SIEM + crons de rétention (ADR 2026-04-16)
    chain:
      enabled: false                        # chaîne de hachage infalsifiable — optionnel, coût de signature

analytics:
  marimoSidecar:
    enabled: true                           # éditeur de notebooks ; désactiver pour réduire ~2Gi
  secrets:
    MARIMO_EDIT_TOKEN: ""

apiTable:
  starrocks:
    host: ""                                # vide → Service FE intégré ; indiquer pour StarRocks externe
    user: root
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PW

agentic:
  realtime:
    ingress:
      annotations:                          # cookie sticky pour la route WebSocket
        traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
  passkey:
    rpId: app.example.com                   # DOIT correspondre à routing.host sinon l'enregistrement passkey échoue
    origin: https://app.example.com

auth.secrets.SERVICE_ADMIN_TOKEN est déprécié — la production utilise Dapr mTLS (SPIFFE). Ne le définir que pour le développement local sans sidecars. Quand les clés avec underscore sont interdites (paramètres protégés Azure Marketplace), utiliser auth.authSecret à la place de auth.secrets.AUTH_SECRET.

opa — point de décision d'autorisation

Chaque décision d'autorisation sur les espaces de travail, workflows et ontologies est évaluée par OPA.

license — posture de validation

auth.secrets.LICENSE_PUBLIC_KEY doit être défini chaque fois que license.enabled: true pour qu'api-platform puisse vérifier les signatures JWT. Voir Licences.

packSources — distribution de packs gérée par le chart

Ordonnancement des pods

Les nodeSelector, tolerations et affinity à l'échelle du chart s'appliquent à chaque Deployment, StatefulSet et Job de migration — les pods peuvent ainsi atterrir sur des nœuds dédiés ou marqués avec des teints. Les surcharges par composant ne sont pas exposées.

tolerations:
  - { key: workload, operator: Equal, value: scrydon, effect: NoSchedule }
nodeSelector:
  workload: scrydon
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - { key: node-role.kubernetes.io/scrydon, operator: Exists }

Réduction pour les installations à ressources limitées

Les valeurs par défaut présupposent un cluster de forme production (≥ 8 vCPU / ≥ 32 Gio sur les nœuds). Sur des clusters d'évaluation (4 vCPU / 16 Gio), désactivez les composants optionnels les plus lourds :

infra:
  starrocks:
    enabled: false     # ~2–8 Gio RAM, 20 Gio PVC — seules les Tables managées + l'inférence de schéma agentique sont affectées
apiTable:
  enabled: false
analytics:
  enabled: false       # supprime l'interface analytique + le sidecar marimo (~2 Gio)

Recettes de configuration courantes

Personnaliser les chemins de routage

Montez les applications sous des préfixes différents (ex. tout sous /scrydon/...) via routing.paths.* — voir le tableau routing ci-dessus et Modes de routage.

Installations Dapr existantes

Si le cluster exécute déjà Dapr, mettez dapr.installControlPlane: false pour que le chart ne tente pas de le gérer, et pointez dapr.controlPlaneNamespace vers l'emplacement de Dapr :

dapr:
  installControlPlane: false
  controlPlaneNamespace: dapr-system

Votre Dapr doit satisfaire trois prérequis, faute de quoi la connexion fonctionne mais la création de compte / les appels inter-services échouent avec PermissionDenied :

kubectl -n <dapr-ns> get deploy dapr-sentry \
  -o jsonpath='{.spec.template.spec.containers[0].image}'   # attendre sentry:1.17.7+

Ingress avancé : derrière un équilibreur de charge qui termine le TLS

Les configurations App Gateway / ALB / GCP LB / F5 nécessitent un ajustement du contrôleur Traefik (trustedIPs, externalTrafficPolicy: Local, la règle de schéma public ingress.tls.enabled, ingress privé, dépannage 502). Guide complet : TLS Offloading.

Identifiants StarRocks

Le StarRocks intégré est livré avec root sans mot de passe. Après helm install, appliquez le mot de passe défini dans apiTable.secrets.STARROCKS_PASSWORD :

NEW_PW="<your-starrocks-password>"   # même valeur que apiTable.secrets.STARROCKS_PASSWORD
# StarRocks est dans le namespace de la release par défaut (namespaces.infra → scrydon-platform).
kubectl -n scrydon-platform exec -it deploy/starrocks-fe -- \
  mysql -h127.0.0.1 -P9030 -uroot -e "SET PASSWORD FOR 'root' = PASSWORD('${NEW_PW}');"
kubectl -n scrydon-platform rollout restart deployment/svc-api-table

api-table entre en CrashLoop entre l'installation et cette étape — c'est attendu ; il se stabilise après le redémarrage. Pour apporter votre propre StarRocks :

infra:
  starrocks:
    enabled: false
apiTable:
  starrocks:
    host: starrocks-fe.starrocks.svc.cluster.local
    user: scrydon
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PASSWORD

Vérifier le déploiement

kubectl get pods -n scrydon-platform   # tous Running, 2/2 avec le sidecar Dapr
kubectl get ingress -n scrydon-platform   # chaque Ingress a une ADDRESS
kubectl get certificates -A             # Certificats cert-manager READY=True

Les données de licence (niveau, droits, jours avant expiration) apparaissent sous Paramètres de la plateforme → Licence après /setup. Connectez-vous sur https://app.example.com/ et passez d'une application à l'autre via le sélecteur de produit sans vous reconnecter.

Dépannage

Opérations de jour 2

• Renouveler la licence — collez le bundle renouvelé sous Paramètres → Licence → Mettre à jour la licence ; pas de redémarrage. Licences.
• Sauvegarde & restauration — CronJob Postgres intégré (infra.db.backup) ou votre fournisseur managé. Sauvegarde & Restauration.
• Mises à jour — Mises à jour.
• Observabilité — Observabilité.