Recettes de locataire

Automatiser le déploiement complet d’un VDC grâce à des modèles de recettes de locataire réutilisables, notamment les questions système, les questions personnalisées, l’échange de recettes et des exemples CSP concrets.

Qu'est-ce que les recettes de locataire ?

Les recettes de locataire transforment un locataire configuré manuellement en un modèle de déploiement réutilisable en un clic. Une seule recette de locataire peut automatiser la création d'un centre de données virtuel complet — y compris les paramètres du locataire, la configuration réseau, les règles de pare-feu, les machines virtuelles incluses, les identifiants aléatoires, l'enregistrement DNS/DHCP et les notifications par e-mail — le tout à partir d'une seule soumission de formulaire.

Là où l'assistant de locataire (couvert à la page précédente) vous guide à travers une configuration manuelle unique, les recettes codifient cette configuration afin qu'elle puisse être répétée des centaines de fois avec des personnalisations par instance.

Pourquoi utiliser des recettes de locataire ?

Déploiement rapide

Réduisez le provisionnement des locataires de plusieurs heures de configuration manuelle à quelques minutes de déploiement automatisé.

Cohérence et conformité

Chaque instance de locataire suit la même image de référence — le réseau, les règles de pare-feu, les VM et les politiques sont identiques.

Réduction des erreurs humaines

L'automatisation élimine les erreurs de configuration qui s'installent lors d'une configuration manuelle répétitive.

Activation du libre-service

Associées à l'API, les recettes alimentent des portails destinés aux clients où les utilisateurs finaux provisionnent leurs propres VDC.

Préparation du locataire de base

Chaque recette de locataire commence par un locataire de base qui sert de modèle. Ce locataire doit être :

1. Éteint — le système de recettes capture l'état du locataire, donc il ne doit pas être en cours d'exécution
2. Réservé à l'utilisation par les recettes — n'utilisez pas un locataire de production comme base. Si vous souhaitez baser une recette sur un locataire existant, clonez-le d'abord et supprimez les données spécifiques au client (mots de passe, noms d'utilisateur, fichiers client)
3. Entièrement configuré — incluez tous les réseaux, les VM, les règles de pare-feu, les paramètres DHCP/DNS et toute autre configuration qui doit apparaître dans chaque instance

Considérez le locataire de base comme une image de référence pour l'ensemble d'un centre de données, pas seulement pour une seule VM.

Création d'une recette de locataire

Processus étape par étape

1. Construisez et configurez le locataire de base avec tous les paramètres, réseaux et VM souhaités
2. Éteignez le locataire de base
3. Accédez à Référentiels > Recettes de locataire dans l’interface VergeOS
4. Cliquez sur Nouveau dans le menu de gauche
5. Configurez les champs de la recette (voir ci-dessous)
6. Cliquez sur Soumettre pour enregistrer — le tableau de bord de la recette s'ouvre pour la personnalisation des questions

Champs de la recette

Champ	Description	Remarques
Nom	Nom descriptif de la recette	Aide les utilisateurs à trouver la bonne recette lorsqu'il y en a plusieurs disponibles
Description	Documentation facultative pour la recette	Bon endroit pour les consignes d'utilisation, l'objectif prévu et les notes de conformité
Icône	Icône Font Awesome facultative	Identifiant visuel pour distinguer les types de recettes (par ex., fa-cloud, fa-database)
Catalogue	Le catalogue dans lequel stocker la recette	Doit être un catalogue dans un référentiel local — les recettes ne peuvent pas être créées directement dans des référentiels distants/Marketplace. Voir Échange de recettes ci-dessous
Tenant	Le locataire de base à utiliser comme modèle	Doit être éteint
Version	Numéro de version auto-incrémenté	Commence à 1.0.0, augmente à 1.0.0-1, 1.0.0-2, etc. Peut être défini manuellement sur 2.0.0 pour les changements majeurs
Conserver les certificats SSL	Copier les certificats SSL du locataire de base vers les instances	Activer lorsque le locataire de base possède des certificats préinstallés
Dépendances de version	Exigences relatives aux fonctionnalités de VergeOS	Empêche les systèmes distants d'utiliser une recette qu'ils ne peuvent pas prendre en charge

Questions de la recette

Les questions sont le cœur d'une recette de locataire. Elles capturent les saisies par instance de l'opérateur (ou de la base de données VergeOS) et injectent ces valeurs dans le nouveau locataire lors de la création.

Lorsque vous créez une recette de locataire, VergeOS génère automatiquement des questions système organisées en sections. De nombreuses questions système sont désactivées par défaut et doivent être explicitement activées si nécessaire. Les questions système ne peuvent pas être supprimées — seulement activées ou désactivées.

