Compose: docker-compose up zieht das neueste Image nicht herunter, wenn das Image lokal vorhanden ist

Gibt es einen Grund, warum docker-compose pull && docker-compose up unpraktisch ist?

Ich denke, die meisten Punkte dafür/dagegen sind die gleichen wie in der Ausgabe für das Hinzufügen von --pull zu docker run . Sie reichen von ux und Konsistenz über einfaches Skripting/Workflow bis hin zur Schwarmintegration (was macht docker-compose pull aus Neugierde mit Schwarm?).
Ich denke nicht, dass es ein großes Problem ist, aber etwas, das man bedenken sollte. Die gleiche Art von Benutzern, die die Funktion an anderer Stelle wünschten, würde sie wahrscheinlich auch hier genießen.

Ich versuche, "docker-compose build" auszuführen, aber das in der Dockerfile referenzierte Bild wird nicht aktualisiert, es sei denn, Sie verwenden _--pull_.

Sie können Container auch beim Start mit _up --build_ bauen. Aber die neuesten Bilder werden nicht gezogen. Können wir sthg wie "docker-compose up --build --pull" (oder ähnliches) erwarten? Vielleicht ist es sinnvoll, es im YML zu platzieren, da nicht alle Builds aktualisiert werden müssen (vgl. lokale Images).

Anstatt (oder zusätzlich) --pull zur cli hinzuzufügen, was wäre, wenn Sie etwas zur Service-Definition in der docker-compose-Datei hinzufügen?, z

version: '2'

services:

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

Auf diese Weise wird Docker-Compose keine Zeit damit verschwenden, Bilder herunterzuladen, die mich nicht interessieren, wenn es einen Dienst gibt, der mir egal ist, und einen, den ich tue

Ich bin auf der Suche nach dieser Funktion hierher gekommen, weil wir sie in unserem Produktionscluster von Kubernetes verwenden. Dort heißt das Tag "imagePullPolicy" und kann auf "IfNotPresent", "Always" oder "Never" gesetzt werden. Etwas Ähnliches für eine Compose-Umgebung wäre schön.

In unserem Fall müssen wir das Basis-Image jeden Tag neu erstellen, um sicherzustellen, dass die neuesten Abhängigkeiten für Anwendungen aktualisiert werden. Docker Compose-Up, um das neueste Image mit demselben Tag abzurufen, ist eine nette Funktion. Warum nicht !

Irgendetwas Neues darüber?

Hi,

Gibt es Neuigkeiten zu diesem Thema?

+1

+1

Wie ich bereits erwähnt habe, ist docker-compose pull && docker-compose up funktional identisch. Es gibt keinen guten Grund, dafür ein weiteres Flag hinzuzufügen.

Stellen Sie sich vor, dass git nicht über pull weil git fetch && git merge origin/master funktional identisch ist.

Das Hinzufügen eines pull: true Tags kann beispielsweise nützlich sein, wenn sich einige der Bilder, die Sie in Ihrer Compose-Datei verwenden, in Ihrem Cache befinden. docker-compose pull ziehe _alle_ Bilder in deiner Compose-Datei, und dieser Ziehvorgang schlägt fehl, wenn sich diese Bilder in deinem Cache, aber nicht im Repository befinden.

+1

Ein Szenario, in dem docker-compose pull && docker-compose up unpraktisch wird, ist die Verwendung mehrerer Docker-Compose-Dateien. Sie können leicht mit einem Befehl wie docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up enden.

Wir haben ein Szenario, in dem wir lokal entwickeln und wir möchten nur einige der Bilder aus der Ferne abrufen. Die eine (oder mehrere) lokal entwickelte sollte unberührt bleiben. In diesem Fall sind wir verpflichtet, Images manuell zu erstellen/herauszuziehen, bevor docker-compose up ausgeführt wird.
Ein pull: true wäre von Vorteil.

