> 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-7-multi-tenancy/03-tenant-recipes.md). # Tenant-Rezepte ## Was sind Mandantenrezepte? Mandantenrezepte verwandeln einen manuell konfigurierten Mandanten in eine **wiederverwendbare Bereitstellungsvorlage mit einem Klick**. Ein einziges Mandantenrezept kann die Erstellung eines vollständigen Virtual Data Center automatisieren — einschließlich Mandanteneinstellungen, Netzwerkkonfiguration, Firewall-Regeln, enthaltenen virtuellen Maschinen, zufällig generierten Zugangsdaten, DNS/DHCP-Registrierung und E-Mail-Benachrichtigungen — alles mit einer einzigen Formularübermittlung. ```mermaid flowchart LR BASE["Basis-Mandant
(ausgeschaltet)"] --> RECIPE["Mandantenrezept
+ Fragen"] RECIPE --> I1["Mandanteninstanz A"] RECIPE --> I2["Mandanteninstanz B"] RECIPE --> I3["Mandanteninstanz 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 ``` Während der Mandanten-Assistent (auf der vorherigen Seite behandelt) Sie durch eine einmalige manuelle Konfiguration führt, **kodifizieren** diese Konfiguration, sodass sie mit individuellen Anpassungen pro Instanz Hunderte Male wiederholt werden kann. ### Warum Mandantenrezepte verwenden? ### Schnelle Bereitstellung Reduzieren Sie die Mandantenbereitstellung von stundenlanger manueller Konfiguration auf Minuten automatisierter Bereitstellung. ### Konsistenz und Compliance Jede Mandanteninstanz folgt derselben Golden-Image-Basis — Netzwerke, Firewall-Regeln, VMs und Richtlinien sind identisch. ### Weniger menschliche Fehler Automatisierung beseitigt Fehlkonfigurationen, die sich bei wiederholter manueller Einrichtung einschleichen. ### Self-Service-Ermöglichung In Verbindung mit der API ermöglichen Rezepte kundenorientierte Portale, in denen Endbenutzer ihre eigenen VDCs bereitstellen. ## Den Basis-Mandanten vorbereiten Jedes Mandantenrezept beginnt mit einem **Basis-Mandanten** als Vorlage. Dieser Mandant muss: 1. **Ausgeschaltet** — das Rezeptsystem erfasst den Zustand des Mandanten, daher darf er nicht laufen 2. **Für die Rezeptnutzung vorgesehen** — verwenden Sie keinen Produktionsmandanten als Basis. Wenn Sie ein Rezept auf einen bestehenden Mandanten stützen möchten, klonen Sie ihn zuerst und entfernen Sie kundenspezifische Daten (Kennwörter, Benutzernamen, Kundendateien) 3. **Vollständig konfiguriert** — fügen Sie alle Netzwerke, VMs, Firewall-Regeln, DHCP-/DNS-Einstellungen und jede andere Konfiguration hinzu, die in jeder Instanz vorhanden sein soll Betrachten Sie den Basis-Mandanten als ein **Golden Image** für ein gesamtes Rechenzentrum, nicht nur für eine einzelne VM. ## Ein Mandantenrezept erstellen ### Schritt-für-Schritt-Vorgehen 1. Erstellen und konfigurieren Sie den Basis-Mandanten mit allen gewünschten Einstellungen, Netzwerken und VMs 2. Den Basis-Mandanten ausschalten 3. Navigieren Sie zu **Repositories > Mandantenrezepte** in der VergeOS-UI 4. Klicken Sie auf **Neu** im linken Menü 5. Die Rezeptfelder konfigurieren (siehe unten) 6. Klicken Sie auf **Senden** zum Speichern — das Rezept-Dashboard öffnet sich zur Anpassung der Fragen ### Rezeptfelder | Feld | Beschreibung | Hinweise | | ------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Namen** | Beschreibender Name für das Rezept | Hilft Benutzern, das richtige Rezept zu finden, wenn mehrere verfügbar sind | | **Beschreibung** | Optionale Dokumentation für das Rezept | Guter Ort für Nutzungshinweise, Verwendungszweck und Compliance-Hinweise | | **Symbol** | Optionales Font-Awesome-Symbol | Visuelle Kennung, um Rezepttypen zu unterscheiden (z. B. `fa-cloud`, `fa-database`) | | **Katalog** | Der Katalog, in dem das Rezept gespeichert werden soll | Muss ein Katalog in einem lokalen Repository sein — Rezepte können nicht direkt in Remote-/Marketplace-Repositories erstellt werden. Siehe [Rezeptaustausch](#recipe-exchange-sharing-between-systems) unten | | **Mandant** | Der Basis-Mandant, der als Vorlage verwendet werden soll | Muss ausgeschaltet sein | | **Version** | Automatisch hochzählende Versionsnummer | Beginnt bei `1.0.0`, erhöht sich auf `1.0.0-1`, `1.0.0-2`, usw. Kann manuell auf `2.0.0` für größere Änderungen | | **SSL-Zertifikate beibehalten** | SSL-Zertifikate vom Basis-Mandanten auf Instanzen kopieren | Aktivieren, wenn der Basis-Mandant vorinstallierte Zertifikate hat | | **Versionsabhängigkeiten** | VergeOS-Funktionsanforderungen | Verhindert, dass Remotesysteme ein Rezept verwenden, das sie nicht unterstützen können | ## Rezeptfragen Fragen sind das Herzstück eines Mandantenrezepts. Sie erfassen pro Instanz Eingaben vom Betreiber (oder aus der VergeOS-Datenbank) und fügen diese Werte während der Erstellung in den neuen Mandanten ein. Wenn Sie ein Mandantenrezept erstellen, generiert VergeOS **automatisch Systemfragen** in Abschnitte organisiert. Viele Systemfragen sind standardmäßig deaktiviert und müssen bei Bedarf ausdrücklich aktiviert werden. Systemfragen können nicht gelöscht werden — nur aktiviert oder deaktiviert. ### Fragefelder Jede Frage — system- oder benutzerdefiniert — wird mit diesen Feldern konfiguriert: | Feld | Zweck | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Abschnitt** | Gruppiert Fragen im Eingabeformular (einige werden automatisch erstellt, benutzerdefinierte Abschnitte können hinzugefügt werden) | | **Namen** | In Skripten referenzierter Variablenname — nur alphanumerisch, keine Leerzeichen oder Sonderzeichen | | **Typ** | Wie Daten erfasst werden — Eingabefeld, Datenbanksuche, versteckter Wert usw. | | **Reihenfolge-ID** | Anzeigereihenfolge innerhalb des Abschnitts | | **Anzeige** | Auf dem Benutzer-Eingabeformular angezeigte Bezeichnung | | **Standardwert** | Vorausgefüllte Antwort (optional) | | **Regex-Validierung** | Regulärer Ausdruck zur Eingabevalidierung (optional) | | **Platzhaltertext** | Grau hinterlegter Hilfetext, der das erwartete Eingabeformat anzeigt (optional) | | **Tooltip-Text** | Popup beim Überfahren mit dem Mauszeiger mit Hilfetext (optional) | | **Hinweistexte** | Hilfetext, der direkt unter dem Eingabefeld angezeigt wird (optional) | | **Bei Änderung** | JavaScript, um andere Fragen auf Basis des Werts dieses Felds ein- oder auszublenden (optional) | ### Referenz der Systemfragen Die folgenden Tabellen dokumentieren die integrierten Systemfragen, die für jedes Mandantenrezept generiert werden. #### Mandantenabschnitt Zentrale Mandantenidentität, Admin-Zugangsdaten und SSL-Konfiguration: | Variablenname | Anzeigebezeichnung | Typ | Standard | Standardmäßig aktiviert | | --------------------------- | --------------------------- | ------------- | ----------- | ----------------------- | | `YB_URL` | URL | Zeichenkette | — | Ja | | `YB_DESCRIPTION` | Beschreibung | Textbereich | — | Ja | | `YB_USER_NAME` | Admin-Benutzer | Zeichenkette | `admin` | Ja | | `YB_USER_PASSWORD` | Passwort | Passwort | — | Ja | | `YB_USER_EMAIL` | E-Mail | Zeichenkette | — | Nein | | `YB_USER_CHANGE_PASSWORD` | Passwortänderung erzwingen | Boolesch | `false` | Nein | | `YB_EXPOSE_CLOUD_SNAPSHOTS` | System-Snapshots freigeben | Boolesch | `true` | Nein | | `YB_HELP_URL` | Hilfe-URL | Zeichenkette | `standard` | Nein | | `YB_THEME_ACCESS` | Themenzugriff | Liste | `host_only` | Ja | | `YB_SPECIFIED_THEME` | Design | Zeilenauswahl | — | Ja | | `YB_CLUSTER` | Cluster | Cluster | — | Nein | | `YB_CERT_TYPE` | SSL-Zertifikattyp | Versteckt | `manual` | Nein | | `YB_CERT_DOMAIN` | SSL-Zertifikatsdomäne | Zeichenkette | — | Nein | | `YB_CERT_PUBLIC` | Öffentliches SSL-Zertifikat | Textbereich | — | Nein | | `YB_CERT_PRIVATE` | Privates SSL-Zertifikat | Textbereich | — | Nein | | `YB_CERT_CHAIN` | SSL-Zertifikatskette | Textbereich | — | Nein | #### Knotenabschnitt Dem/den virtuellen Knoten des Mandanten zugewiesene Rechenressourcen: | Variablenname | Anzeigebezeichnung | Typ | Standard | Standardmäßig aktiviert | | ---------------------------- | ----------------------------- | ------- | -------- | ----------------------- | | `YB_NODE_1_CPU_CORES` | Kerne von Knoten 1 | Zahl | `8` | Ja | | `YB_NODE_1_RAM` | RAM von Knoten 1 | RAM | `16384` | Ja | | `YB_NODE_1_INSTANCES` | Instanzen von Knoten 1 | Zahl | `1` | Nein | | `YB_NODE_1_CLUSTER` | Cluster von Knoten 1 | Cluster | — | Nein | | `YB_NODE_1_CLUSTER_FAILOVER` | Failover-Cluster von Knoten 1 | Cluster | — | Nein | #### Netzwerkabschnitt Netzwerkadressen für die UI des Mandanten und die externe Konnektivität: | Variablenname | Anzeigebezeichnung | Typ | Standard | Standardmäßig aktiviert | | ------------- | ------------------ | -------------------- | -------- | ----------------------- | | `YB_NET_1_IP` | UI-IP-Adresse | Virtuelle IP-Adresse | — | Ja | | `YB_NET_2_IP` | IP-Adresse | Virtuelle IP-Adresse | — | Ja | {% hint style="success" %} Dies sind die standardmäßigen Systemfragen in VergeOS 26.1. Sie können darüber hinaus benutzerdefinierte Fragen hinzufügen, um zusätzliche Eingaben wie Ablaufdaten, benutzerdefinierte Hostnamen oder andere mandantenspezifische Werte zu erfassen. {% endhint %} ## Benutzerdefinierte Fragen Über die Systemfragen hinaus können Sie **benutzerdefinierte Fragen** hinzufügen, um zusätzliche Eingaben zu erfassen, die Ihre Bereitstellung erfordert. Benutzerdefinierte Fragen unterstützen dieselben Feldtypen wie Systemfragen sowie mehrere Datenbank-Interaktionstypen (Lesen/Schreiben auf jedes VergeOS-Objekt). ### Gängige Fragetypen | Typ | Zweck | Beispielverwendung | | ------------------------ | --------------------------------- | ---------------------------------- | | **Zeichenkette** | Einzeilige Texteingabe | Kundenname, Hostname | | **Textbereich** | Mehrzeilige Texteingabe | Notizen, Konfigurationsausschnitte | | **Passwort** | Maskierte Eingabe mit Bestätigung | Passwörter für Dienstkonten | | **Zahl** | Numerische Eingabe | Portnummern, Instanzanzahlen | | **Boolesch** | Kontrollkästchen (wahr/falsch) | Funktionen aktivieren/deaktivieren | | **Liste** | Dropdown-Auswahl | Aus vordefinierten Optionen wählen | | **Versteckt** | Nicht im Formular angezeigt | Fest kodierte Werte für Skripte | | **Netzwerk** | Netzwerkauswahl | Zielnetzwerk wählen | | **Virtuelle IP-Adresse** | IP-Adressauswahl | Bestimmte IPs zuweisen | | **RAM** | Speichereingabe (in MB) | Zusätzliche Ressourcenzuweisung | | **Cluster** | Cluster-Auswahl | Ziel-Cluster für die Platzierung | ### Datenbank-Interaktionstypen Diese erweiterten Fragetypen ermöglichen es Rezepten, **aus der VergeOS-Datenbank zu lesen und in sie zu schreiben** während der Mandantenerstellung — und ermöglichen so Automatisierungs-Workflows wie: | Typ | Zweck | Beispielverwendung | | ------------------------ | -------------------------------------------------------- | ----------------------------------------------------------------- | | **Datenbank erstellen** | Einen neuen Datensatz in der VergeOS-Datenbank erstellen | Eine DHCP-Reservierung registrieren, einen DNS-Eintrag erstellen | | **Datenbank bearbeiten** | Einen vorhandenen Datenbankdatensatz ändern | Eine Netzwerkkonfiguration aktualisieren, eine Einstellung ändern | | **Datenbank suchen** | Werte aus der Datenbank nachschlagen | Die nächste verfügbare IP abrufen, eine Netzwerk-ID finden | Jede Datenbankfrage enthält ein **Datenbankkontext** Feld, das festlegt, ob die Operation die Datenbank des **übergeordneten Systems** oder die **neu erstellte Datenbank des Mandanten**anspricht. Diese Unterscheidung ist entscheidend: * **Übergeordneter Kontext:** Die IP des Mandanten im DNS des Hosts registrieren, eine DHCP-Reservierung im Hostnetzwerk erstellen * **Mandantenkontext:** Einstellungen innerhalb des neuen Mandanten selbst konfigurieren {% hint style="info" %} Fragen zur Datenbankinteraktion verweisen auf die VergeOS-API-Tabellen. Konsultieren Sie die [Beschreibung der API-Tabellen](https://docs.verge.io/knowledge-base/api-tables-description) und [API-Leitfaden](https://docs.verge.io/knowledge-base/verge-api-guide) für Tabellennamen, Feldnamen und Filtersyntax. {% endhint %} ## Rezepten ändern und erneut veröffentlichen Wenn Sie ein Rezept ändern (Fragen anpassen, den Basis-Mandanten aktualisieren, Standardwerte anpassen), sind die Änderungen **nicht sofort verfügbar** für Benutzer. Sie müssen das Rezept **erneut veröffentlichen** : 1. Nehmen Sie Ihre Änderungen im Rezept-Dashboard vor (Fragen bearbeiten, Abschnitte aktualisieren usw.) 2. Oben erscheint ein Banner: *„Das Rezept muss erneut veröffentlicht werden, damit Änderungen wirksam werden“* 3. Klicken Sie auf **Erneut veröffentlichen** (über den Banner-Link oder das linke Menü) 4. Die Versionsnummer erhöht sich automatisch (z. B. `1.0.0-1` → `1.0.0-2`) Wenn ein Rezept erneut veröffentlicht wird, **erhalten entfernte Systeme und Mandanten mit Zugriff** eine Benachrichtigung, dass ein Update zum Download verfügbar ist. Sie müssen das Update ausdrücklich herunterladen, um die neue Version zu verwenden. ### Rezeptinstanzen Ein **Instanz** ist ein Mandant, der aus einem Rezept erstellt wurde und weiterhin mit diesem verbunden bleibt. Sie können alle Instanzen im Rezept-Dashboard anzeigen, indem Sie auf **Instanzen** im linken Menü klicken. Wichtige Regeln für Instanzen: * Ein Rezept **kann nicht gelöscht werden** solange es zugeordnete Instanzen hat * Instanzen können **getrennt** werden, um eigenständige Mandanten zu werden * Getrennte Mandanten verlieren ihre Rezeptzuordnung, behalten jedoch die gesamte Konfiguration ## Rezeptaustausch: Teilen zwischen Systemen Rezepte sind in **Repositories** und **Katalogen**organisiert und bilden eine hierarchische Struktur: ```mermaid graph TD R["Repository"] --> C1["Katalog A
(Windows-Mandanten)"] R --> C2["Katalog B
(Linux-Mandanten)"] R --> C3["Katalog C
(Speicherdienste)"] C1 --> TR1["Mandantenrezept 1"] C1 --> TR2["Mandantenrezept 2"] C2 --> TR3["Mandantenrezept 3"] C3 --> TR4["Mandantenrezept 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 ``` ### Repository-Typen * **Lokale Repositories:** Kataloge und Rezepte, die auf dem lokalen System erstellt und gepflegt werden. Jedes VergeOS-System wird mit einem leeren „Local“-Repository ausgeliefert, das sofort einsatzbereit ist. * **Remote-Repositories:** Stellen Sie Verbindungen zu Katalogen her, die auf einem separaten VergeOS-System gehostet werden. Dadurch entfällt die Pflege derselben Rezepte an mehreren Orten. * **Marketplace:** Ein von VergeOS bereitgestelltes Remote-Repository, das auf Systemen auf Host-Ebene vorinstalliert ist und sofort verwendbare VM-Rezepte enthält. Marketplace-Kataloge sind standardmäßig `scope=global`, wodurch sie allen Mandanten zur Verfügung stehen. ### Veröffentlichungsbereiche für Kataloge | Umfang | Verfügbarkeit | | ----------- | ---------------------------------------------------------------------------- | | **Privat** | Nur das lokale VergeOS-System | | **Keine** | Deaktiviert — nirgendwo verfügbar | | **Mandant** | Lokales System und seine direkten Mandanten | | **Global** | Lokales System, Mandanten und externe VergeOS-Systeme (mit API-Zugangsdaten) | ### Freigabe für Mandanten 1. Legen Sie den Veröffentlichungsbereich des Katalogs fest auf **Mandant** oder **Global** 2. Navigieren Sie in der UI des Mandanten zu **Service-Provider** Repository 3. Klicken Sie auf **Aktualisieren** um verfügbare Kataloge zu entdecken 4. Laden Sie die gewünschten Rezepte herunter — der Status zeigt *Online* wenn bereit ### Freigabe für entfernte Systeme 1. Erstellen Sie einen **API-Benutzer** auf dem freigebenden System mit List-/Read-Berechtigungen für den Zielkatalog 2. Erstellen Sie auf dem empfangenden System ein **Remote-Repository** das auf die URL des freigebenden Systems verweist 3. Authentifizieren Sie sich mit den API-Benutzeranmeldedaten 4. Aktualisieren Sie das Repository, um verfügbare Kataloge und Rezepte zu entdecken und herunterzuladen Wenn Rezepte an der Quelle aktualisiert werden, erhalten sowohl Mandanten als auch Remotesysteme eine Benachrichtigung, dass ein Update zum Download verfügbar ist. ## Praxisbeispiel: S3-kompatibles Speicherangebot eines CSP Um die Leistungsfähigkeit von Mandantenrezepten zu veranschaulichen, betrachten Sie dieses Szenario aus der [VergeOS CSP-Referenzarchitektur](https://docs.verge.io/reference-architecture/csp/): **CloudHoster**, ein mittelgroßer Cloud-Anbieter, möchte seinen Kunden einen S3-kompatiblen Speicherdienst namens „Cloud Storage“ anbieten. Statt die Umgebung jedes Kunden manuell zu konfigurieren, erstellen sie ein Mandantenrezept, das die gesamte Bereitstellung automatisiert: ### Was das Rezept erstellt 1. **Mandant** — Ein neues VDC mit geeigneten Rechen- und Speicherressourcen 2. **Internes Netzwerk** — Isoliertes Netzwerk für die Speicher-Anwendungs-VM 3. **Firewall-Regeln** — Konfiguriert, um S3-API-Verkehr zuzulassen und alles andere zu blockieren 4. **Speicher-VM** — Die VM, die die S3-kompatible Speicheranwendung hostet, vorkonfiguriert 5. **Speicherbereitstellung** — Dedizierte vSAN-Speicherebene, dem Mandanten zugewiesen 6. **DNS/DHCP-Registrierung** — Automatische Registrierung im Hostnetzwerk ### Rezeptfragen für diesen Anwendungsfall Das Rezept fordert den Betreiber (oder das Self-Service-Portal des Kunden) auf, Folgendes anzugeben: * **Kundenname und URL** (Mandantenabschnitt) * **Admin-Zugangsdaten** (automatisch generiert oder manuell) * **Speicherkapazität** (benutzerdefinierte Frage — wie viel S3-Speicher bereitgestellt werden soll) * **Externe IP** (Netzwerkabschnitt — für den S3-API-Endpunkt) * **Knotenressourcen** (Knotenabschnitt — CPU/RAM für die Speicher-VM) Mit einer einzigen Formularübermittlung stellt CloudHoster für seinen Kunden eine vollständige, isolierte, S3-kompatible Speicherumgebung bereit — in Minuten statt Stunden. ### Das Angebot skalieren CloudHoster stellt dieses Rezept an vier seiner Standorte bereit, indem der Katalog über ein Remote-Repository geteilt wird. Wenn sie das Rezept aktualisieren (z. B. um die Speicheranwendungs-VM zu aktualisieren), erhalten alle Standorte eine Benachrichtigung und können das Update abrufen. ## Best Practices ### Rezeptdesign * **Einfach anfangen** — erstellen Sie zunächst einen minimalen Basis-Tenant und fügen Sie schrittweise Komplexität hinzu * **Verwenden Sie aussagekräftige Variablennamen** — `STORAGE_CAPACITY_GB` ist besser als `Q1` für die Wartung von Skripten * **Dokumentieren Sie Ihre Rezepte** — verwenden Sie das Beschreibungsfeld und den Notiztext bei Fragen, um Operatoren anzuleiten * **Mit Simulation testen** — validieren Sie Fragen und Ausgaben, bevor Sie sie in Produktionskatalogen veröffentlichen ### Wartung des Basis-Tenants * **Dedizierte Basis-Tenants** — verwenden Sie niemals den Basis-Tenant eines Rezepts für Produktions-Workloads * **Versionskontrolle** — legen Sie Hauptversionsnummern manuell fest (z. B., `2.0.0`) wenn Sie wesentliche Änderungen am Basis-Tenant vornehmen * **Sensible Daten entfernen** — stellen Sie sicher, dass im Basis-Tenant keine kundenspezifischen Passwörter, Daten oder Konfigurationen vorhanden sind ### Organisation * **Aussagekräftige Katalognamen** — gruppieren Sie Rezepte nach Zweck (z. B. „Standard VDC“, „GPU-Computing“, „Speicherdienste“) * **Symbole verwenden** — Font-Awesome-Symbole helfen Operatoren, Rezeptsarten in der Benutzeroberfläche schnell zu erkennen * **Geltungsbereich angemessen festlegen** — verwenden Sie Private für nur intern genutzte Rezepte, Tenant für kundenorientierte, Global für die Verteilung über mehrere Standorte {% hint style="info" %} **Kommen Sie von VMware oder Nutanix?** Ein VergeOS-Tenant-Rezept stellt in einem einzigen Vorgang ein vollständiges isoliertes VDC bereit — Verwaltungsoberfläche, Benutzer, Netzwerkkonfiguration, Firewall-Regeln, Speicher und DNS/DHCP — und nicht nur VMs oder Anwendungen. Für den Umfang und die Funktionen jedes VMware- oder Nutanix-Automatisierungstools, mit dem Sie es möglicherweise vergleichen, konsultieren Sie die aktuelle Dokumentation des jeweiligen Anbieters. {% 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/de/modul-7-multi-tenancy/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.