Compose: docker-compose up ne récupère pas la dernière image si l'image existe localement

Y a-t-il une raison pour laquelle docker-compose pull && docker-compose up n'est pas pratique ?

Je pense que la plupart des points pour/contre sont les mêmes que ceux discutés dans le numéro pour ajouter --pull à docker run . Ils vont de l'ux et de la cohérence à la facilité de script/workflow, à l'intégration de swarm (par curiosité, que fait docker-compose pull avec swarm ?).
Je ne pense pas que ce soit un problème majeur, mais quelque chose à considérer. Le même type d'utilisateurs qui souhaitait la fonctionnalité ailleurs l'apprécierait probablement également ici.

J'essaie d'exécuter "docker-compose build", mais cela n'actualise pas l'image référencée dans le Dockerfile, sauf lorsque vous utilisez _--pull_.

Vous pouvez également construire des conteneurs au démarrage avec _up --build_. Mais les images les plus récentes ne seront pas extraites. Pouvons-nous nous attendre à quelque chose comme "docker-compose up --build --pull" (ou similaire) ? Il est peut-être logique de le placer dans le YML car tous les builds ne doivent pas être actualisés (cfr. images locales).

Au lieu (ou en plus) d'ajouter --pull au cli, qu'en est-il de l'ajout de quelque chose sur la définition du service dans le fichier docker-compose ?, par exemple

version: '2'

services:

  postgres:
    image: postgres
    container_name: postgres
    pull: true
    ports:
     - '5432:5432'

De cette façon, s'il y a un service dont je me fiche d'être le dernier et que je le fais, docker-compose ne perdra pas de temps à télécharger des images qui ne m'intéressent pas

Je suis venu ici à la recherche de cette fonctionnalité car nous l'utilisons dans notre cluster de production de Kubernetes. Là, la balise est "imagePullPolicy" et elle peut être définie sur "IfNotPresent", "Toujours" ou "Jamais". Quelque chose de similaire pour un environnement de composition serait bien.

Dans notre cas, nous devons reconstruire l'image de base tous les jours pour nous assurer que les dernières dépendances sont mises à jour pour les applications. Docker composer pour extraire la dernière image avec la même balise est une fonctionnalité intéressante. Pourquoi pas !

Des nouvelles à ce propos?

Salut,

Des nouvelles de ce problème ?

+1

+1

Comme je l'ai mentionné précédemment, docker-compose pull && docker-compose up est fonctionnellement identique. Il n'y a aucune bonne raison d'ajouter un autre indicateur pour cela.

Imaginez que git n'ait pas pull car git fetch && git merge origin/master est fonctionnellement identique.

L'ajout d'une balise pull: true peut être utile par exemple si certaines des images que vous utilisez dans votre fichier de composition sont dans votre cache. docker-compose pull pull _all_ des images dans votre fichier de composition, et cette extraction échouera si ces images sont dans votre cache mais pas dans le référentiel.

+1

Un scénario dans lequel docker-compose pull && docker-compose up devient peu pratique est lorsque vous utilisez plusieurs fichiers docker-compose. Vous pouvez facilement vous retrouver avec une commande comme docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up .

Nous avons un scénario dans lequel nous développons localement et nous voudrions seulement extraire certaines des images à distance. Celui (ou plusieurs) développé localement doit rester intact. Dans ce cas, nous sommes obligés de créer/extraire des images manuellement avant d'exécuter docker-compose.
Un pull: true serait bénéfique.

@shin- et si vous revoyiez votre décision à ce sujet ? Je pense que les commentaires et les réactions à leur égard semblent suffisamment auto-descriptifs.

Non ça va. Il s'agit d'un projet open source, si vous n'êtes pas d'accord avec l'approche conservatrice que nous adoptons lors de l'ajout de fonctionnalités, vous pouvez le forker.

