Lors du déploiement d’une application, s’il y a un problème avec le déploiement, vous pouvez voir l’une des erreurs suivantes :

Votre application a rencontré une erreur de déploiement. Consultez notre documentation, et si vous continuez à rencontrer des problèmes, contactez notre équipe de support.

Le processus de construction a échoué
Type d’échec de construction inconnu

Si le processus de déploiement échoue immédiatement, ou si le processus de construction échoue, qu’aucun pod n’est créé et que les journaux d’exécution n’existent pas, une commande de démarrage incorrecte dans le processus web en est le plus souvent la cause (ou un ENTRYPOINT incorrect dans le Dockerfile si votre application est construite à partir d’un Dockerfile).

Si le processus de déploiement s’exécute pendant une minute ou deux, puis échoue, cela signifie généralement que les pods ont été créés, mais que quelque chose s’est mal passé et que le processus s’est arrêté. Dans ce cas, vous devez vérifier les journaux d’exécution de l’application pour identifier tout message d’erreur. Les messages d’erreur peuvent vous aider à identifier les bogues dans le code de l’application afin que vous puissiez déboguer le problème.

Si vous ne parvenez pas à identifier le problème, vérifiez les points suivants, et si le problème persiste, contactez notre équipe de support.

Dépôt Git

Vérifiez votre dépôt pour vous assurer que tous les fichiers corrects ont été poussés dans le dépôt pour votre application.

Langage

Quand vous ajoutez votre application et que vous choisissez d’utiliser Nixpacks ou Buildpacks pour créer l’image du conteneur de votre application, nous déterminons et configurons automatiquement un conteneur pour votre application. Quand vous utilisez des Nixpacks ou des Buildpacks, si vous ne voulez pas que la version par défaut ou la dernière version disponible du langage soit utilisée, vous devez définir la version du langage dans les réglages de votre application. Pour en savoir plus, consultez notre documentation sur la spécification d’une version de langage pour les Buildpacks ou la spécification d’une version de langage pour les Nixpacks.

En outre, si vous déployez une application PHP ou Python avec Nixpacks et que le déploiement échoue quand l’image du conteneur est construite, cela est très probablement dû à une version de langage manquante dans le code de l’application, en particulier si le déploiement fonctionne avec Buildpacks mais pas avec Nixpacks. Vérifiez les points suivants pour vous assurer que la version de langage est définie :

PHP

S’il y a un fichier composer.json dans votre dépot, il doit contenir la clé require avec la version PHP, comme ce qui suit :

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

Python

Pour spécifier votre version de Python, incluez ce qui suit dans le fichier runtime.txt de votre application :

python-3.10.13

Commande de démarrage ou ENTRYPOINT

La commande Start du processus web démarre votre application. Si elle est incorrecte, l’application ne se lancera pas. Vous pouvez vérifier la commande à plusieurs endroits dans MyKinsta :

  • Processus > Temps d’exécution > Processus web.
  • Ou Déploiements > Historique, sélectionnez un déploiement pour voir les détails, puis cliquez sur Processus de déploiement sous Progression du déploiement.
Processus de déploiement réussi dans les détails du déploiement.
Processus de déploiement réussi dans les détails du déploiement.
Processus de déploiement échoué dans les détails du déploiement.
Processus de déploiement échoué dans les détails du déploiement.

Si votre application utilise un Dockerfile pour configurer votre image de conteneur, vous devez spécifier le ENTRYPOINT dans le Dockerfile pour exécuter un conteneur. Pour plus d’informations sur la façon de spécifier le ENTRYPOINT de votre application, consultez la référence Dockerfile.

Pour plus de détails sur la commande à utiliser en fonction du langage de votre application, consultez les exemples fournis dans notre documentation sur la commande de démarrage d’application.

Chemin de construction ou contexte Dockerfile

