Compose: Das Standardbenennungsschema für Container, die von Compose erstellt wurden

Leider nein, sorry.

Das selbe hier. Diese Slug-Funktion sollte optional sein. Wie schwer ist es, eine Flagge im Befehl up oder build zu übergeben, um sie auszuschalten?

Ich stimme zu - dies sollte optional sein. Einige Programme, die Docker Compose verwenden, werden jetzt nur ausgeführt, wenn Sie ein Downgrade auf 1.22 durchführen.

Ich stimme zu, dies sollte optional sein. Wir brauchen diese Slug-Funktion überhaupt nicht und viele Bash-Skripte verwenden das alte Namensformat.

Für uns müssen wir auf 1.22 bleiben, da wir die Funktion "Volumes von" verwenden und uns auf das alte Namensschema verlassen. Bitte machen Sie es in 1.24 optional.

Diese Funktion macht es schwierig, auf die Container zu verweisen, nachdem sie erhöht wurden.

Ich verstehe den Sinn dieser Änderung nicht. Derzeit bieten weder Docker noch Compose eine Serviceerkennung an. Was soll ich tun, wenn ich einen Hostnamen aus dem Container erhalten möchte? Meine eigene Service-Entdeckung rollen?

Übrigens, was sind die Vorteile dieser Änderung? Lohnt es sich wirklich, die Abwärtskompatibilität zu brechen?

Die standardmäßige Änderung des _slug-Namens ist der richtige Ansatz, aber die Möglichkeit, sie nicht über eine Umgebungsvariable oder eine Befehlszeilenoption zu deaktivieren, unterbricht viele vorhandene Workflows. Bitte betrachten Sie dies als eine Funktionsanforderung zum Hinzufügen eines Flags, um das Namensverhalten von Docker-Compose <= 1.22.0 wiederherzustellen.

Sorry, aber "external_links" sind jetzt unbrauchbar. Ich muss den Namen eines Containers kennen, um ihn zu verknüpfen.
+1, um es optional zu machen

@ shin- dieses neue Verhalten ruiniert viel. Vor diesem zufälligen slug es möglich, einen Container zu adressieren, der von einer Docker-Compose-Datei in einer anderen Datei wie gestartet wurde

services:
  app:
    image: app
    external_links:
      - "other-project_other-app_1:other-app"
networks:
  default:
    external:
      name: other-project_default

Und das ist es. Nun, das wird überhaupt nicht funktionieren.

Wie ist dieses Ding zumindest nicht optional?

Ein weiterer Schritt zum Docker-Compose-Tod, glaube ich.

Es gibt also eine Problemumgehung. container_name Parameter slug wird nicht verwendet. Zumindest hilft das.

@ shin- bitte, halte dies nicht für einen Fehlerbericht über slug nicht mit container_name . Lass es so wie es ist. Ich packe hier buchstäblich ein.

Oh Junge! https://github.com/ansible/ansible/issues/47978

Obwohl ich den Anreiz hinter der Änderung verstehe, ist er äußerst störend, zumal es keine Nachfrist gibt, um Entwicklern zumindest Zeit zu geben, ihr Skript anzupassen. Viele Skripte wurden unter Berücksichtigung dieser Namenskonvention geschrieben, die buchstäblich für immer existierte. Grundsätzlich macht diese Änderung Docker-Compose 1.23 nicht abwärtskompatibel mit jedem anderen Docker-Compose.

@ shin- Sie persönlich und das gesamte Docker-Compose- und Docker-Team sollten bereits lernen, was rückwärts inkompatible Änderungen sind und wie sie zu einem weit verbreiteten Projekt gebracht werden können, auf das sich die gesamte Branche verlässt.

Erstens geht es bei rückwärts inkompatiblen Änderungen nicht darum, dass Sie das brechen, was Sie zuvor garantiert haben, um es nicht zu tun. Es interessiert niemanden, ob dieses Ding von niemandem benutzt wird.

Eine rückwärts inkompatible Änderung tritt auf, wenn Sie etwas beschädigen, auf das sich Ihre Benutzerbasis tatsächlich verlässt. Und es spielt keine Rolle, welche Garantien es gab, denn es ist schließlich Apache 2.0 und das gesamte Projekt provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND . Ihre Benutzer entscheiden, worauf sie sich verlassen. Und Sie (das gesamte Team) sollten lernen, wie Sie wissen, wer Ihr Projekt nutzt, warum und wie.

