Compose: Depends_on in Version3

Erstellt am 9. Jan. 2017  ·  37Kommentare  ·  Quelle: docker/compose

Hallo, ich würde gerne wissen, was die Alternative von abhängige_on in Docker-Compose v3 ist, wie in den Versionshinweisen, die Sie sagten, wir werden die abhängige_on-Funktion in v3 nicht portieren

formav3 kinquestion

Hilfreichster Kommentar

Was wäre das Äquivalent zu Docker-Compose v3, um so etwas wie Healthcheck-Abhängigkeiten zu erreichen? Wenn Sie diese Funktionalität in Version 3 löschen möchten, sollten Sie sie grundsätzlich nie verwenden, oder es sollte zumindest einen Migrationspfad dafür geben.

Was sind die Absichten, es in eine neue Docker-Compose-Version 2.1 einzuführen und dann für Version 3 zu löschen? Ich richte derzeit verschiedene Compose-Dateien für unsere Anwendungen ein, möchte jedoch keine Funktionen verwenden, die in der nächsten Version gelöscht werden, und daher verhindern, dass die Verwendung auf eine neuere Docker-Compose-Dateiversion aktualisiert wird.

Alle 37 Kommentare

depends_on ist in Version

HTH

Aber ich habe eine Docker-Compose-Version 3 geschrieben und versuche, sie auf Swarm bereitzustellen, aber abhängige_on funktioniert nicht, da der Container nicht in der Weise startet, in der er gestartet werden muss.

Verwenden Sie docker-compose oder docker stack deploy ?

Ich verwende Docker Stack Deploy
und ich versuche es auf einem Schwarm von 7 Maschinen bereitzustellen

Was wäre das Äquivalent zu Docker-Compose v3, um so etwas wie Healthcheck-Abhängigkeiten zu erreichen? Wenn Sie diese Funktionalität in Version 3 löschen möchten, sollten Sie sie grundsätzlich nie verwenden, oder es sollte zumindest einen Migrationspfad dafür geben.

Was sind die Absichten, es in eine neue Docker-Compose-Version 2.1 einzuführen und dann für Version 3 zu löschen? Ich richte derzeit verschiedene Compose-Dateien für unsere Anwendungen ein, möchte jedoch keine Funktionen verwenden, die in der nächsten Version gelöscht werden, und daher verhindern, dass die Verwendung auf eine neuere Docker-Compose-Dateiversion aktualisiert wird.

Im Moment sollten Sie davon ausgehen, dass die neue Syntax depends_on nicht auf v3 portiert wird, da wir derzeit keine Pläne dazu haben.

Ich weiß, dass dies nicht die Antwort ist, die viele Leute wollen, aber ich hoffe, dass dies zumindest Klarheit schafft.

Kann ich fragen, warum es nicht in Plänen ist? Ich gehe davon aus, dass dies sehr nützlich wäre.

Es gibt Klarheit, erklärt aber nicht. Können Sie das Warum näher erläutern? Und zu den Alternativen (falls vorhanden)?
Mit abhängige_on können wir uns auf einfache Weise auf einen Dienst verlassen, anstatt ihn im Container zu verwalten (was bedeuten kann, dass ein Image eines Drittanbieters mit einem Warteskript versehen wird und dieses gewartet werden muss).

@ shin- warum hast du es dann überhaupt in 2.1 implementiert? Wenn Benutzer es verwenden und sich darauf verlassen, können sie niemals ein Upgrade durchführen. Bei allem Respekt scheint das eine sehr schlechte Planung für euch zu sein.

Was ist die unterstützte abhängige Syntax für Version 3? https://docs.docker.com/compose/compose-file/#version -3 erwähnt abhängige_on nicht, und wenn ich Docker-Compose v1.10 zum Bereitstellen einer Anwendung verwende, funktionieren weder die v2- noch die v2.1-abhängigen_on-Varianten ich in einer v3 komponierdatei ...

@ Mustafaakin

Kann ich fragen, warum es nicht in Plänen ist? Ich gehe davon aus, dass dies sehr nützlich wäre.

@hsmade

Können Sie das Warum näher erläutern? Und zu den Alternativen (falls vorhanden)?

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

