Distribuzione fallita

Durante la distribuzione di un’applicazione, potreste riscontrare degli errore durante la fase di build o di rollout che faranno fallire la distribuzione. Questo articolo spiega come risolvere errori di distribuzione specifici; se il problema si verifica ancora dopo aver seguito questi passaggi, fate riferimento ai nostri passaggi generali per la risoluzione dei problemi.

Processo di build fallito – Nessun gruppo Buildpack rilevato

Quando distribuite un’applicazione, se si verifica un problema nel rilevamento del buildpack dell’applicazione durante il processo di build, potreste vedere il seguente errore nei Dettagli distribuzione.

Processo di build fallito
Tipo di errore di build sconosciuto

Fate clic sull’errore nei dettagli distribuzione per vedere il log del processo di build e cercare errori simili a:

===> 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

Questi errori si verificano quando non ci sono abbastanza informazioni per rilevare correttamente il tipo di applicazione. Di solito sono causati da una delle seguenti motivazioni:

• Il repository Git non contiene tutti i file necessari per l’applicazione.
• Qualcosa nel codice o nelle impostazioni fa sì che venga selezionato un buildpack non corretto.
• Il percorso di build non è corretto.

Repository Git

Controllate il repository per assicurarvi che tutti i file corretti siano stati inseriti nel repository per l’applicazione.

Buildpack

Se scegliete Imposta automaticamente l’immagine del container quando aggiungete l’applicazione, noi useremo un buildpack per determinare e impostare automaticamente un container per l’applicazione. Se l’applicazione richiede un buildpack aggiuntivo, potete aggiungerne altri nella pagina delle impostazioni dell’applicazione.

Quando utilizzate i buildpack, dovete anche assicurarvi che nei file dell’applicazione sia presente la versione di linguaggio corretta. Per maggiori dettagli, consultate la nostra documentazione su come specificare la versione di linguaggio per Nixpacks o Buildpacks.

Percorso di build

Il percorso di build è la posizione dei file per la build dell’applicazione nel repository. Di solito si tratta della root del repository e non è necessario impostare un percorso di build quando aggiungete un’applicazione.

Se l’applicazione ha un percorso di build diverso, potete impostarlo quando aggiungete l’applicazione oppure potete modificarlo in Impostazioni (Impostazioni > Modifica dettagli > Percorso di build). Ad esempio, se l’applicazione deve essere costruita da una sottodirectory denominata app, inserite il percorso della sottodirectory come /app nel campo Percorso di build.

Failed Build Because Process Exited Too Early

Quando distribuite un’applicazione, se c’è un problema con il processo di build, potreste vedere il seguente errore:

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.

Di solito questo errore è dovuto a una memoria di sistema insufficiente nella build machine dell’applicazione.

Per risolvere questo errore, aumentate la dimensione della build machine dell’applicazione. Andate su Processi, cliccate su Aggiorna build, scegliete una build machine più grande e cliccate nuovamente su Aggiorna build per confermare la modifica.

Rollout fallito

Quando distribuite un’applicazione, se si verifica un problema di distribuzione, potreste visualizzare uno dei seguenti errori:

L’applicazione ha subito un errore di rollout. Dai un’occhiata alla nostra documentazione e se continui a riscontrare problemi, contatta il nostro team di supporto.

Processo di build fallito
Tipo di errore di build sconosciuto

Se il processo di rollout fallisce immediatamente o se il processo di build fallisce, non vengono creati pod e non esistono registri di runtime, la causa è spesso un comando Start errato nel processo web (o un ENTRYPOINT errato nel Dockerfile se l’applicazione è costruita da un Dockerfile).

Se il processo di rollout viene eseguito per un minuto o due e poi fallisce, di solito significa che i pod sono stati creati, ma qualcosa è andato storto e il processo si è interrotto. In questo caso, dovete controllare i log del runtime dell’applicazione per individuare eventuali messaggi di errore. I messaggi di errore possono aiutarvi a identificare i bug nel codice dell’applicazione in modo da poter eseguire il debug del problema.

Se non riuscite a identificare il problema, controllate quanto segue e, se il problema persiste, contattate il nostro team di supporto.

Repository Git

Controllate il repository per verificare che tutti i file corretti siano stati inseriti nel repository dell’applicazione.

Linguaggio

Quando aggiungete l’applicazione e scegliete di utilizzare Nixpacks o Buildpacks per creare l’immagine del container dell’applicazione, determiniamo e impostiamo automaticamente un container per la vostra applicazione. Quando utilizzate Nixpacks o Buildpacks, se non volete che venga utilizzata la versione predefinita o l’ultima disponibile del linguaggio, dovrete impostare la versione del linguaggio nei file dell’applicazione. Per maggiori dettagli, consultate la nostra documentazione su come specificare una versione di linguaggio per Buildpacks o su come specificare una versione di linguaggio per Nixpacks.

Inoltre, se distribuite un’applicazione PHP o Python con Nixpacks e il rollout fallisce quando viene costruita l’immagine del container, è probabile che ciò sia dovuto a una versione linguistica mancante nel codice dell’applicazione, soprattutto se la distribuzione funziona con Buildpacks ma non con Nixpacks. Controllate quanto segue per verificare che la versione del linguaggio sia impostata:

PHP

