@jmmills Können Sie Ihre Container nicht starten, z.

@aanm Ja, aber ich denke, dass die Funktionalität standardmäßig in der

@ @aanm Erwarten Sie, dass ein docker-compose up den Parameter scale berücksichtigen sollte? Das einzige Problem, das ich dabei sehe, ist, dass wir Parameter in die deklarative Konfiguration einführen, die NICHT mit den zugrunde liegenden Docker / Docker-API-Konzepten kompatibel sind, aber sehr spezifisch für Docker Compose sind.

Wenn wir dies in Zukunft tun würden; Ich würde so etwas vorschlagen:

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

Wobei $<parameter> ein Docker Compose-spezifisches Ding bezeichnet.

Wir sind hin und her gegangen, ob scale in die YAML gehört; Es gab schon einmal eine PR, um es hinzuzufügen (#630). Ich bin immer noch der Meinung, dass die meisten Leute keine Skalenzahlen in ihre Konfiguration aufnehmen sollten, weil dies weniger portabel ist, aber ich verstehe die Anwendungsfälle dafür.

Jetzt, da wir eine rudimentäre Möglichkeit haben, Compose-Dateien mit extends (und hoffentlich bald besseren - #1380, #758) zu erweitern, habe ich die Bedenken, die ich in https://github.com/docker/compose geäußert habe

Ich möchte scale=0 in meiner Yml für testbezogene Dienste festlegen, die normalerweise nicht gestartet werden sollen. Ich möchte diese Dienste nur explizit mit docker-compose run oder einem expliziten scale erstellen.

@jamshid Das habe ich mir oft gewünscht, eine Definition, die eine Umgebung docker run ), und dann verbraucht meine Containerzusammensetzung die Basisbild.

So etwas scheint für Entwicklerkonfigurationen ziemlich nützlich zu sein

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

@jamshid @jmmills Was ist mit einem enabled Parameter/Schlüssel in der YAML-Datei pro Dienst? Damit Sie einen Dienst deaktivieren/aktivieren können?

@prologic Warum tun Sie das, wenn der Parameter "Skala" beide Anforderungen erfüllen würde?
Wenn man sich einen laufenden Prozess/Container als Instanz einer Klasse vorstellen möchte, könnte man ihn sogar instances

@jmmills Ich versuche nur, eine _Lösung_ für Ihren Anwendungsfall zu finden, bei der es nicht darum geht, das aktuelle docker-compose als solches zu brechen. Ich neige dazu, dass scale=0 nicht so passend erscheint und ich bin mir nicht sicher, ob scale=X überhaupt Teil von Compose selbst sein sollte.

Meiner Meinung nach ist der Maßstab (oder die Anzahl der Kopien) Teil der Zusammenstellung eines Dienstes und sollte daher in das Verfassen einbezogen werden.

Nun, ich denke, wir haben entweder einen scale=0 oder disabled Schlüssel.

:+1: über die Möglichkeit, eine Standardgröße von scale für eine Instanz festzulegen. Und ich stimme zu, sobald die Skalierung aktiviert ist, ist keine Taste disabled erforderlich, da Sie die Skalierung einfach auf 0 setzen würden.

+1

Außerdem ein weiterer Anwendungsfall: Was ist, wenn ich die Anzahl der Container skalieren möchte, aber nicht alle Dienste im Hintergrund anzeigen möchte oder zu einem anderen Terminal (oder Prozess) springen und meine Staffelnummern festlegen muss ...
z.B:

$ docker-compose up && docker scale thing=4

Funktioniert nicht, da up nicht beendet wird.
Aber wenn meine Kompositionsdatei den Maßstab meiner Container festlegt...

$ docker-compose up

Wird zu DWIM.

Ich bin mir nicht sicher, ob mir das wirklich gefällt; plötzlich nimmt up zwei Fähigkeiten an:

• Rufen Sie alle Container auf, die den Parameter scale nicht haben.
• Bringen Sie alle Container hoch, die scale=0 .

Wir missbrauchen jetzt wirklich den Befehl "up". "Scale" bekommt auch eine neue Bedeutung, indem es jetzt zwei Dinge tut:

• Behälter hoch/runter skalieren
• Deaktivieren Sie Container/Dienste mit ` scale=0

Warum sollten Container mit einem scale=0 aufgerufen werden?
Build würde Images mit einem scale=0 erstellen, wodurch ein Basis-Image-Bedarf erleichtert wird.

Ich _könnte mich irren_, aber das Lesen Ihres letzten Kommentars deutete darauf hin :)

Lassen Sie mich näher erläutern:

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

Nun, erwartetes Verhalten: docker-compose build alle Container mit "build" (komponiert externe Images beim Build? Weiß nicht mehr), docker-compose up würde alles mit positiver Skalierung ausführen (Standard ist 1) würde docker-compose run test_harness bei Bedarf "base_thing" erstellen und meinen einen Befehl ausführen. Kapieren? :)

Bearbeiten: docker-compose up würde 1 "thing" und 4 "workers_for_thing" ausführen

Okay danke; dein Beispiel macht ein bisschen mehr Sinn und ein bisschen klarer in Bezug auf die Absicht von scale=0

Ich denke, docker-compose "zieht" Bilder auf up / run .

Ich muss ein Rezept erstellen, um die Anzahl der De Instanzen (Skala) anzugeben, für Test, Produktion, Qa usw.

+1 für scale=X . Dies wäre sehr hilfreich.
Und +1 für @jmmills Kommentar mit Konfigurationsbeschreibung und erwarteten Ergebnissen.

Yay! für scale=x . Das Initialisieren einer Reihe von Containern würde definitiv dazu beitragen, potenzielle Race-Bedingungen beim Einrichten von Cluster-Konfigurationen zu identifizieren.

+1 für scale=x (einschließlich scale=0 zum Deaktivieren der Dienste für die ersten docker-compose up )

+1 für scale=x .

x ist NaN, ich würde stattdessen -1 vorschlagen.

+1 für Maßstab=x.

+1

+1

Wie wäre es, wenn wir mit den +1 aufhören, bitte?

+1 ist nützlich, um das Interesse an einer Funktion zu erkennen.

@shofetim Ich kenne einen besseren Weg, um genau das zu tun: Implementieren Sie das fragliche Feature und senden Sie einen Pull-Request...

+1 ist auch eine gute Möglichkeit, um zu sehen, wie sich die Leute auf einen Lösungsvorschlag einigen. Sein ziemlich übliches Verhalten auf github. Wenn Sie in den Benachrichtigungen auf die Schaltfläche zum Abbestellen klicken, werden diese deaktiviert, wenn dies ein Problem darstellt.

Nun, es sieht nach solchen Leuten aus. Es gibt ein ähnliches Element im Compose-Backlog (überbleibt von Abb), ich bin mir ziemlich sicher, dass ich irgendwann einen Kommentar dazu abgegeben habe. Ich werde versuchen, es später heute Abend weiterzuverfolgen.
Ich bin die meiste Zeit dieser Woche auf der PuppetCon, also hoffe ich, dass mir das etwas Zeit zum Hacken verschafft - ich werde sehen, ob ich das schreiben kann.

Hier ist ein Workaround für den Anwendungsfall "scale=0":

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

@wkonkel ja, ich habe in der Vergangenheit ähnliche Dinge getan.

Ich arbeite gerade daran, mich mit der Compose-Codebasis vertraut zu machen, sobald ich weiß, wo all die Dinge für Compose sind, werde ich einen PR für einen Scale-Konfigurationsparameter hacken.
Es scheint nicht so schwer zu sein, es gibt eine scale Methode für ein Projekt, das das Backend für die CLI-Schnittstelle ist, also sollte ich eigentlich nur "scale" hinzufügen Wenn es vorhanden ist, um es nach der Containererstellung aufzurufen, stellen Sie sicher, dass es keinen Container ausführt, wenn es auf Null gesetzt ist.

Dafür gibt es tatsächlich eine ganz alte PR-Opening: #630.

Das Problem ist, dass die Skalierung ein betriebliches Problem ist, es ist nicht Teil der Anwendungsdefinition und passt daher nicht wirklich in die Compose-Datei.

Es wäre schön, eine Konfiguration für eine Standardskalierungsebene zu unterstützen, aber ich glaube nicht, dass die Compose-Datei der richtige Ort dafür ist.

Der Fall von scale: 0 sollte bereits mit #1754 behandelt werden. Ein "No-Op"-Container kann nur einen Befehl haben, der sofort beendet wird (echo, true usw.). Die Fälle, in denen Sie scale: 0 benötigen, sind normalerweise einer von zwei: Datenvolumen-Container oder "Adhoc-/Admin-Aufgaben".

Schon bald sollten wir keine Datenvolumencontainer benötigen, da Volumes neue API-Endpunkte erhalten und wir in der Lage sein werden, Volumes ohne Container zu definieren.

Administrative Aufgaben werden mit #2051 besser abgewickelt. Sie können admin.yml das den Kern docker-compose.yml und es Ihnen ermöglicht, Ihre administrativen Aufgaben mit der "Kernzusammensetzung" zu verknüpfen, ohne die Definition jedes einzelnen zu verwirren.

Beide Änderungen sind jetzt in Master und werden in der Version 1.5.0 (die gleich um die Ecke ist) verfügbar sein.

Damit bleibt nur der Fall, dass Sie einen Dienst standardmäßig auf > 1 skalieren möchten. Es ist schon ziemlich einfach, so etwas zu skripten, aber es wäre immer noch schön, es in eine Konfigurationsdatei zu schreiben. Ich denke, wir werden die Idee einer separaten Konfiguration in #745 untersuchen. Meiner Meinung nach wäre diese neue Konfiguration ein guter Ort für Dinge, die nicht Teil der Anwendungsdefinition sind (Projektname, Standardnetzwerkname, Standardskalierung usw.).

Ehrlich gesagt bin ich nicht damit einverstanden, dass die Größe nur ein operatives Anliegen ist. Anwendungen können sich um die Mindestanzahl der ausgeführten Dienste kümmern.
Was einen No-Op-Container angeht, fühlt es sich ungeschickt an, einen Container tatsächlich auszuführen, wenn der Zweck dieses Containers darin besteht, ein Basis-Image auszulösen, in dem andere Container für ihr image Feld verwenden.

Anwendungen können sich um die Mindestanzahl der ausgeführten Dienste kümmern.

Könnten Sie ein Beispiel für diesen Fall nennen?

Was einen No-Op-Container angeht, fühlt es sich kläglich an, einen Container tatsächlich auszuführen, wenn der Zweck dieses Containers darin besteht, ein Basis-Image auszulösen, in dem andere Container für ihr Image-Feld verwenden

Gibt es einen Grund, warum das Basis-Image Teil desselben Builds sein muss? Wie ich in #1455 hervorhebe, ist Compose nicht in erster Linie ein "Docker-Build"-Tool. Ziel ist es, eine Zusammenstellung von Containern zur Laufzeit bereitzustellen. Der Versuch, jedes mögliche Build-Szenario zu unterstützen, erhöht den Umfang der Erstellung erheblich und lenkt den Fokus von der Container-Komposition ab. Es wäre selbst für ein Tool, das zum Erstellen von Bildern entwickelt wurde, schwierig, jede dieser Anforderungen zu unterstützen. Ich denke, eine bessere Richtung besteht darin, einen möglichst großen Teil der Build-Komplexität aus dem Compose herauszuhalten und den Benutzern zu ermöglichen, das entsprechende Build-Tool anstelle von docker-compose build .

Der Anwendungsfall, der mir wichtig ist, ist scale=0 (vielleicht wäre abstract=true ein besserer Deskriptor). Ich möchte Bilder und Umgebungsvariablen mit verschiedenen Befehlen teilen. Insbesondere möchte ich, dass ein Webserver und ein Server für Hintergrundjobs ausgeführt werden, beide mit demselben Code und beide mit denselben Umgebungsvariablen.

@wkonkel anhand Ihres Beispiels würde das wohl auch funktionieren?

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

Sie tauschen einen Abstract-Service mit einer No-Op-Überschreibung command gegen keinen Abstract mit einer No-Op-Überschreibung auf ports . Klingt das richtig?

1988 bezieht sich auf abstrakte Dienste.

@dnephin Ja, das funktioniert in meinem Fall.

Eigentlich nehme ich das zurück ... Ich habe es gerade mit docker-compose-1.4.2 versucht und es scheint, dass "ports: []" das übergeordnete Element nicht überschreibt, sodass der app_worker nicht mit "Port ist bereits zugewiesen" beginnt ".

@dnephin Der Thread hat vielleicht eine bessere Erklärung, aber ich werde versuchen, es hier zu artikulieren.

Das erste, was mir in den Sinn kommt, sind Jobsysteme, bei denen separate Container, die denselben Code ausführen, wie ein Dienst vom Typ Parent->Fork()->Child-Pool modelliert werden könnten, bei dem die Standardanwendungskonfiguration eine minimale Anzahl von Workern für die Parallelität erfordert.

Meine Inspiration dafür kam von einer App, die RQ-Worker verwendet, die an verschiedene Warteschlangen angehängt sind, die ein Basis-Image teilten, das meine Python-Pakete (Worker-Code) enthielt, aber für jede Warteschlange mehrere Instanzen ausgeführt hatte. Eine Mindestverfügbarkeit der Parallelität war eine Anforderung an die Anwendung aufgrund von Jobs mit langer Ausführungszeit.

Ich denke nur, dass ein No-Op-Befehl wie eine Verschwendung von Ressourcen zu sein scheint, nur um ein gemeinsam genutztes Basis-Image zu erhalten, das auf die gleiche Weise wie der Rest des Anwendungsstapels erstellt wird. Am Ende erhalten Sie eine While-/Sleep-Schleife nur für ein Basisimage, was eine coole Problemumgehung ist, aber keine intuitive Möglichkeit zu sein scheint, dies zu erreichen. Ganz zu schweigen davon, dass ein Element in unserem Prozessbaum ohne Laufzeitfunktion bleibt.

Wenn Docker-Compose wirklich nicht in die Domäne der Codierung von Image-Build-Beziehungen übergehen soll, sollte die Build-Option möglicherweise wegfallen und einige andere Build-Definitionssysteme erstellt werden, damit ich ein Build-Ziel definieren kann, um ein Basis-Image zu erstellen , und dann andere Bilder, die diese Basis mit einigen der geänderten Artefakte/Konfigurationen und in der richtigen Reihenfolge verbrauchen?

Oder vielleicht bin ich einfach zu eigensinnig und sollte meine Docker-Kompositionsbefehle in Shell-Skripte einschließen, um meine Dienste mit Scale zu starten, und alle meine Image-Builds als Make-Ziele mit Abhängigkeiten definieren.

Ich denke nur, dass ein No-Op-Befehl wie eine Verschwendung von Ressourcen zu sein scheint, nur um ein gemeinsam genutztes Basis-Image zu erhalten, das auf die gleiche Weise wie der Rest des Anwendungsstapels erstellt wird.

Mit #1754 (im nächsten Release) ist das nicht mehr nötig. Ein Dienst kann beendet werden und wird die restlichen Dienste nicht stoppen. So können Sie die Basis einfach verlassen und sich keine Sorgen machen.

@dnephin Cool, würden Sie diesem Basis-/Zwischencontainer dann link zur Verfügung stellen, um sicherzustellen, dass er zuerst erstellt wird?

@dnephin : Ich habe einen CI-Läufer, der docker compose up . Ich möchte, dass meine Testumgebung mit mehreren Versionen eines Dienstes ausgeführt wird (dh skaliert). Ich könnte den gesamten Konfigurationsblock kopieren, aber dazu würde ich mich wiederholen. In diesem Fall ist es nicht "nur ein operatives Anliegen", sondern etwas, das ich in meiner Entwicklungsumgebung benötige, während ich eine geclusterte Anwendung entwickle, die derzeit vollständig als Compose-Datei beschrieben wird. Im Moment müsste ich eine Out-of-Band-Skalierungskonfiguration haben und dann irgendwie docker-compose scale aufrufen, nehme ich an, aber das scheint nicht ideal zu sein und bietet weitere Möglichkeiten für Misserfolge und Rennen.

In Produktionsfällen möchten Sie Ihre Dienste möglicherweise mit einem minimalen Maßstab starten. Nehmen wir zum Beispiel an, Sie migrieren von einem Cluster zu einem anderen, und lassen einige schwierige Teile der Migration zur Vereinfachung des Beispiels als Datenkopie aus; und Sie müssen wirklich von Anfang an mit etwas Verkehr beginnen, also müssen Sie mit docker-compose mindestens (n) Instanzen einiger Dienste, sagen wir Web, bereitstellen.

Die Skalierung unter dem Dienst in der Konfigurationsdatei wird das wirklich handhaben. Es ist auch ein Usability-Anwendungsfall, da der Anwendungsfall tatsächlich die Anforderung aufzeigt, dass mindestens (n) Instanzen eines Diensts ausgeführt werden und nicht nur eine am Startpunkt.

Aus meiner Sicht ist Maßstab tatsächlich ein bestimmender Parameter einer Topologie und Komposition.

@dnephin

Könnten Sie ein Beispiel für diesen Fall nennen?

Consul, MariaDB Master-Master oder jede andere verteilte App auf Swarm muss wirklich mindestens 3 Knoten im Cluster haben, um zuverlässig zu sein. Es gibt definitiv Anwendungsfälle für eine Reihe von Diensten, die in der Konfigurationsdatei verfügbar sind. Ich verstehe nicht, warum Sie so dagegen sind. Big :+1: von mir hier.

Ich bin nicht gegen eine Möglichkeit, die Skalierung zu konfigurieren, ich glaube nur, dass sie nicht in die Compose-Datei gehört, da sich der Zustand unabhängig von der Compose-Datei ändert.

Nehmen Sie dieses Beispiel, das davon ausgeht, dass wir der Compose-Datei eine Skalierungskonfiguration hinzufügen:

1. Ich habe eine anfängliche Skala von 3 für eine Dienstleistung festgelegt
2. Ich führe docker-compose up -d , mein Dienst skaliert auf 3
3. Ich laufe docker-compose scale service=4
4. Ich nehme einige Änderungen vor und stelle eine erneute Bereitstellung mit docker-compose up -d .. Was passiert? Wird es wieder auf 3 herunterskaliert? Ignoriert es die Skalierung jetzt vollständig?

Keines dieser Szenarien klingt gut oder angemessen, und dies ist nur ein triviales Beispiel, das Instanzfehler ignoriert (was es noch komplizierter macht).

Wenn es der Compose-Datei hinzugefügt werden sollte, sollten wir den Befehl scale entfernen, damit sie nicht in Konflikt geraten.

Das von Ihnen angegebene Beispiel ist ein Beispiel für eine betriebliche Anforderung. Sie benötigen nicht mehrere Master, um die Anwendung auszuführen, sondern für die Zuverlässigkeit (den Betrieb) des Dienstes. Und das können Sie immer noch mit scale db=x .

Verwenden Sie das obige Beispiel von @dnephin :

Erstens denke ich, dass der Befehl scale auch naiv ist, da Sie nicht sagen können, ob Sie einen Dienst vergrößern oder verkleinern möchten, indem Sie zwei diff-Befehle haben, um die Absicht des Hoch- oder Herunterskalierens zu erklären, indem Sie nur sagen, wie viele Dienste es tun Sie erstellen oder entfernen möchten, ist viel besser.

Die Antwort auf die von @dnephin gestellte Frage lautet, dass ich erwarte, dass so viele Dienste/Container ausgeführt werden wie vor der Änderung.

Compose ist ein zustandsloses Tool, das die Dienste/Container nicht kennt oder überwacht. Es verwendet die Docker-API, um Ops bei der Orchestrierung zu helfen. und jetzt brauchen wir das, wir haben eine Engine, die einfach gut läuft, wir haben eine Maschine zum Bereitstellen und wir haben einen Schwarm, um sie alle zu einem Cluster zusammenzufassen, aber wir verlieren einen echten Orchestrierungsdienst/einen echten Orchestrierungsdienst/einen, der uns die Flexibilität bei der Konfiguration gab und um die bereitgestellten Dienste/Container so zu verwalten, wie es k8s tut. Im Moment ist das Komponieren das, was dem sehr ähnlich ist, aber wenn es nicht in der Zukunft dieses Projekts ist, sich zu etwas Größerem zu entwickeln, werden die offiziellen Entwickler und Betreuer am besten darüber nachdenken, damit wir es anders herausfinden können Werkzeug, das es kann.

Persönlich denke ich, dass es besser sein wird, das Komponieren weiterzuentwickeln, da es ein großartiges Werkzeug ist und für uns alle bekannt ist.

Ich freue mich, dies zu sehen: docker-compose > docker compose .
Bei den restlichen Tools bin ich mir nicht sicher, aber dafür wäre es wirklich schön, eine zustandsorientierte Integration mit der Engine zu haben. Entschuldigung für einen etwas Off-Topic-Kommentar.

Ich habe # 2496 für meinen Vorschlag erstellt, den Skalierungsbefehl zu entfernen und durch die Skalierungsoption zu ersetzen (aus dem obigen Beitrag). Feedback zu diesem Vorschlag wäre toll.

@dnephin mit dem #2496 Compose verliert die Fähigkeit, leicht nach oben oder unten zu skalieren, wir müssen die Compose-Datei neu konfigurieren und dann Compose-Up erneut ausführen, wenn wir nur eine Instanz nach unten oder oben skalieren müssen kompliziert.

Auch hier verlieren wir den Punkt, dass all diese Szenarien davon ausgehen, dass Compose ein zustandsloses Werkzeug ist und den Zustand der Dienste nicht kontrollieren kann und wie viele von ihnen zu einem bestimmten Zeitpunkt vorhanden sind.

Das Szenario, das Sie im neuen Vorschlag erwähnen, wird durch eine State-Full-Service/Tool-Neuzusammenstellung leicht gelöst.

+1

+1

+1

@dnephin Wäre das Verhalten nicht dasselbe, wenn Sie

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

Ist das nicht eher ein Problem mit der internen Skalierung der Komposition?

Das ist die Sache, "Verfassen Sie die Anwendung" ist zustandslos. Der einzige Zustand ist 1) die Compose-Datei und 2) die Docker-Container-Labels, die von der Engine verwaltet werden.

Die Compose-Datei wird nur von einem Menschen bearbeitet, nicht von Compose. Es wäre ein Durcheinander, zu versuchen, Yaml mit den gleichen Kommentaren, der gleichen Reihenfolge und der gleichen Struktur zu schreiben. Es wird von pyyaml ​​nicht unterstützt, und es ist sowieso nicht etwas, was wir wirklich tun möchten.

Die Docker-Engine erkennt die Skalierung nicht und kann diesen Zustand daher nicht speichern. Dies ist mit viel größeren Architekturänderungen möglich, aber das liegt etwas außerhalb des Rahmens dieses Problems.

Im Moment bestehen unsere Optionen im Wesentlichen darin, entweder die Skalierung als Befehlszeilenoptionen beizubehalten oder sie in die Compose-Datei zu verschieben, aber wie ich in #2496 beschreibe, denke ich, dass beides verwirrend ist und zu falschem Verhalten führt.

up && scale && up tut jetzt tatsächlich das Richtige. up erstellt alle Container neu, und da es keinen Skalierungswert in der Konfiguration gibt, gibt es keine Verwirrung darüber, was die gewünschte Skalierung sein sollte. Es wurde bereits durch den Skalierungsbefehl festgelegt und durch Containeretiketten verfolgt.

@dnephin Ich glaube, ich stimme mit dem überein, was Sie sagen, [ich könnte in dieser Annahme falsch sein], dass Sie wirklich in Frage stellen, _ob_ die Anzahl der Instanzen einer Komponente tatsächlich die Zusammensetzung eines Dienstes (eine Gruppierung von Containern) betrifft verschiedene Komponentencontainer ausführen). Ich würde sagen, dass es dieses Problem derzeit anspricht, nur mit dem Vorbehalt, dass die cli und die Kompositionsdefinition (yaml) keine Parität aufweisen.

Wenn der Verantwortungsbereich festgestellt wird, dass der Maßstab nicht die Zusammenstellung betrifft, sollte Maßstab als Clientoption entfernt werden (was wahrscheinlich viele Benutzer verärgert), oder wenn festgestellt wird, dass der Maßstab die Zusammenstellung eines Dienstes betrifft dass es eine Parität zwischen cli und yaml geben sollte, mit der zusätzlichen Unterstützung einer Mindestanzahl von Instanzen, um geclusterte Instanzen zu berücksichtigen, die N+1 erfordern.

Stimme @jmmills zu Besonders bei der Ausführung von Clustern von scale Teil der Anwendung: Ohne die richtige Skalierung funktioniert es möglicherweise nicht einmal

+1

+1

+1

Derzeit muss ich solche Dinge deklarieren:

Selen-Chrom1:
...
Selen-Chrom2:
...

Es wäre nett:
Selen-Chrom:
Maßstab: 2

+1

genau das, was @caioquirino gesagt hat. +1

docker-compose up sollte eine Arbeitsumgebung schaffen, ohne dass andere Arbeiten erforderlich sind. Die einzige Möglichkeit, Dienste aufzurufen , die mehrere Knoten erfordern, besteht darin, das Muster zu verwenden, das

Scale in der yml-Datei behebt dies.

Big +1, ich möchte dies auch verwenden, um Dienste zu definieren, deren Skalierung anfänglich auf 0 festgelegt ist.

Nach dem Vorbild...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

Die Idee ist, dass Sie dieselbe docker-compose.yml verwenden und nahtlos von einer Entwicklungsumgebung in die Produktion übergehen können. Die consul_master-Instanzen würden sich automatisch dem Raft anschließen und ein Quorum herstellen, indem sie docker-compose scale consul_master=3 tun. Das wäre ziemlich cool.

Um auf @dnephin zu antworten...

Nehmen Sie dieses Beispiel, das davon ausgeht, dass wir der Compose-Datei eine Skalierungskonfiguration hinzufügen:

1. Ich habe eine anfängliche Skala von 3 für eine Dienstleistung festgelegt
2. Ich führe docker-compose up -d aus, mein Dienst skaliert auf 3
3. Ich starte docker-compose scale service=4
4. Ich nehme einige Änderungen vor und stelle die Bereitstellung mit docker-compose up -d. wieder her. Was passiert? Wird es wieder auf 3 herunterskaliert? Ignoriert es die Skalierung jetzt vollständig?
5. Liebe es
6. In Ordung
7. ich bin immer noch bei dir
8. Ich denke, es sollte zwischen einer vorhandenen Bereitstellung und einer neuen Bereitstellung unterschieden werden, damit die Skalierungskontinuität für vorhandene Bereitstellungen aufrechterhalten werden kann, die fortlaufend aktualisiert werden. Eine einzelne Bereitstellung würde die DOCKER_HOST-Umgebung usw. zusammen mit dem Maßstab jeder Komponente, Image-IDs und einem Verlauf der erneuten Bereitstellungen umfassen. Dies könnte ein guter Ort sein, um Upstack-Mechanismen wie Continuous Deployment oder Blue Green Deployments zu nutzen? Ich stelle mir einen etwas produktionsbereiteren Workflow vor, so dass Sie sich einfach mit einem anderen DOCKER_HOST verbinden und docker-compose up -d ausführen und dann Hooks bereitstellen können, damit Upstack-Tools Dinge wie CI und Blau/Grün-Rollouts verwalten können. Vielleicht etwas hinzufügen wie DOCKER_COMPOSE_ENV={"testing" || "Produktion" || "dev"}?

IMHO, mit "hardcodierten" scale , sagen wir zu 3, sollte es mit 3 Containern beginnen

Ich denke, ein Großteil der Verwirrung über einen "scale"-Parameter im Vergleich zum "scale"-Befehl würde durch die Benennung des YAML-Parameters "initial_scale" oder "default_scale" gemildert. Das macht ziemlich deutlich, dass es sich nur um einen Wert handelt, der verwendet wird, wenn es keine Überschreibung gibt. Es erscheint auch (zumindest IMHO) vernünftig, dass dieser Parameter "initial_scale" nur referenziert wird, wenn docker-compose den Dienst zum ersten Mal aufruft und nicht, wenn docker-compose erneut ausgeführt wird, während einige Instanzen des Dienstes bereits ausgeführt werden.

+1 für "initial_scale", auch wird dieser Parameter explizit als Compose-spezifisch beschrieben, da Docker selbst keinen solchen Parameter hat.

Es passiert eine interessante Sache, im Blog-Beitrag https://blog.docker.com/2016/02/video-containers-as-a-service-caas/ im Video "48.56 wird gezeigt, dass Sie auf dem neu veröffentlichten Docker-Rechenzentrum" Kann am Stack-Erstellungspunkt tatsächlich festlegen, wie viele Instanzen eines Containers Sie ausführen möchten. Diese Idee ist also nicht neu für das Docker-Team, ich hoffe, sie wird in die nächsten Compose-Releases aufgenommen

+1

+1

Millionen von Problemen und Anfragen scale/initial_count und so weiter .. und immer noch nicht geplant.

Es ist traurig, ein ansonsten gutes Projekt zu sehen, aber die Leute finden nur Ausreden und schaffen neue und doppelte Probleme, schließen Probleme und "machen" Arbeit.

+1

+1

+1

+1

BITTE HÖR AUF!
NICHT +1 HINZUFÜGEN!
ABONNIEREN SIE DIE AUSGABE EINFACH!

+1 ( @pierrre tut

+1 ist sehr wichtig ( @pierrre , sorry)

Ich stimme zu, möchte aber keine 100000 Benachrichtigungen für Ihr "+1" erhalten!

/me forks Docker Compose und beginnt mit dem Erlernen der Codebasis.

Viele gültige Punkte oben, es sieht so aus, als ob ein default/inital scale Parameter in der Konfigurationsdatei + ein scale cli-Befehl beide adressiert. Um Anwendungsfälle zur Unterstützung einer anfänglichen Skalierungsoption hinzuzufügen, ziehen Sie geclusterte Dienste in Betracht, bei denen ein Quorum aus einer Anzahl von X Knoten besteht und die ansonsten nicht betriebsbereit sein sollten (z. B. nicht weniger als 3). Der Sinn von docker-compose besteht darin, einen vollständig enthaltenen Deskriptor eines solchen Systems zu haben.

Mein Anwendungsfall ist:

Ich habe einen Dienst mit einigen allgemeinen Einstellungen erweitert, um weniger Duplizierung zu ermöglichen. Der Basisdienst wird jedoch erstellt (bei Ausführung ohne explizite Angabe von Dienstnamen) und dann manuell heruntergefahren. Ich möchte, dass der Basisdienst eine anfängliche Skala von 0 hat.

Ich bin allgemein einverstanden. Meiner Meinung nach laufen dieses Problem und die damit verbundenen/verwandten Probleme jedoch auf ein etwas anderes Problem hinaus: up und scale wollen letztendlich derselbe Befehl sein.

Sie sind manchmal schon:

• docker-compose up service
• docker-compose scale service=1 .

Und wenn scale alle CLI-Optionen (zB --force-recreate ) offenlegen würde, die up tut, oder wenn up über das Zählen Bescheid wüsste, dann wären sie es im Grunde.

Wenn, wie in dieser Ausgabe vorgeschlagen, der docker-compose.yml -Anweisung eine "initial scale"-Anweisung hinzugefügt wird, dann muss up das Zählen lernen. An welchem ​​Punkt sollte up einfach die Zählsyntax docker-compose up service=10 (die jede im Yaml definierte Skala überschreiben könnte)?

Es wird zwischen "Anfangsmaßstab" und "Skala" unterschieden, die die Domäne verschiedener Befehle sein können. Aber da up idempotent ist und wiederholt ausgeführt werden kann, ohne dass der Zustand notwendigerweise geändert wird, denke ich, dass diese Unterscheidung nicht streng ist. Ich denke, wir sollten stattdessen in Betracht ziehen, up scale direkt ausschlachten zu lassen.

@mattgiles Ich stimme zu, da war ich mit #2496, aber ich hatte nicht daran service=count zu up hinzugefügt werden könnte. Ich denke, das könnte die Situation bewältigen. Das einzige Problem, das ich sehe, ist, dass derzeit up web bedeutet, dass nur der Webdienst und seine Abhängigkeiten aufgerufen werden. Der Versuch, up web=3 müsste weiterhin dasselbe bedeuten. Das bedeutet, dass es keine Möglichkeit gibt, alles up überschreiben und die Skalenzahl auf einmal zu überschreiben, aber das ist wahrscheinlich in Ordnung.

Ich werde den Vorschlag in #2496 aktualisieren

@dnephin Ich habe den neueren Vorschlag verpasst. Fantastisch!

FWIW, ich denke , dass es für völlig intuitiv docker-compose up web=3 bringen drei Container für den „Web“ Service, sowie alle Abhängigkeiten ... in den Verhältnissen in der yaml definiert (je so etwas wie ein scale Anweisung). Auf diese Weise wird die Compose-Datei weiterhin verwaltet, sofern sie nicht von der Befehlszeile überschrieben wird.

Nachfolgende Aufrufe von up könnten wie bisher bestehende Container in Ruhe lassen. Nur wenn die aktuelle Skala kleiner als die in der Yaml definierte ist, wird die Anzahl geändert, damit sie mit der vorgeschriebenen Skala übereinstimmt. Keine definierte Skala würde weiterhin eine Skala von 1 implizieren.

Dinge wie --force-recreate sollten wahrscheinlich auch Zähler in Ruhe lassen, wenn sie höher sind als in der yaml definiert, aber trotzdem alle Container neu erstellen, um mit anderen Attributen in Einklang zu sein.

Wäre für mich auch sinnvoll, Container töten zu können, wie man es derzeit mit scale , indem man so etwas wie docker-compose up web=2 usw. aufruft.

+1

+1 (nur um @pierrre zu ärgern ;) )

+1

+1 für Maßstab=x.

In diesem Zusammenhang würde ich gerne Singletons beschreiben. scale=1

Irgendein Erfolg hier mit der Skalierungsoption

+1

Ich habe dazu nichts Neues von Upstream gesehen, persönlich hatte ich keine Chance zu sehen, ob ich einen Patch dafür hacken kann.

Vielen Dank,
Jason Mills

• vom Handy geschickt.

Am 8. August 2016 um 17:19 Uhr schrieb lavvy [email protected] :

Irgendein Erfolg hier mit der Skalierungsoption

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

+1

+1

+1

+1

+1 (um @pierrre wieder zu ärgern)

+1

Ich möchte den Fall wiederholen

Skala=0
Nützlich für Test, Debug. probe usw. Dienste, die Sie normalerweise nicht aufrufen, aber definiert haben möchten - da sie normalerweise im Kontext der anderen Dienste in der Datei verwendet werden.

Maßstab=1
Denn ich will ein und nur eins davon – _ever_. In einem MariaDB-Cluster kann es vorkommen, dass ich immer nur einen einzelnen Knoten mit einer bestimmten Speicher-Engine (z. B. Spider, ColumnStore usw.) konfigurieren möchte.

Skala=n
Weil es Zeiten gibt, in denen ich weiß, dass ich 'n' Dienste brauche, zum Beispiel ein MariaDB-Cluster, in dem ich immer eine primäre (mit ihrer Konfiguration) und zwei sekundäre (mit ihrer unterschiedlichen Konfiguration) habe.

Macht für mich vollkommen Sinn @alvinr. Der Standardwert sollte wahrscheinlich 1 sein.

HAFTUNGSAUSSCHLUSS: Ich bin kein Vertreter von Marathon oder Mesosphere

Dies ist ein weiteres Beispiel für eine ziemlich einfache Funktionsanfrage, die vom Docker-Support-Team seit über einem Jahr aufgegeben / verschoben wurde. https://github.com/docker/docker/pull/12749 ist ein weiteres Beispiel. Kubernetes und Marathon haben diese Optionen schon seit längerem ("instances": 3 in der Datei marathon.json) und implementieren sogar Autoscaling. Es ist die Unwilligkeit der Docker Support Group, die mich schon seit einiger Zeit vom Docker Data Center & Swarm weggedrängt hat.

Kontena hat dies auch als instances: 3 (https://www.kontena.io/docs/references/kontena-yml)

Eine andere Möglichkeit, dies zu tun, besteht darin, einen Abschnitt scale in der Version 2 der Compose-Datei hinzuzufügen.

Es würde sich nicht mit den Docker-only-Optionen vermischen, die in Diensten verwendet werden.

Ein Beispiel wäre:

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2    

Dies mit der Möglichkeit, scale: 0 anzugeben, würde möglicherweise zwei Fliegen mit einer Klappe schlagen, die andere wäre https://github.com/docker/compose/issues/1896

Dies scheint ein Kinderspiel zu sein.

Ich möchte nginx+nodejs+mongodb mit 3 oder 4 nodejs-Instanzen bereitstellen. Jedes Mal wenn ich die App starte.

Wenn Sie eine Befehlszeilenoption dafür haben, warum nicht in der yml-Datei?

docker-compose up scale nodejs=4

Würdest du.

Es ist einfach. Sie wollen den Weg gehen "jemand anders baut es und wir"
werden versuchen, es zu unterstützen". Außer dem Basis-Docker haben sie keine erstellt
irgendetwas. Compose war ein anderes Produkt, das sie konsumiert haben und jetzt haben sie es
keine Ahnung wie man es unterstützt/erweitert, deshalb Produkte wie marathon und
Kubernetes sind beliebter als Schwarm.

Am 16. Oktober 2016, 21:36 Uhr, "Michael Schwartz" [email protected]
schrieb:

Dies scheint ein Kinderspiel zu sein.

Ich möchte nginx+nodejs+mongodb mit 3 oder 4 nodejs-Instanzen bereitstellen. Jeden
wenn ich die App starte.

Wenn Sie eine Befehlszeilenoption dafür haben, warum nicht in der yml-Datei?

docker-compose up scale nodejs=4

Würdest du.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/compose/issues/1661#issuecomment -254093296,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AES98nZt1uIejnIU9iajVt54QbzdlVK1ks5q0tETgaJpZM4FS8ZQ
.

Ich bin ehrlich gesagt ein wenig erstaunt, dass es _irgendwelche_ Rückschläge gibt, da es so offensichtlich scheint,...

@westlakem Hoffen

Es wäre schön, einen kompletten Stack auf seine funktionale Größe auf einmal zu bringen. In unserem aktuellen Anwendungsfall muss der Service-Stack "workers=16" haben, um ordnungsgemäß zu funktionieren.

Das ist einfach schrecklich:

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

was eindeutig durch etwas ersetzt werden könnte wie:

docker-compose up --abort-on-container-exit --scale workers=16

Bearbeiten: Ich sehe, dass "Rancher" eine docker-compose-ähnliche Syntax hat und einen anfänglichen Skalierungsparameter unterstützt: https://paypertrail.com/blog/tech/docker-rancher-and-laravel-easy-and-safe-scalability

Eine Problemumgehung besteht darin, YAML-Anker- und Zusammenführungsfunktionen zu verwenden und den Dienst in der docker-compose-Datei zu duplizieren.

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

etc ...

Das wäre super praktisch!

Das ist super komisch das gibt es nicht...

Am Ende muss ich möglicherweise doppelte Dienste erstellen, weil ich so faul bin.

Dies ist bereits an der Arbeit an der Composer-Datei v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json , die auf docker-compose v1. 10.0-rc1

Ihre "Services" -Angebote haben den Parameter eingebaut. Sehr traurig, dass als
Abonnent dieser Ausgabe hat uns niemand aus dem Entwicklungsteam darüber informiert
es kam im Service-Produkt, und jemand musste die RC-Notizen lesen
für 1.10 für jeden Einblick. Wo sind die Docker-Vertreter?

Am Freitag, 6. Januar 2017 um 6:30 Uhr, Yasmany Cubela Medina <
[email protected]> schrieb:

Dies ist bereits bei der Arbeit an der Komponistendatei v3 https://github.com/aanand/
compose-file/blob/master/schema/data/config_schema_v3.0.json, die sein wird
und wird bereits von docker-compose v1.10.0-rc1 unterstützt

—
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/1661#issuecomment-270886347 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AES98nOAW-h0BVaR8D9uQfLpMCQRfdyfks5rPiXEgaJpZM4FS8ZQ
.

+1

+1

Hallo, ich habe eine ähnliche Frage.
Ich habe mich jemals gefragt, dass docker-compose up sich an die Skala erinnern kann, die ich jemals eingestellt habe.

Zum Beispiel führe ich docker-compose scale nodejs_web=4 dann docker-compose down ,
dann starte ich wieder docker-compose up , es werden 4 nodejs_web gestartet.

Ich möchte wissen, wo der Befehl scale die Zahl 4 speichert?

Die docker-compose.yml kann sein:

version: '2'
services:
  nodejs_web:
    image: node
    command: node

Ich unterstütze @dnephin Vorschlag auf #2496
Bitte geben Sie uns diese grundlegende Funktion.

Dienste in der neuen Version von Docker bieten eine "Replikate"-Funktion.

Am Montag, 20. März 2017 um 15:28 Uhr, alwaysastudent [email protected]
schrieb:

Ich unterstütze @dnephin https://github.com/dnephin Vorschlag auf #2496
https://github.com/docker/compose/issues/2496
Bitte geben Sie uns diese grundlegende Funktion.

—
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/1661#issuecomment-287870998 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AES98uWGEnbyCFyxNSSlv7QkXy5oBek1ks5rntNBgaJpZM4FS8ZQ
.

@westlakem - diese Funktion ist für Schwarm. Es ist nicht für die Skalierung des regulären Dienstes.

So viele Vorteile, wenige Nachteile. Was hat es mit diesem Problem auf sich?

Es gibt einen neueren Vorschlag zum vollständigen Entfernen des Skalierungsbefehls in https://github.com/docker/compose/issues/2496

Ich verstehe wirklich nicht, warum oder warum es keine Option initial_scale: 3 in der Datei zum Verfassen gibt (ich verstehe, warum es nicht nur scale: 3 )

Bereits in 1.13.0 implementiert. Vielen Dank an alle für Ihr Feedback und Ihre Geduld.

@shin- Warum gilt dies als geschlossen? Bei der Verwaltung großer Apps, bei denen ALLES automatisiert und in der Versionskontrolle ist, muss ich jetzt mein Ansible ändern, das Docker ausführt, um zu definieren, wie viele Instanzen eines Dienstes ausgeführt werden.

Ansible sollte alles einrichten, damit Docker ausgeführt werden kann. Docker sollte definieren, wie viele Instanzen eines Dienstes die App benötigt. Jetzt liegt es in der Verantwortung von Docker, das Inventar der Dienste zu kennen, aber Ansibles Verantwortung, Docker anzurufen, damit es weiß, wie viele Container hochgefahren werden müssen?

@greenscar Entschuldigung, ich bin mir nicht ganz sicher, was das Problem ist - sind Sie mit der Implementierung der Funktion unzufrieden? Wenn ja, wie können wir es verbessern?

Warum ist dies in Version 3 nicht vorhanden? Äußerst verwirrend, da "deploy.replicas" und "up" nicht gleichbedeutend sind, könnte man sagen, dass diese Funktion in v3 fehlt.

@cgarciae deploy.replicas dient dem gleichen Zweck wie scale . Warum sind sie aus Ihrer Sicht nicht gleichwertig?

@shin- Wenn ich keinen Schwarm erstellen und nur docker-compose up -d möchte, sagt mir Docker Compose, dass die "Bereitstellungseinstellungen" ignoriert werden.

@cgarciae Warum verwenden Sie eine v3-Datei, wenn Sie keinen Schwarm erstellen möchten?

Ich denke, jeder, der Docker verwendet, erwartet, dass der Skalierungsparameter entweder für Docker-2- oder Docker-3-Dateien funktioniert. Es gibt keinen Grund, dies nicht zu tun, und es könnte sogar den Standardwert für deploy.replicas festlegen. Wenn deploy.replicas gesetzt ist, überschreibt es daher die Skalierung im Schwarm. Was ist falsch an diesem Bild, abgesehen davon, dass es das ist, was jeder erwartet (und wenn es Ihnen nicht gefällt, müssen Sie es natürlich nicht in Ihrer docker-compose.yml verwenden)?

Der fehlende Skalierungsparameter hat dazu geführt, dass ein Dienst fehlgeschlagen ist, da ich vergessen habe, ihn seit der letzten Neubereitstellung wie zuvor zu skalieren -.- Warum ist dies keine Sache, die Service und vielleicht sogar Leben retten würde, je nachdem, was es läuft?

Habe auch gerade dieses Thema angesprochen. Scheint es keine Möglichkeit zu geben, anzugeben, wie viele Dienste innerhalb der Docker-Compose-Konfiguration gestartet werden sollen? Noch verwirrender ist, dass die docker-compose-Dokumentation eine Menge Dokumentation für Dinge enthält, die mit docker-compose nicht funktionieren...

Oh warte, wenn ich also meine Docker-Compose-Konfiguration auf version: "2.2" ändere, kann ich scale: 2 aber wenn man zu einer späteren Version wechseln möchte, gibt es keine Option mehr dafür?

Ok, ich sehe dieses Problem von "Version" nicht wirklich, was bedeutet, dass Versionen bereits angesprochen wurden, https://github.com/docker/compose/issues/4693

Ich verwende v3.6, weil ich einige Konfigurationen benötige, die in 2.2 nicht vorhanden sind. Für die lokale Entwicklung verwende ich keinen Swarm, aber ich möchte scale=0 auf einige Container in meiner docker-compose.overrides.yml setzen. Weil einige von ihnen nur für Buildprozesse wie der Frontendbuild-Container gedacht sind. Dieser Container teilt sich einige Volumes mit anderen laufenden Containern, sollte aber nicht zusammen mit diesen anderen Containern auf docker-compose up gestartet werden. Der buildcontainer wird also einfach mit dem Befehl run ausgeführt. Ja, ich kann den Parameter --scale beim Aufrufen von docker-compose einstellen, aber ich denke, es ist besser, ihn direkt in die Konfiguration zu schreiben. :)

Danke für den Skalierungsparameter. Ich konnte es in einem Nicht-Produktions- docker-compose.yml sodass jeder eine HA-Konfiguration von Consul und Vault verwenden konnte. Der Skalierungsparameter machte die Bereitstellung einer lokalen HA-Konfiguration einfach. https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

In diesem Fall nur dafür gedacht, Consul und Vault in einer HA-Konfiguration auszuprobieren und Consul DNS zu verwenden.

Welche Version von Docker Compose läuft auf dir? Seit v3 wurde diese Funktion fallengelassen (mit Drop meine ich nie implementiert), also wird sie ignoriert. Siehe https://docs.docker.com/compose/reference/scale/

Ich verwende das v3-Format aufgrund fehlender Funktionen nie. Ich tendiere dazu, das niedrigste 2.1- oder 2.2-Format zu verwenden, je nachdem, welche Funktionen ich verwende.

Bearbeiten: Um nicht zu sagen, dass ich das v3-Format vermeide. Nur wenn ich eine Compose-Datei schreibe, fehlt normalerweise das, was ich verwenden möchte.

Ok, ich dachte du sprichst von Docker Compose mit Swarm Stack, deshalb. Ich habe es nie versucht, aber es ist seltsam, über HA mit Docker Compose ohne Orchestrator und Multi-Node zu sprechen. Ist es für "poc" oder zu Testzwecken? Jedenfalls habe ich es in diesem Zusammenhang nie versucht

In diesem Fall bezieht sich der HA einfach auf einen Konsul-Cluster und einen Tresor-Cluster. Es soll als Proof of Concept dienen, das zum Experimentieren und zur Vereinfachung des Bootstraps zur Verfügung steht. Der HA bezieht sich nicht auf Docker-HA oder sogar auf Multi-Maschinen-HA. Es ist nur insofern HA, als die experimentierende Person einen der Cluster-Container töten und sehen kann, dass der Konsul und/oder der Tresordienst nicht betroffen sind.