depends_on ist ein No-Op, wenn es mit docker stack deploy . Dienste im Schwarmmodus werden neu gestartet, wenn sie fehlschlagen. Es gibt also keinen Grund, den Start zu verzögern. Selbst wenn sie einige Male versagen, werden sie sich irgendwann erholen.


@brettmc

Was ist die unterstützte abhängige Syntax für Version 3?

Bei Verwendung von docker-compose ist die unterstützte Syntax für v3 die Listensyntax (ähnlich der für 2.0 verwendeten). Wenn Sie docker stack deploy , werden Abhängigkeiten nicht berücksichtigt (Begründung siehe oben).


Das Format der Version 3 ist der erste Schritt auf dem Weg vom externen Tool docker-compose zur integrierten Lösung docker stack . Die aktuelle Implementierung hat ihre Macken, an denen gearbeitet wird. Die Unterstützung des Formats der Version 3 in docker-compose soll diesen Übergang erleichtern. Seit der Einführung von fig / Compose haben sich in Docker viele Dinge geändert und verbessert, und das bedeutet, dass viele Dinge, die früher Sinn machten, inzwischen veraltet sind. docker stack ist ein Neuanfang mit neuen Konzepten und entfernt einige der unhandlicheren Syntax- und Konzepte von volumes_from bis depends_on .
Wenn Sie besondere Bedenken hinsichtlich einiger dieser Änderungen haben, melden Sie diese bitte im Docker / Docker- Repo, in dem sie aktiv wiederholt werden.
Wenn Sie noch nicht bereit sind, auf Docker-Dienste und docker stack umzusteigen, können Sie das v2-Format weiterhin verwenden. Es ist zwar vernünftig anzunehmen, dass das Projekt irgendwann in der Zukunft untergehen wird, es wird jedoch frühzeitig angekündigt. Danach bleibt der Code verfügbar und Open Source.

Vielen Dank. Jetzt macht es Sinn.

Dienste im Schwarmmodus werden neu gestartet, wenn sie fehlschlagen. Es gibt also keinen Grund, den Start zu verzögern. Selbst wenn sie einige Male versagen, werden sie sich irgendwann erholen.

IMHO ist dies kein guter Ansatz. Nicht alle Dienste können die anderen Dienste, von denen sie abhängen, ordnungsgemäß erkennen. Sie sind nicht bereit. Sie versuchen es mehrmals und schlagen dann fehl, sodass der Container möglicherweise später stirbt. Wir müssen noch Entrypoint-Wrapper-Skripte einführen, was nicht sehr schön ist. Die Abhängigkeit von gesunden Checks war sehr schön, unterstützt jedoch nicht den Schwarmmodus.

Dienste im Schwarmmodus werden neu gestartet, wenn sie fehlschlagen. Es gibt also keinen Grund, den Start zu verzögern. Selbst wenn sie einige Male versagen, werden sie sich irgendwann erholen.

Hallo allerseits!
Bedeutet das, dass wenn ich zum Beispiel einen Dienst habe, der seine Arbeit sehr schnell ausführt und beendet (und von Natur aus nur einmal ausgeführt werden sollte), dieser immer wieder und immer wieder gestartet wird ... wiederholt?

@ Marvel77 Standardmäßig ja, aber Sie können dieses Verhalten mithilfe des Abschnitts deploy.restart_policy überschreiben: https://docs.docker.com/compose/compose-file/#restartpolicy

@ shin- Vielen Dank!

@mustafaakin Tatsächlich ist es (IMHO) die beste Vorgehensweise, eine fehlertolerante Verbindung zu den Diensten herzustellen, von denen Sie abhängig sind. Wenn Sie beispielsweise eine Datenbank verwenden, können Sie den Start verzögern, bis sie reagiert. Aber wie geht man mit einem Neustart der Datenbank um? Ihre App sollte in der Lage sein, sich davon zu erholen, und dann müssen Sie sich auch nicht auf 'abhängige_on' verlassen.
In gewissem Sinne ist die Abwertung eine gute Sache. Diese Annehmlichkeiten machen uns faul.