Zweitens sollten Sie lernen, wie Sie eine solche Änderung in Ihre Benutzerbasis einführen. Dieses "zufällige Suffix" bricht definitiv die Art und Weise, wie Ihre Benutzer external_links und volumes_from . Daher wäre die Abwertungswarnung für den Fall, dass kein explizites container_name festgelegt ist oder wenn dies so aussieht, sehr willkommen. Bitte betrachten Sie diese Dokumente als vertraut mit "was andere tun":

• https://www.python.org/dev/peps/pep-0004/
• http://api.mongodb.com/python/current/compatibility-policy.html
• https://docs.openstack.org/python-novaclient/pike/reference/deprecation-policy.html
• https://docs.djangoproject.com/de/dev/internals/release-process/#deprecation -policy

Drittens, @ shin-, sollten Sie persönlich lernen, wie Sie mit Menschen sprechen, die nicht direkt zu Ihrem Projekt beitragen und nur Ihre Benutzer sind, aber gleichzeitig sehr beschäftigte Menschen, die Ihrem Projekt so treu sind, dass sie ihr wertvolles Geld investieren können Zeit einreichen Anfragen und Teilnahme an Diskussionen hier mit der einzigen Hoffnung, einen Sinn für die zukünftige Entwicklung des Projekts zu bringen und zu vermeiden, mehr Ressourcen in die Migration zu einer anderen Lösung zu investieren.

Viertens versucht das Docker-Team, mit dem Docker Geld zu verdienen, aber es geht nicht um Docker selbst. Docker kann nur dann bezahlt werden, wenn die gesamte Docker-Infrastruktur nachweist, dass es sich lohnt, dafür zu zahlen. Ich sehe nicht, wie es ein Produkt ist, das auf den Erfolg der Benutzer ausgerichtet ist, wenn das Entwicklungsteam der Community die meiste Zeit den Rücken kehrt.

Fünftens sind wir alle hier wieder Ihre Colleges und Freunde und keine Feinde, und wir versuchen wirklich, Ihnen bei all dem zu helfen. Und weil wir Ihre Freunde sind, wird der Exodus vom Docker-Stapel schmerzhaft sein, aber im Übrigen sieht der Abschied jetzt überhaupt nicht unrealistisch aus.

Dies ist eine schreckliche Implementierung einer großen Versionsänderung, die die Fähigkeit zur Bereitstellung unseres Frameworks vollständig beeinträchtigt, und ich kann mir nicht einmal vorstellen, wie viele andere genau das gleiche Problem mit absolut null Vorwarnung haben werden. Wenn jemand nicht manuell nach den neuesten Änderungsprotokollen für Docker sucht, hat er keine Ahnung davon, und ich kann mir vorstellen, dass die meisten Leute das nicht tun werden

@ shin- Diese Änderung wirkt sich sehr störend auf vorhandene Workflows aus, und es sollte ein Flag bereitgestellt werden, um keine Slugs zu generieren. Tausende von Stunden Entwicklungszeit wurden für das Schreiben von Skripten und die Automatisierung von Diensten aufgewendet, die auf der Vorhersehbarkeit von Docker-Compose beruhen. Was plant das Team ohne ordnungsgemäße Serviceerkennung, um ein automatisiertes Targeting einzelner Container zu ermöglichen?

Ich habe versucht, die Direktive docker-compose container_name aber sie wurde auf GitLab nicht wirksam.
Aber es sieht so aus, als ob es auf meiner neuesten Version von docker-compose auf Mac Os Mojave funktioniert. Nicht sicher, was passiert :)

Meine .gitlabci.yml -Datei lädt das letzte Bild von tmaier herunter (es sollte 1.23.1 sein).

Hallo zusammen, ein paar allgemeine Kommentare, von denen ich hoffe, dass sie einige der hier geäußerten Bedenken ansprechen:

• Ich verstehe definitiv, dass dies einige Skripte bricht. Unsere Release Notes seit 1.23.0-rc1 sagen so an der Spitze. Dies ist eine Situation, in der der momentane Schmerz uns dabei hilft, eine gesündere Basis zu schaffen.
• Die Vorteile der aktuellen Lösung sind zahlreich und werden teilweise in dieser langjährigen Ausgabe zum Ausdruck gebracht: # 1516 - und das Problem mit docker-compose run wurde hier mehrmals mehrfach gemeldet: # 4688 # 4549 # 5240
• Die Diensterkennung sollte kein Problem darstellen, da sie unter Verwendung von Dienstnamen (anstelle von Containernamen) und Netzwerkaliasnamen behandelt werden sollte, die im zugehörigen Netzwerk statisch sind. Weitere Informationen hierzu finden Sie in den Netzwerkdokumenten
• Ich gehe davon aus, dass dies die Verwendung von volumes_from und external_links in Compose-Projekten erschwert. Bitte beachten Sie, dass bereits vor dieser Änderung nicht garantiert wurde, dass Compose das "erwartete" Format für einen bestimmten Containernamen einhält (siehe z. B. # 6155 oder das in # 3415 erwähnte Präfix), was es zu einer fehlerhaften Lösung macht, die zur Ausführung neigt auf lange Sicht in dunkle Fragen.
  
  
  
  • Die empfohlene Methode, um Containern aus verschiedenen Projekten die Kommunikation zu ermöglichen, besteht darin, dass sie ein external -Netzwerk gemeinsam nutzen und die Alias ​​(e) des anderen Dienstes verwenden. In ähnlicher Weise sollten volumes_from projektübergreifend stattdessen external benannte Volumes nutzen.
  
  
• Ich bin an Vorschlägen interessiert, wie diese Änderung besser hätte kommuniziert werden können. Als Referenz wird die Änderung in unserem rief worden Release Notes zum Testen da 1.23.0-rc1 und zur Verfügung, die 26 veröffentlicht wurde September 1.23.0 GA wurde mehr als ein Monat später wieder freigelassen, und zu wissen , die Änderung umstritten wäre, Wir haben es als große Warnung oben im Changelog platziert. Wenn ich noch etwas hätte tun können, um diese Änderung sichtbar zu machen, höre ich gerne zu und mache diese Dinge, wenn wir das nächste Mal eine riskante Änderung wie diese in Betracht ziehen.
  
  
  
  • Auf der anderen Seite bin ich mir sicher, dass die meisten von Ihnen erkennen, dass dies kein gesunder und vernünftiger Weg ist, wenn der allgemeine Aspekt hier lautet: "Nehmen Sie niemals Änderungen vor oder lassen Sie mich auf unbestimmte Zeit von allen abmelden." Informationen zum Verwalten eines Softwareprojekts in der Größe von Compose, das bereits viele Aufgaben erfüllt, um die Abwärtskompatibilität mit einer Vielzahl von Docker Engine-Versionen, Compose-Dateiformaten und veralteten Redewendungen zu gewährleisten.
  
  

Lassen Sie mich wissen, wenn es etwas gibt, das hier nicht angesprochen wird. Ich verstehe, dass dies für viele von Ihnen ein großer Geschwindigkeitsschub ist und die Gemüter aufflammen können, wenn wir mit unvorhergesehenen Umständen zu tun haben. Nehmen Sie sich die Zeit, die Sie für das Upgrade benötigen, und stecken Sie Ihre Compose-Version vorerst fest. Gerne helfen wir Ihnen bei Fragen wie "Wie mache ich XYZ ohne vorhersehbare Namen?" bis dahin in diesem Thread oder auf Slack. Und seien Sie bitte rücksichtsvoll bei der Interaktion mit anderen in diesen Foren. Überprüfen Sie noch einmal, ob die Informationen, die Sie teilen, korrekt sind (ich habe bereits einige Threads gesehen, die dort erwähnt oder umgeleitet wurden, die nichts mit dieser Änderung zu tun hatten , was ein unnötiges Alarmgefühl erzeugt und den Menschen mit dem Problem, die hier fehlgeleitet werden, nicht hilft) und das Gespräch nicht entgleisen lässt. Vielen Dank für Ihre Zeit und Geduld.

Im Kommunikationsbereich würde ich erwarten, dass eine solche Änderung zuvor über einen Kommunikationskanal kommuniziert und erklärt wird, im Grunde so, wie Sie es hier in diesem Thread getan haben, und erklärt, warum und was jetzt zu tun ist, aber vorher all die Folgen.

@ shin- Du hast meinen letzten Kommentar und meine Links, die ich bereitgestellt habe, nicht gelesen, oder?

Der letzte von dir sieht nett aus, fühlt sich aber genauso an.

Ich bin an Vorschlägen interessiert, wie diese Änderung besser hätte kommuniziert werden können.

TL; DR

• Stellen Sie das neue version des docker-compose.yml
• Fügen Sie DeprecationWarning für external_links mit einem Link zu einem Dokument hinzu, das das Update beschreibt und eine Beispiellösung für diejenigen bereitstellt, die zur Migration bereit sind.
• Unterstützen Sie das alte Verhalten für alle Versionen des Compose-Dateiformats vor der neuen.

Als Referenz wurde die Änderung in unseren Versionshinweisen erwähnt

Das Changelog ist eine Sache für Mitwirkende. Benutzer lesen es nicht. Ein Benutzer installiert docker-compose und betet, dass es nach gestern noch funktioniert.

Auf der anderen Seite bin ich mir sicher, dass die meisten von Ihnen erkennen, dass dies kein gesunder und vernünftiger Weg ist, wenn der allgemeine Aspekt hier lautet: "Nehmen Sie niemals Änderungen vor oder lassen Sie mich auf unbestimmte Zeit von allen abmelden." Informationen zum Verwalten eines Softwareprojekts in der Größe von Compose, das bereits viele Aufgaben erfüllt, um die Abwärtskompatibilität mit einer Vielzahl von Docker Engine-Versionen, Compose-Dateiformaten und veralteten Redewendungen zu gewährleisten.

Ich habe eine gute Nachricht für Sie. Sie haben bereits garantiert, dass Sie niemals Änderungen vornehmen oder mich auf unbestimmte Zeit von allen abmelden lassen. Und mehr noch, Sie haben eine Funktion dafür. Es ist die version in docker-compose.yml Datei. Ziehen Sie also in Betracht, diese Änderung so schnell wie möglich zurückzusetzen und für die nächste version -Nummer einzuführen.

Gerne helfen wir Ihnen bei Fragen wie "Wie mache ich XYZ ohne vorhersehbare Namen?" bis dahin in diesem Thread oder auf Slack.

Bitte geben Sie die Lösung für external_links und externe Volumes an, ohne dass container_name in einem anderen docker-compose.yml in diesem Thread definiert ist (wie wir sehen, dass dies nicht immer funktioniert).

Dies ist eine beliebte Methode, mit der Ihre Benutzer Ihr Projekt verwenden. Die meisten Ihrer Benutzer verwenden Docker-Compose für die lokale Entwicklung. Oft befinden sich mehrere miteinander verbundene Projekte in der Entwicklung. In einem solchen Fall ist es üblich, mehrere Docker-Compose-Dateien an dasselbe Netzwerk zu leiten und external_links für Dienste aus verschiedenen Projekten zu definieren, damit sie sich auf dem Computer des Entwicklers erreichen können.

Entgleisen Sie das Gespräch nicht

@ shin- Alle Gespräche, die ich bisher mit Ihnen gelesen habe, werden entgleist, weil Sie nichts tun, um die Probleme der Menschen zu lösen.

Im Ernst, mit einer solchen Einstellung, die ständig die Anfragen der Benutzer ablehnt und Ihren Community-Kampf erzwingt, wenn Sie vermeiden können, dass Sie dieses Projekt besser an jemand anderen weitergeben.

PS: Entschuldigung für einen weiteren "offtopic" Kommentar. Fühlen Sie sich frei, dieses Problem zu sperren, wenn Sie auch verwendet werden.

Bitte geben Sie die Lösung für external_links und externe Volumes an, ohne dass container_name in einer anderen docker-compose.yml in diesem Thread definiert ist (wie wir sehen, funktioniert dies nicht immer).

Bereits getan, beziehen Sie sich bitte auf meinen früheren Kommentar:

Die empfohlene Methode, um Containern aus verschiedenen Projekten die Kommunikation zu ermöglichen, besteht darin, dass sie ein external -Netzwerk gemeinsam nutzen und die Alias ​​(e) des anderen Dienstes verwenden. In ähnlicher Weise sollte volumes_from projektübergreifend stattdessen external benannte Volumes nutzen.

Der Rest Ihres Beitrags ist unnötig kontrovers und ich werde nicht darauf antworten. Ich bin hier und bereit, eine Diskussion zu führen, aber ich muss Ihr Mobbing nicht ertragen.

Ehrlich gesagt, @ shin-

Ich bin an Vorschlägen interessiert, wie diese Änderung besser hätte kommuniziert werden können

Ich sehe nicht, dass Sie „interessiert“ sind. Wenn Sie das Ticket zum Abrufen von Bildern vor dem Erstellen einer Erstellungsdatei schließen und diese als „Spam“ (lol) markieren, sagen Sie mir, dass Sie definitiv nicht interessiert sind, was die Community vorschlägt. Ich weiß wirklich nicht, was Sie erreichen wollen, aber ich bin der Meinung, dass die Aufrechterhaltung einer Beziehung zur Gemeinschaft von jemand anderem gehalten werden sollte.

Ich bin hier und bereit, eine Diskussion zu führen

Selbst wenn wir reine verdienstvolle Argumente liefern, ignorieren Sie sie einfach. Wieso sich die Mühe machen?

PS. Markieren Sie dies als offtopic, zeigen Sie uns, wie Sie unsere Meinung respektieren. Es tut weh, so viele positive Stimmen zu unterschiedlichen Meinungen zu sehen?

Bereits getan, beziehen Sie sich bitte auf meinen früheren Kommentar:

Ich sehe dort leider keine funktionierende Beispiellösung.

Der Rest Ihres Beitrags ist unnötig kontrovers und ich werde nicht darauf antworten. Ich bin hier und bereit, eine Diskussion zu führen, aber ich muss Ihr Mobbing nicht ertragen.

Entschuldigung, wenn Sie sich so fühlen. Bitte erwägen Sie, das alte Verhalten für aktuelle Docker-Compose-Dateiversionen zu unterstützen und die neue Formatversion einzuführen, die sich auf die neue Weise verhält. Dies ist die einzige Option, die Sie benötigen, um eine gute Lösung für Ihre Benutzerbasis bereitzustellen.

Bitte. Lesen Sie diese beiden Kommentare noch einmal mit der Idee, dass ich bereit bin, dem Projekt in Ihrem Kopf zu helfen:

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

Zu den Mitteilungen: Wir haben das Update über Docker für Mac erhalten, und es schien kein Änderungsprotokoll anzuzeigen, das auf diese Änderung hinweist. Daher dauerte es eine Weile, um herauszufinden, warum sich unsere Umgebungsvariablen geändert hatten.

Als ich mir dessen bewusst wurde, nutzte ich die Gelegenheit, um unsere Konfiguration von Version 1 auf Version 3 zu aktualisieren und mithilfe von Dienstnamen anstelle von Umgebungsvariablen zu verknüpfen. Dadurch wurden die Dinge tatsächlich viel sauberer

FWIW, ein abwärtskompatibler Hack zum Ausführen in einem von compose erstellten Container:

docker container exec -it $(docker container ls -f name=expected -q) cmd

Als ich mir dessen bewusst wurde, nutzte ich die Gelegenheit, um unsere Konfiguration von Version 1 auf Version 3 zu aktualisieren und mithilfe von Dienstnamen anstelle von Umgebungsvariablen zu verknüpfen. Dadurch wurden die Dinge tatsächlich viel sauberer

Könnten Sie hier bitte ein kurzes Beispiel für den Dienstnamen angeben, der über verschiedene Docker-Compose-Dateianwendungen hinweg verknüpft ist?

docker container exec -it $(docker container ls -f name=expected -q) cmd

Dies hat jedoch nichts mit Docker-Compose zu tun.

@lig Dies expected . Diese Problemumgehung wäre ohne die Änderung des Namensschemas nicht vorhanden.

@joebowbeer Das Hauptproblem nach dieser Änderung ist die Verknüpfung zwischen Docker-Compose-Dateien. Ich sehe, es gibt eine Möglichkeit, einen Container zu finden, der von Docker-Compose über Docker Cmd gestartet wurde. Aber dies ist eine kleine Hilfe zu diesem Thema :(

@ shin- Ich denke, wir warten alle noch auf die Erklärung, warum wir Docker Composer brauchen, um Namen von Schwarmliniencontainern zu generieren.

Für mich ist es ziemlich klar, dass niemand in seinem gesunden Zustand Komponisten für Produktionszwecke verwenden müsste. Compose ist ein leistungsstarkes Projekt zum Hochfahren, das lokal getestet werden soll. Ich sehe nicht den Reiz, einen Docker-Schwarm-Vorteil / eine Funktionalität für ein Tool zu erhalten, das massiv nur für lokale Tests verwendet wird. Wenn wir einen schwarmartigen Namen für Container benötigen würden, würden wir einen Schwarm verwenden. Recht?

Die zweite große Frage lautet hier: Warum wurde dies nicht durch ein Argument als Optionsmerkmal aufgenommen? Ich sehe in keinem meiner Foren und Communitys Leute, die dieses Verhalten als Standard verwenden. Wir sollten es also wahrscheinlich als neues Argument einführen: docker-compose up --slug . Einfach, elegant und würde niemandes Skripte brechen.

  * On the flipside, if the general takeaway here is "don't make any breaking change ever, or let me opt out of all of them indefinitely", I'm sure most of you realize that it's not a healthy, reasonable way to go about maintaining a software project the size of Compose, which already jumps through a lot of hoops to maintain backward-compatibility with a wide array of Docker Engine versions, Compose file formats, and deprecated idioms.

In der Vergangenheit hatten wir in Unternehmen die Regel "Zwei Hauptversionen" zum Brechen von Änderungen - in einer veraltet, in der nächsten entfernt. Ich bin mir nicht sicher, wie dies hätte erfolgen können, aber ein vorübergehendes Opt-out wäre wirklich wünschenswert gewesen.

Docker-compose scheint kein Konzept für Hauptversionen zu haben, aber ich sehe nicht, wie eine vorübergehende Option zum Deaktivieren dieser Option (ob über die Befehlszeile oder in der Compose-Datei) auf ein oder zwei Releases (1.23 und möglicherweise 1.24) würde "auf unbestimmte Zeit" darstellen.

Angesichts der Tatsache, dass dies mit automatischen Updates für Nicht-Linux-Benutzer verbunden zu sein scheint, waren viele Leute überrascht, und anstatt den Rest des Quartals damit zu verbringen, "mit diesem Befehlszeilenflag auszuführen, während wir unsere Skripte aktualisieren". Wir haben eine ganze Reihe von Entwicklern, die entweder manuell ein Downgrade durchführen und / oder das, was sie tun, um Skripte zu aktualisieren, löschen müssen.

Diese bahnbrechende Veränderung ist eine Katastrophe. Hat viele automatische Bereitstellungen plötzlich abgebrochen. Bitte mach das nicht noch einmal.

* Introduce the new `version` of the `docker-compose.yml` 
* Add `DeprecationWarning` for `external_links` with a link to a document which describes the update and provides a sample solution for those willing to migrate.
* Support the old behavior for all compose file format versions prior the new one.

Macht zu viel Sinn ... keine Ahnung, warum es nicht so gemacht wird.

Ich bin hier und bereit, eine Diskussion zu führen, aber ich muss Ihr Mobbing nicht ertragen.

@ shin- es ist ziemlich offensichtlich, dass es hier keine Diskussion gibt, da Sie keine rationalen Vorschläge berücksichtigen. Und wenn jemand schikaniert - Sie sind es -, schikanieren Sie mit dieser bahnbrechenden Veränderung effektiv zahlreiche Entwickler auf der ganzen Welt.

Viele Leute (ich und eine andere Person wahrscheinlich) verwenden Compose nicht für den Schwarmmodus. Ich gebe eine niedrigere Version für meine Compose-Dateien an, da ich in der Vergangenheit Probleme hatte, bei denen davon ausgegangen wird, dass eine Compose-Datei zum Definieren von Diensten für Schwärme verwendet wird. Ich stellte fest, dass die von mir angegebene Version an die Ergebnisse gebunden war, die auf meinem Docker-Knoten erzeugt wurden. Wenn ich die Version auf einen niedrigen Wert sperrte, konnte ich konsistente Ergebnisse erzielen und trotzdem Aktualisierungen vornehmen, um mit der Docker-Version kompatibel zu bleiben Ich renne. Anscheinend kann ich hier keine richtige Versionierung erwarten.

Können wir die Docker-Komposition andocken, um sicherzustellen, dass sie unsere Sachen nicht plötzlich kaputt machen?

Ich denke, die beste Lösung wäre, eine neue Konfigurationsoption in die Datei docker-compose.yml einzuführen, bei der das Hinzufügen des Slug-Teils zu den Containernamen deaktiviert werden könnte.

s / disabled / enabled /. Zumindest bei vorhandenen Compose-Dateiversionen.

Dieses Verhalten muss an die Versionsnummer der Erstellungsdatei gebunden sein. Unabhängig davon, ob dieses Verhalten „spezifiziert“ wurde, ist es ziemlich weit verbreitet und daher eine rückwärts inkompatible Änderung. Warum sollte die Spezifikation zu diesem Zeitpunkt überhaupt versioniert werden, wenn nicht garantiert wird, dass das, was eine Compose-Datei tut, beim Upgrade meiner Binärdatei auf die gleiche Weise funktioniert? Wenn ich eine Compose-Dateispezifikation ablehne (mit viel Warnung, wenn docker-compose natürlich ausgeführt wird) und sie dann entferne, wäre es definitiv meine Schuld, dass alle meine Sachen nicht mehr funktionieren, aber ich erwarte, dass ich Ihre Veröffentlichung durchlese Notizen für ein Programm, das das Privileg hat, mir Warnmeldungen ins Gesicht zu drucken?

Änderungen wie diese scheinen eine gute Motivation für die Versionierung des Verhaltens der Spezifikation zusätzlich zu ihrem Format zu sein: Sie können die Annahmen anderer Codes mit Warnung ablehnen. Ich denke, die Menge an externen Problemen, die dieses Problem benennen, spricht dafür, wie überraschend dies für viele Menschen war. Es ist wirklich großartig zu sehen, wie altes Verhalten zerstört wird, damit der Code nicht kompliziert wird, aber solche Änderungen können nicht auf einmal angewendet werden. Kann ich erwarten, dass andere Annahmen zum Erstellen von Containernamen nicht mehr funktionieren? Befindet sich der Dienstname immer im Containernamen oder kann dieser wie die vorhersehbaren Namen entfernt werden?

Dies erinnert mich wirklich daran, als die konsistente Benennung von gibt jedoch eine Möglichkeit, das alte Verhalten auf systemd-Systemen (und auf anderen Systemen, aber es kann variieren) wiederherzustellen, indem Sie den Kernel-Argumenten net.ifnames=0 hinzufügen.

(Entschuldigung für den zweiten Durchgang, aber ich denke nicht, dass mein erster sehr konstruktiv war.)

Es scheint, dass diese Änderung die Option --scale unbrauchbar macht. weil das zufällige Postfix bekannt sein muss, um skalierte Instanzen eines Dienstes zu erreichen.

Zum Beispiel mehrere Dienstinstanzen als Upstream-Server für Nginx.

Bearbeiten: Weitere Informationen finden Sie unter # 6365

Wow, was für eine schreckliche Veränderung. 👎

Wie sollen wir die zufällig generierte Zeichenfolge zur Verwendung in Skripten erhalten?

Ich bin auch auf dieses Problem gestoßen und möchte meine Empfehlung für zukünftige rückwärts inkompatible Änderungen ausdrücken. Wir haben auch Skripte, die auf dem Format project_service_index basieren, wobei viele Leute diese Skripte auf dem Mac verwenden. In einer idealen Welt könnten wir die Version von Docker für Mac steuern, die von Benutzern verwendet wird. Derzeit wird jedoch ein Upgrade durchgeführt, wenn das Dialogfeld für die automatische Aktualisierung angezeigt wird.

Meine Probleme und Empfehlungen sind:

1) Der Upgrade-Dialog hatte keinen Hinweis auf diese signifikante Änderung, daher hatten wir keine offensichtlichen Hinweise auf diese Änderung. In einer idealen Welt würden wir alle Versionshinweise für jedes Upgrade überprüfen, aber im Moment nicht. Es wäre also sehr dankbar, wenn im Aktualisierungsdialog explizit etwas Bedeutendes wie dieses aufgerufen würde.

2) Aufgrund von 1) gab es keine offensichtliche Warnung. Es wäre großartig, wenn eine solche Änderung im vorherigen Upgrade angekündigt würde. Zum Beispiel würde das Upgrade vor dem letzten so etwas wie "Containernamensschema ändert sich in der nächsten Version, bitte aktualisieren Sie Ihre Skripte" sagen.