Mettez-vous d'accord sur l'ajout d'un indicateur à la commande docker-compose up ou d'un paramètre à la configuration. Nous utilisons une image de base avec une configuration supplémentaire qui a tendance à changer fréquemment au cours du processus de développement. Nous voulons créer un environnement infaillible, où un développeur peut simplement exécuter docker-compose sans déboguer ce qu'il n'a pas besoin de déboguer.

En fait, j'ai atteint ce fil après que mon collègue ait vérifié ma demande d'extraction et ait déclaré qu'il avait cassé la construction. Et la raison en est que l'image de base manquait simplement quelques packages - mais a été exécutée dans le Dockerfile final. Ce serait une bonne fonctionnalité, mais apparemment pas quelque chose que vous avez utilisé, @shin- .

Nous serions heureux si vous introduisiez cette fonctionnalité dans la nouvelle version.

@shin- Je pense que @blockloop a montré avec l'exemple git quel point l'option pull est pratique / utile. Honnêtement, j'espère que pour de telles choses, il n'est pas nécessaire de forger un projet.

Je comprends tout à fait l'approche conservatrice, mais j'ai l'impression qu'elle n'est même plus considérée comme une option. Peut-être qu'il peut faire partie d'une prochaine version ?

Un pull: IfNotPresent serait bien. Il pourrait donc être possible d'utiliser des solutions de secours comme
1) utiliser l'image locale
2) tirer si n'est pas local
3) construire s'il n'est pas capable de tirer

