Cloud Temple

Cloud Temple est un fournisseur de cloud souverain français dont l'infrastructure est qualifiée SecNumCloud, certifiée HDS, ISO 27001 et attestée C5 allemand. Scrydon s'exécute sur son offre Managed Kubernetes sous forme d'une installation Helm standard — le même chart que sur AKS ou en on-premise, avec les spécificités Cloud Temple pour le stockage, l'ingress et les flux sortants détaillées ci-dessous.

Il n'existe aujourd'hui aucune offre Scrydon sur le Marketplace de Cloud Temple : cette page décrit donc la voie Helm. Si vous avez besoin d'une isolation réseau plus stricte que ce qu'autorise un pull de registre, consultez plutôt Déploiement en environnement air-gapped.

Avant de commencer

• Un cluster Cloud Temple Managed Kubernetes exécutant Kubernetes 1.28+ avec accès kubectl.
• Un bundle de licence de Scrydon — un JSON { "jwt": "…", "publicKey": "…" }.
• Des identifiants de registre pour scrydonops.azurecr.io (le nom du jeton ACR + sa valeur, fournis par votre équipe commerciale).
• Un nom DNS unique pointant vers votre ingress (par ex. app.example.com).
• cert-manager installé dans le cluster pour les certificats TLS automatiques.

Dimensionnement complet et checklist : Prérequis. Pour la liste des hôtes externes que l'installation contacte, voir Liste d'autorisation des flux sortants ci-dessous — partagez-la avec votre équipe réseau avant de commencer si votre cluster est soumis à une politique de sortie restrictive.

Étape 1 : Se connecter au registre

helm registry login scrydonops.azurecr.io --username <acr-token-name>
# (collez la valeur du jeton à l'invite de mot de passe)

Étape 2 : Créer le namespace et le secret de pull

Par défaut, le chart déploie chaque service dans un seul namespace, scrydon-platform :

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>

Répartir les services sur plusieurs namespaces est optionnel via namespaces.* (voir la référence Helm). Si vous le faites, créez le même secret de pull dans chaque namespace ciblé.

Étape 3 : Rédiger values.customer.yaml

Les spécificités Cloud Temple sont global.storageClass (pointez-le vers le provisionneur CSI exposé par votre cluster — interrogez-le avec kubectl get storageclass) et le nom d'hôte de l'ingress. Les valeurs par défaut du chart — ingress Traefik, émetteur letsencrypt-prod, Postgres / StarRocks / SeaweedFS intégrés — fonctionnent sans modification.

# Remplacez les REPLACE-WITH-* par des valeurs que vous générez. Gardez ce fichier hors du contrôle de version.

global:
  imageRegistry: scrydonops.azurecr.io  # tire les images depuis l'ACR auquel vous vous êtes connecté
  imagePullSecrets:
    - name: scrydon-registry            # de l'étape 2
  storageClass: <your-storage-class>    # interrogez : kubectl get storageclass

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

ingress:
  tls:
    enabled: true                       # le navigateur atteint Scrydon en HTTPS

# Secrets — générez-en de nouveaux à chaque déploiement.
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

Étape 4 : Installer

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

Étape 5 : Configurer le DNS

Trouvez l'IP du LoadBalancer d'ingress attribuée par Cloud Temple :

kubectl get svc -n scrydon-platform -l app.kubernetes.io/name=traefik \
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}'

Créez un enregistrement A (ou CNAME) faisant pointer app.example.com vers cette IP. Avec le mode de routage par chemin par défaut, un seul enregistrement couvre toutes les applications Scrydon — /cortex, /agentic, /analytics, /platform, /api/auth, /api/ontology, /api/table, /agentic/realtime, /marimo. Pour des noms d'hôte par application, voir Modes de routage.

Étape 6 : Exécuter l'assistant de configuration

Ouvrez https://app.example.com/platform/setup et complétez les cinq étapes — collez le bundle { jwt, publicKey }, créez le compte administrateur, nommez votre organisation, configurez l'e-mail (ou ignorez), terminez. Connectez-vous ensuite sur https://app.example.com/. Détails : Helm → Exécuter l'assistant de configuration.

Spécificités Cloud Temple

