Compose: Definieren Sie Dienste, die nicht standardmäßig gestartet werden

+1 für Option 1

Ich denke, dass das Hinzufügen von Diensten, die nicht Teil einer Komposition sind, sondern zufällig verknüpft / angehängt werden müssen, eine schlechte Designentscheidung ist. Es gibt einige andere Anwendungsfälle, die durch Zulassen einer Form von Includes-Syntax gelöst werden könnten. Es ist immer schön, mehrere Probleme mit einer einzigen Funktion zu lösen.

Einige dieser Probleme (diejenigen, die sich mit Nur-Daten-Containern befassen, # 942, der letzte Kommentar von @ cpuguy83) sind bereits durch # 1754 behoben. Ich denke, wir müssen sie nicht mehr als Problem betrachten (nach 1.5 ).

Wir entwickeln Magento-Erweiterungen. Dazu benötigen wir eine einfache Möglichkeit, einen Webstore auf einem LAMP-Stack auszuführen. Komponieren macht das einfach. Wir möchten aber auch phpunit, verschiedene statische Analysetools, Dokumentationsersteller usw. ausführen. Tatsächlich besteht die überwiegende Mehrheit unserer "Dienste" nur aus Befehlen wie docker-compose run --rm phplint . Idealerweise mag ein unqualifizierter Befehl

docker-compose up -d

würde nur einen lang laufenden Dienst starten (sozusagen die eigentlichen Dienste) und nicht unnötig andere Effekte wie phpunit auslösen. (Es ist auch wichtig, dass keine Fehlfunktionen ausgelöst werden, z. B. das Ausführen von Selenium-Tests, bevor der Webdienst verfügbar ist.)

Alles, was wir wirklich versuchen, ist, den Entwicklern den Schmerz des Umgebungsmanagements zu nehmen und keine Produktionsdienste auszuführen. Ich weiß nicht, ob der Kommentar von @dnephin repräsentativ für die Richtung ist, in die Compose geht oder nicht, aber es scheint mir zweideutig, ob Compose noch plant, der Nische zu dienen, in der Fig angefangen hat. (Weil, um klar zu sein, ich denke, Option 1 unterstützt nicht die Benutzerfreundlichkeit, die Entwickler benötigen, um dies wie in Abb. 1 beabsichtigt zu verwenden.) Ich verstehe vollkommen, wenn Compose nicht mehrere Verantwortlichkeiten haben möchte, aber ich hoffe, dass jemand uns dies klar mitteilen kann. Wenn diejenigen von uns, die dieses Produkt für schnelle, isolierte Entwicklungsumgebungen verwenden, in eine andere Richtung gehen sollten.

@kojiromike , worum geht es bei (1), das für Ihren Anwendungsfall ungeeignet ist? Geht es nur um die Befehlssemantik ( docker-compose run --rm phplint vs. docker-compose --file phplint.yml up )?

Es ist so, dass docker-compose up -d versucht, phplint zu starten, und docker-compose ps meldet, dass der phplint-Dienst nicht verfügbar ist. In Wirklichkeit ist das kein Service-Container, sondern ein Werkzeug-Container. Es sollte kein Konzept von Auf / Ab geben. Nach meinem Verständnis werden Werkzeugcontainer von Docker angenommen (so würden Sie so etwas wie Redis-Cli ausführen, eindeutig kein "Service"), und obwohl ich sie in der Entwicklung häufiger verwende, denke ich, dass sie auch einen Platz für die Produktion haben. Zum Beispiel, warum awk auf Produktionsmaschinen oder in Containern installiert ist. Warum nicht einen Container mit Verknüpfung durchlaufen, um ein vorhersehbares Verhalten zu erzielen?

: +1: Ich möchte routinemäßig zusammen mit meinen anderen Diensten einen tests -Container erstellen, um laufende Komponententests zu kapseln. Meine "Problemumgehung" besteht darin, den Befehl auf "/ bin / true" zu setzen und den Container mit dem in der CLI angegebenen Unit-Test-Befehl auszuführen. Es wäre großartig, angeben zu können, welche Container bei up sollen!

(Übrigens, gute Arbeit, Leute)

cc @jameydeorio

@ryneeverett Die Semantik ist ein Teil davon. Es ist ein Problem der Selbstdokumentation und Auffindbarkeit. Derzeit teilen wir Entwicklern docker-compose run --rm foo bar . Wir laden sie ein, eine Shell-Funktion oder einen Alias ​​zu erstellen, pflegen jedoch keinen Standard-Alias ​​/ eine Standard-Datei für Projekte. (Wir möchten keine Dinge außerhalb von Containern standardisieren. Wir möchten Docker _to_ standardize verwenden.) Durch Hinzufügen einer neuen Datei für einige Befehle wird eine wichtige Hierarchie erstellt: Die Datei docker-compose.yml wird zur "Standard" -Datei für wichtige Dinge, und die "andere" Datei wird weniger wichtig.

Die andere Sache ist, dass die Aufrechterhaltung der Beziehungen zwischen Diensten schwieriger wird. Nur weil wir möchten, dass etwas nicht standardmäßig ausgeführt wird, heißt das nicht, dass kein link oder volume von einem Dienst verwendet wird, der lange läuft. extends bietet nicht alle Funktionen, die wir benötigen, um Dienste mit "Befehlen" (einmaligen Diensten) zu verknüpfen. Selbst wenn dies der Fall wäre und wir mehrere Yaml-Dateien verwenden müssten, müssten wir extends wo wir es sonst nicht brauchen würden.

extensions bietet nicht alle Funktionen, die wir benötigen, um Dienste mit "Befehlen" (One-Run-Diensten) zu verknüpfen. Selbst wenn dies der Fall wäre, wenn wir mehrere Yaml-Dateien verwenden müssen, müssen wir Erweiterungen verwenden, wo wir dies sonst nicht benötigen würden.

@kojiromike Das habe ich vermutet. Ich frage mich, ob Sie mit einer verbesserten Unterstützung von extends + einer Möglichkeit zur Ausführung von Unterbefehlen (die funktional mit extends identisch wären) innerhalb eines einzelnen docker-compose.yml zufrieden wären. Aber vielleicht ist letzteres dasselbe wie (4).

2) Fügen Sie den Diensten eine Option hinzu, damit sie nicht standardmäßig gestartet werden

Ich stimme für Option 2. zB so etwas wie eine start: false Direktive. Die Vorteile sind, dass wir nicht mehrere compose.yml-Dateien oder zusätzliche Konfigurationsdateien benötigen. Sie können nur eine compose.yml lesen, um das Gefühl für den gesamten App-Stack zu bekommen.

Ich denke, unsere vorgeschlagene Lösung für https://github.com/docker/compose/issues/1987#issuecomment -139632238 wird dies bewältigen. "admin" -Dienste können in einer separaten Konfiguration definiert und mit -f hinzugefügt werden, wenn ein admin-Befehl für eine Komposition ausgeführt werden muss.

@dnephin Die Lösung in # 1987 (Kommentar) behandelt "Admin-Dienste", aber nicht "nur Datencontainer", oder? Sie müssten weiterhin die Problemumgehung command: /bin/true .

Sie sollten keine Nur-Daten-Container mit Compose benötigen, da Compose das Austauschen der Volumes in neu erstellte Container für Sie übernimmt.

@ cpuguy83 Im folgenden Beispiel ist der

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

Ich stimme jedoch zu, dass dies ein Eckfall ist und das Hinzufügen zusätzlicher Syntax sich wahrscheinlich nicht lohnt. Ich sage nur, dass die vorgeschlagene Lösung diesen Fall nicht behandelt.

Richtig, für Datenvolumes ist noch ein Befehl erforderlich, sodass Sie ein minimales Image verwenden müssen, um diesen Befehl zu unterstützen.

Ich bin mit der neuen Volume-API, die herauskommt, nicht ganz auf dem neuesten Stand, aber ich hoffe, dass wir einen Abschnitt volumes: hinzufügen können, um das Datenvolumen besser zu handhaben (anstatt einen Container für sie zu benötigen).

Dies macht es nicht unbedingt zur richtigen Wahl, aber ich denke, Lernkurve / Leichtigkeit des Verständnisses sollten berücksichtigt werden.

Ich denke, (2) ist am einfachsten zu verstehen. Ich habe keine Möglichkeit, dies zu bestätigen, aber mein Bauch sagt, dass die meisten Leute, die nicht mit allen Optionen von docker-compose vertraut sind, die auf das Problem stoßen, das wir hier zu lösen versuchen, sagen: "Ich wünschte, es gäbe eine Möglichkeit, diesen Container nicht zum Starten zu bringen, wenn ich docker-compose up laufen lasse", und sie sehen start: false und bam, wir sind fertig und glücklich.

Sie sagen nicht: "Wenn es nur eine Möglichkeit gäbe, eine zweite Datei mit einer umständlichen Verknüpfungsgeschichte zu erstellen, um dieses Problem zu lösen ..." (obwohl mir klar ist, dass https://github.com/docker/compose/issues/ 1987 # issuecomment-139632238 hilft bei der "unangenehmen Verknüpfungsgeschichte", ya?).

(4) war etwas vage, aber ein spezieller Weg für den Weg für Skripte und Unikate wie dieses passt zu dieser "sinnvollen" Rechnung.

Heute habe ich genau nach (2) gesucht, aber am Ende meine am wenigsten bevorzugte Lösung gefunden, eine zweite YML-Datei. Mein Anwendungsfall:

Ich habe ein paar Container und alle sind mit demselben mongo Container verknüpft. Ich möchte mir und dem Team die Möglichkeit bieten, Fixtures in die Mongo-Datenbank zu laden, und ich dachte, der einfachste Weg, dies zu tun, besteht darin, den mongo -Container unter einem anderen Namen fixtures zu laden selbst Link zu Mongo und dann mongorestore --host mongo --port 27017 --drop /dump ausführen. Da wir die Fixtures nicht zu jeder Zeit laden möchten, fühlte es sich natürlich an, sie mit einem start: false aber am Ende gab es eine separate YML-Datei für beide Container fixtures und mongo .

Funktioniert gut, aber start: false ist IMO viel sauberer. Wenn ich 10 oder mehr Permutationen dieses sogenannten Fixtures-Containers hätte, wäre ja start: false eine schlechte Idee und ich würde mit (1) .

Ich musste nur eine Erstellungsdatei erstellen, in der einige Dienste nicht mit dem Befehl docker-compose up -d ausgeführt werden sollten. Für mich wäre Option (2) die beste Lösung für mein Problem.

Ich bin auch darauf gestoßen. Ich bin mir nicht sicher, welche Lösung meiner Meinung nach die beste ist, aber für mich kommt es darauf an, dass ich die Fähigkeit brauche, Bilder zu erstellen, die als Teil einer Komposition verwendet werden. Sie sind für kurzlebige Container gedacht, aber das Image muss einsatzbereit sein, damit ich den Container bei Bedarf ausführen kann.

Hallo! gleiche Ausgabe hier, froh, dass es eine schöne Gruppierungsfrage gibt, tolle Arbeit!

In meinem Fall habe ich einen Python-Stack, der mit einigen Containern mit Diensten arbeitet. Alles funktioniert gut, aber ich habe gerade einen Koffer aus dem Stapel gefunden. Ich verwalte statische Abhängigkeiten mit bower und möchte den Befehl bower in einem Container ausführen. Es ist nur ein Skript, das wir gelegentlich ausführen.

Es wäre großartig, dieses Skript innerhalb der Kompositionsstruktur auszuführen, die wir haben. Ich bilde so etwas wie:
Docker-Compose Run Node Bower installieren

Also ich mag die 2. von 4. Option. Benötigen Sie nur den Dienst, um nicht zu starten, es wird nicht benötigt: P.

Wenn es einen Konsens gibt, könnte ich versuchen, eine Pull-Req für so etwas wie "Neustart" zu senden.
Start: immer
vielleicht ... keine Ahnung.

Eine weitere Abstimmung für Option 2.

Ich würde auch Option 2 bevorzugen. Die neuen Docker-Datencontainer können in einer Docker-Compose-Datei angegeben werden, müssen jedoch nicht ausgeführt werden, um verwendet zu werden.

Option 2 auch für mich

Option 2 wäre toll.

+1 für Option 2

+1 für Option 2. Das Verwalten mehrerer Dateien und das Eingeben ihrer Namen ist nur Zeitverschwendung. Eine einzige boolesche Flagge würde sie alle regieren. :Biere:

+1 für opt 4,
Wenn ich einen zweiten Favoriten auswählen muss, ist es opt 2.

Es stimmt, dass die besten Optionen 2,4 sind, wenn ich beide +1 kann, dann ist es das, was ich tue, wenn ich nicht mit der Mehrheit gehe und für 2 stimme.

Abstimmung für 2

beide 2 und 4 sind schön zu haben.
+1 für 2

Ich denke nicht, dass es notwendig ist, ein neues Konzept für Aufgaben einzuführen. Diese lesen sich meiner Meinung nach sehr gut und sind ohne viele Änderungen möglich:

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

Die aktuelle "Lösung" mit der separaten Compose-Datei ist meiner Meinung nach keine wirkliche Lösung. Wie @xaka sagte, möchte niemand all dies

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

Am Ende erhalten Sie ein ./run-task -Skript, das die gesamte Boilerplate vor myTask für Sie hinzufügt. Jetzt haben Sie Ihrer Multi-Container-App einen weiteren Einstiegspunkt und eine weitere Schnittstelle hinzugefügt. Entwickler sehen docker-compose.yml und denken: _ "Oh, großartig, eine Compose-App. Ich weiß, wie man mit dieser Sache umgeht!" _ Und jetzt müssen Sie ihnen sagen: _ "Richtig, Sie können es mit docker-compose wie jede andere Compose-App ... oh, aber warte ... es gibt auch dieses zusätzliche Skript, das du kennen musst ... "_

start: false / up: false / some-additional-flag-to-a-service: false ist wahrscheinlich am einfachsten zu implementieren, aber höchstwahrscheinlich auch am klarsten und am einfachsten zu verstehen. Und es würde die Benutzerfreundlichkeit so sehr verbessern.

was @sherter gesagt hat. :Pfeil nach oben:

: +1: dafür. Eine separate Docker-Datei ist ein großer Schmerz, insbesondere wenn Netzwerke beteiligt sind

Der start: true|false -Ansatz ist zu begrenzt. Was ist, wenn einige Dienste zum Testen verwendet werden, andere für den Administrator und der Rest für den normalen Betrieb?

Ich würde es vorziehen, den Begriff der Gruppierung zu Diensten hinzuzufügen.

    myservice:
       group: `admin`

Wenn das Attribut group nicht definiert ist, wird default angenommen.
Auf diese Weise können wir die Standard- und Verwaltungsdienste mit docker-compose up -g admin -d starten.

Besser noch, machen Sie groups einem Array.

Das Erstellen von Gruppenklassen von Diensten scheint eine leistungsstarke Funktion zu sein, wirkt sich jedoch auch tangential auf dieses Problem aus.

In Docker-Compose Version 2 wird jeder Container innerhalb des Top-Level-Elements services: deklariert.
Das Deklarieren eines Dienstes mit start: never zum Ausführen eines Skripts klingt falsch.
Sollten wir angesichts des neuen Formats nicht zusätzlich zu _services_, _volumes_ und _networks_ ein zusätzliches Element der obersten Ebene deklarieren?

Mein Vorschlag:

• Fügen Sie v2 ein neues Element der höchsten Ebene scripts: , transients: (oder einen besseren Namen) hinzu.
• Innerhalb von Transienten können Sie einen Container wie bei jedem Dienst definieren
• Der einzige Unterschied besteht darin, dass sie nicht standardmäßig starten, da sie nur für den vorübergehenden Gebrauch bestimmt sind.

Beispiel:

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

Und dann könntest du rennen:

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

Sorgen:

• Es klingt überlastet, ein weiteres Element der obersten Ebene nur für diesen Zweck der Startverwaltung zu erstellen, aber es wird durch die Tatsache abgeleitet, dass das neue Format das Verhalten in der obersten Ebene deklariert.
• Ich versuche mir zusätzliche Flexibilität (und Probleme) vorzustellen, die dies hinzufügen könnte.

Schließlich klingt das _groups-Feature_ gut, aber wenn Sie so viele Gruppierungen haben, sehe ich kein Problem beim Erstellen von Docker-Compose-Dateien für jede einzelne von ihnen. Wahrscheinlich ist die gewünschte Funktion die Vererbung von Docker-Compose-Dateien . Das wäre großartig!

PD: @bfirsh Vielleicht, wenn Ihnen die Idee gefällt, können Sie sie zu den "Möglichen Vorschlägen" hinzufügen.

Auf der zweiten Seite ist dies jedoch eine Überarbeitung des vierten Vorschlags aufgrund des bevorstehenden neuen Formats, in dem Dienste deklariert werden.

Abstimmung für Option 2: Am klarsten, am einfachsten zu lesen und ohne neue Konzepte lernen zu müssen
Ich möchte nur einen Dienst, der nicht standardmäßig gestartet wird

Was ist mit so etwas wie disabled: true ?

@ cpuguy83 Das scheint zu bedeuten, dass der gesamte Dienst deaktiviert ist, selbst für run . Ich würde es verwirrend finden.

@qcho hmm, jetzt, wo ich mich seit 1.6 mit Docker @gittycat sprechen. In diesem Sinne mag ich den Ansatz von

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

Inzwischen in der Schale…

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

Ein solcher Ansatz wäre fantastisch und würde die Notwendigkeit dieses Tickets überflüssig machen, geht aber über seinen Rahmen hinaus.

@ Kojiromike Das glaube ich nicht. Auf diese Weise beziehen sich Init-Systeme auf Dienste, die nicht automatisch gestartet werden sollten.

Es ist auch einfach und jede "Verwirrung" kann mit Dokumentation behoben werden.
Ich finde es auch viel weniger verwirrend als diese Gruppierung, die völlig unabhängig vom Konzept eines Dienststarts ist.

@ cpuguy83 Ich denke, die Semantik von "Diensten" ist genau das, was an erster Stelle verwirrend ist. Ich bin damit einverstanden, dass die Gruppierungssache Scope Creep ist. In diesem Sinne bevorzuge ich den Ansatz von Option 4 / @qcho , bei dem "Dienste" klar von "Dingen, die keine Dienste sind" unterschieden werden.

Das ist der Punkt, warum sollte ich einen Container, der niemals einen Dienst ausführen wird, unter die Kategorie "Dienst ... deaktiviert" stellen. Klingt nach einem hässlichen Patch, den jemand gemacht hat, und ist nicht intuitiv.

Vielleicht hätte die "Version 2" des Formats dieses Problem berücksichtigen sollen. Zum Beispiel könnte eine andere Spezifikation sein

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

Ok, jetzt haben wir die richtigen Dienste mit Gruppendefinition. Ich kann eine Produktions- oder Entwicklungsdienstgruppe starten. Oder führen Sie einfach ein Skript im some_script_container aus. Da es in keinem Dienst definiert ist, wird niemand gestartet

@qcho Hängt von der Definition eines Dienstes ab, aber auf jeden Fall - ich würde etwas in Frage stellen, das nur gelegentlich ausgeführt werden sollte und das nur ein Mensch bestimmen kann, ob es ausgeführt werden soll oder nicht.

Nehmen wir also an, Compose übernimmt so etwas wie ein job -Objekt.

1. Jobs werden nur einmal ausgeführt
2. Jobs werden nach Dienstleistungen gestartet
3. Jobs werden voraussichtlich beendet
4. ???

Jetzt muss compose auch einen lokalen Status über den Job beibehalten, was derzeit überhaupt nicht der Fall ist.

Aus diesem Grund ist das Hinzufügen eines einfachen auto-up: false oder autorun: false die einfachste und am wenigsten gruselige (skopewise) Methode, um damit umzugehen.

@ cpuguy83 Ich denke, Sie erweitern das, was ich sage, um etwas Komplexeres. Ich habe nicht vor, Docker-Compose zu erstellen, um über einen Job oder Workflow Bescheid zu wissen. Dafür können externe Skripte erstellt werden. Ich beabsichtige, dass Docker-Compose den gesamten Stapel definiert, damit eine Anwendung ausgeführt werden kann.

Ich kann mir vorstellen, ein Skript zu erstellen und den Status beizubehalten, den Sie sagen. Sogar das Skript vor dem Start des Dienstes aufrufen, nicht erst danach. Was ich mir nicht vorstellen kann, ist, dass ich die Composer-Datei selbst analysiere, weil ich überprüfen muss, welche Volumes ich importieren muss oder welche Konfiguration ich in einem unbekannten Container daraus extrahieren muss, um ein Skript auszuführen, das für sie gilt. Ich denke, Docker-Compose sollte mir diesen Container geben. Das Skript auszuführen und den Status beizubehalten ist mein Problem.

Ich verstehe nicht, warum die Leute das immer wieder sagen

services:
  my-script-container:
    auto-up:false

Ist einfacher als:

scripts/containers/transients/you_name_it:
  my-script-container:

Es ist das gleiche Maß an Komplexität. Aber semantisch weniger hackig.

Um die Ideen zu einem Thread zu erhalten, verweisen Sie auf # 2803

Anwendungsfall: Sie haben ein Projekt mit vielen Komponenten und Benutzern, die ausgewählt und ausgewählt werden sollen, welche installiert werden sollen, aber er erstellt eine Datei, in der alle installiert werden.

Vorschlag: Wir fügen eine Option hinzu, die in die Datei docker-cmpose.overrider.yml eingefügt wird, um ein in docker.compose definiertes Bild auszuschließen

dh

ein Bild:
ausschließen: ja

Das Verhalten wäre, diesen Eintrag in der Datei docker-compose.yml zu ignorieren

Können Sie mir mitteilen, was das Team denkt? Ich wäre daran interessiert, die Änderung vorzunehmen.

Ich habe auch für # 2 gestimmt ... bin heute auf dieses Bedürfnis gestoßen.

Der Vorschlag von

+1 für 2. Ich habe eine Situation, in der ich ein Docker-Image als Teil von compose erstellen muss, es aber nicht als Dienst ausgeführt wird. Die anderen Dienste (in denen Docker-Socken montiert sind) führen von Zeit zu Zeit Container aus dem Image aus.

+1 für 2. Und +1 für "Auto-Up" oder "Auto-Run" als Wortlaut.

Und können die Fälle für Gruppen von Diensten (wie von @gittycat erläutert) nicht über Umgebungsvariablen wie "auto-up: $ {ADMIN}" behandelt werden?

Ich sehe auch reale Anwendungsfälle zum Markieren von Diensten in docker-compose.yml , die nicht automatisch mit einem einfachen docker-compose up gestartet werden, sondern nur explizit gestartet werden.

Lösung 1) ist jetzt ein möglicher Weg, aber meiner Meinung nach zu umständlich, da man eine oder mehrere yml-Dateien angeben muss, anstatt nur docker-compose up aufzurufen und die Dateien zu teilen oder sogar zu duplizieren.

