Der Projektname ist nicht wichtig. Ich mag die Idee eines zufälligen Projektnamens. Noch besser - könnten wir einen Hash des Pfades zu fig.yml generieren und diesen verwenden?

Ich denke eigentlich, dass der Projektname ziemlich wichtig ist. Wenn Sie mit den Bildern in einer CI-Pipeline etwas tun möchten, müssen Sie den Projektnamen kennen, um sie als etwas anderes markieren zu können.

Die Möglichkeit, den Projektnamen aus Umgebungsvariablen zu überschreiben, macht es einfach, diese eindeutig und vorhersehbar zu halten. Ich denke, egal was passiert, wir müssen das Überschreiben von Umgebungsvariablen unterstützen.

Ich mag die Idee, den Projektnamen aus einer Datei konfigurierbar zu machen. Ich denke, eine ähnliche Diskussion fand in (# 45) statt. Wenn der Projektname in .fig/project-name scheint dies zu vielen wirklich kleinen Dateien zu führen. Ich denke, es wäre einfacher, es einfach in das fig.yml selbst zu setzen (wie es in # 45 vorgeschlagen wird und einer der Docker Vorschläge verfasst).

Was sind die Vorteile, wenn Sie es in einem separaten Verzeichnis und einer separaten Datei ablegen?

Der Grund für das Einfügen in eine separate Datei hat mehrere Gründe. Ich werde versuchen, meine Überlegungen dahinter zu erklären.

• Um den Namen beizubehalten, der zum Starten des Projekts verwendet wurde (dh --project-name=foobar ), der sich vom automatischen Projektnamen unterscheiden kann.
• Mehrere Instanzen oder Versionen eines Projekts auf demselben Server ausführen, ohne dass sie sich widersprechen
• Kurz gesagt, .fig/project-name enthält den Namen der Instanz des Projekts.

Vielleicht sollte die Datei instance-name oder ähnlich heißen.

Ich mag die Idee, den Projektnamen aus einer Datei konfigurierbar zu machen

Obwohl es möglich ist, dies mit diesem Vorschlag zu tun (durch manuelles Erstellen der project-name -Datei), bestand mein primärer Anwendungsfall darin, dass _fig_ die Datei erstellt, um den verwendeten Namen zu speichern.

wird zu vielen wirklich kleinen Dateien führen.

Die Alternative besteht zwar darin, das Verzeichnis .fig zu überspringen. Wenn jedoch in Zukunft zusätzliche Dinge benötigt werden, können zusätzliche Dateien hinzugefügt werden, ohne das Stammverzeichnis Ihres Projekts zu überladen. Git macht es ähnlich und ich denke, es ist ein sauberer Ansatz.

Ich denke, es wäre einfacher, es einfach in die fig.yml zu setzen

Ich denke, beide Optionen können sich ergänzen. Verwenden Sie den Namen von fig.yml als Standard, wenn der Name nicht durch ein Flag oder eine env-Variable überschrieben wird. Geben Sie den Namen, der tatsächlich zum Starten des Projekts verwendet wird, in .fig/project-name

Die Möglichkeit, den Projektnamen aus Umgebungsvariablen zu überschreiben, macht es einfach, diese eindeutig und vorhersehbar zu halten. Ich denke, egal was passiert, wir müssen das Überschreiben von Umgebungsvariablen unterstützen.

Neugierig; Wie gehen Sie mit der Verwaltung mehrerer Projekte um? Dh cd project-a && fig ps dann cd project-b fig <something> ?

Vielen Dank für Ihr Feedback!

Neugierig; Wie gehen Sie mit der Verwaltung mehrerer Projekte um?

Normalerweise führe ich fig von python-tox , wodurch ich die Umgebung festlegen kann, sodass ich sie nie wirklich in meiner Shell einstelle. Ich neige auch dazu, tmux zu verwenden, daher habe ich für jedes Projekt eine andere Shells.

Ich denke, beide Optionen können sich ergänzen

Cool, ich stimme zu.

Ich weiß nicht , ob ich auf bin verkauft .fig/instance-name vs sagen .fig-instance.yml , die keine Instanz spezifische Überschreibungen enthalten könnte, aber ich denke , das ist eher ein kleiner Punkt ist.

An den Projektnamen denken; Wenn ich Ihre Situation richtig verstehe, ist es wichtig, die Kontrolle über die produzierten Bilder zu haben, z. B. myapp:build12345 oder auch die Namen der Container? Nur um ein "Gefühl" für Ihre Situation zu bekommen.

Meine Gedanken hinter "zufälligen" Projektnamen waren, dass gut aussehende Namen nicht wichtig sind, solange Fig die Container für ein Projekt finden kann. Wenn ich als Benutzer über seinen Dienstnamen (z. B. fig stop web ) auf den Container eines Dienstes zugreifen kann, spielt der Name des tatsächlichen Containers keine Rolle.

Ich habe sogar gedacht, dass fig Container nach ID in einem lokalen Speicher im Verzeichnis .fig verfolgen könnte (was auf Computern mit vielen laufenden Containern einen Leistungsgewinn bedeuten könnte). Aber das ist wirklich etwas für ein separates Thema.

Irgendwelche Gedanken zum "impliziten" Erstellen der 'Projektnamen'-Datei oder "explizit" über fig init ? Wenn ich in den kommenden Ferien etwas Zeit habe, kann ich vielleicht ein bisschen experimentieren (habe nie etwas in Python codiert, also wird es wirklich experimentell sein :))

Ist es wichtig, die Kontrolle über die produzierten Bilder zu haben, zB

Ich denke, das Image ist wirklich wichtig, aber es ist auch auf gemeinsam genutzten Hosts sehr wichtig, sicherstellen zu können, dass Containernamen nicht in Konflikt geraten. Ich sehe, dass dieser Vorschlag tatsächlich darauf abzielt, sich auch mit diesem Thema zu befassen.

Aber ich denke, dass vorhersehbare Namen für Container immer noch wichtig sind. Ich kann mir einige Aufgaben vorstellen, bei denen es für externe Systeme (nicht nur für Abb.) Wichtig ist, einen Container anhand seines Namens zu identifizieren:

• Bereinigungsskripte zum Entfernen alter Container, um zu identifizieren, durch welches Projekt ein Container erstellt wurde
• Container debuggen / inspizieren

Beide sind momentan ziemlich einfach, da ich bereits weiß, wie der Containername lauten wird. Wenn ich einen Namen nachschlagen muss, ist das etwas komplizierter.

Ich habe sogar gedacht, dass fig Container nach ID in einem lokalen Speicher im .fig-Verzeichnis verfolgen könnte

Es ist wahr, dass dies ein Leistungsgewinn sein könnte, aber ich mache mir Sorgen, dass dies der falsche Ansatz ist. Das Hinzufügen eines dauerhaften Status zu Abb. Führt die Möglichkeit vieler Fehler (die mit dem Status einhergehen). Ich würde viel lieber sehen, dass dies von einem Etikettiersystem in dockerd erledigt wird. Wenn fig nur Container beschriften und dann alle Container mit dieser Bezeichnung abfragen kann, wird der gesamte Status an einem einzigen Ort (dockerd) gespeichert. Ich weiß, dass irgendwann darüber gesprochen wurde, ich bin mir nicht sicher, ob es auf der Roadmap steht.

Irgendwelche Gedanken zum "impliziten" Erstellen der 'Projektnamen'-Datei oder "explizit" über fig init?

Ich denke implizit wäre abwärtskompatibler. Ich möchte ein fig init vermeiden, es sei denn, dies ist absolut notwendig. Anstatt das basedir zu verwenden, konnte ich sehen, dass es implizit einen Projektnamen von <basename>-<4 digit random id>

Ich kann nur sagen, wenn fig jetzt anfängt, zufällige Namen zu generieren, werde ich davon abweichen, weil ich mehr als 1000 Container auf einem einzelnen Host laufen lasse und wenn ich sie nicht mehr anhand des Namens identifizieren kann, ist es nichts für mich.

@ frank-dspeed danke für das Hinzufügen deines Anwendungsfalls. Wenn ich das richtig verstehe, starten Sie Ihre Container mit fig, aber verwalten sie danach direkt über Docker, wobei Sie die von Fig verwendete Namenskonvention verwenden.

Vielleicht ist dies auch für Sie von Interesse: https://github.com/docker/docker/pull/9882 - Metadaten bieten mehr Möglichkeiten zur Identifizierung von Containern, nicht nur deren Namen.

ah ja, ich habe solche Vorschläge oft gemacht, zum Beispiel einfach neue Filds hinzugefügt und das, aber ich endete in diesem Fall mit dem einfachen Hinzufügen einer ENV und dann habe ich das als Kostümfild, das ich analysieren kann: dart:

Ich denke, die Verwaltung der Eindeutigkeit des Projektnamens sollte nicht in der Verantwortung von fig liegen.

Wenn ich Ihren Vorschlag richtig verstanden habe, würde die Generierung eines zufälligen Namens die Option FIG_PROJECT_VARIABLE und --project-name unbrauchbar machen. Das ist praktisch für "Templating" -Dienste.

Ich denke, die Verwaltung der Eindeutigkeit des Projektnamens sollte nicht in der Verantwortung von fig liegen.

Ich bin mir nicht sicher; Abb. "Still" das Überschreiben der Container anderer Projekte, da es manchmal unangenehm ist, sich in einem Verzeichnis mit demselben Namen zu befinden.

Wenn ich Ihren Vorschlag richtig verstanden habe, würde die Generierung eines zufälligen Namens die Option FIG_PROJECT_VARIABLE und die Option --project-name-nutzlos machen. Das ist praktisch für "Templating" -Dienste.

Nach der obigen Diskussion denke ich, dass so etwas funktionieren würde

• Wenn --project-name ist, verwenden Sie dies (und schreiben / aktualisieren Sie .project-name ? Nicht sicher)
• Es wird kein --project-name bereitgestellt, aber FIG_PROJECT_NAME verwendet FIG_PROJECT_NAME (und schreibt / aktualisiert auf .project-name ?)
• Keine der oben genannten Optionen, aber .project-name ist festgelegt. Verwenden Sie .project-name
• Nichts des oben Genannten; Erstellen Sie einen zufälligen Namen und schreiben Sie ihn in .project-name

Aus der Sicht von jemandem, der fig in Skripten verwendet, die sich um einen Namen kümmern und ihn an fig übergeben, macht es keinen Sinn, einen Namen im Projektspeicherort (in meinem Fall eher eine Vorlage) zu speichern.

und trotzdem habe ich es sehr intuitiv gespürt, dass der Verzeichnisname im Namen der resultierenden Container verwendet wird, als ich gerade fig up .
und sagen wir mal, Sie sehen sich docker ps -a , das ist nicht sehr hilfreich, wenn es mit zufälligen Namen gefüllt ist.

Würde eine Option --random-name in Ihrer Situation helfen?
Daneben denke ich, dass die Möglichkeit, einige [a-zA-Z0-9_].* voranzustellen, um einige Namespaces widerzuspiegeln, für breitere Bereitstellungen nützlich wäre.

Was ist mit der fig.yml, um solche Informationen zu speichern?

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

Und um BC zu behalten, in compose / project.py :: from_config

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

@jderusse Ich bin sehr für etwas, wie Sie vorgeschlagen haben. Vielleicht möchten Sie Ihren Vorschlag zu # 45 hinzufügen, da dies wahrscheinlich der bessere Ort ist, um darüber zu diskutieren?

trotzdem zur Lösung dieses Tickets zu kommen? Es sieht so aus, als ob das vorgeschlagene # 1233 Ihnen das Beste aus beiden Welten bietet, indem der Benutzer die beabsichtigte Aktion festlegen kann, ohne die Abwärtskompatibilität zu beeinträchtigen.

Ursprünglich wollte ich den Namen in docker-compose.yml , aber nachdem ich mehr darüber nachgedacht habe, mag ich die Idee einer separaten Datei wirklich.

Eine separate Datei bietet Ihnen die Möglichkeit, sie bei Bedarf außerhalb der Versionskontrolle zu halten (in Fällen, in denen jeder Benutzer einen anderen Projektnamen haben soll).

Bei der neuen Netzwerkunterstützung besteht eine Funktionsanforderung, um auch den Netzwerknamen konfigurieren zu können (standardmäßig der Projektname). Mit einer separaten Konfigurationsdatei könnten wir also Dinge wie den Standardnetzwerknamen, die Standardskala usw. einschließen. Die gesamte Metakonfiguration, die nicht Teil der Anwendungsdefinition ist, aber dennoch für die Ausführung der Komposition relevant ist.

Ich stimme dem zu, was Dnephin gesagt hat. Wie wäre es mit einer Datei .docker-compose ? Wir könnten dort Standardoptionen für alle Befehlszeilenargumente auflisten.

@dnephin sgtm

@mikehaertl In meinem Beispiel .docker-compose , aber eine Datei könnte auch funktionieren, je nachdem, wie viele Informationen wir speichern möchten

@thaJeztah Oh, richtig, sorry. Das habe ich vermisst.

@mikehaertl hat sie gerade von .fig in .docker-compose ;-)

Recht :)

Eigentlich würde ich eine einfache Datei bevorzugen. Wie wäre es mit Ini-Stil? Globale Optionen oben, befehlsspezifische Optionen in einem Abschnitt:

project-name = blabla

[build]
no-cache

Einige Ideen für semi-bezogene Informationen, die wir möglicherweise entweder in derselben Datei oder in demselben Verzeichnis speichern möchten:

• Netzwerkname (Benutzer möchten möglicherweise einen anderen Netzwerknamen als den Projektnamen. Wir haben bereits eine Anfrage dafür erhalten.)
• Client-API-Version
• Docker-Host
• Standard-Skalierungswert

Da wir jetzt mehrere Compose-Dateien unterstützen, kann es auch interessant sein, die Pfade zu den Compose-Dateien einzuschließen, die als Konfiguration verwendet werden sollen.

Client-API-Version

möglicherweise docker_host ?

Das klingt auch gut (hinzugefügt)

Ich bin gerade auf dieses Problem gestoßen.

Ich bin an einem Punkt angelangt, an dem die Grundstruktur unserer Docker-Konfiguration festgelegt wurde, und repliziere sie jetzt auf andere Dienste. Da alle Projekte dieselbe Struktur haben, verwenden sie alle dasselbe Unterverzeichnis (und damit den Standardprojektnamen). Das heißt, ich kann nicht sicher 2 Dienste auf demselben Host aufspulen.

Möglicherweise muss ich die Struktur ändern, damit der Name des Projektverzeichnisses die Standardeinstellung ist, aber ich bin mir nicht 100% sicher, was dies beim Kopieren von Dateien zum Zeitpunkt der Image-Erstellung bewirkt.

Gleich hier habe ich ein ähnliches Problem mit Makefile- Zielen gelöst. Wenn Sie jedoch benutzerdefinierte docker-compose -Befehle ausführen möchten, müssen Sie -p customname .

Im Moment versuche ich herauszufinden, wie verhindert werden kann, dass Docker-Compose-Setups in /home/alice/myproject und /home/bob/myproject gegenseitig auf die Container treten. Gibt es eine Möglichkeit, Containernamen aus dem vollständigen Dateipfad anstatt nur aus dem letzten Verzeichnisnamen abzuleiten?

@ chris-martin Dies ist nur eine Problemumgehung ...

alias docker-compose="docker-compose -p ${PWD}"

Docker-Compose-Streifen / aus Projektnamen?

Ist dokumentiert, welche Zeichen in Projektnamen zulässig sind?

Am Ende habe ich meine Verzeichnisstruktur geändert und docker-compose.yml in das Projektstammverzeichnis eingefügt, was eine ausreichend gute Problemumgehung ist

Es bietet einen gewissen Schutz, wenn Sie dazu neigen, alle Ihre Git-Repositorys in dasselbe Verzeichnis zu stellen (z. B. $ HOME oder $ HOME / Projekte), aber es wird problematisch, wenn Sie eine andere Struktur verwenden (z. B. ein Verzeichnis pro Organisation, wie ich häufig) oder wenn Ihr Computer boot2docker verwendet, wodurch Informationen zwischen Benutzern auf derselben Box verloren gehen, es sei denn, Sie achten darauf, dass Docker-Computer Ihnen unterschiedliche VMs zur Verfügung stellt.

Ich denke, # 2294 oder einfach hygienischer mit Docker-Maschine zu sein, würde auch meine Probleme beheben.

Ich würde auch empfehlen, es in das Projektstammverzeichnis zu stellen und einen anderen Ordnernamen zu haben.

In meinem Fall möchte ich den anfänglichen Projektnamen festlegen, da ich einen freigegebenen Computer in AWS habe und obwohl ich die Datei docker-compose.yml im Stammverzeichnis habe, kann ein Benutzer das Repository in ein Verzeichnis mit einem anderen Namen klonen. Wenn dies derzeit geschieht, treten Probleme beim Starten / Stoppen von Containern auf.

Mit der neuen Syntax v2 könnte dies wie unter https://github.com/docker/compose/issues/745#issuecomment -74028861 erwähnt implementiert werden

Es ist eigentlich nur ein container_name_prefix , nicht wahr?

@ schmunk42

Es ist eigentlich nur ein container_name_prefix, nicht wahr?

Es wird auch als volume_name_prefix , image_name_prefix und network_name_prefix , also denke ich, dass project_name ein allgemeinerer Begriff ist.

.docker-compose docker-compose.override.yml in vielerlei Hinsicht bekannt vor. Warum sollten Sie ein anderes Konfigurationsformat (z. B. ini) einführen, wenn wir bereits YAML haben?
Ich bin daher für den Vorschlag von @jderusse in # 745 (Kommentar) , dem docker-compose.yml einen project_name Schlüssel hinzuzufügen, um den Anwendungsfall von @JosephEarl zu aktivieren.

Benutzerspezifische Anpassungen können bereits implementiert werden, indem docker-compose.override.yml und über .gitignore .
Wenn eine dritte explizit benutzerspezifische Überschreibungsdatei gewünscht wird, würde ich .docker-compose.local-override.yml vorschlagen.

In Bezug auf die Struktur der YAML würde ich vorschlagen, einen neuen Schlüssel der obersten Ebene mit dem Namen project erstellen, der project_name und möglicherweise in Zukunft andere Variablen enthält. Dadurch wird vermieden, dass der Namespace der obersten Ebene verschmutzt wird. Um zu veranschaulichen:

project:
  project_name: "your-project"
  network_prefix: "abc"

Beachten Sie, dass es möglicherweise verständlicher ist, anstelle von network_prefix die Namen der Netzwerke selbst direkt anzupassen. Nach meinem Verständnis gibt es zwei Fälle:

• Der erste Fall ist "Gib den Netzwerken nur einen eindeutigen Namen, aber es ist mir egal, welcher genau". Für diesen Fall reichen project_name aus.
• Der andere Fall sind Netzwerke, auf die von externen Systemen verwiesen wird. In diesem Fall ist es wahrscheinlich sowieso besser, die Netzwerknamen selbst explizit anzugeben.

Der oben vorgeschlagene Vorschlag klingt gut für mich. Ich stimme zu, dass wir keine zusätzlichen Konfigurationsdateien einführen möchten

+1 zum Konzept dieser Ausgabe
Aber auch +1 bei Verwendung eines Schlüssels in docker-compose.yml anstatt eine weitere Datei zu unseren Repos hinzuzufügen.

Um frühere Kommentare zusammenzufassen: Ein Vorschlag für die Suchsequenz des Projektnamens wäre wie folgt; frühere Elemente haben Vorrang vor späteren:

1. Verwenden Sie --project-name falls angegeben
2. Verwenden Sie COMPOSE_PROJECT_NAME falls angegeben.
3. Verwenden Sie den Schlüssel project_name von docker-compose.yml (oder wo immer diese Einstellung gespeichert ist).
4. Verwenden Sie die basename des Projektverzeichnisses

Ich bin mir nicht sicher, welche Priorität 2 gegen 3 hat:

• Aus Gründen der Konsistenz mit --project-name sollte COMPOSE_PROJECT_NAME definitiv project_name: überschreiben.
• Aber: Wenn COMPOSE_PROJECT_NAME Vorrang vor project_name: hat, kann aufgrund der festgelegten Umgebungsvariablen versehentlich der falsche Projektname verwendet werden. Dies kann schwierig zu debuggen sein. Vielleicht kann in diesem Fall eine Warnmeldung problematisch sein?

Was ist mit der Einführung einer neuen Eigenschaft container_name_pattern mit dem Standardwert %(project_name)s_%(service_name)s_%(instance_number)s , um BC zu behalten?
Mit diesem Parameter können wir ihn in hardcodedproject_%(service_name)s_%(instance_number)s ändern und dieses Problem endgültig beheben

Ich bin gerade bei diesem Problem angekommen, nachdem ich 10 Minuten lang nach dieser Funktionalität gesucht habe.

Das erste, was ich tat, war die Suche nach dem richtigen Schlüssel im Referenzdokument zum Verfassen von Dateien, also +1 für project_name Geben Sie docker-compose.yml

: +1: für die Strategie @ cr7pt0gr4ph7

+1 für die Strategie @ cr7pt0gr4ph7

Compose hat eine Syntax für die Substitution der Umgebung. Lassen Sie die Leute es vielleicht selbst tun, anstatt eine Umgebungsvariable für den Projektnamen zu verwenden, wenn sie sich darum kümmern.

Auf der anderen Seite verwendet der Docker-Computer das Ende, um zu entscheiden, auf welchem ​​Computer ein Compose-Build erstellt wird. Daher sollten der Projektname und das Ziel möglicherweise gleich funktionieren. Hmm, das ist eine schwierige Frage.

https://github.com/docker/compose/issues/745#issuecomment -182296139 klingt richtig. Die Umgebungsvariable hat Vorrang vor dem Wert in der Erstellungsdatei, der standardmäßig verwendet wird (vorausgesetzt, der Projektname gehört in die Erstellungsdatei).

Was ist zu beachten, wenn Sie mehrere Compose-Dateien verwenden, die jeweils einen Projektnamen definieren?

Ich denke nicht, dass es ein Fehler sein sollte, der dazu führen würde, dass Dateien entweder "primär" oder "extras" sind, was derzeit nicht der Fall ist. Jede Datei kann isoliert oder in Kombination mit anderen verwendet werden.

Möglicherweise ist eine Warnung sinnvoll, oder wir ignorieren sie einfach vollständig (da der Wert auch durch Festlegen einer Option oder einer Umgebungsvariablen ignoriert werden kann).

Was ist zu beachten, wenn Sie mehrere Compose-Dateien verwenden, die jeweils einen Projektnamen definieren?

Wenn Sie so etwas wie docker-compose -f compose1.yml -f compose2.yml up tun und beide Dateien den Projektnamen definieren, sollte der verwendete Name von compose2.yml .

Ich denke, jeder hat eine Lösung, die mir schon gefällt: -) Dh project_name in docker-compose.yaml. Ich möchte nur einen anderen Anwendungsfall für den Projektnamen in der Datei docker-compose.yaml erwähnen:

Auf den HTTP 500 Internal Server Error-Seiten in meinem Projekt sage ich dem Entwickler, wie das Problem behoben oder behoben werden soll. Ich sage ihm beispielsweise, dass er zcat database-dump.tgz | docker exec -i projectname_db_1 psql wenn der Server feststellt, dass keine PostgreSQL-Datenbank vorhanden ist Benutzer wurde erstellt - und dann möchte ich selbst projectname auswählen, andernfalls können die Hilfemeldungen nicht in die Konsole kopiert werden.

Stimmen Sie zu, dass eine Warnung angezeigt werden sollte, wenn COMPOSE_PROJECT_NAME den Projektnamen in der Datei compose.yml überschreibt. Dieses Verhalten ist basierend auf den vorhandenen Docker-Befehlen sinnvoll, für einen Neuling jedoch nicht besonders logisch oder offensichtlich.

+1 für die Strategie @ cr7pt0gr4ph7

Ich habe versucht, nach etwas zu suchen, bevor ich selbst eine Ausgabe geöffnet habe, da ich nichts finden konnte.
+1 für project_name in der Datei docker.compose.yml. Mit v2 macht das wohl immer mehr Sinn.

Stimmen Sie zu, dass eine Warnung angezeigt werden sollte, wenn COMPOSE_PROJECT_NAME den Projektnamen in der Datei compose.yml überschreibt. Dieses Verhalten ist basierend auf den vorhandenen Docker-Befehlen sinnvoll, für einen Neuling jedoch nicht besonders logisch oder offensichtlich.

Es ist ziemlich normal, dass Umgebungsvariablen Konfigurationseinstellungen überschreiben und Befehlszeilenargumente Konfigurationseinstellungen und Umgebungsvariablen überschreiben.
Sind wir wirklich eine Warnung dafür? Es ist nicht so, dass jemand versehentlich eine Umgebungsvariable mit dem Namen COMPOSE_PROJECT_NAME erstellen würde.

Wäre es in Ordnung, eine PR zu erstellen, die nur die project_name von docker-compose.yml , um dies in Gang zu bringen? Oder möchten wir zusätzliche Dinge wie die Verwendung des Werts project_name aus der letzten Datei yml , auf die sofort verwiesen wird?

Wie wäre es damit?

version: "2"
project:
    default_name: "app"

Ich werde meine Implementierung (https://github.com/docker/compose/pull/3118) für dieses Format ändern. Aber ich bin mir nicht sicher, ob es einen project Abschnitt braucht ....

+1 Seien Sie gespannt auf diese Funktion

@timgriffiths , sieht so aus, als ob dies im neuesten RC möglich ist, indem Sie Ihrem Projekt eine Umgebungsdatei hinzufügen:

• https://docs.docker.com/compose/env-file/
• https://github.com/docker/compose/releases/tag/1.7.0-rc1

@deizel Also habe ich Erstellungsdatei definieren zu können.

In unserer Situation haben wir Prod-, Staging-, UAT- und Dev-Compose-Dateien, damit wir verschiedene Versionen unseres Anwendungsstapels starten können, und manchmal möchten wir eine Staging- und UAT-Umgebung auf demselben Schwarm aufbauen, damit ich die Umgebung verwenden kann Variablen oder was nicht, aber das hängt davon ab, dass der Benutzer sich daran erinnert, dies festzulegen, wobei, als ob es in der Erstellungsdatei wäre, alles in das Repo eingecheckt würde und wir alles inline und einfach für alle Benutzer erklären könnten.

+1 Wir haben eine Situation, in der unsere Compose-Datei Verweise auf vorkonfigurierte Remote-Volumes enthält. Compose fügt den Projektnamen automatisch zu den Datenträgernamen hinzu, die dann aufgrund nicht übereinstimmender Namen nicht bereitgestellt werden können. Wenn Sie den Projektnamen explizit in der Compose-XML-Datei festlegen können, wird die Namenskonvention für andere Projektbeteiligte viel offensichtlicher, anstatt Umgebungsvariablen in undurchsichtigen externen Dateien zu verbergen, die je nach Umgebung variieren können.

@edevenport In Ihrem Fall könnten Sie eine externe Option für benannte Volumes verwenden:

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

Vielen Dank an @fesor - ich hätte näher darauf eingehen sollen. Ich mounte tatsächlich glusterfs-Volumes mit einer ähnlichen Konfiguration:

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

In diesem Fall wird media auf dem Host zu projectname_media und kann nicht gemountet werden, es sei denn, das glusterfs-Volume wird vorab mit dem Projektnamen erstellt. Ich hatte gedacht, die glusterfs-Volumes manuell auf dem Host zu mounten und external in der Docker-Compose-Datei zu verwenden, aber ich würde dies lieber nicht vorab manuell über alle Knoten hinweg tun müssen.

@edevenport Ich verstehe das. Sie können dieses Volume jedoch einfach manuell mit docker volume create hinzufügen und verwenden:

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

Es ist also nicht erforderlich, das Projekt zu ändern und Präfixe zu entfernen.

@timgriffiths 'Fall ist etwas komplexer und es gibt keine Problemumgehungen. Ich benutze einen einfachen Wrapper um docker-compose nur um mich nicht an Projektnamen zu erinnern.

@fesor, also haben wir das Problem indem wir nur die Ordnernamen gesteckt haben.

@timgriffiths Ich habe eine PR gemacht (https://github.com/docker/compose/pull/3118) - vielleicht würde das helfen. Ihr Fall wird jedoch nicht behandelt, wenn Sie mehrere Erstellungsdateien haben.

@fesor, dass PR perfekt wäre, ist es eine Möglichkeit, es zusammenzuführen?

Jetzt stellt Compose eine Umgebungsdatei bereit, sodass der Projektname dort beibehalten werden kann.

@mkuzmin es ist traurig, dass es COMPOSE_FILE gibt, aber es gibt keine COMPOSE_OVERRIDE_FILE .

@fesor AFAIK Sie können mehrere Dateien angeben

@ schmunk42 Ich könnte auch den Projektnamen angeben. Aber das löst das Problem nicht. Ich möchte im Bereitstellungsskript so etwas haben:

docker-compose up -d

Anstatt von

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

COMPOSE_PROJECT_NAME im obigen Beispiel wird von CI angegeben. Und Funktionen wie .env file sind cool, aber ... nutzlos, wenn der Projektname bestehen bleibt.

Ich benutze .env um env-Variablen zu trocknen (und für Docker-Compose <1.7 habe ich einen einfachen Wrapper), aber es löst keine anderen Probleme. @timgriffiths hat bereits auf den Fall der Bereitstellung auf einem

COMPOSE_FILE=one.yml:two.yml ist das Festlegen mehrerer Dateien. Fügen Sie also einfach die Überschreibungsdatei in $COMPOSE_FILE

@nephin hat diese Funktion verpasst, cool.

Nun ... über die Schwarmbereitstellung habe ich das bereits über COMPOSE_PROJECT_NAME in den ENV-Variablen meines Jenkins-Jobs erledigt, also nur Probleme mit der manuellen Bereitstellung. Und meine Implementierung erlaubt nicht, dass der Standardprojektname überschrieben wird, also ...

Dieses Problem ist fast 2 Jahre alt und noch ungelöst. Ich frage mich, was genau das Docker-Team daran hindert, endlich eine richtige Lösung hinzuzufügen. Ist es wirklich so schwierig, eine einfache neue Konfigurationsanweisung für docker-compose.yml -Dateien hinzuzufügen?

Die Problemumgehung mit .env ist zwar gut, aber nicht immer verwendbar (die Datei .env wird möglicherweise bereits von Ihrer Anwendung verwendet). Und es ist auch immer noch eine Problemumgehung.

Und ich habe sogar andere neue Probleme gesehen, die möglicherweise mit dem Projektnamen zusammenhängen und sich in die neuesten Versionen eingeschlichen haben (# 3966).

Also, was ist das Problem wirklich?

Ist es wirklich so schwierig, eine einfache neue Konfigurationsanweisung für docker-compose.yml -Dateien hinzuzufügen?

Nein! Das Problem war nie die Schwierigkeit der Implementierung.

Die Problemumgehung mit .env ist zwar gut, aber nicht immer verwendbar (die Datei .env wird möglicherweise bereits von Ihrer Anwendung verwendet). Und es ist auch immer noch eine Problemumgehung.

Es ist keine Problemumgehung, es ist eine Lösung! Die Datei .env enthält Umgebungsvariablen, die von Compose gelesen werden sollen. Wenn Sie Umgebungsvariablen haben, die von Ihrer Anwendung gelesen werden sollen, legen Sie sie in einer anderen Datei ab (z. B. app.env ) und referenzieren Sie sie mit der Option env_file .

Also, was ist das Problem wirklich?

Das Hinzufügen des Projektnamens zu einer docker-compose.yml -Datei macht sie weniger portabel, was wir nicht fördern möchten. Jetzt, da es eine Möglichkeit gibt (mit .env ), den Projektnamen dauerhaft anzugeben, ohne die Portabilität von docker-compose.yml , ist der Fall, ihn als Konfigurationsoption hinzuzufügen, schwächer. Dies ist der Hauptgrund, warum sich dieses Problem nicht bewegt hat.

Durch Hinzufügen des Projektnamens zu einer Datei docker-compose.yml wird sie weniger portabel.

Könnte dies nicht optional sein? Persönlich checke ich nie meine docker-compose.yml sondern gebe nur ein docker-compose-example.yml in meinem Repo an, das ich lokal optimiere. Während der Entwicklung kann ich beispielsweise einige zusätzliche Umgebungsvariablen hinzufügen oder zusätzliche Volumes in meinen Container abbilden. Warum geben Sie uns nicht auch die Möglichkeit, den Projektnamen anzugeben?

Nach Ihrer Argumentation sollten Sie auch alle network -Optionen auf .env da sie normalerweise überhaupt nicht portierbar sind und von der Netzwerkeinrichtung Ihres Host-Computers abhängen.

Anders ausgedrückt: Was macht den Projektnamen so besonders? Es gibt bereits viele andere Optionen im docker-compose.yml , die nicht wirklich portabel sind. Warum geben Sie dem Entwickler nicht die Möglichkeit, das für seinen Anwendungsfall am besten geeignete auszuwählen?

Ich denke auch, dass die Option verfügbar gemacht werden sollte. Mit zunehmender Verbreitung von Docker werden Projekte mit nur einem Entwickler, der Containerisierung in seinem Workflow verwendet, immer häufiger. In diesen Anwendungsfällen ist der konstante Projektname in Ordnung. Ein gutes Beispiel für ein anderes Projekt, das eine solche Flexibilität ermöglicht, ist das Vagrantfile . Sie erkennen, dass es sicherlich Anwendungsfälle für große Teams gibt, erkennen dann aber auch die Szenarien der Entwickler einsamer Wölfe.

Ich denke, dass die Implementierung einer Projektnamenoption hier für die Annahme wichtig ist. Es könnte Solo-Entwickler abschrecken, die sich nicht für eine "skalierbare Strategie zur Konfiguration von Projektnamen" interessieren.

Durch Hinzufügen des Projektnamens zu einer docker-compose.yml-Datei wird diese weniger portabel, was wir nicht fördern möchten. Jetzt, da es eine Möglichkeit gibt (mit .env), den Projektnamen dauerhaft anzugeben, ohne die Portabilität von docker-compose.yml zu beeinträchtigen, ist der Fall, ihn als Konfigurationsoption hinzuzufügen, schwächer. Dies ist der Hauptgrund, warum sich dieses Problem nicht bewegt hat.

Wie macht das Hinzufügen des Projektnamens zu docker-compose.yml es weniger portabel?

IMHO ist es eigentlich das Gegenteil, wie # 3966 von @mikehaertl zeigt. Dieses Problem zeigt deutlich, dass das Nicht-Speichern des Projektnamens in docker-compose.yml die Dinge tatsächlich weniger portabel macht (wie in: eine größere Wahrscheinlichkeit, mit anderen Compose-Projekten in Konflikt zu geraten, die auf demselben Computer gestartet wurden), da Compose auf einer Konvention über basiert Der Name des Containerordners, den viele Leute zumindest anfangs nicht kennen.

Durch das Hinzufügen einer .env -Datei wird nicht nur eine zusätzliche Lernfunktion für neue Benutzer hinzugefügt, die Compose übernehmen möchten, sondern ich müsste sie auch neben docker-compose.yml zu meinem Repo hinzufügen, um dies zu verhindern Kollisionen Ich sehe keine andere Portabilität als die Definition des Projektnamens in docker-compose.yml .

Ich bin auch dafür, den Namen in docker-compose.yml hinzuzufügen. Die .env-Datei wird in anderen von mir verwendeten Frameworks verwendet und es ist wichtig, dass sie nicht im Repo angezeigt wird. Um jedoch lokalisierte Container in meinen Entwicklern zu verwalten, ist es umso besser, je weniger sie (zunächst) über Docker wissen. Ich möchte einen einfachen Einstiegspunkt, der nicht mit anderen Projekten kollidiert. Ich möchte nicht erklären, warum die Dinge so sind, wie sie sind. Nur eine einfache

Repo klonen
Docker-komponieren

Meine Problemumgehung besteht jetzt noch darin, die von @ schmunk42 vorgeschlagene Datei zu erstellen.

Der Container selbst sollte sich nicht um den Projektnamen kümmern. Warum sollten Umgebungsvariablen als Mechanismus verwendet werden, der nur dem Host wichtig ist?

Ich würde gerne Unterstützung dafür in der docker-compose.yml -Datei sehen. Wenn es über eine Umgebungsvariable festgelegt werden muss, kann es in der Datei .env werden (falls nicht direkt auf dem Host festgelegt) und über die Variablensubstitution in der Datei docker-compose.yml werden.

Wenn benannte Container zulässig sind, warum sind benannte Projekte nicht zulässig?

Der Anwendungsfall, in dem eine Projektnamendefinition in der .yml-Datei nützlich wäre, ist folgender:
Wir haben dieselbe Docker-Compose-Datei für verschiedene Webserver (verschiedene Datenbankanmeldeinformationen, verschiedene Datenmengen, einige kleine Unterschiede wie Logo usw.). Pro Anwendung werden 3 Dienste ausgeführt, die in einer Erstellungsdatei konfiguriert sind. Wenn mehrere Server nebeneinander ausgeführt werden, wäre es schön zu sehen, welcher Dienst zu welchem ​​Projekt gehört.

Das Ersetzen von Variablen im Containernamen ist praktisch, wobei das Präfix $ COMPOSE_PROJECT_NAME verwendet wird. Nun, ich verstehe die .env-Dateilösung, aber dies macht sie in einer (CI) -Bereitstellungsumgebung nicht "entwicklerfreundlicher".

Ein Docker-Compose-Kill-Container eines völlig anderen Docker-Compose zu haben, weil kein -p oder keine Umgebungsvariable festgelegt wurde und Sie das Docker-Compose in einem "Docker" -Unterordner erstellt haben, ist meiner Meinung nach ein kritischer Fehler.

Bei ernsthaften Bereitstellungen ist einfach zu viel Platz für Fehler. Vergessen Sie einfach, den Projektnamen anzugeben, ob in -p, .env oder anderswo: Sie gehen einige Zeit offline, bis Sie bemerken, was passiert ist. Schlimmer noch: Der Kollisionsdienst wird offline geschaltet, nicht der, an dem Sie arbeiten. Sie werden einen schönen Tag haben :(

@dnephin Was genau hält das Docker-Team davon ab, dies endlich umzusetzen? Wie viele weitere klagende Benutzer sind erforderlich? Dies ist eine so triviale Lösung, dass es kaum zu glauben ist, dass immer noch nichts passiert ist.

Vielleicht bin ich der einzige hier, der Bedenken hat, aber trotzdem.
In unserem Setup ändern wir nur .env und app.env Dateien zum Wechseln der Umgebung. Dies setzt jedoch voraus, dass mehrere Dateien vorhanden sind und yml Dateien zusammengeführt werden.

Wenn dies implementiert wird, denken Sie bitte an BC.

Z.B. Wenn ein Projektname in docker-compose.yml und .env sollte letzterer Vorrang haben. Andernfalls treten bei Personen, die sich auf die Verwaltung über .env , ähnliche Probleme mit überlappenden Stapeln auf, z. B. mit dem aktuellen Workflow und der Verwendung von Ordnernamen.

@ schmunk42 Wir sagen nicht, dass die .env -Funktion entfernt werden sollte. Wenn Sie Ihren Projektnamen lieber in .env haben möchten, konfigurieren Sie ihn einfach nicht in docker-compose.yml .

Aber andere bevorzugen es, es in ihren docker-compose.yml wie die Diskussion hier deutlich zeigt. Sie sollten dazu in der Lage sein, wenn sie wollen. Dies ist eine optionale Funktion. Was Vorrang hat, wenn beide konfiguriert sind, ist die Definition einer einfachen Konvention.

Bitte fügen Sie benannte Projekte hinzu. Anwendungsfall:
Projekt eins:
docker-compose up --build --remove-orphans

• Nginx
• statischer Inhalt
  Projekt zwei:
  docker-compose up --build --remove-orphans
• Nginx
• statischer Inhalt

Wenn Projekt zwei startet, werden die Container des Projekts mit einem Exit 137 (Code 128 + Level 9) beendet.

Jetzt muss ich docker system prune ausführen und jeden Tag Netzwerke neu aufbauen, um nicht Dutzende toter Container zu haben.

export COMPOSE_PROJECT_NAME=somethingnew

Kann jemand aus dem Kernteam vielleicht endlich erklären, was diese Funktion aufhält? Es ist so frustrierend, wie Dinge, die so einfach zu reparieren sind, ohne guten Grund blockiert werden.

Das einzige Argument war bisher, das docker-compose.yml portabel zu halten. Das macht keinen Sinn, weil

• Der Projektname in der Composer-Datei macht sie nicht automatisch nicht mehr portierbar
• Nicht jeder hat diese Anforderung
  
  
  
  • Wir haben bereits andere Optionen, die die Portabilität auf die gleiche Weise einschränken können: networks , port , ...
  
  

Es hängt alles sehr stark vom jeweiligen Anwendungsfall ab. Aber nur weil einige diese Option nicht wollen, sollte das nicht bedeuten, dass jeder seiner Meinung folgen muss!

@mikehaertl Sie haben bereits dauerhafte Projektnamen. Legen Sie einfach die Datei .env und setzen Sie dort die Variable COMPOSE_PROJECT_NAME . Ich sehe keinen Vorteil mehr im Projektnamen in der Erstellungsdatei.

@fesor Ich habe im Allgemeinen keine .env -Dateien unter Versionskontrolle, da sie maschinen- / umgebungsspezifische Einstellungen enthalten. Deshalb möchte ich auch, dass Projektnamen in der docker-compose.yml -Datei konfigurierbar sind .

@fesor : Ich denke, @thasmo ist in dieser compose.yml werden, da er in der Versionskontrolle sein sollte, wenn er für alle Entwickler relevant ist, die das Projekt verwenden.

@fesor Es tut mir leid, aber ich denke nicht, dass persönliche Vorlieben ein echtes Argument sind. Die eigentliche Frage ist nicht, warum wir keine .env- oder Umgebungsvariablen verwenden möchten. Es ist umgekehrt: Warum wurde es nicht in die Konfigurationsdatei eingefügt, in die es gehört?

Fast alle Optionen, die Sie in der Befehlszeile an docker übergeben können, können in dieser Datei angegeben werden. Nur der Projektname ist aus mysteriösen Gründen ausgeschlossen. Ist dies eine Form der Apartheid unter den Argumenten? : PI beanspruchen gleiche Rechte für alle! Lassen Sie den Entwickler entscheiden und legen Sie keine künstlichen Einschränkungen fest.

Und nochmal: Niemand nimmt Ihnen die alte Option weg - wir wollen erst endlich diese zusätzliche Option. Das ist nur fair.

@dnephin : Es scheint, als ob Sie und alle anderen mit der Lösung zufrieden sind, die in der Verfeinerung dieses Problems durch cr7pt0gr4ph7 angegeben ist.

Wären Sie bereit, eine Pull-Anfrage zu akzeptieren, die sie implementiert, oder möchten Sie, dass einer der Betreuer sie schreibt?

@ cr7pt0gr4ph7

@dnephin @fesor mit dem Projektnamen in der * compose.yml erleichtert ein einheitliches Konfigurationsschema

Mir ist nicht klar, warum der Projektname wichtig ist. Kein Teil der Konfigurationsdatei sollte sich auf einen bestimmten Projektnamen stützen.

Die einzige wichtige Eigenschaft des Projektnamens ist, dass er nicht mit dem Namen eines anderen Projekts in Konflikt steht. Dies ist eigentlich ein Argument gegen die Aufnahme in die Datei docker-compose.yml . Ein Entwickler in einem Projekt verwendet häufig einen anderen Verzeichnisnamen für jedes Projekt, sodass die Standardeinstellung für die meisten Anwendungsfälle häufig korrekt ist.

Wenn die Standardeinstellung nicht korrekt ist, kann der Entwickler sie überschreiben ( -p oder COMPOSE_PROJECT_NAME ). Dies kann entweder ein Aliase sein oder in die Datei .env eingefügt werden .

Ich bin nicht gegen eine Projektdatei, die den Projektnamen definiert. Ich möchte nur verstehen, warum diese Funktion für einige so wichtig ist. Wenn es daran liegt, dass für die Compose-Datei ein bestimmter Projektname erforderlich ist, sehe ich dies als separates Problem, das anders angegangen werden sollte.

Ich wollte 4 Compose-Dateien in 1 Verzeichnis haben. Der Verzeichnisname ist hier standardmäßig falsch. Die einzige Option, die ich habe, ist .env, die nur für 1 Compose-Datei in 1 Verzeichnis funktioniert.

Warum ich COMPOSE_PROJECT_NAME und -p ausschließe: _
COMPOSE_PROJECT_NAME und -p werden meiner Meinung nach in der Produktion nicht gespeichert, da Sie daran denken müssen, sie festzulegen. Oder erstellen Sie ein Startskript und denken Sie daran, Docker Compose nicht direkt zu verwenden. Wenn sich Person A auf diesen Mechanismus verlässt und Person B ihn nicht kennt, ist dies ein gewisser Fehler.
(Ich habe es oben bereits detailliert beschrieben)

@dnephin Für mich und mein Team wird die Anwendungslogik normalerweise in einem htdocs-Ordner in unserem Projektordner gespeichert. Auf diese Weise können wir andere verwandte Dokumente / Ressourcen in einem Verzeichnis zusammenfassen. Als Entwickler, der mit Remote-Entwicklern zusammenarbeitet. Es fällt mir leicht, sie Docker übernehmen zu lassen, wenn ich nichts über ihre Ordnerstruktur annehmen muss. Ich habe dies in der Vergangenheit angegeben. .Env ist für mich keine Option, da es normalerweise nicht Teil des Repos ist, das wir alle teilen.

Mir ist nicht klar, warum der Projektname wichtig ist. Kein Teil der Konfigurationsdatei sollte sich auf einen bestimmten Projektnamen stützen.

Es ist mir mehr als einmal passiert, dass ich auf einem Host ein Docker-Compose-Down durchgeführt habe - und einen anderen Container heruntergefahren habe als den, den ich wollte! Nur weil ich mich nicht erinnerte, dass es auch eine Konfiguration in einer .env -Datei gab.

Die einzige wichtige Eigenschaft des Projektnamens besteht darin, dass er nicht mit dem Namen eines anderen Projekts in Konflikt steht. Dies ist eigentlich ein Argument gegen die Aufnahme in die Datei docker-compose.yml. Ein Entwickler in einem Projekt verwendet häufig einen anderen Verzeichnisnamen für jedes Projekt, sodass die Standardeinstellung für die meisten Anwendungsfälle häufig korrekt ist.

Vielleicht trifft das auf Sie zu - nicht auf mich und viele andere. Meine App-Struktur ist wie myapp/app/docker-compose.yml . Alle meine Apps haben also den Verzeichnisnamen app . Und ich habe mehr als 1 Container auf einem Host.

Wenn die Standardeinstellung nicht korrekt ist, kann der Entwickler sie überschreiben (-p oder COMPOSE_PROJECT_NAME). Dies kann entweder ein Aliase sein oder in die ENV-Datei eingefügt werden.

Im Ernst, ich fühle mich wie in einem Kafka-Roman hier. Ist es nicht offensichtlich, dass Sie im Grunde alle Befehlszeilenoptionen für docker in ein docker-compose.yml - mit Ausnahme dieser einen großen Ausnahme?

Anstatt uns immer wieder zu fragen und unsere Antworten zu ignorieren, warum kann jemand den Widerstand nicht endgültig rechtfertigen? Und nein: "... aber ich brauche es nicht" ist kein gültiges Argument!

@dnephin Ich habe mehrere Projekte in ihren eigenen Git-Repos und um die Root-Projektverzeichnisse sauber zu halten, habe ich alle Docker-bezogenen Dinge in einen Unterordner namens docker (der Build-Kontext wird einfach zu .. , alles funktioniert wunderbar).

Um mehrere Projekte auf einem einzigen Server läuft, muß ich zur Zeit schaffen docker/.env.dist in jedem Repo- und cp docker/.env.dist docker/.env nach git clone . Ansonsten ist der Projektname nur docker , was ich natürlich nicht will. In einigen Fällen enthält .env Passwörter usw., daher ist das Kopieren von .env.dist ohnehin erforderlich, aber in den meisten Fällen existiert .env einfach, weil es keine Möglichkeit gibt, COMPOSE_PROJECT_NAME zu definieren docker-compose.yml .

Ich verstehe, dass es Fehler beim Starten und Stoppen der Container geben kann, wenn dasselbe COMPOSE_PROJECT_NAME zweimal in docker-compose.yml , aber das passiert bereits, wenn ich vergesse, .env.dist zu kopieren oder wenn ich versehentlich denselben Namen in zwei verschiedenen .env -Dateien auf demselben Server zuweise. Für mich wäre es ideal, wenn ich default_compose_project_name direkt in docker-compose.yml und dann den Wert in .env überschreiben könnte, wenn ich beispielsweise eine Staging-Kopie eines Projekts ausführen möchte . Dies wäre 100% v. Chr., Aber bequemer.

Ich habe dies in der Vergangenheit angegeben. .Env ist für mich keine Option, da es normalerweise nicht Teil des Repos ist, das wir alle teilen.

Vielleicht ist das die Hauptursache von allem, sagte ich vorher, dass docker-compose diese Datei "entführt" hat und wir gezwungen waren, unsere Sachen in app.env umzubenennen.

Vielleicht wäre docker-compose.env die richtige Wahl gewesen.

FWIW: Wir ändern nur .env Dateien in der Produktion. Die yml Dateien werden bei Bedarf mit docker-compose.override.yml .

Eine Problemumgehung besteht auch darin, Ihre yml-Dateien so zu definieren, dass sie nicht ohne eine .env -Datei beginnen, z. mit einer Variablen image: $IMAGE .

Dies ist eine Problemumgehung für meine 4 Docker-Compose-Dateien in einem Verzeichnis über @ schmunk42 ? "Ja wirklich?"

@RobIsHere Aber du musst trotzdem -f , oder?

Als Antwort auf @dnephin in diesem Kommentar :

Mir ist nicht klar, warum der Projektname wichtig ist.

Dies ist wichtig, da es sich auf den Namen der Docker-Container auswirkt, die von docker-compose verwaltet werden. Wenn Sie vergessen, den Projektnamen festzulegen, findet docker-compose ps die Container, die Sie zuvor mit docker-compose --project-name <project_name> up -d <container_name> .

Wenn Sie den globalen Befehl docker ps ausführen, wird der Projektname in die Liste der ausgeführten Container aufgenommen, sodass Sie wissen, woher sie stammen. Wenn Sie beispielsweise mehrere Codeprojekte gleichzeitig testen, die alle MySQL verwenden und jeweils einen mysql -Container haben, zeigt docker ps eine mehrdeutige Liste von Containern an. Daher ist der Projektname im Kontext vieler Docker-Projekte wichtig, die auf demselben Computer ausgeführt werden.

Kein Teil der Konfigurationsdatei sollte sich auf einen bestimmten Projektnamen stützen.

Es macht keinen Sinn, den Projektnamen an einer anderen Stelle als jede andere Variable festzulegen, die dem Docker Compose-Projekt zugeordnet ist.

Die einzige wichtige Eigenschaft des Projektnamens besteht darin, dass er nicht mit dem Namen eines anderen Projekts in Konflikt steht. Dies ist eigentlich ein Argument gegen die Aufnahme in die Datei docker-compose.yml.

Aus den in meinem ersten Absatz genannten Gründen ist dies nicht die "einzige wichtige Qualität des Projektnamens". Es dient der Benutzerfreundlichkeit und dem Verständnis.

Ein Entwickler in einem Projekt verwendet häufig einen anderen Verzeichnisnamen für jedes Projekt, sodass die Standardeinstellung für die meisten Anwendungsfälle häufig korrekt ist.

In dem nicht standardmäßigen Fall, in dem ein Entwickler _all_-bezogene Docker-Dateien in das Verzeichnis docker legt, was eine durchaus vernünftige Methode zum Organisieren eines Docker-Projekts darstellt, führt die Magie, mit der der Projektname festgelegt wird, zu widersprüchlichen Projektnamen. In diesem speziellen Fall treten also dieselben Konflikte auf, die Sie erwähnen. Sie müssen den Entwickler nicht vor Kollisionen mit Projektnamen schützen, wenn er den Projektnamen ohnehin explizit festlegt.

Wenn die Standardeinstellung nicht korrekt ist, kann der Entwickler sie überschreiben (-p oder COMPOSE_PROJECT_NAME). Dies kann entweder ein Aliase sein oder in die ENV-Datei eingefügt werden.

Das Festlegen von Umgebungsvariablen ist eine zusätzliche Komplexitätsebene, die nicht erforderlich ist. Wenn Sie ein Projekt für Entwickler mit Versionskontrolle freigeben, ist es sinnvoll, nur Dateien zu verwenden. Das Einfügen von Befehlszeilenparametern in jeden Aufruf ist mühsam und fehleranfällig. Und die .env -Datei kann in der Versionskontrolle nicht freigegeben werden, da sie _benutzerspezifische_ Variablen enthalten soll, keine _projektspezifischen_. Daher sind die aktuellen Möglichkeiten zum Festlegen eines Projektnamens unzureichend.

Ich bin nicht gegen eine Projektdatei, die den Projektnamen definiert. Ich möchte nur verstehen, warum diese Funktion für einige so wichtig ist. Wenn es daran liegt, dass für die Compose-Datei ein bestimmter Projektname erforderlich ist, sehe ich dies als separates Problem, das anders angegangen werden sollte.

Alle Variablen, die die Funktionsweise von docker-compose sollten sich an derselben Stelle befinden, in der Datei docker-compose.yml . Die derzeitigen Möglichkeiten zum Festlegen eines Projektnamens führen zu unnötiger Komplexität.

Nahezu jeder, der diese Ausgabe abonniert hat, stimmt diesen Punkten zu.

Das Hinzufügen der Möglichkeit, den Projektnamen auf docker-config.yml festzulegen, steht nicht einmal im Widerspruch zu aktuellen Funktionen. Es gibt keinen Grund, es nicht zu implementieren.

@ schmunk42 Als ich das letzte Mal nachgesehen habe, hat Docker uns nicht erlaubt, den Namen unserer .env-Datei auszuwählen. Habe ich etwas verpasst (es ist schwer, mit den Änderungen Schritt zu halten). Wenn Sie es in etwas wie docker-compse.env ändern, wird es für meinen Anwendungsfall behoben. Das Problem, das ich habe, ist, dass ich zwei sehr beliebte Technologien verwende, für die beide eine .env-Datei erforderlich ist. Das PHP Laravel Framework verfolgt diese Datei nicht im Repository und in Produktionsumgebungen ist sie manchmal nicht vorhanden.

Ich fand, dass dies ein echter Stoppblock war, als ich Docker zum ersten Mal einführte, weil wie @RobIsHere zeigt. Alle meine Projektverzeichnisse haben das Format myapp/htdocs/docker-compose.yml . In den frühen Tagen der Einführung von Docker habe ich versehentlich andere Container gelöscht, die ich nicht beabsichtigt hatte. Es wäre besser gewesen, wenn Docker das Projekt zufällig benannt hätte, als in meinem Fall den Ordnernamen zu verwenden.

Ich habe mehrere andere Remote-Entwickler, die Docker einführen. Als Team fällt es mir immer leichter, diese Entwickler anzuweisen, immer / nur docker-compose up , um diese Anwendungen zum Laufen zu bringen. Je weniger diese Early Adopters über Docker wissen, desto besser. Sobald sie die Kraft dahinter sehen, werden sie sich selbstständig machen.

Zusammenfassend scheinen die Anwendungsfälle zu sein, wenn die Standardeinstellung nicht angemessen ist. Es gibt bereits Möglichkeiten, die Standardeinstellung zu überschreiben, diese können jedoch fehleranfällig und für Early Adopters nicht offensichtlich sein.

Fälle, in denen die Standardeinstellung nicht angemessen ist, sind:

• Mehrere Compose-Dateien im selben Verzeichnis (Sie müssen bereits -f angeben, um sie auszuführen).
• Verwenden des gleichen Verzeichnisnamens für alle Projekte (ich denke, dazu müssen Sie auch -f angeben. Eine mögliche Problemumgehung besteht darin, einen eindeutigen Verzeichnisnamen zu verwenden).

@dnephin Ich würde hinzufügen, ein weniger möglicher Stolperstein für frühe Anwender von Docker.

@dnephin Sie hatten auch diese Bedenken in diesem Kommentar :

Ursprünglich wollte ich den Namen in der Datei docker-compose.yml, aber nachdem ich mehr darüber nachgedacht habe, gefällt mir die Idee einer separaten Datei wirklich gut. Eine separate Datei bietet Ihnen die Möglichkeit, sie bei Bedarf außerhalb der Versionskontrolle zu halten (in Fällen, in denen jeder Benutzer einen anderen Projektnamen haben soll).

Wenn Sie die Reihenfolge der Auflösung des Projektnamens wie folgt festlegen, wird das Problem behoben (größere Zahlen überschreiben kleinere):

1. docker-compose.yml
2. Die Umgebungsvariable COMPOSE_PROJECT_NAME
3. Die Befehlszeilenoption --project-name

Als ich das letzte Mal nachgesehen habe, hat Docker uns nicht erlaubt, den Namen unserer .env-Datei auszuwählen.

@fiveanddone AFAIK Sie können das nicht tun, aber es würde auch nur das Problem verschieben, da Sie dann wissen müssten, welche ENV-Datei Sie für das Projekt benötigen würden.

In unserem Fall mit phd5 haben wir die (App) -Umgebung auf src/ verschoben und .env ist ausschließlich die "Control-Environment-Datei". Ich habe versucht, dies hier zu erklären.
Ich mag das nicht und hätte es nicht alleine geändert. Ich weiß, dass dies bei vielen Projekten möglicherweise nicht möglich ist.
Aber ein .env von Ihrer Anwendung auf der gleichen Ebene wie Ihr docker-compose.yml wird sehr ärgerlich, weil a) Sie Variablen in Ihrer "Kontrollumgebung" erhalten, die nicht dorthin gehören und b) Sie müssen diese Variablen an Ihren Container weiterleiten, wenn Sie sie dort benötigen, und c) Sie können sie in Ihrer app.env -Datei nicht mehr überschreiben / ändern.

@dnephin Was ist mit der Einführung von docker-compose.env als bevorzugte Env-Datei und der Verwendung von .env als Fallback? Sie haben dasselbe einmal mit fig.yml .

Ich denke nicht, dass dies das Problem für alle behebt. Die Benennung der .env -Datei scheint mir ein anderes Problem zu sein.

Ich denke, der Kern des Problems ist folgender:

Das ursprüngliche Design von docker-compose up sollte ein einzelner (kurzer) Befehl sein, den Sie ausführen können, um Dienste zum Laufen zu bringen. Das erwarten Entwickler davon. Dieses Verhalten kann jedoch für einige Benutzer (in diesen Fällen ) nicht erreicht

Es gibt viele Möglichkeiten, um das Problem zu umgehen, aber keine, die für alle zu funktionieren scheint.

Ich denke, die Rangfolge (vom höchsten zum niedrigsten) muss ungefähr so ​​sein:

1. --project-name (überschreibt immer)
2. COMPOSE_PROJECT_NAME Umgebungsvariable
3. Ein vom Benutzer definierter Standard, der von jeder versionierten Datei getrennt ist
4. Ein vom Projekt definierter Standard, der eingecheckt werden kann
5. Der Verzeichnisname (der Standard, wenn nichts angegeben ist)

(3) könnte mit einer .docker/project-name -Datei erreicht werden (wie im OP vorgeschlagen)
(4) könnte mit einem Feld in der Datei docker-compose.yml werden

Es ist bedauerlich, dass es so viele verschiedene Möglichkeiten geben muss, den Projektnamen festzulegen.

@dnephin in Bezug auf 3, einen Benutzer einen Standard gedacht , keine Notwendigkeit, eine Datei zu erstellen

Hmm ... Und was ist, wenn wir das Problem ein wenig verallgemeinern und einfach den Abschnitt default_environment in docker-compose.yml einführen? Auf diese Weise können wir COMPOSE_PROJECT_NAME festlegen, ohne ein spezielles Feld in das yaml einzufügen, aber wir können auch andere Standardvariablen definieren, die wahrscheinlich an anderer Stelle in der Datei vorhanden sind. Dies reduziert die Anzahl der Fälle, in denen .env.dist auf .env kopiert werden muss und die Kosten für das Vergessen geringer sind.

Anwendungsbeispiel:

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

Dieses Yaml ist dem sehr ähnlich, was ich sehr oft habe - es beschreibt eine vis-Skizze, die immer einen Dienst namens web , aber auch von einem Mini-API-Server und möglicherweise einem Container mit einer Datenbank gesichert werden kann. Es wird davon ausgegangen, dass https://github.com/jwilder/nginx-proxy an vorderster Front steht und die realen Ports 80 und 443 abhört.

Unabhängig davon, ob ich mich auf einem lokalen Computer oder auf einem Remote-Server befinde, muss ich im Moment daran denken, .env und sicherzustellen, dass _all_ Umgebungsvariablen dort festgelegt sind. Wenn ich beispielsweise SUBDOMAIN vergessen habe, startet der Container, aber der Webserver bleibt defekt.

Mit dem Abschnitt default_environment könnte ich alle meine Produktionsvariablen in einer Datei haben und müsste auf dem Server nicht .env.dist kopieren. Auf dem lokalen Computer habe ich im obigen Beispiel nur eine einzelne Variable in .env , was ROOT_HOST=example.com.dev (oder könnte ich sogar export ROOT_HOST=example.com.dev im Bash-Profil? )

Zusammenfassend lässt sich sagen, dass der Abschnitt default_environment in docker-compose.yml nicht nur das Problem lösen kann, über das wir gerade sprechen, sondern auch ein paar zusätzliche nette Tricks ermöglichen kann, während er 100% v. Chr. Ist und leicht zu verstehen ist!

WDYT?

Das hört sich gut an, kann in einigen Szenarien für mich nützlich sein.

Beachten Sie jedoch, dass angesichts der oben genannten (hitzigen) Diskussion Ihre
Die Lösung bedeutet ungefähr: „Anstatt der Datei eine neue Datei hinzuzufügen
yml, wie wäre es, wenn wir einen neuen Abschnitt hinzufügen? “ :) :)

Am Dienstag, 28. Februar 2017, 00:02 Uhr Alexander Kachkaev [email protected]
schrieb:

Hmm ... Und was ist, wenn wir das Problem ein wenig verallgemeinern und einfach vorstellen
Abschnitt default_env in docker-compose.yml. Auf diese Weise definieren wir
COMPOSE_PROJECT_NAME ohne ein spezielles Feld in das yaml einzufügen, aber
wird auch in der Lage sein, andere Standardvariablen zu definieren, die wahrscheinlich sind
an anderer Stelle in der Datei vorhanden. Dies reduziert die Anzahl der Fälle
wenn .env.dist nach .env kopiert werden muss und die Kosten für das Vergessen
dies wird weniger sein.

Anwendungsbeispiel:

~ / Projekte / Skizzen / Skizze-42 / Docker / Docker-Compose.yml

Version 2"
default_env:
SUBDOMAIN = Skizze-42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = Skizze-42
Dienstleistungen:
Netz:
bauen:
Kontext: ../
Docker-Datei: Docker / Docker-Datei
Umgebung:
- VIRTUAL_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- VIRTUAL_PORT = 80
- VIRTUAL_NETWORK = Proxy
- LETSENCRYPT_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- LETSENCRYPT_EMAIL = admin @ $ {ROOT_HOST}
Neustart: immer
Netzwerke:
- Proxy

Netzwerke:
Proxy:
extern:
Name: Proxy

Dieses Yaml ist sehr ähnlich zu dem, was ich sehr oft habe - es beschreibt ein Vis
Skizze, die immer einen Dienst namens Web hat, aber auch gesichert werden kann
von einem Mini-API-Server und möglicherweise einem Container mit einer Datenbank. Es wird davon ausgegangen
dass https://github.com/jwilder/nginx-proxy vorne sitzt und zuhört
zu den realen Ports 80 und 443.

Im Moment, egal ob ich mich auf einem lokalen Computer oder auf einem Remote-Server befinde,
Ich muss daran denken, .env zu pflegen und auch sicherzustellen, dass alle
Umgebungsvariablen werden dort gesetzt. Wenn ich zum Beispiel vergessen habe
SUBDOMAIN, der Container startet, aber der Webserver bleibt defekt.

Mit dem Abschnitt default_env könnte ich meine gesamte Produktion haben
Variablen vorhanden und ich müsste .env.dist nicht auf den Server kopieren.
Auf dem lokalen Computer habe ich nur eine Variable in .env eingefügt
ROOT_HOST = example.com.dev (oder vielleicht könnte ich sogar exportieren
ROOT_HOST = example.com.dev im Bash-Profil?)

Zusammenfassend kann der Abschnitt default_env in docker-compose.yml nicht nur
Lösen Sie das Problem, das wir jetzt diskutieren, aber es kann auch ein paar weitere nette Funktionen ermöglichen
Szenarien!

WDYT?

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/745#issuecomment-282885661 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AAQJJZumr10j3i17gPxrSyA-n8CwvsXTks5rg1X_gaJpZM4DLBNs
.

Wenn Sie den "Projektnamen" in der Datei docker-compose.yml haben, wird ein Problem mit unserem Stack behoben.
Wir haben ein Monolith-Repo mit einem standardisierten Baum, der mehrere Projekte bearbeitet, was mehr oder weniger so aussieht:

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

Es ist offensichtlich komplexer als das in der realen Welt, daher können wir die Datei docker-compose.yml nicht einfach in den Ordner "projectA / projectB" verschieben.

Wir haben eine CLI im Stammverzeichnis, die fragt, welche Projekte gestartet werden sollen. Da der Projektname direkt vom übergeordneten Ordner der Datei docker_compose.yml abhängt, treten Konflikte auf.

Da wir den Docker-Compose-Befehl (der in unser CLI-Skript eingeschlossen ist) nicht selbst schreiben, können wir dem Befehl nicht einfach das Argument "-p" manuell hinzufügen.
Eine Lösung für uns wäre, immer einen Projektnamen innerhalb des CLI-Skripts zu generieren, sodass wir beim Aufrufen von Docker-Compose immer ein "-p" haben, basierend auf dem absoluten Pfad, aber es klingt seltsam.

Ein Typ hier sagte, "es funktioniert die meiste Zeit, weil bei den meisten Projekten die Datei docker-compose.yml sich im Stammordner des Projekts befindet und Projekte einen anderen Namen haben, um Konflikte zu vermeiden", kann ich einfach nicht zustimmen diese. Es befindet sich nicht immer im Stammordner.

Warum ist es möglich, den "Containernamen" in einer docker-compose.yml-Datei (Deaktivierung der Skalierung) für einen Dienst zu definieren, kann jedoch keinen "Projektnamen" für die docker-compose.yml-Datei selbst auf derselben Ebene wie definieren "Version" / "Dienste" / "Netzwerke" / "Volumes"?

Dies scheint bei Verwendung von scale notwendig zu sein, damit Containernamen offensichtlich sind. (zB <project_name>_<container_name>_1 ).

Dies ist hilfreich, wenn Sie den Containernamen für DNS verwenden.

Kam hierher in der Hoffnung, dass dies getan wurde. Links enttäuscht. 3 Jahre +

Ja, es ist eines der dümmsten Usability-Probleme von Docker und es wird nicht behoben.

Wir haben so viel Zeit damit verbracht, mit den Entwicklern darüber zu streiten, und obwohl es einen Konsens gab, gab es kein Eingeständnis, dass es ein schlechtes Design ist.

Es ist frustrierend, weil es offensichtliche Benutzerunterstützung dafür gibt, aber da es nicht zu den Anwendungsfällen der Entwickler passt, werden wir dieses Jahr Jahr für Jahr wieder aufgewärmt.

Was bringt Docker-Compose, wenn wir Optionen mit cli hinzufügen müssen?
Ich hatte einige Container dank des Namensschemas überschrieben.

Heute habe ich ein weiteres docker-compose -Projekt mit einer weiteren .env -Datei eingerichtet, um dem Projekt einen dauerhaften Namen zu geben. Also dachte ich, ich würde mich mit diesem Thema befassen, da es einige Jahre her ist, seit ich das letzte Mal nachgesehen habe. Aber nichts Neues hier, soweit ich sehen kann? Ich denke, ich muss weiterhin die .env Problemumgehung verwenden. Das Benennen eines Projekts in der yaml-Datei scheint mir das Grundlegendste zu sein, was Sie tun können, aber ich denke, es gibt etwas, das ich einfach nicht verstehe, da es noch nicht gelöst wurde.

Es ist einfach sinnlos, den Projektnamen extern (über die Befehlszeile oder Variable) angeben zu müssen, ihn jedoch nicht in der Datei docker-compose.yml festlegen zu können - der Datei, in der absolut alles andere angegeben ist. Es gibt viele Fälle, in denen ein Prozess möglicherweise einen bestimmten Stapel von Diensten basierend auf einer beliebigen docker-compose.yml -Datei adressieren muss, unabhängig vom Namen des übergeordneten Verzeichnisses, der Shell-Umgebung oder dem Vorhandensein einer bestimmten Zeile in einem bestimmten .env file. Ich möchte nicht, dass meine CI-Jobs ständig "herausfinden" müssen, wie der Projektname lauten soll - er sollte in docker-compose.yml klar angegeben sein, damit meine Jobs ihn extrahieren und verwenden können.

Dies scheint bei diesem Projekt immer wieder vorzukommen. Docker ist eine wunderbare Technologie, aber manchmal frage ich mich, ob die Entwickler tatsächlich Erfahrungen aus der Praxis haben, oder sind sie alle nur 18-jährige Hacker, die glauben, sie am besten zu kennen? Die Leute wollen dieses Zeug für echte Arbeit verwenden und nicht ihre Zeit damit verbringen, ständig nach Problemumgehungen zu suchen.

Ich vermute, dass das Team dieses Problem inzwischen ignoriert. Der Versuch, Docker-Entwickler zu überzeugen, kann, gelinde gesagt, ein echtes Problem sein.

Klare Argumente werden mit einer seltsamen Logik konterkariert, die wenig Sinn macht. Die Meinung realer Benutzer, die alle aus demselben Grund hierher kommen, wird ignoriert. Es ist Schande.

Ich möchte nicht, dass meine CI-Jobs ständig "herausfinden" müssen, wie der Projektname lauten soll - er sollte in der docker-compose.yml klar angegeben sein, damit meine Jobs ihn extrahieren und verwenden können.

Haben Sie das Problem, dass Ihr Stapel den Namen "build1234" hat und / oder wie möchten Sie den Namen des Stapels an einer anderen Stelle verwenden, z. B. docker exec build1234_myservice script.sh ?

Könnte nicht in einen Anwendungsfall passen, aber dafür, dass es gesagt wurde ...

In unseren Setups ändern wir nur .env Dateien, wenn wir ein (Klon-) Projekt einrichten. Wenn wir Änderungen oder eine dynamische Konfiguration benötigen, verwenden wir Variablen von .env in docker-compose.yml . Ein Vorteil ist, dass Docker-Compose Sie warnt (oder fehlschlägt), wenn eine Variable fehlt.

Ich möchte Ihnen nicht sagen, dass Sie Ihre Workflows ändern müssen, da mich dieses Problem ebenfalls geärgert hat.
Es ist im Grunde so etwas wie, wir behandeln Änderungen an docker-compose.yml eher wie Änderungen am Quellcode, während .env ausschließlich Konfiguration ist. Ich stimme aber auch zu, dass es in docker-compose.yml mehrere Optionen gibt, wie network die stark vom Projekt abhängen. Zurück zum oben Gesagten; Ich würde eine Variable .env für das Netzwerk definieren. 🤐

Ich möchte Ihnen nicht sagen, dass Sie Ihre Workflows ändern müssen, da mich dieses Problem ebenfalls geärgert hat.

Ich dachte noch etwas über meine eigene Situation nach. Ich habe eigentlich kein Problem damit, den Projektnamen extern festzulegen, und tatsächlich mache ich dies mit dem Flag -p <project_name> , das es ermöglicht, eindeutige Instanzen des Stapels in CI zu isolieren und mehrere Stapel gleichzeitig auszuführen, wenn notwendig. Nur diese CI-Kette muss diesen Projektnamen kennen, damit er automatisch generiert oder zufällig (aber bekannt) wird, kein Problem. Ich habe auch kein Problem mit der Verwendung einer Umgebungsvariablen zum Überschreiben des Standardnamens, finde jedoch den Trick .env nicht offensichtlich.

Es gibt jedoch auch andere Situationen, in denen es nützlich ist, den Standardnamen des Projekts explizit irgendwo zu definieren. Warum wird der übergeordnete Verzeichnisname als Quelle für diesen Namen verwendet? Das ist für mich die Schwachstelle hier. Es kann von überall her übernommen werden - die Auswahl eines übergeordneten Verzeichnisses erscheint einfach willkürlich und ohne großen Grund (z. B. in fast allen meinen Projekten befindet sich die Datei docker-compose.yml in einem Unterverzeichnis namens docker ). Wenn es also willkürlich sein soll, speichern Sie es an einem expliziteren Ort wie der yml-Datei, anstatt externe Nebenwirkungen zu verursachen, indem Sie die Namen der übergeordneten Verzeichnisse beeinflussen, die in vielen Fällen völlig unabhängig vom Inhalt des Verzeichnisses sein sollten (basierend auf den Jahren) Erfahrung im Umgang mit wiederverwendbaren Ressourcen).

Es kann von überall her übernommen werden - die Auswahl eines übergeordneten Verzeichnisses scheint nur willkürlich und ohne großen Grund zu sein (z. B. befindet sich die Datei docker-compose.yml in fast allen meinen Projekten in einem Unterverzeichnis namens docker).

Wenn Sie etwas anderes als eine zufällige ID benötigen, sehe ich keine echte Alternative zum übergeordneten Verzeichnis. Zumindest haben Sie die Möglichkeit zu wissen, woher Ihr Stapel "kam".
Aber ich stimme Ihnen auch zu, da wir in unseren Projekten Teststacks in tests -Ordnern haben, die - ohne eine .env -Datei - auch schlecht miteinander kollidieren würden. Aus diesem Grund habe ich vorgeschlagen, eine Datei mit dem Namen docker-compose.env zu bevorzugen, die meiner Meinung nach viel klarer wäre.

Würdet ihr diesen Fehler entweder einfach schließen und zugeben, dass es euch egal ist, oder die unglaublich einfache Sache implementieren, die die große Mehrheit von uns will? Es ist 2,86 Jahre später. Steig aus dem Topf. Besitze deine Entscheidungen oder behebe deine Fehler. Wie auch immer Sie es betrachten möchten. Mach mehr als nichts.

@matsaman und alle Leute, die seinem Kommentar den Daumen hoch geben:

Würdet ihr diesen Fehler entweder einfach schließen und zugeben, dass es euch egal ist, oder die unglaublich einfache Sache implementieren, die die große Mehrheit von uns will? Es ist 2,86 Jahre später. Steig aus dem Topf. Besitze deine Entscheidungen oder behebe deine Fehler. Wie auch immer Sie es betrachten möchten. Mach mehr als nichts.

Wer seid "ihr"? In Open Source besitzt die Community die Entscheidungen und behebt die Fehler anderer. Docker ist Open Source. Überlegen Sie, ob Sie eine Pull-Anfrage senden möchten, anstatt zu jammern.

Ich bin auch traurig, dass dies noch nicht umgesetzt wurde. Aber in Open Source tragen wir entweder dazu bei oder warten geduldig.

CLI arg:

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Scheitern.

Env-Datei:

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Scheitern.

Vorgeschlagene Lösungen mit Projektname in der yml-Datei:

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

Yay!

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

Ö/

Wer seid "ihr"?

@benjaminwood Es sind die Betreuer dieses Projekts. Ihr Argument wäre sinnvoll, wenn wir über eine komplexe Änderung sprechen würden und niemand die Zeit dafür finden würde.

Dies ist hier ganz offensichtlich nicht der Fall: Die Implementierung wäre für diejenigen, die mit der Codebasis vertraut sind, wahrscheinlich sehr einfach und für jemanden von außerhalb viel schwieriger. Es ist also nicht so, dass niemand Zeit dafür hat, sondern dass die Betreuer es nicht wollen . Und das ist es, was die Unterstützer hier angesichts der langen Zeit, in der diese Ausgabe jetzt offen ist, und der Masse von: +1: hier äußerst nervig finden.

Die hier immer wieder veröffentlichten Problemumgehungen sind bekannt, gelten jedoch nicht für alle. Und ich konnte immer noch keine Antwort finden, warum ausgerechnet in den Funktionen von docker-compose.yml fast nur der Projektname weggelassen wurde. Wenn jemand denkt, es gehört nicht dorthin, dann benutze es einfach nicht! Aber behindern Sie nicht Ihre Meinung zu anderen, wenn die Nachfrage danach so überwältigend offensichtlich ist.

Betrachten wir dies von einem anderen Punkt aus.

Wie finde ich heraus, welchen Projektnamen mein Stapel hat, wenn ich mich in einem Ordner mit einer docker-compose.yml -Datei befinde?
Das ist eine ziemlich grundlegende Frage, aber es gibt keine einfache Antwort darauf.

Derzeit ist es (sortiert nach Priorität):

• der Wert von -p
• der Wert von COMPOSE_PROJECT_NAME aus Ihrer Umgebung
• Der Wert von COMPOSE_PROJECT_NAME aus Ihrer .env -Datei
• der aktuelle Verzeichnisname

Um der Anwalt des Teufels zu sein, warum sollte man diesem bereits verwirrenden Setup einen fünften hinzufügen?

Trotz dieser Entscheidung sollte es eine "trockenlauffähige" Information über den aktuellen Namen geben. Weder docker-compose config hat das, noch docker-compose ps wenn der Stack nicht läuft.
Vielleicht ist docker-compose create die beste derzeit verfügbare Option, aber alles andere als perfekt.

Es sollte mindestens so etwas wie docker-compose config --project-name . Derzeit muss ich die oben genannten Standorte kennen und in der richtigen Reihenfolge überprüfen.

Wie finde ich heraus, welchen Projektnamen mein Stapel hat, wenn ich mich in einem Ordner mit einer Datei docker-compose.yml befinde?

Nochmals: Wenn Sie es nicht verwenden möchten, verwenden Sie es nicht! Wenn Sie mit Ihrer Lösung zufrieden sind - gut für Sie! Für Sie wird sich nichts ändern, sodass Sie überhaupt nicht verwirrt sind!

Aber können Sie nicht akzeptieren, dass andere andere Anforderungen haben? Wir wollen nur, dass dieses logisch fehlende Stück endlich hinzugefügt wird.

Um der Anwalt des Teufels zu sein, warum sollte man diesem bereits verwirrenden Setup einen fünften hinzufügen?

Der einzige Grund, warum es verwirrend sein kann, ist, dass der Projektname überhaupt nicht in docker-compose.yml . Ansonsten wäre jetzt alles in dieser Datei. Wir können eine Rangliste definieren - kein Problem.

Derzeit muss ich die oben genannten Standorte kennen und in der richtigen Reihenfolge überprüfen.

Warum kennen Sie den Docker-Namen Ihres Projekts nicht und warum ist das für Sie überhaupt relevant? Und warum verwenden Sie nicht in allen Ihren Projekten denselben Mechanismus, wenn er Sie so verwirrt?

Nochmals: Wenn Sie es nicht verwenden möchten, verwenden Sie es nicht! Wenn Sie mit Ihrer Lösung zufrieden sind - gut für Sie! Für Sie wird sich nichts ändern, sodass Sie überhaupt nicht verwirrt sind!

Bei meiner Frage ging es nicht um die Verwendung einer neuen Funktion, sondern um das Fehlen einer vorhandenen. Der Projektname ist die einzige relevante Information, mit der docker-compose einen bestimmten Satz von Containern startet und stoppt.
Die Leute in diesem Thread beschweren sich über das Töten der falschen Container, da der Projektname nicht Teil des Stapels ist.

Aber können Sie nicht akzeptieren, dass andere andere Anforderungen haben? Wir wollen nur, dass dieses logisch fehlende Stück endlich hinzugefügt wird.

Wenn Sie dies hinzufügen, beschweren sich die Leute über das Töten der falschen Container, da diese Teil des Stapels sind, da zuvor der Verzeichnisname verwendet wurde.

Der einzige Grund, warum es verwirrend sein kann, ist, dass der Projektname in erster Linie in docker-compose.yml weggelassen wurde. Ansonsten wäre jetzt alles in dieser Datei. Wir können eine Rangliste definieren - kein Problem.

Eigentlich kann man dies nicht auf BC-Weise hinzufügen, da es eine niedrigere Priorität als der Verzeichnisname haben müsste, was es unbrauchbar machen würde. Deshalb habe ich gefragt, wie man den Projektnamen bekommt.

Warum kennen Sie den Docker-Namen Ihres Projekts nicht und warum ist das für Sie überhaupt relevant?

Da ich normalerweise den Verzeichnisnamen verwende, aber manchmal einen benutzerdefinierten Wert in .env - ist dies relevant, da der Projektname die Container definiert, für die Aktionen ausgeführt werden.

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

Dadurch wird Ihr erster Stapel beendet. Dies entspricht dem Projektnamen in der Datei yml .

Und warum verwenden Sie nicht in allen Ihren Projekten denselben Mechanismus, wenn er Sie so verwirrt?

Ich verwende nur die Standardfunktionen von docker-compose . Meistens ist der Verzeichnisname in Ordnung, aber falls ich ihn umbenennen muss, aber weiterhin mit denselben Containern arbeiten möchte, füge ich eine .env -Datei hinzu.

Wenn Sie dies hinzufügen, beschweren sich die Leute über das Töten der falschen Container, da diese Teil des Stapels sind, da zuvor der Verzeichnisname verwendet wurde.

Das macht keinen Sinn. Wenn jemand den Projektnamen nicht zu docker-compose.yml hinzufügt, ändert sich nichts. Und wenn sie es hinzufügen, dann weil sie es dort wollen! Niemand wird es hinzufügen, wenn er es nicht braucht.

Und selbst wenn sie es tun, ist alles in Ordnung. Ich verstehe nicht, welches Problem Sie hier zu konstruieren versuchen. Du machst Dinge zu kompliziert.

Wenn Sie alle Optionen mischen, bei denen ein Projektname konfiguriert werden könnte, würde ich sagen, dass dies Ihr Problem ist. Das solltest du gar nicht machen.

3 der 4 Optionen im Prioritätsbaum sind wertlos, wenn Sie mehrere benannte Compose-Dateien in einem Verzeichnis haben. Sagen Sie mir nicht, dass ich Unterverzeichnisse erstellen soll, da ich immer noch eine ENV-Datei für sie freigebe.

Sagen Sie mir nicht, dass ich Unterverzeichnisse erstellen soll, da ich immer noch eine ENV-Datei für sie freigebe.

Teilen Sie eine anwendungsspezifische .env -Datei, die in env_file ?
Oder der, den docker-compose benutzt?
Oder mischst du sie?

Das macht keinen Sinn. Wenn jemand den Projektnamen nicht zu docker-compose.yml hinzufügt, ändert sich nichts.

Das ist nicht das Problem, aber wenn es hinzugefügt wird, ändert sich das Verhalten drastisch.

Wenn wir einen Stapel in ein neues Verzeichnis kopieren, um eine temporäre Instanz zu erzeugen (dh um ein Upgrade zu testen), müssen wir docker-compose.yml überhaupt nicht berühren. Wenn dies jedoch Teil des Stapels ist, müssen wir entscheiden, ob wir es mit .env überschreiben oder ob wir es in docker-compose.yml ändern.

Ja, es könnte sein, dass es gar nicht erst hinzugefügt werden sollte, aber eine andere Option hier macht die Dinge auch nicht einfacher und prägnanter.

Ich habe eine gemeinsame einzelne .env-Datei, die von 4 benannten Compose-Dateien (im selben Verzeichnis) verwendet wird. Keine Umgebungsvariablen. Keine Shell-Skripte. Ich benutze nur komponieren.

Ich würde das vorziehen

docker-compose -f service1.yml up -d

Stattdessen ist es eher so

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

@ schmunk42 Sie glauben ernsthaft, dass dies eine Lösung ist, um jedes Mal 'COMPOSE_PROJECT_NAME = ...' für jeden Docker-Compose-Befehl einzugeben, möglicherweise zusätzlich zum Compose-Dateinamen? Dazu müssen Sie auch den Projektnamen kennen und sich daran erinnern. Die Möglichkeit, den Projektnamen in einer Umgebungsvariablen anzugeben, hat sicherlich seine Verwendung, aber in einigen Fällen möchten Sie nur ein Verzeichnis mit ein paar yml-Dateien haben und in der Lage sein, Projekte auf kinderleichte Weise zu verwalten, ohne dies zu müssen Erinnern Sie sich an die Projektnamen, die Sie vor Monaten ausgewählt haben, ohne daran denken zu müssen, Umgebungsvariablen zu exportieren.

Können Sie nicht einen Ordner pro Dienst verwenden und trotzdem eine .env -Datei im obersten Ordner haben?

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

Schreiben Sie einfach den Projektnamen in die Datei (-path) 😉

Ich gebe auf. Es ist offensichtlich, dass sich die Kundenbasis dafür geändert hat.

Lassen Sie mich wissen, was mit dem Vorschlag, den ich Ihnen gemacht habe, nicht stimmt.

Anfangs hatte ich die gleichen Bedenken, aber wir haben unsere Workflows an die verfügbaren Funktionen angepasst.

Ich kann mich nicht erinnern, in den letzten 2 Jahren versehentlich einen Stapel von niemandem aus unserem Team getötet zu haben. Auf diese Weise führen wir> 200 Stapel mit rund 1.000 Containern und 1.000 automatischen oder manuellen Umschichtungen aus.

Ich möchte mich hier nicht wirklich engagieren ... aber ich kann nicht widerstehen.

Es gibt einen sehr wichtigen Unterschied zwischen einer "Lösung" angesichts der heutigen Situation und der "richtigen" Lösung angesichts der vorhandenen Möglichkeiten. Dieses Problem sollte sich darauf konzentrieren, die "richtige" Lösung zu finden, was für mich ziemlich offensichtlich ist, obwohl einige möglicherweise immer noch anderer Meinung sind.

@ schmunk42 & @mikehaertl

Ich kann mich nicht erinnern, in den letzten 2 Jahren versehentlich einen Stapel von niemandem aus unserem Team getötet zu haben .

Ich muss fragen. Ich sehe, dass Sie beide Teil der Codemix-Organisation sind . Seid ihr Mitarbeiter? Ich fange an mich zu fragen, ob ihr zwei hinter den Kulissen rotfl seid.

Derzeit ist es (sortiert nach Priorität):

1. der Wert von -p
2. Der Wert von COMPOSE_PROJECT_NAME aus Ihrer Umgebung
3. Der Wert von COMPOSE_PROJECT_NAME aus Ihrer .env-Datei
4. der aktuelle Verzeichnisname

Um der Anwalt des Teufels zu sein, warum sollte man diesem bereits verwirrenden Setup einen fünften hinzufügen?

Das Problem, wie ich es sehe, ist _jeder einzelne Wert_, der derzeit zur Verwendung verfügbar ist, _umgebungsspezifisch_. Es gibt keine Möglichkeit, eine projektspezifische Option bereitzustellen.

1 + 2. Muss manuell vom Benutzer bereitgestellt werden, der den Befehl aufruft.

1. _Kann_ geteilt werden, aber in der Praxis sollte .env ignoriert und aus gutem Grund nicht geteilt werden. (Ich arbeite daran, indem ich .env.example , aber dies erfordert noch einen zusätzlichen manuellen Schritt.)
2. Ist effektiv zufällig und ist benutzer- / umgebungsspezifisch. (Ich betrachte dies auch als Fallback, weil _needs_ einen Projektnamen erstellt. Es ist nicht einmal ein sehr guter Fallback, da es Projekte in verschiedenen Verzeichnissen mit demselben Namen geben könnte, die Konflikte verursachen würden.)

Meiner Meinung nach und vielen in diesem Thread sollte es eine Option geben, die zwischen 3 und 4 liegt, wobei ein Standardprojektname _ in der Docker-Compose-Datei angegeben werden kann, die für dieses Projekt verwendet wird und als erste verwendet wird Zurückfallen. Dieser Wert wird dann von jedem geteilt, der dieses Projekt bereitstellt. Die Optionen 1-3 würden diesen Wert überschreiben, und Option 4 würde nur verwendet, wenn sie nicht bereitgestellt würde.

@benjaminwood Ich kann Ihnen versichern, dass niemand über dieses Problem lacht. Ja, wir kennen uns schon seit einiger Zeit und es ist nicht das erste Mal, dass wir uns grundsätzlich nicht einig sind. Ich mag für mehrere Benutzer hier nervig klingen, aber es ist nicht meine Absicht. Tatsächlich möchte ich meine Erfahrungen teilen und Lösungen vorschlagen. Ich glaube, dass ich eine große Erfahrung mit diesem Thema habe. Wenn die Funktion wie vorgeschlagen eingeführt würde, würde dies eine große Quelle möglicher Fehler in unserem Setup verursachen.

@ Joshuajabbour

1. Könnte geteilt werden, aber in der Praxis sollte .env ignoriert und aus gutem Grund nicht geteilt werden.

Das hängt von Ihrem Setup ab. Wir haben dies in allen unseren Projekt-Repositorys ignoriert.
Wir ignorieren dies jedoch nicht in unseren Nur-Staging- und Produktions-Stack-Repositorys. Wenn Sie den in docker-compose.yml festgeschriebenen Namen teilen möchten, können Sie auch .env (diese Datei ist nur für den Befehl docker-compose - sonst nichts).

1. Ist effektiv zufällig und ist benutzer- / umgebungsspezifisch.

Es ist nicht mehr oder weniger zufällig als ein Wert in docker-compose.yml . Sie müssen die Stapelkonfiguration als Ordner und nicht als einzelne Datei anzeigen. Wenn Sie dies tun, können Sie entweder den Namen in .env oder einen Unterordnernamen haben.

Ich habe eine letzte Alternative für euch alle:

docker stack deploy -c docker-compose.yml the-project-name

(*) Nur im Schwarmmodus verfügbar

Ich kann nicht sehen , wie ein Projekt-Name in die platziert werden konnte yml Datei in der Zukunft wäre es völlig die Idee einer Stapeldefinition widersprechen.

Danke @ schmunk42. Ich glaube dir und ich denke, du hast die Dinge unter all den starken Meinungen, die in diesem Thread gezeigt werden, ziemlich gut gehandhabt.

Dies würde eine große Anzahl möglicher Fehler in unserem Setup verursachen.

Da ist das Problem. Schließen Sie das Problem.

Das hängt von Ihrem Setup ab. Wir haben dies in allen unseren Projekt-Repositorys ignoriert. Wir ignorieren dies jedoch nicht in unseren Nur-Staging- und Produktions-Stack-Repositorys.

Diese Funktion, die alle anderen wünschen, sollte also nicht eingeführt werden, da sie Ihre ungewöhnliche Repository-Architektur beschädigen würde.

Wenn Sie den in docker-compose.yml festgeschriebenen Namen teilen möchten, können Sie auch .env festschreiben (diese Datei ist nur für den Docker-Compose-Befehl bestimmt - sonst nichts).

Nun, wenn das einzige, was in meiner .env -Datei war, COMPOSE_PROJECT_NAME , dann ja. Aber es ist mit vielen anderen sicheren Variablen gefüllt, die ich nicht festschreiben möchte. Und ich importiere sie mit der Eigenschaft environment in Docker-Compose. Dies ist, wofür .env Dateien im Allgemeinen sind ...

Ich verstehe immer noch nicht, wie dies Ihr Setup beschädigen würde, da in meinem Vorschlag nur der Standardprojektname aus dem Verzeichnis überschrieben wird. Und wenn Sie davon abhängig sind (weil es sich um ein Verzeichnis handelt, das in Ihr Repo übernommen wurde, im Gegensatz zu dem Verzeichnis, in das Ihr Repo geklont wurde), wie würde es dann jemals durch die Einstellung docker-compose.yml überschrieben werden (da dies ebenfalls festgeschrieben ist) zu Ihrem Repo; Sie kontrollieren beide Dinge in Ihrem Szenario)?

@schmunk42 Was Sie sagen ist "Ich möchte keine neuen Funktionen, weil ich sonst mein Projekt-Setup nicht mehr verstehe".

Ernsthaft? Dies ist Ihr Argument, warum Sie wollen, dass alle anderen, die dies brauchen, darauf verzichten?

Nur zur Veranschaulichung: Ich bin auch hier draußen. Fühlen Sie sich frei, um das Problem zu schließen. Die Diskussion hier ist sinnlos geworden.

Diese Funktion, die alle anderen wünschen, sollte also nicht eingeführt werden, da sie Ihre ungewöhnliche Repository-Architektur beschädigen würde.

Ich spreche meine Bedenken aus, dass dadurch zusätzliche Fehlerquellen entstehen könnten.

Nun, wenn das einzige, was in meiner .env-Datei war, COMPOSE_PROJECT_NAME war, dann ja. Aber es ist mit vielen anderen sicheren Variablen gefüllt, die ich nicht festschreiben möchte. Und ich importiere sie mit der Umgebungseigenschaft in Docker-Compose.

Verwenden Sie für diese ein secrets.env und importieren Sie es über env_file .
Wie würde sich das auf Ihren Workflow auswirken?

Dies ist, was .env-Dateien im Allgemeinen für ...

Stimmt ... aber ich denke immer noch, dass das Problem darin besteht, dass docker-compose die Datei .env entführt .

Wie wäre es, wenn Sie diese Variablen plus diejenigen, die in den obersten Ebenen von docker-compose.yml , wie IMAGE_VERSION , in einer Datei namens docker-compose.env festlegen können?

Ich habe es nie gewagt, COMPOSE_COMMAND_ENV_FILENAME=.env vorzuschlagen - bis jetzt :)

Ich verstehe immer noch nicht wirklich, wie dies Ihr Setup zerstören würde, ...

Es ist wahr, dass es nicht sofort kaputt geht, sondern es geht nur um meinen ersten Punkt - und darum, noch mehr Optionen einzuführen.

Denken Sie an die Verwendung mehrerer Dateien -f docker-compose.A.yml -f docker-compose.B.yml . Nehmen wir an, A ist Ihr Projekt und stützt sich auf den Projektnamen nach Verzeichnis (wir tun dies, da wir es steuern!), Während B a ist Satz zusätzlicher Dienste mit project_name: extra , die versehentlich beim Testen in einem Ordner mit einer .env -Datei eingeführt wurden, die den Projektnamen mit COMPOSE_PROJECT_NAME=testing überschrieb.

Aber jetzt würde jedes Projekt, das ohne eine .env -Datei gestartet wird, extra heißen. 💥

Wir führen Dateien auf mehreren Ebenen zusammen, einschließlich mehrerer *.env -Dateien. Dies ist ein sehr gültiger Anwendungsfall.

Ernsthaft? Dies ist Ihr Argument, warum Sie wollen, dass alle anderen, die dies brauchen, darauf verzichten?

Warnung: Etwas off-Topic, aber immer noch Docker-bezogen ...

• "Ich glaube nicht, dass wir es wirklich brauchen"
• "hat mehr Schichten als nötig. mehr Komplexität"

@mikehaertl Ich frage mich wirklich, dass du das so siehst;)

Hallo Leute,

Wir haben die leidenschaftliche Diskussion in diesem Thread aufgegriffen (danke an diejenigen von Ihnen, die sie höflich und herzlich gehalten haben!) Und obwohl wir grundsätzlich immer noch der Meinung sind, dass der Projektname nicht in eine Compose-Datei gehört, haben wir uns was ausgedacht Wir glauben, dass dies ein vernünftiger Mittelweg mit der folgenden PR ist: # 5378. Wir würden uns jedoch über Ihr Feedback freuen, um sicherzustellen, dass es Ihren Anforderungen entspricht.

Hier ist das Wesentliche:

• Sie können Ihrer Compose-Datei einen x-project-name -Eintrag hinzufügen. Dieser Schlüssel wird standardmäßig ignoriert.
• Wenn COMPOSE_X_PROJECT_NAME in Ihrer Umgebung festgelegt ist (oder .env Datei), versucht Compose, den Projektnamen aus dem Eintrag x-project-name in Ihrer Compose-Datei abzurufen.
• Diese Option hat eine niedrigere Priorität als COMPOSE_PROJECT_NAME und --project-name

Gerne beantworten wir Ihre Fragen oder Bedenken dazu.

@ shin- Also müsste COMPOSE_X_PROJECT_NAME auf 1 werden, um die Funktion zu aktivieren?

Wenn ja, könnte COMPOSE_ENABLE_X_PROJECT_NAME auch ein Name sein, über den man nachdenken sollte, aber dies sind nur meine 2 Cent - ich werde es sowieso nicht verwenden 😄

@schmunk42 Jeder "wahrheitsgemäße" Wert wird funktionieren , aber ja, das ist die Idee.

@matsaman Cool, danke für das nützliche, umsetzbare Feedback.

Anstatt uns zu sagen, dass wir Endbenutzer anweisen müssen, eine Variable festzulegen oder einen Parameter aufzurufen, sagen Sie uns, dass wir Endbenutzern anweisen müssen, eine Variable festzulegen oder einen Parameter aufzurufen.

Ehrlich gesagt und wirklich nicht umsonst kann ich mir nicht vorstellen, wie Sie dies in irgendeiner Weise als Lösung angesehen haben.

@ shin- Ich werde erklären, wie diese Änderung keinen nützlichen Unterschied macht:

Das Festlegen einer Umgebungsvariablen, um nach dem Projektnamen in der Erstellungsdatei suchen zu können, entspricht in etwa dem Arbeitsaufwand, dem Risiko des Vergessens und der Bequemlichkeit, dem Festlegen einer Umgebungsvariablen für den Projektnamen.

Der springende Punkt beim Festlegen des Projektnamens in der Erstellungsdatei besteht darin, die Verwendung von Umgebungsvariablen zu vermeiden. Sie können der Umgebungsvariablen für den Projektnamen Vorrang einräumen, um Benutzern die Möglichkeit zu geben, den Projektnamen in der Erstellungsdatei zu überschreiben.

Ich denke, es ist eine sehr gute Lösung, da es BC nicht kaputt macht und es vermeidet, Fehler beim Zusammenführen einzuführen, wie ich es oben beschrieben habe.

Das Festlegen einer Umgebungsvariablen, um nach dem Projektnamen in der Erstellungsdatei suchen zu können, entspricht in etwa dem Arbeitsaufwand, dem Risiko des Vergessens und der Bequemlichkeit, dem Festlegen einer Umgebungsvariablen für den Projektnamen.

Es ist nicht so, dass Sie diese Einstellung einmal global in Ihrer Umgebung vornehmen können - Sie müssen dies nicht in jedem Projekt tun.

Es ist nicht so, dass Sie diese Einstellung einmal global in Ihrer Umgebung vornehmen können - Sie müssen dies nicht in jedem Projekt tun.

Ich gehe davon aus, dass Sie in all Ihren Shells, die Sie auf Ihrem Computer erzeugen, global meinen. Wenn Sie dies tun, kann es in völlig unabhängigen Projekten zu unerwünschtem Verhalten kommen. Dies führt auch zu Verwirrung, wenn ein Entwickler ein Projekt aus der Versionskontrolle zieht und vergisst, die Umgebungsvariable festzulegen.

Eines der wichtigsten Ziele, wenn der Projektname in der Erstellungsdatei enthalten ist, besteht darin, sicherzustellen, dass jede Variable, die mit dem Erstellungsprojekt zu tun hat, in der Versionskontrolle gespeichert wird.

@nhooey @matsaman
Es ist speziell dazu gedacht, Personen zu helfen, die mehrere Compose-Dateien im selben Verzeichnis haben und für die die .env keine Option ist. Wenn dies für Ihre Projekte immer aktiviert sein muss, können Sie es einfach in Ihrer .env -Datei, Ihrer .profile oder an einer anderen Stelle festlegen, die sicherstellt, dass x-project-name immer verwendet wird berücksichtigen.

Anstatt uns zu sagen, dass wir Endbenutzer anweisen müssen, eine Variable festzulegen oder einen Parameter aufzurufen, sagen Sie uns, dass wir Endbenutzern anweisen müssen, eine Variable festzulegen oder einen Parameter aufzurufen.

Unser Hauptanliegen dabei war immer, dass der "Endbenutzer" eigene Projekte hat und Namenskonflikte um jeden Preis vermeiden möchte. In dieser Hinsicht sollten sie die Kontrolle über den Projektnamen haben, nicht über den Distributor. Wenn Sie "schlüsselfertige" Projekte an Kunden versenden, ist es ähnlich trivial, COMPOSE_X_PROJECT_NAME in der zugehörigen .env -Datei festzulegen. Ich bin also verwirrt, welcher Teil davon ein Problem ist, um ehrlich zu sein.

Wenn Sie dies tun, kann es in völlig unabhängigen Projekten zu unerwünschtem Verhalten kommen.

Könnten Sie ein Beispiel geben? Ich kann mir kein unerwünschtes Verhalten vorstellen, indem ich einfach COMPOSE_X_PROJECT_NAME in meiner Shell setze.

Eines der wichtigsten Ziele, wenn der Projektname in der Erstellungsdatei enthalten ist, besteht darin, sicherzustellen, dass jede Variable, die mit dem Erstellungsprojekt zu tun hat, in der Versionskontrolle gespeichert wird.

Warum kannst du dafür nicht .env ? Niemand verbietet das Speichern von .env in der Versionskontrolle (ja, das ist nicht üblich).

Wir hatten zu Beginn .env . Sie haben das gesamte Gespräch deutlich verpasst.

@matsaman Du musst deine Einstellung ernsthaft

Um einige der Verwirrung zu klären

Das kannst du schon machen

Zuvor konnten Sie einen Projektnamen mithilfe einer Umgebungsvariablen festlegen. Die neue Umgebungsvariable ist kein Name, sondern ein Umschalter, der eine Funktion aktiviert, mit der Sie einen Projektnamen in der Erstellungsdatei festlegen können.

Ich gehe davon aus, dass Sie in all Ihren Shells, die Sie auf Ihrem Computer erzeugen, global meinen. Wenn Sie dies tun, kann es in völlig unabhängigen Projekten zu unerwünschtem Verhalten kommen.

Wenn Sie "andere Projekte" als "in" meinen, "könnte etwas, das nicht komponiert ist, dies lesen und brechen". Ich denke, das ist nicht realistisch. In jeder Shell sind viele Umgebungsvariablen festgelegt. Die Umgebungsvariable hat den richtigen Namespace "COMPOSE_X_".

Wenn Sie "andere Compose-Projekte" meinen, dann machen Sie meiner Meinung nach tatsächlich ein Argument dafür, warum diese Variable notwendig ist. Wenn die Funktion standardmäßig aktiviert wäre, würde jeder, der sich auf das aktuelle Standardverhalten verlässt, brechen.

Wenn es keines davon ist, klären Sie es bitte.

Dies führt auch zu Verwirrung, wenn ein Entwickler ein Projekt aus der Versionskontrolle zieht und vergisst, die Umgebungsvariable festzulegen.

Wenn ein Projekt nur mit einem bestimmten Projektnamen funktioniert, gibt es meiner Meinung nach andere Probleme. Es sollte niemals einen Fall geben, in dem ein Projekt nur mit einem einzigen Namen funktioniert.

Ich sehe dies als ein weiteres Argument dafür, den Projektnamen nicht in die Compose-Datei aufzunehmen. Wenn sich der Projektname in der Erstellungsdatei befindet, können zwei beliebige Projekte denselben Namen verwenden, was zu einem Konflikt führt, der beide Projekte beschädigen würde. Der Name sollte wirklich vom Entwickler festgelegt werden, der weiß, welche anderen Projektnamen bereits verwendet werden.

Leider hilft mir das auch nicht aus Gründen, die ich bereits vor über einem Jahr erwähnt habe.

Eine Lösung, die Umgebungsvariablen umfasst, würde Benutzer erfordern, die wissen müssen, wie sie überhaupt erstellt werden. Ich weiß, dass es schwer zu glauben scheint, aber nicht jeder arbeitet im Terminal. Auch hier ist das Einfügen einer .env-Datei in das Repository für mich keine Option.

Die Schönheit von Docker-Compose ist up . Keine Anweisungen zum Einrichten dieses Anrufs.

@ fünfeanddone

Auch hier ist das Einfügen einer .env-Datei in das Repository für mich keine Option.

Können Sie das erweitern? Ich höre Sie total über Benutzer mit geringeren technischen Kenntnissen, aber wenn sie nicht für die Interaktion mit dem Code oder der Umgebung gedacht sind, warum ist es dann ein Problem, eine .env -Datei in das Projekt aufzunehmen?

@ Shin- Ja, kein Problem.

Ich habe diese Datei in einigen Fällen in das Repository aufgenommen, aber sie funktioniert nicht immer. Meine Anwendungsfälle betreffen hauptsächlich die Webentwicklung, bei der das technische Wissen eines Entwicklers sehr unterschiedlich sein kann.

Das .env Parameter, die in anderen Frameworks verwendet werden. Einige der Variablen in meinem .env sind Anmeldeinformationen für externe Dienste wie SMTP. Die meisten Entwickler in meinem Team verweisen diese Dienste mithilfe ihrer eigenen .env -Datei auf ihre eigenen Endpunkte. Wenn das .env nicht vorhanden ist, habe ich Standardeinstellungen.

Für weniger technische Entwickler, die möglicherweise nur etwas CSS ändern möchten, funktioniert die Anwendung ohne die Datei .env einwandfrei. Dies setzt voraus, dass nicht jeder Projektordner gleich benannt wird. :) :)

Es scheint nicht viel zu sein, aber wenn Sie mit mehreren Entwicklern und Designern im ganzen Land zusammenarbeiten - je einfacher, desto besser.

Docker hat mein Leben so viel einfacher gemacht und ich bin sehr dankbar für dieses Projekt, aber ich kann mich auf die Frustrationen rund um diesen Thread beziehen.

@fiveanddone Danke für den Einblick! Wenn die Datei .env stattdessen docker-compose.env (oder ähnlich) heißt, würde dies Ihre Bedenken zerstreuen?

@Schienbein-

Ja, das wäre für meine Anwendungsfälle.

Wird die env-Datei automatisch von Docker Compose geladen?

Wenn nicht, könnte docker-compose.env automatisch geladen werden?

@nhooey Die env-Datei wird automatisch geladen, wenn sie .env . Sie können die env-Datei auch für jeden Dienst einzeln angeben. Siehe Dokumente .

Die env-Datei wird automatisch geladen, wenn sie den Namen .env trägt. Sie können die env-Datei auch für jeden Dienst einzeln angeben. Siehe Dokumente.

Hier nicht der Trottel zu sein, aber das ist nicht wirklich richtig. Und meiner Meinung nach die größte Quelle für Missverständnisse des gesamten Themas.

Keine der Variablen von .env wird an einen Container / Service übergeben, wenn Sie ihn nicht explizit weiterleiten

env_file: 
  - .env

oder

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

Die .env -Datei wird zwar automatisch geladen, aber ohne weitere Konfiguration gilt sie nur für diese Compose CLI-Umgebungsvariablen .

Ich würde es nachdrücklich unterstützen , dies standardmäßig in docker-compose.env umzubenennen und noch besser - eine Variable dafür , sodass dies auf BC-Weise verwendet werden kann, indem nur eine ENV-

(Danke an diejenigen von euch, die es höflich und herzlich gehalten haben!)

Ich höre dich und bin sicher schuldig, nicht immer meine Gelassenheit zu bewahren. Das tut mir leid. Einige Kommentare bringen mich manchmal wirklich zum Laufen ... werden daran arbeiten.

Wenn sich der Projektname in der Erstellungsdatei befindet, können zwei beliebige Projekte denselben Namen verwenden, was zu einem Konflikt führt, der beide Projekte beschädigen würde.

Unser Hauptanliegen dabei war immer, dass der "Endbenutzer" eigene Projekte hat und Namenskonflikte um jeden Preis vermeiden möchte. In dieser Hinsicht sollten sie die Kontrolle über den Projektnamen haben, nicht über den Distributor.

@ shin- Dies klingt wie allgemein vereinbart, dass docker-compose.yml immer Teil eines Projekts ist und sich im Projekt-Repository befindet. Ich würde sagen, das ist nicht unbedingt wahr. Einige von uns teilen nicht docker-compose.yml sondern möchten ihre lokale Version mit lokalen Anpassungen (z. B. Entwicklungseinstellungen, Testversionen usw.) beibehalten.

Und in Bezug auf "Vermeiden von Namenskonflikten": Anstelle eines Namenskonflikts mit dem Projektnamen haben wir jetzt einen (IMO) kritischeren Namenskonflikt auf Dateisystemebene: .env ist ein gebräuchlicher Name, mit dem Projekte ihre definieren App-spezifische Einstellungen. Es sollte nicht mit Docker-Einstellungen verschmutzt werden, es sei denn, ein Entwickler möchte dies wirklich tun. Diese Entscheidung sollte jedoch dem Entwickler überlassen bleiben.

Hier ist ein Vorschlag: Wie wäre es, wenn Sie zwei weitere Optionen für den Projektnamen hinzufügen und die Verwendung von .env in V4 der docker-compose.yml ablehnen? Eine ist project_name in docker-compose.yml , eine andere ist eine Datei .dockerproject die nur den Namen enthält und niemals an ein Repository gesendet werden sollte. Es sollte eine lokale Datei sein.

Hier ist mein Vorrangvorschlag (höchster zuerst):

• -p CLI-Argument
• .dockerproject Datei
• project_name in docker-compose.yml (sollte vermieden werden, wenn docker-compose.yml mit dem Projekt verteilt wird)
• COMPOSE_PROJECT_NAME aus der Umgebung
• COMPOSE_PROJECT_NAME von .env (veraltet)
• Verzeichnisname

Auf diese Weise können Endbenutzer einen Projektnamen immer noch in .dockerproject überschreiben, selbst wenn jemand ihn in einem verteilten docker-compose.yml codiert hat.

UPDATE: Ich könnte auch damit leben, .dockerenv oder docker.env anstelle von .dockerproject . Es sollte jedoch eine höhere Priorität haben, um das Problem zu lösen, dass einige hier fest codierte Projektnamen in docker-compose.yml überschreiben müssen.

Hallo zusammen,

Zunächst einmal danke ich @dnephin und @ shin-, dass Sie sich diesen Fall angesehen haben. Die von change @ shin eingereichte Änderung scheint ein großer Schritt zur Lösung dieses Problems zu sein.

