Docker Compose : lancer application, API et base ensemble

Pourquoi décrire l’environnement dans un fichier

Une application peut dépendre d’une API, d’une base, d’un cache et d’un processus de traitement. Les démarrer séparément avec des commandes manuelles favorise les oublis et les variations entre personnes. Docker Compose rassemble leurs définitions dans une configuration versionnée : images, réseaux, volumes et paramètres. Cette configuration explique la structure d’un environnement reproductible. Elle ne remplace pas les décisions d’architecture ni les procédures de sauvegarde, mais fournit une base lisible pour démarrer, arrêter et inspecter les composants. Un nouveau membre de l’équipe doit pouvoir comprendre les services sans reconstituer une suite de commandes oubliées.

Définir les services par responsabilité

Un service Compose décrit un type de composant, par exemple web, api ou database. Il peut utiliser une image existante ou une construction locale. Donnez des noms compréhensibles et séparez les processus qui ont des cycles de vie différents. L’application web et un worker peuvent partager une image tout en avoir des commandes distinctes. Évitez de mettre tous les composants dans un seul conteneur uniquement pour réduire le nombre de services. Cette simplification apparente rend les mises à jour, les logs et les redémarrages plus difficiles à gérer séparément.

Organiser les réseaux et les noms de services

Les composants d’un réseau Compose partagé peuvent communiquer en utilisant leurs noms de service. Depuis l’API, la base n’est généralement pas accessible sous localhost, car ce nom désigne le conteneur de l’API lui-même. Configurez l’adresse du service de base et son port interne. Les ports publiés sur l’hôte servent les accès extérieurs ; ils ne sont pas nécessaires à chaque communication interne. Séparez les réseaux lorsque cela apporte une limite utile. Un frontend public peut avoir besoin de joindre l’API sans que la base soit directement accessible depuis le navigateur ou Internet.

Gérer variables, configurations et secrets

Compose permet de fournir des paramètres aux services et d’utiliser des valeurs substituées depuis l’environnement. Distinguez ce que Compose interprète lors de la lecture du fichier et ce que l’application reçoit dans son conteneur. Un fichier local contenant des secrets ne doit pas être ajouté au dépôt simplement pour faciliter le démarrage. Fournissez plutôt un exemple sans valeurs sensibles et documentez les paramètres requis. Vérifiez les valeurs par environnement et la méthode de rotation. Une configuration manquante doit produire une erreur explicite plutôt que connecter silencieusement l’application à une mauvaise base.

Comprendre les dépendances et la disponibilité

Démarrer la base avant l’API ne garantit pas que la base accepte déjà les connexions. Un processus peut être actif pendant une initialisation ou une restauration. Utilisez des contrôles de santé pertinents et les conditions de dépendance adaptées, tout en rendant l’application capable de réessayer les connexions temporaires. Les dépendances doivent rester limitées aux besoins réels. Une panne d’un outil facultatif ne devrait pas empêcher toute l’application de répondre si un mode dégradé est possible. Vérifiez aussi le comportement après un redémarrage en cours d’exploitation, pas uniquement au premier lancement.

Préserver les données et préparer les sauvegardes

Déclarez les volumes nécessaires et identifiez les opérations qui peuvent les supprimer. Un arrêt ou un remplacement de conteneur n’a pas les mêmes conséquences qu’une suppression explicite des données. Les commandes de nettoyage doivent être documentées avec prudence. Pour la sauvegarde d’une base, utilisez une méthode cohérente avec son fonctionnement, pas une copie improvisée pendant des écritures. Conservez les sauvegardes dans un emplacement distinct et contrôlez leur durée de conservation. Une restauration sur un environnement séparé fournit une preuve concrète que le plan de reprise peut réellement être utilisé.

Exemple d’environnement API et base