• Classe de stockage — Cloud Temple Managed Kubernetes fournit son propre provisionneur CSI ; choisissez la classe voulue via global.storageClass à l'étape 3 (kubectl get storageclass pour les lister).
• Base de données — le Postgres intégré fonctionne d'emblée ; ou pointez vers Cloud Temple Managed PostgreSQL via Base de données BYO. L'offre managée garde vos données opérationnelles à l'intérieur du périmètre qualifié de Cloud Temple.
• Stockage d'objets — le SeaweedFS intégré au chart fonctionne sans modification. Pour utiliser plutôt Cloud Temple Object Storage (compatible S3), configurez-le sous https://app.<domain>/settings/platform/storage après l'installation — la plateforme prend en charge n'importe quel endpoint S3 via le même écran Paramètres que sur les hyperscalers.
• Tables gérées (StarRocks) — le StarRocks intégré mono-pod fonctionne très bien. Pour une production multi-AZ, soit désactivez Tables (apiTable.enabled: false), soit exécutez le starrocks-kubernetes-operator dans un namespace séparé et pointez apiTable.starrocks.host vers lui. Cloud Temple ne propose aujourd'hui aucune offre StarRocks managée.
• Ingress derrière un load balancer externe — si un proxy L7 managé par Cloud Temple termine le TLS devant le cluster, gardez ingress.tls.enabled: true (afin que le schéma d'URL public, le CORS et les cookies sécurisés restent en HTTPS) et suivez Terminaison TLS déportée pour faire confiance à la plage d'adresses source du proxy.

Liste d'autorisation des flux sortants

Si votre cluster est soumis à une politique de sortie restrictive, autorisez les hôtes ci-dessous avant helm install. La liste est courte car le runtime du chart est autonome à l'intérieur du cluster — le trafic sortant se limite au pull de registre, à l'émission de certificats et aux fournisseurs LLM / STT / embedding que vous activez dans la plateforme.

Le registre d'images du chart est hébergé sur Azure ACR. Si contacter un endpoint hébergé sur Azure depuis l'intérieur de Cloud Temple n'est pas acceptable pour votre posture de souveraineté, basculez vers la voie de déploiement air-gapped — Zarf empaquette chaque image dans une archive unique que vous transférez via votre canal approuvé et déploie vers un registre intra-cluster sans aucun pull sortant.

Flux sortants par intégration. Chaque intégration de plateforme que vous activez (OpenAI, Anthropic, Mistral, Azure OpenAI, ElevenLabs, Resend, …) contacte son endpoint fournisseur directement depuis le cluster. Les hôtes dépendent entièrement des intégrations que vous configurez dans https://app.<domain>/settings/platform/integrations ; autorisez-les selon la documentation du fournisseur. L'installation Helm elle-même ne contacte aucun de ces endpoints — ce sont des dépendances d'exécution, pas d'installation.

Toutes les options

Tout ce qui dépasse cette voie minimale — modes de routage, StarRocks BYO, planification des pods, allègements pour installations à faibles ressources, plan de contrôle Dapr existant et opérations de jour 2 — se trouve dans la référence Helm.

Mises à jour

helm upgrade standard sur le même values.customer.yaml. Voir Mises à jour pour la politique d'écart de version et les notes de migration.

Dépannage

Pods bloqués en ImagePullBackOff

• Vérifiez que le secret de pull est dans le bon namespace : kubectl get secret scrydon-registry -n scrydon-platform
• Relancez helm registry login et recréez le secret si le jeton ACR a été renouvelé
• Vérifiez que la sortie vers scrydonops.azurecr.io est autorisée (voir Liste d'autorisation des flux sortants)

Certificats TLS non provisionnés

• Vérifiez que cert-manager est installé : kubectl get pods -n cert-manager
• Vérifiez l'état des certificats : kubectl get certificates -n scrydon-platform
• Confirmez que la sortie vers acme-v02.api.letsencrypt.org est autorisée

Assistant de configuration inaccessible

• Vérifiez que le DNS se résout : nslookup app.<domain>
• Vérifiez l'état des pods : kubectl get pods -n scrydon-platform
• Vérifiez que Traefik est sain et dispose d'une IP de LoadBalancer : kubectl get svc -n scrydon-platform -l app.kubernetes.io/name=traefik