@shin- vous continuez à demander une raison pour laquelle la méthode && ne le coupera pas, et ma raison est la suivante. Je l'utilise pour une image "app" à tester (Puppet PDK/Onceover). Le fichier de composition fait partie du référentiel de modèles. Par conséquent, lorsqu'un développeur de marionnettes (vraiment des gens d'exploitation) a besoin de créer un nouveau module, il crée ce référentiel. Jenkins exécute l'image pour la validation de la fusion sur ce référentiel de module (en interne, nous avons un plugin jenkins qui gère la mise à jour des travaux.) Maintenant, les personnes qui l'utilisent ne seront pas des experts docker, et devoir leur dire de faire le && est un extra étape qu'ils peuvent (et vont probablement) bousiller. Je ne vois pas pourquoi ce serait difficile ou quel inconvénient cela créerait, mais ce raisonnement semble être une raison valable pour l'ajouter. Cela nous aide, les développeurs, à envoyer des choses qui nécessitent moins d'instructions et d'étapes.

bref c'est... pour se protéger de la paresse

Voici une meilleure raison : && est synchrone. Mais docker-compose a intégré un excellent support pour l'exécuteur parallèle qui optimise ce genre de choses. docker-compose up --pull --build pourrait commencer à créer l'image et l'exécuter dès qu'elle est extraite, au lieu d'attendre que toutes les images soient extraites et ensuite seulement commencer à construire

@shin suppose que l'on utilise pour nous-mêmes sur une base très rare avec de rares mises à jour Dockerfiles.
Mais si vous mettez chaque jour à jour une image Docker que les développeurs utiliseront, cela entraînera rapidement des problèmes de développement si un seul développeur oublie de tirer l'image qu'il doit faire tous les jours (surtout ceux qui ne sont pas vraiment familiers avec docker, et c'est en fait pas leur affaire de le savoir et de s'en souvenir). Catastrophe programmée.
Est-ce un gros problème de simplement ajouter cette option au docker-compose.yml ?
Je veux dire, cela ne changera pas d'autres choses, cela ajoute juste des fonctionnalités. ..

c'est la principale raison pour laquelle je ne peux pas utiliser docker-compose et j'ai besoin d'écrire des scripts wrapper avec les commandes d'exécution de docker héritées, mais c'est moche.

Essayant de comprendre les circonstances dans lesquelles ce ticket a été fermé - quelqu'un pourrait-il développer s'il vous plaît ? Si cela peut vous aider, je suis pro en ajoutant un drapeau --pull à docker-compose up .

Je pense qu'il y a deux propositions en discussion ici :

1 - Cela doit-il être ajouté en tant qu'option de ligne de commande ? En fait, le problème posté.
2 - Si cette option doit être ajoutée au fichier YML.

Je suis tout à fait d'accord avec ce dernier, bien que @shin n'ait pas fait de commentaire à ce sujet. Le rejeter avec le même argument, qu'il est fonctionnellement identique serait incohérent. Tout dans le fichier YML est fonctionnellement identique à la ligne de commande.

Je peux voir son point de vue en ce qui concerne le premier, mais je pense que la justification est un peu trop large. Je peux faire à peu près n'importe quoi sur la ligne de commande en enchaînant une série d'instructions avec && . Soyons clairs, ce sont deux commandes, pas une. Les critères devraient être les suivants : y a-t-il une demande suffisante pour cela pour qu'il soit possible de le faire en une seule étape au lieu de deux ? Parce que s'il est utilisé assez souvent, le nombre de commandes enchaînées ne cesse de croître. Le fait est que lorsque vous écrivez un script, vous voulez qu'il soit aussi succinct que possible.

@orodbhen pas besoin de discuter. Il n'y a personne qui nous écoute ici.

Pour ajouter au raisonnement pour l'ajout d'un drapeau... au cours de l'année dernière environ, je me suis retrouvé à chercher cette chose même et je me suis retrouvé ici pour découvrir que j'avais déjà fait plusieurs commentaires en faveur d'un Drapeau --pull . J'imagine que je me retrouverai ici aussi la prochaine fois.

@shin-, veuillez rouvrir ou verrouiller ce problème. Il est ouvert depuis près de deux ans, recevant des commentaires constants (à la fois intelligents et divertissants), des dizaines de participants et des centaines de votes.
Cependant, il semble clair que l'équipe de composition n'est pas intéressée par cette fonctionnalité. Ne perdons donc pas de temps à qui que ce soit et ne laissons place à de faux espoirs que le problème reviendra si ce n'est pas le cas.

Veuillez vous abstenir d'utiliser des blasphèmes.

Bien que je pense qu'il y a une utilité dans la demande d'origine, beaucoup de personnes dans ce fil semblent oublier l'esprit de l'open source : si c'est si important pour vous, vous êtes libre de bifurquer et de modifier à votre guise. Je comprends que vous ne souhaitiez peut-être pas maintenir un fork, mais se plaindre que les mainteneurs n'implémenteront pas une fonctionnalité est contre-productif : ce n'est pas ainsi que les fonctionnalités sont implémentées, et les mainteneurs voudront moins vous aider.

Peu importe qu'il y ait une demande pour une fonctionnalité, surtout si personne ne paie pour utiliser le produit. Il ne suffit pas d'intégrer toutes les fonctionnalités que tout le monde souhaite dans le produit principal. Nous devons respecter la réponse de @shin- à ce sujet et croire qu'il y a de bonnes raisons de ne pas la mettre en œuvre.

@lig Ne cherche pas à discuter. Juste faire le cas.

Selon vos besoins, le fork peut être excessif. Dans mon cas particulier, j'ai trouvé que Compose ne se prêtait pas très bien au script, à moins qu'il ne s'agisse d'un script très basique. L'utilisation de l'API Docker Python et de mon propre fichier YAML pour préserver les paramètres est plus polyvalent et souvent plus simple.

@ bdharrington7 - mais vous devez entretenir votre fork et le garder installé sur toutes les machines que vous utilisez (ce qui est rarement possible). Attention, Docker Compose est populaire, d'autres diraient : « qui s'en soucie ? »

La réalité est que le commentaire "c'est open source, créez votre propre fork", n'est tout simplement pas réaliste. Les frais généraux liés à la maintenance de votre propre fork et à sa mise à jour avec les dernières modifications du référentiel principal en valent rarement l'investissement. Une bien meilleure approche consiste à adresser une pétition aux responsables et à fournir les bonnes raisons pour lesquelles la fonctionnalité est importante.

Malheureusement, cela entraînera toujours des problèmes comme celui-ci avec une certaine insatisfaction. Je pense que le principal problème ici, c'est qu'il ne semble pas y avoir eu d'argument valable pour expliquer pourquoi c'est une mauvaise idée. L'argument

"Nous devons respecter la réponse de @shin- à ce sujet et croire qu'il y a de bonnes raisons de ne pas la mettre en œuvre."

ne va tout simplement pas satisfaire les gens. La communauté a besoin de voir les "bonnes raisons".

Le fait demeure que frapper vos poings et mendier entraînera rarement
pour obtenir ce que vous voulez, ce qui se passait beaucoup dans ce fil.
Il y a également eu beaucoup de bons cas d'utilisation dans le fil,
mais à moins que vous ne payiez réellement pour le logiciel, il n'y a aucune obligation
de la part des responsables de faire quoi que ce soit à ce sujet, ni de donner de raisons pour lesquelles. je suis
juste en donnant à @shin- et à la société le bénéfice du doute ici.
Le samedi 24 mars 2018 à 5h39, Greg Pakes [email protected] a écrit :

La réalité est que le commentaire "c'est open source, créez votre propre fork",
n'est tout simplement pas réaliste. Les frais généraux liés à l'entretien de votre propre fourche et
le tenir à jour avec les dernières modifications du référentiel principal
fait que l'investissement en vaut rarement la peine. Une bien meilleure approche consiste à adresser une pétition
les responsables et fournir les bonnes raisons pour lesquelles la fonctionnalité est
important.

Malheureusement, cela entraînera toujours des problèmes comme celui-ci avec certains
insatisfaction. Je pense que le problème principal ici est qu'il ne semble pas
ont été un bon argument avancé pour expliquer pourquoi c'est une mauvaise idée. Les
argument "Nous devrions respecter la réponse de @shin- http:///shin- à ce sujet,
et je crois qu'il y a de bonnes raisons de ne pas le mettre en œuvre.
va satisfaire les gens. La communauté a besoin de voir les "bonnes raisons".

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/compose/issues/3574#issuecomment-375805478 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEV8Q9RseMxYS8KGyD9E2BK0pZv7OJpuks5thWt7gaJpZM4IyPQh
.

Le fait est que frapper des poings et mendier aboutira rarement à obtenir ce que vous voulez

Ce n'est tout simplement pas vrai. Bien que je ne tolère pas cela comme une stratégie pour demander un travail gratuit, c'est en fait assez efficace. C'est exactement comme ça que fonctionnent les pétitions et plus il y a de gens qui « martèlent leurs poings », plus il y a de chances que les gens qui comptent en prennent note. Encore une fois, je ne dis pas que je l'approuve

Il y a également eu beaucoup de bons cas d'utilisation dans le fil

Je peux voir un cas, qui se résume essentiellement à "vous pouvez utiliser ces deux commandes à la place". Mais clairement, les gens n'en veulent pas. Alors engagez-les et expliquez-leur pourquoi il s'agit d'un bon travail.

il n'y a aucune obligation de la part des responsables de faire quoi que ce soit à ce sujet, ni de donner de raisons pour lesquelles

Je suis d'accord. Mais vous devez vous attendre à ce que les gens soient frustrés par cela. C'est une attitude méprisante. En fin de compte, tout le monde ici est dans la même équipe. Les personnes qui maintiennent le projet et les utilisateurs du projet veulent tous que le projet réussisse.

Quel produit est gratuit exactement ici ? Si j'utilise docker-compose.exe et que j'exécute docker EE, cela ne signifie-t-il pas vraiment que je paie pour le produit ?

IMHO --build devrait tirer ; aucun autre indicateur ou configuration n'est nécessaire. si vous ne voulez pas qu'il tire, spécifiez la version de l'image.

@ET-CS : les versions d'image ne sont que des balises et peuvent toujours changer en un hachage différent

bon point @lifeofguenter merci. peut composer vérifier si l'image a changé en un hachage différent et tirer dans ce cas aussi?

Dans un tel scénario, je pense que je voudrais que tous les environnements (dev, prod) aient la même image que possible maintenant que les développeurs utilisent le nouveau hachage tandis que la production utilise l'ancien.

Je m'attendrais à ce que --build apporte tout au plus tard.

Voici donc un bon cas d'utilisation :

J'ai implémenté un CI pour mon projet de microservices, qui extrait de nouvelles images vers un registre lorsque nous développons de nouvelles fonctionnalités dans le service backend. L'équipe frontend (qui connaît peu de docker) doit avoir un moyen de faire apparaître l'intégralité de la pile backend sur ses machines locales, et elle s'appuie sur les images les plus mises à jour. Si quelque chose se brise, alors seulement ils se souviendront de tirer les images.

Voici ce qui s'est passé : un sprint de développement entier a échoué parce que quelqu'un a oublié de mettre à jour les images principales et a développé une fonctionnalité complète basée sur une ancienne version. La faute à l'équipe frontend, mais cela pourrait être évité avec cette fonctionnalité (ce que je ferai en utilisant des scripts wrapper).

@agnjunio Cela semble vraiment malheureux, désolé. Cependant, si la personne a oublié d'exécuter docker-compose pull , je ne sais pas en quoi il est moins probable qu'elle oublie d'utiliser un indicateur hypothétique --pull ?

@shin- Désolé, j'ai oublié de mentionner une chose importante: la solution dans mon cas est d'avoir la balise pull: always à l'intérieur du yaml, peut-être à l'intérieur des options image:

@ET-CS de https://github.com/docker/compose/issues/3574#issuecomment -382451356 :

Je m'attendrais à ce que --build apporte tout au plus tard.

IMHO --build devrait tirer; aucun autre indicateur ou configuration n'est nécessaire. si vous ne voulez pas qu'il tire, spécifiez la version de l'image.

AFAIK qui bloquerait le cas d'utilisation avec une construction utilisant un FROM qui est le résultat d'une construction depends_on .

version: "3.4"
services:
  some-base-image:
    image: our/base-image
    build:
      context: ./base
  # This Dockerfile has FROM our/base-image
  coolthing:
    depends_on:
    - some-base-image
    build:
      context: ./coolthing

Je suis en faveur d'un drapeau comme suggéré dans https://github.com/docker/compose/issues/3574#issuecomment -252861859 et https://github.com/docker/compose/issues/3574#issuecomment -279460839

@solsson
Je ne suis pas sûr de voir pourquoi ou ce que cela bloque dans ce cas d'utilisation.
s'il vous plaît partager plus d'informations à ce sujet si vous le pouvez.

@shin- La différence ici serait que si je lance docker-compose up --help je recevrais un descriptif sur la façon d'utiliser la dernière image. ce fil et je dois lire tous les commentaires pour comprendre que docker-compose up ne fait pas ce dont j'ai besoin/veux, donc maintenant je dois exécuter deux commandes.

@agnjunio Cela semble vraiment malheureux, désolé. Cependant, si la personne a oublié d'exécuter docker-compose pull, je ne sais pas en quoi il est moins probable qu'elle oublie d'utiliser un drapeau hypothétique --pull?

Chaleureusement

L'une des principales raisons pour lesquelles nous utilisons docker-compose est la possibilité de placer un fichier docker-compose.yaml dans un référentiel et d'avoir une sortie reproductible lorsqu'un développeur extrait le référentiel et exécute docker-compose up [service] .

Nous utilisons plusieurs services dans nos fichiers docker-compose qui effectuent des tâches telles que l'exécution de codegen et l'exécution d'un outil pour déréférencer un schéma JSON dans un seul fichier.
Il est essentiel de s'assurer que ces outils sont à jour, surtout si nous mettons à jour notre image de codegen pour résoudre un problème critique commun observé dans tous les projets.

Avoir la possibilité de placer :

services:
  codegen:
    image: myimage:latest
    pull: Always

conserverait notre capacité à ce qu'un développeur exécute de manière fiable docker-compose et obtienne les résultats attendus, plutôt que d'avoir à compléter chaque référentiel avec une documentation pour rappeler aux développeurs d'exécuter une chaîne de commandes ou de scripts pour extraire les dernières images disponibles avant de démarrer les applications .

Il ne s'agit pas de "la fonctionnalité existe déjà pour le faire en exécutant ces commandes", c'est une meilleure expérience utilisateur.

Imaginez quand quelqu'un a suggéré d'ajouter --stop à docker-compose rm que la réponse était "qu'est-ce qui ne va pas avec docker-compose stop myapp && docker-compose rm myapp , ou si quelqu'un avait demandé la mise en œuvre de docker-compose down ils étaient juste demandé pourquoi docker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ... n'est pas pratique ?

Ce fil a été soulevé il y a 2 ans et je pensais toujours que l'ajout d'un indicateur dans le docker-compose.yml était le meilleur moyen. Dans mon cas, nous avons environ 37 services dans un essaim, et la mise à jour de 4 à 5 images à partir de ce total n'est pas facile. Je viens de créer un shell pour l'instant qui peut surveiller le changement à partir du référentiel et effectuer le tirage pour l'image spécifique avant de recréer le service s'il a été mis à jour.

Un autre point ici est que docker-compose up a une option --quiet-pull . Lorsque j'ai essayé pour la première fois de déterminer si up incluait un pull, j'ai supposé que c'était le cas en fonction de sa présence. Il va de soi que ne pas utiliser --quiet-pull entraîne un pull verbeux.

Deux ans de personnes essayant de convaincre les responsables de Docker Compose qu'avoir une option --pull serait une meilleure expérience sans avoir à exécuter une commande séparée. Si les mainteneurs de docker-compose implémentaient simplement la fonctionnalité, pour commencer, la vie de tout le monde serait meilleure. Il semble clair que les mainteneurs actuels ne veulent pas ajouter cette fonctionnalité pour l'amélioration de la communauté.

Peut-être devrions-nous simplement forker docker-compose et le mettre à jour nous-mêmes.

Si quelqu'un soumettait un PR, aurait-il une chance d'être accepté ?
C'est open source. J'ai été sur le point d'examiner la mise en œuvre de quelques
fois moi-même. Je suppose que cela pourrait être accepté, sinon ce rôle serait fermé,
droit?

Je suis tombé sur ce même problème et putain de merde, un tas de pleurnichards ici. Il s'agit d'un logiciel libre et gratuit. Donnez une pause aux mainteneurs. Je suis sûr qu'ils ont des choses bien plus importantes sur lesquelles travailler que ça. Si quelqu'un en a tellement besoin, pourquoi n'ouvrez-vous pas un PR ? Si le code est propre avec un risque minimal, je ne vois pas pourquoi ils ne l'accepteraient pas.

Cette question devrait être rouverte car la discussion manque d'une bonne raison de ne pas mettre en œuvre cette demande. Les gens sont plus susceptibles de commencer à travailler sur des problèmes _ouverts_ plutôt que sur des problèmes fermés.

Le fait que ce problème « clos » soit resté si actif suggère qu'il n'a pas été bien traité.

Malheureusement, j'ai constaté que les réponses aux messages de problème sur certains dépôts GitHub ne sont pas très utiles. Le ton est souvent laconique et suggère que les commentaires sont moins que bienvenus.

Certains ont souligné ici qu'il s'agit d'un projet open source et (du moins la plupart d'entre nous) ne payons pas de clients. Cependant, il convient également de noter que la soumission de rapports de problème constitue un investissement de temps important, d'autant plus si vous participez à la résolution du problème.