@shin- wie wäre es, wenn Sie Ihre Entscheidung diesbezüglich überdenken? Ich glaube, Kommentare und Reaktionen darauf sehen selbsterklärend genug aus.

Nein ich bin gut. Dies ist ein Open-Source-Projekt. Wenn Sie mit unserem konservativen Ansatz beim Hinzufügen von Funktionen nicht einverstanden sind, können Sie ihn gerne abspalten.

Stimmen Sie zu, entweder dem Befehl docker-compose up ein Flag oder der Konfiguration einen Parameter hinzuzufügen. Wir verwenden ein Basis-Image mit zusätzlicher Konfiguration, das sich während des Entwicklungsprozesses häufig ändert. Wir möchten eine narrensichere Umgebung schaffen, in der ein Entwickler einfach docker-compose up ausführen kann, ohne zu debuggen, was er nicht debuggen muss.

Ich bin tatsächlich auf diesen Thread gestoßen, nachdem mein Kollege meinen Pull-Request überprüft und gesagt hat, dass er den Build kaputt gemacht hat. Und der Grund dafür ist, dass dem Basis-Image einfach ein paar Pakete fehlten - aber im endgültigen Dockerfile ausgeführt wurde. Es wäre eine gute Funktion, aber anscheinend nicht etwas, das Sie verwendet haben, @shin- .

Wir würden uns freuen, wenn Sie diese Funktion in der neuen Version einführen.

@shin- Ich denke, @blockloop hat mit dem Beispiel git wie praktisch / nützlich die Pull-Option ist. Ehrlich gesagt hoffe ich, dass es für solche Dinge nicht notwendig ist, irgendein Projekt zu forken.

Ich verstehe den konservativen Ansatz total, aber es fühlt sich so an, als ob er nicht einmal mehr als Option in Betracht gezogen wird. Vielleicht kann es Teil einer kommenden Version sein?

Ein pull: IfNotPresent wäre schön. Es könnte also möglich sein, Fallbacks zu verwenden wie
1) lokales Bild verwenden
2) ziehen, wenn nicht lokal
3) bauen, wenn er nicht ziehen kann

@shin- Sie fragen immer wieder nach einem Grund, warum die &&-Methode nicht funktioniert, und mein Grund ist dieser. Ich verwende es für ein "App"-Image zum Testen (Puppet PDK/Onceover). Die Compose-Datei ist Teil des Vorlagen-Repositorys. Wenn also ein Puppet-Entwickler (wirklich Ops-Leute) ein neues Modul erstellen muss, teilt er dieses Repository. Jenkins führt das Image für die Merge-Validierung in diesem Modul-Repository aus (intern haben wir ein Jenkins-Plugin, das das Update für die Jobs übernimmt.) Jetzt werden die Leute, die dies verwenden, keine Docker-Experten sein, und ihnen sagen zu müssen, dass sie das && machen sollen, ist ein Extra Schritt, den sie vermasseln können (und wahrscheinlich auch tun werden). Ich verstehe nicht, warum es schwierig sein sollte oder welchen Nachteil es haben würde, aber diese Argumentation scheint ein lohnender Grund zu sein, es hinzuzufügen. Es hilft uns Entwicklern, Dinge zu versenden, die weniger Anweisungen und Schritte erfordern.

Kurz gesagt... um vor Faulheit zu schützen

Hier ist ein besserer Grund: && ist synchron. Aber docker-compose hat eine großartige Unterstützung für Parallel Executor eingebaut, die dieses Zeug optimiert. docker-compose up --pull --build könnte mit dem Erstellen des Images beginnen und es ausführen, sobald es abgerufen wurde, anstatt darauf zu warten, dass alle Images abgerufen wurden, und erst dann mit dem Erstellen beginnen