@hsmade Aber fast alle init (upstart, systemd) haben abhängig von der Beziehung. Es ist also nicht so faul zu sein, es macht Sinn. Der SSHD-Daemon wird erst gestartet, wenn Sie Ihr Netzwerkgerät bereit haben. Ich habe keine Kontrolle über alle Systeme, die ich habe. Ja, ich kann meine Systeme fehlertolerant machen. Angenommen, A hängt von B ab. Die Initialisierung von A dauert eine Weile, ist jedoch nicht sehr deterministisch. Wie können Sie eine Neustartrichtlinie für B schreiben? für immer neu starten? Was ist, wenn Sie das nicht wollen?

Dies ist ein größeres Problem als Compose. Compose startet sie nur. Schwarm ist das, was sie zum Laufen bringt, daher denke ich, dass Schwarm mit dieser Abhängigkeit von der Gesundheitsbeziehung umgehen sollte.

@mustafaakin Ich glaube nicht, dass Sie das Ausführen von

Aber andererseits sind dies meine Gedanken zu diesem Thema, und ich könnte mich irren;)

Ja, für Microservices macht es keinen Sinn, aber nicht alles ist ein Microservice. Ich führe Hadoop in einem Container aus. Docker ist nicht nur für Microservices gedacht. Wie gesagt, es ist großartig für die Umgebungen, die ich kontrolliere, aber in den Dingen, die ich nicht kontrolliere, muss der Einstiegspunkt der Dienste umschlossen werden. Es wurde nur mit Depends_on mit Healtcheck gelöst. Ich denke, es wäre großartig, es auch in Swarm zu haben. Ein kontinuierlicher Neustart ist nur die Wahl eines faulen Mannes.

Jungs,

Ich denke, es gibt eine Art Missverständnis von "fehlertolerant" und eine Art "Erstinitialisierung".
Stimmen Sie zu, dass der Ansatz für den ersten gut genug klingt, aber der letztere ist ein echter Schmerz.
Ich würde mir vorstellen, dass nicht nur ich selbst, sondern im Allgemeinen normalerweise Dienste in einer bestimmten Reihenfolge gestartet werden müssen, da sie mehr oder weniger voneinander abhängen.

Ein kontinuierlicher Neustart in der Initialisierungsphase und das Warten auf den Start der Dienste in der richtigen Reihenfolge ist wie ein Albtraum - man kann keine "Ausfallzeit" für den Startprozess planen, sollte das Schlimmste passieren. Nicht nur das Schlimmste, sondern manchmal gibt es auch "Wartungszeit", wenn sich etwas ändern muss und niemand vorhersagen kann, wie lange es dauern würde, bis das System tatsächlich gestartet wird, da verschiedene Dienste immer wieder durch Schwarm neu gestartet werden wieder auf die richtige Bestellung warten.
Ich habe versucht und gewartet, um zu sehen, wie es mit 7 Containern gehen wird und für 20 Minuten _swarm_ hat es immer noch nicht herausgefunden und der gesamte Service war immer noch nicht verfügbar.
Man kann also nicht einmal angeben, wie viel Zeit es dauern würde, die gesamte Infrastruktur wiederherzustellen, da es wirklich unbekannt ist, wie lange der erste Start dauern würde.
Klingt für mich absurd.

Ich glaube nicht, dass ich ohne eine solche Vorhersehbarkeit in die "Produktion" einsteigen kann, obwohl es selten passieren soll (ganz unten) - am besten nie passieren.
Aber genau wenn es immer noch passiert, wäre ich vor Ort und werde aufgefordert, so schnell wie möglich wiederherzustellen. Zu diesem Zeitpunkt und unter diesem Druck hätte ich absolut keine Ahnung, wie viel Zeit meine Container starten würden, nur weil sie sich während des Startvorgangs weiter neu starten.

@ozlatkov Dies sollte wirklich auf dem Docker / Docker Issue Tracker gepostet werden, nicht hier.

@ Shin- Danke! Ich habe es auf Docker / Docker Tracker verschoben:

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

Ich finde es wirklich schlimm, dass das Docker-Team davon ausgeht, dass Docker Swarm verwendet wird. Compose soll ein voll funktionsfähiges eigenständiges Tool sein.

Wir verwenden Docker Compose jedoch häufig in unseren Test-Pipelines, und eine so grundlegende ENTFERNUNG von Funktionen (ohne eine praktikable Alternative anzugeben) hat wirklich dramatische negative Auswirkungen auf Ihre Benutzer.