3) Ich verstehe, dass nach dem Lesen dieses Threads das von uns verwendete Namensschema nicht garantiert ist, und ich erkenne, dass es bessere Möglichkeiten gibt, auf Container zu verweisen. Wir haben jedoch alle ein arbeitsreiches Leben und müssen unsere Aufgaben planen. Daher kann ich als Betreuer unserer Skripte unsere Verwendung von Containernamen nicht sofort in etwas Besseres umwandeln. Ich verwende gerne die empfohlenen Best Practices, benötige jedoch Zeit, um unseren Code zu migrieren. Daher wäre es großartig, eine Abschreibungsstrategie für eine solche Änderung zu haben.

Der wichtigste Aspekt hierbei ist, dass der größte Teil der Welt von einem Containernamensschema ausgeht, das für die Verwendung von Docker Compose von grundlegender Bedeutung ist. Eine Änderung des Standardverhaltens ohne eine offensichtliche Verfallsstrategie kann sich nachteilig auf diese Workflows auswirken.

Die Leute verwenden Software nicht immer genau so, wie sie beabsichtigt war, und es liegt in der Verantwortung dieser Leute, Dinge zu reparieren, wenn ihre Annahmen fehlschlagen. Ein paar einfache Mitteilungen können uns jedoch dabei helfen, uns auf zukünftige Änderungen vorzubereiten, und uns motivieren, auf die neuesten Best Practices umzusteigen.

