Échec du déploiement

Lorsque vous déployez votre application, il se peut qu’une erreur se produise pendant la phase de construction ou de déploiement, entraînant l’échec du déploiement. Cet article explique comment résoudre des erreurs de déploiement spécifiques ; si le problème persiste après avoir suivi ces étapes, reportez-vous à nos étapes générales de résolution des problèmes.

Échec du processus de construction – Aucun groupe Buildpack n’a été détecté

Lors du déploiement d’une application, s’il y a un problème de détection du buildpack de votre application pendant le processus de construction, vous pouvez voir l’erreur suivante dans les Détails du déploiement.

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

Cliquez sur l’erreur dans les détails du déploiement pour voir le journal du processus de construction et recherchez des erreurs similaires :

===> DETECTING
ERREUR : Aucun groupe de buildpack n’a passé la détection.
ERREUR : Veuillez vérifier que vous utilisez le bon chemin d’accès.
ERREUR : Échec de la détection : aucun buildpack participant
ERROR : failed to build : executing lifecycle : failed with status code : 20

Ces erreurs se produisent lorsqu’il n’y a pas assez d’informations pour détecter correctement le type d’application. Cela est généralement dû à l’un des éléments suivants :

• Le dépôt Git ne contient pas tous les fichiers nécessaires à l’application.
• Quelque chose dans le code ou les réglages fait qu’un buildpack incorrect est sélectionné.
• Le chemin de construction est incorrect.

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.

Buildpack

Si vous choisissez Configurer l’image du conteneur automatiquement lorsque vous ajoutez votre application, nous utilisons un buildpack pour déterminer et configurer automatiquement un conteneur pour votre application. Si votre application nécessite un buildpack supplémentaire, vous pouvez ajouter des buildpacks supplémentaires sur la page des Réglages de votre application.

Lorsque vous utilisez des buildpacks, vous devez également vous assurer que la version de langage correcte se trouve dans les fichiers de votre application. Pour plus de détails, consultez notre documentation sur la spécification d’une version de langage pour les Nixpacks ou les Buildpacks.

Chemin de construction

Le chemin de construction est l’endroit où les fichiers pour construire votre application sont situés dans le dépôt. En général, il s’agit de la racine du dépôt, et vous n’avez pas besoin de définir un chemin de compilation lors de l’ajout de votre application.

Si votre application a un chemin de construction différent, vous pouvez le définir lorsque vous ajoutez l’application, ou vous pouvez le changer dans les Réglages (Réglages > Modifier les détails > Chemin de compilation). Par exemple, si votre application doit être construite à partir d’un sous-répertoire nommé app, saisissez le chemin de ce sous-répertoire sous la forme /app dans le champ Chemin de construction.

Échec de la compilation car le processus s’est arrêté trop tôt

Lors du déploiement d’une application, s’il y a un problème avec le processus de compilation, vous pouvez voir l’erreur suivante :

La compilation a échoué parce que le processus s’est arrêté trop tôt. Cela signifie probablement que le système a manqué de mémoire ou que quelqu’un a appelé kill -9 sur le processus.

Ce problème est généralement dû à une insuffisance de mémoire système dans la machine de construction de l’application.

Pour résoudre cette erreur, augmentez la taille de la machine de compilation de votre application. Allez dans Processus, cliquez sur Mise à niveau de la construction, choisissez une machine de construction plus grande et cliquez à nouveau sur Mise à niveau de la machine de construction pour confirmer la modification.

Échec du déploiement

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

Votre application a connu 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 une adresse ENTRYPOINT incorrecte dans le fichier Docker si votre application est construite à partir d’un fichier Docker).

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 les messages d’erreur. Les messages d’erreur peuvent vous aider à identifier des 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

Lorsque 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. Lorsque vous utilisez Nixpacks ou Buildpacks, si vous ne souhaitez pas que la version par défaut ou la dernière version disponible du langage soit utilisée, vous devez définir la version de langage dans les fichiers de votre application. Pour plus de détails, 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 lorsque l’image du conteneur est construite, cela est 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 éléments suivants pour vous assurer que la version de langage est définie :

PHP

S’il y a un fichier composer.json dans votre dépôt, il doit contenir la clé require avec la version PHP, comme 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 de démarrage pour le processus web démarre votre application. Si elle est incorrecte, l’application ne s’exécutera pas. Vous pouvez vérifier la commande à plusieurs endroits dans MyKinsta :

• Processus > Processus 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.

Si votre application utilise un fichier Docker pour configurer votre image de conteneur, vous devez spécifier l’adresse ENTRYPOINT dans le fichier Docker pour exécuter un conteneur. Pour plus d’informations sur la manière de spécifier l’adresse 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 de l’application.

Chemin de construction ou contexte du fichier Docker

Lorsque 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 ne s’applique qu’aux Nixpacks et Buildpacks. Il s’agit du chemin dans le dépôt vers les fichiers nécessaires à la construction de l’application. La plupart des applications sont construites à partir de la racine du référentiel, 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 à partir d’un sous-répertoire (par exemple app), entrez le chemin de ce sous-répertoire dans le champ Chemin de construction: app. Ceci est également utile si vous avez un mono-dépôt.
• Contexte : Ceci ne s’applique qu’aux Dockerfiles. Il s’agit du chemin dans le dépôt auquel nous devons accéder pour construire votre application. La plupart des applications sont construites à partir de la racine du dépôt, et vous pouvez entrer la racine du dépôt (.) dans le champ Contexte. Si votre application doit être construite à partir d’un sous-répertoire (par exemple app), entrez le chemin de ce sous-répertoire dans le champ Contexte: app.

Vous pouvez afficher et modifier le chemin de construction ou le contexte du fichier Docker dans les réglages de votre application.

Variables d’environnement

Les variables d’environnement fournissent à votre application des 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.

Confirmez que les variables d’environnement correctes existent et qu’elles contiennent des valeurs valides. Il y a quelques points 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, en fonction du moment où elles sont disponibles pendant le déploiement. Elles ne peuvent pas être utilisées dans les variables d’environnement.
• Les virgules non encapsulé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 ne sont disponibles que pendant l’exécution ; elles ne sont pas disponibles 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, indiquant que la base de données n’est pas en cours d’exécution, ce qui entraîne l’échec de la construction. C’est normal, car la connexion interne n’est pas active pendant la construction ; elle ne peut être utilisée que pendant l’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 de 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 n’accèdera à la base de données que pendant l’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 étant 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 n’est disponible que pendant le processus de construction et l’autre que pendant l’exécution. Utilisez les détails de la connexion externe de la base de données (Bases de données > Nom de la base > 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 paquet non valide

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