Un utilisateur ou un développeur, ayant passé du temps à résoudre un problème et trouvé une solution de contournement, décidera alors s'il souhaite consacrer plus de temps à le signaler. Une réponse peu réceptive des responsables les amènera probablement à choisir de ne pas s'en soucier la prochaine fois.

Le logiciel n'est pas vraiment "GRATUIT", au sens "bière gratuite". car nous essayons tous de participer à son amélioration. Avoir des personnes disposées à tester votre logiciel et à fournir des commentaires est une ressource précieuse. Ceux qui ont les compétences de programmation requises sont même prêts à contribuer au code, mais ils veulent une sorte d'indication que leurs contributions sont les bienvenues avant de passer du temps dessus.

De toute évidence, les commentaires qui se plaignent simplement d'un problème et demandent qu'il soit corrigé ne sont pas utiles, mais la majorité ne le font pas, et des commentaires comme "c'est open source, il suffit de le forger" sont tout aussi inutiles.

@shin- Pourquoi "--build" a-t-il été implémenté ? Est-ce différent de docker-compose build && docker-compose up ? J'essaie juste de comprendre la différence philosophique entre --build (qui a été ajouté) et --pull (qui a été jugé redondant). Comprendre le processus de pensée pourrait m'aider à me rappeler comment les choses fonctionnent. ET si le problème est ouvert, je suis heureux de soumettre un PR. @everybodyelse... est-ce vraiment "l'esprit de l'opensource" que si vous n'aimez pas quelque chose, vous bifurquez ? Je pensais que l'esprit de l'opensource était "si vous n'aimez pas quelque chose, vous a) aidez à contribuer aux exigences si c'est là que vous êtes, b) aidez à contribuer au code si vous le pouvez" et que vous n'avez forké que si vos exigences étaient très clairement quelque chose dont vous seul bénéficieriez. c'est-à-dire que je pensais que nous bénéficions le plus lorsque nous partageons - mais je suis heureux d'être éduqué ici.