Wenn Sie zuvor von docker container exec -it project_php_1 bash abhängig waren, können Sie dies nicht mehr verwenden.

Sie müssen docker ps , um die Service-ID zu finden.

Sie können jedoch nicht docker ps -q --filter=name=project_php da dies für Dienste mit den Namen project_php und project_php_xdebug oder für alles andere gilt, das mit project_php übereinstimmt.

Die zuvor lesbaren docker container exec -it project_php_1 bash nun folgende werden:

docker container exec -it \
    $(docker ps -q \
        --filter label=com.docker.compose.project=project \
        --filter label=com.docker.compose.service=php) \
    bash

Dies war eine schlecht durchdachte Änderung.

@jtreminio FWIW, aus dem Projekt können Sie immer noch docker-compose exec php

Vielen Dank an alle, die sich die Zeit genommen haben, ihre Gedanken über die Veränderung zu teilen. Wir sind uns einig, dass dies schlecht gehandhabt und unsererseits etwas übereifrig war, und es wurde teilweise in Compose 1.23.2 zurückgesetzt (wir behalten zufällige Suffixe für Container bei, die von docker-compose run , wodurch wir diese eleganter handhaben können : # 4688 # 4549 # 5240, wie ursprünglich beabsichtigt).

Lassen Sie mich wissen, ob noch offene Fragen zu klären sind.

Gibt es einen Plan, entweder eine Befehlszeilenoption hinzuzufügen, um dies zu deaktivieren? --no-slug oder bevorzugter --slug damit die Standardeinstellung wie früher funktioniert.

1.23.2 kehren zu dem zurück, was es vorher war.

Es wurde nur für docker-compose up , nicht aber für docker-compose run

Vielen Dank für die schnelle Lösung!

Am 28. November 2018, um 20:09 Uhr, schrieb Joffrey F [email protected] :

Vielen Dank an alle, die sich die Zeit genommen haben, ihre Gedanken über die Veränderung zu teilen. Wir sind uns einig, dass dies schlecht gehandhabt und unsererseits etwas übereifrig war, und es wurde teilweise in Compose 1.23.2 zurückgesetzt (wir behalten zufällige Suffixe für Container bei, die durch Docker-Compose-Lauf erstellt wurden, wodurch wir diese eleganter handhaben können: # 4688 # 4549 # 5240, wie ursprünglich beabsichtigt).

Lassen Sie mich wissen, ob noch offene Fragen zu klären sind.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

@ shin- Ich gehe davon aus, dass dies irgendwann zurückgegeben wird - möglicherweise in 1.24 (da es sich um eine so bahnbrechende Änderung handelt?). Wenn ja, könnten Sie mit der Community zusammenarbeiten, um alternative Leichtbaumechanismen für Menschen zu verstehen und zu empfehlen, die diese ohne Schnecken verwenden? Ich bin mir nicht sicher, wo ich mich am besten unterhalten kann.

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

geändert von <project>_<service>_<index> zu <project>_<service>_<index>_<slug>

Dies ist ein Fehler, keine Funktion.
Vielen Dank!
Denken Sie an ansible Playbooks, die mit ansible_connection=docker ... 😔 laufen !!
sollten wir explizit container_name ? oder werden wir unser Inventar weiterhin mit dem zufälligen <slug> aktualisieren !!.
Wirklich sehr schlecht!