@shin geht davon aus, dass man sehr selten mit seltenen Aktualisierungen von Dockerfiles für sich selbst verwendet.
Aber wenn Sie jeden Tag ein Docker-Image aktualisieren, das Entwickler verwenden werden, führt es schnell zu Entwicklungsproblemen, wenn nur ein Entwickler vergisst, das Image zu ziehen, was er jeden Tag tun muss (insbesondere diejenigen, die mit Docker nicht wirklich vertraut sind, und das ist eigentlich nicht ihre Sache, es zu wissen und sich daran zu erinnern). Katastrophe programmiert.
Ist es ein großes Problem, diese Option einfach der docker-compose.yml hinzuzufügen?
Ich meine, es wird keine anderen Dinge ändern, es fügt nur Funktionalität hinzu. ..

Es ist der Killergrund, warum ich docker-compose nicht verwenden kann und Wrapper-Skripte mit Legacy-Docker-Ausführungsbefehlen schreiben muss, aber das ist hässlich.

Ich versuche herauszufinden, unter welchen Umständen dieses Ticket geschlossen wurde - würde bitte jemand näher darauf eingehen? Wenn es dir hilft, bin ich ein Profi, der --pull docker-compose up hinzufügt.

Ich glaube, hier werden zwei Vorschläge diskutiert:

1 - Sollte dies als Befehlszeilenoption hinzugefügt werden? Eigentlich die gepostete Ausgabe.
2 - Soll diese Option der YML-Datei hinzugefügt werden.

Letzterem stimme ich definitiv zu, obwohl @shin das nicht kommentiert hat. Es mit dem gleichen Argument abzutun, dass es funktional identisch ist, wäre inkohärent. Alles in der YML-Datei ist funktional identisch mit der Befehlszeile.

Ich kann seinen Standpunkt in Bezug auf Ersteres verstehen, aber ich denke, die Begründung ist ein wenig zu weit gefasst. Ich kann fast alles auf der Befehlszeile tun, indem ich eine Reihe von Anweisungen mit && verketten. Seien wir klar, das sind zwei Befehle, nicht einer. Die Kriterien sollten lauten: Ist die Nachfrage dafür so groß, dass dies in einem statt in zwei Schritten möglich sein sollte? Denn wenn es oft genug verwendet wird, wächst die Zahl der verketteten Befehle einfach weiter. Der Punkt ist, wenn Sie ein Skript schreiben, möchten Sie, dass es so prägnant wie möglich ist.

@orodbhen kein

Um die Begründung für das Hinzufügen einer Flagge zu ergänzen ... im Laufe des letzten Jahres oder so habe ich mich auf der Suche nach genau diesem Ding gefunden und bin hier gelandet, nur um festzustellen, dass ich bereits mehrere Kommentare zu Gunsten von a . hochgeblättert hatte --pull Flag. Ich kann mir vorstellen, dass ich mich auch das nächste Mal hier wiederfinden werde.

@shin-, bitte öffnen oder sperren Sie dieses Problem. Es ist seit fast zwei Jahren geöffnet und erhält ständig Kommentare (sowohl intelligent als auch unterhaltsam), Dutzende von Teilnehmern und Hunderte von Stimmen.
Es scheint jedoch klar zu sein, dass das Compose-Team nicht daran interessiert ist, dieses Feature zu verfolgen. Lassen Sie uns also nicht die Zeit von irgendjemandem verschwenden oder der falschen Hoffnung Raum geben, dass das Problem wiederbelebt wird, wenn dies nicht der Fall ist.

Bitte verzichten Sie auf Schimpfwörter.

Während ich dort denken ist Nützlichkeit in der ursprünglichen Anfrage, scheinen viele Leute in diesem Thread , den Geist des Open - Source -vergessen: wenn es so wichtig für Sie, Sie sind zu Herzenslust frei gabeln und zu ändern. Ich verstehe, dass Sie einen Fork vielleicht nicht pflegen möchten, aber sich zu beschweren, dass die Betreuer ein Feature nicht implementieren, ist kontraproduktiv: So werden Features nicht implementiert und die Betreuer wollen Ihnen weniger helfen .

