VariablenFehlerbehebungEin Secret oder eine Referenz wird nicht angezeigt

Ein Secret oder Verweis erscheint nicht in meinem Service

Du hast ein Secret oder einen ${{name.KEY}}-Verweis gesetzt, erneut bereitgestellt, und der laufende Service sieht den erwarteten Wert trotzdem nicht.

Was das bedeutet

Der von dir gesetzte Wert ist nie in die zusammengeführte Umgebung des Service gelangt — oder etwas anderes in der Zusammenführung hat ihn überschrieben, bevor die App gestartet wurde.

Warum das passieren kann

  • Das Verweisziel oder der Schlüssel existiert nicht. Ein Verweis auf einen fehlenden Service-/Add-on-Namen oder auf einen Schlüssel, den dieses Add-on nicht bereitstellt, wird zu einem leeren String aufgelöst, statt das Deployment fehlschlagen zu lassen. Das Build-Log gibt für jeden leeren Verweis eine Warnung mit dem Grund aus; bei einer Variablenänderung, die per Neustart ohne Build übernommen wird, erscheint keine Warnung. Ein umbenanntes Ziel gilt als fehlend: Verweise beziehen sich auf den aktuellen Namen.
  • Etwas mit höherer Priorität hat ihn überschrieben. Werte werden in einer festen Reihenfolge zusammengeführt — addon-issued env < project secrets < project env < app env < app secrets < platform vars — daher kann ein projektbezogenes (--global) Secret stillschweigend von einem servicebezogenen Secret mit demselben Schlüssel verdeckt werden, und Plattformvariablen (PORT, LIZARD_SERVICE_NAME, LIZARD_PROJECT_ID, LIZARD_PUBLIC_DOMAIN, LIZARD_PRIVATE_DOMAIN) haben immer Vorrang. Wenn du PORT selbst setzt, ändert sich stattdessen der Port, an den Lizard weiterleitet, außer der Port wurde mit lizard port gesetzt.
  • Ein Build-Zeit-Wert hat den Build nicht erreicht. Die meisten Variablenänderungen werden ohne Rebuild übernommen — der Service startet neu, um sie zu übernehmen. VITE_*- und NEXT_PUBLIC_*-Werte werden in die gebauten Assets eingebettet, und eine Änderung startet sofort einen Rebuild laufender Services. Ein Service, der zu diesem Zeitpunkt abgestürzt oder gestoppt war, wird übersprungen, und ein Service mit eigenem dockerfilePath oder einer Bereitstellung per lizard up ohne Build-/Start-Befehle erhält diese Werte zur Build-Zeit nie.

Mögliche Lösungen

Prüfe das Build-Log auf leere Verweise

Shell-Zugriff auf Services (lizard ssh) ist deaktiviert. Das Build-Log ist die richtige Anlaufstelle: Jeder leere Verweis erhält eine Zeile wie ==> Warning: ... is empty mit dem Grund.

lizard logs --build --service api

Liste danach die Verweisvorlagen auf, die in diesem Geltungsbereich gültig sind, und vergleiche Name und Schlüssel mit deinen. Prüfe Schlüssel anhand der dokumentierten Variablen des Add-ons:

lizard secrets list --service api --ref

Prüfe auf eine Kollision zwischen Geltungsbereichen

Liste Secrets in beiden Geltungsbereichen auf und vergleiche sie:

lizard secrets list --service api --show
lizard secrets list --global --show

Denke daran: App-Secrets überschreiben Projekt-Secrets — wenn ein servicebezogener Wert für denselben Schlüssel existiert, hat er Vorrang vor allem, was mit --global gesetzt wurde.

Nach einer Änderung zur Build-Zeit neu bauen

Wenn der geänderte Schlüssel VITE_* oder NEXT_PUBLIC_* ist und der Service bei der Änderung abgestürzt oder gestoppt war, löse einen Rebuild aus:

lizard redeploy --service api

Siehe Build-Zeit vs. Laufzeit und Build-Pipeline → was einen Rebuild auslöst.

Siehe auch

Dienstübergreifende ReferenzenNetzwerk

Aktualisiert