Comment faire en sorte que Docker Compose attende les conteneurs de dépendance
Docker Compose vous permet de démarrer plusieurs conteneurs en exécutant une seule commande. Cela simplifie la mise en place de services complexes formés de plusieurs composants indépendants.
Ce n’est pas toujours assez bon cependant. Certains de vos conteneurs peuvent avoir des dépendances les uns sur les autres qui cassent l’application s’ils ne peuvent pas être remplis. Dans ce guide, nous montrerons comment vous pouvez configurer vos services Compose pour prendre en charge ces dépendances, ce qui permet de démarrer les conteneurs dans l’ordre.
Sommaire
Les bases
Docker Compose prend en charge un depends_on champ dans docker.compose.yml des dossiers. Les services peuvent inclure les noms de leurs frères et sœurs dans depends_on. Cela empêche le conteneur de démarrer tant que les services dont il dépend ne sont pas activés.
services: api: image: example.com/api:latest depends_on: - db web-app: image: example.com/web-app:latest depends_on: - api db: image: mysql:8.0
Dans cet exemple, le depends_on les champs provoquent le démarrage des services dans l’ordre suivant :
Les dépendances de chaque service sont résolues de manière récursive. Le service qui définit chaque depends_on champ est démarré en dernier, à la toute fin de la chaîne. Lorsqu’un service dépend de plusieurs autres conteneurs, ils sont démarrés dans l’ordre dans lequel ils sont répertoriés dans le depends_on champ.
La chaîne de services est utilisée à l’envers lorsque vous arrêtez une pile avec docker-compose stop. Avec l’exemple ci-dessus, le web-app le conteneur sera d’abord supprimé, puis api et db. Cela évite les demandes au web-app conteneur de tomber en panne au début d’une opération de démontage.
En attente de préparation
Le défaut depends_on la configuration n’attend que les conteneurs dépendants début. Dans l’exemple ci-dessus, Compose peut créer le api conteneur dès que db est en cours d’exécution, même si le serveur de base de données à l’intérieur du conteneur n’est pas prêt à recevoir des connexions. Ça signifie depends_on se suffit rarement à lui-même.
Vous pouvez combiner la fonctionnalité avec des vérifications de l’état pour empêcher le démarrage des conteneurs tant que leurs dépendances ne sont pas réellement prêtes. Pour utiliser cette fonctionnalité, imbriquez un condition champ sous depends_on avec service_healthy comme sa valeur :
services: api: image: example.com/api:latest depends_on: - db healthcheck: test: curl --fail http://127.0.0.1 || exit 1 interval: 10s retries: 5 start_period: 5s timeout: 10s web-app: image: example.com/web-app:latest depends_on: api: condition: service_healthy db: image: mysql:8.0
Maintenant le api conteneur a une commande de vérification de l’état attachée. La web-app le service reçoit l’instruction de ne pas démarrer avant api a été créé avec un résultat de vérification de l’état réussi. Ce sera une fois que l’API commencera à répondre aux demandes et que le curl la commande se termine avec un code d’état zéro.
En attente d’une sortie de conteneur réussie
Dans certains cas, votre dépendance peut être un conteneur à usage unique que vous souhaitez exécuter jusqu’à la fin. Vous pouvez attendre ce type de dépendance en définissant le condition champ à service_completed_successfully. Ceci est utile lorsque vous avez un script de configuration de première exécution qui s’exécute dans un autre conteneur.
services: app: image: example.com/app:latest depends_on: config_builder: condition: service_completed_successfully volumes: - config:/opt/app/config config_builder: image: example.com/config_builder:latest env: - EXAMPLE_KEY - ANOTHER_KEY volumes: - config:/output volumes: config:
Cet exemple montre comment une image dépendante peut exécuter une commande qui écrit un fichier de configuration sur un volume partagé par app. Une fois les données écrites, le config_builder le conteneur s’arrête avec un code de sortie nul. Composer lance alors automatiquement la app service car sa condition de dépendance est remplie.
Dans certaines situations depends_on avec un condition peut ne pas être suffisant pour répondre à votre cas d’utilisation. Vous pouvez ajouter des outils externes pour implémenter manuellement des vérifications de l’état et gérer les liens entre les conteneurs.
Wait-for-It est un script utilitaire qui enveloppe un autre processus. Il exécutera la commande que vous spécifiez une fois qu’une certaine condition est remplie. Cela peut être utilisé pour définir des procédures de vérification de l’état indépendamment du support intégré de Docker.
Voici comment utiliser healthcheck attendre qu’un port à conteneurs lié devienne accessible :
services: api: image: example.com/api:latest depends_on: - db web-app: image: example.com/web-app:latest depends_on: - api command: ["./wait-for-it.sh", "api:8080", "--", "node", "app.js"] db: image: mysql:8.0
Ici, nous sommes revenus à seulement faire attendre Docker Compose api conteneur à début. La web-app service accepte la responsabilité de vérifier si api est sain. Il utilise le script Wait-for-It pour détecter quand le conteneur est accessible sur le port 8080. Wait-for-It lancera alors la commande réelle du conteneur d’application Web, définie comme node app.js.
Cette approche est mieux réservée aux situations spécifiques où vous ne pouvez pas configurer un bilan de santé approprié avec Docker. Cela peut être nécessaire lorsque vous utilisez une image tierce qui ne peut pas être configurée pour exécuter une commande de vérification de l’état. Wait-for-It fournit un moyen de détecter si un port dessert le trafic en remplacement. Bien qu’il ne soit pas infaillible, c’est souvent un bon indicateur de la salubrité d’un contenant.
Sommaire
Par défaut, Docker Compose démarre simultanément tous les services de votre pile. Ceci est souvent indésirable lorsque les liens entre les services créent des relations de dépendance parent-enfant.
La depends_on permet de définir une séquence de démarrage pour vos services. Compose créera chaque nouveau conteneur dans l’ordre, garantissant que le précédent a démarré avant que le conteneur suivant ne soit ajouté.
Vous pouvez attendre que le conteneur précédent se ferme ou signaler un bilan de santé positif en ajoutant un condition à la définition de la dépendance. Dans les situations où les vérifications de l’état ne peuvent pas être utilisées, vous pouvez vous reporter à des outils comme Wait-for-It pour que les conteneurs parents détectent quand leurs dépendances sont prêtes.
