Présentation du déploiement

Exécuter Zaris se résume à deux choix : quel modèle de déploiement possède les processus des nœuds, et quel environnement vous utilisez. Cette page explique les modèles, compare les environnements et renvoie vers un guide pas à pas pour chacun.

remarque

Zaris démarre avec un essai automatique de 30 jours sur chaque machine. L'usage en production est sous licence (par machine — une machine, un siège). Lorsque l'essai se termine, la console web se verrouille d'abord ; après une période de grâce, le produit cesse de servir jusqu'à ce qu'une licence soit activée, et rien n'est jamais supprimé. Consultez Support et licence et le Guide de licence et d'activation.

Les deux modèles de déploiement

Chaque cluster Zaris dispose d'un service de gestion (le plan de contrôle, avec la console web) et d'un ou plusieurs nœuds (le plan de données qui stocke vos données). Les modèles ne diffèrent que par qui possède les processus des nœuds.

Le manager résout son modèle une fois au démarrage à partir de la variable d'environnement ZARIS_MGMT_MODE. La valeur par défaut est supervisor.

Modèle supervisor

Dans le modèle supervisor, le service de gestion crée et possède les nœuds — il les forke, les démarre, les arrête, les redémarre et les met à l'échelle. Vous provisionnez des stores avec les cmdlets AdminShell ou la console web, et le manager génère les processus des nœuds localement. C'est le modèle pour les hôtes que vous gérez directement, tels que les services Windows et les VM. C'est aussi le foyer naturel des modes CA 0 à 2 signés par Clustron, car les nœuds s'enrôlent pour leurs certificats via le manager.

C'est le modèle par défaut ; définissez-le explicitement avec ZARIS_MGMT_MODE=supervisor.

Modèle attach

Dans le modèle attach, un orchestrateur externe — Docker, Docker Compose ou Kubernetes — exécute les processus des nœuds, et le service de gestion se contente de les observer tout en servant le plan de contrôle et la console. Le manager ne forke jamais un nœud ; vous enregistrez auprès de lui le store exécuté en externe (Register-ZrStore, ou l'API d'enregistrement). Comme un seul manager observe tout le cluster, la console et la CLI affichent une vue d'appartenance unique et cohérente. C'est le modèle pour les déploiements conteneurisés et orchestrés, et le foyer du mode CA 3 (feuilles pré-émises), où l'orchestrateur monte le certificat de chaque nœud.

Sélectionnez-le avec ZARIS_MGMT_MODE=attach. En mode attach, le manager refuse de créer ou de forker des stores — l'orchestrateur possède le cycle de vie des nœuds.

Les deux modèles s'associent naturellement avec un environnement et un mode de confiance, mais le modèle n'est qu'un réglage — vous n'êtes pas verrouillé.

	Supervisor	Attach
Qui exécute les nœuds	Service de gestion	Votre orchestrateur
Démarrage / arrêt / mise à l'échelle via	Cmdlets Zaris ou console	Votre orchestrateur
Certificats	Enrôlés (Clustron signe)	Montés (vous émettez)
Idéal pour	Hôtes Windows et VM que vous gérez	Docker, Compose et Kubernetes

Les environnements

Choisissez l'environnement qui correspond à l'endroit où vous exécutez, puis suivez son guide. Les environnements basés sur conteneurs utilisent tous la même image de nœud et le modèle attach.

Environnement	Modèle	Ce que vous obtenez	Quand l'utiliser
Installation Windows	Supervisor	Le service de gestion et la console web en tant que services Windows, les modules PowerShell et le runtime de nœud — depuis un seul package	Hôtes et VM que vous gérez directement ; le chemin le plus rapide vers un cluster fonctionnel avec une console
Conteneur Docker	Attach	Un cluster simple, non sécurisé, uniquement composé de nœuds, à partir d'une seule image et d'une configuration partagée	Développement local et évaluation ; un cluster léger et reproductible sur un seul hôte Docker
Docker Compose (sécurisé)	Attach	Un cluster multi-nœuds sécurisé avec un manager, un TLS mutuel et une authentification par token	Un cluster sécurisé sur un seul hôte ; tester le workflow de certificat monté en mode 3 avant Kubernetes
Kubernetes	Attach	Un chart Helm officiel : un StatefulSet avec identité stable, découverte headless, scale-out à chaud par kubectl, mises à jour progressives contrôlées par la readiness, un PodDisruptionBudget, des clients hors cluster et le TLS via des Secrets	Orchestrer un cluster auto-réparant avec un scale-out élastique et des mises à jour progressives sûres à travers un cluster de machines

Une note sur les ports

Un store en cours d'exécution expose un ensemble de ports restreint et prévisible, documenté sur la page Guide d'administration → Ports :

• API de gestion et console web — le plan de contrôle (par défaut 7801 et 7810).
• Port client du nœud — où les clients du plan de données se connectent (7861 dans les images de conteneur).
• Port de cluster du nœud — le trafic intra-cluster entre les nœuds (7811 dans les images de conteneur).

Quels que soient le modèle et l'environnement que vous choisissez, les clients se connectent toujours aux ports client des nœuds, et les administrateurs utilisent l'API de gestion et la console.

Étapes suivantes

• Exécuter sur un hôte Windows → Installation Windows.
• Exécuter un cluster simple en conteneurs → Conteneur Docker.
• Exécuter un cluster sécurisé avec Compose → Docker Compose (sécurisé).
• Orchestrer sur Kubernetes → Kubernetes.