Operer le control plane.
NoryxLab est un control plane Kubernetes. Il enregistre des intentions et cree des objets Kubernetes standards ; vos identites, donnees et images restent dans vos systemes.
Ce que l'operateur administre
Une installation de production est une composition explicite : le cluster, le nom de domaine et le TLS, le fournisseur d'identite, le registre d'images, le stockage objet, la base de metadonnees et les politiques reseau. NoryxLab n'est pas le proprietaire de ces composants : il les relie et rend leur etat visible.
La base de la plateforme contient les metadonnees de controle : objets, droits, executions et evenements. Elle ne remplace ni le stockage objet des datasets, ni le registre des images, ni votre annuaire.
Architecture de reference
La console et les integrations appellent la meme API. Les workspaces, jobs, applications et services se retrouvent dans Kubernetes sous forme d'objets standards : les outils de diagnostic restent donc ceux de l'equipe d'exploitation.
Installer proprement
Le point d'entree est le guide CE pas a pas. Il part d'un cluster neuf, impose un rendu de manifeste prive sans valeurs de demonstration, configure Keycloak et termine par un smoke test puis un parcours utilisateur reel.
Preparer l'infrastructure
Fournissez un cluster avec une StorageClass par defaut, un endpoint S3 compatible, un registre que le cluster peut joindre, un nom de domaine et une terminaison TLS decidee clairement : proxy frontal ou Traefik.
Construire ou synchroniser les images
La production doit tirer les images depuis votre registre. Conservez les tags de version et les digests effectivement utilises par les workloads.
Appliquer les manifests
Les manifests Kubernetes sont dans le depot. Les overlays d'installation portent les decisions propres a l'environnement sans modifier le socle.
Configurer l'identite
Initialisez le realm et les clients OIDC, puis appliquez le hardening : politique de mot de passe, protection contre la force brute et auditoires des jetons.
Verifier le deploiement
Le smoke test de livraison doit valider la version servie, le TLS, la decouverte OIDC, l'API, les extensions et les taches de fond. Ne sautez pas cette etape sans raison explicite.
Identite, organisations et RBAC
Keycloak est la reference des comptes, des mots de passe et des organisations. NoryxLab consomme l'identite OIDC puis applique les droits sur les projets, datasets et catalogues. Une organisation permet d'attribuer un droit a un collectif sans devoir gerer chaque personne sur chaque objet.
- Les roles projet sont separes de l'administration de plateforme.
- Les droits de datasets et de catalogues peuvent etre attribues par utilisateur ou organisation.
- Les organisations sont requises pour simplifier la gouvernance et les droits collectifs.
- En Enterprise Edition, la matrice RBAC, les journaux d'audit avances et les fonctions de gouvernance sont des extensions distinctes du binaire Community.
Stockage, images et donnees
Le montage S3 direct evite de recopier un bucket dans le stockage ephemere d'un workspace. La plateforme ne transforme pas un dataset externe en copie non gouvernee.
Exploiter et observer
- Etat de sante : surveillez l'API, le fournisseur OIDC, le registre, les workers et la cible de sauvegarde.
- Workloads : un workspace est un pod, un job est un Job, une application est un Deployment. Les journaux Kubernetes restent la source de diagnostic.
- Capacite : publiez des hardware tiers et des quotas par projet ; la plateforme presente les limites utiles aux utilisateurs.
- Reseau : isolez le control plane des workloads et appliquez une politique d'egress explicite. Les profils de sortie controles relevent de l'Enterprise Edition.
- Mises a jour : deployez une version, lancez les smoke tests, puis observez le rollout et l'etat fonctionnel. Ne confondez pas pod Running et plateforme utilisable.
Securiser l'installation
Utilisez des comptes operateurs nominatifs et des cles SSH protegees par phrase de passe. N'autorisez pas les mots de passe SSH en production, limitez les comptes avec sudo, gardez les secrets hors des depots et stockez les credentials de reprise dans un coffre.
Un endpoint expose au public doit etre justifie par un usage. Les applications publiees ont leur propre politique d'acces ; les workspaces ne deviennent jamais partageables par simple transmission d'URL. La terminaison TLS, le pare-feu frontal et le routage des sous-domaines restent de la responsabilite de l'environnement.
Sauvegarder et restaurer
Une sauvegarde couvre les metadonnees de plateforme, les grants, les executions, l'audit et les elements necessaires a la reprise des identites et secrets selon le contrat de l'edition. Les datasets S3 ne sont pas implicitement copies : leur resilience doit etre fournie par le stockage objet ou une strategie de sauvegarde dediee.
Une sauvegarde n'est valable qu'apres un test de restauration. Le mode de restauration doit d'abord rapporter ce qui manque et ne rien ecrire par defaut sur une plateforme vivante.
Ne pas operer a partir d'une capture d'ecran.
Les commandes et les parametres varient avec la version. Utilisez les documents du commit deployee et gardez les procedures propres a l'environnement dans un depot prive d'exploitation.