Compose: Depends_on dans la version3

Créé le 9 janv. 2017  ·  37Commentaires  ·  Source: docker/compose

Salut, je voudrais savoir quelle est l'alternative de depend_on dans docker-compose v3 comme dans les notes de publication, vous avez dit que nous allons enregistrer la fonctionnalité depend_on dans la v3

formav3 kinquestion

Commentaire le plus utile

Quel serait l'équivalent sur docker-compose v3 pour obtenir quelque chose comme les dépendances de contrôle de santé? Si vous allez supprimer cette fonctionnalité dans la v3, vous ne devriez pratiquement jamais l'utiliser, ou du moins il devrait y avoir un chemin de migration pour cela.

Quelles sont les intentions de l'introduire dans un nouveau docker-compose v2.1 puis de le laisser tomber pour la v3? Je suis actuellement en train de configurer différents fichiers de composition pour nos applications, mais je ne veux pas utiliser des fonctionnalités qui seront supprimées dans la prochaine version et empêchent donc l'utilisation de la mise à jour vers une version plus récente du fichier docker-compose.

Tous les 37 commentaires

depends_on existe toujours dans la v3, mais les dépendances de contrôle de santé (et par conséquent, la syntaxe étendue) ne seront pas portées.

HTH

Mais j'ai écrit un docker-compose v3 et j'essaye de déployer sur swarm mais depend_on ne fonctionne pas car le conteneur ne démarre pas de la manière dont il doit être démarré.

Utilisez-vous docker-compose ou docker stack deploy ?

J'utilise le déploiement de la pile de docker
et j'essaye de le déployer sur un essaim de 7 machines

Quel serait l'équivalent sur docker-compose v3 pour obtenir quelque chose comme les dépendances de contrôle de santé? Si vous allez supprimer cette fonctionnalité dans la v3, vous ne devriez pratiquement jamais l'utiliser, ou du moins il devrait y avoir un chemin de migration pour cela.

Quelles sont les intentions de l'introduire dans un nouveau docker-compose v2.1 puis de le laisser tomber pour la v3? Je suis actuellement en train de configurer différents fichiers de composition pour nos applications, mais je ne veux pas utiliser des fonctionnalités qui seront supprimées dans la prochaine version et empêchent donc l'utilisation de la mise à jour vers une version plus récente du fichier docker-compose.

Pour le moment, vous devez supposer que la nouvelle syntaxe depends_on ne sera pas portée vers la v3, car nous n'avons pas l'intention de le faire actuellement.

Je sais que ce n'est pas la réponse que beaucoup de gens veulent, mais j'espère que cela contribuera à clarifier au moins.

Puis-je demander pourquoi ce n'est pas prévu? Je suppose que ce serait très utile de le faire.

