Fehlgeschlagene Bereitstellung

Wenn du deine Anwendung bereitstellst, kann während der Build- oder Rollout-Phase ein Fehler auftreten, der dazu führt, dass die Bereitstellung fehlschlägt. In diesem Artikel wird erklärt, wie du bestimmte Fehler bei der Bereitstellung beheben kannst. Wenn das Problem nach diesen Schritten immer noch auftritt, lies unsere allgemeinen Schritte zur Fehlerbehebung.

Build-Prozess fehlgeschlagen – keine Buildpack-Gruppen erkannt

Wenn bei der Bereitstellung einer Anwendung während des Build-Prozesses ein Problem bei der Erkennung des Buildpacks deiner Anwendung auftritt, kann der folgende Fehler in den Bereitstellungsdetails.

Build-Prozess fehlgeschlagen Unbekannter Build-Fehlertyp

Klicke auf den Fehler in den Bereitstellungsdetails, um das Protokoll des Build-Prozesses zu sehen und nach ähnlichen Fehlern zu suchen:

===> ERKENNUNG ERROR: Keine Buildpack-Gruppen haben die Erkennung bestanden. FEHLER: Bitte überprüfe, ob du mit dem richtigen Pfad arbeitest. ERROR: Erkennung fehlgeschlagen: keine Buildpacks beteiligt ERROR: failed to build: executing lifecycle: failed with status code: 20

Diese Fehler treten auf, wenn nicht genügend Informationen vorhanden sind, um die Art der Anwendung korrekt zu erkennen. Dies wird normalerweise durch einen der folgenden Gründe verursacht:

• Das Git-Repository enthält nicht alle Dateien, die für die Anwendung benötigt werden.
• Etwas im Code oder in den Einstellungen führt dazu, dass ein falsches Buildpack ausgewählt wird.
• Der Build-Pfad ist falsch.

Git-Repository

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

Buildpack

Wenn du beim Hinzufügen deiner Anwendung die Option Container-Image automatisch einrichten gewählt hast, verwenden wir ein Buildpack, um automatisch einen Container für deine Anwendung zu bestimmen und einzurichten. Wenn deine Anwendung ein zusätzliches Buildpack benötigt, kannst du auf der Seite Einstellungen deiner Anwendung weitere Buildpacks hinzufügen.

Wenn du Buildpacks verwendest, musst du auch sicherstellen, dass die richtige Sprachversion in den Dateien deiner Anwendung enthalten ist. Weitere Informationen findest du in unserer Dokumentation zur Angabe einer Sprachversion für Nixpacks oder Buildpacks.

Build-Pfad

Der Build-Pfad ist der Ort, an dem sich die Dateien zum Erstellen deiner Anwendung im Repository befinden. In der Regel ist dies das Stammverzeichnis des Repositorys, und du musst beim Hinzufügen deiner Anwendung keinen Build-Pfad angeben.

Wenn deine Anwendung einen anderen Build-Pfad hat, kannst du diesen beim Hinzufügen der Anwendung festlegen oder du kannst ihn in den Einstellungen (Einstellungen > Details bearbeiten > Build-Pfad). Wenn deine Anwendung z. B. in einem Unterverzeichnis mit dem Namen app erstellt werden soll, gibst du den Pfad dieses Unterverzeichnisses als /app in das Feld Erstellungspfad ein.

Build fehlgeschlagen, weil der Prozess zu früh beendet wurde

Wenn bei der Bereitstellung einer Anwendung ein Problem mit dem Build-Prozess auftritt, kannst du folgende Fehlermeldung erhalten:

Der Build ist fehlgeschlagen, weil der Prozess zu früh beendet wurde. Das bedeutet wahrscheinlich, dass dem System der Speicher ausgegangen ist oder dass jemand den Prozess kill -9 aufgerufen hat.

Die Ursache dafür ist in der Regel, dass der Systemspeicher der Build-Maschine für die Anwendung nicht ausreicht.

Um diesen Fehler zu beheben, erhöhe die Größe der Build-Maschine für deine Anwendung. Gehe zu Prozesse, klicke auf Build aktualisieren, wähle eine größere Build-Maschine und klicke erneut auf Build aktualisieren, um die Änderung zu bestätigen.

Fehlgeschlagener Rollout

Wenn bei der Bereitstellung einer Anwendung ein Problem auftritt, kann eine der folgenden Fehlermeldungen angezeigt werden:

Bei deiner Anwendung ist ein Rollout-Fehler aufgetreten. Sieh in unserer Dokumentation nach, und wenn du weiterhin Probleme hast, wende dich an unser Support-Team.

Build-Prozess fehlgeschlagen Unbekannter Build-Fehlertyp

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 gebaut wird).

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 gesetzt ist:

PHP

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

{
  "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

Start-Befehl oder ENTRYPOINT

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

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

Wenn deine Anwendung eine Dockerdatei verwendet, um dein Container-Image einzurichten, musst du die ENTRYPOINT in der Dockerdatei 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 ein Dockerfile verwendest, um das Container-Image einzurichten.

• Build-Pfad: Dies gilt nur für Nixpacks und Buildpacks. Dies 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 erstellt, 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. aus 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 Zugriff brauchen, um deine Anwendung zu bauen. Die meisten Anwendungen werden aus dem Stammverzeichnis des Repositorys erstellt, daher kannst du das Stammverzeichnis des Repositorys (.) in das Feld Context eingeben. Wenn deine Anwendung aus einem Unterverzeichnis (z. B. app) erstellt werden muss, gibst du den Pfad dieses Unterverzeichnisses in das Feld Context 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.

Überprüfe, ob 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 während der Bereitstellung verfügbar sind. Sie können nicht in Umgebungsvariablen verwendet werden.
• Nicht abgeschnittene Kommas 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 umgekehrten Schrägstrich () abschließen.
• Nicht entschärfte Anführungszeichen werden entweder nicht beachtet oder führen dazu, dass der Rollout-Vorgang fehlschlägt. Wenn du doppelte Anführungszeichen in deinem Umgebungsvariablenwert verwenden musst, musst du sie mit einem Backslash () abschließen.

Interne Verbindungen und der Build-Prozess

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

Wenn deine Anwendung während des Build-Prozesses versucht, sich ü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 (Databases > dbname > Info > Externe Verbindungen) für die Werte der Variablen, die im Erstellungsprozess verwendet werden sollen.

Port

Für das Anwendungs-Hosting sind nur die Ports 80 und 443 geöffnet. Wenn deine Anwendung andere 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.