Es spielt keine Rolle, dass eine Nachfrage nach einer Funktion besteht, insbesondere wenn niemand für die Nutzung des Produkts bezahlt. Es gibt mehr zu beachten, als nur jedes Feature, das jeder möchte, in das Hauptprodukt zu integrieren. Wir sollten die Antwort von @shin- respektieren und glauben, dass es gute Gründe gibt, sie nicht umzusetzen.

@lig Ich

Je nach Bedarf kann das Forking übertrieben sein. In meinem speziellen Fall habe ich festgestellt, dass Compose nicht sehr gut zum Skripting geeignet ist, es sei denn, es handelt sich um ein sehr einfaches Skript. Die Verwendung der Docker-Python-API und meiner eigenen YAML-Datei zum Beibehalten von Einstellungen ist vielseitiger und oft einfacher.

@bdharrington7 – aber Sie müssen Ihren Fork warten und auf allen von Ihnen verwendeten Computern installiert lassen (was selten möglich ist). Vorbehalt ist, dass Docker Compose beliebt ist, andere würden sagen: „wen cares?“

Die Realität ist, dass der Kommentar "Es ist Open Source, erstelle deinen eigenen Fork" einfach nicht realistisch ist. Der Aufwand, Ihren eigenen Fork zu pflegen und mit den neuesten Änderungen aus dem Haupt-Repository auf dem neuesten Stand zu halten, macht die Investition selten lohnenswert. Ein viel besserer Ansatz besteht darin, bei den Betreuern eine Petition einzureichen und angemessene Gründe dafür anzugeben, warum das Feature wichtig ist.

Leider führt dies immer zu Problemen wie diesem mit einiger Unzufriedenheit. Ich denke, das Hauptproblem hier ist, dass es anscheinend keine angemessene Argumentation dafür gegeben hat, warum dies eine schlechte Idee ist. Das Argument

"Wir sollten die Antwort von @shin- respektieren und glauben, dass es gute Gründe gibt, sie nicht umzusetzen."

wird die Leute einfach nicht zufrieden stellen. Die Community muss die "guten Gründe" sehen.

Der Punkt bleibt, dass das Schlagen mit den Fäusten und das Betteln selten zur Folge haben wird
um zu bekommen, was Sie wollen, was in diesem Thread viel passiert ist.
Es wurden auch viele gute Anwendungsfälle im Thread angesprochen,
Aber es sei denn, Sie zahlen tatsächlich für die Software, es gibt keine Verpflichtung
von den Betreuern, etwas dagegen zu unternehmen, und geben Sie auch keine Gründe dafür an. Ich bin
Geben Sie @shin- und Company hier nur den Vorteil des Zweifels.
Am Sa., 24. März 2018 um 5:39 Uhr schrieb Greg Pakes [email protected] :

Die Realität ist, dass der Kommentar "Es ist Open Source, erstelle deinen eigenen Fork",
ist einfach nicht realistisch. Der Aufwand für die Wartung Ihrer eigenen Gabel und
es mit den neuesten Änderungen aus dem Haupt-Repository auf dem neuesten Stand zu halten
macht die Investition selten lohnenswert. Ein viel besserer Ansatz ist die Petition
die Betreuer und begründen Sie, warum die Funktion
wichtig.

Leider wird das bei einigen immer zu Problemen wie diesem führen
Unzufriedenheit. Ich denke, das Hauptproblem hier ist, dass es das nicht zu geben scheint
wurde ein richtiger Fall vorgebracht, warum dies eine schlechte Idee ist. Die
Argument "Wir sollten @shin- http:///shin -s Antwort darauf respektieren,
und glauben, dass es gute Gründe gibt, es nicht umzusetzen." ist es einfach nicht
wird die Leute zufriedenstellen. Die Community muss die "guten Gründe" sehen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/compose/issues/3574#issuecomment-375805478 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEV8Q9RseMxYS8KGyD9E2BK0pZv7OJpuks5thWt7gaJpZM4IyPQh
.

