Mislukte deployments

Wanneer je je applicatie deployt, kan er tijdens de bouw- of rolloutfase een fout optreden waardoor de deployment mislukt. In dit artikel wordt uitgelegd hoe je specifieke deploymentfouten kunt oplossen; als je probleem zich na het volgen van deze stappen nog steeds voordoet, raadpleeg dan onze algemene stappen voor probleemoplossing.

Buildproces mislukt – Buildpack-groepen niet langs detectie

Als er bij het uitrollen van een applicatie een probleem is met het detecteren van het buildpack van je applicatie tijdens het bouwproces, kun je de volgende fout zien in Rollout details.

Build process failed
Unknown build fail type

Klik op de fout in Deployment details om het logboek van het bouwproces te bekijken en zoek naar fouten die lijken op:

===> DETECTING
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: no buildpacks participating
ERROR: failed to build: executing lifecycle: failed with status code: 20

Deze fouten treden op als er niet genoeg informatie is om het type applicatie correct te detecteren. Dit wordt meestal veroorzaakt door een van de volgende dingen:

• De Git repository bevat niet alle bestanden die nodig zijn voor de applicatie.
• Iets in de code of instellingen zorgt ervoor dat een onjuist buildpack wordt geselecteerd.
• Het bouwpad is onjuist.

Git repository

Controleer je repository om er zeker van te zijn dat alle juiste bestanden naar de repository voor je applicatie zijn gepushed.

Buildpack

Als je Automatisch container image instellen kiest wanneer je je applicatie toevoegt, gebruiken we een buildpack om automatisch een container voor je applicatie te bepalen en in te stellen. Als je applicatie een extra buildpack nodig heeft, kun je extra buildpacks toevoegen op de Instellingen pagina van je applicatie.

Als je buildpacks gebruikt, moet je er ook voor zorgen dat de juiste taalversie in de bestanden van je applicatie staat. Zie voor meer informatie onze documentatie over het specificeren van een taalversie voor Nixpacks of Buildpacks.

Bouwpad

Het bouwpad is waar de bestanden om je applicatie te bouwen zich bevinden in het archief. Meestal is dit de root van de repository en hoef je geen bouwpad in te stellen bij het toevoegen van je applicatie.

Als je applicatie een ander bouwpad heeft, kun je dat instellen wanneer je de applicatie toevoegt, of je kunt het wijzigen in Instellingen (Instellingen > Details bewerken > Bouwpad). Als je applicatie bijvoorbeeld moet worden gebouwd vanuit een submap met de naam app, voer dan het pad van die submap in als /app in het veld Bouwpad.

Mislukte build omdat proces te vroeg is afgebroken

Als er bij de rollout van een applicatie een probleem is met het bouwproces, kun je de volgende foutmelding te zien krijgen:

The build failed because the process exited too early. This probably means the system ran out of memory or someone called kill -9 on the process.

Dit wordt meestal veroorzaakt door onvoldoende systeemgeheugen in de bouwmachine voor de applicatie.

Om deze foutmelding op te lossen, moet je de grootte van de bouwmachine van je applicatie vergroten. Ga naar Processen, klik op Build bijwerken, kies een grotere bouwmachine en klik nogmaals op Build bijwerken om de wijziging te bevestigen.

Mislukte rollout

Als er bij het uitrollen van een applicatie een probleem optreedt, kun je een van de volgende fouten zien:

Your application experienced a rollout error. Check our documentation, and if you continue to experience problems, contact our support team.

Build process failed
Unknown build fail type

Als het rolloutproces onmiddellijk mislukt, of als het bouwproces mislukt, er geen pods worden aangemaakt en er geen runtime logs bestaan, is een onjuist startcommando in het webproces meestal de oorzaak (of een onjuiste ENTRYPOINT in de Dockerfile als je applicatie is gebouwd vanuit een Dockerfile).

Als het rolloutproces een minuut of twee loopt en dan mislukt, betekent dit meestal dat de pods zijn aangemaakt, maar dat er iets mis is gegaan en dat het proces is gestopt. In dit geval moet je de runtime logs van de applicatie controleren op foutmeldingen. De foutmeldingen kunnen je helpen om bugs in de code van de applicatie te identificeren, zodat je het probleem kunt debuggen.

Als je het probleem niet kunt identificeren, controleer dan het volgende, en als het probleem aanhoudt, neem dan contact op met ons ondersteuningsteam.

Git repository

Controleer je repository om er zeker van te zijn dat alle juiste bestanden naar de repository voor je applicatie zijn gepushed.

Taal

Als je je applicatie toevoegt en ervoor kiest om Nixpacks of Buildpacks te gebruiken om de container image van je applicatie te maken, bepalen we automatisch een container voor je applicatie en stellen die in. Als je Nixpacks of Buildpacks gebruikt en niet wilt dat de standaard of laatst beschikbare versie van de taal wordt gebruikt, moet je de taalversie instellen in de bestanden van je applicatie. Zie voor meer informatie onze documentatie over het specificeren van een taalversie voor Buildpacks of het specificeren van een taalversie voor Nixpacks.

Als je een PHP- of Python applicatie deployt met Nixpacks en de rollout mislukt wanneer de container image wordt gebouwd, is dit waarschijnlijk te wijten aan een ontbrekende taalversie in de code van de applicatie, vooral als de deployment werkt met Buildpacks maar niet met Nixpacks. Controleer het volgende om er zeker van te zijn dat de taalversie is ingesteld:

PHP

Als er een composer.json bestand in je repository staat, moet deze de require key met de PHP versie bevatten, zoals het volgende:

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

Python

