Quando si distribuisce un’applicazione, se c’è un problema con la distribuzione, potrebbe presentarsi uno dei seguenti errori:

L’applicazione ha subito un errore di rollout. Controllare la nostra documentazione e se si continuano a riscontrare problemi, contattare il nostro team di supporto.

Processo di build fallito.
Tipo di errore di compilazione sconosciuto.

Se il processo di rollout fallisce immediatamente o se a fallire è il processo di compilazione, non vengono creati pod e i log di runtime non esistono. La causa è spesso un comando di avvio errato nel processo web (o un ENTRYPOINT errato nel Dockerfile se l’applicazione è costruita a partire da un file Docker).

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 è fermato. In questo caso, è necessario 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 analizzare il problema.

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

Repository Git

Controllate il vostro repository per verificare che tutti i file siano stati inseriti nel repository della vostra applicazione.

Linguaggio

Quando si aggiunge un’applicazione, e si sceglie di usare Nixpacks o Buildpacks per creare l’immagine del contenitore dell’applicazione, determiniamo e impostiamo automaticamente un contenitore per l’applicazione. Quando si usa Nixpacks o Buildpacks, se non si vuole utilizzare la versione predefinita o l’ultima disponibile della lingua, è necessario impostare la versione della lingua nei file dell’applicazione. Per maggiori dettagli, consultare la nostra documentazione su come specificare una versione di linguaggio per Buildpacks o specificare una versione di linguaggio per Nixpacks.

Inoltre, se si distribuisce 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 di linguaggio mancante nel codice dell’applicazione, in particolare se la distribuzione funziona con Buildpacks ma non con Nixpacks. Verificare quanto segue per assicurarsi che la versione del linguaggio sia impostata:

PHP

Se esiste un file composer.json nel repository, deve contenere la chiave require con la versione di PHP, come segue:

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

Python

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

python-3.10.13

Comando di Avvio o ENTRYPOINT

Il comando di avvio o ENTRYPOINT per il processo web esegue l’applicazione. Se non è corretto, l’applicazione non verrà eseguita. Potete controllare il comando in un paio di punti in MyKinsta.

  • Processi > Processi runtime > Processo web
  • O Distribuzioni > Cronologia, selezionate una distribuzione per visualizzare i dettagli e il Processo di rollout.
Processo di rollout riuscito nel dettaglio in Distribuzione.
Processo di rollout riuscito in Dettagli Distribuzione.
Processo di rollout fallito in Dettagli Distribuzione.
Processo di rollout fallito in Dettagli Distribuzione.

Se la vostra applicazione utilizza un Dockerfile per impostare l’immagine del container, dovete specificare il sito ENTRYPOINT nel Dockerfile in modo da eseguire un container. Per maggiori informazioni su come specificare l’indirizzo ENTRYPOINT della vostra applicazione, consultate il riferimento al Dockerfile.

Per maggiori informazioni sul comando da utilizzare in base al linguaggio della vostra applicazione, consultate gli esempi forniti nella nostra documentazione sui comandi di avvio delle applicazioni.

Percorso di Build o Dockerfile Context

Quando si aggiunge l’applicazione, si può scegliere di impostare l’immagine del container automaticamente con un Nixpack o un Buildpack o di usare un Dockerfile per impostare l’immagine del container.

  • Percorso di build: Questo vale solo per i Nixpacks e i Buildpacks. È il percorso nel repository dei file necessari per effettuare il build dell’applicazione. La maggior parte delle applicazioni viene costruita dalla root del repository, su cui il percorso di build è preimpostato (.). Se il proprio percorso di build è diverso, specificarlo qui. Ad esempio, se l’applicazione deve effettuare il build da una sottodirectory (ad esempio app), inserire il percorso della sottodirectory nel campo Percorso di Build: app. Questo è utile anche se si dispone di un monorepository.
  • Context: Si applica solo ai file Docker. È il percorso del repository a cui accedere per effettuare il build dell’applicazione. La maggior parte delle applicazioni sono costruite a partire dalla root del repository, ed è possibile inserire la root del repository (.) nel campo Context. Se l’applicazione deve effettuare il build da una sottodirectory (ad esempio, app), inserire il percorso della sottodirectory nel campo Context: app.

È possibile visualizzare e modificare il percorso di build o il Dockerfile Context 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.

Variabili d'ambiente dell'applicazione.
Variabili d’ambiente dell’applicazione.

Verificate che le variabili d’ambiente necessarie esistano e contengano valori validi. Ci sono un paio di cose importanti da tenere a mente quando si creano e controllane le variabili d’ambiente:

  • Ogni chiave deve essere univoca e 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 usate nelle variabili d’ambiente.
  • Le virgole senza escape sono interpretate come delimitatori dal processo di rollout, quindi non possono essere usate nelle variabili d’ambiente. Se si vuole usare una virgola nel valore di una variabile d’ambiente, è necessario eseguire l’escape della virgola con un backslash (\).
  • I doppi apici senza escape vengono ignorati o causano l’insuccesso del processo di rollout. Se si devono usare i doppi apici nel valore della variabile d’ambiente, è necessario eseguirne l’escape con un backslash (\).

Connessioni Interne e Processo di Build

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

Se, durante il processo di build, l’applicazione tenta di connettersi a un database utilizzando una connessione interna, 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, ma può essere utilizzata solo in fase di esecuzione.

Ci sono un paio di modi per risolvere il problema.

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

Opzione 2: aggiungere 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. Utilizzare i dati della connessione esterna del database (Database > dbname > Info > Connessioni esterne) per i valori delle variabili da utilizzare nel processo di build.

Porte

Per l’hosting di applicazioni, sono aperte solo le porte 80 e 443. Se l’applicazione espone qualsiasi porta, è necessario utilizzare la 8080.

Nome del pacchetto non valido

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

Documentazione Correlata