Der Punkt bleibt, dass das Schlagen mit den Fäusten und das Betteln selten dazu führt, dass Sie bekommen, was Sie wollen

Dies ist einfach nicht wahr. Obwohl ich es nicht als Strategie dulde, um freie Arbeit zu bitten, ist es tatsächlich ziemlich effektiv. Es ist genau so, wie Petitionen funktionieren und je mehr Leute "mit den Fäusten schlagen", desto größer ist die Wahrscheinlichkeit, dass die Leute, die wichtig sind, darauf aufmerksam werden. Auch hier sage ich nicht, dass ich damit einverstanden bin

Es wurden auch viele gute Anwendungsfälle im Thread angesprochen

Ich kann einen Fall sehen, der im Wesentlichen darauf hinausläuft, dass Sie stattdessen diese beiden Befehle ausführen können. Aber die Leute wollen es offensichtlich nicht. Beziehen Sie sie also ein und erklären Sie ihnen, warum es eine gute Arbeit ist.

Es gibt keine Verpflichtung seitens der Betreuer, etwas dagegen zu unternehmen, und auch keine Gründe dafür anzugeben

Ich stimme zu. Aber Sie müssen damit rechnen, dass die Leute frustriert sind. Es ist eine ablehnende Haltung. Am Ende des Tages sind alle hier im selben Team. Die Leute, die das Projekt betreuen, und die Benutzer des Projekts wollen alle nur, dass das Projekt erfolgreich ist.

Welches Produkt ist hier genau kostenlos? Wenn ich docker-compose.exe verwende und Docker EE ausführe, bedeutet das nicht wirklich, dass ich tatsächlich für das Produkt bezahle?

IMHO --build sollte ziehen; keine weiteren Flags oder Konfigurationen erforderlich. Wenn Sie nicht möchten, dass es gezogen wird, geben Sie die Image-Version an.

@ET-CS: Image-Versionen sind nur Tags und können sich noch in einen anderen Hash ändern

guter Punkt @lifeofguenter danke. kann komponieren, ob das Bild in einen anderen Hash geändert wurde, und in diesem Fall auch ziehen?

In einem solchen Szenario möchte ich, dass alle Umgebungen (dev, prod) das gleiche Image haben, wie es jetzt möglich ist, da die Entwickler den neuen Hash verwenden, während die Produktion den älteren verwendet.

Ich würde erwarten, dass --build alles auf den neuesten Stand bringt.

Hier ist also ein guter Anwendungsfall:

Ich habe für mein Microservices-Projekt ein CI implementiert, das neue Images in eine Registry zieht, wenn wir neue Funktionen im Backend-Dienst entwickeln. Das Frontend-Team (das wenig über Docker weiß) muss eine Möglichkeit haben, den gesamten Backend-Stack auf seinen lokalen Computern aufzurufen, und es verlässt sich auf die aktuellsten Images. Wenn etwas kaputt geht, werden sie nur daran denken, die Bilder zu ziehen.

Nun ist folgendes passiert: Ein ganzer Entwicklungssprint ist gescheitert, weil jemand vergessen hat, die Backend-Images zu aktualisieren, und ein ganzes Feature auf Basis einer alten Version entwickelt. Schuld am Frontend-Team, aber dies könnte mit dieser Funktionalität vermieden werden (die ich mit Wrapper-Skripten mache).

@agnjunio Das klingt wirklich schade, sorry. Wenn die Person jedoch vergessen hat, docker-compose pull auszuführen, bin ich mir nicht sicher, wie es weniger wahrscheinlich ist, dass sie vergessen, ein hypothetisches --pull Flag zu verwenden?