Da ich wirklich gerne so etwas wie Lösung 2) sehen würde (wie viele andere auch), habe ich in # 3047 einen Proof-of-Concept implementiert, damit Sie ein bisschen damit herumspielen können, um zu sehen, ob es realisierbar sein könnte Lösung.

+1 für Option 2

+1 für Option 2

+1 für Option 2

+1 für beide Optionen 2 und 4

+1 für die Optionen 2 und 4

+1 für Option 4. Einige Konfigurationen sollten für Skripte nicht zulässig sein (z. B. Neustart: immer).

mit Option 2 könnte es diesen seltsamen Fall haben:

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

was würde das bedeuten

@mathroc :

@niko oh richtig, ich sollte etwas länger darüber nachdenken, bevor ich etwas

Ändern meiner "Stimme" auf +1 für Option 2

+1 für Option 2, ich habe dies in mehreren Projekten benötigt.

ping @bfirsh @dnephin :
Könnten Sie ein Update zu diesem Problem geben? Da die meisten Kommentare hier für Option 2 sind, gibt es derzeit Pläne, so etwas (oder Option 3/4) umzusetzen?
Ich könnte meine Pull-Anfrage (Nr. 3047) aufpolieren und mit Tests und Dokumentation abschließen, wenn Sie sie dann zusammenführen möchten.

Vielen Dank.

+1 für Option 2

+1 für Option 2

+1 für Option 2

Ich denke, dass Option 1 funktionieren könnte, aber wir brauchen einen besseren Weg, um die Ausführlichkeit von:

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

Könnte vielleicht eine vereinfachte / erweiterte Flagge hinzufügen? docker-compose --augment tests up und automatisch auflösen, wenn es sich um eine Variation von docker-compose.yml - andernfalls müsste der Benutzer explizit sein.

Ich mag die Idee eines neuen Top-Level-Keywords wirklich, vielleicht suites und commands ?

Die folgende Konfiguration würde Folgendes ermöglichen:

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

Ich kann im Code sehen, dass es bereits den Begriff "einmalige" Dienste gibt (IMHO wird nur verwendet, wenn docker-compose run aufgerufen wird.
Könnte es wiederverwendet werden?
Wenn ich einen Container mit com.docker.compose.oneoff=True beschrifte, würde er versuchen, ihn zu starten?

Ansonsten stimme ich für Option 2.

Ich bin gerade darüber gestolpert, also hier meine zwei Anwendungsfälle:

1. "globale" Umgebungsvariablen: Der hier vorgeschlagene Ansatz besteht darin, extends , was mir recht ist ... aber jetzt muss ich ein image für das Ding definieren, von dem ich mich ausdehne und kann nicht einmal scratch (so endete https://hub.docker.com/r/tianon/true/).
2. "Skalierungs" -Dienste: Standardmäßig habe ich eine MongoDB-Instanz, aber für einige Tests möchte ich eine zweite inaktive definieren, die ich für diese Tests aufrufen kann. Hier scheint die Verwendung von extends in einer anderen Datei eine praktikable Idee zu sein (immer noch etwas über Docker / Docker-Compose und die damit verbundenen Best Practices zu lernen).

+1 für Option 2

+1 für Option 2

+1 für Option 2
Scheint eine einfache Änderung zu sein ...

+1 Option 2,

Im Anwendungsfall mehrerer Container, die einen gemeinsamen Satz von Envs und Konfigurationen gemeinsam nutzen, ist es sinnvoll, einen Basiscontainer zu erstellen, der den Container erweitert, aber niemals startet

auto-start:true|false

Da ich seit letztem September eine nette Lösung namens Rocker-Compose habe , würde ich run: _always_ | empfehlen _once_ | _noch nie_. Ich mag auch state: _running_ | _ran_ | _created_ auch.

Ich bin kein Fan davon, ein separates Projekt nur für diese Funktion zu verwenden. Am Ende habe ich den Befehl True asm code aus tianon / true project gestohlen, bis dies implementiert ist

Anfangs dachte ich auch, Option 2 wäre am besten, aber jetzt fange ich an zu denken, dass sie zu restriktiv wäre, und bald nach dem Hinzufügen würde ein Bedarf an einmaligen Aufgaben auftauchen. Tatsächlich arbeite ich gerade an einem Projekt, bei dem ich die folgenden Anwendungsfälle benötige:

• Innerhalb des Stacks möchte ich in der Lage sein, Container zu definieren, die bei der ersten Bereitstellung einmal ausgeführt werden, und zukünftige Läufe werden nur extern ausgelöst (z. B. Zeitplan / Ereignis, über API-Aufruf usw.), damit sie den Status des Hauptdienstcontainers initialisieren / aktualisieren können innerhalb desselben Stapels (z. B. DB-Daten / Schema, Auffüllen von Datenvolumes usw.)
• Innerhalb des Stacks möchte ich Container definieren können, die nur extern ausgelöst werden, damit sie Dienstprogramm- / Administratoraufgaben (z. B. Status- / Dateninspektion usw.) und Prozesse einkapseln können, die planmäßig ausgelöst werden (z. B. Sicherung) oder durch externe Ereignisse (z. B. Auslösen eines Prozesses bei Änderungen an einem S3-Bucket)

In meinem Fall ist die Unterscheidung zwischen state: created (lief 0 Mal) und state: ran (lief> = 1 Mal) wichtig, da einige der Dienstprogramm- / Administratoraufgaben möglicherweise destruktiv sind und nur verwendet werden dürfen unter bestimmten Umständen wie die Migration von Diensten.

Angesichts der Tatsache, dass ich mich jetzt mehr in Richtung state: running | ran | created neige, wie in Rocker-Compose oder Option 4 mit der Fähigkeit _task_ oder _job_ object + der obersten Ebene, eine Abhängigkeit auszudrücken, damit ein Dienst eine Aufgabe auslösen kann, die vor / nach sich selbst ausgeführt wird .

Ich möchte erwähnen, dass dies für meinen Anwendungsfall wichtig ist. Ich verwende Docker-Compose, um eine Testumgebung zu erstellen und eine Testsuite auszuführen. Das Problem beim gleichzeitigen Starten aller Container besteht darin, dass ich nicht einfach zulassen kann, dass die Service-Container (wie Datenbank- oder Sellerie-Mitarbeiter) vor dem Ausführen der Testsuite initialisiert werden.

Es wäre vorzuziehen, etwas erreichen zu können wie:

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

Sie können sich vorstellen, dass etwas Aufwändigeres als sleep 5 könnte, um zu überprüfen, ob die Initialisierung erfolgt ist, dies ist jedoch für das Beispiel-Snippet nicht erforderlich.

Ich habe keine Option über eine CLI-Flagge gelesen. Daher würde ich vorschlagen, dass der Liste der Optionen ein --exclude -Flag hinzugefügt wird. Das Flag --exclude weist den Befehl up an, den angegebenen Container nicht zu starten. Das Flag --exclude so analysiert, dass bei Bedarf mehrere Container vom Start ausgeschlossen werden können.

: +1:

Abwägen mit einem anderen Anwendungsfall, bei dem Option 2 eine geeignete Lösung wäre: Iterieren eines neuen Teildienstes innerhalb einer vorhandenen Anwendung. Die meisten Entwickler des Projekts werden den neuen Service noch nicht benötigen, und Sie möchten definitiv keine Probleme damit, die ihre Arbeit behindern, aber Sie möchten möglicherweise auch vermeiden, dass ein Zweig außerhalb des Baums über einen längeren Zeitraum beibehalten wird Zeit.

Eine separate "docker-compose-experiment.yml" -Datei _could_ funktioniert, aber dies bedeutet, dass die gesamte Dokumentation für die Arbeit an dieser Komponente in eine Richtung geschrieben werden muss, während die Komponente noch experimentell ist, und dann überarbeitet werden muss, sobald sie Teil des Standardsatzes wird von Dienstleistungen.

+1 zu Option 2

+1 für Option 2

+1 für Option 2

+1 für Option 2

+1 für Option 2

@acran Ich würde gerne sehen, dass Sie Ihre Pull-Anfrage einreichen, um zu sehen, ob wir eine gewisse Traktion erzielen können. Wenn Sie den Konflikt auf # 3047 beseitigen, wird er möglicherweise aufgegriffen und weiß nicht, wie Sie darauf aufmerksam werden sollen.

@jimzucker gut # 3047 ist bereits eine Pull-Anfrage und ich warte immer noch auf einige Kommentare der Entwickler: enttäuscht:

Siehe meinen Kommentar oben : Um die PR zusammenzuführen, muss noch etwas poliert werden, dh die zugehörigen Dokumente und Testfälle müssen aktualisiert werden. Aber ich würde diese Arbeit lieber nicht machen, ohne zu wissen, dass dieser Ansatz von Upstream als integriert betrachtet wird. Sonst könnten meine Bemühungen sinnlos sein ...

+1 Option 2

@acran , ich möchte Ihnen helfen, verwandte Dokumente und Testfälle zu aktualisieren. Ist es o.k ?

+1 Option 2

oder vielleicht eine Art Job definieren, wie in Kubernetes?

+1 für Option 2

Wir haben ein Docker-Compose mit mehreren Diensten, und einer davon (die Datenbank) muss in der Entwicklungsumgebung gestartet werden, nicht jedoch in der Produktionsumgebung. Daher müssen wir zwei Docker-Compose-Dateien verwalten. Option 2 ist genau das, wonach wir suchen!

: +1: für Option 2

+1 Option 2

@acran Ich

👍 für Option 2

+1 für Option 2

+1 Option 2

+1 Option 2

Ich stimme auch für Option 2

Eine andere Idee: Jetzt haben wir networks und volumes höchster Ebene. Wir könnten auch eine Option images hinzufügen. Dies wäre ein Hinweis für Compose, dass diese Bilder gezogen oder erstellt werden müssen, damit die Anwendung funktioniert, aber sie werden nicht ausgeführt, wenn Sie docker-compose up ausführen.

Dies würde für zwei Anwendungsfälle funktionieren:

1) Das häufigste Problem hier, bei dem eine Art Verwaltungsbefehl ausgeführt werden soll. docker-compose run kann auf laufende Bilder zurückgreifen, wenn der Dienst nicht vorhanden ist.
2) Apps wie diese, auf denen Docker-Images ausgeführt werden, die jedoch nicht immer ausgeführt werden.

