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

Qualcosa è andato storto, contatta l’assistenza.

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

Se scegliete Imposta automaticamente l’immagine del container quando aggiungete la vostra applicazione, per individuare e impostare automaticamente un container per l’applicazione viene usato un buildpack. Quando si usano i buildpack, è necessario assicurarsi che la versione corretta del linguaggio sia presente nei file dell’applicazione. Per maggiori informazioni, si legga come specificare la versione del linguaggio.

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 buildpack o di usare un Dockerfile per impostare l’immagine del container.

  • Percorso di build: Si applica solo ai buildpack. È 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:

  • Le virgole sono interpretate dal processo di rollout come delimitatori, quindi non possono essere utilizzate nelle variabili d’ambiente.
  • Ogni chiave deve essere univoca e può essere aggiunta solo una volta.
  • Le doppie virgolette senza escape vengono ignorate o causano l’interruzione del processo di rollout.

Porte

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

Documentazione Correlata