Échecs au démarrage

Le conteneur de l’application applique ses migrations puis sert, et il se couche plutôt que de répondre contre un schéma ou une configuration auxquels il ne correspond pas. Docker le redémarre, si bien qu’une pile mal configurée a quand même l’air vivante : docker compose ps continue d’afficher l’application en Up, avec son contrôle de santé à starting, parce que le conteneur ne vit jamais assez longtemps pour en rater un.

Le statut n’est pas le signal, le journal l’est :

docker compose logs app | tail -30

Deux échecs qui n’atteignent jamais ce journal

Une pile dont le .env porte encore un secret vide n’y arrive même pas : docker compose up refuse d’interpoler le fichier et affiche required variable SECRET_ENCRYPTION_KEY is missing a value: empty in .env; fill it with openssl rand -base64 32. Il nomme toutes les variables vides en une seule passe plutôt qu’une par exécution, si bien qu’un .env copié et non modifié les affiche toutes les trois d’un coup, et POSTGRES_PASSWORD deux fois parce que les deux services la lisent. Remplissez-les et relancez la commande ; rien n’est construit tant qu’elles n’y sont pas toutes.

Un port déjà pris arrête tout aussi tôt. docker compose up construit l’image, démarre la base, puis affiche failed to bind host port 0.0.0.0:8080/tcp: address already in use et s’arrête là. Le conteneur de l’application a été créé mais jamais démarré, si bien que docker compose logs app n’affiche rien du tout et que docker compose ps montre la base toute seule. Posez WEB_PORT dans .env sur un port libre, déplacez PUBLIC_URL sur le même, et relancez la commande.

La pile à moitié levée qui s’ensuit

Ce dernier échec laisse une pile à moitié levée, et rien ne le dit. Compose démarre la base d’abord et l’application ensuite, et il ne recouche pas la première quand la seconde ne démarre pas : la commande sort en 1 en n’ayant nommé que le conteneur sur lequel elle a buté, et la base continue de tourner.

docker compose ps      # ce qui a survécu à l'échec : la base, sans l'application

Le conteneur de l’application survit lui aussi, et dans un état qu’il vaut mieux connaître. Il a été créé et jamais démarré, et ce qui a échoué, c’est Docker l’attachant au réseau : il n’est donc attaché à aucun. Compose démarre un conteneur qu’il a déjà créé plutôt que de le construire de nouveau, si bien que libérer le port à la main et répéter le même up démarre celui-là : il monte sans route vers la base et boucle sur P1001: Can't reach database server at db:5432 pendant que la base tourne à côté de lui.

Changer WEB_PORT et PUBLIC_URL évite cela, parce qu’une modification de .env est ce qui fait remplacer le conteneur par compose. Libérer le port à la place veut dire nettoyer d’abord la pile à moitié levée :

docker compose down    # conteneurs et réseau partis ; le volume et ses données ne sont pas touchés

Seul down -v supprime ce que porte la base.

Cinq lignes dans le journal

Ce que dit le journal	Ce que cela veut dire
`Invalid environment configuration:`	une variable manque ou est malformée ; la ligne en dessous nomme laquelle et ce qu’il faut lancer
`SECRET_ENCRYPTION_KEY: must be 32 bytes base64-encoded`	`openssl rand -hex 32` se décode en 48 octets, pas 32 ; cette clé veut `openssl rand -base64 32`
`DATABASE_URL: is not a valid connection URL`	`POSTGRES_PASSWORD` porte un `/`, un `?` ou un `#`, que l’URL de connexion lit comme siens
`P1001: Can't reach database server`	la base n’était pas encore levée, en général après un redémarrage ; le redémarrage le règle en quelques secondes
`P1000: Authentication failed against database server`	`POSTGRES_PASSWORD` a changé après le premier démarrage ; la base porte encore l’ancien

Remettre l’ancien mot de passe est la sortie de ce dernier cas.

Confidentialité