/ cc @dnephin @aanand @ shin-

Abgesehen davon, dass es schön wäre, alle Optionen, die ein Kurzzeitcontainer benötigen würde (dh die Volumes / Mount-Punkte, Netzwerke, Links, Namen usw.), in der Docker-Compose-Datei so konfigurieren zu können, dass Sie dies nicht tun Sie müssen sie jedes Mal hinzufügen, wenn Sie diesen Container ausführen müssen ...

Am 13. September 2016, 03:58:41 Uhr CDT, schrieb Ben Firshman [email protected] :

Eine andere Idee: Jetzt haben wir networks und volumes höchstem Niveau
Fügen Sie auch eine images Option hinzu. Dies wäre ein Hinweis, um diese zu komponieren
Bilder müssen gezogen oder erstellt werden, damit die Anwendung funktioniert, aber sie
würde nicht ausgeführt werden, wenn Sie docker-compose up tun.

Dies würde für zwei Anwendungsfälle funktionieren:

1) Das häufigste Problem hier, wo Sie eine Art Management wollen
Befehl zum Ausführen. docker-compose run könnte auf laufende Bilder zurückgreifen
wenn der Dienst nicht existiert.
2) Apps mögendas was läuft
Docker-Images werden jedoch nicht ständig ausgeführt.

/ cc @dnephin @aanand @ shin-

Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an:
https://github.com/docker/compose/issues/1896#issuecomment -246618909

Von meinem Android-Gerät mit K-9 Mail gesendet. Bitte entschuldigen Sie meine Kürze.

Ich stimme @mgriego darin zu. Stellen Sie sich einen Build-Generierungscontainer vor - es ist am besten, wenn Sie den Befehl und die Optionen eingerichtet haben und nur docker-compose up foo und ihn erstellen und beenden.

Versuchen Sie hier, mehr Verständnis zu erlangen: Ist Option 2) nur ein Spezialfall des allgemeineren "Wir wollen einen initial_scale in docker-compose.yml "? (siehe Nr. 1661, Nr. 2496 et al.)

@ankon überhaupt nicht.

füge einen images [Abschnitt] hinzu

@bfirsh dies beginnt sich in die Richtung zu bewegen, die ich mit https://github.com/dnephin/dobi eingeschlagen habe. Ich habe mich von "Abschnitten" verabschiedet (und stattdessen nur Elemente der obersten Ebene für jede Ressource verwendet). Ich denke, es wäre schwierig, dies mit dem Compose-Modell zum Laufen zu bringen.

1. networks und volumes werden nie direkt bearbeitet, sondern nur nach Bedarf von einem Container erstellt. Das Aufteilen von Bildern in einen eigenen Abschnitt wird das derzeitige Verhalten nicht ändern, sondern die Compose-Konfiguration nur komplizierter machen. Wenn Sie nur ein Image erstellen möchten, führen Sie docker-compose build .
2. Ich denke nicht, dass es tatsächlich die in diesem Problem identifizierten Probleme behebt. Die Leute wollen Container, nicht nur das Bild

Wenn ich den Thread und die Diskussion in # 2496 über das Deklarieren von Skalierungsbeschränkungen in der Erstellungsdatei erneut lese, bevorzuge ich Option 4 (dh einen neuen Abschnitt der obersten Ebene) gegenüber Option 2.

Insbesondere ein Abschnittsname wie utilities passt gut: Komponenten, die normalerweise nicht benötigt werden, aber wenn Sie sie benötigen, möchten Sie vorkonfiguriert haben, mit welchen anderen Komponenten sie verknüpft sind, anstatt müssen Lassen Sie die Leute selbst eine geeignete Beschwörung für docker run konstruieren.

Dieser Ansatz würde dann nicht nur einmalige Administratorbefehle abdecken, sondern auch zusätzliche Debugging- und Introspection-Dienste wie pgweb und Celery Flower (die sehr praktisch sind, um in der Entwicklung ausgeführt zu werden, aber aufgrund der zusätzlichen Sicherheit normalerweise nicht in der Produktion gewünscht werden Bedrohungsfläche, die sie schaffen).

Das Definieren der Semantik dieser neuen "Nicht-Dienste" wird ebenfalls viel einfacher: Sie entsprechen genau services (einschließlich aller zukünftigen Änderungen an diesem Format), mit der einzigen Ausnahme, dass nicht qualifizierte Befehle wie docker-compose build , docker-compose pull und docker-compose up ignorieren sie vollständig. Wenn Sie möchten, dass eine in "Dienstprogramme" anstelle von "Dienste" aufgeführte Komponente verarbeitet wird, müssen Sie sie speziell benennen (obwohl dort vorhanden) könnte vielleicht eine --all Option sein, ähnlich der aktuellen für docker-compose rm ). Die CLI für die Interaktion mit diesen Dienstprogrammen nach Namen ist jedoch identisch mit der für die Interaktion mit normalen Diensten (im Gegensatz zum Status Quo, in dem Sie die zusätzliche Dienstprogrammkonfigurationsdatei angeben müssen), und Docker-Compose sorgt dafür, dass Namenskonflikte vermieden werden zwischen Service- und Utility-Definitionen.

Während der Skalierungsvorschlag in # 2496 möglicherweise (ab) verwendet werden könnte, um dieses Verhalten zu erhalten, fühlt es sich eher wie eine Problemumgehung als wie eine richtig gestaltete Funktion an.

Ich mag dieses Design, @ncoghlan.

Anstelle von utilities benennen Sie es einfach .services ? Dies zeigt natürlich, dass services und .services genau dieselbe Semantik verwenden. Der einzige Unterschied besteht darin, dass .services nicht standardmäßig ausgeführt werden. Es ist ein ziemlich nahes Analogon zu Dateinamen, die standardmäßig nicht angezeigt werden. Ich nehme an, der Nachteil ist, dass die Unterscheidung zwischen den beiden etwas subtil ist.

Ich mag die Grundidee, über die @ncoghlan dort spricht, aber…

1. Stimmen Sie nicht zu, dass _all_ unqualifizierte Befehle diese Dienstprogramme standardmäßig ignorieren sollten. Meiner Meinung nach sollten alle Befehle normal ausgeführt werden, mit Ausnahme derjenigen, die zu einem laufenden Container führen würden. (Also im Grunde up und start .)
2. In Bezug auf den Kommentar von

@bfirsh @ncoghlan Ich stimme @dnephin voll und

Ich denke nicht, dass es tatsächlich die in diesem Problem identifizierten Probleme behebt. Die Leute wollen Container, nicht nur das Bild

Was ich - und ich denke, die meisten Leute hier - für meinen gewünschten Workflow brauche, sind einfache Dienstleistungen; Sie werden wie normale Dienste definiert, wie normale Dienste usw. gestartet / gestoppt.
Der einzige Unterschied besteht darin, dass sie nicht automatisch von einem einfachen docker-compose up standardmäßig gestartet werden, sondern nur, wenn dies explizit angegeben (oder als Abhängigkeit eingezogen) wird.

Daher sehe ich keine Notwendigkeit für einen neuen Abschnitt der obersten Ebene oder ein völlig neues Konzept für diese einmaligen Container, sondern nur einen optionalen Konfigurationsparameter pro Dienst.
Ich habe dies in meiner Pull-Anfrage Nr. 3047 als Proof of Concept implementiert. Es ist eine recht kleine Änderung, würde aber meine Anwendungsfälle voll erfüllen. Wenn ich also noch etwas tun kann, um dies zusammenzuführen, lassen Sie es mich bitte wissen (=

Für alle, die dies testen möchten, hier die Befehle zum Erstellen und Ausführen von Docker-Compose in einem Container:

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

@acran , ich möchte Ihnen helfen, verwandte Dokumente und Testfälle zu aktualisieren. Ist es o.k ?

@ dattran-vn01 natürlich würde ich mich freuen: smiley:

@acran In Ihrem Beispiel ist der einzige Befehl, der sich vom aktuellen Compose unterscheidet, der erste. up baz .
Sie können dasselbe auch erreichen, indem Sie mehrere Compose-Dateien verwenden.

Einige Befehle auf einer anderen Liste von Standarddiensten ausführen zu lassen, scheint sehr verwirrend zu sein und war einer der Gründe, warum mir diese Funktion nicht gefällt.

@acran In Ihrem Beispiel ist der einzige Befehl, der sich vom aktuellen Compose unterscheidet, der erste, und dieses Verhalten kann mit up baz erreicht werden.
Sie können dasselbe auch erreichen, indem Sie mehrere Compose-Dateien verwenden.

@dnephin ja genau, ich weiß, und in diesem Beispiel wäre es der einfachste Weg.
Stellen Sie sich dies jedoch mit 10 Diensten und nur einem einmaligen Dienst vor (wie "init" oder "backup" / "dump"): In diesem Fall müssten Sie alle Dienste in der Befehlszeile auflisten, mit Ausnahme eines einzigen. Off-Service wie docker-compose up service1 service2 ... service10 (siehe unten). Insbesondere müssten Sie sich alle Dienste merken und alle Änderungen in docker-compose.yml manuell verfolgen.

Ich weiß auch über die Möglichkeit der Verwendung mehrerer YAML-Dateien Bescheid, siehe meinen ersten Kommentar oben , und dies sowie die explizite Angabe aller Dienste in der Befehlszeile decken tatsächlich die meisten hier genannten Anwendungsfälle ab. Es fühlt sich jedoch eher nach einer Problemumgehung an.

Hier ein weiteres Beispiel docker-compose.yml , um das Problem zu visualisieren:

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

Ein einfaches docker-compose up _mit_ dem auto_up -Attribut startet hier alle Dienste außer Service init . Um dasselbe zu erreichen, ohne es zu tun, müsste ein viel längerer Befehl mit 10 Diensten eingegeben oder die YAML-Datei aufgeteilt und mehrere Dateien angegeben werden.

Bei der hier angeforderten Funktion geht es also mehr um Bequemlichkeit und weniger Eingabe auf der CLI und nicht um eine völlig neue Funktion.

In Bezug auf die Option "Mehrere Konfigurationsdateien verwenden" (die in der Tat die derzeit beste verfügbare Option ist) besteht das Usability-Problem darin, dass es in der Praxis folgendermaßen aussieht:

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

Die Diskrepanz infiziert dann alle Ihre Projektdokumentation und -automatisierung: Sie müssen sicherstellen, dass zwei Compose-Dateien für alle verfügbar sind, die Dienstprogrammbefehle ausführen möchten. Sie müssen sicherstellen, dass der vollständige Aufruf für Befehle in der Dienstprogrammdatei erfolgt, und falls vorhanden Wenn der Dienst jemals von "immer ausgeführt" auf "nur auf explizite Anforderung ausgeführt" herabgestuft wird, müssen Sie einen Aufruf suchen, der die Konfigurationsdateinamen nicht enthält, und diese hinzufügen.

Das ist alles _doable_, es ist nur ärgerlich im Vergleich dazu, in der Erstellungsdatei sagen zu können "Führen Sie dies nur aus, wenn ich Sie ausdrücklich dazu auffordere, führen Sie es niemals standardmäßig aus".

Jemand sagte mir einmal: _ "Wenn mehrere kluge Leute nicht entscheiden können, welcher Ansatz der beste ist, ist normalerweise keiner der beiden ziemlich schlecht. Der schlechteste ist, nichts zu tun." _

Diese Karte scheint ein Paradebeispiel dafür zu sein :)

Angesichts der Tatsache, dass Docker jetzt das Konzept des Dienstes für Befehle mit langer Laufzeit nativ unterstützt, wäre es meiner Meinung nach am besten, einen neuen Abschnitt namens Befehle hinzuzufügen, der die gleiche Funktionalität wie Dienste bietet, mit Ausnahme von Neustartrichtlinien, die nicht zulässig sein sollten.

In meinem Setup habe ich Dienste im Docker-Compose, die zum Ausführen meiner Infrastruktur erforderlich sind (Nginx, Datenbank, Webserver, Nachrichtenwarteschlangen ...). Ich habe auch zusätzliche Dienste definiert, die ich nur aus Debugging-Gründen benötige (zum Beispiel eine Datenbank-Web-GUI).

Ich möchte, dass die "Debugging" -Dienste NICHT automatisch gestartet werden, aber wenn ich sie hinzufügen möchte, kann ich dies mit einem einfachen docker-compose up -d database-gui tun und es wird einfach hinzugefügt.

Außerdem: Manchmal ändere ich meine Meinung und möchte, dass einer dieser Dienste immer gestartet wird ... => Mit Option 2) kann ich nur dieses eine Flag ändern

=> Stimmen Sie für Option zwei, weil es einfach ist und hier alle Anforderungen zu erfüllen scheint. Jede andere Lösung fühlt sich für mich wie eine Überentwicklung an ... Hinzufügen von Komplexität zur Konfiguration basierend auf seltenen oder nur imaginären Anwendungsfällen, nicht aufgrund praktischer Anforderungen.

Nur hier, um meine +1 hinzuzufügen. Ich verwende Django-Apps und wenn ich sie im Docker ausführe, wäre es schön, einen Container zu haben, der Shell oder Tests ausführt oder Befehle migriert. Ich möchte diese Funktionen jedoch nicht jedes Mal ausführen, wenn ich die App starte. Während die Verwendung mehrerer Konfigurationsdateien funktionieren würde, müssten meilenlange Befehlszeilen eingegeben, Skripte erstellt oder Aliasing ausgeführt werden. Wenn ich das tun wollte, würde ich Compose überhaupt nicht verwenden, ich würde nur meine Container als Shell-Skript verwenden (oder als Python-Skript ... vielleicht eine einheitliche YAML-Datei hinzufügen, um Containerkonfigurationen zu speichern ... warte ...) Ich möchte nichts wie docker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrate tun, nur um Datenbankmigrationen auf meinem Container auszuführen. Die Alternative besteht darin, /bin/true als Befehl zu verwenden und so etwas wie docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate' tun, was auch nicht sehr elegant ist. Es wäre also sehr nützlich, wenn einmalige Befehle irgendwo in der Konfiguration gespeichert würden. Jede der Optionen 2, 3 und 4 würde für mich funktionieren.

Ich möchte vorschlagen, dass Sie sich dobi ansehen , ein Tool, an dem ich gearbeitet habe, teilweise basierend auf dem Feedback aus diesem Thread.

compose wurde entwickelt, um lang laufende Dienste zu starten, die eine "Umgebung" bilden.
dobi konzentriert sich auf sequentielle projektaufbauten.

Die Dinge, nach denen Sie suchen (Ausführen einer Shell, Ausführen von Komponententests, Ausführen der Migration), sind alle Projektaufgaben, sodass sie viel besser in das Dobi-Modell passen.

dobi und compose arbeiten recht gut zusammen. Sie können compose von dobi aus mit einer compose-Ressource starten.

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

die Sie ausführen können mit:

dobi dev-environment

Hier finden Sie ein Beispiel für die Compose-Integration und das Ausführen von DB-Migrationen: https://github.com/dnephin/dobi/tree/master/examples/init-db-with-rails

Hier finden Sie Beispiele für viele Workflows (einschließlich Ausführen von Tests, Starten einer interaktiven Shell, Freigeben und Erstellen minimaler Bilder): http://dnephin.github.io/dobi/examples.html

+1 für 2). Aus unserer Sicht ist es unnötig, ungewöhnliche Anwendungsfälle wie einmalige Befehle zu denken und zu diskutieren, aber wir möchten nur echte Dienste haben, die erstellt und einsatzbereit sind, aber bei Bedarf bei Bedarf gestartet werden können (und standardmäßig nicht verbrauchen) Ressourcen).

"ungewöhnliche Fälle"? Führen Sie Datenbankmigrationen durch? Führen Sie Unit-Tests durch? Laufen Sie Fusseln? Webpack?

Ja, ich renne, aber das kann meiner Meinung nach in Containern erreicht und kontrolliert werden. Aber ich möchte Ihre Ansicht oder Forderungen nicht beeinträchtigen, lassen Sie uns diese Diskussion nicht in Flammen aufgehen. Unsere Anforderungen an Docker Compose stehen nicht unbedingt im Widerspruch.