@shin- Entschuldigung, ich habe vergessen, eine wichtige Sache zu erwähnen: Die Lösung in meinem Fall besteht darin, das Tag pull: always im Yaml zu haben, vielleicht in den image: Optionen

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

Ich würde erwarten, dass --build alles auf den neuesten Stand bringt.

IMHO --build sollte ziehen; keine weiteren Flags oder Konfigurationen erforderlich. Wenn Sie nicht möchten, dass es gezogen wird, geben Sie die Image-Version an.

AFAIK, die den Anwendungsfall mit einem Build blockieren würde, der ein FROM verwendet, das das Ergebnis eines depends_on Builds ist.

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

Ich befürworte eine Flagge, wie sie in https://github.com/docker/compose/issues/3574#issuecomment -252861859 und https://github.com/docker/compose/issues/3574#issuecomment -279460839 vorgeschlagen wird

@solsson
Ich bin mir nicht sicher, warum oder was es in diesem Anwendungsfall blockiert.
Bitte teilen Sie uns weitere Informationen darüber mit, wenn Sie können.

@shin- Der Unterschied hier wäre, dass ich, wenn ich docker-compose up --help ausführe, eine Beschreibung zur Verwendung des neuesten Bildes erhalten würde, stattdessen muss ich heutzutage im Dokument oder in der Google suchen, die mich führt Dieser Thread und ich muss alle Kommentare lesen, um zu verstehen, dass docker-compose up nicht das tut, was ich brauche/will, also muss ich jetzt zwei Befehle ausführen.

@agnjunio Das klingt wirklich schade, sorry. Wenn die Person jedoch vergessen hat, docker-compose pull auszuführen, bin ich mir nicht sicher, wie es weniger wahrscheinlich ist, dass sie vergessen, ein hypothetisches --pull-Flag zu verwenden?

Herzlich

Einer der Hauptgründe, warum wir docker-compose verwenden, ist die Möglichkeit, eine docker-compose.yaml Datei in einem Repository abzulegen und eine reproduzierbare Ausgabe zu erhalten, wenn ein Entwickler das Repository abruft und docker-compose up [service] .

Wir verwenden mehrere Dienste in unseren Docker-Compose-Dateien, die Aufgaben wie das Ausführen von Codegen und das Ausführen eines Tools zum Dereferenzieren eines JSON-Schemas in eine einzelne Datei ausführen.
Es ist wichtig, sicherzustellen, dass diese Tools auf dem neuesten Stand sind, insbesondere wenn wir unser Codegen-Image aktualisieren, um ein allgemeines kritisches Problem zu beheben, das in allen Projekten aufgetreten ist.

Mit der Fähigkeit zu platzieren:

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

würde unsere Fähigkeit behalten, Docker-compose von einem Entwickler zuverlässig ausführen zu lassen und die erwarteten Ergebnisse zu erzielen, anstatt jedes einzelne Repository mit Dokumentation zu ergänzen, um Entwickler daran zu erinnern, eine Kette von Befehlen oder Skripten auszuführen, um die neuesten verfügbaren Bilder abzurufen, bevor die Apps gestartet werden .

Es geht nicht um "die Funktionalität ist bereits vorhanden, um dies durch Ausführen dieser Befehle zu tun", sondern um eine bessere Benutzererfahrung.

Stellen Sie sich vor, wenn jemand vorschlägt, --stop zu docker-compose rm hinzuzufügen, --stop die Antwort "Was ist mit docker-compose stop myapp && docker-compose rm myapp nicht in Ordnung, oder wenn jemand die Implementierung von docker-compose down angefordert hätte, dann wären sie einfach gefragt, warum docker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ... unpraktisch ist?

Dieser Thread wurde vor 2 Jahren erstellt und ich dachte immer noch, dass das Hinzufügen eines Flags in der docker-compose.yml der beste Weg ist. In meinem Fall haben wir etwa 37 Dienste in einem Schwarm, und die Aktualisierung von 4-5 Bildern von dieser Gesamtzahl ist nicht einfach. Ich habe vorerst nur eine Shell erstellt, die die Änderung aus dem Repository überwachen und den Pull für das bestimmte Image ausführen kann, bevor der Dienst neu erstellt wird, wenn er aktualisiert wurde.