Ich überprüfe derzeit eine sehr hässliche PR meiner Teammitglieder, in der sie versuchen, alle möglichen Problemumgehungen zu finden (da wir uns stark auf diese Funktionalität verlassen), einschließlich des Verbleibs bei Compose 2.X für alle Ewigkeit.

Docker soll uns helfen, unsere Ziele zu erreichen, und es nicht schwieriger machen, kritische Funktionen zu entfernen, auf die sich viele Teams bereits verlassen.

Bitte überdenken Sie die Portierung all dessen in Docker Compose 3.

Sehr geschätzt.

Jetzt zum 100. Mal: ​​Es gibt keinen Grund, das v3-Format zu verwenden, wenn Sie nicht beabsichtigen, Schwarmdienste zu verwenden.

Bedeutet das, dass sich das Team verpflichtet, die 2.X-Formate für diejenigen zu unterstützen, die compose als eigenständiges Entwicklungstool verwenden?

Genau meine Frage: Ist das Compose-Team entschlossen, das v2-Format für immer zu unterstützen?

Wir können Docker Compose nicht standardisieren, wenn das v2-Format jederzeit veraltet sein soll.

Ich habe das Gefühl, dass dies alle Container in ein init container -Muster zwingt, die Docker-Neustartrichtlinie entfernt und einen hackigen Ansatz für die Startreihenfolge erstellt. Sollte davon ausgegangen werden, dass sich> = v3 von compose in diese Richtung bewegt, um sich auf Stapel zu konzentrieren und Anwendungspakete zu erstellen? Und wenn das stimmt, können Sie mir dann zeigen, wie die Startreihenfolge in einem Docker-Stack beibehalten werden soll? Ist das wait-for-it.sh oder dockerize der Ansatz dort?

Was ist das deklarative Äquivalent von docker-compose.yml für einen Stapel?

Hallo Leute, was ist die beste Vorgehensweise, wenn ich Docker-Stack verwenden und Docker-Compose loswerden möchte?

Dies scheint die Lösung zu sein, aber es klingt nicht nach einer guten Praxis, Hacky-Skripte zum Initiieren von Containern zu haben. Macht es?

Vielen Dank.

@mustafaakin Danke für deine Ablehnung! Sehr hilfreich ❤️

@VinceOPS Ich bin mir nicht sicher über "Best Practice", aber ich habe Healthchecks und restart: always so dass es nur so lange läuft, bis es funktioniert ¯ \ _ (ツ) _ / ¯

@hutchic Aber wie in der obigen Konversation erwähnt, konnte es kein Enddatum geben, eine Art zirkulärer Neustart bei einem Fehler.

Warum entfernt das Docker-Team diese Funktion in Version 3 und lehnt es ab, diese hinzuzufügen?

@ tianhao-au siehe Diskussion unter https://github.com/moby/moby/issues/31333 (und https://github.com/moby/moby/issues/31333#issuecomment-409143581)

Zum Verfassen habe ich auch einen Vorschlag in https://github.com/moby/moby/issues/31333#issuecomment -333265696 hinterlassen (habe ein x-depends_on )

Diese Änderung der Funktion ist buchstäblich der Grund, warum ich Docker-Compose nicht mehr verwende. Wenn ich Docker in der Produktion verwende und Docker-Compose lokal für Entwicklungsumgebungen verwende, muss ich jetzt dafür sorgen, dass sich meine Docker-Container in der Entwicklung radikal anders verhalten als in der Produktion. In der Produktion verlasse ich mich auf ein Orchestrierungssystem, um den Zustand und die Reihenfolge meiner Bereitstellungen sicherzustellen. In Dev Land wurde diese Orchestrierung von Docker-Compose durchgeführt. Jetzt schreibe ich eine Reihe von verstümmelten Skripten, um den Zustand der Dinge zu überprüfen und mein System zu orchestrieren. Wenn ich das mache, warum schreibe ich nicht einfach einen Golang, um meine Hafenarbeiter zu verwalten und damit fertig zu sein? Ein wenig verblüfft wurde es fallen gelassen. Nur meine 2p

Der Versuch, die neueste Docker-Compose-Version zu verwenden, um die Dinge zukunftssicherer zu machen, stieß auf dieses Problem. Das ist traurig.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen