Fehlgeschlagener Rollout

Wenn bei der Bereitstellung einer Anwendung ein Problem auftritt, kannst du eine der folgenden Fehlermeldungen sehen:

Bei deiner Anwendung ist ein Fehler beim Rollout aufgetreten. Überprüfe unsere Dokumentation und wenn du weiterhin Probleme hast, wende dich an unser Support-Team.

Build-Prozess fehlgeschlagen
Unbekannter Build-Fail-Typ.

Wenn der Rollout-Prozess sofort fehlschlägt oder wenn der Build-Prozess fehlschlägt, keine Pods erstellt werden und keine Laufzeitprotokolle vorhanden sind, ist meistens ein falscher Startbefehl im Webprozess die Ursache (oder ein falscher ENTRYPOINT im Dockerfile, wenn deine Anwendung aus einem Dockerfile erstellt wurde).

Wenn der Rollout-Prozess ein oder zwei Minuten lang läuft und dann fehlschlägt, bedeutet das normalerweise, dass die Pods zwar erstellt wurden, aber etwas schief gelaufen ist und der Prozess abgebrochen wurde. In diesem Fall solltest du die Laufzeitprotokolle der Anwendung auf Fehlermeldungen hin überprüfen. Die Fehlermeldungen können dir helfen, Fehler im Code der Anwendung zu finden, damit du das Problem beheben kannst.

Wenn du das Problem nicht identifizieren kannst, überprüfe die folgenden Punkte und wende dich an unser Support-Team, wenn das Problem weiterhin besteht.

Git-Repository

Überprüfe dein Repository, um sicherzustellen, dass alle richtigen Dateien in das Repository für deine Anwendung gepusht wurden.

Sprache

Wenn du deine Anwendung hinzufügst und dich dafür entscheidest, Nixpacks oder Buildpacks zu verwenden, um das Container-Image deiner Anwendung zu erstellen, ermitteln wir automatisch einen Container für deine Anwendung und richten ihn ein. Wenn du Nixpacks oder Buildpacks verwendest und nicht möchtest, dass die Standardversion oder die neueste verfügbare Version der Sprache verwendet wird, musst du die Sprachversion in den Dateien deiner Anwendung festlegen. Weitere Informationen findest du in unserer Dokumentation zur Angabe einer Sprachversion für Buildpacks oder zur Angabe einer Sprachversion für Nixpacks.

Wenn du eine PHP- oder Python-Anwendung mit Nixpacks bereitstellst und der Rollout beim Erstellen des Container-Images fehlschlägt, liegt das höchstwahrscheinlich an einer fehlenden Sprachversion im Code der Anwendung, insbesondere wenn die Bereitstellung mit Buildpacks, aber nicht mit Nixpacks funktioniert. Überprüfe Folgendes, um sicherzustellen, dass die Sprachversion eingestellt ist:

PHP

Wenn es eine composer.json-Datei in deinem Repository gibt, muss sie den require-Schlüssel mit der PHP-Version enthalten, wie im Folgenden:

{
  "require": {
    "php": "~8.1.0"
  }
}

Python

Um deine Python-Version anzugeben, füge Folgendes in die Datei runtime.txt deiner Anwendung ein:

python-3.10.13

Startbefehl oder ENTRYPOINT

Mit dem Startbefehl für den Webprozess wird deine Anwendung gestartet. Wenn er falsch ist, wird die Anwendung nicht ausgeführt. Du kannst den Befehl an mehreren Stellen in MyKinsta überprüfen:

Prozesse > Laufzeitprozesse > Webprozess.
Oder Bereitstellung > Verlauf, wähle einen Einsatz aus, um die Details zu sehen, und klicke dann unter Einsatzfortschritt auf Rollout-Prozess.

Erfolgreicher Rollout-Prozess in den Einsatzdetails.

Fehlgeschlagener Rollout-Prozess in den Einsatzdetails.

Wenn deine Anwendung ein Dockerfile verwendet, um dein Container-Image einzurichten, musst du die ENTRYPOINT im Dockerfile angeben, um einen Container zu starten. Weitere Informationen darüber, wie du die ENTRYPOINT für deine Anwendung angibst, findest du in der Dockerfile-Referenz.

Weitere Informationen darüber, welchen Befehl du je nach Sprache deiner Anwendung verwenden musst, findest du in den Beispielen in unserer Dokumentation zum Anwendungsstartbefehl.

Build-Pfad oder Dockerfile-Kontext

Wenn du deine Anwendung hinzufügst, kannst du wählen, ob du das Container-Image automatisch mit einem Nixpack oder einem Buildpack einrichtest oder eine Dockerdatei verwendest, um das Container-Image einzurichten.

