Wie erstelle und rendere ich eine Konfigurations-Vorlage?

Ab Tarif Elite

Kurzantwort

Lege im Bereich Provisionierung auf dem Reiter Vorlagen über „Vorlage hinzufügen” eine Vorlage an: Name, Typ (Provisionierung oder Deprovisionierung) und der Inhalt mit Platzhaltern wie {{ hostname }}. Anschließend rendert der Endpunkt /render die Vorlage serverseitig mit konkreten Variablen zu einer fertigen Konfiguration, sandboxed, ohne Zugriff auf das System.

Voraussetzungen

Die Provisionierung ist ab Tarif Elite verfügbar.

Reiter „Vorlagen” öffnen. Wähle in der linken Navigation Provisionierung; der Reiter Vorlagen ist vorausgewählt. Die Tabelle zeigt die vorhandenen Vorlagen mit Name und Typ.

Screenshot ausstehend provisioning-vorlagen-01 Bereich Provisionierung mit aktivem Reiter Vorlagen und Schaltfläche 'Vorlage hinzufügen'

Der Reiter 'Vorlagen' im Bereich Provisionierung.
Vorlage anlegen. Klicke „Vorlage hinzufügen” und fülle den Dialog:
- Name (Pflicht): z. B. „Nginx vHost Standard”.
- Typ (Pflicht): Provisionierung oder Deprovisionierung.
- Inhalt: die Vorlage selbst, mit Jinja2-Platzhaltern, z. B.:
  Beispiel-Inhalt
```
server {
  listen 443 ssl;
  server_name {{ hostname }};
  root /var/www/{{ site }};
}
```
- Beschreibung (optional): wofür die Vorlage gedacht ist.
Screenshot ausstehend provisioning-vorlagen-02 Dialog 'Vorlage hinzufügen' mit Name, Typ, Inhalt mit Jinja2-Platzhaltern und Beschreibung

Eine Vorlage mit Jinja2-Platzhaltern im Feld 'Inhalt'.
Speichern. Die Vorlage erscheint in der Liste und kann ab sofort per API gerendert werden (siehe Reiter API). Das Rendern ist ein API-Vorgang. Die Weboberfläche pflegt die Vorlagen.

Vorlage anlegen ist ein POST auf /api/v1/provisioning/templates (Scope write):

curl -X POST https://demo.notory.io/api/v1/provisioning/templates \
  -H "Authorization: Bearer inv_dein_token" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Nginx vHost Standard",
    "template_type": "provisioning",
    "content": "server {\n  listen 443 ssl;\n  server_name {{ hostname }};\n  root /var/www/{{ site }};\n}",
    "description": "Standard-vHost für neue Webprojekte"
  }'

{
  "id": "tp_5f6a…",
  "tenant_id": "3d9b0c12-…",
  "name": "Nginx vHost Standard",
  "template_type": "provisioning",
  "content": "server {\n  listen 443 ssl;\n  server_name {{ hostname }};\n  root /var/www/{{ site }};\n}",
  "description": "Standard-vHost für neue Webprojekte",
  "created_at": "2026-07-08T11:20:00Z",
  "updated_at": "2026-07-08T11:20:00Z"
}

Vorlage rendern ist ein POST auf /api/v1/provisioning/templates/{id}/render mit den konkreten variables:

curl -X POST https://demo.notory.io/api/v1/provisioning/templates/tp_5f6a.../render \
  -H "Authorization: Bearer inv_dein_token" \
  -H "Content-Type: application/json" \
  -d '{ "variables": { "hostname": "shop.example.com", "site": "shop" } }'

{
  "rendered": "server {\n  listen 443 ssl;\n  server_name shop.example.com;\n  root /var/www/shop;\n}"
}

Mögliche Fehler: 400 („Template error: …”, Syntaxfehler in der Vorlage), 401, 403 (Provisionierung nicht im Tarif oder kein Schreibrecht), 404 (Vorlage nicht gefunden), 422 (Validierung).

Was passiert dabei?

Sandbox-Rendering: Das Rendern läuft in einer abgeschotteten Jinja2-Umgebung auf dem Server. Vorlagen haben keinen Zugriff auf Dateisystem oder interne Objekte. Fehlerhafte Vorlagen liefern 400 mit der Fehlermeldung.
Kein automatisches Deployment: Notory rendert die Konfiguration nur; sie wird nicht automatisch auf Zielsysteme ausgerollt. Die Zustellung übernimmt dein Deployment-Werkzeug bzw. ein Workflow.
Mandanten-Isolation & Audit: Vorlagen gehören deinem Mandanten; Anlegen, Ändern und Löschen werden protokolliert. Das Rendern ist ein Lesevorgang am Vorlagenbestand.
Typ ist dokumentarisch: Provisionierung/Deprovisionierung klassifiziert die Vorlage für Übersicht und Filterung; beide Typen rendern identisch.