Ich habe den PR 5378 im Testprojekt für den folgenden Anwendungsfall validiert: A default project name defined by the project, that can be checked in (https://github.com/docker/compose/issues/745#issuecomment-282858900). Dafür habe ich ein Git-Repo gemacht, das verschiedene Möglichkeiten veranschaulicht: https://github.com/estarter/compose_745

Ich fand PR # 5378, das den Anwendungsfall teilweise abdeckte. Das Problem ist, dass die Lösung die Variable COMPOSE_X_PROJECT_NAME env erfordert. Mögliche Lösungen:

1. Behalten Sie die env-Variable im Projektordner bei. Ich habe versucht, .env Datei, aber es funktioniert nicht, wenn Docker-Compose von einem anderen Ort aufgerufen wird (siehe Befehlsbeispiel , Dateien erstellen )
2. Definieren Sie COMPOSE_X_PROJECT_NAME global (.profile oder gleichwertig). Das würde funktionieren, kann aber nicht im Projekt angegeben werden, dh es ist keine Lösung für unseren Anwendungsfall defined by the project, that can be checked in
3. Gibt es eine andere Option?

Hoffentlich habe ich es geschafft, den Anwendungsfall zu veranschaulichen, der hier angesprochen wird.

Sehr geehrte Betreuer, bitte überlegen Sie, wie der Anwendungsfall durch PR # 5369 gelöst wird, das die optionale Eigenschaft project_name in die Docker-Compose-Datei einführt. Diese Eigenschaft hat eine niedrige Priorität, hängt jedoch nicht von der Umgebung oder dem Arbeitsverzeichnis ab.

1. Gibt es eine andere Option?

Es gibt diese Option docker-compose --project-directory <PATH> (Geben Sie ein alternatives Arbeitsverzeichnis an). Sollte auch mit einer .env -Datei funktionieren.

So fügen Sie der Mischung einen weiteren nuancierten Anwendungsfall hinzu:
In meinem Anwendungsfall habe ich zwei Repositorys, eines für das Hauptprojekt (zum Erstellen / Bereitstellen verwendet) und eines für Entwickler (mit den Docker-Dateien, docker-compose.yml usw.).
In unserem aktuellen Setup befindet sich das Hauptprojekt-Repo im Stammverzeichnis ./ und das Devops-Repo wird in einem Unterverzeichnis ausgecheckt ./devops/

In diesem Setup funktioniert die Verwendung einer .env-Datei nicht, da dies sein muss:

Wird in dem Ordner abgelegt, in dem der Befehl docker-compose ausgeführt wird (aktuelles Arbeitsverzeichnis).
(doc ref)

Was nicht funktioniert, da es wie folgt aufgerufen wird: docker-compose -f devops/docker-compose.yml
Natürlich können wir hier den Parameter -p hinzufügen, den wir derzeit verwenden, aber er ist anfällig für menschliches Versagen, wie oben erwähnt.

Wenn die .env-Datei (oder die vorgeschlagene Datei docker-compose.env) aus demselben Verzeichnis gelesen werden könnte, in dem sich die Datei docker-compose.yml befindet, würde die Definition des dortigen Projektnamens für mich funktionieren.

Die Verwendung der Anweisung env_file in der Datei docker-compose.yml funktioniert nicht, da diese env-Variablen nur innerhalb des Containers angewendet werden und nicht auf die Erstellung der Container.

Letztendlich ist es mein Ziel, meine devops-bezogenen Dateien so in sich geschlossen zu halten, dass meine tatsächliche Projektcodebasis nicht verschmutzt wird, aber dennoch parallel zu diesem Repo zugegriffen / ausgeführt werden kann.

Es gibt diese Option docker-compose --project-directory(Geben Sie ein alternatives Arbeitsverzeichnis an.) Sollte auch mit einer .env-Datei funktionieren.

@ schmunk42 könnte ein guter Schuss sein, aber --project-directory funktioniert nicht für .env-Dateien. Ich habe Folgendes versucht: Die ENV-Datei wurde ignoriert ( Projektdateien ):

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

In Zukunft werde ich Kommentare löschen, die nicht auf konstruktive Weise zur Konversation beitragen. Ich habe kein Interesse daran, mit Kindern zu interagieren.

Bei einem einstellbaren .env Namen
Das Problem mit einer Umgebungsvariablen, die angibt, welche .env -Datei verwendet werden soll, besteht darin, dass es sich im Wesentlichen um eine zirkuläre Abhängigkeit handelt. Wir müssten eine Ausnahme in der Interpretation von Umgebungsvariablen einführen, die zwar sinnvoll, aber von Natur aus kontraintuitiv ist.

Auf dem .env Namen selbst
Mittlerweile ist klar, dass der Name .env von einer Vielzahl von Software und Frameworks verwendet wird und normalerweise nicht für die Versionskontrolle bestimmt ist. Wir reagieren sehr empfindlich auf wichtige Änderungen, könnten jedoch einen alternativen Namen (z. B. docker-compose.env ) mit einem Fallback auf die Datei .env einführen, wenn der erstere nicht vorhanden ist, mit der Absicht, dass Es kann mit anderen Benutzern geteilt werden.

Beim Hinzufügen von project_name zur Compose-Datei
Wir haben unsere Haltung dazu bereits mehrmals bekräftigt - siehe Daniels neuesten Kommentar aus einigen Gründen, aus denen wir gegen diese Änderung sind. Es ist nicht so, dass es schwierig ist. Es ist nicht so, dass wir nicht darüber nachgedacht hätten. Wir haben viel Zeit damit verbracht, es zu evaluieren, und wir sind der Meinung, dass die Qualität des Projekts zu stark darunter leiden würde, um das Hinzufügen (in dieser Form) zu rechtfertigen. Realistisch gesehen ist # 5378 wahrscheinlich das beste Zugeständnis, das wir machen können, damit dies auf eine Weise funktioniert, die opt-in und abwärtskompatibel ist (BEARBEITEN: Natürlich bin ich offen für Vorschläge, die diesen Vorschlag innerhalb dieser Parameter verbessern).

Auf --project-directory
Ein bisschen tangential, aber ich bin mir bewusst, dass diese Option momentan ein bisschen kaputt ist. Im Nachhinein hätte ich es vorgezogen, es überhaupt nicht hinzuzufügen, da es mehr Probleme verursacht als löst. Ich werde versuchen, einige Zeit zu verbringen, um zu sehen, ob es reparabel ist, aber es hat viele seltsame Randfälle, die es wirklich unzuverlässig machen.

Gibt es jemanden, für den docker-compose.env + # 5378 keine zufriedenstellende Lösung wäre? Ich verstehe, dass es möglicherweise nicht Ihre bevorzugte Lösung ist, aber ich frage, ob es vernünftige Zugeständnisse macht, mit denen Sie fertig werden können.

Alle Scherze beiseite ...

Ich verstehe immer noch nicht, wie sich Daniels jüngster Kommentar auf die "Qualität des Projekts" bezieht. Außerdem ist es eine allgemeine Faustregel, dass das Hinzufügen eines Schlüssels zu einem Wörterbuch niemals zu einer Unterbrechung der Abwärtskompatibilität führen darf. Es gibt immer Fälle, in denen Programmierer Dinge so implementiert haben, dass dies nicht der Fall ist, aber ich schweife ab.

Ich denke, das Lager, das das Feld project-name (oder was auch immer) haben möchte, ist gerechtfertigt, da der "Name" des Projekts für viele Aspekte des Werkzeugs von grundlegender Bedeutung ist. Die Leute in diesem Lager möchten diesen Namen vielleicht einfach irgendwo in Stein schreiben, um Probleme mit temporäreren Lösungen wie Umgebungsvariablen oder befehlsähnlichen Flags zu vermeiden.

Ich hoffe das war konstruktiv.

@estarter Ich würde dies als Fehler betrachten, vielleicht lohnt es sich, ein separates Problem dafür zu eröffnen

Eigentlich würde ich erwarten, dass dies mit der Datei .env im Verzeichnis PR_5378 funktioniert:

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Beim Hinzufügen von Projektname zur Compose-Datei

@ shin- Es scheint, die Entscheidung ist bereits getroffen. Aber ich versuche immer noch, den Hintergrund zu verstehen. Ich habe das schon einmal gefragt und nie eine Antwort bekommen (was ein Grund ist, warum die Diskussion für mich so nervig war).

Könnten Sie mir bitte helfen zu verstehen, warum wir container_name und sogar network in docker-compose.yml ? Die erste könnte auch eine Quelle für potenzielle Konflikte sein. Und letzteres ist sehr hostspezifisch. Nach Ihrer Logik sollten diese beiden (und andere) auch nicht da sein. Ich sehe den Unterschied zu project_name .

Bitte ignorieren Sie diese Frage nicht noch einmal.

@ michael-k Wollen Sie damit sagen, dass project_name dasselbe ist wie container_name ? Wenn Sie dies sagen, möchte ich Sie darüber informieren, dass ein Projekt aus mehreren Containern bestehen kann. Oder habe ich dich missverstanden?

Während für network , ist es nicht unbedingt hostspezifisch. Es gibt viele Fälle, in denen ein Projekt ein zentrales isoliertes Netzwerk erfordert, in dem ein Container mit einem anderen Netzwerk interagiert. Und seine Konfigurationen werden im docker-compose.yml gespeichert.

@ AyushyaChitransh Du hast es falsch verstanden. Die Frage ist: Warum ist container_name , network und andere in docker-compose.yml während project_name nicht dort sein dürfen? Sie alle haben das gleiche Konflikt- oder hostspezifische Konfigurationspotential, das nicht gemeinsam genutzt werden sollte.

@aanand ich weiß über diese Gelegenheit. Dasselbe könnte man auch über Containernamen sagen, aber wir haben die Möglichkeit, den Containernamen in der Erstellungsdatei festzulegen, oder?

Ja, aber ich denke nicht, dass es eine gute Idee war, das hinzuzufügen.

Aus der zugehörigen Diskussion Geben Sie den Netzwerknamen in der Docker-Compose-Datei an .

@estarter Ich würde dies als Fehler betrachten, vielleicht lohnt es sich, ein separates Problem dafür zu eröffnen

@ schmunk42 Ich sehe, dass die Betreuer sich dessen bewusst sind - siehe On --project-directory in Joffreys Kommentar plus # 4709, # 4933 und # 4841

Eigentlich würde ich erwarten, dass dies mit der .env-Datei im Verzeichnis PR_5378 funktioniert:
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Sie haben angenommen, dass --project-directory -f Parameter
Tatsächlich ist dies nicht der Fall, dieser Befehl gibt IOError: [Errno 2] No such file or directory: u'./docker-compose.yml'

Es ist sehr gut, dass --project-directory -f nicht beeinflusst - stellen Sie sich ansonsten vor, was für ein Albtraum wäre, wenn Sie --project-directory und mehrere Docker-Compose-Dateien in verschiedenen Verzeichnissen verwenden würden.

Ich bin sehr überrascht, so viele Überlegungen über etwas zu sehen, das ich als gelöstes Problem betrachte.

Dies ist die Rangfolge, die ich gewohnt bin:

1. fest codiert
2. CLI-Option
3. Umgebung
4. project.rc
5. vernünftiger Standard

Für project_name wir derzeit weder Option 1 noch Option 4. Dies ist das grundlegende Problem, mit dem Menschen konfrontiert sind, und es scheint leicht abwärtskompatibel zu lösen.

Wir scheinen philosophische Argumente über Reinheit zu haben, die möglicherweise nicht hilfreich sind. Die Verwendung eines sehr verbreiteten OSS-Kaskadenkonfigurationsschemas ist dagegen sehr hilfreich.

Wir scheinen philosophische Argumente über Reinheit zu haben, die möglicherweise nicht hilfreich sind.

Dieses Argument zu haben ist jedoch nicht das Ziel. Von Anfang an war uns sehr klar, wo wir in Bezug auf die Definition des Projektnamens in der Compose-Datei stehen.

Aber lassen Sie mich diesbezüglich transparent sein. Dies wird in docker-compose niemals passieren. Wenn dies der einzige Lösungspfad ist, den Sie für dieses Problem akzeptieren möchten, müssen Sie genau den OSS-Prozess ausführen, bei dem das Projekt gegabelt und selbst ausgeführt wird. Der Code ist verfügbar und wird mit einer sehr zulässigen Lizenz geteilt.

Könnten Sie mir bitte helfen zu verstehen, warum wir container_name und sogar ein Netzwerk in docker-compose.yml haben? Die erste könnte auch eine Quelle für potenzielle Konflikte sein. Und letzteres ist sehr hostspezifisch. Nach Ihrer Logik sollten diese beiden (und andere) auch nicht da sein. Ich sehe den Unterschied zu Projektname nicht.

Für container_name wurde diese Option sehr früh in der Laufzeit des Projekts eingeführt. Wie @ schmunk42 betonte, wäre dies definitiv nicht in der Spezifikation enthalten, wenn wir es noch einmal machen würden. Es wird ständig missbraucht und hat im Laufe der Jahre unzählige Probleme für Benutzer verursacht.
Was network , bin ich mir nicht ganz sicher, wie es in Ihrem Kopf verglichen wird?

Was ist mit Option 4, die ich erwähnt habe? Ich habe einige Gespräche über die Einführung eines .docker-compose für lokale verzeichnisspezifische Einstellungen gesehen. Dies wäre der Einführung der _x_ -Umgebungsflags (für die noch Umgebungsverwaltung erforderlich ist) weitaus vorzuziehen (imo).

Es wäre so:

# <my-project-dir>/.docker-compose
project_name: foobar

Das Obige unterscheidet sich von der Option für Umgebungsvariablen und ist in der Prioritätsliste niedriger.

Dies löst meinen Anwendungsfall gut und markiert einen anderen Standardkonfigurationspfad von der Liste.

@thedeeno In unseren Augen erreicht COMPOSE_PROJECT_NAME in der .env -Datei dies bereits (mit der gleichen Prioritätsreihenfolge wie in Ihrer Gliederung). Wir haben jedoch gehört, dass Sie bei .env eine schlechte Namenswahl haben, weshalb wir docker-compose.env als Alternative in Betracht ziehen. Würde das für dich funktionieren?

In unseren Augen erreicht COMPOSE_PROJECT_NAME in der .env-Datei dies bereits

@ shin- hier sind wir uns nicht einig. Ich glaube nicht.

Ich persönlich finde es toll, dass wir die Datei .env beziehen. Dies ist ein sehr herkömmlicher Ort, um lokale Geheimnisse und andere lokale hardwarespezifische Konfigurationen zu speichern.

Dies eignet sich hervorragend für die Unterstützung bei der umgebungsbasierten Konfiguration von number 3 .

Es gibt uns keine Notluke ( number 4 ), wenn wir nicht möchten, dass die Umgebung den Projektnamen besitzt.

In meinem Fall haben unsere Entwickler jeweils eine eigene .env -Datei (nicht VC). Es enthält Geheimnisse für die Injektion in docker-compose.yaml . Ich liebe das.

Wir möchten jedoch nicht, dass die Entwickler die Kontrolle über den Projektnamen haben, da dieser stark an einige Tools gekoppelt ist. Da .env nicht in der Versionskontrolle ist, müssen unsere Entwickler die COMPOSE_PROJECT_NAME bei diesem Ansatz manuell festlegen. und es ist das eine Ding, das nicht wie die anderen ist, weil es kein Geheimnis ist.

Leider würde es uns hier nicht helfen, einfach den Standardquellpfad von .env ändern. Wir lieben es wirklich, dass .env automatisch bezogen wird. Wir wollen den Projektnamen einfach nicht so angeben.

Ich werde einen Anwendungsfall aus meiner Praxis zeigen:

Ich verwende die Datei .env , um die Bildversion anzugeben und um seltsame sed / awk / perl / was auch immer zu analysieren, überschreibe ich einfach den Wert in CI:

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

später in docker-compose.yml wird das Bild wie folgt angegeben:

    image: my.registry.example.net/app:${APP_VERSION}

Wenn ich jetzt mehr Variablen dieser Art benötige, muss ich etwas analysieren, es sei denn, mehrere .env -Dateien werden unterstützt.

Fügen Sie also möglicherweise auch "Verzeichnis" -Unterstützung hinzu, z. B.: docker-compose.env.d/* oder .docker-compose.env.d/* oder docker-compose.d/* .

Da ein solcher Glob jedoch sofort Probleme beim Abgleichen von Editor-Backups verursachen kann ( *~ , *.bak ), ist es besser, stattdessen eine Erweiterung zu verwenden: docker-compose.env.d/*.sh

... aber andererseits, machen Sie es vielleicht einfach in docker-compose.yml konfigurierbar. Welche Root-Level .env Dateien werden geladen, oder das würde ein Hühnerei-Problem verursachen? Ich weiß nicht, wie der Konfigurationsparser funktioniert :)

ein bisschen offtopic, aber COMPOSE_PROJECT_NAME env erlaubt keine vollständige Kontrolle des Präfixes, es würde immer noch entfernt werden, um mit A-Za-z0-9_ übereinzustimmen ... Ich wollte - in meinem Präfix verwenden. (Ich kann nicht finden, wo ich das gerade gemeldet habe, aber afaik ist es nicht angesprochen)

Es wäre logisch, dieselben Zeichen zuzulassen, auf die sich Docker selbst beschränkt.

@glensc Das ist eine Menge Infrastruktur, um die Umgebung zu verwalten. Ich persönlich glaube nicht, dass dies in der Verantwortung von docker-compose .

Das einzige, was ich bei anderen Projekten gesehen habe, ist, automatisch .env

@glensc @thedeeno Idealerweise hätten wir zwei *.env -Dateien, von denen eine für andere Benutzer freigegeben und eine privat gehalten werden soll, wobei die letztere die erstere überschreibt, wenn beide dieselbe Variable definieren?

Ich habe letzte Woche in meinem Kommentar konfigurierbare .env Namen angesprochen.

Ein öffentliches docker-compose.env (während das private .env noch automatisch beschafft wird) würde für uns großartig funktionieren!

Wir würden es wie eine RC-Datei behandeln und es als Quellcodeverwaltung festlegen.

Ich denke, mit öffentlichen / privaten Env-Dateien werden wahrscheinlich die meisten der hier genannten Anwendungsfälle gelöst. Wenn - auch im Projektnamen erlaubt wäre, wäre das großartig.

@thedeeno @glensc Könnten Sie bitte einen Anwendungsfall benötigen, die die Werte in der öffentlichen überschreibt?

Geheimnisse sollten nicht in docker-compose.env , da sie nicht automatisch an Container weitergeleitet werden. Sie könnten dann immer noch eine .env -Datei verwenden und damit machen, was Sie wollen. Aber es erscheint mir verwirrend, Einstellungen für docker-compose und Container im Stapel zu mischen.

@schmunk42 Ich habe diesen Anwendungsfall nicht, daher werde ich dort nicht viel helfen. Ich muss nur die project_name für die Versionskontrolle festlegen. docker-compose.env löst das.

Ich bin mir nicht sicher, ob ich Ihrem zweiten Absatz folge. Wir verwenden .env für Geheimnisse und injizieren sie manuell in docker-compose.yaml .

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -346491062

Es ist nur so, weil NUR der Ort, an dem ${variables} für image definiert werden soll, .env Datei zu sein scheint.

@glensc Einverstanden!

Stattdessen würde ich docker-compose.override.env vorschlagen, um es an der aktuellen Überschreibungsfunktion für yml -Dateien auszurichten.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

Ich bin mir nicht sicher, ob ich Ihrem zweiten Absatz folge. Wir verwenden .env für Geheimnisse und injizieren sie manuell in docker-compose.yaml.

@thedeeno Ich nehme an, du machst das:

environment:
  - ${SECRET_VAR_FROM_DOTENV}

was auch mit docker-compose.override.env . Oder Sie könnten tun:

env_file:
  - .env

Schlagen Sie vor, .env zugunsten eines Docker-Compose-spezifischen zu löschen?
Pfad?

Wenn wir die automatische Beschaffung von .env überspringen, wirkt sich dies negativ auf meine aus
Workflow des Teams. Wir verlassen uns auf diese Datei für andere Werkzeuge. Wir würden am Ende enden
unsere Geheimnisse in zwei Teile teilen (.env und diese andere Datei, die Sie vorschlagen)
Orte, an denen Docker-Compose nicht mehr auf .env schaut.

Am Do, 23. November 2017 um 01:15 Uhr Tobias Munk [email protected]
schrieb:

@glensc https://github.com/glensc Einverstanden!

Aber stattdessen würde ich docker-compose.override.env vorschlagen, um es auszurichten
Die aktuelle Überschreibungsfunktion für XML-Dateien.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

Ich bin mir nicht sicher, ob ich Ihrem zweiten Absatz folge. Wir verwenden .env für Geheimnisse und
injizieren Sie sie manuell in docker-compose.yaml.

@thedeeno https://github.com/thedeeno Ich gehe davon aus, dass Sie dies tun:

Umgebung:

• $ {SECRET_VAR_FROM_DOTENV}

Dies sollte auch mit docker-compose.override.env möglich sein. Oder du
tun könnte:

env_file:

• .env

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/745#issuecomment-346538315 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AAFIdxtbI7y3wW2TFa401Go6Msj0gC74ks5s5Q1vgaJpZM4DLBNs
.

Schlagen Sie vor, .env zugunsten eines Docker-Compose-spezifischen zu löschen?
Pfad?

Nicht unbedingt, für BC könnte docker-compose immer noch .env wenn die anderen nicht gefunden werden, genau wie bei fig.yml einmal. Obwohl es schwierig sein kann, die folgenden Fälle zu entscheiden:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env würde im letzten Fall nicht verwendet, aber ich bin mir nicht sicher, wie ich mit den ersten beiden umgehen soll, da einige Benutzer .env als Override verwenden würden, andere als Fallback.

Für mich sollte .env in jedem Fall verwendet werden. Es ist eine Datei mit besonderer Bedeutung
im weiteren Ökosystem.

In Ihrem dritten Fall ist es nur die Datei mit der niedrigsten Priorität.

Ich brauche nur eine Möglichkeit, meinen Projektnamen für die Quellcodeverwaltung festzulegen. Ich nicht
Achten Sie besonders auf anspruchsvollere Kaskadenumgebungen
Management. Eigentlich würde ich es vorziehen, wenn diese Projektnamenstrategie nichts zu tun hätte
mit Umgebungsvariablen tun.

Wenn eine Konfigurationsdatei vom Tisch ist und es eine Möglichkeit gibt, meine zu verpflichten
Projektname mit dieser Env-Kaskade, die Sie verwenden, werde ich gerne verwenden
obwohl!

Am Do, 23. November 2017 um 01:31 Uhr Tobias Munk [email protected]
schrieb:

Schlagen Sie vor, .env zugunsten eines Docker-Compose-spezifischen zu löschen?
Pfad?

Nicht unbedingt, denn BC Docker-Compose könnte sich immer noch .env ansehen, wenn die
andere werden nicht gefunden, wie bei fig.yml einmal. Obwohl es sein könnte
Es ist schwierig, die folgenden Fälle zu entscheiden:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env würde im letzten Fall nicht verwendet, aber ich bin unentschlossen, wie ich damit umgehen soll
zu den ersten beiden, da einige Benutzer .env als Override verwenden würden, andere als
Zurückfallen.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/745#issuecomment-346539891 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AAFId95kZQIsiWp488JyPQOtGJju0OPbks5s5RFbgaJpZM4DLBNs
.

Was das Netzwerk betrifft, bin ich mir nicht ganz sicher, wie es in Ihrem Kopf verglichen wird?

@Schienbein-

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

Ich schätze, ich mache es falsch, weil ich meine docker-compose.yml nie für mein Repo festschreibe. Es enthält immer sehr hostspezifische Einstellungen. Es kann ganz andere Inhalte in der Entwicklung einer Produktion haben.

Ich bin ein Fan von "4 project.rc", obwohl ich wahrscheinlich so etwas wie docker-project.yaml anstelle eines anderen Formats verwenden würde. Dies ist genau das, was die ursprüngliche Ausgabe beschreibt. Aus meiner Sicht sollte jede Diskussion über das Einfügen des Projektnamens in die Erstellungsdatei in einem separaten Thema stattfinden.

Ich brauche nur eine Möglichkeit, meinen Projektnamen für die Quellcodeverwaltung festzulegen.

Dies ist immer noch ein Punkt, den ich nicht verstehe. Es sollte keinen Grund geben, einen einzigen fest codierten Projektnamen zu verlangen. Wenn es externe Tools gibt, die einen konsistenten Namen erwarten, warum setzt dieses Tool keinen Projektnamen, bevor es docker-compose aufruft?

my_project_network_on_my_localhost scheint mir falsch zu sein. Warum benötigen Sie den Projektnamen in einem externen Netzwerk? Es muss nicht mit dem Namen des Erstellungsprojekts übereinstimmen.

my_project_network_on_my_localhost scheint mir falsch zu sein.

Dies war nur ein Beispiel. Ich habe auf meinem lokalen Entwicklungscomputer ein anderes Netzwerk-Setup als auf einem Produktionsserver. Viele andere Einstellungen in meinem docker-compose.yml ebenfalls regelmäßig von der Produktion, z. B. habe ich dort Dienstprogrammcontainer definiert, um projektspezifische Inhalte zu erstellen oder eine Datenbank zu verwalten oder was auch immer.

So wie ich es verstanden habe, bestand die Hauptidee hinter docker-compose (oder besser fig ) zunächst darin, all diese langwierigen docker Befehlszeilenoptionen für ein komplexes Container-Setup in einem gut zu organisieren einfache Yaml-Datei. Deshalb fühlt es sich so komisch an, dass eine einzige Option ausgelassen wird. Aber es scheint, als hätte ich irgendwie übersehen, dass dies nicht mehr die Hauptidee dahinter ist.

Viele andere Einstellungen in meiner docker-compose.yml unterscheiden sich ebenfalls regelmäßig von der Produktion, z. B. habe ich dort Dienstprogrammcontainer definiert, um projektspezifische Inhalte zu erstellen oder eine Datenbank zu verwalten oder was auch immer.

Wir haben hier den gleichen Workflow. In unserem Fall bringt die "gemeinsame" Docker-Compose-Definition fast nichts auf den Punkt , aber dies sind die einzigen Dinge, die zwischen Entwickler, Test, Inszenierung und Produktion wirklich geteilt werden.
Die Hauptteile der Entwicklungseinstellungen werden in einer separaten Datei definiert. Die automatische Zusammenführung erfolgt über eine .env- Datei. Es ist das gleiche für den Testaufbau .

Da es sich in unserem Fall in einem Ordner befindet, können wir so etwas tun

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

zum Testen ... oder so

(cd production && docker-compose logs -f --tail 100)

für die Produktion (Bonus: Sie können DOCKER_HOST in der Produktion definieren, um auf eine andere Maschine zu verweisen, jedoch nur mit docker-compose ).

Aber ja, es ist ein Ordner, keine Datei - und erfordert cp .env-dist .env an zwei Stellen, um zu arbeiten, andernfalls schlägt es mit einer ungültigen Erstellungsdatei fehl. Eigentlich wollte ich nur diesen IMHO ordentlichen Workflow teilen.

Dies ist immer noch ein Punkt, den ich nicht verstehe. Es sollte keinen Grund geben, einen einzigen fest codierten Projektnamen zu verlangen. Wenn es externe Tools gibt, die einen konsistenten Namen erwarten, warum setzt dieses Tool keinen Projektnamen, bevor es Docker-Compose aufruft?

@dnephin Es gibt Gründe.

Ja, es gibt Workarounds. Die Frage ist, es bequemer und vorhersehbarer zu machen.

Hier ist ein Beispiel, bei dem ein fest codierter Projektname hilfreich ist: Die Docker-Konfiguration von traefik erstellt standardmäßig Hostregeln für Container im folgenden Format: <service>.<project>.<domain> . Diese Formatierung ist nicht einfach zu ändern. Für unsere Entwickler ist es sehr vorteilhaft, dieselben fqdns für unsere Docker-Compose-Dienste zu verwenden. Es wäre großartig, wenn wir das Nullkonfigurations-Setup verwenden könnten, da die einzige Möglichkeit, die Konsistenz zu gewährleisten, darin besteht, entweder: a) sie zu zwingen, einen bestimmten Verzeichnisnamen für ihren Klon zu verwenden, b) die Regeln für traefik manuell anzugeben. Beide saugen.

Hier ist eine andere: Referenzieren von Bildern, die mit Docker-Compose erstellt wurden. Wenn wir den Projektnamen nicht garantieren können, können wir diese Bildnamen nicht garantieren und können sie nicht mit Sicherheit referenzieren. Sicher, wir können das image_name für jede Definition fest codieren, aber es fühlt sich offen gesagt überflüssig an, weil wir die Konvention verwenden möchten, aber nur befürchten, dass Entwickler, die unterschiedliche Dateinamen verwenden, sehr überraschende Fehler in unseren Werkzeugen haben werden.

Leute, so viele Diskussionen ... wie ist der Status, kann ich den Standardprojektnamen in meiner .docker-compose -Datei festlegen?
Oder brauchen Sie noch weitere Diskussionen in diesem Thread?

Das Speichern des Projektnamens in der Datei docker-compose.yml ist in Verbindung mit anderen Tools, z. B. PyCharm, sehr sinnvoll.

Es wäre großartig, wenn Sie es in derselben YAML-Datei speichern und bei Bedarf möglicherweise überschreiben würden.

Ich denke, dass der Kern dieses Problems von der Tatsache herrührt, dass der Standardprojektname einfach (sollte ich _naively_ sagen?) Als Basisname des aktuellen Verzeichnisses verwendet wird. Dadurch wird der Namensraum des Dateisystems (hierarchisch) effektiv auf einen flachen komprimiert, was aufgrund von Namenskonflikten problematisch ist. Dies führt beispielsweise zu Problemen für Benutzer, die Dienste in ~/fooproject/master und ~/barproject/master .

Ich denke, dass Projektnamen unwichtig sind. Vielleicht besteht eine Möglichkeit, Docker-Compose robust zu machen, darin, Projektnamen zu generieren, die auf dem vollständigen Pfad basieren (dh home_flaviovs_fooproject_master )?

Ich mag jedoch die beharrliche Idee. In der Lage zu sein, den Projektnamen an Git zu übergeben, ist ein solcher häufiger Anwendungsfall. Vielleicht ist das Lesen einer .env.default -Datei vor .env eine einfache Lösung dafür (welche BTW würde sich auch um die langjährige # 210 kümmern)?

Ich habe dieses Problem gelöst, indem ich Docker-Compose-Binärdateien mit meiner eigenen Funktion umschlossen habe, damit ich die Funktion von überall aus aufrufen kann. Dadurch wird die ENV-Datei geladen und überall die richtige Docker-Compose-Datei verwendet.

Natürlich können Sie dies erweitern, um eine Funktion pro Projekt oder etwas zu haben. Ich denke, es könnte Nachteile geben, aber ich habe sie nicht herausgefunden.

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

Ich habe ein Problem mit der Kollision von Bildern, und es sieht wirklich seltsam aus, dass ich project_name nicht in der Datei docker-compose.yml festlegen kann, da dies eine sehr logische und direkte Lösung darstellt. Eigentlich war es eine schlechte Idee, überhaupt einen Namen aus dem Projektordner zu nehmen. In vielen Fällen können Projektordner wie / home / project1 / repository, / home / project2 / repository usw. sein. In diesem Fall hat Docker dieselben Bildnamen wie repository_app generiert.

@vedmant Sie können den docker-compose.yml festlegen, verwenden Sie einfach image und build .

Also ... Wie wäre es jetzt durch Projekte im gleichnamigen Ordner getrennt?

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

Vielleicht wurde dies bereits vorgeschlagen. Aber warum nicht eine wichtige Änderung in version: 4 vornehmen und ein neues Schlüsselwort hinzufügen, um das Festlegen des Projektnamens von docker-compose.yml ?

Mein .docker-compose / Projektname hat nicht funktioniert ...
--Projektname hat funktioniert

Ich möchte den Projektnamen auch in der Datei docker-compose.yml festlegen.

Mein Anwendungsfall ist, dass ich eine docker-compose.yml -Datei habe, die eine Web-App und einen Postgress-Datenbankdienst enthält.
Ich möchte auch separate docker-compose.yml -Dateien für Ad-hoc-Aufgaben - im Grunde beschreibt ich Ad-hoc-Aufgaben, die ich mit Docker-Compose orchestrieren möchte. Diese Ad-hoc-Aufgaben müssen dieselben Dienste / Netzwerke / Volumes nutzen, die im Hauptprojekt verwendet werden.

Ein Beispiel für eine Ad-hoc-Aufgabe, die ich mit Docker-Compose orchestrieren möchte, könnte sein. Migrieren von Daten in die postgress Datenbank. Es ist nützlich, dies mit Docker-Compose zu orchestrieren, da die Aufgabe möglicherweise das Hochfahren zusätzlicher Dienste und Volumes, Netzwerke usw. neben den aktuellen umfasst, um diese Aufgabe zu erfüllen.

Um dies zu erreichen, kann ich eine separate docker-compose.adhoctask.yml -Datei erstellen, um die Aufgabe darzustellen, sodass ich diese Aufgabe nur bei Bedarf bei Bedarf ausführen kann. Da es sich im selben Verzeichnis wie die ursprüngliche Docker-Compose-Datei befindet, erhält es standardmäßig denselben Projektnamen und hat Zugriff auf dieselben Netzwerke, Volumes usw.? und so funktioniert.

Das Problem tritt jedoch auf, wenn diese Ad-hoc-Task-XML-Datei nicht im selben Verzeichnis der obersten Ebene (oder sogar im selben Repo) wie das Hauptverzeichnis docker-compose.yml gespeichert werden soll. Zum Beispiel möchte ich vielleicht die Ad-hoc-Aufgabe docker-compose.adhoc.yml in einen Unterordner einfügen, mit den DOCKERFILE und den Assets, die die Aufgabe benötigt, gut isoliert / gruppiert, als ihr eigenes Anliegen. Sobald ich es in einen Unterordner verschiebe, stimmt der Projektname nicht mehr überein. Dies bedeutet, dass es keinen Zugriff mehr auf dieselben Volumes / Netzwerke usw. hat, die im Hauptprojekt definiert wurden.

Wenn ich die projectname in den docker-compose.yml und docker-compose.adhoc.yml angeben könnte - dann könnte ich sie strukturieren, wie ich will (sogar in separate Repos einfügen) und sie trotzdem ausführen, ohne es zu müssen Geben Sie ständig zusätzliche Befehlszeilenargumente an oder wechseln Sie die Umgebungsvariablen.

Dies ist ein echtes Problem für mich, da es zu Namenskonflikten kommt

Ich habe mehrere Projekte in der Struktur

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

Wenn ich jetzt ein Docker-Compose in einem Projekt starte, erstellt es das Netzwerk backend_default und stellt Container voran, die nicht explizit mit backend_ .. benannt sind. Wenn ich das andere Projekt starten möchte, habe ich Um zum richtigen Ordner zurückzukehren und zuerst docker-compose down auszuführen, um Konflikte zu vermeiden - andernfalls würden neue Container im selben Netzwerk gestartet, und wenn sie dann deaktiviert würden, würden sie sich über Orhans beschweren, wenn es keine gibt.

Auch ein Problem für mich. Ich habe mehrere Projekte und verwende Docker-Compose für dynamische Demo-Stände auf einem einzelnen Computer, einem Stand pro Zweig.

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

"Master" und "Entwickler" stehen also in Konflikt zwischen Projekten. Eine .docker-compose -Datei könnte das lösen.

@simplesmiler Auf die Gefahr hin, mich zu wiederholen, löst ein .env das bereits.

@ shin- .env wird häufig für Geheimnisse verwendet, die nicht in der Versionskontrolle enthalten sind.

Was @simplesmiler möchte, ist eine Möglichkeit, den Projektnamen für die Versionskontrolle zu übernehmen, während .env außerhalb der Versionskontrolle bleibt.

Soweit ich das beurteilen kann, gibt es immer noch keine Möglichkeit, dies einfach zu tun.

@thedeeno das ist nicht was ihr Beitrag sagt. Arbeitest du zusammen Wenn nicht, sollten wir nicht davon ausgehen, dass der Anwendungsfall eines anderen über das explizit Geschriebene hinausgeht.

Wir arbeiten nicht zusammen. Das ist meine Interpretation ihres Problems. Ganz fair, ich könnte mich irren und ich könnte annehmen.

Ich wünschte, wir hätten zusammengearbeitet, damit wir uns einen Kaffee holen könnten. Ich hoffe du denkst nicht, dass ich hier ein Idiot bin.

Vielleicht erinnere ich mich nur falsch an diesen Thread: Gibt es eine Möglichkeit, den Projektnamen für die Versionskontrolle zu übernehmen, während .env ignoriert wird?

Gibt es eine Möglichkeit, den Projektnamen für die Versionskontrolle zu übernehmen, während .env ignoriert wird? Oder fehlt dies noch?

Derzeit nicht. Wie ich vor einigen Monaten erwähnt habe ^ 1, ist geplant, docker-compose.env als sekundäre Env-Datei zu haben, die in die Versionskontrolle aufgenommen werden kann. Es ist etwas in die Prioritätenliste gerutscht, aber ich hoffe, bald darauf zu kommen.

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

Das sind gute Nachrichten! PRs akzeptieren?

Ich habe die Hoffnung vor langer Zeit aufgegeben, aber versuchen wir es noch einmal:

Ich denke, viele hier verstehen immer noch nicht, warum wir gezwungen sind, eine zweite Datei für diese Einstellung zu verwalten.

So wie ich es verstehe, bricht es für einige wenige hier ihre Projekteinrichtung. Aber für die Mehrheit in diesem Thread wäre das kein Problem. Wie kann es also sein, dass diese wenigen diese Einschränkung allen anderen auferlegen, denen diese Funktion fehlt? Warum können wir nicht mehrere Optionen haben, um den Namen zu konfigurieren und die Entscheidung dann uns zu überlassen?

Es macht nicht einmal logisch Sinn: Das Fehlen dieser Einstellung in docker-compose.yml ist so offensichtlich, dass ich nicht einmal glauben konnte, dass diese Option fehlt, als ich im Handbuch danach gesucht habe. Fast jeder andere Aspekt Ihres Setups kann dort konfiguriert werden. Für mich ist das ein klarer Bruch in der Konfigurationslogik.

Ich denke, man könnte sagen, dass (fast) alle Einstellungen in docker-compose.yml vom Projektnamen "erfasst" werden.

Wie in # 4841 vorgeschlagen, sollte eine Option zum Festlegen der zu verwendenden .env-Datei (dh --env-file ) sehr nützlich sein.

@roipoussiere siehe https://github.com/docker/compose/issues/4841#issuecomment -414543951

Danke @ schmunk42.
Das heißt aber, ich muss eine Hierarchie erstellen wie:

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

statt etwas einfacher wie:

.
├── a.env
├── b.env

Ja, siehe auch https://github.com/docker/compose/issues/745#issuecomment -345054893 - Möglicherweise müssen Sie dies in einem neuen Fenster öffnen, da es manchmal hier versteckt ist : nerd_face:

Ich stimme dem Vorschlag von --env-file zu. Habe nur dafür ein Ticket gemacht. Gehen Sie und mögen Sie es, wenn Sie diese Option möchten.

Ich habe also nur ein paar Kommentare zu diesem Fehler / Feature gelesen, und die Tatsache, dass die Diskussion fortgesetzt wird und offen ist, bringt mich zu dem Schluss, dass es 4 Jahre her ist, seit dies ursprünglich eröffnet wurde und es immer noch keine Lösung gibt? Können wir eine Teilentscheidung treffen und dann vorwärts gehen?

Ich gebe zu, ich habe nicht die gesamte Ausgabe und alle damit verbundenen Probleme gelesen, aber es gibt interessante Probleme rund um dieses Thema, die dies komplizierter machen, als es auf den ersten Blick scheint. Wie wir alle wissen, wird .env häufig für geheime Werte verwendet, sodass Sie dies normalerweise bei der Versionskontrolle ignorieren.

Angenommen, Sie arbeiten mit Stripe, wodurch Sie Testschlüssel und Live-Schlüssel haben, AKA. 2 Schlüsselsätze zum Arbeiten. In der Entwicklung verwenden Sie häufig die Testschlüssel, und in der Produktion verwenden Sie am Ende die Live-Schlüssel.

Das bedeutet automatisch, dass Sie .env alleine verwenden können, um mit geheimen Werten umzugehen, da Sie in jeder Umgebung unterschiedliche Schlüssel haben und die Werte in Ihrer Datei nicht zwischen dem Ausführen von wechseln müssen App in Dev oder Prod (das wäre verrückt und super fehleranfällig).

Am Ende erstellen Sie wahrscheinlich sowohl eine .env als auch eine .env.prod -Datei und ignorieren beide bei der Versionskontrolle. Auf diese Weise können Sie Ihre Test- / Entwicklungsschlüssel in der Entwicklung haben und diese dann mit env_file in Ihrer Entwicklungskompositionsdatei referenzieren.

Aber dann verweisen Sie in der Produktion sowohl auf .env als auch auf .env.prod in Ihrer Produktionskompositionsdatei.

Aber sehen Sie, wohin das führt? Derzeit können Sie mit Docker Compose keine optionalen env_file -Dateien haben. Wenn die Datei nicht vorhanden ist, wird Docker Compose in die Luft gesprengt, sobald Sie versuchen, Docker Compose auszuführen.

Sie benötigen also automatisch eine .env -Datei, um am Ende zu existieren, wenn Sie sie mit env_file und dies ist auch nicht auf Stripe beschränkt. Viele Web-Frameworks haben bestimmte Einstellungen, die umgebungsspezifisch sind, sich jedoch sowohl in der Entwicklung als auch in der Produktion ändern würden (z. B. SERVER_NAME mit Flask).

Das bedeutet, dass wir nur eine .env_example -Datei haben, die Sie zur Versionskontrolle verpflichten, und es wird erwartet, dass der Endbenutzer diese Datei in .env umbenennt und sie dann in dieser Datei enthält unser alter Freund COMPOSE_PROJECT_NAME .

Was jetzt die Frage aufwirft. Benötigen wir tatsächlich eine alternative Methode zum Festlegen des Projektnamens? Ich bin nicht davon überzeugt, aber ich bin davon überzeugt, dass das Festlegen eines benutzerdefinierten Projektnamens in jedem Projekt eine gute Idee ist, oder zumindest etwas anderes als der Ordnername, da es leicht zu Namenskonflikten kommen kann.

Ist dieses Problem bitte auf einer Straßenkarte?

Der Anwendungsfall hierfür wäre das Ändern von COMPOSE_PROJECT_NAME für den Fall, dass Ihr Projekt mehrere Docker-Compose-Dateien enthält (z. B. eine für dev, test, möglicherweise eine Basis, möglicherweise eine lokale Testversion usw.). Möglicherweise müssen Sie drehen bis zu 2 sehr unterschiedliche Umgebungen, die voneinander getrennt sind.

In unserem Fall können wir diese Docker-Compose-Einschränkung umgehen, indem wir COMPOSE_PROJECT_NAME in unserem Makefile erstellen.

Ich würde gerne sehen, dass dies innerhalb des Compose Yaml selbst konfigurierbar ist.

Ist das noch offen? Ach du lieber Gott...

Gezeichnet. Ich möchte auch, dass der Projektname in der Compose-Yaml-Datei festgelegt werden kann.

Das dauert ewig 🤦‍♂

wäre sehr hilfreich, um diese Funktion zu haben

Diese Funktion wäre in dem Projekt, an dem ich arbeite, sehr willkommen

Ok, aus diesem langen Thread können wir schließen, dass der Projektname nicht in der Datei docker-compose.yml enthalten ist, da die Hauptentwickler dagegen sind und keine solche Pull-Anfrage zusammenführen.

Können wir also bitte zum ursprünglichen Vorschlag zurückkehren, der oben in dieser Ausgabe steht: um den Projektnamen dauerhaft zu machen. Die Verwendung einer Datei .docker-compose oder eines Verzeichnisses .docker-compose klingt für mich in Ordnung. Aber es wäre schön, wenn wir endlich Fortschritte bei der Umsetzung erzielen könnten.

Ich würde dieser Liste von Alternativen eine ENV-Variable hinzufügen.

Eine wesentliche Wurzel aller Meinungsverschiedenheiten ist, dass dieser Thread / dieses Problem darin besteht, dass er für viele Menschen nicht funktioniert, wenn er sich in einer ENV-Variablen befindet. Sie möchten in der Lage sein, es für ein Repo festzuschreiben (optional kann die Standardempfehlung natürlich sein, es nicht festzuschreiben.)

Die Verwendung von ENV anstelle von Yaml-Inhalten widerspricht der Philosophie, Yaml-Dateien zwischen verschiedenen Projekten auszutauschen. Tatsächlich ist es offiziell dokumentiert: https://docs.docker.com/compose/extends/ (siehe beispielsweise "Beispielanwendungsfälle"). Wenn Sie eine einzelne Basis-Yaml-Datei verwenden und dann Dateien für dev, test und prod überschreiben und Gott weiß, was noch alles ist, ist es nicht sinnvoll, sie unter demselben Projektnamen auszuführen oder den Projektnamen von ENV / cli festzulegen. Es werden nur N * N Kombinationen erstellt, während N gültig sind.

Ich habe mehrere dieser Diskussionen durchlaufen und sehe eine TONNE Kommentare von Leuten, die möchten, dass der Projektname in der YML-Datei konfiguriert werden kann. Aber nicht ein einziger Kommentar, der erklärt, warum das nicht getan werden sollte. Diese Diskussionen reichen weit zurück.

Als jemand, der nach einer benutzerfreundlichen Lösung sucht und feststellt, dass es keine einfache Möglichkeit gibt, den Projektnamen festzulegen, der keine sorgfältige Aufmerksamkeit des Benutzers für die ausgeführte Befehlszeile erfordert (was mit der Kernidee eines Tools konkurriert, für das Sie sich entscheiden Übergeben Sie up und starten Sie auf magische Weise einen vollständigen Cluster von Servern. Ich bin schockiert, dass dies eine offene Frage ist. Wenn es eine klare Erklärung dafür gäbe, warum die Implementierung problematisch oder problematisch ist, wäre ich interessiert.

Eine elegante Lösung könnte darin bestehen, Platzhalter in der Eigenschaft container_name (und andere dynamische Namen wie Volume, Netzwerk, ...).

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

mit einer solchen Konfiguration könnte man verwenden

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

Bearbeiten: Dies ist keine perfekte Lösung, da dies zu Konflikten für Personen führen kann, die zwei unterschiedliche Projekte innerhalb desselben Ordnernamens verwenden

@jderusse

Eine elegante Lösung könnte darin bestehen, Platzhalter in der Eigenschaft container_name (und andere dynamische Namen wie Volume, Netzwerk, ...).

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

mit einer solchen Konfiguration könnte man verwenden

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

Bearbeiten: Dies ist keine perfekte Lösung, da dies zu Konflikten für Personen führen kann, die zwei unterschiedliche Projekte innerhalb desselben Ordnernamens verwenden

Ich mache das auch und dachte, dies würde das Konfliktproblem beheben, obwohl wir die Variable COMPOSE_PROJECT_NAME auf einen eindeutigen Wert in der Datei .env .

An dieser Stelle möchte ich wirklich nur verstehen, warum die Betreuer Lösungen ablehnen. Es gibt bereits eine Pull-Anfrage für eine Lösung.

Sobald wir wissen, was falsch ist, können wir daran arbeiten, es zu beheben. Zu diesem Zeitpunkt sehe ich kein anderes Feedback als "abgelehnt".

Wir haben diese 2 Kommentare:

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

Aber ich muss zugeben, dass ich selbst beim Lesen dieser Kommentare nicht ganz verstehe, warum ich nicht einfach den Projektnamen zur yaml-Datei hinzufüge. Für diejenigen, die glauben, dass dies ihre Docker-Compose.YAML-Dateien weniger allgemein macht, sollten sie den Namen dann einfach nicht in die YamL-Datei einfügen, aber bitte lassen Sie den Rest von uns eine Option dazu.

OK, ich gebe mein Bestes, um Verweise auf andere Kommentare durchzulesen. Ich würde mich zumindest über einen kurzen Klappentext freuen, der zusätzlich zur Referenz auf den Inhalt der Referenz verweist, um sicherzustellen, dass ich das Richtige lese und den richtigen Inhalt erhalte.

Lassen Sie mich versuchen, zusammenzufassen, was ich sehe, sind die Bedenken. Jede Hilfe, um dies zu klären, wäre dankbar.

(1) Durch Hinzufügen eines Projektnamens zur YML-Datei kann das Projekt weniger wiederverwendbar werden, da dadurch die Ausführung einer YML-Datei mit mehr als einem Projektnamen verhindert oder zumindest erschwert wird.
(2) "Die Qualität des Projekts würde dadurch zu stark leiden, um das Hinzufügen zu rechtfertigen (in dieser Form)."
(3) "Wenn sich der Projektname in der Erstellungsdatei befindet, können zwei beliebige Projekte denselben Namen verwenden, was zu einem Konflikt führt, der beide Projekte beschädigen würde."

Ich habe Gedanken dazu, aber ich werde mich mit Kommentaren zurückhalten, bis wir uns auf die Bedenken einigen können, die angegangen werden müssen. Ist das vernünftig?

(4) Abwärtskompatible Implementierung (Vorrang / Reihenfolge der Werte)

(1) Durch Hinzufügen eines Projektnamens zur YML-Datei kann das Projekt weniger wiederverwendbar werden, da dadurch die Ausführung einer YML-Datei mit mehr als einem Projektnamen verhindert oder zumindest erschwert wird.

Wieder gibt es eine offizielle Möglichkeit, die Konfiguration in Basis und Datei aufzuteilen und zu erben - https://docs.docker.com/compose/extends/. In der Basiskonfiguration konnte kein Projektname eingerichtet werden.

Für mich ist der primäre Anwendungsfall, nach dem ich suche, die Möglichkeit, mehrere Instanzen des Projekts lokal auszuführen (Entwickler, Testumgebungen usw.).

Möglicherweise besteht die Lösung darin, dass Sie entweder den Projektnamen explizit oder eine Pfadüberquerung festlegen können.

Wenn ich den Projektnamen in der yaml-Datei explizit auf my-project setze, kann dies die Dinge für eine einzelne Instanz eines Projekts vereinfachen oder wenn ich so etwas wie das Hinzufügen aller meiner Docker-Dateien in einem docker -Ordner mache über mehrere Projekte hinweg.

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

Dies hilft jedoch nicht bei mehreren Instanzen desselben Projekts. Wie wäre es also mit einer Pfadüberquerung?

project_name: ../(*) also mit dem gleichen Beispiel

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

ähnlich project_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

Die Angabe der Durchquerung sollte wahrscheinlich etwas ausführlicher sein als mein Daumenlutscher, aber zumindest auf diese Weise haben wir meiner Meinung nach Flexibilität, um alle Anwendungsfälle abzudecken.

Nur halb im Scherz: Das heißt, um einen festen Namen in meiner docker-compose.yml zu konfigurieren, würde ich eine Datei mit dem gewünschten Namen erstellen und dann project_name: name-of-the-file-named-like-the-name-i-want ?

Ich habe derzeit eine Ladung von docker-compose Dateien im selben Verzeichnis. Wie dc-work.yml , dc-server.yml usw., die alle unterschiedliche, nicht verwandte Dienste laden.

Wenn ich docker-compose up dc-A.yml und dann docker-compose up dc-B.yml ausführe, nervt Docker mich, dass verwaiste Dienste ausgeführt werden (natürlich nicht, es liegt am verdammten Projektnamen).

Gibt es wirklich keine Möglichkeit, dies zu lösen? Es scheint eine echte Zeitverschwendung zu sein, jede dc-A|B|C|etc.yml -Datei in ein eigenes Verzeichnis zu verschieben und dann in jede Datei zu wechseln, um alle meine Dienste zu laden, oder fehlt mir etwas?

Warum wurde dieses Problem nicht behoben? Die klare und unkomplizierte Lösung wurde von @ cr7pt0gr4ph7 hier vorgestellt: https://github.com/docker/compose/issues/745#issuecomment -182296139. Es erhielt viele Stimmen. Jedes einzelne Anliegen wurde in der Diskussion angesprochen. Und vor allem löst es viele Probleme für viele Menschen. Was gibt?

Dieses Problem tritt auch auf, weil wir eine feste Projektverzeichnisstruktur mit einem .docker-Ordner verwenden, der alle Docker-bezogenen Inhalte enthält. Daher habe ich am Ende viele .docker-Projektnamen - ich arbeite an einer Microservices-Architektur Es ist also normal, mehrere zu haben ... aber dieses kleine Ding stört immer wieder -> auch PHPStorm usw. hat nicht die Option, das Argument -p / - project-dir zu übergeben, und ich kann nicht Verwenden Sie dazu wirklich eine .env, denn glauben Sie mir, das Einstellen des richtigen Werts wird vergessen ...

Entwickler, bitte teilen Sie uns mit, wie das Problem gelöst werden soll.

Fügen Sie der Docker-Compose-Datei möglicherweise eine Eigenschaft hinzu, um den Projektnamen festzulegen?

@ AyushyaChitransh

Entwickler, bitte teilen Sie uns mit, wie das Problem gelöst werden soll.

Dies ist die beste Zusammenfassung:
https://github.com/docker/compose/issues/745#issuecomment -182296139

Es wurde viel diskutiert. Es besteht keine Notwendigkeit für weitere Diskussionen. Die Projektbetreuer müssen nur die Threads (Plural) lesen und das Notwendige tun.

Für mich ist es immer noch das: https://github.com/docker/compose/issues/745#issuecomment -248644429

Für mich ist es immer noch das: # 745 (Kommentar)

Ja, es gibt eine bestehende, aber schlechte Lösung. Diese Kommentare wurden abgelehnt und die Probleme wurden von vielen klar angegeben. Die verlinkten Kommentare gehen einfach nicht auf die meisten berechtigten Bedenken ein, die in diesen Threads geäußert werden.

Tbh, es ist eine Art Streitpunkt. Viele von uns sind zu Kubernetes gewechselt, um Funktionen vom Typ docker-compose . Es ist ein wenig ausführlich. Aber es funktioniert und wird von den Cloud-Anbietern gut unterstützt.

@ AyushyaChitransh
Wir möchten den Mechanismus verwenden, um den Projektnamen wie hier beschrieben festzulegen: https://github.com/docker/compose/issues/745#issuecomment -182296139

1. Befehlszeile arg.
2. Umgebungsvariable (.env-Datei)
3. In Datei direkt erstellen
4. Ordnerpfad

Denken Sie nicht, dass dies beanstandet wird.

Es geht um Portabilität, wie oben erwähnt, ähnlich, wenn container_name , was auch nicht Teil von docker-compose.yml . Sie können dieselbe Konfiguration nicht mit vorhandenen Einstellungen wiederverwenden.

Wenn Ihr Workflow auf dem Ordnerpfad basieren soll und irgendwie project-name in Ihre Konfiguration eingefügt werden soll, z. Durch das Zusammenführen mehrerer zusammengesetzter Dateien, Vorlagen usw. wird das gleiche Problem auftreten: Überschreiben vorhandener Stapel.

Tut mir leid, das zu sagen, aber dies sollte als wontfix geschlossen werden (bearbeiten) oder eine neue MAJOR (!) Version veröffentlichen

@ schmunk42

Wenn sich Ihr Workflow auf den Ordnerpfad und den Projektnamen stützen soll, werden diese in Ihre Konfiguration eingefügt, z. Durch das Zusammenführen mehrerer zusammengesetzter Dateien, Vorlagen usw. wird das gleiche Problem auftreten: Überschreiben vorhandener Stapel.

Erstens würde der Projektname in Erstellungsdateien nur von denjenigen festgelegt, die ihn benötigen, und genau deshalb, weil sie möchten, dass die Erstellungsdateien mit vorhandenen Stapeln funktionieren. Sie können Ihre Warnung zu den Dokumenten um diese Einstellung hinzufügen.
Zweitens gilt für diejenigen, die sich auf einen bestimmten Projektnamen stützen, Folgendes:

1. Was passiert, wenn die Compose-Datei von einem Git-Repo heruntergeladen wird und der Repo-Besitzer sie beim nächsten Commit in einen anderen Unterordner verschiebt? Oder den Ordner umbenannt, in dem er sich befindet? Die Auswirkungen auf den Workflow sind bereits vorhanden, da Dateien verschoben werden können und sich dies auf den Projektnamen auswirkt.
2. Wenn Sie sich auf einen bestimmten Projektnamen verlassen, haben wir den Mechanismus vorgeschlagen, um dies sicherzustellen, indem Sie entweder die Umgebungsvariable (ENV-Datei) oder das Befehlszeilenargument verwenden, wenn Sie Docker Compose ausführen. Beides würde jeden Wert überschreiben, der sich zufällig in befindet die Erstellungsdatei (falls eine aus irgendeinem Grund hinzugefügt wurde).

Das Schließen als Wontfix ist nicht sehr hilfreich, ohne zu erklären, warum das oben Genannte nicht gut genug ist, oder einen Weg zu einer Lösung anzubieten.

Ich möchte nicht, dass mein Workflow (oder vielmehr der Workflow meines gesamten Teams) davon abhängt, wie sie den Ordner benennen, in den sie den Code auschecken.

Mein Hauptproblem bei der .env-Dateilösung ist, dass sich diese Datei im Arbeitsverzeichnis des Befehls ausführen muss - während Docker-Compose die Compose-Datei in ein übergeordnetes Verzeichnis auflöst. Es ist daher wichtig, dass alle Entwickler entweder (A) Code in den gleichnamigen Ordner auschecken (unter der Annahme einer Datei docker-compose.yml im Stammverzeichnis eines Code-Repos) oder (B) nur Docker-compose-Befehle ausführen Der Stammordner des Repos erstellt andernfalls widersprüchliche Stapel oder (C) sie haben unterschiedliche Stapelnamen und alle Dokumentationen und Skripte müssen replace stack name here .

Wenn (C) Docker als empfohlene "tragbare" Lösung vorschlägt, muss die Docker-Compose-CLI mit Docker-CLI-Befehlen funktionsvollständig sein, und selbst dann sehe ich immer noch einen Anwendungsfall für diese Funktion.

Wenn sich Ihr Workflow auf den Ordnerpfad und den Projektnamen stützen soll, werden diese in Ihre Konfiguration eingefügt, z. Durch das Zusammenführen mehrerer zusammengesetzter Dateien, Vorlagen usw. wird das gleiche Problem auftreten: Überschreiben vorhandener Stapel.

Wenn ein Projektname zur Docker-Compose-Datei hinzugefügt wird, gibt es diesen sicherlich aus einem bestimmten Grund (wie jede andere Zeile in einer Docker-Compose-Datei). Leider bekomme ich gerade ein kaputtes System, wenn ich gerade meinen ausgecheckten Ordner umbenenne (ohne nachverfolgte Änderungen an Git vorzunehmen).

Ich kann nicht glauben, dass es 2020 ist und wir haben diesen riesigen Anwendungsfall immer noch nicht behoben. Dies ist keine bahnbrechende Änderung, sondern eine völlig optionale Funktion, die durchaus Sinn macht. Angesichts der Tatsache, dass Kubernetes jetzt das Defacto-Bereitstellungstool für Docker ist, würde ich mir vorstellen, dass Docker-Compose hauptsächlich in Entwicklungs- / lokalen Bereitstellungen verwendet wird und dass eine Docker-Compose-Datei im Stammverzeichnis eines Repositorys zum lokalen Ausführen des Codes im Repo sehr beliebt ist Anwendungsfall.

@ dc-pm schrieb: "Angesichts der Tatsache, dass Kubernetes jetzt das De-facto-Bereitstellungstool für Docker ist"

Ich schreibe jetzt keine Docker-Compose-Dateien mehr. Es gibt nicht genug Nutzen für etwas, das nicht produziert wird. Kubernetes hat auch seine Macken. Es wird jedoch von Cloud-Anbietern weitgehend unterstützt.

Um ehrlich zu sein, selbst der Umgang mit Containern in meiner Entwicklungsumgebung ist im Alltag zu mühsam. Ich führe nur die Programme aus ...

@ dc-pm schrieb:

Ich kann nicht glauben, dass es 2020 ist und wir haben diesen riesigen Anwendungsfall immer noch nicht behoben.

Es ist nicht nur so, dass es nicht behoben wurde, sondern dass die Entwickler sich aktiv weigern, es zu beheben.

Ich vermute, dass das Problem darin besteht, dass die Teenager, die diese Software entwickeln, nicht über die nötige Erfahrung verfügen, um die Auswirkungen dieses Anwendungsfalls zu verstehen oder der großen Anzahl ihrer erfahreneren Benutzer zuzuhören, die eine Adressierung beantragen. An diesem Punkt bezweifle ich, dass sie in einer Umgebung mit mehr als einem Stapel oder vielleicht sogar in Teams gearbeitet haben. Andernfalls wäre dies ehrlich gesagt eine ganz offensichtliche Verbesserung!

Einige freundliche Erinnerungen ...
Open-Source-Entwickler sind nicht Ihre "Mitarbeiter / Hochschulen", in den meisten Fällen arbeiten sie meistens kostenlos.
Wenn es eindeutig ein Problem für Sie ist, nehmen Sie sich etwas Zeit, um nach Lösungen zu suchen (und eine PR voranzutreiben).

Schuldzuweisungen sind nicht die Lösung.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

Es ist ziemlich schwierig, eine Änderung voranzutreiben, wenn die Entwickler dagegen sind ...

Am Samstag, 14. März 2020, um 03:19 Uhr, Antoine Gravelot [email protected]
schrieb:

Einige freundliche Erinnerungen ...
Open-Source-Entwickler sind in den meisten Fällen nicht Ihre "Mitarbeiter / Hochschulen"
Sie arbeiten meistens kostenlos.
Wenn es eindeutig ein Problem für Sie ist, nehmen Sie sich etwas Zeit, um nach Lösungen zu suchen
und drücken Sie eine PR.

Schuldzuweisungen sind nicht die Lösung.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/745#issuecomment-598991880 oder
Abmelden
https://github.com/notifications/unsubscribe-auth/ABAXP2DRD7H4YI7KQ7B2URLRHLLQ5ANCNFSM4AZMCNWA
.

@agravelot Ich denke, es gab einige PRs, die möglicherweise nicht ideal sind. Aber in all den Diskussionen haben die Eigentümer sehr deutlich die Erwartungen gesetzt, dass sie diese Funktion nicht wollen. Es geht nicht um Codierung.

@agravelot Entschuldigung für die Verzögerung. Und ich meinte wirklich keine Respektlosigkeit gegenüber den vielen großartigen und talentierten Menschen, die hier dazu beitragen. Aber es ist auch nicht hilfreich, mangelnde Anstrengung zu beschuldigen.

Ich hebe einfach die Unterstützung einer Idee hervor, die trotz klarer Unterstützung über einen sehr langen Zeitraum unzählige Male nicht gehört wurde. Der gesamte Sinn dieses (und des allgemeinen OSS), wie er in unserem Verhaltenskodex definiert ist, besteht darin, den Menschen zu ermöglichen, Code beizutragen und alle Ideen zu respektieren.

Es wurden bereits mehrere Pull-Anfragen verfasst, aber wenn dies der Situation helfen würde, bin ich sehr glücklich, eine weitere zu verfassen.

Was wäre ein konstruktiverer Weg nach vorne?

Es wurden bereits mehrere Pull-Anfragen verfasst, aber wenn dies der Situation helfen würde, bin ich sehr glücklich, eine weitere zu verfassen.

Ja, Entwickler sollten sie weiterhin überprüfen oder als "Wird nicht behoben" (möglicherweise argumentierend) schließen. Wenn Sie dies jahrelang offen halten und kein offizielles Feedback erhalten, verschwenden Sie nur die Zeit der Mitwirkenden (im weitesten Sinne) ). Auch das ist Respektlosigkeit, IMO.

Hey Leute, als Benutzer wollte ich nur meinen Anwendungsfall teilen. Ich habe also 2 docker-compose.yml-Dateien, eine für die Entwicklungsumgebung und eine für die Produktion. Sie befinden sich im selben Ordner. Beide haben einen gleichnamigen Dienst namens "Datenbank". Ich möchte beide Dienste gleichzeitig bereitstellen - nur weil ich es kann, es ist Containerisierung, von der wir sprechen, kann ich so viel skalieren, wie ich will. Sie haben jedoch unterschiedliche "container_name" -Werte.

Also renne ich:

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

Beachten Sie, wie dort "Datenbank-Entwickler neu erstellen" steht, während ich mich eindeutig auf den Dienst im Projekt "prod" beziehe. Überschreibt tatsächlich den vorhandenen Container. Die Datenbank wird beendet und der Container durch den letzteren ersetzt.

Ich gehe davon aus, dass separate "docker-compose.yml" -Dateien separate Projekte bedeuten, aber anscheinend ist dies im wirklichen Leben keine Sache. Das Projekt, für das der Dienst bereitgestellt wird, wird durch den Speicherort der Datei "docker-compose.yml" bestimmt. Damit sie Teil separater Projekte sind, muss der Projektname in einer Umgebungsvariablen separat angegeben werden. Damit funktioniert es endlich:

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

Soviel zur Bereitstellung mit nur einem Befehl, was für ein absoluter Witz. Meiner Meinung nach ist .yml ein großartiger Ort, um den Projektnamen in diesem Zusammenhang anzugeben.

Alternativ konnte ich die Dienste in einem einzigen Projekt platzieren - indem ich ihnen unterschiedliche Namen gab: "database-dev" und "database-prod". Das einzige Problem bei diesem Ansatz ist, dass eine Warnung angezeigt wird, dass der zuvor instanziierte Dienst zu einer Waise wird, da er in der anderen docker-compose.yml nicht erwähnt wird.

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

Das macht keinen Sinn, warum muss es so sein? Warum muss es eigentlich so sein?

EDIT1: @ dc-pm @CharlieReitzel was denkst du? Kannst du einen Kommentar zu meinem Anwendungsfall abgeben, nur für den Fall, dass er ungültig ist :)
EDIT2: Ich habe beide Compose-Dateien in separate Verzeichnisse und Voila gestellt

sooo?

Betreuer, jemand hier?
Entwickler warten 6 Jahre!

Hallo! Ich habe ein Problem in der Compose-Spezifikation erstellt, bei dem der Projektname zum Compose-Schema hinzugefügt wurde, da dies regelt, was wir der Compose-Datei hinzufügen können.
Sobald die Eigenschaft project-name zur Compose-Spezifikation hinzugefügt wurde, können wir die Implementierung in Docker-Compose starten.