Cela donne de la clarté, mais n'explique pas. Pouvez-vous expliquer pourquoi? Et sur les alternatives (si elles existent)?
Depend_on nous donne un moyen très simple de dépendre d'un service, plutôt que de le gérer à l'intérieur du conteneur (ce qui peut signifier envelopper une image tierce avec un script d'attente et devoir le maintenir).

@ shin- pourquoi l'avez-vous implémenté en 2.1, alors? Si les gens l'utilisent et en dépendent, ils ne pourront jamais le mettre à niveau. Sauf votre respect, cela semble être une très mauvaise planification de la part de vos gars.

Alors, quelle est la syntaxe depend_on prise en charge pour la v3? https://docs.docker.com/compose/compose-file/#version -3 ne mentionne pas depend_on, et lorsque j'utilise docker-compose v1.10 pour déployer une application, ni les saveurs v2 ou v2.1 depend_on ne fonctionnent pour moi dans un fichier de composition v3 ...

@mustafaakin

Puis-je demander pourquoi ce n'est pas prévu? Je suppose que ce serait très utile de le faire.

@hsmade

Pouvez-vous expliquer pourquoi? Et sur les alternatives (si elles existent)?

De https://github.com/docker/docker/issues/30404#issuecomment -274825244

depends_on est un no-op lorsqu'il est utilisé avec docker stack deploy . Les services en mode Swarm sont redémarrés lorsqu'ils échouent, il n'y a donc aucune raison de retarder leur démarrage. Même s'ils échouent plusieurs fois, ils finiront par se rétablir.


@brettmc

Alors, quelle est la syntaxe depend_on prise en charge pour la v3?

Lorsque vous utilisez docker-compose , la syntaxe prise en charge pour la v3 est la syntaxe de la liste (similaire à celle utilisée pour la version 2.0). Si vous utilisez docker stack deploy , les dépendances ne seront pas honorées (voir ci-dessus pour la justification)


Le format de la version 3 est la première étape pour passer de l'outil externe docker-compose à la solution intégrée docker stack . L'implémentation actuelle a ses bizarreries sur lesquelles on travaille. La prise en charge du format de la version 3 dans docker-compose est destinée à faciliter cette transition. Beaucoup de choses ont changé et améliorées dans Docker depuis l'introduction de fig / Compose, et cela signifie que beaucoup de choses qui avaient du sens sont maintenant devenues obsolètes. docker stack est un nouveau départ en utilisant de nouveaux concepts et élimine certains des syntaxes et concepts les plus difficiles à manier, de volumes_from à depends_on .
Si vous avez des inquiétudes particulières concernant certains de ces changements, veuillez les signaler sur le dépôt docker / docker sur lequel il est activement itéré.
Si vous n'êtes pas encore prêt à passer aux services Docker et à docker stack , n'hésitez pas à continuer à utiliser le format v2. Bien qu'il soit raisonnable de supposer que le projet prendra fin à un moment donné dans le futur, il sera annoncé bien à l'avance. Et après cela, le code restera disponible et open source.

Merci. Maintenant, cela a du sens.

Les services en mode Swarm sont redémarrés lorsqu'ils échouent, il n'y a donc aucune raison de retarder leur démarrage. Même s'ils échouent plusieurs fois, ils finiront par se rétablir.

IMHO ce n'est pas une bonne approche. Tous les services ne peuvent pas détecter correctement les autres services dont ils dépendent ne sont pas prêts, ils essaient plusieurs fois puis échouent, de sorte que le conteneur peut mourir plus tard. Nous devons encore introduire des scripts d'encapsulation de points d'entrée, ce qui n'est pas très agréable. La dépendance au contrôle de santé était très agréable, mais elle ne prend tout simplement pas en charge le mode essaim.

Les services en mode Swarm sont redémarrés lorsqu'ils échouent, il n'y a donc aucune raison de retarder leur démarrage. Même s'ils échouent plusieurs fois, ils finiront par se rétablir.

Salut tout le monde!
Cela signifie-t-il que si, par exemple, j'ai un service qui s'exécute et termine son travail très rapidement (et ne devrait fonctionner qu'une seule fois par conception), il sera redémarré encore et encore et encore ... à plusieurs reprises?

@ Marvel77 Par défaut, oui, mais vous pouvez remplacer ce comportement en utilisant la section deploy.restart_policy : https://docs.docker.com/compose/compose-file/#restartpolicy

@ shin- Merci beaucoup!

@mustafaakin En fait, la meilleure pratique est (IMHO) d'avoir une connexion tolérante aux pannes aux services dont vous dépendez. Par exemple, si vous utilisez une base de données, vous pouvez retarder le démarrage jusqu'à ce qu'il réponde. Mais comment gérez-vous un redémarrage de la base de données? Votre application devrait pouvoir récupérer de cela, et vous n'avez pas non plus besoin de dépendre de 'depend_on'.
Dans un sens, la dépréciation est une bonne chose. Ces commodités nous rendent paresseux.

@hsmade Mais presque tous les init (upstart, systemd) dépendent de la relation. Ce n'est donc pas qu'être paresseux, c'est ce qui a du sens. Le démon SSHD ne démarre pas tant que votre périphérique réseau n'est pas prêt. Je n'ai aucun contrôle sur tous les systèmes dont je dispose, oui je peux rendre mes systèmes tolérants aux pannes. Mais supposons que A dépend de B. A prend un certain temps à s'initialiser, ce n'est pas très déterministe. Alors, comment pouvez-vous écrire une politique de redémarrage sur B? redémarrer pour toujours? Et si tu ne veux pas ça?

C'est un problème plus important que Compose, Compose ne fait que les démarrer. Swarm est ce qui les fait courir, donc je pense que Swarm devrait gérer cette dépendance à la relation de santé.

@mustafaakin Je ne pense pas que vous puissiez comparer les micro-services en cours d'exécution dans un environnement conteneurisé avec les systèmes init classiques. Cela n'a pas vraiment de sens. Je pense que l'idée des micro-services est qu'ils sont des entités autonomes et minimales. Ils ont une définition très claire de leur API, etc. Ils ne doivent assumer aucun statut de leur monde extérieur. Oui, il faudrait une base de données, mais non, vous ne pouvez pas supposer qu'elle est là. Comme j'ai essayé de le dire, savoir que votre dépendance au démarrage est le moindre de vos problèmes, il est plus important de bien le gérer quand il disparaît et devrait également résoudre le premier.

Mais là encore, ce sont mes pensées sur la question, et je pourrais me tromper;)

Ouais, cela n'a pas de sens pour les microservices, mais tout n'est pas un microservice, je lance Hadoop dans un conteneur. Docker n'est pas réservé aux microservices. Comme je l'ai dit, c'est génial pour les environnements que j'ai le contrôle, mais dans les choses que je n'ai pas de contrôle, il faut envelopper le point d'entrée des services. Il vient d'être résolu avec depend_on avec healtcheck, je pense juste que ce serait super de l'avoir dans Swarm également. Redémarrer continuellement n'est que le choix d'un homme paresseux.

Les mecs,

Je pense qu'il y a une sorte de conception erronée de "tolérance aux pannes" et une sorte de "première initialisation".
Convenez que l'approche semble assez bonne pour la première, mais la seconde est une vraie douleur.
J'imagine que non seulement moi-même, mais en général on aurait généralement besoin de démarrer les services dans un ordre particulier car ils dépendent plus ou moins les uns des autres.

Avoir des redémarrages continus lors de la phase d' initialisation et attendre que les services commencent à un moment donné dans le bon ordre par eux-mêmes est comme un cauchemar - on ne peut pas prévoir de «temps d'arrêt» pour le processus de démarrage si le pire devait arriver. Non seulement le pire, mais parfois il y a un temps de "maintenance" quand quelque chose doit changer et personne ne serait en mesure de prédire combien de temps il faudrait au système pour démarrer réellement, parce que différents services sont redémarrés par essaim encore et encore à nouveau en attente de la bonne commande.
J'ai essayé et attendu de voir comment cela se passerait avec 7 conteneurs et pendant 20 minutes, _swarm_ n'a toujours pas compris et tout le service était toujours en panne.
Ainsi, on ne peut même pas dire combien de temps il faudrait pour ramener et restaurer toute l'infrastructure car on ne sait vraiment pas combien de temps le _ démarrage initial_ prendrait.
Cela me semble absurde.

Je ne pense pas que je puisse vraiment entrer dans la "production" sans une telle prévisibilité même si cela est censé se produire rarement (complètement vers le bas) - mieux vaut ne jamais arriver.
Mais exactement si cela se produit encore, je serais sur place et je serai mis au défi de restaurer dès que possible et juste à ce moment-là et sous pression, je n'aurais absolument aucune idée de combien de temps mes conteneurs commenceraient simplement parce qu'ils continuent à redémarrer pendant le _startup._

@ozlatkov Cela devrait vraiment être publié sur le suivi des problèmes de docker / docker, pas ici.

@ shin- Merci! Je l'ai déplacé vers docker / docker tracker:

https://github.com/docker/docker/issues/31333

Je pense que c'est vraiment dommage que l'équipe Docker suppose que Docker Swarm est utilisé. Compose est censé être un outil autonome totalement fonctionnel.

Cependant, nous utilisons beaucoup Docker Compose dans nos pipelines de test et une suppression aussi fondamentale de fonctionnalités (sans donner d'alternative viable) a vraiment des effets négatifs dramatiques sur vos utilisateurs.

Je suis actuellement en train de passer en revue un PR très laid des membres de mon équipe où ils essaient de trouver toutes sortes de solutions de contournement (puisque nous comptons beaucoup sur cette fonctionnalité), y compris rester sur Compose 2.X pour toute l'éternité.

Docker est censé nous aider à atteindre nos objectifs, pas rendre les choses plus difficiles en supprimant les fonctionnalités critiques sur lesquelles de nombreuses équipes comptent déjà.

Veuillez reconsidérer le portage de tout cela dans Docker Compose 3.

Très appréciée.

Pour la 100e fois maintenant: il n'y a aucune raison d'utiliser le format v3 si vous n'avez pas l'intention d'utiliser les services swarm.

Cela signifie-t-il que l'équipe s'engage à prendre en charge les formats 2.X pour ceux qui utilisent compose comme outil de développement autonome?

Exactement ma question: l'équipe Compose s'engage-t-elle à supporter le format v2 pour toujours?

Nous ne pouvons pas standardiser sur Docker Compose si le format v2 doit être abandonné à tout moment.

J'ai l'impression que cela force tous les conteneurs dans un modèle init container , supprime la politique de redémarrage du docker et crée une approche hacky de l'ordre de démarrage. Doit-on supposer que> = v3 de compose se déplacera dans cette direction pour se concentrer sur les piles et créer des bundles d'applications? Et si c'est vrai, pourriez-vous m'indiquer comment maintenir l'ordre de démarrage dans une pile de docker? Est-ce que l'approche wait-for-it.sh ou dockerize là?

Quel est l'équivalent déclaratif de docker-compose.yml pour une pile?

Salut les gars, quelle est la meilleure pratique si j'ai l'intention d'utiliser docker stack et de me débarrasser de docker-compose?

Cela semble être la solution, mais avoir une sorte de scripts hacky pour lancer des conteneurs ne semble pas être une bonne pratique. Le fait-il?

Merci.

@mustafaakin Merci pour votre vote contre! Très utile ❤️

@VinceOPS Je ne suis pas sûr des "meilleures pratiques" mais j'ai utilisé des bilans de santé et restart: always donc ça tourne juste jusqu'à ce que ça marche ¯ \ _ (ツ) _ / ¯

@hutchic Mais comme mentionné dans la conversation ci-dessus, il ne pouvait pas avoir de date de fin, une sorte de redémarrage circulaire en cas d'échec.

Pourquoi l'équipe Docker a-t-elle supprimé cette fonctionnalité dans la version3 et la refuser de l'ajouter?

@ tianhao-au voir la discussion sur https://github.com/moby/moby/issues/31333 (et https://github.com/moby/moby/issues/31333#issuecomment-409143581)

Pour composer, j'ai également laissé une suggestion dans https://github.com/moby/moby/issues/31333#issuecomment -333265696 (avoir un x-depends_on )

Ce changement de fonctionnalité est littéralement la raison pour laquelle je n'utilise plus docker-compose. Si j'utilise docker en production et docker-compose localement pour les environnements de développement, je suis maintenant obligé de faire en sorte que mes conteneurs docker se comportent radicalement différemment en développement qu'en production. En production, je compte sur un système d'orchestration pour assurer la santé et l'ordre de mes déploiements. En pays de développement, cette orchestration était réalisée par docker-compose. Maintenant, j'écris un tas de scripts mutilés pour vérifier la santé des choses pour orchestrer mon système. Si je veux faire ça, pourquoi ne pas simplement écrire du golang pour gérer mes dockers et en finir avec ça. Un peu déçu, il a été abandonné. Juste mon 2p

Essayer d'utiliser la dernière version de docker-compose pour rendre les choses plus pérennes et est tombé sur ce problème. C'est triste.

Cette page vous a été utile?
0 / 5 - 0 notes