Champs de question

Chaque question — système ou personnalisée — est configurée avec ces champs :

Champ	Rôle
Section	Regroupe les questions sur le formulaire de saisie (certaines sont créées automatiquement, des sections personnalisées peuvent être ajoutées)
Nom	Nom de variable référencé dans les scripts — alphanumérique uniquement, sans espaces ni caractères spéciaux
Type	Comment les données sont collectées — champ de saisie utilisateur, recherche dans la base de données, valeur masquée, etc.
ID d'ordre	Ordre d'affichage dans la section
Affichage	Libellé affiché sur le formulaire de saisie utilisateur
Valeur par défaut	Réponse préremplie (facultatif)
Validation par expression régulière	Expression régulière pour la validation de la saisie (facultatif)
Texte d'espace réservé	Texte d'aide grisé indiquant le format de saisie attendu (facultatif)
Texte d'infobulle	Fenêtre contextuelle au survol avec texte d'aide (facultatif)
Texte de note	Texte d'aide affiché directement sous le champ de saisie (facultatif)
Au changement	JavaScript pour afficher/masquer d'autres questions en fonction de la valeur de ce champ (facultatif)

Référence des questions système

Les tableaux suivants documentent les questions système intégrées générées pour chaque recette de locataire.

Section du locataire

Identité principale du locataire, identifiants d'administration et configuration SSL :

Nom de variable	Libellé affiché	Type	Par défaut	Activé par défaut
YB_URL	URL	Chaîne	—	Oui
YB_DESCRIPTION	Description	Zone de texte	—	Oui
YB_USER_NAME	Utilisateur admin	Chaîne	admin	Oui
YB_USER_PASSWORD	Mot de passe	Mot de passe	—	Oui
YB_USER_EMAIL	E-mail	Chaîne	—	Non
YB_USER_CHANGE_PASSWORD	Exiger un changement de mot de passe	Booléen	false	Non
YB_EXPOSE_CLOUD_SNAPSHOTS	option Exposer les instantanés système	Booléen	true	Non
YB_HELP_URL	URL d'aide	Chaîne	par défaut	Non
YB_THEME_ACCESS	Accès aux thèmes	Liste	host_only	Oui
YB_SPECIFIED_THEME	Thème	Sélection de ligne	—	Oui
YB_CLUSTER	Cluster	Cluster	—	Non
YB_CERT_TYPE	Type de certificat SSL	Masqué	manuel	Non
YB_CERT_DOMAIN	Domaine du certificat SSL	Chaîne	—	Non
YB_CERT_PUBLIC	Certificat SSL public	Zone de texte	—	Non
YB_CERT_PRIVATE	Certificat SSL privé	Zone de texte	—	Non
YB_CERT_CHAIN	Chaîne de certificats SSL	Zone de texte	—	Non

Section des nœuds

Ressources de calcul allouées au(x) nœud(s) virtuel(s) du locataire :

Nom de variable	Libellé affiché	Type	Par défaut	Activé par défaut
YB_NODE_1_CPU_CORES	Cœurs du nœud 1	Nombre	8	Oui
YB_NODE_1_RAM	RAM du nœud 1	RAM	16384	Oui
YB_NODE_1_INSTANCES	Instances du nœud 1	Nombre	1	Non
YB_NODE_1_CLUSTER	Cluster du nœud 1	Cluster	—	Non
YB_NODE_1_CLUSTER_FAILOVER	Cluster de basculement du nœud 1	Cluster	—	Non

Section réseau

Adresses réseau pour l'interface utilisateur du locataire et la connectivité externe :

Nom de variable	Libellé affiché	Type	Par défaut	Activé par défaut
YB_NET_1_IP	Adresse IP de l'interface utilisateur	Adresse IP virtuelle	—	Oui
YB_NET_2_IP	Adresse IP	Adresse IP virtuelle	—	Oui

Voici les questions système par défaut dans VergeOS 26.1. Vous pouvez ajouter des questions personnalisées au-delà de celles-ci pour capturer des informations supplémentaires telles que des dates d'expiration, des noms d'hôte personnalisés ou d'autres valeurs spécifiques au locataire.

Questions personnalisées

Au-delà des questions système, vous pouvez ajouter des questions personnalisées pour capturer toute information supplémentaire requise par votre déploiement. Les questions personnalisées prennent en charge les mêmes types de champs que les questions système, ainsi que plusieurs types d'interaction avec la base de données (lecture/écriture sur n'importe quel objet VergeOS).

Types de questions courants