Ein weiterer Punkt hier ist, dass docker-compose up eine Option --quiet-pull . Als ich zum ersten Mal versuchte herauszufinden, ob up einen Pull enthält, ging ich davon aus, dass dies der Fall ist. Es liegt nahe, dass die Nichtverwendung von --quiet-pull zu einem ausführlichen Pull führt.

Zwei Jahre lang haben Leute versucht, die Docker Compose-Betreuer davon zu überzeugen, dass eine --pull-Option eine bessere Erfahrung wäre, ohne einen separaten Befehl ausführen zu müssen. Wenn die Docker-Compose-Betreuer das Feature einfach nur implementieren würden, wäre das Leben aller besser. Es scheint klar zu sein, dass die derzeitigen Betreuer dieses Feature nicht zum Wohle der Community hinzufügen möchten.

Vielleicht sollten wir docker-compose einfach abspalten und selbst aktualisieren.

Wenn jemand eine PR einreichen würde, hätte diese eine Chance, angenommen zu werden?
Dies ist Open Source. Ich war kurz davor, es ein paar zu implementieren
mal selbst. Ich gehe davon aus, dass es akzeptiert werden könnte, sonst wird diese Rolle geschlossen,
rechts?

Ich bin auf das gleiche Problem gestoßen und heiliger Mist, ein Haufen Nörgler hier drin. Dies ist KOSTENLOSE Open-Source-Software. Geben Sie den Betreuern eine Pause. Ich bin sicher, sie haben viel wichtigere Dinge zu tun als diese. Wenn das jemand so dringend braucht, warum eröffnen Sie dann nicht eine PR? Wenn der Code mit minimalem Risiko sauber ist, verstehe ich nicht, warum sie ihn nicht akzeptieren würden.

Dieses Thema sollte noch einmal aufgegriffen werden, da es in der Diskussion keinen triftigen Grund gibt, diesen Wunsch nicht umzusetzen. Die Leute beginnen eher an _offenen_ Themen zu arbeiten als an geschlossenen.

Die Tatsache, dass dieses "geschlossene" Thema so aktiv geblieben ist, deutet darauf hin, dass es nicht gut gehandhabt wurde.

Leider habe ich festgestellt, dass Antworten auf Issue-Posts in einigen GitHub-Repos nicht sehr hilfreich sind. Der Ton ist oft knapp und deutet darauf hin, dass Feedback nicht erwünscht ist.

Einige haben hier darauf hingewiesen, dass dies ein Open-Source-Projekt ist und (zumindest die meisten von uns) keine zahlenden Kunden sind. Es ist jedoch auch erwähnenswert, dass das Einreichen von Problemberichten einen erheblichen Zeitaufwand darstellt, insbesondere wenn Sie an der Lösung des Problems mitwirken.

Ein Benutzer oder Entwickler, der Zeit damit verbracht hat, ein Problem zu beheben und eine Problemumgehung gefunden hat, entscheidet dann, ob er zusätzliche Zeit aufwenden möchte, um das Problem zu melden. Eine unempfängliche Antwort von Betreuern wird wahrscheinlich dazu führen, dass sie sich beim nächsten Mal nicht darum kümmern.

Die Software ist nicht wirklich "KOSTENLOS", im Sinne von "Freibier". da wir alle versuchen, daran mitzuwirken, dass es besser wird. Es ist eine wertvolle Ressource, Leute zu haben, die bereit sind, Ihre Software zu testen und Feedback zu geben. Diejenigen, die über die erforderlichen Programmierkenntnisse verfügen, sind sogar bereit, Code beizutragen, möchten jedoch einen Hinweis darauf, dass ihre Beiträge willkommen sind, bevor sie Zeit damit verbringen.

