Prérequis
Conditions requises avant de déployer la plateforme Scrydon
Cette page indique ce qui doit être prêt à chaque étape du déploiement. Le tableau ci-dessous sépare les bloqueurs d'installation, les défauts intégrés et la configuration après installation.
| Timing | Signification |
|---|---|
| Avant Helm | Requis avant que helm install puisse réussir. |
| Avant setup | Requis pour activer la plateforme installée dans /setup. |
| Inclus | Le chart fournit un défaut fonctionnel. Préparez un service externe uniquement si vous voulez le remplacer. |
| Avant usage | Pas nécessaire pour installer le chart, mais nécessaire avant que la capacité produit associée soit utile en production. |
1. Cluster Kubernetes
Vous apportez le cluster et la capacité. Scrydon ne peut rien installer tant que ces éléments ne sont pas en place.
| Domaine | Timing | Pourquoi c'est important |
|---|---|---|
| Kubernetes | Avant Helm | Le chart a besoin de Kubernetes 1.28+, Helm 3.14+ et des permissions pour créer workloads, services, ingress, configs et secrets. |
| Ressources | Avant Helm | La pile par défaut a besoin de CPU, mémoire, disque et marge de rollout suffisants pour planifier et démarrer les pods fiablement. |
2. Entrée réseau
Vous apportez la route que les utilisateurs empruntent vers le cluster. Scrydon peut rendre des objets Ingress, mais ne peut pas posséder votre zone DNS ou votre autorité de certification.
| Domaine | Timing | Pourquoi c'est important |
|---|---|---|
| DNS | Avant Helm | Le nom d'hôte public ou privé doit pointer vers l'ingress pour que le trafic navigateur et la validation ACME fonctionnent. |
| TLS | Avant Helm | Choisissez cert-manager, ACME interne, certificats BYO ou terminaison TLS en amont avant d'exposer la plateforme. |
3. Accès Scrydon
Ces éléments sont fournis par Scrydon, mais ils bloquent des moments différents.
| Domaine | Timing | Pourquoi c'est important |
|---|---|---|
| Registre | Avant Helm | Helm et Kubernetes ont besoin de l'identifiant ACR limité au client pour récupérer le chart et les images privés. |
| Licence | Avant setup | La plateforme installée a besoin du bundle { jwt, publicKey } avant que /setup puisse activer le déploiement. |
4. Défauts que vous pouvez accepter
Ce ne sont pas des prérequis sauf si vous choisissez de remplacer les défauts intégrés.
| Domaine | Timing | À décider |
|---|---|---|
| Dapr | Inclus | Utiliser le plan de contrôle Dapr intégré, ou pré-installer un plan de contrôle Dapr opéré séparément. |
| PostgreSQL | Inclus | Utiliser PostgreSQL 18 + pgvector intégré, ou pré-provisionner des bases Postgres gérées. |
5. Configurer avant usage réel
Ces éléments ne bloquent pas l'installation Helm. Ils comptent quand vous voulez que les utilisateurs exploitent vraiment le produit.
| Domaine | Timing | Pourquoi c'est important |
|---|---|---|
| Fournisseur d'IA | Avant usage | Les fonctionnalités IA n'ont aucun modèle à appeler tant qu'un admin d'organisation ne connecte pas un fournisseur hébergé ou auto-hébergé. |
| Messagerie | Avant usage | La vérification d'inscription, les invitations et les réinitialisations de mot de passe en production nécessitent l'e-mail transactionnel. Les installations d'évaluation peuvent l'ignorer. |
Ordre recommandé
- Préparez le Cluster Kubernetes et l'Entrée réseau.
- Obtenez l'identifiant Registre Scrydon.
- Décidez si vous acceptez les défauts Dapr et PostgreSQL intégrés.
- Exécutez le guide d'installation correspondant à votre emplacement.
- Utilisez le bundle Licence dans
/setup, puis configurez l'IA et l'e-mail avant d'intégrer des utilisateurs.
Étape suivante : choisissez où vous déployez — On-Premise, Azure ou Air-Gapped — ou allez directement à la référence Helm.