Pourquoi un déploiement échoue vraiment, raison par raison

« Le déploiement a échoué » n’est pas un seul problème — c’est au moins une douzaine de problèmes différents qui se présentent de la même façon à quelqu’un qui survole un tableau de bord. Savoir lequel s’est vraiment produit est l’essentiel de la correction, c’est pourquoi la page d’un déploiement échoué commence par pourquoi il a échoué : la cause, la correction, et la ligne de log qui le prouve.

Les deux qui se ressemblent mais ne le sont pas

La confusion la plus fréquente : « le build a dépassé son délai » (arrêté à sa limite de 60 minutes; la prochaine tentative réutilise ce qui était déjà construit) contre « le build a manqué de mémoire » (une étape du build tuée carrément pour avoir dépassé ce que le serveur de build a). Les deux ressemblent à « le build n’a juste pas fini » vu d’un coup d’œil sur un statut rouge — la correction pour l’un est la patience et la réutilisation du travail partiel, la correction pour l’autre est un serveur de build plus gros ou déployer une image déjà construite plutôt que de construire sur la plateforme du tout.

L’application tourne, mais ne répond pas

Celui-ci mérite sa propre mention parce qu’il est rarement évident depuis le propre code de l’application : le conteneur tourne, mais rien ne répond en HTTP. Pas planté — en marche, en bonne santé selon toutes les métriques sauf celle qui compte. La cause réelle est presque toujours une correction d’une ligne : l’application doit écouter sur 0.0.0.0, pas 127.0.0.1, et sur le port dans $PORT, pas un port codé en dur. Une application parfaitement correcte, qui tourne parfaitement correctement, mais qui ne parle jamais qu’à elle-même.

Un proche parent : la commande a tourné dans le mauvais dossier — l’image ne contient pas l’application où la commande de démarrage l’attend, habituellement parce qu’un Dockerfile écrit pour le développement local (qui attend un bind mount) a été utilisé pour un vrai build. Passer à Railpack plutôt qu’au propre Dockerfile du dépôt est la correction quand c’est la vraie situation.

Les pannes en forme de base de données, de trois façons différentes

• La base de données n’était pas accessible — plus confus encore quand ça arrive pendant le build, parce qu’une application qui se connecte à sa base de données en compilant des assets ou en exécutant une vérification au moment du build essaie d’atteindre une infrastructure que cette étape du build n’allait jamais avoir.
• L’utilisateur de la base de données manque d’une permission — une migration a besoin de quelque chose que l’utilisateur de base de données de l’application n’a pas encore. La correction est presque suspicieusement simple : redéployez une fois, puisque les droits se rafraîchissent à chaque déploiement.
• L’étape de release a échoué — habituellement des migrations, exécutées une fois avant que la nouvelle version ne prenne le trafic. La première ligne de l’erreur réelle s’affiche directement sur la page de déploiement, pas enfouie dans un dump complet de logs.

Les deux qui sont vraiment le même problème habillé différemment

Une variable requise n’est pas définie (l’application s’arrête au démarrage parce que quelque chose dont elle a besoin est vide) et l’application a besoin d’identifiants pour un service externe (une API tierce, du stockage cloud, un envoi d’e-mail, un paiement — aucune clé configurée) sont la même cause racine — une variable d’environnement manquante — avec une précision différente. L’une dit « quelque chose manque », l’autre nomme quelle catégorie de chose.

L’image n’a pas pu être récupérée (n’existe pas, mauvaise étiquette, ou privée sans identifiants) et le nom de l’image est invalide (caractères que Docker n’accepte pas) forment la paire équivalente pour les déploiements basés sur une image plutôt que sur un build.

Pourquoi nommer la cause exacte compte plus qu’il n’y paraît

Chacune de ces pannes produit le même symptôme visible pour quelqu’un qui survole un tableau de bord : un statut rouge et un déploiement échoué. La vraie correction ne devient évidente qu’une fois la cause précise nommée — « a dépassé son délai » et « a manqué de mémoire » ont besoin de réponses opposées; un pipeline de déploiement fiable tient moins à ne jamais échouer qu’à ce qu’un échec dise immédiatement et précisément quoi faire ensuite.

Référence complète, chaque cause : Dépannage des déploiements échoués.