Type	Rôle	Exemple d'utilisation
Chaîne	Saisie de texte sur une ligne	Nom du client, nom d'hôte
Zone de texte	Saisie de texte sur plusieurs lignes	Notes, extraits de configuration
Mot de passe	Saisie masquée avec confirmation	Mots de passe de comptes de service
Nombre	Saisie numérique	Numéros de port, nombre d'instances
Booléen	Case à cocher (vrai/faux)	Activer/désactiver des fonctionnalités
Liste	Sélection dans une liste déroulante	Choisir parmi des options prédéfinies
Masqué	Non affiché sur le formulaire	Valeurs codées en dur pour les scripts
Réseau	Sélecteur de réseau	Choisir le réseau cible
Adresse IP virtuelle	Sélecteur d'adresse IP	Attribuer des IP spécifiques
RAM	Saisie de mémoire (en Mo)	Allocation de ressources supplémentaire
Cluster	Sélecteur de cluster	Cluster cible pour le placement

Types d'interaction avec la base de données

Ces types de questions avancés permettent aux recettes de lire et d'écrire dans la base de données VergeOS lors de la création du locataire — permettant des flux de travail d'automatisation tels que :

Type	Rôle	Exemple d'utilisation
Création en base de données	Créer un nouvel enregistrement dans la base de données VergeOS	Enregistrer une réservation DHCP, créer une entrée DNS
Modification en base de données	Modifier un enregistrement existant dans la base de données	Mettre à jour une configuration réseau, modifier un paramètre
Recherche en base de données	Rechercher des valeurs dans la base de données	Récupérer la prochaine IP disponible, trouver un ID de réseau

Chaque question de base de données inclut un Contexte de base de données champ qui détermine si l'opération cible la base de données du système parent ou celle du locataire nouvellement créé. Cette distinction est cruciale :

• Contexte parent : Enregistrer l'IP du locataire dans le DNS de l'hôte, créer une réservation DHCP sur le réseau hôte
• Contexte du locataire : Configurer les paramètres à l'intérieur du nouveau locataire lui-même

Les questions d'interaction avec la base de données font référence aux tables de l'API VergeOS. Consultez le Description des tables de l'API et Guide de l'API pour les noms de tables, les noms de champs et la syntaxe des filtres.

Modification et republication des recettes

Lorsque vous modifiez une recette (changez des questions, mettez à jour le locataire de base, ajustez les valeurs par défaut), les modifications sont pas immédiatement disponibles pour les utilisateurs. Vous devez republier la recette :

1. Apportez vos modifications sur le tableau de bord de la recette (modifiez les questions, mettez à jour les sections, etc.)
2. Une bannière apparaît en haut : "La recette doit être republiée pour que les modifications prennent effet"
3. Cliquez sur Republier (depuis le lien de la bannière ou le menu de gauche)
4. Le numéro de version s'incrémente automatiquement (par ex., 1.0.0-1 → 1.0.0-2)

Lorsqu'une recette est republiée, les systèmes distants et les locataires ayant accès reçoivent une notification indiquant qu'une mise à jour est disponible. Ils doivent télécharger explicitement la mise à jour pour utiliser la nouvelle version.

Instances de recette

Une instance est un locataire qui a été créé à partir d'une recette et reste associé à celle-ci. Vous pouvez voir toutes les instances depuis le tableau de bord de la recette en cliquant sur Instances dans le menu de gauche.

Règles clés pour les instances :

• Une recette ne peut pas être supprimée tant qu'elle a des instances associées
• Les instances peuvent être détachées de leur recette pour devenir des locataires autonomes
• Les locataires détachés perdent leur association à la recette mais conservent toute la configuration

Échange de recettes : partage entre systèmes

Les recettes sont organisées en référentiels et catalogues, formant une structure hiérarchique :

Types de référentiels

• Référentiels locaux : Les catalogues et les recettes créés et maintenus sur le système local. Chaque système VergeOS est livré avec un référentiel « Local » vide, prêt à l'emploi.
• Référentiels distants : Se connecter à des catalogues hébergés sur un système VergeOS distinct. Cela évite de maintenir les mêmes recettes à plusieurs endroits.
• Marketplace : Un référentiel distant fourni par VergeOS, préinstallé sur les systèmes au niveau de l'hôte, contenant des recettes de VM prêtes à l'emploi. Les catalogues Marketplace sont par défaut définis sur scope=global, ce qui les rend disponibles pour tous les locataires.

Périmètres de publication des catalogues

Portée	Disponibilité
Privé	Uniquement le système VergeOS local
Aucune	Désactivé — indisponible partout
Tenant	Système local et ses locataires directs
Globale	Système local, locataires et systèmes VergeOS externes (avec identifiants API)

Partage avec les locataires

