> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/fr/module-7-multi-tenant/03-tenant-recipes.md).
# Recettes de tenant
## 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.
```mermaid
flowchart LR
BASE["Locataire de base
(éteint)"] --> RECIPE["Recette de locataire
+ Questions"]
RECIPE --> I1["Instance de locataire A"]
RECIPE --> I2["Instance de locataire B"]
RECIPE --> I3["Instance de locataire C"]
style BASE fill:#fff3e0,stroke:#e65100
style RECIPE fill:#e8f5e9,stroke:#2e7d32
style I1 fill:#e3f2fd,stroke:#1565c0
style I2 fill:#e3f2fd,stroke:#1565c0
style I3 fill:#e3f2fd,stroke:#1565c0
```
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](#recipe-exchange-sharing-between-systems) 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 |
{% hint style="success" %}
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.
{% endhint %}
## 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
{% hint style="info" %}
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](https://docs.verge.io/knowledge-base/api-tables-description) et [Guide de l'API](https://docs.verge.io/knowledge-base/verge-api-guide) pour les noms de tables, les noms de champs et la syntaxe des filtres.
{% endhint %}
## 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 :
```mermaid
graph TD
R["Référentiel"] --> C1["Catalogue A
(locataires Windows)"]
R --> C2["Catalogue B
(locataires Linux)"]
R --> C3["Catalogue C
(services de stockage)"]
C1 --> TR1["Recette de locataire 1"]
C1 --> TR2["Recette de locataire 2"]
C2 --> TR3["Recette de locataire 3"]
C3 --> TR4["Recette de locataire 4"]
style R fill:#e8eaf6,stroke:#283593
style C1 fill:#e3f2fd,stroke:#1565c0
style C2 fill:#e3f2fd,stroke:#1565c0
style C3 fill:#e3f2fd,stroke:#1565c0
```
### 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](https://docs.verge.io/reference-architecture/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
{% hint style="info" %}
**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.
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.verge.io/learn-the-platform/fr/module-7-multi-tenant/03-tenant-recipes.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.