Ich bin gerade auf diesen Thread gestoßen, der versucht hat, einen Docker-Compose-Container für ein Skript zu erstellen, der die Datenbank in meinem MySQL-Container löscht und das Schema aus einem heruntergeladenen Dump neu lädt. Es ist ein sehr langwieriger und zerstörerischer Prozess, daher möchte ich nicht, dass er jedes Mal ausgeführt wird, wenn ich die Dienste aufrufe, sondern er muss auch innerhalb der zusammengesetzten Gruppe von Containern mit einer eigenen Docker-Datei ausgeführt werden.

Nenne sie Aufgaben, Befehle, was auch immer, aber ich bin ein bisschen SOL ohne sie.

Ich bin auf die Suche nach etwas anderem gestoßen und wollte nur einen Anwendungsfall einbinden ... Wir haben festgestellt, dass unsere Entwickler am besten definieren können, welche Daten von ihren Diensten gesichert werden sollen. Da die Datei docker-compose.yml in ihren Händen liegt und benannte Volumes verwendet werden, haben wir beschlossen, sie zum Definieren der Sicherungsstrategien zu verwenden ... Hier ist ein zusammengefasstes Beispiel unserer alten docker-compose.yml, die wir verwendet haben.

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

Um die Volumendaten sichern zu können, haben wir uns für einen Busybox-Container entschieden, um die benötigten Daten zu tarieren. Er muss jedoch flexibel sein und nur die Volumes ausführen, die die Entwickler sichern möchten. Schließlich sollten wir in der Lage sein, jedes Volume separat zu sichern. Um dies zu erreichen, haben wir unserer docker-compose.yml 3 Dienste hinzugefügt

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

Die Sicherungs- und Wiederherstellungsdienste müssen nur mithilfe der Volumes konfiguriert werden. Den Rest erledigen die Befehle. Wir planen, ein wenig Konfiguration hinzuzufügen, um auswählen zu können, welche Volumes gesichert oder wiederhergestellt werden sollen, aber im Moment machen wir sie alle ... Da wir nicht möchten, dass diese beiden Dienste bei jedem Docker-Compose gestartet werden Mit dem Befehl up mussten wir alle gewünschten Dienste angeben, was mühsam sein kann. Also haben wir einen Dummy-Dienst namens boot hinzugefügt. Alles, was wir tun müssen, hängt von allen Diensten ab, die ausgeführt werden müssen, und wir rufen diesen nur auf, wenn wir Docker-komponieren.

Dies hier ist voll von kleinen Hacks, aber es ermöglicht uns, docker-compose up backup einfach auszuführen, um unser Backup auf den Hosts / Backups / neuesten zu speichern, und von dort aus führen wir unsere Versions- / Bereinigungslogik aus.

Ich hoffe, es hilft jemandem, der versucht, etwas Ähnliches zu erreichen ... Aber am Ende, wenn wir Docker-Compose nur anweisen können, diese beiden Dienste nicht zu booten, brauchen wir keinen dritten und erschweren unser Docker-Compose Befehle.

In der Entwicklung befinden sich derzeit 4 Docker-Compose-Dateien:

• docker-compose.yml : Definiert die Kerndienste, die für den vollständigen Betrieb unserer App erforderlich sind, z. B. Redis, MySQL, PHP-Fpm, Laravel-Warteschlangenprozessor, Nginx, Solr
• docker-compose-utils.yml : Definiert Dienstprogramme, die zum Ausführen von Entwicklungsaufgaben benötigt werden, z. B. gulp, npm, artisan (Laravel), Composer, redis-cli, die normalerweise mit den oben genannten Diensten ausgeführt werden
• 2 weitere Docker-Compose-Dateien, um die Umgebung und die Volumes für die oben genannten Dienste zu definieren

Dieses Setup funktioniert gut, da wir außerhalb von Docker minimale Abhängigkeiten für unsere Entwicklungsumgebung haben. Der Nachteil sind die unhandlichen Befehlszeilen, die erforderlich sind, um alle erforderlichen .yml-Dateien anzugeben, um einfache Dienstprogramme auszuführen.

Wir entwickeln unter MacOS, Windows und Linux. Darüber hinaus erfordern viele unserer Entwicklungsaufgaben eine Parametrisierung (z. B. Erstellen einer DB-Migration, Ausführen eines Composer / Artisan / Npm-Befehls mit eigenen Argumenten). Daher habe ich schmich/runx als Cross-Zero für die Installation erstellt. Plattform Task Runner, um unsere gemeinsamen Entwicklungsaufgaben zu bündeln.

Dies lässt uns beispielsweise sagen, dass runx migrate : make_some_table erstellen , um docker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_table effektiv auszuführen, oder runx npm veraltet , um unsere veralteten JS-Abhängigkeiten anzuzeigen.

Ich habe dobi oben nicht verwendet, aber runx fühlt sich im Geiste ähnlich an, obwohl es weniger auf eine Docker-Umgebung zugeschnitten ist. Letztendlich möchte ich Abhängigkeiten überall vermeiden, außer dort, wo sie unbedingt benötigt werden: für die Dienste selbst und für die in der Entwicklung benötigten Dienstprogramm-Skripte.

Irgendwelche Neuigkeiten? Ich denke, diese Funktion wäre wirklich schön zu haben! Ich stimme für die Lösung einer Toplevel-Konfiguration wie default in der wir angeben können, welcher Dienst ausgeführt werden soll.
Der boot Dummy-Service ist nett, aber ich ziehe es vor, den Prozess im Vordergrund zu lassen. Wenn ich mit dieser Arbeit fertig bin, kann ich einfach das Terminal schließen, um alles herunterzufahren. Es ist auch schön, wenn die Ausgabe standardmäßig angehängt ist, und dies passiert beim Dummy-Dienst nicht.

Da Noboby Anwendungsfälle mit .env-Dateien kommentiert hat, ist hier meine:

Ich habe 4 Compose-Dateien: docker-compose.yml, docker-compose.local.yml, docker-compose.prod.yml und docker-compose.ci.yml. Für jede Umgebung habe ich eine andere .env:

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

Und so weiter...

Benutzer und / oder Skripte müssen sich keine Gedanken darüber machen, welche Compose-Dateien verwendet werden sollen, da Umgebungen bereits individuell konfiguriert sind.

Ich muss jedoch eine Wartungsinstanz ausführen, die nicht in der Hauptdatei docker-compose.yml konfiguriert werden kann. Eine Lösung besteht darin, eine docker-compose.worker.yml zu erstellen und eine Befehlszeile mit 3 "-f" -Optionen auszuführen, die sich ändern mit jeder Umgebung. Das ist zu fehleranfällig, um eine brauchbare Option zu sein.

Die Lösung, die ich gefunden habe, bestand darin, ein Verzeichnis "worker" zu erstellen, die yml-Datei dort abzulegen, die obere .env-Datei mit diesem Verzeichnis zu verknüpfen und leere Docker-Compose-Dateien [ci | local | prod] .yml zu erstellen (andernfalls hätte ich sie um den Wert der Variablen COMPOSE_FILE zu ändern).

Dies funktioniert gut, ist aber alles andere als optimal. Jede andere Lösung aus dem OP würde dies ohne Probleme lösen.

Ich denke, die Diskussion hier, die vielen beispielhaften Anwendungsfälle sowie die Tatsache, dass es häufig doppelte Probleme gibt, machen deutlich, dass es eine echte Nachfrage vieler Benutzer nach einer Möglichkeit gibt, "Dienste zu definieren, die nicht standardmäßig gestartet werden ".

Daher möchte ich die Diskussion hier wirklich von _wenn_ dies mehr implementiert werden sollte zu _wie_ dies implementiert werden sollte. Könnten wir uns vielleicht alle einig sein ?

In Bezug auf _how_ könnte dies erreicht werden @bfirsh listete einige Optionen im Eröffnungskommentar auf:

1) Empfehlen Sie den Benutzern, eine separate Compose-Datei zu verwenden

Dies ist die einzige derzeit verfügbare Lösung für diesen Anwendungsfall. Wie oben erwähnt, ist dies in diesem Fall eher eine Problemumgehung, da lange Befehlszeilen manuell eingegeben und gespeichert werden müssen, welche Compose-Dateien für welchen Befehl enthalten sein sollen.
In einem CI-Setup oder einer automatisierten Bereitstellung für die Produktion ist dies natürlich kein Problem, da die Befehlszeile nur einmal definiert und niemals manuell eingegeben werden muss. Hier geht es also ausschließlich um Komfort in nicht automatisierten Umgebungen, dh um die Entwicklung, die laut Docker-Compose-Handbuch einer der Hauptanwendungsfälle von Compose selbst ist:

Zusammen bieten diese Funktionen Entwicklern eine bequeme Möglichkeit, mit einem Projekt zu beginnen. Compose kann eine mehrseitige Anleitung für Entwickler zum Einstieg auf eine einzige maschinenlesbare Compose-Datei und einige Befehle reduzieren.

Etwas wie docker-compose -f docker-compose.yml -f docker-compose-utils.yml run init eingeben zu müssen, um ein lokales Setup zu initialisieren, klingt für mich nicht bequem, sondern eher wie etwas, das in einem mehrseitigen Leitfaden für Entwickler zu finden ist.

Und um Option 1b) hier zu betrachten:

Empfehlen Sie Benutzern, ein Wrapper-Skript / Tool zu verwenden, um separate Compose-Dateien zu verwenden

Wenn ich nur dafür zusätzliche Tools und Abhängigkeiten einbinden muss, warum überhaupt docker-compose ? Da alles, was docker-compose tut, theoretisch auch nur mit einem benutzerdefinierten Shell-Skript und dem nativen docker -Client direkt erledigt werden kann.
Ich sehe den Hauptvorteil von docker-compose in der standardisierten Benutzeroberfläche (ich klone ein Projekt, sehe dort ein docker-compose.yml und weiß, dass ich nur docker-compose up ausführen muss, um loszulegen). . Immer wissen zu müssen, welche Compose-Datei für was verwendet werden soll, schwächt diesen Vorteil drastisch.

2) Fügen Sie den Diensten eine Option hinzu, damit sie nicht standardmäßig gestartet werden
3) Fügen Sie eine Konfigurationsoption der obersten Ebene hinzu, um die Standarddienste zu definieren

Diese beiden Optionen haben im Grunde das gleiche: Definieren Sie, welche Dienste standardmäßig in einer Erstellungsdatei (nicht) gestartet werden sollen, Option 2) indem Sie einzelne Dienste auf die schwarze Liste setzen, Option 3) indem Sie eine Reihe von Diensten global auf die Whitelist setzen.
Wenn man bedenkt, dass die meiste Zeit mehr Standarddienste als "einmalige Dienste" in einer einzelnen Erstellungsdatei enthalten sind, ist es wahrscheinlich einfacher, einen Dienst auf die schwarze Liste zu setzen, als alle anderen auf die Whitelist zu setzen und die Whitelist jedes Mal zu aktualisieren, wenn ein Standarddienst abgerufen wird hinzugefügt oder entfernt. Auch mit Option 2) ist das Zusammenführen mehrerer Compose-Dateien wahrscheinlich einfacher.

4) Fügen Sie ein Konzept für eine Sache wie einen Dienst hinzu, das jedoch nur für einmalige Befehle ("Skripte", "Aufgaben" usw.) vorgesehen ist.

Ich denke, Option 4) ist nur eine Spezialisierung von Option 2) oder 3), da in den meisten obigen Beispielen die gewünschten einmaligen Container grundsätzlich wie jeder andere Dienst definiert sind und nichts mehr oder weniger wie normale Dienste tun - außer dass sie werden nicht standardmäßig gestartet. (Oder habe ich einen signifikanten Unterschied zu einem "Service" verpasst).

Meiner Meinung nach ist Option 2) hier die beste Wahl, da sie die geringste Änderung erfordert, aber gleichzeitig flexibel genug ist, um die meisten (oder alle?) Hier genannten Anwendungsfälle zu erfüllen und gleichzeitig sehr bequem zu verwenden.
Trotzdem würde ich mich genauso freuen, wenn etwas wie Option 3) oder 4) in den Upstream verschmolzen würde. Gibt es nach über einem Jahr Diskussion hier einen Zeitplan, wann oder ob dies passieren wird?

Ich stimme zu, dass Option 2 wahrscheinlich am wenigsten invasiv ist. Die einzige Funktion, die Option 4 bietet, ist die Möglichkeit, Befehle für vorhandene Container auszuführen (mithilfe des Docker-Exec-Mechanismus). Wenn ich beispielsweise nur eine Datenbankmigration oder Unit-Tests ausführen möchte, gibt es möglicherweise keinen Grund, einen separaten Container dafür zu erstellen, wenn ich bereits einen Container habe, in dem meine App ausgeführt wird. Das heißt, Container sind leicht und ich würde mit Option 2 vollkommen zufrieden sein.

@ MadWombat Ich habe das gleiche Gefühl bei Option 4, deshalb habe ich eine weitere Funktion für diesen Anwendungsfall vorgeschlagen: # 4096. Es gibt Überschneidungen mit der hier beschriebenen Funktion, aber ich glaube, sie könnte allein oder zusätzlich zu dieser nützlich sein

@mathroc Ich habe Option 4 mit Docker Exec erwähnt, da @acran gefragt hat, ob es einen signifikanten Unterschied zwischen Option 2 und 4 gibt. Ich kann jedoch keinen realen Anwendungsfall finden, in dem Sie speziell einen Befehl auf einem ausführen möchten vorhandener Container, anstatt einen anderen ähnlichen Container für diesen Zweck aufzurufen. Möglicherweise gibt es ein Szenario mit begrenzten dauerhaften Verbindungen zu einem Dienst oder einer anderen begrenzten Ressource, die bereits von vorhandenen Containern verwendet wird, aber ich kann mir keine vorstellen.

Die einzige Funktion, die Option 4 bietet, ist die Möglichkeit, Befehle für vorhandene Container auszuführen (mithilfe des Docker-Exec-Mechanismus).

Dies ist in der Tat ein neuer Anwendungsfall, der die Einführung eines neuen Top-Level-Konzepts rechtfertigen (und erfordern) würde, das sich von den Diensten unterscheidet. Solange die Befehle nicht über docker exec im bereits vorhandenen Service-Container ausgeführt werden müssen, sollte das vorhandene Service-Konzept ausreichen.

Ich kann mir jedoch keinen realen Anwendungsfall ausdenken, in dem Sie speziell einen Befehl für einen vorhandenen Container ausführen möchten, anstatt einen anderen ähnlichen Container für diesen Zweck aufzurufen.

Der nächste Fall, an den ich denken kann, ist so etwas wie das Ändern einer Konfigurationsdatei im Container und das Auslösen eines Neuladens durch die Anwendung. am Beispiel von

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

Obwohl # 4096 mit diesem Problem zusammenhängt, hat es seine eigenen Anwendungsfälle und Option 4) könnte am besten dorthin verschoben werden?

Es war über ein Jahr der Diskussion und wir scheinen keine weitere Entscheidung zu treffen. @bfirsh sollte einfach einen Stil auswählen und dazu

+1

+1, das wäre eine sehr nützliche Funktion.

Und noch +1 für Option 2 mit so etwas wie auto-start: false oder enabled: false .

Mein Anwendungsfall ist die Erweiterung von Diensten. Es ist nicht möglich, Dienste zu erweitern, für die depends_on festgelegt ist. Daher möchte ich eine Dienstvorlage definieren und dann mehrere Dienste daraus erweitern. Natürlich sollte die Vorlage erstellt, aber nicht automatisch erstellt werden.

Ich habe meine eigene Lösung erstellt und kann sie kostenlos verwenden.
Es ist noch in der Beta :)

https://github.com/jonathanborges/picles-docker

Viele tolle Möglichkeiten hier. Die Notwendigkeit für die Funktion ist real.

Option 2 ist eindeutig das beliebteste Ereignis:

1 -> 4
2 -> 52
3 -> 3
4 -> 10

Ein weiteres 👍 für Option 2

Wir können dies ziemlich einfach in einem "Tools" -Dienst mit einem anfänglichen Einstiegspunkt oder Befehl behandeln, der einfach zurückgegeben wird. Dann führen wir diesen Dienst mit einem alternativen Befehl aus, um das zu tun, was wir wollen (z. B. Tests oder Seed der Daten). Z.B

docker-compuse up -d
docker-compose run tools tests

Ja, der Tools-Service wird in docker-compose ps als "gestoppt" https://github.com/docker/compose/pull/2051 . z.B

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

Obwohl es so aussieht, als würden viele Orchestrierungshelfer für dieses Bedürfnis geschrieben und ich bin schuld daran, auch an einem zu arbeiten :).