Quand vous ajoutez votre application, vous choisissez de configurer l’image du conteneur automatiquement avec un Nixpack ou un Buildpack ou d’utiliser un Dockerfile pour configurer l’image du conteneur.

  • Chemin de construction : Ceci s’applique uniquement aux Nixpacks et aux Buildpacks. Il s’agit du chemin dans le dépot vers les fichiers nécessaires à la construction de l’application. La plupart des applications sont construites depuis la racine du dépot, et le chemin de construction est par défaut (.). Si vous avez un chemin de construction différent, indiquez-le ici. Par exemple, si votre application doit être construite depuis un sous-répertoire (par exemple app), saisissez le chemin de ce sous-répertoire dans le champ Chemin de construction : app. Ceci est également utile si vous avez un monorepo.
  • Contexte : Ceci s’applique uniquement aux Dockerfiles. Il s’agit du chemin dans le dépot auquel nous devons accéder pour pouvoir construire votre application. La plupart des applications sont construites depuis la racine du dépôt, et vous pouvez saisir la racine du dépôt (.) dans le champ Contexte. Si votre application doit être construite depuis un sous-répertoire (par exemple app), saisissez le chemin de ce sous-répertoire dans le champ Contexte : app.

Vous pouvez voir et modifier le chemin de construction ou le contexte Dockerfile dans les réglages de votre application.

Variables d’environnement

Les variables d’environnement alimentent votre application en informations extérieures à l’exécution de cette application. Une variable d’environnement incorrecte peut empêcher l’exécution de votre application. Vous pouvez vérifier vos variables d’environnement dans Réglages > Variables d’environnement.

Variables d'environnement pour votre application.
Variables d’environnement pour votre application.

Confirmez que les variables d’environnement correctes existent et contiennent des valeurs valides. Il y a quelques éléments importants à garder à l’esprit lors de la création et de la vérification des variables d’environnement :

  • Chaque clé doit être unique, et une clé ne peut être ajoutée qu’une seule fois.
  • Les parenthèses peuvent faire échouer le processus de construction ou de déploiement, selon le moment où elles sont disponibles lors du déploiement. Elles ne peuvent pas être utilisées dans les variables d’environnement.
  • Les virgules non échappées sont interprétées comme des délimiteurs par le processus de déploiement et ne peuvent donc pas être utilisées dans les variables d’environnement. Si vous devez utiliser une virgule dans la valeur de votre variable d’environnement, vous devez l’échapper à l’aide d’une barre oblique inverse (\).
  • Les guillemets doubles non échappés sont ignorés ou font échouer le processus de déploiement. Si vous devez utiliser des guillemets doubles dans la valeur de votre variable d’environnement, vous devez les faire précéder d’une barre oblique inverse (\).

Connexions internes et processus de construction

Les connexions internes sont uniquement disponibles pendant le temps d’exécution ; elles ne le sont pas pendant le processus de construction.

Si votre application tente de se connecter à une base de données à l’aide d’une connexion interne pendant le processus de construction, une erreur se produit, qui dit que la base de données n’est pas utilisée, ce qui fait échouer la construction. Ceci est normal, car la connexion interne n’est pas en production pendant la construction ; elle peut uniquement être utilisée pendant le temps d’exécution.

Il existe plusieurs façons de contourner ce problème.

Option 1 : Déplacez la logique de connexion à la base de données depuis la commande de construction de l’application vers la commande de démarrage. Par exemple : si vous avez une commande comme prisma migrate dans le processus de construction et que vous déplacez cette commande vers la commande de démarrage, votre application accèdera uniquement à la base de données pendant le temps d’exécution, et la construction sera réussie.

Option 2 : Ajoutez des variables d’environnement distinctes pour la connexion à la base de données, l’une disponible pour le processus de construction, et l’autre uniquement pour l’exécution. Les clés peuvent être les mêmes (par exemple DB_CONNECTION_URL) tant que l’une est disponible uniquement pendant le processus de construction et l’autre uniquement pendant le temps d’exécution. Utilisez les détails de la connexion externe de la base de données (Bases de données > dbname > Info > Connexions externes) pour les valeurs des variables à utiliser dans le processus de construction.

Port

Pour l’hébergement d’applications, seuls les ports 80 et 443 sont ouverts. Si votre application expose des ports, vous devez utiliser 8080.

Nom de package non valide

Un nom de package non valide dans package.json peut provoquer une erreur. Par exemple, n’utilisez pas « js » ou « node » dans le nom. Pour plus de détails, apprenez les spécificités de la gestion de package.json de npm dans les Docs de npm.

Documentation similaire