Kommentare, die sich einfach über ein Problem beschweren und dessen Behebung fordern, sind offensichtlich nicht sinnvoll, aber die Mehrheit tut dies nicht, und Kommentare wie "Es ist Open Source, einfach fork it" sind ebenso nutzlos.

@shin- Warum wurde "--build" implementiert? Ist es anders als docker-compose build && docker-compose up? Ich versuche nur, den philosophischen Unterschied zwischen --build (der hinzugefügt wurde) und --pull (der als überflüssig erachtet wurde) zu verstehen. Das Verstehen des Denkprozesses kann mir helfen, mich daran zu erinnern, wie die Dinge funktionieren. UND wenn das Thema geöffnet ist, reiche ich gerne eine PR ein. @everybodyelse... ist es wirklich der "Geist von OpenSource", dass man etwas abzweigt, wenn man etwas nicht mag? Ich dachte, der Geist von OpenSource war "wenn dir etwas nicht gefällt, hilfst du a) zu den Anforderungen beizutragen, wenn du dort bist, b) hilf mit, zum Code beizutragen, wenn du kannst" und dass du nur gegabelt hast, wenn deine Anforderungen sehr waren eindeutig etwas, von dem nur Sie profitieren würden. dh ich dachte, wir profitieren am meisten, wenn wir teilen - aber ich freue mich, hier ausgebildet zu werden.

Nach zwei Jahren des Bestehens, der Angabe guter Gründe, die ignoriert werden, und der enormen Unterstützung der Community, dies tatsächlich zu implementieren, würde ich sagen, dass dieses Feature es nicht schaffen wird, nur weil @shin- es nicht will. Kein Grund, weiter darauf zu bestehen.

Es gibt einen Grund: Docker aktualisiert die Images nicht, wenn ein Pull fehlschlägt und es keinen guten Grund gibt, dies nicht zu tun.

Ich suche die Kubernetes-Image-Pull-Richtlinie in Docker Compose, wäre toll, wenn der "Pull" verwendet werden kann.

@shin- Hör auf, kindisch zu sein. Es wurden viele gute Gründe genannt, diese Funktion zu implementieren. Sei wenigstens offen für PRs...

Sie können mir widersprechen, aber ich bin enttäuscht, dass Sie auf ad hominems zurückgreifen würden, @Wenzil. Unsere Community hält sich im Allgemeinen an einen höheren Standard.

@shin- Unsere Community denkt meistens genauso und hält es aus dem von Ihnen genannten Grund unausgesprochen. @Wenzil ist nur ehrlich genug, um es laut
Viele Leute, die ich kenne, ziehen es vor, sich nicht die Mühe zu machen und haben es aufgegeben, Docker-Compose davon zu überzeugen, sich seinen Benutzern zuzuwenden.

Viele Leute stimmen @shin- aus sehr triftigen Gründen nicht zu. Dies sollte zumindest eine Leistungserklärung sein. Das Aneinanderreihen von Bash-Befehlen ist keine besonders gute Lösung für programmatische Bereitstellungen.

Viele Leute, die ich kenne, ziehen es vor, sich nicht die Mühe zu machen und haben es aufgegeben, Docker-Compose davon zu überzeugen, sich seinen Benutzern zuzuwenden.

Dies. Und es ist nicht nur Docker-Compose. Docker-stack, docker-machine und docker-cli sind alle ähnlich.

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

Sperren, da dies immer wieder entgleist. Wir werden es je nach Schicksal von https://github.com/docker/cli/pull/1498 neu bewerten

Als Update haben wir uns intern entschieden, einen pull_policy Parameter zu Service-Definitionen hinzuzufügen. Wir müssen noch herausfinden, was die Optionen und die genaue Syntax sein werden, aber wir hoffen, dass sie die in diesem Thread geäußerten Anforderungen erfüllt.