Persönlich glaube ich, dass es genügend Problemumgehungen gibt (wie die beiden oben genannten; kreativ mit Ihren Einstiegspunkten / Containern werden und / oder den Multifile-Ansatz mit einem Shell-Alias ​​/ Helfer verwenden), und das Verfassen kann einfach gehalten werden.

@briceburg siehe obige Diskussion: Hier geht es nicht um eine fehlende Funktionalität, die auf keine andere Weise möglich wäre. Es gibt Problemumgehungen für fast alles, was die Leute hier erreichen wollen. Aber es sind Workarounds und Dirty Hacks anstelle eines normalen Anwendungsfalls von Docker-Compose.

Es geht um Bequemlichkeit, darum, docker-compose -f docker-compose.yml -f docker-compose-tools.yml up von Hand auf dem CLI eingeben zu müssen, es geht darum, sich nicht daran zu erinnern, ob es docker-compose run tools tests oder docker-compose run utils tests oder sich überhaupt darauf verlassen muss eine mehrseitige "Anleitung für Entwickler", die stattdessen eine einheitliche und einfache Oberfläche für den Entwickler bietet.

Nochmals CCing @bfirsh , @dnephin : bitte _any_ Feedback zu diesem Problem geben? Gibt es irgendeine Hoffnung, dass wir so etwas auf der kommenden Roadmap für docker-compose sehen könnten?

@briceburg für eine einfache Umgebung Vielleicht ist eine

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

Ich habe 8 Compose-Dateien (die ich in mehreren Kombinationen verwende) neben denen im Verzeichnis worker , in denen ich die Container "Nicht standardmäßig starten" konfiguriere. Das Verzeichnis worker (mit einer mit dem übergeordneten Element verknüpften .env-Datei und einigen leeren Erstellungsdateien zur Einhaltung der .env-Variablen COMPENE_FILE des übergeordneten Elements) ist meine Problemumgehung, aber mein Leben wird viel einfacher, wenn wir eine Lösung für haben dieses Problem.

@vipseixas Es ist schwierig, die Richtigkeit dieser Lösung

In den meisten Fällen sollten Sie sicherstellen, dass Integritätsprüfungen abhängige Dienste / Container weiterleiten, bevor Sie Tests ausführen. Beispielsweise ist Jenkins aktiv und wird ausgeführt (Verbindungen werden akzeptiert unter: 8080 oder was auch immer), bevor diese Tests ausgeführt werden. In der Vergangenheit habe ich dafür Dockerize verwendet.

Wenn ich eine Silberkugel vorschlagen würde, wäre es möglich, das Erstellen eines Erstellungsprofils über Umgebungsvariablen (z. B. DOCKER_COMPOSE_PROFILE = "tests") zuzulassen und zuzulassen, dass Dienste von einem Profil abhängig sind - wobei alle Dienste standardmäßig den Standardwert haben "Profil oder was auch immer. Ich würde auch sicherstellen, dass Dienste, die von einem anderen Dienst abhängig sind, auch vom HEALTHCHECK dieser Dienste abhängig sind. Also so etwas wie

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

+1 für Option 2.

Viele hier haben interessante neue Funktionen vorgeschlagen, aber was ist der Kern des Problems hier? Ich stimme dafür, es so einfach wie möglich zu halten.

Nach dem heutigen Stand gehen wir davon aus, dass alle Dienste in unserer docker-compose.yml auf docker-compose up aufgerufen werden. Wir arbeiten alle mit unseren eigenen benutzerdefinierten Bootstrap-Skripten, Makefiles, Build-Tools usw., und glücklicherweise stellen sowohl Docker-Compose als auch Docker eine umfangreiche API für die Verwaltung einzelner Container bereit, sobald das Spülbecken in Betrieb ist.

Mein einziges Bedürfnis, das Kernbedürfnis, das mich zu dieser Diskussion gebracht hat, besteht darin, anzugeben, dass einer dieser Dienste, die ich definiert habe, aus irgendeinem Grund nicht standardmäßig "up" sein soll.

Was ist die einfachste Funktion, die es für uns alle "schafft"? Es ist ein winziges Update der docker-compose.yml-Spezifikation ( @bfirsh ursprüngliche Idee Nr. 2), bei der ein Dienst autostart: false angeben kann

Ich stimme für: "TUN SIE NUR ETWAS FÜR UNS, DANKE." Wir stimmen ab, wir brauchen jetzt mindestens eine Antwort. 4 GOTT!

Was ist die einfachste Funktion, die es für uns alle "schafft"? Es ist ein winziges Update der docker-compose.yml-Spezifikation ( @bfirsh ursprüngliche Idee Nr. 2), bei der ein Dienst Autostart angeben kann: false

Das ist viel besser als jede andere Alternative :)

Es ist so einfach.
scale: 0
https://github.com/docker/compose/issues/1661

@ zeichnete-r was?

@ jonathanborges1542 Es ist docker-compose scale servname=2 . Es gibt kein Äquivalent in der Datei docker-compose.yml .

@ draw-r scale: 0 weist den Docker-Daemon derzeit an, SIGTERM / SIGKILL an alle Container für den Dienst zu senden. Dies würde jeden Wartungsjob beenden, selbst wenn er seinen Job noch nicht abgeschlossen hat. Das ist das erwartete Verhalten. Dies zu ändern wäre ein schlimmer Fall von Überlastung, was derzeit ein klares Verhalten ist.

@gittycat Ich verstehe, aber wir wollen hier "docker-compose up"

Ich verfolge dieses Thema seit über einem Jahr (die meisten Beiträge sind auf der Docker-Seite).
Ich glaube, dass ein neuer "Job" auf höchster Ebene neben "Diensten", "Volumen" und "Netzwerken" die beste Option ist. Das ist Option 4 in der obigen OP-Liste.
Es ist auch ein Vorschlag im Docker Repo.
https://github.com/docker/docker/issues/23880

@ Briceburg

Es ist schwierig, die Vernunft dieser Lösung anhand einer Dateiliste zu beurteilen

Die Absicht war nur zu zeigen, dass ich viele Dateikombinationen habe und die Verwendung mehrerer "-f" -Optionen zu fehleranfällig ist, um manuell durchgeführt zu werden.

Ich schlage nur vor, dass Sie einen Standardeinstiegspunkt / -befehl verwenden, der nichts für die Dienste tut, die Sie nicht automatisch starten möchten.

Manchmal gibt es kein Entrinnen vor dem Untergang. Aber ich bevorzuge meine Lösung: Ich verwende ein anderes Verzeichnis, das niemals "zusammengesetzt" wird, damit es keine nutzlosen gestoppten Container gibt, die meine Umgebung verschmutzen. Deshalb habe ich ein Arbeitsverzeichnis mit einer ".env", die mit der übergeordneten ".env" verknüpft ist.

Wenn ich eine Silberkugel vorschlagen würde, wäre es möglich, ein Kompositionsprofil über Umgebungsvariablen festzulegen (z. B. DOCKER_COMPOSE_PROFILE = "tests").

DAS wäre die beste Lösung. Aber ich glaube nicht, dass die Entwickler dazu neigen, die Komplexität zu erhöhen ...

Ich möchte ein Basis-Image erstellen, dieses in derselben docker-compose.yml "erweitern" und nur das zweite Image starten, das momentan nicht in einem Schritt möglich ist. Mit Option 2 wird es sein, aber vielleicht ist der bessere und sauberere Weg, eine "Build-Phase" und eine "Run-Phase" zu haben, in der die Erstellung von Basis-Images erfolgt. Im Moment muss ich 2 Befehle ausführen und nicht nur einen.

+1 @ draw-r # 1661

Wird dieses Problem irgendwann implementiert oder ist es nur etwas, was Compose Devs nicht tun wollen? Es wäre schön zu wissen, damit die Community nach einer anderen Lösung suchen kann.

Ich stimme übrigens für Option 2.

Vielen Dank

+1 für Option 2.
Würde es explizite Abhängigkeiten respektieren ... links etc?

Wenn ich spezifiziere, welcher Dienst mit docker-compose up [service] aufgerufen werden soll, möchte ich selten andere Dienste als den betreffenden Dienst und seine Abhängigkeiten starten.

Eine weitere Abstimmung für Option 2. Es gibt sogar eine PR dafür (https://github.com/docker/compose/pull/3047), die @acran freundlicherweise erstellt hat, daher sollte der Aufwand der Compose-Entwickler relativ gering sein. da sie es nur überprüfen müssen (und es ist ziemlich kurz und einfach) und keinen Code schreiben müssen.

Wenn die Compose-Entwickler dies nicht möchten, sollten sie es ein für alle Mal angeben und dann das Ticket schließen und sperren, um Kommentare zu vermeiden.

@msabramo compose wird im Wesentlichen von dem beeinflusst, was auf der Ebene der Docker-Engine entschieden wird.

Die Anfrage wird im Docker-Engine-Repo https://github.com/docker/docker/issues/23880 nachverfolgt
Von dort wird die Entscheidung / Arbeit kommen.

Ich schlage vor, dieses Problem zu schließen.

@gittycat compose kann weiterhin die Option haben, die Engine

Ich gebe Docker in der Produktion auf, es gibt viele Probleme. Dann wandere ich zu Vagabund.

Eine weitere Abstimmung für 2)

Eine weitere Abstimmung für 2 und 4.

Um nur auf einen Anwendungsfall hinzuweisen: Einige Dienste haben zirkuläre Abhängigkeiten, die Notwendigkeit, Konfigurationsdateien zu generieren, Testsuiten auszuführen und viele andere Möglichkeiten. Wir können es von Docker entkoppeln oder andere Tools verwenden, aber es fügt dem Einrichten des Projekts unnötige Komplexität hinzu.

Ein einfacher Befehl zum Einrichten und / oder für Tests würde die Dinge viel sauberer machen.

Noch eine Stimme für 2!

Ich hatte diesen Thread gelesen, aber beschlossen, einen neuen Beitrag (https://github.com/docker/compose/issues/4650) zu erstellen, der geschlossen wurde und auf den ich hier verwiesen wurde. Der Punkt, den ich ansprechen wollte, ist, dass während der größte Teil der Diskussion in diesem Thread Flags zum Deaktivieren laufender Container betrifft, mein Anwendungsfall einen dritten Status hat: das Erstellen von Containern.

Ich möchte nicht nur verhindern, dass ein Container ausgeführt wird, sondern in der Lage sein, den Container überhaupt nicht zu erstellen (in meinem Anwendungsfall habe ich einen benutzergesteuerten Prozess, der dies ausführt).

@ekkis Ich bin gespannt, wie es dazu kam. Mein Anwendungsfall besteht darin, auf das Hauptcontainer-Image zu verweisen und alternative "Aktionen" zu konfigurieren. Dies könnte mit Bash erfolgen, aber es ist sinnvoller, Docker zu verwenden.

Würden Sie so freundlich sein, mehr Details zu Ihrem Problem zu geben?

@frnco , nicht sicher, ob ich verstehe, worüber Sie mehr Details build-only könnte dieses Problem lösen

@ekkis Ich schlage vor, Sie werfen einen Blick auf # 963, scheint verwandt mit dem, was Sie suchen.

+1 für Option 2

+1 für Option 2

+1 für Option 2

+1 für Option 2

+1 für Option 2

+1 für Option 2

: +1: für Option 2 mit einer Frage zu einer Schätzung dieser Funktion? Was ist die beste Problemumgehung? Soweit ich mir vorstellen kann, müssen alle meine Dienste aufgelistet werden wie:

docker-compose up service1 service2 service3

... und lassen Sie diejenigen weg, die ich nicht standardmäßig starten möchte

Gibt es eine Möglichkeit, wie wir in der Open Source-Community dazu beitragen können, diese Funktion bereitzustellen, die stark nachgefragt zu sein scheint?

+1 für Option 2.
Eine Möglichkeit, "Bühne" anzugeben, wäre großartig. Angenommen, der Dienst wird nur in der Produktion ausgeführt.

+1 für Option 2.

Stimmen Sie für Option 2 ab

up Befehlsfilterung ist perfekt - docker-compose up service1 service3

: +1: für die Optionen 2 und 4

An diesem Punkt scheint es offensichtlich, dass Option 2 das ist, was Benutzer wollen. Was sind die nächsten Schritte, um dies zu erreichen?

Bei +1 für Option 2 ist dieses Problem aufgetreten, in der Hoffnung, dass diese Funktionalität bereits vorhanden ist.

+1 bei Option 2

... und noch eine +1 für Option 2

+1 für Option 2

+1 für Option 2 :-)

+1 für die Optionen 2 und 4

Hallo zusammen,
+1 Option 2

IMHO ist die Option in lokalen Umgebungen sehr nützlich, wenn Sie eine Anwendung haben, die auf Mikrodiensten oder einer hexagonalen Architektur basiert. Als Entwickler kann ich nur die notwendigen Elemente für meine nächste Arbeit ausführen.

Option 2 ist diejenige, die die meisten Benutzer wünschen. Ist die Entscheidung darüber noch zu treffen oder hat die Entwicklung dazu begonnen und wird sie woanders verfolgt?

Ich denke, wenn ich die Universität in ein paar Monaten beende und mehr Zeit habe, wird es viel schneller sein, diese Funktion selbst zu implementieren (obwohl ich Python nicht gelernt habe, in dem ich denke, dass Compose geschrieben ist), aber ich habe das gesehen Eine große Anzahl von Stimmen und Anfragen für zwei Jahre, ohne einen Schritt nach vorne, und die Selbstimplementierung scheint die Lösung für die nächsten 5 Jahre zu sein (bis diese Funktion offiziell implementiert wird).

natürlich +1000 für Option 2

+1 Option 2

Würde es einen Unterschied machen, wenn ich für Option 2 stimmen würde? 'scheint unwahrscheinlich, dass es würde.

Die Kommentare hier sind in letzter Zeit bitter geworden, und es sind keine neuen Rückmeldungen aufgetaucht, weshalb ich erwäge, diesen Thread zu sperren. Bitte bleiben Sie höflich, wenn Sie hier interagieren.

Dies ist die aktuelle offizielle Position des Betreuerteams in dieser Angelegenheit. Obwohl noch geprüft wird, ob wir diese oder eine ähnliche Funktion als praktische Option hinzufügen möchten, hat sie aus den genannten Gründen keine Priorität, da andere Tools vorhanden sind, die für diese Funktion besser geeignet sind.

@ shin- Bevor wir dies sperren, kann ich klarstellen, ob die Community Entwicklungswillen hat. Würde das Kernteam es zusammenführen, wenn es den Standards des Teams entspricht? In den Threads gibt es eine Implementierung und ein Community-Mitglied, das bereit ist, sie zu vervollständigen. Sie suchten nur nach einer Bestätigung, dass dies keine Verschwendung ihrer Investition sein würde. Wenn wir Feedback bekommen können, werde ich diese Threads aufspüren, um zu sehen, ob wir dies zum Abschluss bringen können.

@ Jimzucker Nein - weil das Problem hier nicht die Implementierung ist; Eine grundlegende Implementierung würde für einen durchschnittlichen Entwickler einen halben Tag dauern. Was uns hier Sorgen macht, ist ein grundlegendes Designproblem.

1. Was ist ein Service? Ein Service ist von Natur aus ein klar definierter, lang laufender Prozess, der mit anderen Services interagiert, um eine Anwendung zu bilden. Dies ist die Grundannahme, unter der Compose arbeitet, und sie leitet unser Design für die meisten, wenn nicht alle von uns implementierten Funktionen.
2. Nach dieser Definition ist ein "Dienst, der nicht standardmäßig gestartet wird" nicht wirklich ein Dienst [1] - es ist eher eine vordefinierte Aufgabe, die in einem Container ausgeführt wird und auf die Anwendung Teil davon zu sein.
3. Daher ist es falsch (grundsätzlich beabsichtigt), es als Dienstleistung zu bezeichnen. An diesem Punkt müssen wir überlegen, einen neuen Definitionstyp in Ihrer Compose-Datei zu erstellen (ich werde es der Kürze halber "Aufgabe" nennen, die genaue Terminologie spielt hier keine Rolle).
4. Da es sich bei Aufgaben von Natur aus um kurz laufende Prozesse handelt, verwenden sie im Vergleich zu Diensten andere Optionen. Zum Beispiel können wir uns vorstellen, dass Aufgaben keine Ports verfügbar machen müssen [2]. Andererseits kann eine Option wie eine CID-Datei, die für Dienste meist sinnlos ist, für Aufgaben sehr nützlich sein.
5. In den meisten Projekten haben Aufgaben in der Regel Abhängigkeitsketten (deshalb haben wir in der traditionellen Welt ohne Container Makefiles). Daher müssen wir zumindest eine grundlegende Implementierung von Abhängigkeitsketten mit Parallelität haben und in der Lage sein, dies zu erkennen Wenn diese eine JAR-Build-Aufgabe, die immer 10 Minuten dauert, wirklich erneut ausgeführt werden muss.
6. Dann hängen einige Dienste tatsächlich davon ab, welche Aufgaben ausgeführt wurden, bevor sie gestartet werden können, was die Berechnung und den Umgang mit Abhängigkeiten noch komplexer macht.
7. Für einige Aufgaben müssen einige Dienste ausgeführt werden, um ausgeführt zu werden (z. B. Datenbankmigration).