Om je Python versie op te geven, moet je het volgende opnemen in het runtime.txt bestand van je applicatie:

python-3.10.13

Startcommando of ENTRYPOINT

Het Startcommando voor het webproces start je applicatie. Als dit niet correct is, zal de applicatie niet starten. Je kunt het commando op een paar plaatsen in MyKinsta controleren:

• Processen > Runtimeprocessen > Webproces.
• Of Deployments > Geschiedenis, selecteer een deployment om de details te bekijken en klik vervolgens op Rollout proces onder Deployment voortgang.

Als je applicatie een Dockerfile gebruikt om je container image op te zetten, moet je de ENTRYPOINT in het Dockerfile opgeven om een container te laten draaien. Voor meer informatie over hoe je de ENTRYPOINT van je applicatie moet opgeven, zie de Dockerfile Reference.

Voor meer details over welk commando je moet gebruiken op basis van de taal van je applicatie, zie de voorbeelden in onze documentatie over Applicatie Startcommando’s.

Bouwpad of Dockerfile context

Wanneer je je applicatie toevoegt, kun je ervoor kiezen om de container image automatisch op te zetten met een Nixpack of een Buildpack of om een Dockerfile te gebruiken om de container image op te zetten.

• Bouwpad: Dit geldt alleen voor Nixpacks en Buildpacks. Dit is het pad in de repository naar de bestanden die nodig zijn om de applicatie te bouwen. De meeste applicaties worden gebouwd vanaf de root van het archief en het Bouwpad is standaard (.). Als je een ander bouwpad hebt, geef het dan hier op. Als je applicatie bijvoorbeeld gebouwd moet worden vanuit een submap (bijvoorbeeld app), geef dan het pad van die submap op in het veld Bouwpad : app. Dit is ook handig als je een monorepo hebt.
• Context: Dit geldt alleen voor Dockerfiles. Dit is het pad in de repository waartoe we toegang moeten hebben om je applicatie te kunnen bouwen. De meeste applicaties worden gebouwd vanaf de repository root, en je kunt de repository root (.) invoeren in het Context veld. Als je applicatie gebouwd moet worden vanuit een subdirectory (bijvoorbeeld app), voer dan het pad van die subdirectory in het Context veld in: app.

Je kunt het Bouwpad of de Dockerfile context bekijken en wijzigen in de Instellingen van je applicatie.

Omgevingsvariabelen

Omgevingsvariabelen voeden je applicatie met informatie van buiten het uitvoeren van die applicatie. Een verkeerde omgevingsvariabele kan ervoor zorgen dat je applicatie niet draait. Je kunt je omgevingsvariabelen controleren in Instellingen > Omgevingsvariabelen.

Controleer of de juiste omgevingsvariabelen bestaan en geldige waarden bevatten. Er zijn een paar belangrijke dingen om in gedachten te houden bij het maken en controleren van omgevingsvariabelen:

• Elke sleutel moet uniek zijn en een sleutel kan maar één keer worden toegevoegd.
• Haakjes kunnen ervoor zorgen dat het bouw- of rolloutproces mislukt, afhankelijk van wanneer ze beschikbaar zijn tijdens de deployment. Ze kunnen niet worden gebruikt in omgevingsvariabelen.
• Unescaped komma’s worden door het rolloutproces geïnterpreteerd als scheidingstekens, dus ze kunnen niet worden gebruikt in omgevingsvariabelen. Als je een komma moet gebruiken in de waarde van je omgevingsvariabele, moet je deze escapen met een backslash ().
• Dubbele aanhalingstekens zonder escape worden genegeerd of zorgen ervoor dat het rolloutproces mislukt. Als je dubbele aanhalingstekens moet gebruiken in de waarde van je omgevingsvariabele, moet je ze omzeilen met een backslash ().

Interne verbindingen en het bouwproces

Interne verbindingen zijn alleen beschikbaar tijdens runtime; ze zijn niet beschikbaar tijdens het bouwproces.

Als je applicatie verbinding probeert te maken met een database via een interne verbinding tijdens het bouwproces, veroorzaakt dit een fout die zegt dat de database niet draait, waardoor de bouw mislukt. Dit wordt verwacht omdat de interne verbinding niet live is tijdens het bouwen; deze kan alleen tijdens runtime worden gebruikt.

Er zijn een paar manieren om dit te omzeilen.

Optie 1: Verplaats de logica die verbinding maakt met de database van het bouwcommando van de applicatie naar het startcommando. Bijvoorbeeld: als je een commando als prisma migrate in het bouwproces hebt en je verplaatst dat commando naar het startcommando, dan zal je applicatie alleen tijdens runtime toegang hebben tot de database en zal de bouw succesvol zijn.

Optie 2: Voeg naar behoefte aparte omgevingsvariabelen toe voor de databaseverbinding, de ene beschikbaar voor het bouwproces en de andere alleen voor runtime. De sleutels kunnen hetzelfde zijn (bijv. DB_CONNECTION_URL) zolang de ene alleen beschikbaar is tijdens het bouwproces en de andere alleen tijdens runtime. Gebruik de externe verbindingsgegevens van de database (Databases > dbnaam > Info > Externe verbindingen) voor de waarden van variabelen die gebruikt moeten worden tijdens het bouwproces.

Poort

Voor Applicatie Hosting zijn alleen poorten 80 en 443 open. Als je applicatie poorten opent, moet je 8080 gebruiken.

Ongeldige pakketnaam

Een ongeldige pakketnaam in package.json kan een fout veroorzaken. Gebruik bijvoorbeeld geen “js” of “node” in de naam. Zie voor meer details de specifieke afhandeling van npm’s package.json in de npm Docs.