Verwaltete Addons
Managed Addons sind die Datenbanken und Speicher, die Lizard (lizard.build) in Ihrem Projekt betreibt: Managed Postgres, Managed Redis und S3-kompatibler Managed Object Storage. lizard add postgres redis s3 erstellt alle drei mit einem Befehl. Jedes Add-on stellt einen festen Satz von Umgebungsvariablen bereit, etwa DATABASE_URL, und Ihre Services lesen sie über Referenzen wie ${{postgres.DATABASE_URL}}. Verwenden Sie sie, wenn eine App Daten braucht, die einen Deploy oder Neustart überdauern.
Ein Add-on bereitstellen
lizard add postgres # one addon
lizard add postgres redis s3 # several at once
lizard add --list # show available typesBenennung
Das erste Add-on eines bestimmten Typs erhält den bloßen Typ als Namen — daher funktioniert ${{postgres.DATABASE_URL}} sofort. Zusätzliche Addons desselben Typs erhalten einen generierten Namen wie postgres-autumn-bear. Ein gelöschtes Add-on behält seinen Namen 3 Tage lang im Papierkorb, sodass ein in diesem Zeitraum hinzugefügtes neues Add-on einen generierten Namen erhält; stellen Sie das alte wieder her oder richten Sie die Referenzen auf den neuen Namen aus.
Es gibt keinen Fallback über einen Typ-Alias: Eine Referenz muss den aktuellen Namen des Addons verwenden. Das Umbenennen eines Add-ons bricht Referenzen auf den alten Namen, aktualisieren Sie diese daher nach einer Umbenennung:
lizard service rename main-db --service postgres # addons rename through the same command
lizard secrets set DATABASE_URL='${{main-db.DATABASE_URL}}' --service apiEin Add-on verwenden
Referenzieren Sie die Variablen eines Addons aus jedem Service. Die Referenz wird beim Bereitstellen aufgelöst, sodass der Service beim nächsten Deployment die aktuellen Werte des Addons übernimmt:
lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api
lizard redeploy --service apiLizard injiziert außerdem DATABASE_URL und REDIS_URL von jedem laufenden Postgres- und Redis-Add-on in jeden Service des Projekts, und zwar mit der niedrigsten Priorität. Eine explizite Referenz überschreibt sie und wählt ein bestimmtes Add-on aus. Für Services im selben Projekt und in derselben Region sollten Sie die private URL bevorzugen:
lizard secrets set DATABASE_URL='${{postgres.DATABASE_PRIVATE_URL}}' --service apiSiehe Secret-Scoping.
Variablen nach Typ
| Add-on | Variablen |
|---|---|
| postgres | DATABASE_URL, DATABASE_PRIVATE_URL, PGHOST, PGPORT, PGUSER, PGPASSWORD, PGDATABASE, POSTGRES_USER, POSTGRES_DB, POSTGRES_PASSWORD |
| redis | REDIS_URL, REDIS_PRIVATE_URL |
| s3 | S3_ENDPOINT, S3_DEFAULT_BUCKET, S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY, S3_REGION |
DATABASE_URL und REDIS_URL verwenden den öffentlichen Endpunkt. DATABASE_PRIVATE_URL und REDIS_PRIVATE_URL verwenden <name>.lizard.internal im privaten Netzwerk und funktionieren nur von Services im selben Projekt und in derselben Region aus. Ein Service in einer anderen Region muss DATABASE_URL oder REDIS_URL verwenden. Damit er die private URL nutzen kann, erstellen Sie das Add-on in seiner Region, zum Beispiel mit lizard add postgres --region <code>. <name> ist der Name, den das Add-on beim Vergeben der privaten Adresse hatte; eine Umbenennung ändert ihn nicht.
Browser im Dashboard
Das Dashboard enthält einen Datenbrowser für jedes Add-on — einen SQL-/Tabellen-Editor für Postgres, einen Key-Browser für Redis und einen Bucket-/Objekt-Browser für S3 — sodass Sie Daten prüfen und bearbeiten können, ohne Lizard zu verlassen.
Speicher
Daten-Volumes von Postgres und Redis sind nur erweiterbar. Erhöhen Sie die Kapazität mit:
lizard scale --service postgres --storage 8192Erlaubte Größen sind 512, 1024, 2048, 4096, 8192 oder 16384 MB. Beim Vergrößern stoppt Lizard die Datenbank, kopiert ihre Daten auf ein größeres Volume und startet sie wieder. Rechnen Sie also mit einer kurzen Ausfallzeit. Setzen Sie eine pausierte Datenbank vorher mit lizard resume fort.
Anleitungen nach Typ
Warum ein Prototyp in der Regel alle drei gleichzeitig braucht, erfahren Sie unter Daten und Konfiguration explizit machen.
Aktualisiert