Zu diesem Zeitpunkt ist dies ein völlig neuer Code geworden, der in Bezug auf Umfang und Komplexität wahrscheinlich mit cmake übereinstimmt oder diesen übertrifft. Aus diesem Grund haben wir uns so lange dagegen gewehrt, dies zu implementieren - zum Teil, weil Compose dafür überhaupt nicht entwickelt wurde, aber auch, weil wir [3] einfach nicht die Zeit oder die Ressourcen haben, um diese Funktion zu implementieren oder zu warten müsste werden, um wirklich nützlich für Menschen zu sein.

Hoffentlich klärt dies die Dinge ein bisschen mehr. Ich weiß, dass die Leute über die Reaktion (oder das Fehlen) auf diesen Thread verärgert und enttäuscht waren, und ich bin nicht sicher, ob dies das in irgendeiner Weise lindern wird, aber da ist es.

[1] Einige Leute erwähnen, dass sie "optionale Dienste" haben möchten, aber das ist nicht der häufigste Anwendungsfall, der in diesem Thread erwähnt wird. Die meisten Leute wollen die "Aufgabe" -Funktion, soweit ich das beurteilen kann.
[2] Ich bin sicher, dass mir jemand ein Beispiel für eine Aufgabe widersprechen wird, bei der Ports verfügbar gemacht werden müssen. Dies zeigt nur, dass die Entscheidung, welche Optionen für jeden Satz gelten, nicht trivial ist.
[3] Und an dieser Stelle meine ich "Ich", da ich der einzige Betreuer bin, der derzeit aktiv an docker-compose arbeitet.

@ Shin- Ich verstehe den Punkt. Was ich verfolge, sind "optionale Dienste" in Ihren Fußnoten und die Anwendungsfälle dafür, nicht die Idee von Aufgaben. Können wir uns irgendwie darauf einigen, wie wir diesen Punkt erreichen können, da dies der Teil des Threads war, für den ich mich einsetzen möchte und Meine Tickets auf diesem Weg wurden eindeutig zugunsten dieses Threads geschlossen. Wenn wir das von den Punkten trennen können, die Sie klar als „Aufgaben“ definiert haben, können wir Fortschritte erzielen. Wenn Leute in meiner Lektüre eine +1 für Option 2 machen, ist dies der optionale Dienst. Gerne nehmen wir dies offline, um zu diskutieren, und wir können dann zum Forum zurückkehren. Ich bin unter [email protected]

@ shin- dein Punkt # 2 ist falsch. Ein Dienst ist ein Dienst, unabhängig davon, ob er ausgeführt wird. Es gibt unzählige Anwendungsfälle, in denen abhängige Dienste das Verhalten ändern, wenn die Abhängigkeit nicht verfügbar ist, sodass Ihre Anwendungsschicht möglicherweise nicht erfordert, dass alle "Dienste" jederzeit verfügbar sind

Wenn Sie es in den traditionellsten Begriffen betrachten, denken Sie daran, dass ein Webserver ein "Dienst" ist, aber er kann heruntergefahren oder so konfiguriert werden, dass er auf einem bestimmten Host nicht standardmäßig gestartet wird, aber niemand würde ihn als etwas anderes als einen Dienst betrachten

Ich denke, viele Leute, die diese Funktion anfordern, möchten keine Aufgaben ausführen, sondern optionale Dienste. Wenn Sie beispielsweise eine Reihe von Mikrodiensten als Docker-Container ausführen und alle als ganzen Dienst bereitstellen, ändern sich möglicherweise eines Tages Ihre Anforderungen, und Sie müssen in diesem Fall nicht alle Container auf allen Servern ausführen Sie benötigen keine bestimmte Funktionalität, die in einem nicht obligatorischen Container enthalten ist.

Darüber hinaus denke ich, dass dies eine nette Funktion für die Entwicklungsumgebung ist; Wenn Sie einen Fehler in einem bestimmten Container beheben, müssen Sie nicht alle Container dafür starten.

Genau, mit einem einfachen booleschen Feld könnten wir Dienste aus der .env -Datei leicht aktivieren / deaktivieren und das Bearbeiten der yaml-Datei vermeiden.

@ekkis Ich denke, Sie verwechseln Fehlertoleranz und Entbehrlichkeit etwas. Siehe auch meine Fußnote zu diesem Thema, in der ich anerkenne, dass einige Anwendungsfälle existieren.

Jeder: Bitte beachten Sie, dass einige Dienste, die für Ihre Anwendung optional sind, bereits mit den aktuellen Funktionen möglich sind. Der empfohlene Weg, dies zu tun, besteht darin, eine separate Compose-Datei zu haben, die mit dem Flag -f ein- oder ausgeschlossen werden kann. Sie sind kein sehr überzeugendes Argument für das Hinzufügen dieser Option.

@ shin- Ich schätze es, dass Sie sich die Zeit genommen haben, diesen Dialog mit uns zu führen. Ich bin damit einverstanden, dass es mehrere Möglichkeiten gibt, dies zu tun. Da Sie mehrere XML-Dateien vorschlagen, können Sie auch eine Liste von Diensten übergeben. Diese sind jedoch nicht bequem und führen zu Benutzerfehlern, die ein operationelles Risiko verursachen. Insbesondere im Fall eines kommerziellen Produkts möchten wir eine Compose-Datei verteilen und standardmäßig das gewünschte allgemeine Verhalten erhalten und Anweisungen für erweiterte Optionen geben. Eine Datei macht all dies sowohl für Entwickler, CI / CDs als auch für die Distribution viel übersichtlicher. Das Hinzufügen von ENV-Variablen mit Standardwerten war eine große Hilfe für uns und hat die Notwendigkeit vieler XML-Dateien beseitigt. Dies ist ein weiterer Schritt zur Verwaltung einer einzelnen Datei, die die Bereitstellung beschreibt.

Gibt es irgendeine Form, in der das Kernteam bereit wäre, einen Beitrag zu diesem LMK anzunehmen?

@shin , ich habe weder auf Fehlertoleranz noch auf Entbehrlichkeit Bezug genommen. Ich habe lediglich auf die Definition eines "Dienstes" hingewiesen, nämlich, ob die Ausführung des Dienstes der Definition nicht inhärent ist oder nicht

@ shin- Ich stimme @ekkis voll und ganz zu : Nicht standardmäßig gestartet zu werden, verstößt nicht gegen die Definition, ein Dienst zu sein. Daher ist Ihr Punkt 2. eine Annahme, die nicht unbedingt wahr ist, ebenso wie die aufeinander folgenden Punkte, auf denen sie basieren die Annahme von 2.

Beispiel: Wenn ich eine Anwendung mit einer MySQL-Datenbank entwickle, definiere ich normalerweise einen zusätzlichen _service_ phpmyadmin . Dies ist ein echter Dienst: lang laufende, exponierte Ports, abhängig von anderen Diensten.
Aber ich möchte diesen Dienst nicht standardmäßig starten, sondern nur auf Anfrage in der Entwicklung.
Derzeit wird mir dies klar, indem ich diesen Service in ein zusätzliches docker-compose.yml und ihn starte, indem ich beide Dateien für docker-compose bereitstelle - genau wie Sie oben vorgeschlagen haben.

Ja, es gibt bereits Möglichkeiten, dies zu erreichen. Sei es durch Aufteilen der Dienste in mehrere Dateien oder einfach durch Verwenden eines anderen Tools als docker-compose . Aber wie ich schrieb schon oben : Dieses Problem ist nicht über eine völlig neue Funktion / Funktionalität oder ein neues Konzept (dh _tasks_) , sondern über Bequemlichkeit, vor allem in Entwicklungsumgebungen.
Das Eingeben von docker-compose -f docker-compose.yml -f docker-compose-tools.yml up ist alles andere als bequem und daher hält docker-compose seine eigenen Versprechen nicht ein :

Zusammen bieten diese Funktionen Entwicklern eine bequeme Möglichkeit, mit einem Projekt zu beginnen. Compose kann eine mehrseitige Anleitung für eine einzelne maschinenlesbare Compose-Datei und einige Befehle reduzieren .

Welche Dienste gestartet werden sollen oder welche yml -Dateien in welcher Umgebung verwendet werden sollen, finden Sie normalerweise in der _Multi-Seite „Leitfaden für Entwickler - Erste Schritte“ _ - falls überhaupt ...

Meiner Meinung nach und wie @jimzucker schrieb, sind die meisten +1 hier eher für "optionale Dienste" als für ein neues Konzept von Aufgaben. Zumindest sind alle besser dran mit einem einfachen Booleschen Wert, um einen Dienst zu kennzeichnen, der standardmäßig gestartet werden soll oder nicht.

Wie mein PoC zeigt, ist die erforderliche Codeänderung - für "optionale Dienste" - recht überschaubar und bietet den meisten Menschen hier einen enormen Komfortvorteil. Option 2 - gelesen als "_Möglichkeit zum Markieren eines Dienstes optional_" - ist ein vernünftiger Kompromiss zur Lösung dieses Problems.

@ shin- würden Sie nicht zustimmen, dass es ihnen sehr helfen würde, Benutzern die Möglichkeit zu geben, Dienste als optional zu markieren - aber sie sind immer noch Dienste -?
Würde dieses Problem / eine Pull-Anfrage dafür akzeptiert und zusammengeführt, wenn es auf "_services_ als optional markieren / nicht standardmäßig gestartet" reduziert wird?

@shin , um @acrans obigen Punkt zu ergänzen, Verwendung von Namen ausgeführt werden . Bedenken Sie, dass ich jedes Mal, wenn ich "up" mache, eine Reihe von "Services" mit den Namen project_app_1 , project_otherapp_1 usw. bequem

@acran

Würden Sie nicht zustimmen, dass es ihnen sehr helfen würde, Benutzern die Möglichkeit zu geben, Dienste als optional zu kennzeichnen - aber sie sind immer noch Dienste?

Ich bin mir nicht einig, wie viel es helfen würde - ich denke, "stark" ist überbewertet. In Ihrem Beispiel ist es nicht aufwändiger oder komplexer (nur in Bezug auf Anweisungen "Entwicklerhandbücher"), nur ein docker-compose.phpmyadmin.yml , das optional enthalten sein kann, als eine Umgebungsvariable festzulegen oder eine Dienstdefinition in der Hauptdatei zu ändern.
Ich denke auch über den Kompromiss nach, Entwicklern

Würde dieses Problem / eine Pull-Anfrage dafür akzeptiert und zusammengeführt, wenn es auf "Dienste als optional markieren / nicht standardmäßig gestartet" reduziert wird?

Siehe oben - Sobald diese Funktion verfügbar ist, werden sie von Menschen für andere Zwecke als den beabsichtigten Zweck verwendet und erwarten, dass wir ein neues Feature-Set implementieren, um sie zu unterstützen. Auch cc @jimzucker ; Ich kann mir derzeit keine Implementierung vorstellen, die verhindern würde, dass sich dieses Szenario entfaltet. Wenn ich könnte, wäre dieses Problem vor langer Zeit geschlossen worden.

@ekkis Wenn Sie diese Dienste niemals selbst starten möchten, warum genau ist es dann ein Problem, sie in einer separaten Datei zu isolieren? Ich bin wirklich verwirrt darüber, warum dies hier so ein Auflegen ist.

@shin Wenn eine docker-compose.yml zum Erstellen eines Dienstes verwendet werden kann, ist dies ein äußerst nützliches Tool zur Zentralisierung meines Erstellungsprozesses. Es macht tatsächlich sehr viel Sinn, dass ich (bedingt) einen Dienst erstellen möchte, bevor ich ihn ausführe, und ich begrüße diese Funktionalität

Die Docker-Compose-Datei ist also auch mein Makefile . Aber nur weil ich etwas baue, heißt das nicht, dass ich es ausführen möchte. Für Docker-Compose macht es keinen Sinn anzunehmen, dass ich einen Dienst ausführen, einen Namen dafür erfinden und ihn ohne die richtigen Parameter / Umgebungsvariablen / etc. ausführen möchte.

Ehrlich gesagt bin ich mir nicht sicher, ob ich den Einwand gegen diesen einfachen Patch verstehe. es wäre sehr nützlich für mich

In meinem früheren Beitrag habe ich klar darauf hingewiesen, warum die offizielle Position des Teams darin bestand, dass Sie Ihre Compose-Datei nicht als Makefile verwenden sollten. Wenn Sie glauben, dass wir diesbezüglich falsch liegen und dies dennoch tun möchten, ist dies Ihr Vorrecht, aber es ist etwas absurd, darauf zu bestehen, dass wir Funktionen hinzufügen, um dies zu unterstützen.

@Schienbein-

In Ihrem Beispiel ist es nicht aufwändiger oder komplexer, nur eine docker-compose.phpmyadmin.yml zu haben, die optional enthalten sein kann (in Bezug auf Anweisungen "Entwicklerhandbücher"), als eine Umgebungsvariable festzulegen / eine Dienstdefinition in der Hauptdatei zu ändern.

Eigentlich habe ich noch nicht darüber nachgedacht, Umgebungsvariablen hier einzubeziehen. Mein gewünschter Workflow "optionale Dienste" würde schließlich Folgendes ermöglichen:

• Ich kopiere / klone ein neues Projekt
• Ich sehe, dass eine (einzelne) docker-compose.yml -Datei darin enthalten ist. Daher weiß ich, dass ich nur docker-compose up ausführen muss und die Anwendung erstellt und ausgeführt wird
• Jetzt möchte ich einen der optionalen Dienste für Entwicklungszwecke starten (z. B. zusätzliches Debugging, phpMyAdmin). Alles was ich tun muss ist docker-compose up phpmyadmin .

Für mich ist dies viel bequemer als die Verwendung mehrerer docker-compose.yml -Dateien, und wie ich für die meisten anderen Leute hier auch verstehe. Der Vorteil von "optionalen Diensten" ist hier

• für den Entwickler, der nichts zwischen mehreren Dateien duplizieren oder sorgfältig überlegen muss, welche Definitionen in welche Datei eingefügt werden sollen, sondern nur ein boolesches Flag ( auto_up: false ) für einen Dienst setzen muss
• für den Benutzer, der nicht wissen / sich merken muss, welche Dateien für welche Dienste enthalten sein sollen: muss ich ausführen
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml up oder sogar
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ?
  
  
• Stattdessen muss der Benutzer nur wissen, dass es einen Dienst namens phpmyadmin und der Benutzer sofort weiß, wie er ihn starten soll.

Siehe oben - Sobald diese Funktion verfügbar ist, werden sie von Menschen für andere Zwecke als den beabsichtigten Zweck verwendet und erwarten, dass wir ein neues Feature-Set implementieren, um sie zu unterstützen

Verstehen Sie mich nicht falsch, ich verstehe Ihr Anliegen hier nicht nur, sondern stimme dem zu: Es wird immer Benutzer geben, die diese - oder jede andere (!) - Funktion so biegen, dass sie zu ihren gewünschten Workflows passt, obwohl die Funktionen nie dazu gedacht waren so verwendet.
ABER für jede Anfrage zu "optionalen Diensten", bei der Funktionen einer "Aufgabe" fehlen, können Sie leicht argumentieren, dass Dienste keine Aufgaben sind und Aufgaben zuerst als neues Konzept eingeführt werden müssen und daher (noch) nicht unterstützt werden. Das heißt, mehr als nur das Markieren eines Dienstes als optional ist ein Schritt in Richtung des Aufgabenkonzepts (z. B. Option 4), und es gibt einen klaren Unterschied zwischen diesen.

Mit der Funktion, einen _service_ als optional zu markieren, befinden wir uns immer noch auf der rechten Seite dieses Schnitts. "Die Funktion an sich ist nicht zu komplex zu implementieren, aber sie könnte Benutzer dazu verleiten, sie falsch zu verwenden." Derzeit ist das einzige echte (obwohl gültige!) Argument, das gegen diese Funktion spricht, als Grund für die Nichtimplementierung ziemlich unbefriedigend - zumindest für die Benutzer, die viel Komfort daraus ziehen könnten, wenn sie es richtig verwenden ™.