Build-Pfad: Dies gilt nur für Nixpacks und Buildpacks. Das ist der Pfad im Repository zu den Dateien, die zum Bauen der Anwendung benötigt werden. Die meisten Anwendungen werden vom Stammverzeichnis des Repositorys aus gebaut, und der Build-Pfad ist standardmäßig auf dieses Verzeichnis (.) eingestellt. Wenn du einen anderen Build-Pfad hast, gib ihn hier an. Wenn deine Anwendung z. B. in einem Unterverzeichnis (z. B. app) erstellt werden soll, gib den Pfad dieses Unterverzeichnisses in das Feld Erstellungspfad ein: app. Dies ist auch nützlich, wenn du eine Monorepo hast.
Kontext: Dies gilt nur für Dockerdateien. Das ist der Pfad im Repository, auf den wir zugreifen müssen, damit wir deine Anwendung bauen können. Die meisten Anwendungen werden aus dem Stammverzeichnis des Repositorys erstellt, daher kannst du das Stammverzeichnis des Repositorys (.) in das Feld Kontext eingeben. Wenn deine Anwendung aus einem Unterverzeichnis (z. B. app) erstellt werden muss, gib den Pfad zu diesem Unterverzeichnis in das Feld Kontext ein: app.

Du kannst den Build-Pfad oder den Dockerfile-Kontext in den Einstellungen deiner Anwendung einsehen und ändern.

Umgebungsvariablen

Umgebungsvariablen versorgen deine Anwendung mit Informationen, die nicht von der Anwendung selbst stammen. Eine falsche Umgebungsvariable kann dazu führen, dass deine Anwendung nicht läuft. Du kannst deine Umgebungsvariablen unter Einstellungen > Umgebungsvariablen überprüfen.

Vergewissere dich, dass die richtigen Umgebungsvariablen vorhanden sind und gültige Werte enthalten. Bei der Erstellung und Überprüfung von Umgebungsvariablen gibt es einige wichtige Dinge zu beachten:

Jeder Schlüssel muss eindeutig sein, und ein Schlüssel kann nur einmal hinzugefügt werden.
Klammern können dazu führen, dass der Build- oder Rollout-Prozess fehlschlägt, je nachdem, wann sie bei der Bereitstellung verfügbar sind. Sie können nicht in Umgebungsvariablen verwendet werden.
Ungeschützte Kommata werden vom Rollout-Prozess als Begrenzungszeichen interpretiert und können daher nicht in Umgebungsvariablen verwendet werden. Wenn du ein Komma in deinem Umgebungsvariablenwert verwenden musst, musst du es mit einem Backslash abschließen (\).
Ungeschützte Anführungszeichen werden entweder nicht beachtet oder führen dazu, dass der Rollout-Prozess fehlschlägt. Wenn du Anführungszeichen in deinem Umgebungsvariablenwert verwenden musst, musst du sie mit einem Backslash abschließen (\).

Interne Verbindungen und der Erstellungsprozess

Interne Verbindungen sind nur während der Laufzeit verfügbar; während des Build-Prozesses sind sie nicht verfügbar.

Wenn deine Anwendung versucht, sich während des Build-Prozesses über eine interne Verbindung mit einer Datenbank zu verbinden, führt dies zu einer Fehlermeldung, die besagt, dass die Datenbank nicht läuft, wodurch der Build fehlschlägt. Das ist zu erwarten, weil die interne Verbindung während des Builds nicht aktiv ist; sie kann nur während der Laufzeit verwendet werden.

Es gibt mehrere Möglichkeiten, dieses Problem zu umgehen.

Option 1: Verschiebe die Logik, die die Verbindung zur Datenbank herstellt, vom Build-Befehl der Anwendung zum Start-Befehl. Wenn du z. B. einen Befehl wie prisma migrate im Build-Prozess hast und diesen Befehl in den Startbefehl verschiebst, greift deine Anwendung nur während der Laufzeit auf die Datenbank zu und der Build wird erfolgreich sein.

Option 2: Füge je nach Bedarf separate Umgebungsvariablen für die Datenbankverbindung hinzu, von denen eine für den Build-Prozess und die andere nur für die Laufzeit verfügbar ist. Die Schlüssel können gleich sein (z.B. DB_CONNECTION_URL), solange eine nur während des Build-Prozesses und die andere nur während der Laufzeit verfügbar ist. Verwende die Details zur externen Verbindung der Datenbank (Datenbanken > dbname > Info > Externe Verbindungen) für die Werte der Variablen, die im Erstellungsprozess verwendet werden sollen.

Port

Für Application Hosting sind nur die Ports 80 und 443 offen. Wenn deine Anwendung irgendwelche Ports offenlegt, musst du 8080 verwenden.

Ungültiger Paketname

Ein ungültiger Paketname in der package.json kann einen Fehler verursachen. Verwende zum Beispiel nicht „js“ oder „node“ im Namen. Weitere Details findest du in den npm Docs zur Handhabung der package.json von npm.

Lösungen

Vorteile