1. Définissez le périmètre de publication du catalogue sur Tenant ou Globale
2. Dans l'interface utilisateur du locataire, accédez à fournisseur de services dépôt
3. Cliquez sur Actualiser pour découvrir les catalogues disponibles
4. Téléchargez les recettes souhaitées — l'état affiche En ligne lorsqu'il est prêt

Partage avec les systèmes distants

1. Créez un utilisateur de type API sur le système de partage avec des autorisations Liste/Lecture sur le catalogue cible
2. Sur le système destinataire, créez un Référentiel distant pointant vers l'URL du système de partage
3. Authentifiez-vous avec les identifiants de l'utilisateur API
4. Actualisez le référentiel pour découvrir et télécharger les catalogues et recettes disponibles

Lorsque les recettes sont mises à jour à la source, les locataires et les systèmes distants voient tous une notification indiquant qu'une mise à jour est disponible au téléchargement.

Exemple concret : offre de stockage compatible S3 pour CSP

Pour illustrer la puissance des recettes de locataire, considérez ce scénario tiré de la Architecture de référence VergeOS CSP:

CloudHoster, un fournisseur de cloud de taille moyenne, souhaite proposer à ses clients un service de stockage compatible S3 appelé « Cloud Storage ». Plutôt que de configurer manuellement l'environnement de chaque client, ils créent une recette de locataire qui automatise l'ensemble du déploiement :

Ce que la recette crée

1. Tenant — Un nouveau VDC avec les ressources de calcul et de stockage appropriées
2. Réseau interne — Réseau isolé pour la VM de l'application de stockage
3. Règles de pare-feu — Configuré pour autoriser le trafic API S3 tout en bloquant tout le reste
4. VM de stockage — La VM hébergeant l'application de stockage compatible S3, préconfigurée
5. Provisionnement du stockage — Niveau de stockage vSAN dédié alloué au locataire
6. Enregistrement DNS/DHCP — Enregistrement automatique sur le réseau hôte

Questions de recette pour ce cas d'utilisation

La recette demande à l'opérateur (ou au portail libre-service client) les informations suivantes :

• Nom du client et URL (section du locataire)
• Identifiants d'administration (générés automatiquement ou manuels)
• Capacité de stockage (question personnalisée — quantité de stockage S3 à provisionner)
• IP externe (section réseau — pour le point de terminaison de l'API S3)
• Ressources du nœud (section des nœuds — CPU/RAM pour la VM de stockage)

Avec une seule soumission de formulaire, CloudHoster déploie un environnement de stockage complet, isolé et compatible S3 pour son client — en quelques minutes plutôt qu'en quelques heures.

Mise à l'échelle de l'offre

CloudHoster déploie cette recette sur quatre de ses sites en partageant le catalogue via un référentiel distant. Lorsqu'ils mettent à jour la recette (par exemple, pour mettre à niveau la VM de l'application de stockage), tous les sites reçoivent une notification et peuvent récupérer la mise à jour.

Bonnes pratiques

Conception de recette

• Commencez simplement — créez d’abord un tenant de base minimal, ajoutez la complexité progressivement
• Utilisez des noms de variables descriptifs — STORAGE_CAPACITY_GB est mieux que T1 pour la maintenance des scripts
• Documentez vos recettes — utilisez le champ Description et le texte de note sur les questions pour guider les opérateurs
• Testez avec une simulation — validez les questions et les sorties avant de publier dans les catalogues de production

Maintenance du tenant de base

• Tenants de base dédiés — n’utilisez jamais le tenant de base d’une recette pour les charges de production
• Contrôle de version — définissez manuellement les numéros de version majeurs (par ex., 2.0.0) lors de modifications importantes du tenant de base
• Supprimez les données sensibles — assurez-vous qu’aucun mot de passe, donnée ou configuration spécifique au client n’existe dans la base

Organisation

• Noms de catalogues parlants — regroupez les recettes par objectif (par ex. « VDC standard », « Calcul GPU », « Services de stockage »)
• Utilisez des icônes — les icônes Font Awesome aident les opérateurs à identifier rapidement les types de recettes dans l’interface utilisateur
• Adaptez le périmètre — utilisez Private pour les recettes internes uniquement, Tenant pour celles destinées aux clients, Global pour une distribution multisite

Vous venez de VMware ou de Nutanix ?

Une recette de tenant VergeOS approvisionne un VDC isolé entier en une seule opération — interface de gestion, utilisateurs, pile réseau, règles de pare-feu, stockage et DNS/DHCP — et pas seulement des VM ou des applications. Pour connaître le périmètre et les capacités de tout outil d’automatisation VMware ou Nutanix auquel vous pourriez le comparer, consultez la documentation actuelle de ce fournisseur.