Ich bin bereit, meine Pull-Anfrage Nr. 3047 an den aktuellen Master weiterzuleiten und alle erforderlichen Polierarbeiten durchzuführen, damit dies akzeptiert wird. Bitte lassen Sie es mich wissen.

Mein Anwendungsfall ist, dass wir weder alle unsere Bilder an den Docker-Hub oder -Kai senden, noch über eine eigene Registrierung verfügen. Wenn wir einen Dienst als nicht standardmäßig ausführbar markieren können, können wir dies Lassen Sie ein Basis-Image in docker-compose.yml , das nicht gestartet wird, und dann andere Container, die dieses verwenden oder darauf aufbauen.

Ich würde gerne eine docker-compose -Gabel verwenden, die diese Funktion nur für diese einzigartige Funktion implementiert.

@ shin- Obwohl ich denke, dass wir alle Ihren Standpunkt verstehen und damit sympathisieren, denke ich nicht, dass "es könnte missbraucht werden" ein gutes Argument für etwas mit - eindeutig - vielen brauchbaren Anwendungsfällen ist. Natürlich wird es missbraucht. Genau so wachsen Software und neue Ideen. aus dem Einsatz von Technologie nicht ganz so, wie es sein sollte. Das Web wäre nicht das, was es heute ist, wenn wir in den letzten 25 Jahren nicht alle bereitgestellten Technologien missbraucht hätten.

Wie auch immer.
Ihrer Meinung nach - vereinfacht - ist der Unterschied zwischen einem Service und einer Aufgabe die Lebensdauer. Es macht Sinn, und ich verstehe, dass Sie sie als zwei verschiedene Konzepte betrachten und glauben, dass es sich um eine potenzielle Dose Würmer handelt. Diese Unterscheidung wird jedoch in der Dokumentation nirgends geklärt oder erläutert. Es wird auch nirgends darauf hingewiesen, dass Docker nicht dazu gedacht ist, zeitliche Prozesse in Gang zu setzen.
Was ich damit sagen will ist, dass wenn das Docker-Team eine starke Haltung dazu hat, dies von Anfang an klargestellt werden sollte.
Ebenfalls. Aufgabe oder Dienst, es gibt eindeutig eine Überschneidung. Und das Markieren eines Dienstes als optional gehört definitiv nicht nur zur Aufgabenseite.
Aus praktischer Sicht stimme ich @acran definitiv zu - eine einzelne Docker-Compose-Datei ist weitaus besser als DX, vereinfacht viel und ist weniger fehleranfällig als mehrere Docker-Compose-Dateien.

Hehe, ich erinnere mich an die heftigen Diskussionen, die wir geführt haben, als wir uns dafür eingesetzt haben, dass "Browser" Bilder anzeigen können. Das Hauptargument der Gegner ist, dass es als Hyper- Text- Übertragungsprotokoll bezeichnet wird.
Entschuldigung für die OT-Erinnerungen an einen alten Furz.

@ shin- Wenn das Docker-Compose nicht als Makefile verwendet werden soll, sollte es keine Makefile-Funktionalität bieten. Wenn es mir erlaubt, meine Projekte zu erstellen (bravo!), dann ist es lächerlich, die Position einzunehmen, dass es kein Makefile ist

@ shinlook, ihr müsst keine Funktion implementieren, die ihr nicht wollt, egal wie unvernünftig eure Gründe sind oder wie nützlich die Funktion ist. Es ist nur so, dass es das Tool für diejenigen von uns, die es verwenden, weniger nützlich macht. Wir sind die Benutzer, wir kennen die Anwendungsfälle - und Tools sind nur so nützlich und wertvoll, wie sie für Anwendungsfälle geeignet sind

Dies ist für mich nur eine kleine Irritation. Ich muss manuell eine Menge Dinge töten, die ohne guten Grund entstehen, jedes Mal, wenn ich meine Dienste in Anspruch nehme. für andere kann es ein Hindernis sein, die Reizung wird in der Schwere variieren

Ich verstehe, dass die offizielle Position ist, dass wir Dobi verwenden sollten, auch wenn es für das, was wir brauchen, übertrieben ist. Diese offizielle Position erklärt jedoch nicht die Grundlage für Ihre Zurückhaltung, eine nützliche PR zu akzeptieren. Wir können dobi immer noch verwenden, wenn die Nachfrage nach Docker-Compose zu groß ist oder die Überlappung für die Migration ausreicht, aber dies ist eine sehr kleine Änderung, die unser gesamtes Leben viel besser machen würde

und im Übrigen bin ich nicht "bitter", aber den Faden zu sperren, um weitere Diskussionen zu verhindern, wäre einfach undemokratisch und autoritär. Open Source basiert auf dem Prinzip der Offenheit und ich wäre traurig zu sehen, dass dieses Projekt mit Zensur und diktatorischer Taktik verwaltet wird

@rysiekpl Dies ist ein Problem, das wir auf andere Weise lösen https://github.com/docker/cli/pull/452 (sobald die Syntax überlegt ist, wird es in Compose und v2 as aufgenommen Gut)

