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 l'installeur guidé ou les cinq étapes manuelles ci-dessous. 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.

Démarrage rapide

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

L'installeur demande la version souhaitée, l'environnement de déploiement, et les identifiants de registre ainsi que le bundle de licence fournis par votre équipe. Il vérifie votre cluster avant toute modification, puis installe et vérifie.

Vous préférez l'inspecter avant, ou avez besoin d'une copie figée ?

curl -fsSL https://get.scrydon.com -o setup.sh
curl -fsSL https://get.scrydon.com/setup.sh.sha256 | shasum -a 256 -c -
bash setup.sh

Si votre cluster n'est pas accessible depuis votre machine, lancez quand même l'installeur — il sauvegarde vos réponses et vous indique de copier trois fichiers (le fichier de valeurs, scrydon-install.conf et votre manifeste pull-secret) sur un hôte bastion qui peut atteindre le cluster, puis d'exécuter :

curl -fsSL https://get.scrydon.com | bash -s -- \
  --conf scrydon-install.conf --pull-secret <chemin-vers-votre-pull-secret>

Le manifeste pull-secret est le fichier fourni par votre équipe. Les identifiants de registre ne sont pas stockés dans le fichier conf (les identifiants ne transitent jamais dans le conf), ils doivent donc être fournis à nouveau sur le bastion.

Installations sans surveillance

Pour exécuter l'installateur sans aucune invite — en CI, ou depuis un outil de gestion de configuration — passez --non-interactive avec toutes les valeurs que l'entretien aurait demandées :

curl -fsSL https://get.scrydon.com | bash -s -- \
  --non-interactive \
  --context <votre-contexte-kubectl> \
  --version v1.3.23 \
  --namespace scrydon-platform \
  --host app.example.com \
  --storage-class <votre-storage-class> \
  --ingress-class traefik \
  --tls-issuer letsencrypt-prod \
  --pull-secret <chemin-vers-votre-pull-secret>

--non-interactive vaut également confirmation : l'installateur poursuit sans demander de validation finale.

--ingress-class désigne la classe de routage sous laquelle la porte d'entrée de Scrydon est publiée ; elle est requise lorsque l'installateur n'en détecte aucune sur le cluster. L'installateur refuse de deviner : une porte d'entrée publiée sous une classe qu'aucun contrôleur ne revendique laisse l'installation signaler un succès alors que la plateforme reste injoignable.

Les numéros de version sont les tags publiés du chart et comportent un v initial (v1.3.23, et non 1.3.23). Utilisez --list-versions pour connaître les versions installables.

Quel cluster ?

Avant toute chose, l'installateur demande dans quel contexte Kubernetes installer, en listant ceux que kubectl connaît et en proposant le contexte courant par défaut. Toutes les commandes suivantes sont épinglées à ce choix.

Cela existe parce que la cible était auparavant implicite : le contexte courant, quel qu'il soit, sans que rien ne l'indique. Utilisez --context <nom> pour y répondre à l'avance — et faites-le dans tout script, où personne n'est là pour répondre.

Les trois réponses qui déterminent l'accessibilité de Scrydon

L'installateur détecte une valeur par défaut pour chacune depuis votre cluster et vous montre ce qu'il a trouvé. Elles sont détaillées ici parce que chacune échoue d'une manière facile à manquer.

Le préflight vérifie les trois avant toute application : la classe de routage et le ClusterIssuer doivent exister sur le cluster, et la StorageClass doit exister. L'absence de cert-manager n'est une erreur que si vous avez nommé un émetteur ; un émetteur vide correspond au mode TLS géré par vos soins.

Après l'installation, l'installateur effectue une requête HTTP vers le nom d'hôte fourni. Si rien ne répond, il le signale clairement au lieu d'afficher une URL de configuration qui ne fonctionne pas.

Installation manuelle

Avant de commencer

• Un cluster Kubernetes 1.28+ avec un provisionneur de stockage opérationnel (Ceph, vSphere, local-path, …) et un accès kubectl.
• Une implémentation Gateway API — les CRD gateway.networking.k8s.io et une GatewayClass. Soit vous en exploitez déjà une et définissez gateway.className en conséquence, soit vous définissez traefik.enabled: true et laissez le chart installer une release Traefik qui fournit les deux. Voir Prérequis Kubernetes.
• Un bundle de licence fourni par Scrydon — un fichier JSON de la forme { "jwt": "…", "publicKey": "…" }.
• 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'équilibreur de charge en périphérie 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 GatewayClass 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.

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

gateway:
  tls:
    enabled: true                       # le navigateur accède à Scrydon via HTTPS (valeur par défaut)

Ces trois valeurs de secrets sont optionnelles. Sur un helm install en direct, le chart génère tous les secrets dont il a besoin et les préserve entre les mises à niveau. Définissez-les explicitement uniquement si vous gérez les secrets en externe, ou si vous effectuez un rendu sans cluster en direct (ArgoCD, helm template) — voir Rendu sans cluster en direct.

# Optionnel — uniquement nécessaire pour le rendu sans lookup ou la gestion externe des secrets.
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/gateway/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.
• La périphérie — il n'y a pas d'équilibreur de charge cloud ; exposez votre implémentation Gateway API (Traefik par défaut) via NodePort, MetalLB ou votre propre équilibreur L4/L7. N'oubliez pas que gateway.listenerPorts.* correspond à ce que le contrôleur écoute — les entryPoints de Traefik écoutent sur :8000/:8443 alors que son Service publie 80/443. Voir Modes de routage.
• TLS — choisissez Let's Encrypt, ACME interne ou certificats d'entreprise avec Certificats 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.