Als er bij de rollout van een applicatie een probleem optreedt, zie je mogelijk een van de volgende fouten:
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 onjuist ENTRYPOINT in het Dockerbestand als je applicatie uit een Dockerbestand is gebouwd).
Als het rolloutproces een minuut of twee loopt en dan mislukt, betekent dit meestal dat de pods zijn aangemaakt, maar dat er iets fout is gegaan, en dat het proces is gestopt. In dit geval moet je de runtime logs van de applicatie controleren op eventuele 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 archief
Controleer je repository om er zeker van te zijn dat alle juiste bestanden naar de repository voor je applicatie zijn gepushed.
Taal
Wanneer je je applicatie toevoegt en ervoor kiest om Nixpacks of Buildpacks te gebruiken om het container image van je applicatie te maken, wordt er automatisch een container voor je applicatie bepaald en ingesteld. 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 deployed met Nixpacks en de uitrol mislukt wanneer het container image wordt gebouwd, dan 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, neem je het volgende op in het runtime.txt bestand van je applicatie:
python-3.10.13Startcommando of ENTRYPOINT
Het startcommando voor het webproces start je applicatie. Als dit onjuist is, draait de applicatie niet. 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 dan op Rolloutproces onder Deployment voortgang.
Als je applicatie een Dockerfile gebruikt om je container image op te zetten, moet je in het Dockerfile de ENTRYPOINT opgeven om een container te laten draaien. Zie de Dockerfile referentie voor meer informatie over hoe je de ENTRYPOINT van je applicatie moet specificeren.
Voor meer details over welk commando je moet gebruiken op basis van de taal van je applicatie, zie de voorbeelden in onze documentatie over het Applicatie startcommando.
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.
- Buildpad: 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 de repository, en het buildpad staat hier standaard op (.). Als je een ander buidlpad hebt, geef dat dan hier op. Als je applicatie bijvoorbeeld gebouwd moet worden vanuit een submap (bijv. app), geef dan dat submap pad op in het veld Buildpad: app. Dit is tevens handig als je een monorepo hebt.
- Context: Dit geldt alleen voor Dockerfiles. Dit is het pad in de repository waartoe we toegang moeten hebben zodat we je applicatie kunnen bouwen. De meeste applicaties worden gebouwd vanaf de repository root, en je kunt de repository root (.) invoeren in het veld Context. Als je applicatie gebouwd moet worden vanuit een subdirectory (bijvoorbeeld app), vul dan het pad van die subdirectory in het Context veld in: app.
Je kunt het buildpad of de Dockerfile Context bekijken en wijzigen in de Instellingen van je applicatie.
Omgevingsvariabelen
Omgevingsvariabelen voeden je applicatie met informatie van buiten het draaien van die applicatie. Een verkeerde omgevingsvariabele kan voorkomen dat je applicatie 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.
- Parentheses kunnen ervoor zorgen dat het build- of rolloutproces mislukt, afhankelijk van wanneer ze beschikbaar zijn tijdens het deployen. Ze kunnen niet worden gebruikt in omgevingsvariabelen.
- Unescaped komma’s worden door het rolloutproces geïnterpreteerd als scheidingstekens en kunnen dus niet worden gebruikt in omgevingsvariabelen. Als je een komma moet gebruiken in de waarde van je omgevingsvariabele, moet je deze escapen met een backslash (
\). - Unescaped dubbele aanhalingstekens worden genegeerd of zorgen ervoor dat het rolloutproces mislukt. Als je dubbele aanhalingstekens moet gebruiken in de waarde van je omgevingsvariabele, dan 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 probeert verbinding te maken met een database met behulp van een interne verbinding tijdens het bouwproces, veroorzaakt dit een fout die zegt dat de database niet draait, waardoor de build 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 hier omheen te werken.
Optie 1: Verplaats de logica die verbinding maakt met de database van de bouwopdracht van de applicatie naar de startopdracht. 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 build 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 (bijvoorbeeld 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 staan alleen de poorten 80 en 443 open. Als je applicatie poorten openstelt, moet je 8080 gebruiken.
Invalid Package Name (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.