@creynders Ich denke, das ist eine Art Fehlcharakterisierung - niemand sagt, dass optionale Dienste nicht existieren sollten (und tatsächlich gibt es, wie ich bereits <img> -Tags gültig ist und ob unser spezifischer Browser dies unterstützen sollte oder nicht.

Auch zu Ihrem Punkt:

Diese Unterscheidung wird jedoch in der Dokumentation nirgends geklärt oder erläutert. Es wird auch nirgends darauf hingewiesen, dass Docker nicht dazu gedacht ist, zeitliche Prozesse in Gang zu setzen.

Dies ist eigentlich der erste Absatz der Seite https://docs.docker.com/compose/overview/ (Hervorhebung von mir):

Compose ist ein Tool zum Definieren und Ausführen von Docker-Anwendungen mit mehreren Containern. Mit Compose verwenden Sie eine Compose-Datei, um die Dienste Ihrer Anwendung zu konfigurieren. Anschließend erstellen und starten Sie mit einem einzigen Befehl

@ekkis Ich bin wirklich froh, dass Compose tatsächlich für Ihre Projekte hilfreich ist! Ich hoffe, dass ich bei all dem nicht als unaufrichtig abschneide. Es ist absolut in Ordnung, wenn Sie die Software so verwenden möchten. Was ich jedoch sage, ist, dass eine weitere Weiterentwicklung in diese Richtung es auf lange Sicht wahrscheinlich noch schlimmer machen würde. Wir alle wissen, was mit Anwendungen passiert, die versuchen, zu viele Dinge zu tun (obwohl Emacs es wohl geschafft hat: stecken_out_tongue :)

Ich glaube nicht, dass ich "autoritär" war, aber vielleicht habe ich mich nicht richtig ausgedrückt. Meine Absicht war es, die Menschen zu ermutigen, in ihren Interaktionen höflich und positiv zu bleiben. Der Thread ist immer noch entsperrt und bleibt so lange bestehen, wie die Leute nicht gemein oder unhöflich sind.

Sie erstellen und starten alle Dienste aus Ihrer Konfiguration.

und ich denke, unsere Behauptung ist, dass "create and / or start" hätte lauten sollen, obwohl man, um der Sprache gerecht zu werden, den OP nicht angeben muss, weil er im AND impliziert ist. Mit anderen Worten, es ist wahr, dass Sie einen Dienst erstellen und starten können, aber es gibt keine Implikation, dass er beides tun muss

Wir alle wissen, was mit Anwendungen passiert, die versuchen, zu viele Dinge zu tun

Ja, ich kann verstehen, dass Sie die Grenzen der Domain verwalten

Ich glaube nicht, dass ich "autoritär" war

Ich liebe die Open Source Bewegung. Wir können unsere Meinungsverschiedenheiten haben, aber wir sind immer noch zusammen. Die Kriege innerhalb der Bitcoin-Community waren entsetzlich und ich glaube, ich schwanke immer noch davon. Vielen Dank, dass Sie auf der Seite der Höflichkeit bleiben

Als Abschiedsgedanke würde ich Sie bitten, https://github.com/docker/compose/issues/4650 erneut zu überprüfen. Dies entspricht nicht der Anforderung in diesem Thread (wie Sie beim Schließen angegeben haben), entspricht jedoch meiner Verwendung Fall, nämlich dass das hier diskutierte Flag nicht binär, sondern trinär ist

Die Idee, mehrere Dateien zu definieren, gefällt mir sehr gut. Das Einbeziehen aller Dateien mit Multi -f einschließlich des Originals scheint jedoch ein totaler Overkill zu sein.

Es gibt tatsächlich einen praktischeren Weg, der für mich funktioniert (siehe PS unten): Setzen Sie alle Dienste, die Sie nicht ausführen möchten, in docker-compose.override.yml . Und verwenden Sie docker compose -f docker-compose.yml up für den normalen Start (beachten Sie, dass dies ein einmaliger Befehl ist). Bei allen aufeinander folgenden Anrufen wird die Außerkraftsetzung ...

Insgesamt ist das alles sehr unintuitiv und etwas unbefriedigend. Hinzufügen eines zusätzlichen:

• Eine Option zum Deaktivieren von Diensten ist insbesondere bei komplexeren Überschreibungen sinnvoll

• Die Option -f ist minimal, aber nicht sehr intuitiv. Eine weitere Option -F <name> , die nur zusätzliche Überschreibungen hinzufügt, wäre sehr willkommen (dh Docker-Compose)..yml. Eine Alternative wäre die Verwendungals Verzeichnis, in dem alle .yml -Dateien gespeichert sind: Zusammen mit Symlinks wäre dies ähnlich leistungsfähig wie /etc/apache/sites.available -> /etc/apache/sites.enabled

Auf der anderen Seite: Jeder kann ein Simpe-Wrapper-Skript (Funktion) für seine Shell bereitstellen, um dieses Verhalten zu emulieren ...

PS: Mein Anwendungsfall ist, dass ich einen Debugger als Service definiere. Offensichtlich wird dieser Dienst nicht immer benötigt, aber die Links (auch aus Sicherheitsgründen) müssen korrekt funktionieren.

Ein weiterer Anwendungsfall, für den Option 2 großartig ist:

Angenommen, Sie haben ein Team von Mitarbeitern, die an demselben Projekt arbeiten. Einige von ihnen haben Zugriff auf von AWS verwaltete Services, andere müssen die entsprechenden Ressourcen als lokale Container ausführen. Abhängig von meinem Workflow benötige ich entweder immer oder nie Redis- und MySQL-Container in meiner Compose-Konstellation.

Ich werde sagen, dass das Verwalten mehrerer Compose-Dateien für diesen Anwendungsfall dumm ist. Das Ausmaß der Überlappung ist komisch. Das Verwalten mehrerer Dateien ist eine Fußwaffe - sie werden nicht mehr synchron sein und Verwirrung stiften. Ich bin ehrlich gesagt ein bisschen schockiert, dass jemand diese Option für jeden Anwendungsfall ernst genommen hat.

Die Möglichkeit, Dienste schnell zu aktivieren und zu deaktivieren, ohne große Konfigurationsblöcke auskommentieren zu müssen (umständlich in YAML, sehr unordentlich, wenn sie versehentlich festgeschrieben werden), ist für sich genommen großartig. Wenn Compose jedoch eines Tages die Möglichkeit erhält, Variablen in die Konfiguration zu interpolieren, wird diese Funktion automatisch exponentiell leistungsfähiger. Bis dahin ist es verdammt nützlich.

Stimmen Sie @campadrenalin voll und ganz zu.

Soweit ich weiß, handelt es sich bei dieser gesamten Diskussion im Grunde genommen um eine große Anzahl von Personen, die eine große Anzahl sehr guter Gründe für die Implementierung von Option 2 liefern, und die Entwickler lehnen dies ab, da jemand möglicherweise hypothetisch die Existenz dieser Funktion falsch interpretieren und andere nicht verwandte Funktionen anfordern könnte .

OT:

Wenn Compose jedoch eines Tages die Möglichkeit erhält, Variablen in die Konfiguration zu interpolieren, wird diese Funktion automatisch exponentiell leistungsfähiger.

Ist diese Funktion nicht schon lange verfügbar? Siehe https://docs.docker.com/compose/compose-file/#variable -substitution. Ich verwende es, um die Anpassung unserer Compose-Entwicklungsumgebung mithilfe der Datei .env - z. B. Speicherort des Quellcodes, Portzuordnung usw. Seit der Version 2.1 der Compose-Datei ist sogar die Standardvariable im Shell-Stil ( ${VARIABLE:-default} / ${VARIABLE-default ) wird unterstützt.

Soweit ich weiß, handelt es sich bei dieser gesamten Diskussion im Grunde genommen um eine große Anzahl von Personen, die eine große Anzahl sehr guter Gründe für die Implementierung von Option 2 liefern, und die Entwickler lehnen dies ab, da jemand möglicherweise hypothetisch die Existenz dieser Funktion falsch interpretieren und andere nicht verwandte Funktionen anfordern könnte .

Ich finde, dass dies - vielleicht ein bisschen hart im Ton, aber im Wesentlichen gültig - eine sehr gute Zusammenfassung von @rysiekpl ist.
Also, @ shin-, sind wir einer Entscheidung in Bezug auf dieses Problem näher gekommen? Ob Sie es einfach schließen oder eine PR für Option 2 implementieren / akzeptieren möchten?

Ich sehe und verstehe Ihre Bedenken vollkommen, sehe aber auch, dass die Vorteile das Risiko überwiegen, dass jemand dies möglicherweise missbraucht, da es sich um eine eher kleine Änderung handelt, aber vielen Menschen viel mehr Möglichkeiten für viel bequemere Arbeitsabläufe bietet.

Da Docker-Compose auf lange Sicht ohnehin zugunsten des Docker-Stacks fallen gelassen wird, schlage ich vor, dass alle so schnell wie möglich auf das neue v3-Format und das docker stack -Tool umsteigen.

Mit einem Stapel auf einem Schwarm (sogar auf 1 Knoten) können Sie Folgendes angeben:

        deploy:
            mode: replicated
            replicas: 0

Wenn keine Replikate vorhanden sind, kann der Dienst im Wesentlichen nicht ausgeführt werden.

Sie benötigen nur ein anderes Tool, um diese XML-Datei zu generieren, wenn Sie Umgebungsvariablensubstitutionen wie envsubst anwenden möchten.

Sie können dann einen Platzhalter in Ihrem yml verwenden:

        deploy:
            mode: replicated
            replicas: ${R}

Und verarbeite es so:

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

Also, wenn docker-compose auf lange Sicht veraltet sein wird, was genau ist das Problem beim Zusammenführen der Pull-Anfrage, die bereits da draußen ist ? Ich meine, wenn docker-compose den Weg des Dodos geht, wie ist "jemand wird seltsame Funktionen anfordern" ein echtes Problem?

Da Docker-Compose langfristig zugunsten des Docker-Stacks fallen gelassen zu werden scheint

Also, wenn Docker-Compose auf lange Sicht veraltet sein wird

warte, wat? docker-compose ist für viele Menschen von zentraler Bedeutung für ihren Entwicklungsworkflow, für den kaum ein Schwarmmanager erforderlich ist. Könnten Sie mich auf eine offizielle Erklärung von Docker zu diesem Thema hinweisen?

Ich könnte das falsch lesen, aber es klingt so, als ob Docker-Schwarm und Docker-Stack eng mit Docker-Cloud-Diensten verbunden sind. Sind diese Dinge auf einem eigenständigen Offline-System konfigurierbar?

Sind diese Dinge auf einem eigenständigen Offline-System konfigurierbar?

Ja, Sie können sie offline verwenden.

Für mich sieht es so aus, als würden Stapel auf Docker-Schwarm irgendwann eine Obermenge der Funktionen von Docker-Compose sein. Ich denke, die Deskriptordateien sind bereits sehr ähnlich. Hoffentlich wird dieser Übergang nicht zu schwierig sein. Der größte Ärger, den ich sehen kann, ist die Verwaltung des Schwarms getrennt von den Stapeln. Mehr Overhead-Arbeit für mich, da ich kein Interesse daran habe, zusammengesetzte Anwendungen auf mehr als einem Knoten auszuführen.

Oder vielleicht verstehe ich alles falsch ...?

+1 bei Option 2!
Und ich denke, dass der Tropfen Docker, der zugunsten des Schwarmstapels komponiert, ein großer Nachteil für die Community sein wird. Docker Compose ist so einfach und benutzerfreundlich !!

@ tberne Ich stimme dem zu. Docker-Compose ist einfach und einfach ist eine gute Sache. wir sollten abstimmen, um es zu behalten

Heh, was für eine ausführliche Diskussion! Achten Sie nicht besonders auf diesen Kommentar, nur auf meine zwei Cent.

Zuerst stimmte ich der Mehrheit zu, nur eine Art enabled -Flag hinzuzufügen.
Dann sah ich einen Vorschlag, Definitionen nach Gruppen zu verzweigen, und hielt ihn für eine gute Idee.
Dann las ich über Dobi, versuchte es, stellte sicher, dass es momentan nicht in meinem Projekt verwendet werden kann und las weiter.
Dann las ich die Argumente von @ shin- und hielt sie für gut genug, obwohl ich auch einigen Gegenargumenten zustimmte.

Meine aktuelle Lösung besteht darin, einige Docker-Compose-Yamls zu erstellen und einige Bash-Wrapping-Skripte zu schreiben, um Docker-Compose nicht von Hand auszuführen.

So führe ich beispielsweise Container aus, auf denen eine Website ausgeführt wird ( ./docker/scripts/up script):

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

Big +1 für Option 2 oder 3.

+1 für Option 2 oder 3.

Auch das vorgeschlagene "Gruppen" -Konzept klingt interessant!

+1 für Option 2

_Es gibt so viele +1 on option x , dass ich nicht einmal die ursprüngliche Aussage finden kann. Bitte benutzen Sie stattdessen die Reaktionsschaltflächen unter Beiträge._

So fügen Sie eine neue Idee hinzu:

Können wir nicht einfach eine Standardskala auf 0 ?

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

Sie sollten nur Option 2 ausführen (aber vielleicht stattdessen Nostart oder so), weil die Leute schon seit Jahren warten, und dann Docker-Compose mit ihren eigenen Konfigurationsmanagern verpacken, weil das Tool zu begrenzt ist, was den Punkt zunichte macht, da es das tut, was Docker-Compose tun sollte tun. In zwei Jahren könnte jemand auch seine eigene leistungsstärkere Docker-Komposition erstellen. Das ist viel Zeit, für die diese Ausgabe offen war.

Auf lange Sicht sollte eine echte Gruppierung von Optionen in Betracht gezogen werden. Einige sind nur zum Erstellen relevant, andere nur zum Ausführen und andere sind gegenseitig (Sie möchten wirklich eine Verschachtelungsebene, zumindest zum Ausführen oder einfach trennen und einen Erstellungsabschnitt haben, Problem gelöst). Obwohl viele Dinge in der Konfiguration problematisch sind, bin ich alle dafür, alles in Version 5 neu zu erstellen, aber es zu diesem Zeitpunkt richtig zu machen (hauptsächlich indem ich das Reale auf technischer Ebene darstelle, anstatt zu versuchen, es einer Verwendung zuzuordnen basierend auf einer Domäne oder zu einfach, erstellen Sie stattdessen eine Konfigurationsebene für diese Ziele über der richtigen (Sie können dies nicht umgekehrt tun). Ich denke, aufgrund dieses Zustands ist die schnelle Lösung gerechtfertigt.

+1 für Option 2 oder 4

Wenn derzeit keine Pläne zum Hinzufügen dieser Funktion vorhanden sind, möchte ich, dass die Art und Weise, wie solche Dienste (oder Aufgaben) in einer Komposition ausgeführt werden, in den Dokumenten von docker-compose geschrieben ist.

Dies ist ein alter Thread, und ich stimme zu, dass docker-compose nicht um _services kümmern soll, die nicht von Anfang an_ ausgeführt werden.

Aber ich füge normalerweise auch einen test -Dienst hinzu, also habe ich Folgendes getan:

1. Überschreiben Sie die entrypoint des Dienstes.

2. Überprüfen Sie im neuen entrypoint , ob ein tty verfügbar ist ( docker-compose run verwendet standardmäßig --tty während up dies nicht tut).

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   Dadurch wird der Dienst immer beendet, wenn er ohne tty (z. B. mit docker-compose up ), während er weiterhin wie erwartet mit docker-compose run

@paulodiovani Das sieht eher nach einem Hack als nach einer Lösung aus.

+1 für eine Funktionsanforderung.
Hacks wie Befehle, die nichts bewirken, bedeuten, dass der Container, selbst wenn er nicht ausgeführt wird, noch erstellt, initialisiert usw. werden muss.

Ich habe dies in meinem Projekt gelöst, indem ich ein einfaches Bash-Skript bereitgestellt habe, das den entsprechenden Befehl docker-compose basierend auf den angegebenen Argumenten aufruft.

Wenn ich jetzt ./docker-compose.sh -e testing up mache, ist das Ergebnis dasselbe, als hätte ich docker-compose -f docker-compose.yml -f docker-compose.testing.yml up .
Wenn ich nur ./docker-compose.sh up mache, bekomme ich, wie zu erwarten, reguläre docker-compose up .

Daher ist meine Option -e ${environment} (eine Abkürzung für --env ) im Grunde ein Alias ​​für -f docker-compose.yml -f docker.compose.${environment}.yml . Dies führt dazu, dass docker-compose.yml die Basis- / Standard-Compose-Datei ist und Dateien wie docker-compose.testing.yml die Erweiterungen sind.

Dies löst das Problem von @acran , dass der Benutzer nicht weiß, welche Dateien (und in welcher Reihenfolge) in den Befehl docker-compose indem er vernünftige Standardeinstellungen erzwingt. Es ist keine sehr robuste Lösung, da einige möglicherweise komplexere Kombinationen von Kompositionsdateien verwenden, aber ich denke, docker-compose sollte in der Lage sein, etwas Ähnliches zu tun. Die meisten docker-compose -Dateien beginnen wahrscheinlich mit docker-compose. und enden sowieso mit .yml Warum muss ich also immer einen so langen Befehl eingeben ( docker-compose -f docker-compose.yml -f docker-compose.testing.yml up ) Wenn ich nur einen einzigen zusätzlichen Service für meine Testumgebung benötige?

Envsubst ist nicht erforderlich. Docker-compose config führt die Umgebungsvariablen aus und Docker-Stack übernimmt sie von stdin:

docker-compose config | docker stack deploy --prune --compose-file -

Lassen Sie uns auch die Docker-Compose .env-Ersetzungen verwenden.

@kogli Ich denke, das Problem hier ist, eine Option auszuwählen. Alle haben Vor- und Nachteile. Wie ich bereits gesagt habe:

Jede Lösung ist für einige Anwendungsfälle besser und für andere schlechter (oder sogar nutzlos). Wenn das Etwas implementiert ist, halten die Mantainer es für immer, also glaube ich, dass sie klug sind, sich Zeit dafür zu nehmen.

@ shin- Ich denke, du bist derjenige, der fragt: Ist es überhaupt sinnvoll, dies zu berücksichtigen? Wäre es angesichts der aktuellen Position des Teams, der Schwierigkeit, es zu entwerfen, und der vielen Tools da draußen nicht einfacher, den Leuten einfach zu sagen, dass dies nicht passieren wird? Die meisten Leute, wenn nicht alle, die hier kommentierten, fanden einen Weg, damit umzugehen.

Das Schließen scheint ziemlich gut zu sein, und Sie können sich auf das Wesentliche konzentrieren, und niemand fragt sich, ob er eine Pull-Anfrage stellen sollte und wie er all diese Anforderungen gleichzeitig erfüllen kann. Sie können einfach etwas anderes bauen und es vielleicht sogar veröffentlichen, um anderen zu helfen.

Nur zur Veranschaulichung: Meine Lösung war nicht perfekt, aber viel besser als die 2 Tage, die ich gebraucht habe, um die Abhängigkeiten zu installieren, eine Menge Dinge zu reparieren und das Projekt zum Laufen zu bringen (und Docker wurde bereits verwendet). Nur 3 Befehle, wobei Docker und Docker Compose die einzigen Abhängigkeiten sind. Ja, es gab mehr Code als ich wollte. Ja, es gibt einen beschissenen Befehl, Befehle auszuführen. Und ja, es gibt noch ein kleines bisschen mehr zu beachten. Eine Wiki-Seite deckte diese ab. Sehr gut, wenn ich es selbst sage, was bedeutet, dass Docker Compose seinen Job gemacht hat , brauchte ich nur

Der Punkt ist: Wenn es außerhalb des Rahmens liegt, ist es Zeitverschwendung, weiter darüber zu diskutieren. Viele Leute hören hier einfach auf, um danach zu fragen und ihre Meinung zu äußern, bevor sie versuchen zu entscheiden, was zu tun ist. Sie werden immer noch etwas anderes finden oder bauen, wenn dies geschlossen ist, nur schneller. Und du bekommst einen Thread weniger zum Babysitten.

Bearbeiten: Ich habe mir nur einen guten Weg ausgedacht, um es auszudrücken: Wenn es keine klaren Kriterien für die Akzeptanz von PR gibt und niemand im Kernteam daran beteiligt ist oder plant, es in absehbarer Zukunft zu betrachten, ist es kein " Problem ", nur eine Idee.

Ich sehe keinen Grund, die Themenliste zu überladen. Ich glaube, viele Ideen hier sind gut, aber ich denke, sie gehören woanders hin, zum Guten oder zum Schlechten. Es sind fast drei Jahre vergangen, und wenn sich die Situation eines Tages ändert, können Sie diese jederzeit wieder öffnen oder eine neue Ausgabe darüber eröffnen.

Die Implementierung dieser Funktion dauert etwa einen Tag, da sie sehr einfach ist. Nach 2 Jahren Diskussion jedoch immer noch nichts. Traurig.

@rubycut Ja, das passiert, wenn sogenannte "höhere Prinzipien" die Benutzerfreundlichkeit und Benutzerfreundlichkeit ersetzen. Ich verstehe vollkommen, dass die Entwickler das Produkt nicht mit unlogischen Merkmalen verstopfen wollen. Diese besonders begehrte Funktion scheint jedoch tatsächlich sinnvoll zu sein. Es ist traurig, wenn die Entwickler glauben, sie wissen es besser als ihre Benutzer. (Wieder tun sie es normalerweise. Aber nicht immer. Diesmal nicht.)

@ Rubycut Talk ist billig, zeig mir den Code. Wenn Sie können, senden Sie Ihre PR, wenn Sie nicht können, melden Sie es einfach und warten Sie.

@ Wangwenpei Willst du mich

Nur zu Ihrer Information, "der Code" ist bereits da: # 3047

@ Wangwenpei gut, # 3047, da ist die Pull-Anfrage ...
Ich warte seit über zwei Jahren darauf, zumindest ein Feedback dazu zu bekommen. Es wurde vor kurzem geschlossen

aus den unter https://github.com/docker/compose/issues/1896#issuecomment -322285976 genannten Gründen

Das ärgert mich, um ehrlich zu sein, weil die Argumente in https://github.com/docker/compose/issues/1896#issuecomment -322285976 in keiner Weise mit der Pull-Anfrage zusammenhängen:

1. Was ist ein Service? Ein Service ist von Natur aus ein klar definierter, lang laufender Prozess, der mit anderen Services interagiert, um eine Anwendung zu bilden. Dies ist die Grundannahme, unter der Compose arbeitet, und sie leitet unser Design für die meisten, wenn nicht alle von uns implementierten Funktionen.
2. Nach dieser Definition ist ein "Dienst, der nicht standardmäßig gestartet wird" nicht wirklich ein Dienst [1] - es ist eher eine vordefinierte Aufgabe, die in einem Container ausgeführt wird und auf die Anwendung einwirkt, anstatt Teil davon zu sein.

Ich sehe die Behauptung By that definition, a "service that is not started by default" is not really a service als wahr an. Ein Dienst, der nicht standardmäßig gestartet wird, ist nur ein Dienst, der nicht standardmäßig gestartet wird, nicht mehr und nicht weniger zu diesem Zeitpunkt. Standardmäßig gestartet zu werden oder nicht, sagt nichts darüber aus, ob der Dienst lange läuft oder nicht, ob er Teil der Anwendung ist oder nicht, sondern nur, dass er nicht standardmäßig gestartet werden soll.

Und genau das bewirkt die Änderung in der Pull-Anforderung: Fügen Sie die Möglichkeit hinzu, einen Dienst zu markieren, der standardmäßig gestartet werden soll oder nicht.
Es ist nicht erforderlich, ein neues Konzept wie Aufgaben einzuführen, um dies zu tun. Tatsächlich folgen alle anderen Argumente in https://github.com/docker/compose/issues/1896#issuecomment -322285976 aus der falschen Prämisse von 2. und sind daher nicht auf die Pull-Anfrage anwendbar, die nichts zu tun versucht sonst.

Nur der Vollständigkeit halber:

[1] Einige Leute erwähnen, dass sie "optionale Dienste" haben möchten, aber das ist nicht der häufigste Anwendungsfall, der in diesem Thread erwähnt wird. Die meisten Leute wollen die "Aufgabe" -Funktion, soweit ich das beurteilen kann.

Ja, es gab Beispiele für einmalige Aufgaben, aber es gab auch Beispiele für echte Dienste gemäß Ihrer Definition, dh legitime Anwendungsfälle für diese Funktion.
In der Lage zu sein, damit auch einmalige Aufgaben auszuführen, kann ich nicht wirklich als gültiges Argument dagegen akzeptieren. Es ist bereits möglich, einen _service_ zu definieren, der nicht lange läuft, keine Ports verfügbar macht und kein wesentlicher Bestandteil der Anwendung in einem vollständig gültigen docker-compose.yml .

In der Tat ist dies auch eine der vorgeschlagenen Problemumgehungen! Teilen Sie einfach die Aufgaben in ein separates docker-compose.yml .
Die anderen erwähnten Problemumgehungen bestehen darin, Ihre eigenen hausgemachten (plattformabhängigen) Skripte zu verwenden, was dem selbst erklärten Zweck des Docker-Composens völlig widerspricht, siehe meinen Kommentar oben , oder einfach zu einem anderen Tool zu wechseln, dh Ihre perfekt wegzuwerfen Gut funktionierende Toolchain, nur um diese eine winzige Funktion bequem zu machen, die leicht in Ihre aktuelle Toolchain implementiert werden kann (Docker-Compose).

Das einzige wirkliche Argument gegen die grundlegendste Implementierung von Option 2 - dh eine Möglichkeit, docker-compose anzuweisen, einen bestimmten Dienst nicht standardmäßig zu starten, und nichts weiter, keine neuen Konzepte oder irgendetwas - ist, dass dies möglich ist be_somehow_ von _some_ Benutzern missbraucht werden.
Aber dieses Argument ist ziemlich schwach im Vergleich zu der Nachfrage danach und den hier vorgebrachten legitimen Anwendungsfällen ...

@Schienbein-

aber auch, weil wir [3] einfach nicht die Zeit oder die Ressourcen haben, um zu implementieren oder zu warten, was diese Funktion benötigen würde, um für Menschen wirklich nützlich zu sein.
[3] Und an dieser Stelle meine ich "Ich", da ich der einzige Betreuer bin, der derzeit aktiv an Docker-Compose arbeitet.

Einerseits kann ich nicht verstehen, dass es nur einen aktiven Betreuer gibt, während andererseits Pull-Anfragen einfach ignoriert werden und daher jede Gelegenheit verpasst wird, andere Entwickler in das Projekt einzubeziehen.
Die in # 3047 bereitgestellten Codeänderungen implementieren bereits eine Funktion, die für [viele] Personen wirklich nützlich wäre - vielleicht nicht für alle Personen mit all ihren Anwendungsfällen, aber für die meisten Personen hier.

Alle zusätzlichen Anforderungen - völlig neue Konzepte, neues Abhängigkeitsmanagement bis hin zu einer Komplexität von cmake - müssen einfach aus einer falschen Prämisse folgen!

Ich bin erst vor ein paar Tagen auf dieses Problem gestoßen, weil ich nach einer solchen Funktion gesucht habe.

Da es leider nicht implementiert ist und soweit ich das beurteilen kann, besteht die offiziell unterstützte Alternative darin, mehrere Yaml-Dateien zu verwenden.

Nun, ich finde die Idee, mehrere Yaml-Dateien für Dienste zu verwenden, die nicht standardmäßig ausgeführt werden, eine schlechte Alternative im Vergleich zur Verwendung einer Yaml-Datei für alle Dienste, die eine zusätzliche Einstellung für jeden Dienst enthalten, der nicht standardmäßig ausgeführt wird.

Also, hier ist meine +1.