Compose: Vorschlag: Projektname dauerhaft machen.

Erstellt am 21. Dez. 2014  ┬Ě  274Kommentare  ┬Ě  Quelle: docker/compose

Standardm├Ą├čig basiert Compose den Projektnamen auf dem Basisnamen des Verzeichnisses compose
Befehle werden von ausgef├╝hrt. Der Projektname kann entweder von ├╝berschrieben werden
├ťbergeben einer -p / --project-name Option f├╝r jeden Befehl oder Festlegen der
COMPOSE_PROJECT_NAME Umgebungsvariable.

Die Verwendung der Option --project-name f├╝r den Befehl _each_ ist fehleranf├Ąllig und fehleranf├Ąllig.
Wenn Sie die Option ├╝bergeben, wenn Sie (zum Beispiel) docker-compose up , f├╝hrt dies dazu
_eine andere_ Instanz des Projekts, das unter einem anderen Namen oder sogar erstellt wird
Container eines anderen Projekts werden ersetzt.

Die Verwendung der Umgebungsvariablen COMPOSE_PROJECT_NAME ist beim Handel nicht hilfreich
mit mehreren Projekten und kann ├Ąhnliche Probleme verursachen.

Vorschlag: Projektname dauerhaft machen

Um diese Probleme zu l├Âsen, speichert compose den Namen eines Projekts in einer Datei in der
Build-Kontext, wenn das Projekt zum ersten Mal gestartet / erstellt wird.

Wenn eine Projektdatei gefunden wird, verwendet compose automatisch den Projektnamen daraus
Datei und l├Âsen Sie eine Ausnahme aus, wenn der Benutzer versucht, den Projektnamen zu ├╝berschreiben
Verwenden der Option --project-name .

Speicherort

Um eine weitere Erweiterung der Optionen zu erm├Âglichen, erstellt compose ein verstecktes Verzeichnis .docker-compose
im "root" -Verzeichnis des Build-Kontexts. In diesem Verzeichnis wird a
project-name Datei wird erstellt und enth├Ąlt nur den Namen des Projekts.

tree -a
.
ÔöťÔöÇÔöÇ .docker-compose
Ôöé┬á┬á ÔööÔöÇÔöÇ project-name
ÔööÔöÇÔöÇ docker-compose.yml

Bitte um Kommentar

Es gibt noch ein paar Dinge zu besprechen;

  • Sollte die Konfigurationsdatei _automatisch_ erstellt werden oder sollte dies
    eine explizite Aktion des Benutzers sein (zB docker-compose init --project-name=foobar )
  • Sollte ein Befehl hinzugef├╝gt werden, um die Konfigurationsdatei (en) zu entfernen? (z.B
    docker-compose destroy )
  • Mit Compose k├Ânnen Sie eine alternative Compose-Datei ( --file ) angeben, falls die
    Projektname auch auf diese angewendet werden? Sollte jede Compose-Datei ihre eigene bekommen
    Aufbau?

Und in einem gr├Â├čeren Umfang;

  • Ist der Projektname tats├Ąchlich wichtig? Wenn nicht, k├Ânnte compose ein _random_ erstellen
    Projektname und speichern Sie diesen in der Konfiguration. Dies w├╝rde sich stark reduzieren
    das Risiko von Namenskonflikten mit anderen Projekten, die auf demselben Server ausgef├╝hrt werden.

edit: umbenannt in Fig to Compose

kinfeature statu0-triage

Hilfreichster Kommentar

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?

Alle 274 Kommentare

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:

@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 ...

@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.

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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen