Compose, dépendances, santé et configuration

Comprendre le mécanisme

Compose décrit plusieurs services, leurs réseaux, volumes et configuration. Une dépendance ordonne le démarrage mais le simple état running ne prouve pas qu’une base accepte déjà des requêtes. Un healthcheck et une condition de dépendance adaptée peuvent aider au démarrage. L’application doit néanmoins gérer les indisponibilités ultérieures : le succès initial ne garantit pas la disponibilité permanente d’une dépendance.

Raisonner et vérifier

Les variables d’environnement et les fichiers dotenv de Compose participent à l’interpolation et à la configuration selon leurs règles propres. Ne confondez pas leur traitement avec celui de Symfony. Pour un secret, choisissez un montage ou gestionnaire adapté et évitez l’exposition dans les images et logs. Vérifiez le rendu de configuration sans diffuser de valeurs sensibles.

Une déclaration décrit des intentions

Compose organise des services et ressources selon un fichier et un environnement donnés. Un YAML syntaxiquement valide ne prouve pas la disponibilité réelle d’une API ou de sa base. Les images, variables, volumes et réseaux doivent aussi être corrects. Lisez la configuration effective puis lancez le parcours utile ; la présence des bons noms de sections n’est pas une observation du comportement déployé.

Démarrer n’est pas être prêt

Une dépendance peut être en exécution alors que son initialisation n’est pas terminée. Un ordre de démarrage simple ne garantit donc pas que la base accepte déjà la première requête métier. Définissez le critère de disponibilité et les conditions que l’application peut attendre. Un délai fixe choisi au hasard peut masquer le problème sur une machine rapide sans le résoudre sur une autre.

Observer une santé pertinente

Un health check doit correspondre à une propriété clairement définie. Vérifier seulement qu’un processus existe ne démontre pas l’accès aux données nécessaires au parcours. À l’inverse, un contrôle trop lourd ou mutateur peut perturber le service. Choisissez une observation bornée et interprétable, avec un diagnostic minimisé. Le succès doit rester limité aux dépendances et conditions réellement exercées.

Comprendre la condition de démarrage

Une condition comme service_healthy peut organiser le démarrage d’un service consommateur selon la santé déclarée de sa dépendance. Cette coordination ne garantit pas sa disponibilité éternelle. Vérifiez la définition du health check et le comportement du mode de déploiement ciblé. Une configuration porte des règles ; les tests doivent montrer ce qu’elles font lors d’un démarrage lent et d’un refus persistant.

Les pannes peuvent arriver après le démarrage

Une dépendance initialement saine peut tomber en panne pendant le service. L’application doit donc conserver des délais, erreurs et reprises adaptées indépendamment de l’ordre initial. Tester uniquement docker compose up ne couvre pas cette phase. Simulez une indisponibilité après un parcours réussi et vérifiez le refus borné, la récupération et l’absence de répétition incontrôlée d’un effet métier sensible.

Deux usages différents des fichiers dotenv

L’interpolation de variables par Compose et la lecture de configuration par Symfony ne sont pas nécessairement le même mécanisme ni le même moment. Une valeur disponible pour construire le YAML ne se retrouve pas automatiquement dans tout processus. Définissez la chaîne d’injection attendue et contrôlez les variables effectives sans publier les secrets. Un nom de fichier identique ne rend pas deux contrats de configuration interchangeables.

Un nom de service n’exige pas un port public

Sur le réseau prévu, les services peuvent utiliser leur résolution interne pour communiquer. La dépendance db n’a pas toujours besoin d’une publication vers Internet. Cette possibilité de connexion ne remplace ni authentification ni disponibilité SQL. Testez depuis le consommateur réel afin de distinguer erreur de nom, refus réseau et erreur de credentials sans élargir inutilement la surface exposée.

La politique de redémarrage a des limites

Relancer un processus peut aider après certains échecs, mais ne répare pas une donnée invalide ou une mauvaise configuration permanente. Une boucle de redémarrages peut consommer des ressources et masquer la cause. Définissez les conditions et l’observation de reprise. Un test doit inclure un défaut persistant et montrer que l’exploitation peut le diagnostiquer, au lieu d’interpréter toute nouvelle tentative comme un progrès.

Vérifier les ressources dans le runtime choisi

Les options de limite doivent être effectivement prises en compte par le moteur et le mode de déploiement utilisés. Leur présence dans un exemple ne prouve pas la même application partout. Mesurez consommation, refus et comportement sous pression dans l’environnement cible. Un budget mémoire borne certaines conséquences mais ne corrige pas la fuite qui les provoque ; il peut conduire à un arrêt qu’il faut aussi gérer.

Construire des scénarios dégradés

Un démarrage nominal ne couvre pas dépendance silencieuse, réponse lente et erreur durable. Utilisez des services simulés ou un laboratoire pour provoquer ces états sans toucher les données réelles. Pour chaque scénario, écrivez durée maximale et effet interdit. Cette matrice permet de vérifier la résilience comme un contrat observable, plutôt que l’attribuer au seul fait d’utiliser un orchestrateur ou une politique de restart.

Atelier guidé : lire, expliquer et vérifier le code

services:
  api:
    image: example/lab-api:1
    depends_on:
      - db
  db:
    image: postgres:18

L’extrait déclare une dépendance de démarrage entre api et db. Il ne présente ni condition de santé ni preuve que PostgreSQL accepte une requête lorsque l’application effectue son premier appel. Il faut donc distinguer la relation déclarée, bien présente, de la disponibilité métier qui reste à définir et observer.

Dans un laboratoire, ralentissez l’initialisation de la base et relevez le comportement de l’API. Ajoutez une coordination adaptée si elle répond au besoin, puis provoquez une panne après un démarrage réussi. L’application doit encore respecter ses budgets et sa politique de reprise. Le test montre ainsi ce que l’organisation initiale apporte, et quelles responsabilités restent dans le consommateur pendant la durée du service.