Hvis der er et problem med implementeringen af en applikation, kan du få vist en af følgende fejl, når du implementerer det:
Din applikation oplevede en udrulningsfejl. Tjek vores dokumentation, og hvis du fortsat oplever problemer, skal du kontakte vores supportteam.
Opbygningsprocessen mislykkedes
Ukendt fejltype for opbygning.
Hvis udrulningsprocessen mislykkes med det samme, eller hvis byggeprocessen mislykkes, der ikke oprettes pods, og der ikke findes runtime-logfiler, er en forkert startkommando i webprocessen oftest årsagen (eller et forkert ENTRYPOINT i Dockerfilen, hvis din applikation er bygget fra en Dockerfile).
Hvis udrulningsprocessen kører i et minut eller to og derefter mislykkes, betyder det normalt, at pods blev oprettet, men at noget gik galt, og at processen stoppede. I dette tilfælde bør du kontrollere applikationruntime logfilerne for at identificere eventuelle fejlmeddelelser. Fejlmeddelelserne kan hjælpe dig med at identificere fejl i applikationens kode, så du kan fejlfinde problemet.
Hvis du ikke kan identificere problemet, skal du kontrollere følgende, og hvis problemet fortsætter, skal du kontakte vores supportteam.
Git-repositorium
Kontroller dit repository for at sikre, at alle de korrekte filer er blevet skubbet ind i repositoryet for din applikation.
Sprog
Når du tilføjer din applikation og vælger at bruge Nixpacks eller Buildpacks til at oprette din applikations containerbillede, bestemmer og opsætter vi automatisk en container til din applikation. Når du bruger Nixpacks eller Buildpacks, hvis du ikke ønsker, at standardversionen eller den seneste tilgængelige version af sproget skal bruges, skal du indstille sprogversionen i din applikations filer. For flere detaljer, se vores dokumentation om angivelse af en sprogversion til Buildpacks eller angivelse af en sprogversion til Nixpacks.
Derudover, hvis du implementerer en PHP- eller Python-applikation med Nixpacks, og udrulningen mislykkes, når containerbilledet er bygget, skyldes det højst sandsynligt en manglende sprogversion i applikationens kode, især hvis implementeringen fungerer med Buildpacks, men ikke med Nixpacks. Kontroller følgende for at sikre, at sprogversionen er indstillet:
PHP
Hvis der er en composer.json-fil i dit lager, skal den indeholde require-nøglen med PHP-versionen, som følgende:
{
"require": {
"php": "~8.1.0"
}
}Python
For at angive din Python-version skal du inkludere følgende i din applikations runtime.txt-fil:
python-3.10.13
Start kommando eller ENTRYPOINT
Kommandoen Start til webprocessen starter din applikation. Hvis dette er forkert, vil applikationen ikke køre. Du kan tjekke kommandoen et par steder i MyKinsta:
- Processer > Kørselsprocesser > Webproces.
- Eller Implementeringer > Historik, vælg en implementering for at se detaljerne, og klik derefter på Udrulningsproces under Implementeringsforløb.
Hvis dit program bruger en Dockerfil til at opsætte dit containerimage, skal du angive ENTRYPOINT i Dockerfilen for at køre en container. Du kan få flere oplysninger om, hvordan du angiver dit programs ENTRYPOINT, i Dockerfile-referencen.
Du kan få flere oplysninger om, hvilken kommando du skal bruge baseret på dit programs sprog, i eksemplerne i vores dokumentation om kommandoen Programstartskommando.
Byg sti eller Dockerfile-kontekst
Når du tilføjer din applikation, vælger du enten at opsætte containerbilledet automatisk med en Nixpack eller en Buildpack eller bruge en Dockerfile til at opsætte containerbilledet.
- Build path: Dette gælder kun for Nixpacks en Buildpacks. Dette er stien i depotet til de filer, der kræves for at bygge applikationen. De fleste applikationer er bygget fra lagerroden, og Build-stien er som standard denne (.). Hvis du har en anden byggesti, skal du angive den her. For eksempel, hvis din applikation skal bygges fra en undermappe (f.eks. app), skal du indtaste den undermappesti i feltet Byg sti: app. Dette er også nyttigt, hvis du har en monorepo.
- Kontekst: Dette gælder kun for Dockerfiler. Dette er stien i depotet, vi skal have adgang til, så vi kan bygge din applikation. De fleste applikationer er bygget fra lagerroden, og du kan indtaste lagerroden (.) i kontekstfeltet. Hvis din applikation skal bygges fra en undermappe (f.eks. app), skal du indtaste den undermappesti i kontekstfeltet: app.
Du kan se og ændre Build-stien eller Dockerfile-konteksten i din applikations indstillinger.
Miljøvariabler
Miljøvariabler giver din applikation oplysninger til din applikation uden for den pågældende applikations kørsel. En forkert miljøvariabel kan forhindre din applikation i at køre. Du kan kontrollere dine miljøvariabler i Indstillinger > Miljøvariabler.
Bekræft, at de korrekte miljøvariabler findes og indeholder gyldige værdier. Der er et par vigtige ting at huske på, når du opretter og kontrollerer miljøvariabler:
- Hver nøgle skal være unik, og en nøgle kan kun tilføjes én gang.
- Parenteser kan få bygge- eller udrulningsprocessen til at mislykkes, afhængigt af hvornår de er tilgængelige under implementeringen. De kan ikke bruges i miljøvariabler.
- Ikke-undgåede kommaer tolkes som afgrænsninger af udrulningsprocessen, så de kan ikke bruges i miljøvariabler. Hvis du skal bruge et komma i din miljøvariabelværdi, skal du undslippe det med en omvendt skråstreg (
\). - Ikke-undgåede dobbelte anførselstegn enten ignoreres eller vil få udrulningsprocessen til at mislykkes. Hvis du skal bruge dobbelte anførselstegn i din miljøvariabelværdi, skal du undslippe dem med en omvendt skråstreg (
\).
Interne forbindelser og build-processen
Interne forbindelser er kun tilgængelige under kørsel; de er ikke tilgængelige under build-processen.
Hvis dit program forsøger at oprette forbindelse til en database ved hjælp af en intern forbindelse under byggeprocessen, forårsager dette en fejl, der siger, at databasen ikke kører, hvilket gør, at buildet mislykkes. Dette forventes, fordi den interne forbindelse ikke er strømførende under opbygningen; den kan kun bruges under kørsel.
Der er et par måder at løse dette på.
Mulighed 1: Flyt logikken, der forbinder til databasen, fra applikationens build-kommando til start-kommandoen. For eksempel: Hvis du har en kommando som prisma migrate i byggeprocessen og flytter den kommando til startkommandoen, vil din applikation kun få adgang til databasen under kørsel, og opbygningen vil lykkes.
Mulighed 2: Tilføj separate miljøvariabler efter behov for databaseforbindelsen, en tilgængelig for byggeprocessen og den anden kun til runtime. Nøglerne kan være de samme (f.eks. DB_CONNECTION_URL), så længe den ene kun er tilgængelig under build-processen, og den anden kun er tilgængelig under kørsel. Brug databasens eksterne forbindelsesdetaljer (Databaser > dbnavn > Info > Eksterne forbindelser) for værdierne af variabler, der skal bruges i build-processen.
Port
For Application Hosting er kun port 80 og 443 åbne. Hvis dit program eksponerer nogen porte, skal du bruge 8080.
Ugyldigt pakkenavn
Et ugyldigt pakkenavn i package.json kan forårsage en fejl. Brug for eksempel ikke “js” eller “node” i navnet. For flere detaljer, se detaljerne for npms package.json-håndtering i npm Docs.