Après deux ans d'insistance, en donnant de bonnes raisons qui sont ignorées et un énorme soutien de la communauté pour que cela soit réellement mis en œuvre, je dirais que cette fonctionnalité ne le fera pas simplement parce que @shin- ne le veut pas. Aucune raison d'insister.

Il y a une raison : docker ne rafraîchira pas les images si un pull échoue et il n'y a aucune bonne raison de ne pas le faire.

Je recherche la politique d'extraction d'image kubernetes dans docker compose, ce serait formidable si le "pull" peut être utilisé.

@shin- Arrête d'être enfantin. De nombreuses bonnes raisons de mettre en œuvre cette fonctionnalité ont été mentionnées. Soyez au moins ouvert aux RP...

Vous pouvez être en désaccord avec moi, mais je suis déçu que vous ayez recours à des ad hominems, @Wenzil. Notre communauté se tient généralement à un niveau plus élevé.

@shin- Notre communauté pense principalement la même chose sans le dire pour la raison que vous avez mentionnée. @Wenzil est juste assez honnête pour le dire à voix haute.
Beaucoup de gens que je connais préfèrent ne pas s'embêter et ont renoncé à essayer de convaincre docker-compose de se diriger vers ses utilisateurs.

Beaucoup de gens sont en désaccord @shin- pour des raisons très valables décrites. À tout le moins, cela devrait être une déclaration de service. L'enchaînement des commandes bash n'est pas une solution particulièrement bonne pour les déploiements programmatiques.

Beaucoup de gens que je connais préfèrent ne pas s'embêter et ont renoncé à essayer de convaincre docker-compose de se diriger vers ses utilisateurs.

Cette. Et ce n'est pas seulement docker-compose. Docker-stack, docker-machine et docker-cli sont tous similaires.

https://github.com/docker/compose/issues/6316#issuecomment -438564025

Verrouillage car cela continue de dérailler. Nous réévaluerons en fonction du sort de https://github.com/docker/cli/pull/1498

En guise pull_policy mise à jour, nous avons décidé en interne d'envisager d'ajouter un paramètre