Se nel repository è presente un file composer.json, questo deve contenere la chiave require con la versione di PHP, come la seguente:

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

Python

Per specificare la versione di Python, includete quanto segue nel file runtime.txt dell’applicazione:

python-3.10.13

Comando Start o ENTRYPOINT

Il comando Start per il processo web avvia l’applicazione. Se non è corretto, l’applicazione non verrà eseguita. Potete controllare il comando in un paio di punti di MyKinsta:

• Processi > Processi di runtime > Processo web.
• Oppure Distribuzioni > Cronologia, selezionate una distribuzione per visualizzarne i dettagli, quindi cliccate su Processo di rollout sotto Progresso della distribuzione.

Se l’applicazione utilizza un Dockerfile per impostare l’immagine del container, dovrete specificare l’ENTRYPOINT nel Dockerfile per eseguire un container. Per maggiori informazioni su come specificare l’ENTRYPOINT dell’applicazione, consultate la guida sui Dockerfile.

Per maggiori dettagli su quale comando utilizzare in base al linguaggio dell’applicazione, consultate gli esempi forniti nella nostra documentazione sui comandi Start delle applicazioni.

Percorso di build o contesto del Dockerfile

Quando aggiungete un’applicazione, potete scegliere se impostare l’immagine del container automaticamente con Nixpacks o Buildpacks oppure se utilizzare un Dockerfile per impostare l’immagine del container.

• Percorso di build: si applica solo Nixpacks e Buildpacks. Si tratta del percorso nel repository dei file necessari per eseguire la build dell’applicazione. La maggior parte delle applicazioni viene compilata dalla root del repository e il percorso di build è predefinito su (.). Se avete un percorso di build diverso, specificatelo qui. Ad esempio, se l’applicazione deve essere compilata a partire da una sottodirectory (ad esempio app), inserite il percorso della sottodirectory nel campo Percorso di build: app. Questo è utile anche se avete un monorepo.
• Contesto: si applica solo ai Dockerfile. Si tratta del percorso del repository a cui dobbiamo accedere per poter eseguire la build dell’applicazione. La maggior parte delle applicazioni viene compilata a partire dalla root del repository e potete inserire la root del repository (.) nel campo Context. Se l’applicazione deve essere compilata da una sottodirectory (ad esempio app), inserite il percorso della sottodirectory nel campo Context: app.

Potete visualizzare e modificare il percorso di build o il contesto del Dockerfile nelle Impostazioni dell’applicazione.

Variabili d’ambiente

Le variabili d’ambiente forniscono all’applicazione informazioni esterne all’esecuzione dell’applicazione stessa. Una variabile d’ambiente errata può impedire l’esecuzione dell’applicazione. Potete controllare le variabili d’ambiente in Impostazioni > Variabili d’ambiente.

Verificate che le variabili d’ambiente corrette esistano e contengano valori validi. Ci sono alcune cose importanti da tenere a mente quando si creano e controllano le variabili d’ambiente:

• Ogni chiave deve essere unica e una chiave può essere aggiunta solo una volta.
• Le parentesi possono causare il fallimento del processo di build o di rollout, a seconda di quando sono disponibili durante la distribuzione. Non possono essere utilizzate nelle variabili d’ambiente.
• Le virgole senza escape sono interpretate come delimitatori dal processo di rollout, quindi non possono essere utilizzate nelle variabili d’ambiente. Se dovete usare una virgola nel valore della variabile d’ambiente, dovrete eseguirne l’escape con un backslash (\).
• Le doppie virgolette senza escape vengono ignorate o causano il fallimento del processo di rollout. Se dovete usare dei doppi apici nel valore della variabile d’ambiente, dovrete eseguirne l’escape con un backslash (\).

Connessioni interne e processo di build

Le connessioni interne sono disponibili solo in fase di esecuzione; non sono disponibili durante il processo di build.

Se l’applicazione tenta di connettersi a un database utilizzando una connessione interna durante il processo di build, si verifica un errore che indica che il database non è in esecuzione e la build fallisce. Questo è previsto perché la connessione interna non è attiva durante la build; può essere utilizzata solo in fase di esecuzione.

Ci sono un paio di modi per aggirare il problema.

Opzione 1: spostare la logica di connessione al database dal comando di build dell’applicazione al comando Start. Ad esempio, se nel processo di build avete un comando come prisma migrate e lo spostate nel comando Start, l’applicazione accederà al database solo in fase di esecuzione e la build avrà successo.

Opzione 2: aggiungete variabili d’ambiente separate per la connessione al database, una disponibile per il processo di build e l’altra solo per l’esecuzione. Le chiavi possono essere le stesse (ad esempio DB_CONNECTION_URL) purché una sia disponibile solo durante il processo di build e l’altra solo durante l’esecuzione. Utilizzate i dettagli di connessione esterna del database (Database > dbname > Info > Connessioni esterne) per i valori delle variabili da utilizzare nel processo di build.

Porta

Per l’Hosting di Applicazioni, sono aperte solo le porte 80 e 443. Se l’applicazione espone qualsiasi porta, dovrete usare la 8080.

Nome del pacchetto non valido

Un nome di pacchetto non valido nel file package.json può causare un errore. Ad esempio, non utilizzare “js” o “node” nel nome. Per maggiori dettagli, consultate le specifiche della gestione di package.json di npm nei documenti di npm.