Une petite plateforme peut exposer une API sur l’hôte et garder PostgreSQL sur un réseau interne. L’API reçoit sa chaîne de connexion et la base possède un volume. Ajoutez ensuite les contrôles de disponibilité et les migrations propres au projet. L’exemple ci-dessous illustre seulement la structure ; les secrets, versions, limites et paramètres applicatifs doivent être définis pour l’environnement réel. Une configuration de démonstration copiée sans analyse n’est pas une configuration de production.

services:
  api:
    image: my-company/api:release-42
    ports:
      - '8080:8080'
    environment:
      DB_HOST: database
  database:
    image: postgres:17
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD is required}
volumes:
  db-data:

Séparer les besoins de développement et de production

En développement, des montages de code et des outils de diagnostic facilitent les changements. En production, on cherche plutôt un artefact testé et une configuration stable. Évitez d’y conserver les mêmes accès de débogage ou les mêmes volumes de sources. Des fichiers complémentaires peuvent exprimer les différences sans dupliquer toute la définition. Documentez leur ordre et les valeurs résultantes. Vérifiez la configuration finale avant déploiement. Le fait qu’un environnement démarre sur un ordinateur ne prouve pas que les permissions, les sauvegardes et les points d’entrée sont adaptés à un serveur exposé.

Connaître les limites de Compose

Compose peut être pertinent pour un poste de développement ou un déploiement limité. Il ne fournit pas à lui seul toutes les capacités d’une plateforme d’orchestration multi-hôte. Si le produit exige placement sur plusieurs machines, reprise automatique après perte d’un hôte ou politiques de déploiement avancées, d’autres choix d’infrastructure sont à étudier. Ne complexifiez pas pour autant un petit projet sans besoin réel. Comparez disponibilité attendue, compétences d’exploitation et coût total. L’outil doit correspondre à la capacité de l’équipe à surveiller et restaurer le système, y compris pendant une panne.

Livrer un environnement que l’équipe peut exploiter

Une livraison complète indique comment démarrer, vérifier, mettre à jour, sauvegarder et restaurer. Ajoutez les commandes de diagnostic et les emplacements des logs utiles, sans divulguer les secrets. Testez une installation propre et une mise à jour avec des données existantes. Tuplify Studio peut préparer les environnements Docker Compose de vos applications et documenter leur exploitation. La valeur ne vient pas uniquement du fichier YAML : elle réside dans un fonctionnement reproductible, des responsabilités claires et une procédure de reprise comprise par les personnes qui assureront la continuité du service.

Atelier : simuler une dépendance indisponible

Démarrez l’environnement puis rendez la base indisponible dans un contexte de test. Observez le comportement de l’API : erreurs compréhensibles, nouvelles tentatives bornées et absence de saturation des logs. Rétablissez la base et vérifiez que le service retrouve un état utilisable sans manipulation cachée. Répétez avec une initialisation lente au démarrage. Contrôlez ensuite les ports accessibles depuis l’hôte et depuis les autres services. L’objectif est de vérifier disponibilité et exposition, pas seulement l’ordre de lancement. Documentez les résultats et les limites, car une dépendance qui tombe après le démarrage ne sera pas nécessairement gérée par les seules conditions utilisées pour lancer les conteneurs.

Questions fréquentes : localhost et mise en production

Pourquoi localhost ne trouve-t-il pas la base ? Dans un conteneur, il désigne ce conteneur. Les services utilisent normalement le nom et le port interne de leur dépendance sur un réseau commun.

Faut-il publier le port de la base ? Seulement si un accès extérieur défini le nécessite. Une communication interne n’exige pas une exposition publique.

Compose est-il interdit en production ? Non : son adéquation dépend du périmètre, de la disponibilité attendue et de l’exploitation. Vérifiez ce qu’il apporte et ce qu’il ne fournit pas seul, notamment pour plusieurs hôtes. Une petite architecture bien maintenue peut être préférable à une plateforme complexe que l’équipe ne sait pas surveiller ni restaurer.