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 fichier 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 <version> \
  --namespace scrydon-platform \
  --host app.example.com \
  --storage-class <votre-storage-class> \
  --gateway-class traefik \
  --tls-issuer letsencrypt-prod \
  --license <chemin-vers-votre-licence.json> \
  --pull-secret <chemin-vers-votre-pull-secret>

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

--gateway-class désigne la GatewayClass sous laquelle la porte d'entrée de Scrydon est publiée. Sans elle, l'installateur prend la première GatewayClass du cluster, et s'arrête s'il n'y en a aucune : 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. Sur un cluster sans contrôleur Gateway API, passez plutôt --bundle-traefik : le chart installe Traefik, qui apporte les CRD et la GatewayClass traefik.

Avec --license, l'installateur contrôle le fichier de licence avant d'installer, comme le fait l'entretien, et le pré-renseigne pour que l'assistant de configuration l'affiche déjà vérifié.

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 GatewayClass 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.
• cert-manager avec sa prise en charge Gateway API activée, si vous voulez que le chart émette le certificat HTTPS — voir Prérequis TLS. Inutile si vous terminez TLS vous-même.
• Votre fichier de licence fourni par Scrydon — un JSON de la forme { "jwt": "…", "publicKey": "…" }. Voir Licences.
• 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. Gardez traefik.enabled: true, sauf si le cluster exécute déjà un contrôleur Gateway API : retirez-le alors et définissez gateway.className sur la classe de ce contrôleur.

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)

traefik:
  enabled: true                         # installe Traefik dans le namespace `traefik`, avec les CRD Gateway API

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 --wait-for-jobs

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 six étapes : collez votre fichier de licence, créez le compte administrateur, nommez votre organisation, reliez-la à un stockage objet (ou ignorez), configurez l'e-mail (ou ignorez) et terminez. Connectez-vous ensuite sur https://app.example.com/.

L'assistant, le format de la 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. Le Traefik du chart publie un Service LoadBalancer, scrydon-traefik dans le namespace traefik ; donnez-lui une adresse avec MetalLB, ou exposez-le via NodePort 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.
• Sources de données en flux et en push — désactivées tant que ingestBuffer.enabled n'est pas défini (les sources planifiées, poll, s'exécutent sans lui). Le tampon écrit chaque entrée acceptée sur disque : utilisez une classe de stockage qui respecte fsync. Les fournisseurs doivent être joignables à une adresse HTTPS publique ; les fournisseurs sur un réseau privé ne sont pas encore pris en charge. Détails : Helm → apiIngestion.
• Pas d'internet sortant ? Si le cluster est totalement isolé, utilisez Déploiement Air-Gapped à la place — il livre toutes les images dans un seul paquet 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.