On-Premise

Voici le chemin le plus rapide pour obtenir une installation Scrydon opérationnelle sur un cluster Kubernetes auto-géré pouvant récupérer des images via internet. Suivez les cinq étapes ci-dessous dans l'ordre. Pour chaque surcharge que le chart expose — routage, base de données BYO, TLS offloading, ordonnancement des pods, réductions pour ressources limitées — consultez la référence Helm.

Avant de commencer

• Un cluster Kubernetes 1.28+ avec un provisionneur de stockage opérationnel (Ceph, vSphere, local-path, …) et un accès kubectl.
• Un bundle de licence fourni par Scrydon — un fichier JSON de la forme { "jwt": "…", "publicKey": "-----BEGIN PUBLIC KEY-----…" }.
• Des identifiants de registre pour scrydonops.azurecr.io — un token délimité couvre à la fois le chart et les pulls d'images. Votre équipe vous fournit le nom du token ACR (le nom d'utilisateur) et la valeur du token (le mot de passe).
• Un nom DNS unique pointant vers l'ingress de votre cluster (ex. app.example.com).

Le dimensionnement complet des ressources et la liste de contrôle complète se trouvent dans Prérequis.

Étape 1 : Se connecter au registre

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

Étape 2 : Créer le namespace et le secret d'extraction

Par défaut, le chart déploie chaque service dans un seul namespace, scrydon-platform. Créez-le et ajoutez-y le secret d'extraction d'image :

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>

La séparation des services entre namespaces est optionnelle via namespaces.* (voir la référence Helm). Si vous le faites, créez le même secret d'extraction dans chaque namespace ciblé.

Étape 3 : Créer values.customer.yaml

Voici l'installation minimale complète — le chart utilise par défaut le routage par sous-chemin, la classe d'ingress traefik, un émetteur letsencrypt-prod et Postgres / StarRocks / SeaweedFS / OPA intégrés. La seule valeur spécifique à l'on-premise est global.storageClass : le chart n'a pas de valeur cloud par défaut, donc pointez vers votre provisionneur.

# Remplacez REPLACE-WITH-* par des valeurs générées. Ne placez pas ce fichier dans un dépôt de code source.

global:
  imageRegistry: scrydonops.azurecr.io  # récupérer les images depuis l'ACR connecté
  imagePullSecrets:
    - name: scrydon-registry            # depuis l'étape 2
  storageClass: <your-storage-class>    # ex. ceph-rbd, vsphere-csi, local-path

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 (false par défaut)

# Secrets — générer des valeurs fraîches par 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

Le chart déploie le Postgres intégré et chaque service Scrydon dans scrydon-platform, et exécute les Jobs de migration comme des hooks Helm.

Étape 5 : Lancer l'assistant de configuration

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

L'assistant, le format du bundle de licence et la vérification des pods/ingress/certificats sont entièrement documentés dans la référence Helm.

Spécificités on-premise

Voici les points où un cluster on-premise diffère d'un cloud managé :

• Classe de stockage — définir global.storageClass (étape 3) vers votre provisionneur. Il n'y a pas de valeur cloud par défaut.
• Ingress — il n'y a pas d'équilibreur de charge cloud ; exposez Traefik via NodePort, MetalLB ou votre propre équilibreur L4/L7. Voir Modes de routage.
• TLS — si un équilibreur de charge matériel ou de bordure termine le TLS devant le cluster, voir TLS Offloading.
• Base de données — le Postgres intégré fonctionne sans configuration supplémentaire ; pointez vers une instance externe via BYO Database.
• Pas d'internet sortant ? Si le cluster est totalement isolé, utilisez Déploiement Air-Gapped à la place — il livre les images via un bundle Zarf.

Toutes les options

Tout ce qui dépasse ce chemin minimal — routage en sous-domaine par application, préfixes de chemins personnalisés, un plan de contrôle Dapr existant, le verrouillage des identifiants StarRocks, réductions pour ressources limitées, ordonnancement des pods et opérations de jour 2 — se trouve dans la référence Helm.