> 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/de/modul-6-virtuelle-maschinen/02-recipes-marketplace.md). # Rezepte und der Marketplace ## Überblick Das manuelle Konfigurieren jeder virtuellen Maschine von Grund auf ist zeitaufwendig und fehleranfällig. VergeOS **Rezepte** löst dies durch anpassbare Golden-Image-Vorlagen, die die Bereitstellung von VMs standardisieren und dennoch eine Anpassung pro Instanz ermöglichen. Zusammen mit dem integrierten **Marketplace-Katalog**, ermöglichen es Rezepte, produktionsreife VMs in Minuten bereitzustellen -- von Ubuntu-Servern bis zu Windows-Evaluierungsumgebungen -- jedes Mal mit konsistenten Konfigurationen. ```mermaid flowchart LR subgraph sources["Rezeptequellen"] direction TB MP["Marketplace
(von VergeOS bereitgestellt)"] LOCAL["Lokaler Katalog
(Benutzerdefinierte Rezepte)"] REMOTE["Remote-Repository
(Geteilte Rezepte)"] end subgraph deploy["Bereitstellung"] direction TB Q["Fragen beantworten
(CPU, RAM, Netzwerk, Speicher)"] AUTO["Automatisierung
(Datenbank, Cloud-Init)"] VM["Laufende VM-Instanz"] end sources --> Q --> AUTO --> VM ``` Ein Rezept besteht aus drei Komponenten: 1. **Basis-VM** -- Eine generalisierte virtuelle Maschine, die als Golden Image (Vorlage) dient 2. **Fragen** -- Eingabefelder, in Abschnitte organisiert, die Anpassungswerte pro Instanz erfassen (Cores, RAM, Hostname, Netzwerkkonfiguration, Anmeldedaten) 3. **Automatisierung** -- Datenbankoperationen und Cloud-Init/Cloudbase-Init-Skripte im Hintergrund, die die VM beim ersten Start konfigurieren ## Der Marketplace-Katalog Jedes VergeOS-System wird mit dem **Marketplace** geliefert -- einem entfernten, von VergeOS bereitgestellten Repository vorgefertigter VM-Rezepte, die sofort einsatzbereit sind. Der Marketplace ist bei der Installation automatisch verfügbar, und seine Kataloge sind auf `scope=global`gesetzt, wodurch sie auch für alle Tenants zugänglich sind. ### Auf den Marketplace zugreifen 1. Navigieren Sie zu **Machines** > **Virtuelle Maschinen** aus dem linken Menü. 2. Klicken Sie auf **Neu**. 3. Im **Bereich „Typ auswählen“** links wählen Sie **Marketplace** (oder einen bestimmten Katalog wie "Betriebssysteme (Marketplace)" oder "Anwendungen (Marketplace)"). 4. Wählen Sie ein Rezept aus der Liste und klicken Sie auf **Weiter** um mit dem Beantworten der Fragen zu beginnen. ### Verfügbare Rezepte für Betriebssysteme Der Marketplace enthält Rezepte für eine breite Palette von Betriebssystemen: | Kategorie | Verfügbare Rezepte | | ------------------- | ----------------------------------------------------------------------------------- | | **Ubuntu** | Server 18.04 (Bionic), 20.04 (Focal), 22.04 (Jammy), 24.04 (Noble) -- LTS-Versionen | | **RHEL-kompatibel** | 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 Evaluation, 2022 Evaluation, 2025 Evaluation | {% hint style="success" %} Linux-Rezepte verwenden **cloud-init** mit vorab erstellten Cloud-Images, die während der Bereitstellung heruntergeladen werden. Windows-Rezepte verwenden **Cloudbase-init** mit Evaluierungs-ISOs und automatisiertem unbeaufsichtigtem Setup. Beide Ansätze erzeugen eine vollständig konfigurierte, bootfähige VM ohne manuelle Betriebssysteminstallation. {% endhint %} ## Ein Marketplace-Rezept verwenden Die Bereitstellung einer VM aus einem Marketplace-Rezept folgt einem geführten Frage-und-Antwort-Workflow. Hier ist ein typischer Ablauf anhand eines Ubuntu-Server-Rezepts: ### Schritt-für-Schritt-Durchlauf 1. **Navigieren Sie** in **Machines** > **Virtuelle Maschinen** > **Neu**. 2. **Wählen Sie** zu dem Rezept (z. B. "Ubuntu Server 24.04 (Noble Numbat)") im Marketplace-Katalog. 3. **Beantworten Sie die Fragen** die in jedem Abschnitt angezeigt werden: #### VM-Instanzeinstellungen | Variabel | Anzeigename | Beschreibung | | ---------------------- | --------------------------------------------- | --------------------------------------- | | `YB_CPU_CORES` | Kerne | Anzahl der virtuellen CPU-Kerne | | `YB_RAM` | RAM | Speicherzuweisung (MB) | | `YB_HOSTNAME` | Hostnamen | Hostname des Gastbetriebssystems | | `SELECT_CREATE_UEFI` | UEFI aktivieren | UEFI-Bootmodus (empfohlen) | | `YB_DISABLE_CLOUDINIT` | Cloud-init nach dem ersten Start deaktivieren | Optionen: `true`, `false`, oder `purge` | #### Netzwerkeinstellungen | Variabel | Anzeigename | Beschreibung | | ------------------------------ | ----------------- | --------------------------------------- | | `YB_IP_ADDR_TYPE` | IP-Adress-Typ | `dhcp` oder `statisch` | | `YB_NIC_ETH0_EXTERNAL_GATEWAY` | Netzwerk | Zielnetzwerk für die primäre NIC | | `YB_NIC_ETH0_IP_ADDR` | IP-Adresse | Statische IP (wenn statisch ausgewählt) | | `YB_NIC_ETH0_CIDR` | Subnetzmaske CIDR | z. B. `/24` | | `YB_NIC_ETH0_GW` | Standardgateway | Gateway-IP-Adresse | | `YB_NIC_ETH0_NS` | Nameserver | Durch Kommas getrennte DNS-Server | #### Speichereinstellungen | Variabel | Anzeigename | Beschreibung | | ------------------ | ---------------------- | ----------------------------- | | `YB_DRIVE_OS_SIZE` | Größe des OS-Laufwerks | Festplattengröße in GB | | `SELECT_OS_TIER` | Tier des OS-Laufwerks | Bevorzugte vSAN-Speicherebene | #### Benutzerkonto | Variabel | Anzeigename | Beschreibung | | ------------- | ------------ | ---------------------------- | | `YB_USER` | Benutzername | Initialer Admin-Benutzername | | `YB_PASSWORD` | Passwort | Initiales Admin-Passwort | 4. **Klicken Sie auf Senden** um die VM zu erstellen. 5. Die Rezeptautomatisierung wird ausgeführt -- sie erstellt Laufwerke, lädt Cloud-Images herunter, konfiguriert Cloud-Init-Dateien und legt den Maschinentyp fest. 6. **Starten Sie** die VM. Cloud-init wird beim ersten Start ausgeführt, um Ihre Konfiguration anzuwenden (Hostname, Benutzer, Netzwerk, Pakete). ## Rezeptfragen und Variablen Rezeptfragen sind die Bausteine, die Rezepte anpassbar machen. Jede Frage erfasst einen Wert, der als Variable gespeichert wird und in Cloud-Init-Skripten, Datenbankoperationen oder der VM-Konfiguration referenziert werden kann. ### Fragefelder | Feld | Zweck | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Abschnitt** | Gruppiert verwandte Fragen im Eingabeformular (z. B. "Instanzeinstellungen", "Netzwerk") | | **Namen** | In Skripten referenzierter Variablenname (nur alphanumerisch, keine Leerzeichen) | | **Typ** | Wie Daten erfasst werden; gängige Typen sind String, Number, Password, Boolean, List, Hidden, RAM, Disk Size, Network, Cluster, Database Create/Edit/Find, Hostname, Script, Textarea, Virtual IP, Timestamp, Row, Field und Seconds | | **Reihenfolge-ID** | Anzeigereihenfolge innerhalb des Abschnitts | | **Anzeige** | Dem Benutzer im Eingabeformular angezeigte Bezeichnung | | **Standardwert** | Vorausgefüllte Antwort | | **Regex-Validierung** | Regulärer Ausdruck zur Validierung der Eingabe | | **Platzhaltertext** | Grau dargestellter Hinweistext, der das erwartete Format zeigt | | **Tooltip-Text** | Popup-Hilfe beim Darüberfahren | | **Hinweistexte** | Hilfetext, der unter dem Eingabefeld angezeigt wird | | **Bei Änderung** | JavaScript, um andere Fragen dynamisch ein- oder auszublenden | ### Automatisch generierte Fragen Wenn Sie ein Rezept aus einer Basis-VM erstellen, generiert VergeOS automatisch Fragen für jedes Laufwerk der VM (z. B. `YB_DRIVE_1_SIZE`, `YB_DRIVE_2_SERIAL`, `YB_DRIVE_3_NONPERSISTENT`). Einige automatisch generierte Fragen sind standardmäßig deaktiviert -- aktivieren Sie sie bei Bedarf in der Fragenliste. ## Datenbankautomatisierung Hinter jedem Marketplace-Rezept steht eine Reihe von **Datenbanktyp-Fragen** (Database Create, Database Edit und Database Find), die während der VM-Bereitstellung automatisierte Vorgänge ausführen. Diese Fragen interagieren direkt mit der VergeOS-Datenbank-API, um Ressourcen zu erstellen, Images herunterzuladen und Hardware zu konfigurieren -- ohne jegliches manuelles Eingreifen durch den Benutzer. ### Häufige Datenbankoperationen | Variabel | Operation | | ------------------------- | ------------------------------------------------------------------------ | | `CREATE_OS_DRIVE` | Erstellt die OS-virtuelle Festplatte mit der angegebenen Größe und Ebene | | `YB_DOWNLOAD_WINDOWS_ISO` | Lädt das Windows-ISO von einer angegebenen URL herunter | | `YB_DOWNLOAD_VIRTIO` | Lädt das VirtIO-Treiber-ISO für Windows-Gäste herunter | | `YB_CREATE_VIRTIO_CD_DL` | Erstellt ein virtuelles CD-ROM-Laufwerk und hängt das VirtIO-ISO an | | `GET_CLUSTER_CPU` | Fragt den Cluster nach verfügbaren Informationen zum CPU-Modell ab | | `CHANGE_CLUSTER_CPU` | Setzt den CPU-Typ der VM passend zum Cluster | | `EDIT_MACHINE_TYPE` | Passt den Maschinentyp der VM (z. B. Q35) nach der Erstellung an | Diese Operationen verwenden dieselbe REST-API, die Administratoren und Automatisierungstools zur Verfügung steht. Rezeptautoren können benutzerdefinierte Datenbankfragen hinzufügen, um jede von der VergeOS-API bereitgestellte Operation zu automatisieren -- Netzwerke erstellen, DNS-Einträge registrieren, Firewall-Regeln festlegen und mehr. {% hint style="info" %} **Kommen Sie von VMware oder Nutanix?** Ein VergeOS-Rezept bündelt die Vorlage, das Anpassungsformular pro Instanz und die Bereitstellungsautomatisierung -- Cloud-Init/Cloudbase-Init, Laufwerkserstellung, API-Operationen -- in einem eigenständigen Paket, sodass Sie keine separaten Werkzeuge für Vorlagen, Anpassung, Image-Verwaltung und Orchestrierung zusammenfügen müssen, um eine VM bereitzustellen. {% endhint %} ## Cloud-Init-Integration (Linux) VergeOS integriert sich mit **cloud-init**dem branchenüblichen Tool zur Anpassung von Linux-VMs beim ersten Start. Rezepte nutzen Cloud-Init, um Hostname, Benutzerkonten, Netzwerkkonfiguration, Paketinstallation und benutzerdefinierte Skripte anzuwenden -- alles gesteuert durch die Rezept-Fragenvariablen. ### Funktionsweise 1. Das **Cloud-init-Datasource** der VM ist festgelegt auf **Config Drive v2**. 2. VergeOS erstellt ein virtuelles Laufwerk, das zwei Dateien enthält: * **`user_data`** -- Skripte und Konfigurationsanweisungen, die beim ersten Start ausgeführt werden * **`meta_data.json`** -- Instanzmetadaten (Hostname, UUID, Verfügbarkeitszone) 3. Rezept-Variablen werden mithilfe von Vorlagensyntax in diese Dateien eingefügt. 4. Beim ersten Start liest cloud-init das Config Drive und wendet die Konfiguration an. {% hint style="info" %} Das **Cloud-init-Datasource** Feld bietet mehr als eine Option. Marketplace-Rezepte verwenden **Config Drive v2** (die standardmäßige cloud-init-Datasource), aber VergeOS unterstützt auch: * **Keine** — Cloud-init für die VM deaktiviert. * **NoCloud** — eine standardmäßige cloud-init-Datasource, die für die Konfiguration einer VM **ohne Netzwerkverbindung**. Beide **Config Drive v2** und **NoCloud** liefern dieselben `user_data` / `meta_data` Dateien an den Gast; wählen Sie **NoCloud** wenn der Gast beim ersten Start kein Netzwerk hat. {% endhint %} ### Vorlagenvariablen Rezeptvariablen werden mithilfe der `${VARIABLE_NAME}` Syntax in Cloud-Init-Dateien eingefügt: ```json { "availability_zone": "${YB_CLUSTER_NAME}", "name": "${YB_NAME}", "uuid": "${YB_UUID}", "hostname": "${YB_NAME}", "yb": ${$ALL_VARIABLES} } ``` Das `${$ALL_VARIABLES}` Token erweitert sich so, dass jede Fragenvariable als JSON-Objekt enthalten ist, wodurch alle Rezeptantworten für Cloud-Init-Skripte verfügbar werden. Das `${$...}` Formular ist kein Tippfehler: Die Ersetzungs-Engine sucht nach der standardmäßigen `${...}` Syntax, und `$ALL_VARIABLES` ist ein spezieller Variablenname (mit einem literalen führenden `$`)“, den der Renderer erkennt und durch den vollständigen Variablensatz ersetzt. ### Formate für Benutzerdaten Das `user_data` Datei unterstützt mehrere Skriptformate, bestimmt durch die erste Zeile: | Format | Erste Zeile | Anwendungsfall | | ----------------------- | --------------- | ------------------------------------------------------------------- | | **Cloud-Config (YAML)** | `#cloud-config` | Deklarative Konfiguration (Benutzer, Pakete, Dateien, runcmd) | | **Shell-Skript** | `#!/bin/bash` | Beliebige Shell-Befehle | | **PowerShell** | `#ps1` | PowerShell-Skripte (hauptsächlich für Cloudbase-init unter Windows) | | **Batch** | `rem cmd` | Windows-Batch-Skripte (Cloudbase-init) | Das oben beschriebene Dispatcher-Verhalten der ersten Zeile ist standardmäßiges cloud-init/Cloudbase-init-Verhalten und keine VergeOS-spezifische Konvention -- VergeOS liefert lediglich die `user_data` Datei über Config Drive v2 aus und überlässt dem Agenten im Gast die Interpretation. #### Beispiel: Cloud-Config YAML ```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 ``` ### Online-Cloud-Images Linux-Rezepte können vorgefertigte Cloud-Images direkt von den Distribution-Spiegeln herunterladen. Dies wird über versteckte Rezeptfragen konfiguriert: * **`OS_DL_URL`** (Typ: Hidden) -- Lädt das Image herunter und cached es lokal (z. B. `https://cloud-images.ubuntu.com/releases/noble/release/ubuntu-24.04-server-cloudimg-amd64-disk-kvm.img`) * **`OS_URL`** (Typ: Hidden) -- Streamt das Image über das Web ohne lokalen Cache Diese Cloud-Images werden bereits mit cloud-init vorinstalliert geliefert, sodass das Rezept nur die `user_data` und `meta_data.json` Dateien zur Anpassung bereitstellen muss. ## Cloudbase-Init (Windows) Für Windows-VMs verwendet VergeOS **Cloudbase-init** -- das Windows-Äquivalent von cloud-init. Cloudbase-init liest dieselbe Config-Drive-v2-Datasource und führt beim ersten Start PowerShell- oder Batch-Skripte aus. ### Einrichtungsprozess 1. Installieren Sie den [Cloudbase-init-Client](https://cloudbase.it/cloudbase-init/#download) in der Windows-Vorlagen-VM. 2. Führen Sie Sysprep auf der VM mit den Cloudbase-init-Unattend-Optionen aus. 3. Setzen Sie das **Cloud-init-Datasource** in **Config Drive v2**. 4. Erstellen Sie Rezeptfragen für Windows-spezifische Optionen (Lizenzschlüssel, RDP, VirtIO-Treiber). ### Windows-Rezeptautomatisierung Windows-Marketplace-Rezepte automatisieren die gesamte Bereitstellungskette: 1. Laden Sie das Windows-Evaluierungs-ISO über eine Datenbankfrage herunter 2. Laden Sie das VirtIO-Treiber-ISO herunter 3. Erstellen Sie virtuelle CD-ROM-Laufwerke und hängen Sie beide ISOs an 4. Konfigurieren Sie den Maschinentyp und die UEFI-Einstellungen 5. Beim ersten Start wendet Cloudbase-init Hostname, Admin-Anmeldedaten, RDP-Einstellungen und Netzwerkkonfiguration an {% hint style="warning" %} Nachdem cloud-init oder Cloudbase-init seine Arbeit abgeschlossen hat, **entfernen Sie die Cloud-init-Dateien** aus der VM -- insbesondere wenn Skripte Passwörter oder andere sensible Informationen enthielten. {% endhint %} ## Benutzerdefinierte Rezepte erstellen Wenn Marketplace-Rezepte Ihre Anforderungen nicht erfüllen, können Sie benutzerdefinierte Rezepte aus jeder vorhandenen VM erstellen. ### Ablauf 1. **Erstellen Sie eine Basis-VM** -- Installieren Sie das Betriebssystem, die Anwendungen und die Konfiguration, die Sie als Golden Image möchten. Generalisieren Sie die VM (entfernen Sie maschinenspezifische Daten, installieren Sie cloud-init oder Cloudbase-init). 2. **Erstellen Sie das Rezept** -- Navigieren Sie zu **Virtuelle Maschinen** > **Neue VM-Rezept**. * Wenn kein lokaler Katalog vorhanden ist, werden Sie aufgefordert, zuerst einen zu erstellen. 3. **Rezeptfelder konfigurieren:** | Feld | Beschreibung | | --------------------------------- | ------------------------------------------------------------------------------------- | | **Namen** | Beschreibender Name für das Rezept | | **Beschreibung** | Dokumentation und Richtlinien | | **Symbol** | Font-Awesome-Symbol zur visuellen Identifikation | | **Katalog** | Organisatorischer Container für das Rezept | | **Virtuelle Maschine** | Die Basisvorlagen-VM | | **Version** | Beginnt bei 1.0.0, wird bei Änderungen automatisch erhöht (1.0.0-1, 1.0.0-2 usw.) | | **Asset für Fragnamen verwenden** | Benennen Sie Laufwerks-/NIC-Fragen anhand der Asset-Nummer statt nach der Reihenfolge | | **Versionsabhängigkeiten** | Für das Rezept erforderliche VergeOS-Funktionen | 4. **Fragen definieren** -- Fügen Sie Abschnitte und Fragen hinzu, um Eingaben pro Instanz zu erfassen. Konfigurieren Sie Validierung, Standardwerte, Tooltips und bedingte Ein-/Ausblendlogik. 5. **Cloud-Init-Dateien konfigurieren** -- Schreiben Sie `user_data` und `meta_data.json` Vorlagen, die auf Ihre Fragevariablen verweisen. 6. **Simulieren Sie das Rezept** -- Klicken Sie auf **Rezept simulieren** vom Rezept-Dashboard aus, um das Eingabeformular zu testen, Felder zu validieren und eine Vorschau der generierten Antwortdateien anzuzeigen. 7. **Veröffentlichen** -- Das Rezept wird in seinem Katalog für die Erstellung neuer VMs verfügbar. ### Ändern und erneut veröffentlichen Wenn Sie ein Rezept ändern, muss es **neu veröffentlicht werden** damit die Änderungen wirksam werden. Das Rezept-Dashboard zeigt eine Benachrichtigung mit einem **Erneut veröffentlichen** Link an. Nach der erneuten Veröffentlichung werden entfernte Systeme und Mandanten darüber benachrichtigt, dass ein Update verfügbar ist. ### Rezeptinstanzen Eine VM, die aus einem Rezept erstellt wurde, ist eine **Instanz** dieses Rezepts, bis sie gelöscht oder getrennt wird. Sie können alle Instanzen im Rezept-Dashboard anzeigen. Ein Rezept kann nicht gelöscht werden, solange zugehörige Instanzen vorhanden sind. {% hint style="info" %} **Dokumentierte Grenzen** Ein VergeOS-System unterstützt bis zu **1.000 Rezepte** und **50.000 Rezeptinstanzen** insgesamt, mit bis zu **10.000 Rezeptprotokollen pro Rezept** (werden automatisch bei 100 bereinigt und laufen nach 7 Tagen ab). Diese Obergrenzen liegen deutlich über dem typischen Bedarf, sind aber nützlich zu wissen, wenn Sie eine groß angelegte, rezeptgesteuerte Bereitstellung planen. {% endhint %} ## Rezeptaustausch VergeOS unterstützt das Teilen von Rezepten zwischen Systemen und Mandanten über eine Repository- und Katalogarchitektur. ```mermaid flowchart TD REPO["Repository"] --> CAT1["Katalog 1
(Linux-VMs)"] REPO --> CAT2["Katalog 2
(Windows-VMs)"] REPO --> CAT3["Katalog 3
(Anwendungen)"] CAT1 --> R1["Ubuntu-Rezept"] CAT1 --> R2["Rocky-Rezept"] CAT2 --> R3["Win-2022-Rezept"] CAT3 --> R4["Datenbank-Rezept"] CAT3 --> R5["Webserver-Rezept"] ``` ### Freigabe für Mandanten 1. Setzen Sie die **Veröffentlichungsreichweite** in **Mandant** (oder **Global** für den externen Zugriff). 2. Navigieren Sie in der Mandantenoberfläche zum **Service-Provider** Repository und klicken Sie auf **Aktualisieren**. 3. Doppelklicken Sie auf den Katalog, um die Rezepte zu durchsuchen. 4. Wählen Sie Rezepte aus und klicken Sie auf **Herunterladen/Aktualisieren** um sie lokal verfügbar zu machen. ### Freigabe für entfernte Systeme 1. Erstellen Sie einen **API-Benutzer** auf dem freigebenden System mit Listen- und Leseberechtigungen für den Katalog. 2. Erstellen Sie auf dem empfangenden System ein **entferntes Repository** das auf die URL des freigebenden Systems mit den Anmeldedaten des API-Benutzers verweist. 3. Klicken Sie auf **Aktualisieren** um Katalogeinträge abzurufen. Laden Sie Rezepte für die lokale Verwendung herunter. ### Veröffentlichungsbereiche | Bereich | Sichtbarkeit | | ----------- | ---------------------------------------------------------------- | | **Privat** | Nur die lokale VergeOS-Cloud | | **Keine** | Deaktiviert -- nirgends verfügbar | | **Mandant** | Lokale Cloud und ihre direkten Mandanten | | **Global** | Lokale Cloud, Mandanten und entfernte Systeme (mit Anmeldedaten) | ## Best Practices ### Mit dem Marketplace beginnen Verwenden Sie Marketplace-Rezepte als Ausgangspunkt. Klonen Sie sie in einen lokalen Katalog und passen Sie sie an, statt von Grund auf neu zu erstellen -- das spart Zeit und stellt sicher, dass Sie getestete Konfigurationen übernehmen. ### Vor dem Veröffentlichen simulieren Simulieren Sie ein Rezept immer, bevor Sie es für Benutzer verfügbar machen. Stellen Sie sicher, dass die Feldvalidierung funktioniert, die bedingte Logik korrekt arbeitet und die generierten cloud-init-Dateien die erwarteten Werte enthalten. ### Versionieren Sie Ihre Rezepte Verwenden Sie aussagekräftige Versionsnummern und aktualisieren Sie sie bei wesentlichen Änderungen. Entfernte Systeme und Mandanten werden über Updates benachrichtigt, daher hilft eine klare Versionierung dabei, nachzuverfolgen, was sich geändert hat. ### Sensible Daten bereinigen Entfernen Sie cloud-init-Dateien nach dem ersten Start, insbesondere wenn sie Passwörter oder Anmeldedaten enthalten. Erwägen Sie die Verwendung der `YB_DISABLE_CLOUDINIT` Option, um cloud-init-Daten nach der Erstkonfiguration zu löschen. --- # 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/de/modul-6-virtuelle-maschinen/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.