> 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-6-machines-virtuelles/02-recipes-marketplace.md). # Recettes et Marketplace ## Vue d'ensemble Configurer manuellement chaque machine virtuelle de zéro prend du temps et est source d'erreurs. VergeOS **recettes** résout ce problème en fournissant des modèles d'image dorée personnalisables qui standardisent le provisionnement des VM tout en permettant encore une personnalisation par instance. Associé au **catalogue Marketplace**, les recettes vous permettent de déployer des VM prêtes pour la production en quelques minutes -- des serveurs Ubuntu aux environnements d'évaluation Windows -- avec des configurations cohérentes à chaque fois. ```mermaid flowchart LR subgraph sources["Sources des recettes"] direction TB MP["Marketplace
(fourni par VergeOS)"] LOCAL["Catalogue local
(recettes personnalisées)"] REMOTE["Dépôt distant
(recettes partagées)"] end subgraph deploy["Déploiement"] direction TB Q["Répondez aux questions
(CPU, RAM, réseau, stockage)"] AUTO["Automatisation
(Base de données, Cloud-Init)"] VM["Instance de VM en cours d'exécution"] end sources --> Q --> AUTO --> VM ``` Une recette se compose de trois éléments : 1. **VM de base** -- Une machine virtuelle générique qui sert d'image dorée (modèle) 2. **Questions** -- Champs de saisie organisés en sections qui recueillent les valeurs de personnalisation par instance (cœurs, RAM, nom d'hôte, configuration réseau, identifiants) 3. **Automatisation** -- Opérations de base de données en arrière-plan et scripts cloud-init/Cloudbase-init qui configurent la VM au premier démarrage ## Le catalogue Marketplace Chaque système VergeOS est livré avec le **Marketplace** -- un dépôt distant fourni par VergeOS de recettes de VM préconstruites, prêtes à être utilisées immédiatement. Le Marketplace est automatiquement disponible à l'installation et ses catalogues sont définis sur `scope=global`, ce qui les rend également accessibles à tous les tenants. ### Accéder au Marketplace 1. Accédez à **Machines** > **Machines virtuelles** depuis le menu de gauche. 2. Cliquez sur **Nouveau**. 3. Dans le **Sélectionner le type** panneau de gauche, choisissez **Marketplace** (ou un catalogue spécifique comme "Operating Systems (Marketplace)" ou "Applications (Marketplace)"). 4. Sélectionnez une recette dans la liste et cliquez sur **Suivant** pour commencer à répondre aux questions. ### Recettes de systèmes d'exploitation disponibles Le Marketplace comprend des recettes pour un large éventail de systèmes d'exploitation : | Catégorie | Recettes disponibles | | -------------------- | ----------------------------------------------------------------------------------- | | **Ubuntu** | Serveur 18.04 (Bionic), 20.04 (Focal), 22.04 (Jammy), 24.04 (Noble) -- versions LTS | | **Compatibles RHEL** | Rocky Linux 8 & 9, AlmaLinux 8 & 9, CentOS 7, CentOS Stream 8 | | **Debian** | Debian 10 (Buster), 11 (Bullseye), 12 (Bookworm), 13 (Trixie) | | **Fedora** | Fedora 35, 36, 37, 38 | | **Amazon** | Amazon Linux 2 LTS | | **Windows** | Windows Server 2019 Évaluation, 2022 Évaluation, 2025 Évaluation | {% hint style="success" %} Les recettes Linux utilisent **cloud-init** avec des images cloud préconstruites téléchargées pendant le provisionnement. Les recettes Windows utilisent **Cloudbase-init** avec des ISO d'évaluation et une installation automatisée sans surveillance. Les deux approches produisent une VM entièrement configurée et amorçable sans installation manuelle du système d'exploitation. {% endhint %} ## Utiliser une recette Marketplace Le déploiement d'une VM à partir d'une recette Marketplace suit un flux guidé de questions-réponses. Voici un exemple typique avec une recette Ubuntu Server : ### Procédure pas à pas 1. **Accédez à** vers **Machines** > **Machines virtuelles** > **Nouveau**. 2. **Sélectionnez** la recette (par ex. « Ubuntu Server 24.04 (Noble Numbat) ») dans le catalogue Marketplace. 3. **Répondez aux questions** présentées dans chaque section : #### Paramètres de l'instance VM | Variable | Nom d'affichage | Description | | ---------------------- | ------------------------------------------------ | ------------------------------------- | | `YB_CPU_CORES` | Cœurs | Nombre de cœurs CPU virtuels | | `YB_RAM` | RAM | Allocation de mémoire (Mo) | | `YB_HOSTNAME` | Nom d’hôte | Nom d'hôte du système invité | | `SELECT_CREATE_UEFI` | Activer l'UEFI | Mode de démarrage UEFI (recommandé) | | `YB_DISABLE_CLOUDINIT` | Désactiver Cloud-init après le premier démarrage | Options : `true`, `false`, ou `purge` | #### Paramètres réseau | Variable | Nom d'affichage | Description | | ------------------------------ | ----------------------------- | ------------------------------------------------- | | `YB_IP_ADDR_TYPE` | Type d’adresse IP | `dhcp` ou `statique` | | `YB_NIC_ETH0_EXTERNAL_GATEWAY` | Réseau | Réseau cible pour l'interface réseau principale | | `YB_NIC_ETH0_IP_ADDR` | Adresse IP | Adresse IP statique (si statique est sélectionné) | | `YB_NIC_ETH0_CIDR` | CIDR du masque de sous-réseau | par ex., `/24` | | `YB_NIC_ETH0_GW` | Passerelle par défaut | Adresse IP de la passerelle | | `YB_NIC_ETH0_NS` | Serveurs de noms | Serveurs DNS séparés par des virgules | #### Paramètres de stockage | Variable | Nom d'affichage | Description | | ------------------ | --------------------------- | ------------------------------- | | `YB_DRIVE_OS_SIZE` | Taille du disque du système | Taille du disque en Go | | `SELECT_OS_TIER` | Niveau du disque du système | Niveau de stockage vSAN préféré | #### Compte utilisateur | Variable | Nom d'affichage | Description | | ------------- | ----------------- | ------------------------------- | | `YB_USER` | Nom d'utilisateur | Nom d'utilisateur admin initial | | `YB_PASSWORD` | Mot de passe | Mot de passe admin initial | 4. **Cliquez sur Envoyer** pour créer la VM. 5. L'automatisation de la recette s'exécute -- création des disques, téléchargement des images cloud, configuration des fichiers cloud-init et définition du type de machine. 6. **Mettez sous tension** la VM. Cloud-init s'exécute au premier démarrage pour appliquer votre configuration (nom d'hôte, utilisateurs, réseau, paquets). ## Questions et variables de la recette Les questions de recette sont les éléments de base qui rendent les recettes personnalisables. Chaque question capture une valeur stockée comme variable et pouvant être référencée dans des scripts cloud-init, des opérations de base de données ou la configuration de la VM. ### Champs de question | Champ | Rôle | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Section** | Regroupe les questions associées sur le formulaire de saisie (par ex. « Paramètres de l'instance », « Réseau ») | | **Nom** | Nom de variable référencé dans les scripts (alphanumérique uniquement, sans espaces) | | **Type** | Méthode de collecte des données ; les types courants incluent String, Number, Password, Boolean, List, Hidden, RAM, Disk Size, Network, Cluster, Database Create/Edit/Find, Hostname, Script, Textarea, Virtual IP, Timestamp, Row, Field et Seconds | | **ID d'ordre** | Ordre d'affichage dans la section | | **Affichage** | Libellé affiché à l'utilisateur sur le formulaire de saisie | | **Valeur par défaut** | Réponse préremplie | | **Validation par expression régulière** | Expression régulière pour valider la saisie | | **Texte d'espace réservé** | Texte d'indication grisé montrant le format attendu | | **Texte d'infobulle** | Aide contextuelle au survol | | **Texte de note** | Texte d'aide affiché sous le champ de saisie | | **Au changement** | JavaScript pour afficher/masquer dynamiquement d'autres questions | ### Questions générées automatiquement Lorsque vous créez une recette à partir d'une VM de base, VergeOS génère automatiquement des questions pour chacun des disques de la VM (par ex., `YB_DRIVE_1_SIZE`, `YB_DRIVE_2_SERIAL`, `YB_DRIVE_3_NONPERSISTENT`). Certaines questions générées automatiquement sont désactivées par défaut -- activez-les depuis la liste des questions si nécessaire. ## Automatisation de base de données Derrière chaque recette Marketplace, un ensemble de **questions de type base de données** (Database Create, Database Edit et Database Find) effectuent des opérations automatisées pendant le provisionnement de la VM. Ces questions interagissent directement avec l'API de base de données de VergeOS pour créer des ressources, télécharger des images et configurer le matériel -- sans aucune intervention manuelle de l'utilisateur. ### Opérations courantes de base de données | Variable | Opération | | ------------------------- | ----------------------------------------------------------------------------------- | | `CREATE_OS_DRIVE` | Crée le disque virtuel du système avec la taille et le niveau spécifiés | | `YB_DOWNLOAD_WINDOWS_ISO` | Télécharge l'ISO Windows à partir d'une URL spécifiée | | `YB_DOWNLOAD_VIRTIO` | Télécharge l'ISO du pilote VirtIO pour les invités Windows | | `YB_CREATE_VIRTIO_CD_DL` | Crée un CD-ROM virtuel et y attache l'ISO VirtIO | | `GET_CLUSTER_CPU` | Interroge le cluster pour obtenir les informations disponibles sur le modèle de CPU | | `CHANGE_CLUSTER_CPU` | Définit le type de CPU de la VM pour correspondre à celui du cluster | | `EDIT_MACHINE_TYPE` | Ajuste le type de machine de la VM (par ex., Q35) après la création | Ces opérations utilisent la même API REST disponible pour les administrateurs et les outils d'automatisation. Les auteurs de recettes peuvent ajouter des questions Database personnalisées pour automatiser toute opération exposée par l'API VergeOS -- création de réseaux, enregistrement d'entrées DNS, définition de règles de pare-feu, et plus encore. {% hint style="info" %} **Vous venez de VMware ou de Nutanix ?** Une recette VergeOS regroupe le modèle, le formulaire de personnalisation par instance et l'automatisation du provisionnement -- cloud-init/Cloudbase-init, création de disques, opérations API -- dans un seul package autonome, si bien qu'il n'est pas nécessaire d'assembler séparément des outils de modèle, de personnalisation, de gestion d'images et d'orchestration pour provisionner une VM. {% endhint %} ## Intégration Cloud-Init (Linux) VergeOS s'intègre avec **cloud-init**, l'outil standard du secteur pour personnaliser les VM Linux lors du premier démarrage. Les recettes s'appuient sur cloud-init pour appliquer le nom d'hôte, les comptes utilisateur, la configuration réseau, l'installation des paquets et des scripts personnalisés -- le tout piloté par les variables de questions de la recette. ### Fonctionnement 1. Le **source de données Cloud-init** de la VM est définie sur **Config Drive v2**. 2. VergeOS crée un disque virtuel contenant deux fichiers : * **`user_data`** -- Scripts et directives de configuration exécutés au premier démarrage * **`meta_data.json`** -- Métadonnées de l'instance (nom d'hôte, UUID, zone de disponibilité) 3. Les variables de question de recette sont substituées dans ces fichiers à l'aide d'une syntaxe de modèle. 4. Au premier démarrage, cloud-init lit le Config Drive et applique la configuration. {% hint style="info" %} Le **source de données Cloud-init** Le champ offre plus d'une option. Les recettes Marketplace utilisent **Config Drive v2** (la source de données cloud-init standard), mais VergeOS prend également en charge : * **Aucune** — Cloud-init désactivé pour la VM. * **NoCloud** — une source de données cloud-init standard destinée à configurer une VM **sans connexion réseau**. Les deux **Config Drive v2** et **NoCloud** fournissent les mêmes `user_data` / `métadonnées` fichiers au système invité ; choisissez **NoCloud** lorsque le système invité n'a pas de réseau au premier démarrage. {% endhint %} ### Variables de modèle Les variables de recette sont injectées dans les fichiers cloud-init à l'aide de la `${VARIABLE_NAME}` syntaxe : ```json { "availability_zone": "${YB_CLUSTER_NAME}", "name": "${YB_NAME}", "uuid": "${YB_UUID}", "hostname": "${YB_NAME}", "yb": ${$ALL_VARIABLES} } ``` Le `${$ALL_VARIABLES}` le jeton se développe pour inclure chaque variable de question sous forme d'objet JSON, rendant toutes les réponses de la recette disponibles pour les scripts cloud-init. La `${$...}` forme n'est pas une faute de frappe : le moteur de substitution recherche la `${...}` syntaxe standard, et `$ALL_VARIABLES` est un nom de variable spécial (avec un `$`) qui est reconnu par le moteur de rendu et remplacé par l'ensemble complet des variables. ### Formats des données utilisateur Le `user_data` le fichier prend en charge plusieurs formats de script, déterminés par la première ligne : | Format | Première ligne | Cas d'utilisation | | ----------------------- | --------------- | ------------------------------------------------------------------- | | **Cloud-config (YAML)** | `#cloud-config` | Configuration déclarative (utilisateurs, paquets, fichiers, runcmd) | | **Script shell** | `#!/bin/bash` | Commandes shell arbitraires | | **PowerShell** | `#ps1` | Scripts PowerShell (principalement pour Cloudbase-init sur Windows) | | **Batch** | `rem cmd` | Scripts batch Windows (Cloudbase-init) | Le répartiteur de première ligne ci-dessus correspond au comportement standard de cloud-init/Cloudbase-init, et non à une convention propre à VergeOS -- VergeOS se contente de fournir le `user_data` fichier via Config Drive v2 et laisse l'agent dans le système invité l'interpréter. #### Exemple : YAML Cloud-Config ```yaml #cloud-config hostname: ${YB_HOSTNAME} users: - name: ${YB_USER} sudo: ALL=(ALL) NOPASSWD:ALL shell: /bin/bash lock_passwd: false passwd: ${YB_PASSWORD_HASH} packages: - qemu-guest-agent - curl runcmd: - systemctl enable --now qemu-guest-agent ``` ### Images cloud en ligne Les recettes Linux peuvent télécharger directement des images cloud préconstruites depuis les miroirs de distribution. Cela est configuré via des questions cachées de la recette : * **`OS_DL_URL`** (type : Caché) -- Télécharge l'image et la met en cache localement (par ex., `https://cloud-images.ubuntu.com/releases/noble/release/ubuntu-24.04-server-cloudimg-amd64-disk-kvm.img`) * **`OS_URL`** (type : Caché) -- Diffuse l'image via le web sans mise en cache locale Ces images cloud sont préinstallées avec cloud-init, de sorte que la recette n'a besoin de fournir que les `user_data` et `meta_data.json` fichiers de personnalisation. ## Cloudbase-Init (Windows) Pour les VM Windows, VergeOS utilise **Cloudbase-init** -- l'équivalent Windows de cloud-init. Cloudbase-init lit la même source de données Config Drive v2 et exécute des scripts PowerShell ou batch au premier démarrage. ### Processus de configuration 1. Installez le [client Cloudbase-init](https://cloudbase.it/cloudbase-init/#download) dans la VM modèle Windows. 2. Générez le sysprep de la VM à l'aide des options unattend de Cloudbase-init. 3. Définissez le **source de données Cloud-init** vers **Config Drive v2**. 4. Créez des questions de recette pour les options spécifiques à Windows (clé de licence, RDP, pilotes VirtIO). ### Automatisation des recettes Windows Les recettes Windows Marketplace automatisent toute la chaîne de provisionnement : 1. Télécharger l'ISO d'évaluation Windows via une question Database 2. Télécharger l'ISO du pilote VirtIO 3. Créer des lecteurs CD-ROM virtuels et y attacher les deux ISO 4. Configurer le type de machine et les paramètres UEFI 5. Au premier démarrage, Cloudbase-init applique le nom d'hôte, les identifiants d'administration, les paramètres RDP et la configuration réseau {% hint style="warning" %} Après que cloud-init ou Cloudbase-init a terminé son travail, **supprimez les fichiers cloud-init** de la VM -- en particulier si des scripts contenaient des mots de passe ou d'autres informations sensibles. {% endhint %} ## Créer des recettes personnalisées Lorsque les recettes Marketplace ne répondent pas à vos besoins, vous pouvez créer des recettes personnalisées à partir de n'importe quelle VM existante. ### Flux de travail 1. **Construisez une VM de base** -- Installez le système d'exploitation, les applications et la configuration que vous souhaitez pour votre image dorée. Généralisez la VM (supprimez les données spécifiques à la machine, installez cloud-init ou Cloudbase-init). 2. **Créez la recette** -- Accédez à **Machines virtuelles** > **Nouvelle recette de VM**. * Si aucun catalogue local n'existe, vous serez invité à en créer un d'abord. 3. **Configurez les champs de la recette :** | Champ | Description | | ----------------------------------------------- | ---------------------------------------------------------------------------------------------- | | **Nom** | Nom descriptif de la recette | | **Description** | Documentation et consignes | | **Icône** | Icône Font Awesome pour l'identification visuelle | | **Catalogue** | Conteneur organisationnel pour la recette | | **Machine virtuelle** | La VM modèle de base | | **Version** | Commence à 1.0.0, s'incrémente automatiquement lors des modifications (1.0.0-1, 1.0.0-2, etc.) | | **Utiliser l'asset pour les noms de questions** | Nommer les questions de disque/NIC par numéro d'asset plutôt que par ordre | | **Dépendances de version** | Fonctionnalités VergeOS requises pour le fonctionnement de la recette | 4. **Définir les questions** -- Ajoutez des sections et des questions pour recueillir les saisies par instance. Configurez la validation, les valeurs par défaut, les infobulles et la logique conditionnelle d'affichage/masquage. 5. **Configurez les fichiers cloud-init** -- Rédigez `user_data` et `meta_data.json` des modèles faisant référence à vos variables de questions. 6. **Simulez la recette** -- Cliquez sur **Simuler la recette** depuis le tableau de bord de la recette pour tester le formulaire d’entrée, valider les champs et prévisualiser les fichiers de réponse générés. 7. **Publier** -- La recette devient disponible dans son catalogue pour créer de nouvelles VM. ### Modification et republication Lorsque vous modifiez une recette, elle doit être **republiée** pour que les modifications prennent effet. Le tableau de bord de la recette affiche une notification avec un lien de **Republier** . Après la republication, les systèmes distants et les locataires sont informés qu’une mise à jour est disponible. ### Instances de recette Une VM créée à partir d’une recette est une **instance** de cette recette jusqu’à ce qu’elle soit supprimée ou détachée. Vous pouvez afficher toutes les instances depuis le tableau de bord de la recette. Une recette ne peut pas être supprimée tant qu’elle a des instances associées. {% hint style="info" %} **Limites documentées** Un système VergeOS prend en charge jusqu’à **1 000 recettes** et **50 000 instances de recette** au total, avec jusqu’à **10 000 journaux de recette par recette** (nettoyés automatiquement à 100 et expirant après 7 jours). Ces plafonds sont bien au-dessus d’une utilisation typique, mais il est utile de les connaître si vous prévoyez un provisionnement à grande échelle piloté par des recettes. {% endhint %} ## Échange de recettes VergeOS prend en charge le partage de recettes entre systèmes et locataires grâce à une architecture de dépôt et de catalogue. ```mermaid flowchart TD REPO["Dépôt"] --> CAT1["Catalogue 1
(VM Linux)"] REPO --> CAT2["Catalogue 2
(VM Windows)"] REPO --> CAT3["Catalogue 3
(Applications)"] CAT1 --> R1["Recette Ubuntu"] CAT1 --> R2["Recette Rocky"] CAT2 --> R3["Recette Windows 2022"] CAT3 --> R4["Recette de base de données"] CAT3 --> R5["Recette de serveur Web"] ``` ### Partage avec les locataires 1. Définissez la **Portée de publication** vers **Locataire** (ou **Globale** pour un accès externe). 2. Dans l’interface du locataire, accédez au **fournisseur de services** dépôt et cliquez sur **Actualiser**. 3. Double-cliquez sur le catalogue pour parcourir les recettes. 4. Sélectionnez les recettes et cliquez sur **Télécharger/Mettre à jour** pour les rendre disponibles localement. ### Partage avec les systèmes distants 1. Créez un **utilisateur API** sur le système de partage avec les autorisations Liste et Lecture sur le catalogue. 2. Sur le système destinataire, créez un **dépôt distant** pointant vers l’URL du système de partage avec les identifiants de l’utilisateur API. 3. Cliquez sur **Actualiser** pour récupérer les listes du catalogue. Téléchargez les recettes pour une utilisation locale. ### Portées de publication | Portée | Visibilité | | ------------- | --------------------------------------------------------------------------- | | **Privé** | Uniquement le cloud VergeOS local | | **Aucune** | Désactivé -- non disponible nulle part | | **Locataire** | Le cloud local et ses locataires directs | | **Globale** | Le cloud local, les locataires et les systèmes distants (avec identifiants) | ## Bonnes pratiques ### Commencez avec Marketplace Utilisez les recettes Marketplace comme point de départ. Clonez-les dans un catalogue local et personnalisez-les plutôt que de les créer de zéro -- cela fait gagner du temps et garantit que vous héritez de configurations testées. ### Simulez avant de publier Simulez toujours une recette avant de la rendre disponible aux utilisateurs. Vérifiez que la validation des champs fonctionne, que la logique conditionnelle se comporte correctement et que les fichiers cloud-init générés contiennent les valeurs attendues. ### Versionnez vos recettes Utilisez des numéros de version significatifs et mettez-les à jour lors de changements importants. Les systèmes distants et les locataires sont informés des mises à jour, donc un versionnement clair aide à suivre ce qui a changé. ### Nettoyez les données sensibles Supprimez les fichiers cloud-init après le premier démarrage, surtout s’ils contiennent des mots de passe ou des identifiants. Envisagez d’utiliser l’ `YB_DISABLE_CLOUDINIT` option permettant de purger les données cloud-init après la configuration initiale. --- # 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-6-machines-virtuelles/02-recipes-marketplace.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.