Was ist der Anwendungsfall? Die meisten der vorgeschlagenen Verwendungszwecke, die ich gesehen habe, waren Antimuster.

Sie können einige von vielen Anwendungsfällen sehen, indem Sie auf den bereitgestellten Link klicken. Wie Sie sehen können, betrachten viele Abonnenten es als eine wirklich nützliche Funktion anstelle von "Antipattern".

Hoppla, jetzt sehe ich, dass "etwas" mit der Ausgabe Nr. 2105 passiert ist, da es überhaupt keine Kommentare mehr gibt ...
Vielleicht habe ich einen falschen Link angegeben ...

Daher finde ich es sehr nützlich, einige Konfigurations- / Initialisierungsdateien in den Container zu kopieren. Als Beispiel einige * .sql-Inhalte für Datenbankcontainer, einige HTML- / JS- / CSS-Inhalte für Apache- / Nginx-Container oder sogar JAR-Dateien für Java-Container. Dies macht es "global" verfügbar / ausführbar, nicht nur auf Computern, auf denen es wie im Fall von Mounting-Volumes erstellt wurde. Dies ist hauptsächlich eine Kombination aus hostlokalen und containerhaltigen Dateien. Tatsächlich kann jeder Container ohne Konfiguration oder Initialisierung als nutzlos betrachtet werden

Dies ist der richtige Link: https://github.com/docker/compose/issues/1664

+1

Dies macht es "global" verfügbar / ausführbar, nicht nur auf Maschinen, auf denen es wie im Fall von Mounting-Volumes erstellt wurde.

Das Problem dabei ist, dass es unglaublich kurzsichtig ist (daher der Begriff "Anti-Pattern"), da Sie gezwungen sind, den Vorgang jedes Mal zu wiederholen, wenn die Container neu erstellt werden sollen. Ganz zu schweigen von der Tatsache, dass es sehr schlecht skaliert (was ist, wenn Sie 10 Container haben? 20? 100?)

Die eigentliche Lösung für Ihr Problem besteht darin, die erforderlichen Dateien in Ihren Build (Dockerfile) aufzunehmen und neu zu erstellen, wenn ein Update erforderlich ist.

Wenn es zusammengesetzt ist und alle "gemeinsam genutzten" Inhalte in Container enthält, ist die Skalierung von 10-20-100-Containern natürlich viel einfacher. Alles, was Sie brauchen, ist, es aus dem Repository zu ziehen und nur die knotenspezifische Konfiguration zu mounten (ja, in diesem Fall mounten). Darüber hinaus müssen Sie Docker-Compose nicht auf jedem Knoten ausführen.
Sicher können wir Docker-Compose in Kombination mit build: & Dockerfile verwenden, aber die Dinge werden etwas komplexer und die Yaml-Konfiguration in Docker-Compose ist viel "eleganter": o)

Ich stoße auf ein Problem, bei dem sich das Kopieren als nützlich erweisen würde (zumindest als Überschreibung). Ich entwickle meistens auf einem Mac, daher sehe ich fast nie ein Problem mit Befehlen, die als Root im Container ausgeführt und auf ein bereitgestelltes Volume exportiert werden. Die kürzlich Verwendung des gleichen Workflows auf einem CentO hat jedoch einige große Probleme verursacht, da Dateien, die dem Root-Benutzer gehören, über das bereitgestellte Volume zum Host hinzugefügt werden. In diesen Fällen möchte ich nur die Hostdateien in den Container kopieren können, anstatt sie zu mounten.

Das verwandte Problem: # 1532

aktualisieren

Ich denke, in meinem Fall kann ich mit der Verwendung von COPY in der Docker-Datei und mehreren Docker-Compose-Dateien davonkommen, von denen eine eine Volume-Bereitstellung verwendet.

Anwendungsfall:
Ich möchte das Verzeichnis aus dem schreibgeschützten Dateisystem im Container verwenden. Die Anwendung erstellt neue Dateien in diesem Verzeichnis. Da das Dateisystem jedoch schreibgeschützt ist, führt dies zu Fehlern.

Ich kann rw volume nicht verwenden, da das Dateisystem schreibgeschützt ist.
Ich kann die Lautstärke nicht verwenden, da der Effekt der gleiche ist.

Es wäre fantastisch, Schreibvorgänge zu erstellen, die nur dann bestehen bleiben, wenn der Container ausgeführt wird. Ich kann Wrapper (https://stackoverflow.com/questions/36362233/can-a-dockerfile-extend-another-one) nur für COPY -Dateien erstellen, aber dies in compose, ähnlich wie volume , wäre besser

Anwendungsfall: Starten mehrerer Docker-Container gleichzeitig von .gitlab-ci.yml, die in das Verzeichnis des Git-Repositorys geschrieben werden müssen.

Wenn der Prozess in einem Container fehlschlägt oder der ci-Job abgebrochen wird, bevor der Container nach sich selbst bereinigt wurde, können die verbleibenden Dateien von gitlab-running aufgrund fehlender Berechtigungen nicht gelöscht werden. Jetzt könnte ich die Dateien im Container aus dem Volume in ein anderes Verzeichnis kopieren, aber das wäre ein Antimuster, nicht wahr?

Unterscheidet sich das von volumes: - ./folder_on_host/ :/folder_in_container/ ?
Auf diese Weise kann ich Dateien in meiner Erstellungsdatei vom Host in den Container kopieren (entspricht COPY)

@harpratap Sie haben Recht, aber der Nachteil ist, dass / folder_in_container nicht existieren oder leer sein darf, sonst wird es überschrieben. Wenn Sie ein Bash-Skript als Einstiegspunkt haben, können Sie dies umgehen, indem Sie Ihre Dateien nach dem Erstellen eines Volumes unter / some_empty_location mit dem ursprünglich vorgesehenen Verzeichnis verknüpfen

+1 für eine COPY-Funktionalität. Unser Anwendungsfall ist das schnelle Aufstehen lokaler Entwicklungsumgebungen und das Kopieren in Konfigurationen für die Entwicklungseinstellungen.

+1 für KOPIEREN. Dies wäre wirklich eine hilfreiche Funktion.

Anwendungsfall: Im Schwarmmodus habe ich einen Dienst, der MySQL-Image verwendet. Ich muss mein Initialisierungs-Scripst in /docker-entrypoint-initdb.d/ kopieren, damit MySQL sie ausführen kann.

Obwohl es möglich ist, ein Bild über MySQL zu erstellen, kopieren Sie die Dateien und verwenden Sie es oder stellen Sie eine Verbindung zu MySQL her
Aufgabe in Schwarm und dann manuell die Skripte ausführen, ist es meiner Meinung nach irgendwie unnötig.

+1 für KOPIEREN / HINZUFÜGEN,

Anwendungsfall:
Fluentd erfordert, dass die Konfigurationsdateien zur Laufzeit in den Container verschoben werden. Diese Konfigurationsdateien werden zur Laufzeit von unserer Jenkins Engine erstellt und ohne COPY / ADD in Docker Compose schlägt dies einfach fehl.

+1 für KOPIEREN

Angenommen, man hat eine gemeinsam genutzte Konfigurationsdatei auf mehreren Docker-Computern mit ihren Docker-Dateien in den jeweiligen Unterverzeichnissen unter dem Docker-Compose-Verzeichnis. Wie kopiert man diese gemeinsam genutzte Konfiguration in jedes Image? Ich kann aus dem Dockerfile-Kontext keine symbolische Verknüpfung zu ../ herstellen, ohne COPY failed: Forbidden path outside the build context

In diesem Fall möchte ich beim Ausführen des Docker-Compose-Builds die Konfigurationsdateien aus dem Docker-Compose-Kontext kopieren, bevor die Docker-Build-Schritte ausgeführt werden.

Ich bin froh, wenn jemand eine saubere Problemumgehung vorschlagen kann.

Das wäre schön, Feature zu haben !!

Bitte kommentieren Sie nicht nur mit +1 - es ist Zeitverschwendung für alle. Wenn Sie zusätzliche Informationen zur Verfügung stellen müssen, tun Sie dies bitte. Andernfalls fügen Sie der ursprünglichen Ausgabe einfach einen Daumen hinzu.

Was nützt es, dogmatisch darauf zu bestehen, dass es ein Antimuster ist, nur weil es in einigen Fällen gelegentlich Probleme verursachen kann? Dies hat definitiv eine gute Verwendung, da Sie einer vorhandenen Datei eine Zeile hinzufügen können, anstatt einen zusätzlichen Ordner und eine zusätzliche Datei erstellen zu müssen, und dann die hinzuzufügende Datei dorthin verschieben müssen. Diese sinnlose, bürokratische Erstellung winziger Dateien ist das eigentliche Antimuster und verhindert, dass Benutzer einfache und leicht zu wartende Docker-Compose-Dateien erstellen.

Wenn Benutzer mit Docker schädliche Dinge tun möchten, finden sie einen Weg, egal was Sie tun. Es ist dumm, sich zu weigern, legitime Funktionen hinzuzufügen, nur weil jemand sie eines Tages missbrauchen könnte.

Ich denke, was Sie tun, ist in diesem Fall tatsächlich der richtige Weg.

Das Problem, das hier angesprochen wurde, war eher, dass die Datei mongo.conf von drei Docker-Images gemeinsam genutzt wurde, die von einer Docker-Compose-Datei orchestriert werden. Wie stellen Sie sicher, dass es in jedem Docker-Build-Unterverzeichnis gleich ist?

Wenn Sie beispielsweise symbolische Links verwenden, beschwert sich Docker darüber, dass sich die Datei außerhalb der Build-Umgebung befindet. Beispielsweise fehlt dem Docker-Build ein Gefühl der Reproduzierbarkeit, da Änderungen außerhalb dieses Verzeichnisses den Build ändern können.

Die einzige Möglichkeit, dies zu orchestrieren, ist eine Dateikopie, die derzeit mit einem Makefile- oder Shell-Skript ausgeführt werden muss, bevor Docker-Compose ausgeführt wird. Es schien also eine Idee zu sein, zu diskutieren, ob dies eine Funktion ist, die Docker-Compose ausführen kann tun, wie es sicherlich ein häufiger Anwendungsfall ist.

Das Problem, das Sie ansprechen, scheint eher die Laufzeitinjektion (Startzeit) einer lokalen Dateimodifikation zu sein.

Ich denke, du bist in Ordnung in dem, was du tust. Was du oben gesagt hast, ist nur, wie es gemacht wird. Ein Docker-Image kann immer so erstellt werden, dass es Umgebungsvariablen akzeptiert, um Fragen zu beantworten, z. B. wo sich das Konfigurationsverzeichnis befindet, und dieses Konfigurationsverzeichnis kann zur Laufzeit mithilfe eines Volumes "injiziert" werden. Dies hängt jedoch vom Design des Docker-Images ab Umgebungsvariablen und Volume-Zuordnungen (Funktionen, die Docker als Änderung der Laufzeitkonfiguration unterstützt).

Ich hoffe, ich habe Ihren Kommentar nicht falsch interpretiert und meine Antwort ist hilfreich.

@jpz - Ich habe irgendwie meinen ursprünglichen Kommentar gelöscht - yikes - sorry! Danke - ja, das ist hilfreich.

Mein ursprünglicher Kommentar lautete wie folgt:

Mein Anwendungsfall ist, dass ich einen Dienst mit mongo deklarieren möchte, ohne mein eigenes benutzerdefiniertes Image erstellen zu müssen, nur um es über eine Konfigurationsdatei wie /etc/mongod.conf zu kopieren.

UPDATE: Ich habe volumes . Vor ein oder zwei Jahren - ich dachte, ich hätte es mit einer schlechten Erfahrung versucht ... aber es scheint in Ordnung zu sein.

+1 für KOPIEREN

Ich habe dafür einen kurzen Überblick erstellt. Es wird davon ausgegangen, dass der Docker-Erstellungsdienst phpfpm heißt. Sie können dies jedoch nach Belieben ändern. Fühlen Sie sich frei zu ändern.
https://gist.github.com/markoshust/15efb29aa5eebf8adae402af18b2e674

Hallo, ich würde gerne wissen, wie der Fortschritt für dieses Problem ist. Jetzt verwende ich Windows 10 Home mit Docker-Toolbox. Es scheint meistens ein Fehler zu sein, wenn ich versuche, eine Datei als Volume in einen Container zu mounten. Es wäre schön, COPY-Funktionen in Docker-Compose zu haben

KOPIEREN / HINZUFÜGEN wäre auf jeden Fall eine willkommene Funktion.

Ein Anwendungsfall: Ausführen einer Graylog-Instanz in Docker für Entwicklungszwecke. Um eine Eingabe automatisch zu starten, muss eine JSON-Spezifikation in / usr / share / graylog / data / contentpacks abgelegt werden
Mit der Funktion KOPIEREN / HINZUFÜGEN ist dies in YML so einfach wie eine einzelne Zeile.

Damit es jetzt funktioniert (am 16. Oktober 2018), müssen Sie ein Volume bis zu diesem Punkt bereitstellen UND den ursprünglichen Inhalt dieses Ordners auf das persistente Volume kopieren. Welches ist ruhig unpraktisch.

Ich würde davon profitieren, ich habe eine Reihe von Tools, die einen Datenbank-Seed in einen Container importieren und dann den devtools-Datenbankimporter basierend auf dieser Datei ausführen. Ich möchte nicht tun müssen:

docker cp "${seed_file}" $(docker-compose ps -q devtools):/tmp/seed_file

um meinen Samen importieren zu können. Und nein, ich werde meine Entwicklungsbilder nicht mit einem festen Schema kompilieren, dies widerspricht zumindest dem Webentwicklungsmuster. Container sollten für die App-Portabilität dienen, nicht für Daten.

Es wäre viel sinnvoller:

docker-compose cp "${seed_file}" devtools:/tmp/seed_file

Alles in allem ist es nur eine kurze Hand, die im Grunde das Gleiche tut, aber es sieht besser aus, überall docker-compose , als Sachen zu mischen ...

1) Dies scheint ein Duplikat von # 3593 zu sein
2) Ich stimme @ shin- zu, dass die ausgearbeiteten Anwendungsfälle einem Anti-Muster folgen
3) aber das Einschließen von Dockers cp Befehl macht Sinn, imo

@funkyfuture Wenn Sie der Meinung sind, dass diese Anwendungsfälle einem

Was ist mit k8s-ähnlichen "Datenabschnitt" ?
Zum Beispiel:

services:
  service1:
    image: image.name
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2
      filename2.yml: |
        foo:
          bar: val1

oder vielleicht das gleiche, aber für den Abschnitt volumes:

volumes:
  service_config:
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2

services:
  service1:
    image: image.name
    volumes:
      - service_config:/service/config

@Schienbein-

Das Problem dabei ist, dass es unglaublich kurzsichtig ist (daher der Begriff "Anti-Pattern"), da Sie gezwungen sind, den Vorgang jedes Mal zu wiederholen, wenn die Container neu erstellt werden sollen. Ganz zu schweigen von der Tatsache, dass es sehr schlecht skaliert (was ist, wenn Sie 10 Container haben? 20? 100?)

Das eigentliche Problem hierbei ist, dass einige Benutzer zu schnell sind, um angeforderte Funktionen zu dissen, da dies im Widerspruch zu ihrer eingeschränkten Sicht auf tatsächliche Anwendungsfallszenarien steht.

Hier suche ich nach einer Möglichkeit, meine Konfigurationsdatei in einen Container zu kopieren, den ich gerade von Dockerhub erhalten habe. Ich habe keinen Zugriff auf die ursprüngliche Docker-Datei und es wäre sehr praktisch, diese Funktion zu haben (anstatt zu versuchen, eine weitere Ebene darüber zu erstellen, was funktionieren würde, aber unpraktisch ist, möchte ich nicht neu erstellen, wenn ich etwas ändere).

Anwendungsfall:

Ich führe eine Datenbank in einer Integrationstestumgebung aus und möchte, dass die Daten bei jeder Iteration zurückgesetzt werden, wenn die Container gestartet werden. Das Einbetten der Daten in ein benutzerdefiniertes Image würde funktionieren, das Mounten eines Volumes ist jedoch umständlich, da die Daten auf dem Host zurückgesetzt werden müssen.

Wir verwalten die Daten unabhängig voneinander und es wäre am bequemsten, nur das Standard-Datenbank-Image zu verwenden - Daten darauf zu kopieren, bevor es ausgeführt wird. Derzeit scheint dies mit Docker-Compose nicht möglich zu sein.

Ich habe einen Anwendungsfall im Sinn. Ich möchte mein Image auf einem Standard-Image basieren, z. B. einem generischen Apache-Server. Ich möchte mein HTML während der Bilderstellung kopieren. Auf diese Weise kann ich mein Basis-Image jederzeit aktualisieren und die Kopieranweisung stellt sicher, dass mein Inhalt in das neue Image aufgenommen wird.

Übrigens verwende ich derzeit Docker-Dateien und eine Build-Direktive in meiner docker-compose.yaml, um dies zu tun. Es wäre schön, wenn ich die Docker-Dateien nicht bräuchte.

@tvedtorama -

Anwendungsfall:

Ich führe eine Datenbank in einer Integrationstestumgebung aus und möchte, dass die Daten bei jeder Iteration zurückgesetzt werden, wenn die Container gestartet werden. Das Einbetten der Daten in ein benutzerdefiniertes Image würde funktionieren, das Mounten eines Volumes ist jedoch umständlich, da die Daten auf dem Host zurückgesetzt werden müssen.

Wir verwalten die Daten unabhängig voneinander und es wäre am bequemsten, nur das Standard-Datenbank-Image zu verwenden - Daten darauf zu kopieren, bevor es ausgeführt wird. Derzeit scheint dies mit Docker-Compose nicht möglich zu sein.

In diesem Problem wird der Wunsch erläutert, Dateien zur Image-Erstellungszeit und nicht zur Laufzeit zu kopieren. Ich würde vorschlagen, ein separates Ticket zu erheben, um die Vorzüge davon zu besprechen. Es kann diese Diskussion verwirren, in die Diskussion über das Einfügen von Laufzeitdateien abzuschweifen (was ich interpretiere, wovon Sie sprechen).

@ c0ze -

Was ist mit k8s-ähnlichen "Datenabschnitt" ?
Zum Beispiel:

...

Ich bin nicht ganz auf dem neuesten Stand, was diese Konfiguration macht, aber ja, das sieht so aus, als wäre es eine Lösung. Wenn Sie Geheimnisse haben (z. B. wie lautet der Login-Benutzername / pwd / port für die Datenbank), wie füge ich diese in meine Docker-Images - Clients und Server - ein, ohne eine Menge Code zu schreiben?

So etwas wie der Datenabschnitt von kubernetes könnte funktionieren - da dies eine einzige Quelle der Wahrheit wäre. Andernfalls kann es vorkommen, dass dieselben Geheimnisse über mehrere Docker-Images hinweg mehrfach verwaltet werden.

Dort gibt es auch den Stand der Technik, der dazu beiträgt, das Gespräch dahingehend voranzutreiben, ob dies tatsächlich eine gute Idee ist, die es wert ist, angenommen zu werden oder nicht.

Für mich begann alles damit, dass wir eine invariante Konfigurationsdatei für mehrere Container freigeben wollten und erkannten, dass es keine Möglichkeit gab, dies zu tun, ohne ein externes Skript für Docker-Compose zu erstellen und die Konfiguration aus einer einzigen Quelle der Wahrheit in jede von ihnen zu schreiben die Docker-Ordner unter dem Docker-Compose-Ordner. Natürlich bekomme ich das Unveränderlichkeitsargument für Docker (z. B. das Dockerfile-Verzeichnis beschreibt vollständig und vollständig, wie das Image erstellt wird). Wenn Sie also nach einer Automatisierung fragen, um Dinge in dieses Verzeichnis zu kopieren, sieht es so aus, als würde es diesen Prinzipien leicht widersprechen.

Ich denke, die Diskussion ist, wie aufdringlich Docker-Compose sein darf. Ist dies ein häufig genug verwendeter Anwendungsfall, um eine solche Automatisierung zu rechtfertigen? Wenn dies nicht der Fall ist, scheinen wir die Mechanismen zur Weitergabe variabler Umgebungsvariablen mit der Verantwortung zu belasten, Geheimnisse von außen aus einer einzigen Quelle der Wahrheit spät (z. B. zur Laufzeit) einzuspeisen. Ich hoffe, meine Punkte sind hier kohärent genug.

Dies ist für mich nicht von großer Bedeutung, aber ich denke, der Anwendungsfall ist es wert, diskutiert zu werden.

Es wäre sehr nützlich für mich. Bei der Arbeit blockiert die Virensoftware die Möglichkeit für Windows 10, Volumes für Container freizugeben. Es ist eine riesige Organisation und es ist kein Anfänger, sie aufgrund einer auf einem anderen Kontinent festgelegten Politik dazu zu bringen, sich zu ändern.

Hallo, mein Anwendungsfall: Ich verwende das Open Source Prometheus Docker-Compose-Setup (Repo wird von anderen Personen verwaltet). Es hat Konfigurationen, die in Containern montiert sind. PROBLEM: Ich kann keine Docker-Komposition auf einem Remote-Computer (wie einem aws-Docker-Computer oder innerhalb eines CI / CD-Läufers) durchführen, da die Konfigurationen nicht ordnungsgemäß bereitgestellt werden können. In diesem Fall möchte ich sie kopieren / einbetten. Für RW-Daten gibt es Volumina, für RO -?

RO-Volumes mit der Möglichkeit, Anfangsdaten festzulegen, ist die andere Option.

Aktuelle Lösung: Stellen Sie über ssh eine Verbindung zum Docker-Host her, klonen / aktualisieren Sie das Repo und führen Sie Docker-Compose Up aus. Dies funktioniert für manuelle Fälle, aber es ist schmerzhaft für die Automatisierung :(

+1

Anwendungsfall: Ich habe einen Entwicklungs-Docker-Computer, auf dem eine Datenbank ausgeführt wird, und bei jeder Einrichtung muss ein aktueller Speicherauszug der Datenbank installiert werden. Im Endeffekt bedeutet das:

1. Ziehen Sie das Datenbank-Docker-Image von extern.
2. Kopieren Sie die ZIP-Datei und extrahieren Sie sie in das laufende Image.
3. Führen Sie db-restore innerhalb des Volumes aus.
4. DB-Dump löschen.

Das große Problem ist nun, dass Schritt 2 für jeden Entwickler immer unterschiedlich ist, da es viele verschiedene Dump-Versionen dieser Datenbank gibt. Am einfachsten wäre es also, wenn jeder Entwickler seine eigene Compose-Datei mit seinem spezifischen Dump-Speicherort / seiner spezifischen Dump-Version hat und dann Lassen Sie Docker das Bild beim Erstellen mit diesem bestimmten Speicherort zusammenstellen, der dann auch im laufenden Betrieb geändert werden kann, wenn eine andere Version erforderlich ist.

Mein Anwendungsfall ist einfach. Ich möchte weder Volumes noch mein eigenes Bild rollen. Ich möchte nur eine einfache defensive Kopie einer Konfigurationsdatei in einen Container legen, nachdem sie erstellt wurde und bevor sie gestartet wird.

Ist das noch ein Problem?
Ich habe eine Django-Anwendung mit einer sehr langen Einstellungsdatei. Für mich wäre es viel einfacher, ein Docker-Image zu erstellen und eine einzelne Konfigurationsdatei in jeden Container zu kopieren.
Alle Einstellungen als ENV zu übergeben, ist für mich das Gegenmuster. Nimmt viel Code auf, ist schwer zu warten und kann mit einem einzigen Kopierbefehl gelöst werden.

Ich habe # 6643 geöffnet und würde mich über Feedback freuen, wie es als Anti-Pattern angesehen wird. Insbesondere in einer Umgebung, in der zahlreiche Konfigurationsdateien möglicherweise im laufenden Betrieb hinzugefügt / geändert werden müssen.

@Schienbein-

Das Problem dabei ist, dass es unglaublich kurzsichtig ist (daher der Begriff "Anti-Pattern"), da Sie gezwungen sind, den Vorgang jedes Mal zu wiederholen, wenn die Container neu erstellt werden sollen. Ganz zu schweigen von der Tatsache, dass es sehr schlecht skaliert (was ist, wenn Sie 10 Container haben? 20? 100?)

Wie funktioniert docker-compose exec mit mehreren Containern?

    --index=index     index of the container if there are multiple
                      instances of a service [default: 1]

Sollten wir nicht versuchen, dasselbe Verhalten mit cp ?

IMHO exec ist so kurzlebig wie cp . Aber ich halte es trotzdem immer für "Entwicklungs" -Befehle, Entwicklungsumgebungen müssen kurzlebig sein, nicht wahr?

Ich hatte den Kommentar über viele Entwickler hier nicht gesehen, die sagten, dass sie kurzsichtig sind, wenn sie versuchen, dies zu schnell zu beheben, indem sie diese Funktion anfordern. Ich finde das etwas hart und herablassend. Wenn es eine Sache gibt, die ich aus meiner jahrelangen Entwicklung gelernt habe, dann die folgende:

Es kommt nicht darauf an, was Ihre Software macht, sondern darauf, was der Benutzer damit macht

Natürlich verstehe ich, dass Sie eine Rolle spielen, um zu verhindern, dass Dinge verrückt werden, aber nicht weil jemand ein Werkzeug verwendet, das falsch auf Ihrer Vision basiert, wird jeder damit anfangen und die Hölle bricht los.

Alle Sonderfälle, die ich hier gesehen habe, sind die meiste Zeit sehr angemessen. Und die meisten dieser Sonderfälle sollten und würden nicht auf dem Produktionssystem auftreten. Sie sind beispielsweise wie mein Fall, den ich vor einiger Zeit erklärt habe, um eine Entwicklungsumgebung anzupassen und spezielle Dateien in einem Container auszuführen, der nicht verwendet werden kann eine Volumenzuordnung. Die meisten Beispiele sagen eindeutig, dass sie keine Schemas, Daten oder Konfigurationsdateien backen möchten und keine Datenträgerzuordnung verwenden können. Daher verstehe ich nicht, warum dies so unangenehm ist, sondern auch den Begriff "kurzsichtig".

Ich denke, Sie sollten Ihre Worte sorgfältig abwägen, wenn Sie solche Dinge sagen ...

1. Ich brauche wirklich keinen Vortrag darüber, was ich sagen oder schreiben darf. Es tut mir leid, dass "kurzsichtig" Sie beleidigt. Es ist immer noch richtig zu sagen, dass diese Dinge von Natur aus in die Docker-Datei gehören.
2. Ich bin kein Betreuer mehr. Bitte hör auf, mich über Dinge zu informieren, über die ich keine Kontrolle mehr habe.

1. Ich muss sagen, dass ich hier auf der Seite von crazycodr bin ... Perfekt gültige Anwendungsfälle aus der realen Welt als "Anti-Pattern" abzulehnen, ohne nützliche praktische und realistische Alternativen anzugeben, ist ein unfreundlicher Ansatz des Entwicklers und ehrlich gesagt sogar ein bisschen unhöflich.
2. Maintainer oder nicht, wenn Sie am Diskussionsteil von Github teilgenommen haben, müssen Sie im Grunde mit Leuten leben, die Ihre Kommentare kommentieren. So funktioniert es einfach. Komm damit klar...

Lass es uns zurückbringen. Ehrliche technische Frage hier. Mit Docker Stack haben wir eine "Configs" Option. Dies ist eine native Docker-Funktion, die jedoch für Dienste und nicht für Container vorgesehen ist. Wie ist es sinnvoll, so etwas eher auf Containerebene als auf Serviceebene zum Laufen zu bringen? Wie implementiert Docker Stack die Konfigurationsbereitstellung? Kann diese Implementierung speziell für Docker-Compose repliziert werden?

Mindestens die Hälfte der hier erwähnten Anwendungsfälle betrifft Konfigurationen, so dass viele Menschen zufrieden wären, wenn nur dieser Juckreiz zerkratzt würde.

Ein weiterer einfacher Anwendungsfall sind Dinge wie die Validierung der Google-Domain. Wenn Sie das WordPress-Bild verwenden, können Sie keine Datei hinzufügen, nach der Google sucht. Sie müssen ein ganz neues Bild erstellen, um dies zu tun.

Auch diese Kommentare, die besagen, dass die Dinge "Anti-Muster" sind, machen kaum Sinn, stinken nach Elitismus.

EDIT: Huch, lesen Sie mehr, Gott sei Dank, er ist nicht mehr der Betreuer

Sie sagen mir also, wenn ich eine winzige Konfigurationsdatei in ein vorgefertigtes Image kopieren möchte (z. B. nginx oder mariadb ), muss ich jetzt mein eigenes Image-Build-Setup verwalten und duplizieren der verwendete Speicherplatz (Original-Image und konfiguriertes Image)?

Dies sollte ein Merkmal sein.

Duplizieren Sie den verwendeten Speicherplatz

Sie sind nicht, wenn Sie Docker verwenden.

Ich mag es, wie Sie eine Sache aus dem herauspicken, was er gesagt hat, was die kleinste Sache in allem ist. Dies sollte eine Funktion sein. Dieses Problem wird immer größer werden, weil die Leute hierher kommen, während Docker wächst, da es ein häufiger Anwendungsfall ist und die Leute nur erwarten, dass es aufgrund des gesunden Menschenverstandes existiert, was den Betreuern, die hier ex und aktuell sind, zu fehlen scheint.

Ich mag es, wie Sie eine Sache aus dem herauspicken, was er gesagt hat, was die kleinste Sache in allem ist.

Ein ungültiges Argument sollte als solches vermerkt werden.

Ich denke, die Sache hier ist, dass das "Anti-Pattern" -Argument bei einer bestimmten Geschäftsstrategie gültig sein kann (siehe @ washtubs- Punkt). Wir sind vielleicht nicht mit dieser Strategie einverstanden, aber das rechtfertigt keine persönlichen Angriffe. Am Ende sind es @ shins frühere Bemühungen mit docker-py , die es Ihnen ermöglichen würden, eine Alternative zu docker-compose zu implementieren.

Welches "Anti-Muster" -Argument? Es wird kein Argument vorgebracht. Es ist nur ein "Nein, weil Anti-Muster" ohne Logik dahinter, nur um es zu sagen, ohne dass irgendetwas es stützt. Es ist, als hätten die Leute gesagt, sie hätten an das Worst-Case-Szenario auf ihrem Kopf gedacht, entschieden, dass das Szenario ein Anti-Pattern-Szenario ist, und dann alles als solches abgetan, ohne über ihr sogenanntes Anti-Pattern-Szenario zu schreiben.

Es ist nur Elitismus. Viele Kommentare hier haben darüber gesprochen, wie lächerlich die Argumentation ist, dies nicht hinzuzufügen, und sie werden alle ignoriert.

Der gesunde Menschenverstand und die Logik kümmern sich nicht um Ihre Gefühle oder Ihren Elitismus. Oder deine erfundenen Anti-Muster.

Ja, @robclancy , bitte behalte es zivil FFS. Ich möchte diese Funktion, aber wenn Sie nur die Betreuer bescheißen wollen, lassen Sie bitte reddit los. Die frühere Korrektur von @funkyfuture ist vollständig gewährleistet.

Am Ende sind es @ shins frühere Bemühungen mit Docker-Py, die es Ihnen ermöglichen würden, eine Alternative zu Docker-Compose zu implementieren.

Ich möchte natürlich keine Gabel für Docker-Compose, wenn Sie dies vorschlagen, insbesondere für eine so winzige Verbesserung. Das ist der einzige andere Weg, auf dem dies passieren wird, und das wäre schlecht für die Community.

Wenn jemand eine PR einreichen würde, würde dies tatsächlich in Betracht gezogen werden? Oder hat das Docker-Compose-Team gerade entschieden, dass sie das nicht akzeptieren werden? Würden Sie etwas in Betracht ziehen, das dem Hinzufügen eines Konfigurationsabschnitts entspricht, der mit Docker-Stack-Konfigurationen kompatibel ist?

Dies ist aus dem Ruder gelaufen ... 'Anti-Pattern' ohne Erklärung macht 'Anti-Pattern' zu einer sehr weit gefassten Definition, gegen die man nicht argumentieren kann. Es gibt auch keine klare Richtung, auf welcher Seite das "Anti-Muster" sitzt; Docker oder Docker-Compose.

Eine klare Definition der Anti-Muster-Reaktionen wäre fantastisch und würde sehr geschätzt.

Die Community wird weiter wachsen, daher müssen etablierte Definitionen vorhanden sein.

Ich möchte damit Artefakte kopieren, die von einer Jenkins-Pipeline generiert wurden, die auf einem Docker-Compose-Stack ausgeführt wird. Und dann kann der Containername zufällig sein, sodass ich docker cp nicht verwenden kann.

Heute muss ich verwenden

docker cp $(docker-compose -f docker-compose.development.ci.yml ps -q test):/app/tests_output ./tests_output

Unterscheidet sich das von volumes: - ./folder_on_host/ :/folder_in_container/ ?
Auf diese Weise kann ich Dateien in meiner Erstellungsdatei vom Host in den Container kopieren (entspricht COPY)

Ich versuche das Gleiche zu tun. Ich habe einen Ordner mit einer CSV-Datei und möchte ihn an logstash weitergeben.
wie kann ich das machen. oder welcher Ordner im Container?
im Moment habe ich etwas folgendes:
./path/to/storage:/usr/share/logstash/ data: ro

Anregungen wären hilfreich

@ shin- Dieses Ticket ist jetzt 1,5 Jahre alt. Wenn 160 Leute Ihnen sagen, dass Sie falsch liegen, sind Sie es wahrscheinlich.

Was brauchen Sie noch, um Sie davon zu überzeugen, dass dies umgesetzt werden sollte?

@isapir , die Unternehmen, die nicht auf ihre Kunden hören, neigen dazu, das Geschäft eher bald zu verlassen. Ich denke, wir sollten in naher Zukunft einige produktionsbereite Docker-Alternativen sehen.

@ shin- Dieses Ticket ist jetzt 1,5 Jahre alt. Wenn 160 Leute Ihnen sagen, dass Sie falsch liegen, sind Sie es wahrscheinlich.

😆 🤣 💯 🥇 😲 😲

Ebenfalls,

Ich bin kein Betreuer mehr. Bitte hör auf, mich über Dinge zu informieren, über die ich keine Kontrolle mehr habe.

@sfuerte Es gibt ein kleines Projekt namens Kubernetes, das Docker-Compose bereits ersetzt hat. Ich frage mich, ob das passiert wäre, wenn die Einstellung zum Nutzerfeedback positiver gewesen wäre.

Wir brauchen ein Schlagwort, um ihren Schlagworten entgegenzuwirken. Es ist alles, womit sie umgehen können.

Diese Funktion wäre total pro-pattern . Das sollte es tun. Der Unterschied besteht darin, dass, obwohl ich diese dumme Sache erfunden habe, es in dieser Ausgabe viele Kommentare gibt, die die Vorteile auf eine Weise zeigen, die eindeutig häufige Anwendungsfälle sind. Und es gibt keine einzige Instanz eines anti-pattern .

@ shin- du wirst dabei markiert, weil du diesen Bullshit-Antipattern-Mist ohne Grundlage in der Realität gestartet hast. Also hör auf über etwas zu weinen, das du verursacht hast.

Ich habe Spaß

Mein Fall ist:

• Während "dev" möchte ich meinen Quellcode als "Volume" erstellen lassen, damit er während der Entwicklung automatisch aktualisiert wird
• Wenn die App zur Veröffentlichung bereit ist und ich sie "bereitstellen" muss, möchte ich die kopierten Dateien kopieren, anstatt Volumes zu sein.

Ich denke, der einfachste Weg, dies zu lösen, besteht darin, 1 Compose-Datei für Entwickler und 1 Compose-Datei für die Produktion zu haben.

Das Problem hier ist, dass ich "Volumes" in der Docker-Datei angeben kann, aber ich kann nicht "Kopie" in der Docker-Datei angeben?

Ist jemand im selben Fall wie ich? Vermisse ich etwas

@ shin- ist das ein Anti-Pattern? Wie würden Sie dieses Problem lösen?

@hems , in einer perfekten Welt möchten Sie, dass Ihre Anwendung als eigenständiges Docker-Image bereitgestellt wird. Wenn Sie also eine Anwendung schreiben, sollte der Quellcode, den Sie bereitstellen möchten, wahrscheinlich Teil von Dockerfile , sodass das Image Ihre gesamte Anwendung enthält. Wenn Sie also in Dockerfile Ihre Quelle in / var / www haben möchten, würden Sie diese eingeben

COPY my-app-src /var/www

Ihre Quelle ist nicht umgebungsspezifisch und gehört daher nur in das Docker-Image. Einfach.

Die meisten von uns möchten eine umgebungsspezifische Konfigurationsdatei in die Container aufnehmen, damit ein vorhandenes Image mit einer bestimmten Docker-Compose-Konfiguration gut funktioniert. Und wir möchten dies tun können, ohne ein Volume für eine kleine Datei zu erstellen oder ein neues Bild zu rollen.

Kann jemand aus dem Docker-Compose-Team dies bitte ernsthaft und unparteiisch betrachten und ein endgültiges Urteil fällen (hoffentlich eines, das alle unreifen Leute ignoriert)? Diese Ausgabe ist seit jeher offen. Das Ergebnis ist wichtig, aber ich persönlich habe es satt, Benachrichtigungen zu erhalten.

COPY my-app-src /var/www

Das ist, was ich sage, bei der Entwicklung möchte ich meine Docker-Compose-Datei verwenden, um VOLUMEN in die Bilder zu mounten, und während des Produktions-Builds möchte ich Dateien in die Bilder kopieren, weshalb ich denke, dass wir in der Lage sein sollten, VOLUMEN zu KOPIEREN und zu mounten Verwenden Sie die Docker-Compose-Datei, damit ich 1 Compose-Datei für Dev und 1 für Production Build haben kann.

Ich arbeite in dem Team, das Compose unterhält, und freue mich, in diese Diskussion einzusteigen. Zunächst werde ich skizzieren, wie wir die Verantwortlichkeiten von Dockerfiles und Compose-Dateien sehen.

Docker-Dateien sind das Rezept zum Erstellen von Images und sollten alle Binärdateien / anderen Dateien hinzufügen, die Sie benötigen, damit Ihr Dienst funktioniert. Hiervon gibt es einige Ausnahmen: Geheimnisse (dh Anmeldeinformationen), Konfigurationen (dh Konfigurationsdateien) und Anwendungsstatusdaten (z. B. Ihre Datenbankdaten). Beachten Sie, dass Geheimnisse und Konfigurationen schreibgeschützt sind.

Mit Compose-Dateien wird beschrieben, wie eine Reihe von Diensten bereitgestellt wird und wie sie interagieren. Das Compose-Format wird nicht nur für eine einzelne Engine (dh: docker-compose ) verwendet, sondern auch für orchestrierte Umgebungen wie Swarm und Kubernetes. Das Ziel des Compose-Formats besteht darin, das Schreiben und lokale Testen einer Anwendung zu vereinfachen und sie dann ohne oder mit nur geringen Änderungen in einer orchestrierten Umgebung bereitzustellen. Dieses Ziel schränkt ein, was wir im Format ändern können, da grundlegende Unterschiede bestehen, z. B. wie jede Umgebung mit Volumes und Datenspeicherung umgeht.

Wenn wir die Verantwortlichkeiten für die Dockerfile- und Compose-Datei wie folgt aufteilen, können wir die Bedenken gut trennen: Was ist in jedem Container-Image (Dockerfile) enthalten, wie werden die Dienste bereitgestellt und interagieren (Compose-Datei).

Ich werde jetzt jede der Ausnahmen durchgehen, die Sie in einem Bild speichern. Für Geheimnisse möchten Sie nicht, dass diese in Bilder eingebrannt werden, da sie gestohlen werden könnten und sich im Laufe der Zeit ändern könnten. Docker Secrets werden verwendet, um dies zu lösen. Diese funktionieren je nach der Umgebung, in der Sie sie bereitstellen, geringfügig unterschiedlich. Im Wesentlichen besteht die Idee darin, dass Sie Anmeldeinformationen in einer Datei speichern können, die zur Laufzeit schreibgeschützt in ein tmpfs-Verzeichnis im Container bereitgestellt wird. Beachten Sie, dass dieses Verzeichnis immer /run/secrets/ und die Datei der Name des Geheimnisses ist. Geheimnisse werden nur bei Swarm, Engine ( docker-compose ) und Kubernetes unterstützt.

Für Konfigurationsdateien oder Bootstrapping-Daten gibt es Docker-Konfigurationen . Diese funktionieren ähnlich wie Geheimnisse, können aber überall montiert werden. Diese werden von Swarm und Kubernetes unterstützt, jedoch nicht von docker-compose . Ich glaube, wir sollten Unterstützung für diese hinzufügen, und dies würde bei einigen der in dieser Ausgabe aufgeführten Anwendungsfälle helfen.

Schließlich gibt es Anwendungsstatusdaten, die extern gespeichert werden müssen. Ich werde nicht darauf eingehen, da es nicht mit diesem Problem zusammenhängt.

Mit diesem Rahmen kann ich ein paar Fragen beantworten:

• Fügen wir dem Compose-Format ein copy -Feld hinzu? Nein, ich glaube nicht, dass wir das tun werden, da dies in orchestrierten Umgebungen keinen Sinn ergibt.
• Werden wir docker-compose configs Unterstützung hinzufügen? Ja, ich denke wir sollten.
• Werden wir ein docker-compose cp hinzufügen? Vielleicht bin ich mir da noch nicht sicher. Es wäre im Wesentlichen ein Alias ​​für ein docker container cp .

Vor diesem Hintergrund gibt es einige Tools, die hier verwendet werden können:

• Mehrstufige Builds, mit denen Sie Dateien mithilfe von Zielen bedingt zu einem Bild hinzufügen können.
• Geheimnisse, mit denen Sie zur Laufzeit Anmeldeinformationen an einen Dienst übergeben können.
• Konfigurationen, mit denen Sie zur Laufzeit Konfigurationsinformationen an einen Dienst übergeben können.

Ich denke, diese Tools lösen alle Probleme, die in diesem Thread aufgeworfen werden.

Dieser Faden ist ziemlich erhitzt. Bitte denken Sie daran, dass sich hinter jedem GitHub-Handle eine echte lebende Person befindet und dass sie wahrscheinlich versuchen, ihr Bestes zu geben (auch wenn sich ihre Frustration zeigt). Wir sind alle begeistert von Compose und möchten, dass das Projekt weiterhin floriert.

Werden wir ein docker-compose cp hinzufügen? Vielleicht bin ich mir da noch nicht sicher.

Ich würde das als hilfreiche Annehmlichkeit wie docker-compose exec .

@ chris-crone Erstaunliche Antwort, danke!

Ich weiß, dass ich nicht für alle spreche, aber ich habe den Eindruck, dass die Unterstützung von configs die überwiegende Mehrheit des Interesses hier befriedigt. Soll dafür eine Ausgabe eröffnet werden?

Und danke, dass Sie einige alternative Ansätze anbieten. Ich wusste bis jetzt nichts über mehrstufige Builds.

Ich habe den Eindruck, dass die Unterstützung von configs die überwiegende Mehrheit des Interesses an hier befriedigt.

Ich bezweifle dies, da ich vermute, dass die Mehrheit hier Swarm nicht verwendet und afaik die config Funktionalität dies erfordert.

Ja, derzeit ist Swarm erforderlich, aber aus dem Kommentar von @ chris-crone ...

Diese werden von Swarm und Kubernetes unterstützt, jedoch nicht von Docker-Compose. Ich glaube, wir sollten Unterstützung für diese hinzufügen, und dies würde bei einigen der in dieser Ausgabe aufgeführten Anwendungsfälle helfen.

... Ich lese, dass dies in Docker-Compose (ohne Schwarm) implementiert werden kann.

Das Ziel des Compose-Formats besteht darin, das Schreiben und lokale Testen einer Anwendung zu vereinfachen und sie dann ohne oder mit nur geringen Änderungen in einer orchestrierten Umgebung bereitzustellen.

In komplexen Apps gibt es möglicherweise einige Konfigurationsdateien, die im laufenden Betrieb angepasst werden müssen. Derzeit ist es am effizientesten (zeitlich und kostenmäßig), den Volumenschlüssel auszufüllen (da keine vernünftige Person beim Testen mehrerer Konfigurationen ein anderes Image erstellen wird, es sei denn, sie hat einen Chef, der es einfach liebt, Geld auszugeben auf dev Stunden).

Swarm und Config werden einige der aufgeführten Anwendungsfälle nicht wirklich beantworten. "Trennung von Bedenken" ist ebenfalls nicht anwendbar, da Compose bereits das tut, was Sie in Docker tun können, aber es vereinfacht. Ein Wrapper ist keine Trennung ... wir bitten Sie nur, ihn ein bisschen weiter zu erweitern ...

https://github.com/docker/compose/issues/6643

Machen Sie sich damit vertraut. Erweitern Sie die Volume-Funktionalität, bei der jede Datei unter dem neuen Schlüssel dynamisch mit einem einzelnen Volume verknüpft und ihren jeweiligen internen Pfaden zugeordnet wird.

Ich denke, hier gibt es zwei Szenarien, die vollkommen gültig sind
Entwicklungsumgebungen. Menschen schaffen flexible Umgebungen mit Quelle
Code in ihre Bilder montiert. Der Quellcode entwickelt sich als Entwicklung
tritt auf und Sie können das Image nicht ständig neu erstellen oder Sie verschwenden nur
enorme Zeit. Das ist genau mein Szenario und ich kann das sehen
Szenario gilt für viele andere Menschen.

Die zweite handelt von Produktionsbildern, in denen Sie Ihren Quellcode backen
(falls Sie mit nicht kompilierten Skripten arbeiten) in Ihr Bild (und
Andererseits war ich es nicht, ich habe es immer noch auf meiner Seite montiert) oder du nur
Kompilieren Sie Ihre Anwendung und kopieren Sie sie in das endgültige Bild. An diesem Punkt,
Die Anwendung wird extrem portabel.

Ich denke, jeder versteht das! Die Frage ist, machen Sie das Docker-Compose
dev hat sich die zeit genommen, die fälle vorzulesen und die bedürfnisse zu verstehen? Es gibt
Theoretisch gibt es hier keine Anti-Patterns, nur Entwickler, die ein Bedürfnis haben und möchten
respektiert werden.

Wir lieben Docker, Docker-Compose und das gesamte Ökosystem, wir nutzen es, weil wir
Ich liebe es und weil wir es benutzen, haben Sie Jobs (zumindest einige von Ihnen werden bezahlt
dafür hoffe ich).

Etwas, das ich in den letzten Jahren gelernt habe und das ich gerne hierher zurückbringe und
Es gibt Folgendes und es trifft sehr gut auf dieses Szenario zu:

Es kommt nicht darauf an, was Ihre Software tut, sondern darauf, was Ihre Benutzer tun
damit ist es wichtig

Prost und fröhliche Kontinuität!
ᐧ

Am Do, 6. Juni 2019 um 10:55 Uhr schrieb jadon1979 [email protected] :

Ziel des Compose-Formats ist es, das Schreiben einer Anwendung zu vereinfachen
und testen Sie es lokal und stellen Sie es dann in einer orchestrierten Umgebung mit bereit
kleine oder keine Änderungen.

In komplexen Apps haben wir möglicherweise einige Konfigurationsdateien, die benötigt werden
on-the-fly optimieren. Im Moment die effizienteste (zeitlich und kostenmäßig) Art und Weise
Wenn Sie dies tun, füllen Sie den Lautstärkeschlüssel aus (weil keine vernünftige Person geht
um ein anderes Image zu erstellen, während mehrere Konfigurationen getestet werden
Sie haben einen Chef, der es einfach liebt, Geld für Entwicklungsstunden auszugeben.

Swarm und Config werden einige der Anwendungsfälle nicht wirklich beantworten
aufgeführt. "Trennung von Bedenken" gilt auch nicht als bereits verfasst
tut, was Sie in Docker tun können, vereinfacht es aber. Ein Wrapper ist nicht
Trennung ... wir bitten Sie nur, es ein bisschen mehr zu erweitern ...

6643 https://github.com/docker/compose/issues/6643

Holen Sie sich hacky damit .. erweitern Sie die Volume-Funktionalität, wo jede Datei unter dem
Der neue Schlüssel wird dynamisch mit einem einzelnen Volume verknüpft und dessen zugeordnet
entsprechende interne Pfade ...

- -
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/5523?
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ABBR3OMOZFZ47L6ITHPF2TDPZEQP7ANCNFSM4EKAVONA
.

Ich möchte eine Docker-Tomcat-Umgebung starten, um meine App aus einer .war-Datei auszuführen, die nicht ROOT.war . Dazu muss ich es in Tomcats Verzeichnis webapps kopieren und in ROOT umbenennen, damit es auf den aktuell gebundenen Ports 8005/9 ausgeführt wird. Alles andere schlägt fehl, weil Probleme an den Ports mit Fehlern bezüglich "illegaler Zugriff" erneut gebunden wurden. Dies sind kurzlebige Test-Builds, sodass sie nicht in die Docker-Datei aufgenommen werden können. Deshalb möchte ich es in docker-compose

@washtubs

Ich weiß, dass ich nicht für alle spreche, aber ich habe den Eindruck, dass die Unterstützung von Konfigurationen die überwiegende Mehrheit des Interesses hier befriedigt. Soll dafür eine Ausgabe eröffnet werden?

Wenn es dafür noch kein Problem gibt, erstellen Sie bitte eines und verlinken Sie es hier. Ich habe etwas in unserem privaten Team-Tracker hinzugefügt.

@washtubs @funkyfuture

... Ich lese, dass dies in Docker-Compose (ohne Schwarm) implementiert werden kann.

Wir haben bereits rudimentäre geheime Unterstützung und Konfigurationen könnten auf ähnliche Weise implementiert werden.

Auf jeden Fall eine fehlende Funktion. Das einzige "Antipattern" ist, wenn Sie die Tatsache umgehen müssen, dass dies auf andere Weise schwierig ist, z. B. indem Sie das Einstiegspunktskript der Docker-Datei ändern oder Mount-Dateien in den Container binden.

Was Sie wollen, ist ein Container, der einmal (vorzugsweise offiziell) erstellt und für den Anwendungsfall am Verwendungsort konfiguriert werden kann, dh Docker-Compose.

Soweit ich sehen kann, erkennen die Docker-Leute nicht, dass das "Dockerfile" das größte Antimuster im gesamten Docker-Konzept ist, zumal das Ganze absolut unlesbar und nicht wartbar ist. Es bringt mich wirklich zum Lachen, wenn jemand, der mit Docker in Verbindung steht, das Wort "Antipattern" ausstößt, wie er es wissen würde!

Die Docker-Datei verhindert tatsächlich das normale Debuggen und Aufräumen, das verfügbar wäre, wenn Sie ein Build-Skript oder etwas verwenden würden, das tatsächlich zum Erstellen von Dingen entwickelt wurde, wie ... einen Paketmanager oder make.

Für mich selbst verwende ich das gleiche DockerFile für alle Anwendungsfälle (was es zu einem Muster macht!), Was darauf hindeutet, dass ich mein DockerFile für jede andere Verwendung ändere, was wirklich gegen Muster ist.

Und keine "Konfigurationsunterstützung" schneidet es überhaupt nicht ab und legt eine Struktur auf, wo sie einfach nicht benötigt wird.

Das grundlegende Problem ist, dass, wenn Sie mount an / etc / nginx binden, es rw sein muss, damit Skripte ausgeführt werden können, die die Konfigurationen anpassen (auch bekannt als envsubst). Dadurch werden Änderungen an der Eingabekonfiguration vorgenommen (die unveränderlich bleiben muss). Sie erhalten nicht viel mehr Antimuster als ein Container, der über die gesamte Konfiguration schreibt. Daher ist eine Option zum Kopieren von Dateien in den Container zum Zeitpunkt der Neuerstellung erforderlich Lösung.

Mit anderen Worten, es ist ein Bind-Mount-Verzeichnis rw im Container, aber ro auf dem Host. Ernsthaft würde es dich töten, das zuzulassen?

Auf jeden Fall eine fehlende Funktion. Das einzige "Antipattern" ist, wenn Sie die Tatsache umgehen müssen, dass dies auf andere Weise schwierig ist, z. B. indem Sie das Einstiegspunktskript der Docker-Datei ändern oder Mount-Dateien in den Container binden.

Was Sie wollen, ist ein Container, der einmal (vorzugsweise offiziell) erstellt und für den Anwendungsfall am Verwendungsort konfiguriert werden kann, dh Docker-Compose.

Soweit ich sehen kann, erkennen die Docker-Leute nicht, dass das "Dockerfile" das größte Antimuster im gesamten Docker-Konzept ist, zumal das Ganze absolut unlesbar und nicht wartbar ist. Es bringt mich wirklich zum Lachen, wenn jemand, der mit Docker in Verbindung steht, das Wort "Antipattern" ausstößt, wie er es wissen würde!

Die Docker-Datei verhindert tatsächlich das normale Debuggen und Aufräumen, das verfügbar wäre, wenn Sie ein Build-Skript oder etwas verwenden würden, das tatsächlich zum Erstellen von Dingen entwickelt wurde, wie ... einen Paketmanager oder make.

Für mich selbst verwende ich das gleiche DockerFile für alle Anwendungsfälle (was es zu einem Muster macht!), Was darauf hindeutet, dass ich mein DockerFile für jede andere Verwendung ändere, was wirklich gegen Muster ist.

Und keine "Konfigurationsunterstützung" schneidet es überhaupt nicht ab und legt eine Struktur auf, wo sie einfach nicht benötigt wird.

Das grundlegende Problem ist, dass, wenn Sie mount an / etc / nginx binden, es rw sein muss, damit Skripte ausgeführt werden können, die die Konfigurationen anpassen (auch bekannt als envsubst). Dadurch werden Änderungen an der Eingabekonfiguration vorgenommen (die unveränderlich bleiben muss). Sie erhalten nicht viel mehr Antimuster als ein Container, der über die gesamte Konfiguration schreibt. Daher ist eine Option zum Kopieren von Dateien in den Container zum Zeitpunkt der Neuerstellung erforderlich Lösung.

Mit anderen Worten, es ist ein Bind-Mount-Verzeichnis rw im Container, aber ro auf dem Host. Ernsthaft würde es dich töten, das zuzulassen?

Etwas wie das:

`` `

Wenn Datei, dann überschreiben

Wenn Verzeichnis, dann überschreibe / füge den Inhalt des Ziels hinzu

mit Inhalten aus der Quelle, um die ursprüngliche Zielstruktur beizubehalten

Quelle: Datei : Berechtigung: Eigentümer : Gruppe

svc:
Kopieren:
- './source/filename:/path/ filename : ro : www-data'
- './source/dir:/path/ dir: ro : www-data'

# oder
svc:
Kopieren:
- Quelle: './source/file'
Ziel: '/ Ziel'
Erlaubnis: ro
Besitzer: Besitzer
Gruppe: Gruppe
- Quelle: './source/directory'
Ziel: '/ Ziel'
Erlaubnis: ro
Besitzer: Besitzer
Gruppe: Gruppe```

Anwendungsfall: Wir haben eine unorchestrierte Containerlösung, in der die Docker-Compose-Dateien unserer Anwendung enthalten sind. SSL-Zertifikate usw. in einem Git-Repository und ziehen es auf eine VM. Dann starten wir den Dienst und möchten zB die SSL-Zertifikate, Konfigurationsdateien usw. auf das Volume des Containers verschieben. Dies ist derzeit ohne eine zugehörige Docker-Datei mit einem COPY-Befehl nicht möglich. Wir wollen nicht mit den Dateien im geklonten Git-Repo herumspielen. Wenn die Anwendung die Dateien ändern würde, müssten wir das Repo jedes Mal bereinigen.

@MartinMajewski dann können Sie Verzeichnis mit Zertifikaten als Volume mounten und es in Ihrer Anwendungskonfiguration verweisen.

Anwendungsfall (und Frage zur sofortigen Beantwortung):
Ich habe ein postgres Bild mit einer einzigen Umgebungsvariablen, die zu Beginn festgelegt werden soll: POSTGRES_PASSWORD . Ich möchte es über Docker Secret einstellen. Was ich tun muss, ist einfach mein eigenes entrypoint.sh , das das angehängte Secret in die Umgebung des laufenden Containers exportiert. Ich muss diesen Einstiegspunkt beim Start irgendwie in meinen Container einfügen. Ohne zweizeiliges Dockerbuild kann ich nicht. Das Kopieren einer einzelnen Datei ist nicht möglich.

PS postgres ist ein Beispiel. Angenommen, es werden keine _FILE env-Variablen unterstützt.

Internes Tracking-Problem https://docker.atlassian.net/browse/COMPOSE-89

Anwendungsfall: Karaf
Mit einem Karaf-Basis-Image, das ich nicht jedes Mal neu erstellen möchte, wenn ich mein Projekt erstelle, möchte ich meine App schnell bereitstellen und den Container für jeden Build neu erstellen können. Ich muss jedoch beim Starten des Containers eine _features.xml_ und eine _jar_ in das Bereitstellungsverzeichnis kopieren.

Meine bisherige Lösung bestand darin, das Karaf-Image als Basis-Image in einem weiteren Dockerfile (basierend auf Overlays - dem schließlich die Überlagerungen ausgehen und das manuelle Löschen des Bildes erzwingen) und dem Avast / Gradle-Docker-Compose-Plugin zu verwenden. Während die init-Befehle sicherlich als Umgebungsvariable übergeben werden können, kann der Inhalt der Datei features.xml dies nicht. Es muss als Datei an einem bestimmten Ort im Container gespeichert werden. Im Moment kann ich dazu nur einen Volume Bind Mount verwenden. Wie bekomme ich auf einem Remote-Computer Inhalte in dieses Volume? Ich benötige noch mehr Logik in meinem Build-Skript (z. B. org.hidetake.groovy.ssh, wodurch das Build-Skript auch mit einer geheimen Kennwort- / Schlüssellogik kompliziert wird). Wenn ein Docker-Compose-CP verfügbar wäre, könnte ich einfach den erforderlichen Kopierbefehl zur Docker-Compose.yml hinzufügen. Das avast / gradle-docker-compose-Plugin übernimmt das Erstellen des Containers und das Kopieren der Dateien aus meiner Build-Ausgabe direkt in den Container ohne zusätzliche Remote-Dateisystem-Zugriffslogik.

Diese Docker-Datei wird meinem Build-Teil docker-compose.yml des Skripts hinzugefügt. Wenn überhaupt, ist dies ein Antimuster, da es dem Upstream-Docker-Image bei jedem Build nur Überlagerungen hinzufügt (bis ich gezwungen bin, das Image manuell zu löschen - was Builds viel langsamer macht).

FROM myregistry:443/docker/image/karaf-el7:latest

COPY karafinitcommands /usr/local/karaf/etc/

COPY features.xml \
     *.jar \
     /usr/local/karaf/deploy/

Ich finde es frustrierend, dass Docker-CP für das Kopieren zur Laufzeit gut funktioniert, aber Docker-Compose hat keinen äquivalenten Mechanismus.

Ich dachte, die Idee ist, ein lokales Verzeichnis an / usr / local / karaf / deploy zu binden und Ihre Dateien dort abzulegen. Ich würde nicht erwarten, dass ich das Image neu erstellen oder eine Docker-Datei verwenden muss, um dies zu erreichen.

Ich dachte, die Idee ist, ein lokales Verzeichnis an / usr / local / karaf / deploy zu binden und Ihre Dateien dort abzulegen. Ich würde nicht erwarten, dass ich das Image neu erstellen oder eine Docker-Datei verwenden muss, um dies zu erreichen.

Auf diese Weise ist es sicherlich erreichbar. Lesen Sie erneut und beachten Sie, dass dies nur ein praktisches Problem ist: Der Container wird durch Gradle Build neu erstellt. Der nächste logische Schritt lautet: Wie verschiebe ich die neuen Build-Dateien in das "lokale Verzeichnis", das unter / usr / local / karaf / deploy bereitgestellt wird? In meinem Fall ist ein "lokales Verzeichnis" genauer ein "Host-Verzeichnis", in dem der Host ein Remote-Host ist. Ich muss also rsync oder etwas anderes zu meinem Build-Skript hinzufügen, um Dateien dort abzurufen und sicherzustellen, dass alte ersetzt und zusätzliche entfernt werden. Es wäre unnötig, wenn Docker-Compose-CP verfügbar wäre. Ich könnte meinen vorhandenen Docker-Client für die Docker-Daemon-Verbindung verwenden, die ich über die Portweiterleitung eingerichtet habe.

Docker-Volumes können mit jedem Build entfernt werden. Bind-Mount-Volumes können nicht. Sie werden nur wieder aufgefüllt , wenn sie leer sind (Persistenzschutzmechanismus). Natürlich erfordert das Leeren eines Bind-Mount auf einem Remote-Computer bestimmte Berechtigungen und Zugriffslogiken, die mit einem Docker-Compose-CP vermieden werden könnten.

Auch hier kann mit Docker CP eine Kopie in eine Laufzeitumgebung erstellt werden. Das ist der frustrierende Teil.

Ah, ok, ich bin zu sehr an mein eigenes Setup gewöhnt. Ich verwende http://github.com/keithy/groan, ein Bash-Skript, das die Teile selbst auf Remote-Servern bereitstellt. Dann rufen wir Docker auf.

Anwendungsfall: Google Cloud Build und Erstellen von Artefakten

Erforderliches Artefakt: Web-Client (automatisch generiert) reagiert auf Graphql-Bindungen. Der Server muss ausgeführt werden, um die für die Clientkompilierung erforderlichen Dateien zu erstellen. Das Client-Image verfügt über die Tools zum Erstellen der Bindungen unter Angabe einer Serveradresse. Sie starten also das Server-Image im Hintergrund und müssen nun den Client-Container ausführen, der auf den Server zeigt. Wie werden nun die generierten Dateien aus dem Container in das Hostverzeichnis "Arbeitsbereich" verschoben? Das Mounten von Verzeichnissen ist nicht zulässig, da Sie sich bereits in einem gemounteten Verzeichnis in einem Docker-Container befinden. In der Lage zu sein, docker-compose cp würde den besonders schmerzhaften Schritt des Abrufs der Container-ID erleichtern.

Wenn Sie sich auf $(docker-compose ps -q SERVICE) , um den richtigen Container zu finden, können Sie für solche containerzentrierten Vorgänge die einfache Docker-CLI verwenden. Die Einführung eines neuen Befehls würde es für die wenigen Anwendungsfälle, die danach fragen, sicherlich einfacher machen, ist jedoch nicht erforderlich. Ich denke, dieses Problem sollte geschlossen werden, um mehr Codeduplizierungen zwischen Compose und Docker-CLI zu vermeiden.

Es gibt ein offenes Problem, bei dem der Build-Cache zwischen Compose und Plain Docker aufgrund der verwendeten Version des Docker-Daemons Compose unterschiedlich ist. Dies bedeutet, dass Sie Pure Compose verwenden müssen, um Caches in CI-Umgebungen nicht zu beschädigen (https: // github) .com / docker / compose / Issues / 883). Bis diese Probleme behoben sind, werden durch das Mischen von einfachen Docker-Befehlen mit Compose-Befehlen Caches unterbrochen. Die Compose-Konfiguration gibt alle Arten von Backed-In-Konfigurationen an, sodass die doppelte Konfiguration nicht mehr manuell mit einfachen docker -Befehlen angegeben werden muss.

Wenn Sie sich auf $(docker-compose ps -q SERVICE) , um den richtigen Container zu finden, können Sie für solche containerzentrierten Vorgänge die einfache Docker-CLI verwenden. Die Einführung eines neuen Befehls würde es für die wenigen Anwendungsfälle, die danach fragen, sicherlich einfacher machen, ist jedoch nicht erforderlich. Ich denke, dieses Problem sollte geschlossen werden, um mehr Codeduplizierungen zwischen Compose und Docker-CLI zu vermeiden.

Dies geht viel tiefer als "Nur wenige Anwendungsfälle erwähnt", da diese Szenarien ziemlich häufig sind und das Ändern, Erstellen eines Images, erneutes Ändern, Erstellen eines Images usw. eine Zeitsenke ist, die in der Lage ist, diese Dinge durch Docker-Compose zu handhaben. Das Argument "Sie können es in der Docker-Cli tun, also tun Sie es einfach dort" macht zahlreiche andere Dinge, die Docker-Compose hinzugefügt wurden, ziemlich zunichte.

Diese eine Ausgabe ist seit fast einem Jahr geöffnet und es gibt zahlreiche andere Diskussionen darüber außerhalb dieser Ausgabe. Es sollte definitiv nicht geschlossen werden, es sei denn, es ist tatsächlich gelöst.

@dionjwa # 883 muss wirklich untersucht werden (falls noch relevant), da Docker-Compose mit Docker-CLI ausgerichtet werden sollte.

@ jadon1979 Ich versuche nicht, diese Funktionsanforderung zu blockieren. Ich habe gerade festgestellt, dass sie vor mehr als einem Jahr geöffnet wurde, und keiner der Hauptbetreuer hielt es für wichtig genug, einen neuen Befehl einzuführen, und ein Mitwirkender schlug auch keine PR für vor es.
Ich sage nur, dass laut dem Feedback zu dieser Funktionsanforderung und dem mangelnden Entwicklungsaufwand, einen "besseren Weg" anzubieten, die vorgeschlagene Problemumgehung eine Kombination aus Docker-Compose und Docker-CLI verwendet, in der Sie leicht einen Alias ​​erstellen können Ihre Umgebung, um die Verwendung einfach zu halten, ist eine vernünftige Problemumgehung.
Wenn jemand eine PR öffnet, um einen neuen Befehl cp anzubieten, würde ich ihn gerne überprüfen.

Niemand hat dazu beigetragen, weil jedem gesagt wurde, dass jeder Anwendungsfall ein Fall ist
Anti-Muster. Und alle paar Tage haben wir neue Anwendungsfälle veröffentlicht, keine
Anti-Muster.

Am Montag, den 18. November 2019 um 17:31 Uhr Nicolas De loof [email protected]
schrieb:

@dionjwa https://github.com/dionjwa # 883
https://github.com/docker/compose/issues/883 muss es wirklich sein
untersucht (falls noch relevant), da Docker-Compose ausgerichtet werden sollte
Docker-CLI.

@ jadon1979 https://github.com/jadon1979 Ich versuche nicht, dies zu blockieren
Feature-Anfrage, gerade bemerkt, dass es vor mehr als 1 Jahr geöffnet wurde, und
Keiner der Hauptbetreuer hielt dies für wichtig genug
einen neuen Befehl einführen, noch hat ein Mitwirkender eine PR dafür vorgeschlagen.
Ich sage nur, dass laut dem Feedback zu dieser Feature-Anfrage
und mangelnde Entwicklungsanstrengungen, um einen "besseren Weg" anzubieten, schlug der vorgeschlagene vor
Problemumgehung, um eine Kombination aus Docker-Compose und Docker-CLI zu verwenden, die Sie verwenden
kann leicht Alias ​​in Ihrer Umgebung, um es einfach zu bedienen zu halten, ist ein
angemessene Problemumgehung.
Wenn jemand eine PR öffnet, um einen neuen CP-Befehl anzubieten, würde ich mich freuen
Überprüfen Sie es.

- -
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/5523?email_source=notifications&email_token=AAGRIF2NS64IYANNVTGFTULQUL3TZA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG43Vn
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAGRIFY7CULCUS3TDDTTHZLQUL3TZANCNFSM4EKAVONA
.

Mein Anwendungsfall kopiert nicht Dinge in einen Container, sondern kopiert sie aus dem Container, nachdem er ausgeführt wurde. Dies kann über die CLI mithilfe einer umständlichen Problemumgehung erfolgen, die möglicherweise zu

Ich bin ein DevOps-Ingenieur und verlasse mich stark auf Container als Alternative zur Abhängigkeitshölle der Bare-Metal-Build-Agenten. Wenn mein CI-System ein Repo testet, beginnt es damit, aus einer Docker-Datei innerhalb desselben Repos zu erstellen und alle Überprüfungen ( bundle exec rspec , npm test usw.) innerhalb des Containers auszuführen. Wenn Build-Artefakte wie Dokumentation oder Testergebnisse erstellt wurden, kopiere ich sie einfach mit docker cp aus dem Container.

Für Integrationstests haben wir begonnen, docker-compose zu verwenden, um dem Container, in dem die Tests ausgeführt werden, Dienstabhängigkeiten (z. B. einen Datenbankserver) bereitzustellen. Leider ist die "Docker-CLI-Problemumgehung" in diesem Fall zum Kopieren von Dateien weniger nützlich.

Betrachten Sie diese Konfiguration: docker-compose-minimal.yml

version: "3"
services:
  artifact-generator:
    image: busybox

Ich werde den Container erstellen, einen Befehl in diesem Container ausführen, die Container-ID abrufen und versuchen, die Datei mit docker cp zu extrahieren

$ # Prepare the images and (stopped) containers.  In this case there is only one.
$ docker-compose --file docker-compose-minimal.yml up --no-start
Creating network "docker-compose-cp-test_default" with the default driver
Creating docker-compose-cp-test_artifact-generator_1 ... done
$ # Determine the ID of the container we will want to extract the file from
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # Generate the artifact in the container
$ docker-compose --file docker-compose-minimal.yml run artifact-generator touch hello.txt
$ # Check that container ID again, just to be sure
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # OK, that looks like the only answer we're going to get.  Can we use that to copy files?
$ docker cp $(docker-compose --file docker-compose-minimal.yml ps -q artifact-generator):hello.txt ./hello-artifact.txt
Error: No such container:path: 050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88:hello.txt
$ # Nope.  Let's take a look at why this is
$ docker container ls -a
CONTAINER ID        IMAGE                        COMMAND                   CREATED              STATUS                          PORTS               NAMES
9e2cb5d38ba0        busybox                      "touch hello.txt"         About a minute ago   Exited (0) About a minute ago                       docker-compose-cp-test_artifact-generator_run_dd548ee686eb
050753da4b0a        busybox                      "sh"                      2 minutes ago        Created                                             docker-compose-cp-test_artifact-generator_1

Wie Sie sehen können, kennt docker-compose ps die aktualisierte Container-ID wirklich nicht. Das ist unglücklich. Das wäre nicht so schlimm, wenn ich wissen könnte, dass run_dd548ee686eb irgendwie mit den docker-compose run ich ausgeführt habe, aber ich sehe keine Möglichkeit, dies zu erreichen.

Es gibt eine umständliche Problemumgehung für diese Problemumgehung, --name der dem Befehl run

$ docker-compose --file docker-compose-minimal.yml run --name blarg artifact-generator touch hello.txt
$ docker cp blarg:hello.txt ./hello-artifact.txt
$ ls 
docker-compose-minimal.yml  hello-artifact.txt

Erfolg! ...irgendwie

Das Problem hierbei ist, dass ich mir die Mühe machen muss, die --name s global einzigartig zu machen, wenn mehrere Builds gleichzeitig ausgeführt werden. Andernfalls bekomme ich im besten Fall verrauschte Kollisionen und im schlimmsten Fall beschädigte Ergebnisse (kein Fehler, aber falsche Datei extrahiert). Das ist also umständlich, weil ich jetzt die Generierung von Container-IDs neu erfinden muss, anstatt nur die zu verwenden, die Docker bereits erstellt hat.

Zumindest möchte ich die ID des Containers kennen, der sich aus dem Befehl docker-compose run ergibt.

@ndeloof

Wenn Sie sich auf $ (Docker-Compose ps -q SERVICE) verlassen, um den richtigen Container zu finden, können Sie einfache Docker-CLI für solche containerzentrierten Vorgänge verwenden.

Falsch, siehe Demonstration im vorherigen Kommentar.

Wir werden hier jahrelang neue Anwendungsfälle haben. Warten Sie, ich meine neue Anti
Muster...

Am Freitag, den 13. Dezember 2019 um 11:40 Uhr schrieb Ian, [email protected] :

@ndeloof https://github.com/ndeloof

Verlassen Sie sich auf $ (Docker-Compose ps -q SERVICE), um den richtigen Container zu finden
machen es möglich, Plain Docker Cli für solche Container-zentriert zu verwenden
Operationen.

Falsch, siehe Demonstration im vorherigen Kommentar.

- -
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/5523?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAGRIF3S4UHF5NG3VKYXJB3QYONHLANCNFSM4EKAVONA
.

Wen können wir erwähnen, um zu den Betreuern zu gelangen? Dieses Problem ist sinnlos, bis sie anfangen, mit uns zu sprechen. Es könnte einfach sein, "es kann aufgrund der aktuellen Softwarearchitektur nicht durchgeführt werden", was auch immer. Aber solche Probleme inert zu lassen, ist nichts, was Sie von dieser sehr beliebten Lösung wie Docker sehen möchten ...

Unsere Bereitstellung erstellt das Docker-Image mit bazel, lädt es in unsere Docker-Registrierung hoch und verwendet dann Terraform docker_container -Ressourcen mit upload -Strophen, um Konfigurationsdateien in den Container zu kopieren. Ich muss diesen Bereitstellungsprozess migrieren, um Docker-Compose anstelle von Terraform zu verwenden. Ich bin überrascht, dass Docker-Compose keine Funktion für die Konfiguration pro Container bietet.

Diese Ausgabe ist seit 2 Jahren offen. Ist das der Grund, warum Kubernetes Docker an Popularität übertrifft? Kubernetes bietet Konfigurations- und Geheimfunktionen. Docker Team, bitte fügen Sie mindestens Konfigurationsfunktionen hinzu.

tbf docker-compose ist nicht genau mit k8s vergleichbar und wird nicht für den produktionsgebrauch empfohlen. Es ist für die Entwicklung und schnelle Tests gedacht. Docker-Schwarm ist die Sache, die man mit K8s vergleichen kann, und obwohl er auch sehr simpel ist, hat er Funktionen wie Konfigurationen und Geheimnisse.

Wenn es nur für die Entwicklung gedacht ist, dann ist das noch mehr Grund für dieses Problem
sollte arbeiten. Die beschissenen "Anti-Pattern" -Regeln sollten das nicht einmal sein
wichtig (ich sage beschissen, weil es durch die Fülle des normalen Gebrauchs klar ist
Fälle, in denen es sich nicht um ein Anti-Muster handelt).

Am Di, 3. März 2020 um 12:56 Uhr David Milum [email protected]
schrieb:

tbf docker-compose ist nicht genau mit k8s vergleichbar und wird nicht empfohlen
für den produktiven Gebrauch. Es ist für die Entwicklung und schnelle Tests gedacht. Docker
Schwarm ist die Sache mit k8s zu vergleichen und obwohl es auch sehr ist
vereinfacht, es hat Funktionen wie Konfigurationen und Geheimnisse.

- -
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/5523?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAGRIF4NTQQSR2QQWPJT6PLRFUSEJANCNFSM4EKAVONA
.

Ein weiteres "Anti-Muster":

Ich verwende docker-compose für die Container-Orchestrierung während der lokalen Entwicklung und k8s für die Produktion.

Gemäß Dockers eigenem Rat habe ich das Skript wait-for-it.sh implementiert, um die Reihenfolge des Starts / Herunterfahrens des Dienstes zu verwalten.

Derzeit ist eine Kopie des Skripts im Dockerfile-haltigen Verzeichnis jedes Dienstes erforderlich, es sei denn, ich möchte in jedem Dienst nur für diese eine Datei ein Volume bereitstellen.

Stattdessen möchte ich eine einzelne Kopie des Skripts wait-for-it in einem Verzeichnis der obersten Ebene verwalten, das docker-compose dann bei lokaler Ausführung in jeden Container kopiert, da solche Bedenken ansonsten in k8s verwaltet werden. Das heißt, ich möchte nicht, dass diese Bedenken die Dockerfile meiner Dienste verschmutzen.

Wie Emerson einmal schrieb: "Eine dumme Konsequenz ist der Hobgoblin kleiner Geister, der von kleinen Staatsmännern, Philosophen und Göttern verehrt wird."

Vielleicht ist es Zeit, Ihren Benutzern zuzuhören ...

@Phylodome Kannst du keine Container- docker-compose depends_on ? So stelle ich gesunde Startabhängigkeiten für Container sicher.

Mein Verständnis ist, dass wait-for-it.sh wirklich ein Hack ist, da Ihre Dienste selbst gegenüber kommenden und gehenden Abhängigkeiten widerstandsfähig sein sollten. Startup ist nur ein Einzelfall davon.

@ianfixes Soll sich "Ihre Dienste" auf die Docker-Compose-Dienste selbst oder auf "unsere" Dienste beziehen, wie in den Diensten, die von uns geschrieben wurden, die Docker-Compose verwenden? Ich weiß nicht, ob Sie in der Rolle eines "Benutzers" oder eines Docker-Compose-Entwicklers schreiben.

Soll sich "Ihre Dienste" auf die Docker-Compose-Dienste selbst oder auf "unsere" Dienste beziehen, wie in den Diensten, die von uns geschrieben wurden, die Docker-Compose verwenden?

Die Dienste, die Sie als Entwickler erstellen, sollten stabil sein. Dies entspricht den folgenden Dokumenten: https://docs.docker.com/compose/startup-order/

Das Problem, darauf zu warten, dass eine Datenbank (zum Beispiel) bereit ist, ist eigentlich nur eine Teilmenge eines viel größeren Problems verteilter Systeme. In der Produktion kann Ihre Datenbank jederzeit nicht mehr verfügbar sein oder Hosts verschieben. Ihre Anwendung muss für diese Art von Fehlern stabil sein.

Entwerfen Sie dazu Ihre Anwendung so, dass nach einem Fehler versucht wird, eine Verbindung zur Datenbank wiederherzustellen. Wenn die Anwendung die Verbindung erneut versucht, kann sie möglicherweise eine Verbindung zur Datenbank herstellen.

Die beste Lösung besteht darin, diese Prüfung in Ihrem Anwendungscode sowohl beim Start als auch bei Verbindungsverlust aus irgendeinem Grund durchzuführen. Wenn Sie diese Ausfallsicherheit jedoch nicht benötigen, können Sie das Problem mit einem Wrapper-Skript umgehen:

Außerdem werden verschiedene Warteskripte erwähnt.

Ich könnte eine Reihe von Dingen tun. Aber weil dies nur für die lokale Entwicklung ist und ich andere Strategien für die Abwicklung von Produktionsdienstprüfungen in k8s habe, würde ich die einfachste und am wenigsten aufdringliche lokale Implementierung vorziehen , nicht generische Ratschläge von Leuten, die nicht genau wissen, warum ich Ich möchte dies tun (z. B. Probleme mit der Volume-Montage, um UI-Dev über den Dev-Server von Webpack auszuführen).

In jedem Fall ist es nur ein weiterer Teil der langen Liste von Anwendungsfällen für diese potenzielle Funktion, die im Ermessen des Benutzers liegen sollte.

Ich höre Wut auf mich gerichtet und verstehe, warum es frustrierend wäre, unaufgeforderte "Ratschläge" für Ihren Ansatz zu hören. Aber ich bin mir nicht mal sicher, wie ich mich entschuldigen soll. Ich zitierte den Text aus der URL, die Sie selbst als "Docker's eigener Rat" bezeichnet haben und die explizit besagt, dass das Warteskript eine Möglichkeit ist, "das Problem zu umgehen". Für das, was es wert ist, tut es mir trotzdem leid.

Du hörst keine Wut. Sie hören den verärgerten Ton von jemandem, der beim Googeln nach einem ziemlich offensichtlichen Merkmal auf einen Thread mit hundert Kommentaren gestoßen ist, in dem eine Reihe von Betreuern die Bitten der Community um ein vollständig gültiges Merkmal kontinuierlich bevormundete und ablehnte.

Ich habe meine Erfahrungen hier nicht geteilt, weil ich mich entschuldigen wollte. Ich habe es einfach geteilt, um der langen Liste der Beweise hinzuzufügen, dass Docker-Benutzer zusätzliche Flexibilität bei der Verwendung von compose .

Natürlich geht diese Flexibilität wie bei jedem Tool mit dem Missbrauchspotenzial einher. Das gleiche Potenzial, wenn nicht sogar das schlechtere Potenzial, besteht jedoch, wenn Ihre Benutzer Problemumgehungen für ihre spezifischen Anwendungsfälle finden müssen, die durch einfaches Hinzufügen dieser Funktion weitaus einfacher gelöst werden können.

Darüber hinaus ist es ein schlechtes Aussehen, Ihre Benutzer entschuldigend mit Gas zu beleuchten.

Ich bin weder Betreuer noch Mitwirkender dieses Projekts und entschuldige mich für etwaige Verwirrung. Es hört sich so an, als wäre die kleine Hilfe, die ich anbieten könnte, unerwünscht und nicht hilfreich, und es tut mir leid, dass ich Ihre Zeit verschwendet habe.

Ich möchte diese Funktion für einen Go-Container, der Teil meiner verteilten Anwendung ist. Da die .env -Datei im Stammverzeichnis der Go-Anwendung enthalten sein muss, muss ich ein separates .env dafür erstellen ... Wenn ich diese Funktion hätte, könnte ich das Habe meine .env -Datei der obersten Ebene und kopiere sie beim Erstellen in den Go-Container. Es würde weniger Dinge bedeuten, die ich im Auge behalten muss ...

Meine Problemumgehung könnte darin bestehen, diese Datei über die Dockerfile des Go-Containers zu erstellen oder einfach eine .env -Datei für diesen Container zu erstellen. Aber immer noch, wenn ich eine neue env var hinzufüge, muss ich sie möglicherweise an zwei Stellen aktualisieren. Guter Anwendungsfall hier. Oder ich könnte einfach ein Shell-Skript verwenden, um cp die Datei für mich zu erstellen ...

+1 für die Funktion KOPIEREN

Dies erreichen wir bereits in Kubernetes mit Seitenwagen, und es gibt VIELE Anwendungsfälle. Dies ist KEIN Anti-Pattern, sondern nur eine der Funktionen, die Docker-Compose zurückhalten.

Vielleicht fehlt mir etwas, aber im Moment, wenn wir unsere App für 5 Minuten erstellen, ist der Build-Ordner die ganze Zeit "im Fluss" und die App wird aufgrund von Inkonsistenzen nicht gestartet.
Ich würde es vorziehen, einen Build-Ordner in einen Container zu kopieren. Wenn es also Zeit ist, den Container zu starten, übernimmt er den internen. Auf diese Weise ist die App nur für eine Sekunde oder so offline, wenn der Container gestoppt / gestartet wird.

Wie ist dies ein Anti-Pattern, wenn docker bereits unterstützt? Es wäre sinnvoll, wenn docker-compose als Benutzerfreundlichkeit des Dockers folgt - dies nicht zu tun, ist an sich ein Anti-Pattern.

Das Problem dabei ist, dass es unglaublich kurzsichtig ist (daher der Begriff "Anti-Pattern"), da Sie gezwungen sind, den Vorgang jedes Mal zu wiederholen, wenn die Container neu erstellt werden sollen. Ganz zu schweigen von der Tatsache, dass es sehr schlecht skaliert (was ist, wenn Sie 10 Container haben? 20? 100?)

Ich denke, das liegt beim Entwickler. Das einfache Kopieren einer einzelnen lokalen Konfigurationsdatei hat einen unbedeutenden Aufwand. Gib dem Messer keine Schuld.

PS Mein Anwendungsfall; Ich möchte einem Nginx-Container in einem Projekt ohne Docker-Dateien eine Konfiguration hinzufügen.

Wer weiß noch mehr.
Ich musste ein neues Projekt einrichten und suchte nach neuen
Werkzeuge, Lando ist so viel besser als das, es ist verrückt. Ich wünschte, ich hätte es benutzt
früher.
Es ist schneller, einfacher zu verstehen, besser sofort einsatzbereit und
hat keine herablassenden (ehemaligen) Betreuer / Mitwirkenden.

@ Chris-Crone bezüglich Ihres Kommentars ...

Für Konfigurationsdateien oder Bootstrapping-Daten gibt es Docker-Konfigurationen. Diese funktionieren ähnlich wie Geheimnisse, können aber überall montiert werden. Diese werden von Swarm und Kubernetes unterstützt, jedoch nicht von Docker-Compose. Ich glaube, wir sollten Unterstützung für diese hinzufügen, und dies würde bei einigen der in dieser Ausgabe aufgeführten Anwendungsfälle helfen.

Ist Docker-Compose daran interessiert, Konfigurationsunterstützung für die Parität mit Schwarmkonfigurationen zu implementieren?

Wenn es ein Ticket dafür gibt (oder wenn ich eines machen muss, das auch in Ordnung ist), möchte ich das abonnieren und mich von diesem Müllfeuer abmelden. Persönlich würde ich dies schließen und darauf verlinken, aber das bin nur ich.

@harpratap Sie haben Recht, aber der Nachteil ist, dass / folder_in_container nicht existieren oder leer sein darf, sonst wird es überschrieben. Wenn Sie ein Bash-Skript als Einstiegspunkt haben, können Sie dies umgehen, indem Sie Ihre Dateien nach dem Erstellen eines Volumes unter / some_empty_location mit dem ursprünglich vorgesehenen Verzeichnis verknüpfen

+1 für eine COPY-Funktionalität. Unser Anwendungsfall ist das schnelle Aufstehen lokaler Entwicklungsumgebungen und das Kopieren in Konfigurationen für die Entwicklungseinstellungen.

Genau. Wir skalieren nicht alle gleich. Mein Unternehmen verwendet SALT, um die erforderlichen .conf-Dateien für eine Vielzahl von Apps zu erstellen. Ein Build - mit den Grundlagen - dann Docker-Compose, um die einzelnen Instanzen basierend auf ihren eindeutigen Teilen zu erstellen: MAC-Adresse, IP, Port, Lizenzen, Module usw. Es könnte über eine Befehlszeile erfolgen - aber viel einfacher und weniger Fehleranfällig durch Docker-Compose.

Ich habe einen Anwendungsfall. Wir haben einen Testbuild, für den SSL eingerichtet werden muss. Die Zertifikate werden von einem Dienst im Docker-Compose generiert ... Ich füge diese Zertifikate dann den Client-Containern hinzu ... Wenn ich sie einbinde, verliere ich die vorhandenen Zertifikate und kann sie nicht in den Docker-Build einfügen, weil sie nicht vorhanden sind existiert noch nicht.

Folglich muss ich 2 Docker-Compose ausführen - 1, um die Dienste zu starten, um die Zertifikate zu erstellen, und dann einen anderen, um die Dienste zu erstellen und die Tests auszuführen. Unordentlich.

Ich habe hier viele Probleme gesehen, bei denen Benutzer viele Anwendungsfälle für eine Funktion vorgeschlagen haben, diese jedoch abgeschossen wurden, weil ein Betreuer der Meinung ist, dass es sich um ein Anti-Pattern handelt oder die Leute es oder eine andere Geschichte nicht verwenden würden .

Während es für eine Person wie ein Anti-Muster erscheint, bin ich sicher, dass die 1000 Personen, die nach der Funktion fragen und anders denken, ebenfalls gehört werden müssen. Wenn Hilfe bei der Entwicklung der Funktion benötigt wird, können meiner Meinung nach viele Menschen mithelfen.

Mein Anwendungsfall: Zusätzlich zu den Konfigurationen habe ich einige Bibliotheken (RPMs), die ich in 5 meiner Rails-Anwendungscontainer (Debian) installieren muss. Verschiedene Ruby / Rails-Versionen können daher nicht dasselbe Basis-Image verwenden. Daher sollte ich in der Lage sein, die Dateien an einem einzigen Speicherort zu speichern und sie beim Erstellen in einen Container zu kopieren, da ich keine 1,5 GB Daten herunterladen möchte beim bauen.

@ Gauravmanchanda

Mein Anwendungsfall: Zusätzlich zu den Konfigurationen habe ich einige Bibliotheken (RPMs), die ich in 5 meiner Rails-Anwendungscontainer (Debian) installieren muss. Verschiedene Ruby / Rails-Versionen können daher nicht dasselbe Basis-Image verwenden. Daher sollte ich in der Lage sein, die Dateien an einem einzigen Speicherort zu speichern und sie beim Erstellen in einen Container zu kopieren, da ich keine 1,5 GB Daten herunterladen möchte beim bauen.

Haben Sie sich dafür mehrstufige Builds angesehen ? Ich denke, es wäre eine robustere Lösung.

Mit mehrstufigen Builds können Sie dieselbe Docker-Datei für mehrere Bilder verwenden. Auf diese Weise können Sie sie faktorisieren und nur die Bits einschließen, die Sie in jedem Bild benötigen.

Ein gutes Beispiel dafür ist das, mit dem wir Docker Compose erstellen . Dies wird entweder mit Debian oder Alpine erstellt, ermöglicht es uns jedoch, gemeinsamen Code zu berücksichtigen.

In unserem Setup haben wir ungefähr ein Dutzend Simulatoren mit Docker-Compose hochgefahren. Die Simulatoren sind ansonsten identisch, aber eine Init-Datei ist für jedes Ziel unterschiedlich und diese Datei wird beim Start verbraucht (wird gelöscht, wenn der Server läuft). Schlagen Sie wirklich vor, dass wir ungefähr ein Dutzend fast identische Bilder erstellen sollten, nur weil sich eine Datei unterscheidet? Das macht IMO keinen Sinn.

Mit Docker kann dazu das Flag --copy-service verwendet werden. Gibt es Alternativen, die wir mit Docker-Compose verwenden können?

Hallo @megaeater ,

Wir fahren ungefähr ein Dutzend Simulatoren mit Docker-Compose hoch. Die Simulatoren sind ansonsten identisch, aber eine Init-Datei ist für jedes Ziel unterschiedlich und diese Datei wird beim Start verbraucht (wird gelöscht, wenn der Server läuft).

Dies ist ein interessanter Anwendungsfall. Einige Fragen: Werden diese Simulatoren (oder Teile davon) jemals in der Produktion ausgeführt (dh nicht auf dem Computer des Entwicklers oder einem CI)? Wenn der Code offen ist (oder ein ähnliches System), können Sie mich bitte damit verknüpfen, damit ich einen Blick darauf werfen kann?

Es wäre auch interessant zu wissen, warum Sie eine Kopie anstelle der Bindungsmontage oder ein Volume für diese Dateien wünschen würden.

Schlagen Sie wirklich vor, dass wir ungefähr ein Dutzend fast identische Bilder erstellen sollten, nur weil sich eine Datei unterscheidet? Das macht IMO keinen Sinn.

Aus genau diesem Grund basieren Bilder auf Ebenen: Alle Bilder mit Ausnahme der Ebene, die die verschiedenen Dateien enthält, verweisen auf dieselben Ebenen.

Das Problem bei Dingen wie dem Erstellen einer Kopie beim Erstellen eines Containers besteht darin, dass es schwierig ist, denselben Code zu verwenden und in der Produktion auszuführen (dh, dass ein umfangreiches Umschreiben der Logik erforderlich ist), da das Muster in orchestrierten Umgebungen fragil oder unmöglich ist.

Dies bedeutet nicht, dass wir so etwas niemals in Compose implementieren sollten. Wenn eine Änderung dazu führt, dass Benutzer etwas, das lokal in der Produktion funktioniert, nicht wiederverwenden können, möchten wir lieber innehalten und prüfen, ob es einen robusteren Weg gibt, um dasselbe Ziel zu erreichen.

Vielen Dank für den Kommentar @ chris-crone

Wir betreiben Docker nicht in der Produktion, sondern nur zu Entwicklungszwecken. Das Problem bei der Verwendung von Volume (wenn ich es richtig verstehe) ist, dass der Simulator (Drittanbieter) über dieses Startskript verfügt, das die Datei beim Start löscht. Die Skriptausführung wird gestoppt, wenn das Löschen fehlschlägt. Daher müssten wir sie als rw bereitstellen. Und wenn das Löschen von Dateien zulässig ist, benötigen wir einen Mechanismus zum Erstellen eines temporären Verzeichnisses für die Bereitstellung dieser Dateien, damit die Originale nicht gelöscht werden. Wir müssten also eine Art fremde Skripte haben, um die Komposition auf Docker-Compose zu erhöhen.

@ chris-crone Danke für die Links. Ich werde einen Blick darauf werfen und sehen, ob es bei uns funktioniert 👍

Hey @ chris-crone Ich habe versucht, Multi Stage-Builds zu verwenden, und es hat uns geholfen, die Bibliotheken / Konfiguration nur an einem Ort zu halten und sie zu kopieren, aber jetzt gibt es Probleme damit, dass .dockerignore ignoriert wird, egal wo Ich platziere es.

Es funktioniert, wenn ich Docker nur mit der neuen Option DOCKER_BUILDKIT , aber nicht, wenn Docker-Compose verwendet wird, versucht COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build , aber immer noch nicht funktioniert. Irgendwelche Ideen?

Ich habe mich gefragt, ob es eine Option gibt, um anzugeben, wo nach den .dockerignore beim Verfassen gesucht werden soll, als ich auf dieses Problem gestoßen bin: https://github.com/docker/compose/issues/6022 . wurde geschlossen, weil 1 Mitwirkender denkt, dass dies nicht nützlich ist.

Das ist ziemlich frustrierend, wenn ich hier ehrlich bin !!

Dies ist unter MacOS von entscheidender Bedeutung, da es von größter Bedeutung ist, Ihre Entwicklungszyklen so nah wie möglich an die Produktion zu bringen. offensichtlich für ordnungsgemäße kontinuierliche Lieferpraktiken. Erstellen Sie beispielsweise den Container, und binden Sie dann Ihre neue Version der Software, an der Sie gerade arbeiten, in den Container ein, um Erstellungszykluszeiten zu sparen. Leider sind Bindungshalterungen extrem teuer und drei- bis fünfmal langsamer.

Beispielsweise beträgt die Startzeit von Tomcat für meine App in einem Container etwa 3 Sekunden. Fügen Sie einen Bind-Mount von ~ / .bash_history hinzu und es ist 4s. Fügen Sie einen Bind Mount meiner App hinzu und es ist normalerweise ungefähr 18-20s. Unter Linux entspricht die Leistung von Bind Mount der eines lokalen Dateisystems, jedoch nicht unter MacOS. Skalieren Sie das auf 100 Mal pro Tag und das ist wichtig.

Dies schließt nicht die Langsamkeit ein, die beim ersten Zugriff auf die App anhält. bis die Codedateien zwischengespeichert sind. Für mich bedeutet das 3 Minuten, einschließlich einer Verzögerung über das Internet, bei der eine Verbindung zur monolithischen Orakel-Datenbank hergestellt wird, um eine kleine Phrase in etwas anderes zu ändern und zu prüfen, ob sie noch in Ordnung ist. Verdammt covid-19, lol.

Im Idealfall möchte ich Docker-Compose erneut ausführen und meine App im laufenden Container "aktualisieren" und Tomcat zum erneuten Laden auffordern können. Ich könnte den Tomcat-Manager verwenden, um die Änderung hochzuladen, aber wir haben auch eine Back-End-App, die keinen verwalteten Container verwendet, sodass wir dann eine andere Lösung als diese verwenden müssten.

Es wäre schön, wenn Docker-Compose auch auf die Entwicklung ausgerichtet wäre, nicht nur auf eine Produktionsbereitstellung.

Dieser Anwendungsfall ist für die Diskussion relevant: https://github.com/docker/compose/issues/3593#issuecomment -637634435

@ Chris-Crone

@ Gauravmanchanda

Mein Anwendungsfall: Zusätzlich zu den Konfigurationen habe ich einige Bibliotheken (RPMs), die ich in 5 meiner Rails-Anwendungscontainer (Debian) installieren muss. Verschiedene Ruby / Rails-Versionen können daher nicht dasselbe Basis-Image verwenden. Daher sollte ich in der Lage sein, die Dateien an einem einzigen Speicherort zu speichern und sie beim Erstellen in einen Container zu kopieren, da ich keine 1,5 GB Daten herunterladen möchte beim bauen.

Haben Sie sich dafür mehrstufige Builds angesehen ? Ich denke, es wäre eine robustere Lösung.

Mit mehrstufigen Builds können Sie dieselbe Docker-Datei für mehrere Bilder verwenden. Auf diese Weise können Sie sie faktorisieren und nur die Bits einschließen, die Sie in jedem Bild benötigen.

Ein gutes Beispiel dafür ist das, mit dem wir Docker Compose erstellen . Dies wird entweder mit Debian oder Alpine erstellt, ermöglicht es uns jedoch, gemeinsamen Code zu berücksichtigen.

Mehrstufige Builds sind cool, leiden jedoch unter ihren eigenen Problemen. Zum einen müssen alle Phasen im selben Kontext ausgeführt werden, was nicht immer möglich ist. Soweit ich weiß, können Sie COPY --from nicht einfach mit Bildern verwenden, die in einer anderen Docker-Datei definiert und mit docker-compose build (ich gehe davon aus, dass Sie dies tun können, indem Sie sie manuell erstellen und markieren).

COPY an sich ist sehr begrenzt, da Sie nur aus Ihrem Build-Kontext importieren können. docker cp kann von überall nach überall kopiert werden, außer es kann nicht zwischen Bild und Container kopiert werden (ähnlich wie COPY --from ).

Mein eigener Anwendungsfall ist etwas anders (abgesehen vom Kopieren schreibgeschützter Konfigurationsdateien sind lokale Volume-Mounts nicht die beste Idee, wenn Sie sie auf einem anderen Computer bereitstellen), und ich würde sagen, dass das, was ich gerade mache, ein Antimuster ist ... . Ich habe möglicherweise mehrere verschiedene Images, die beim Erstellen kompilierte und minimierte JS + HTML + Assets-Bundles generieren (denken Sie an kleine eckige Apps), und einen einzelnen Nginx-Server, der alle von ihnen bedient (aufgrund von Plugins aus einem benutzerdefinierten Image erstellt).

Derzeit muss ich die "Bereitstellungs" -Pakete beim Start aus den "Build" -Bildern kopieren. Idealerweise sollte dies entweder beim Erstellen eines Containers oder beim Erstellen erfolgen. Letzteres würde jedoch das Erstellen eines weiteren Bildes über dem "modifizierten Nginx" erfordern.

Stellen Sie sich das folgende Projektlayout vor (Teilprojekte befinden sich möglicherweise in separaten Repositorys und kennen sich nicht):

app1/
  src/
    ...
  Dockerfile
app2/
  src/
    ...
  Dockerfile
app3/
  src/
    ...
  Dockerfile
nginx/
  ...
  Dockerfile
docker-compose.yml

Jede der Dateien app{1,2,3}/Dockerfile enthält ein Ziel / eine Stufe build , mit der die App auf /usr/src/app/dist . nginx/Dockerfile hat nur eine Stufe und erstellt ein Image ähnlich nginx/nginx , jedoch mit allen erforderlichen Plugins (keine Konfigurationen).

docker-compose.yml:

version: '3.8'
services:
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app1 \
        && cp -vr /usr/src/app/dist /dist-volume/app1 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  app2-build:
    build:
      context: app2/
      target: build
    image: app2-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app3 \
        && cp -vr /usr/src/app/dist /dist-volume/app3 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  #... same thing for app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    volumes:
      - 'dist:/var/www'
      - # ... (config files etc)

volumes:
  dist:

Dies ist offensichtlich nicht ideal. Jedes Image zum Erstellen von Apps wird unnötig ausgeführt und schnell beendet. Die bereitgestellten Images befinden sich auf einem freigegebenen Volume (ich gehe davon aus, dass dies negative Auswirkungen auf die Leistung hat, konnte es jedoch noch nicht überprüfen). Wenn ein copy oder copy_from eine Docker-Compose-Option wäre, könnte dasselbe geschrieben werden als:

version: '3.8'
services:
  # assuming the images have default entrypoint and cmd combination that immediately returns with success.
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build

  #... same thing for app2-build app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    copy:
      - from: app1-build  # as image or service, both have their pros and cons, service would mean an image associated with this service
         source: /usr/src/app/dist
         destination: /var/www/app1
      - from: app2-build
         source: /usr/src/app/dist
         destination: /var/www/app2
      - from: app3-build
         source: /usr/src/app/dist
         destination: /var/www/app3
    volumes:
      - # ... (config files etc)

Mein Anwendungsfall befindet sich nicht im Build- oder Startschritt. Ich rufe Dateien ab, die in einem Container oder im gesamten Container eines Dienstes generiert wurden. Diese Container werden auf einer Remote-Docker-Engine ausgeführt. Bisher mache ich so etwas wie docker-compose ps -qa <service> | xargs -i docker cp {}:<there> <here> . Ich wünschte nur, ich könnte mich an Docker-Compose halten, die in meinem Skript eindeutig sind.

@ Chris-Crone

Es wäre auch interessant zu wissen, warum Sie eine Kopie anstelle der Bindungsmontage oder ein Volume für diese Dateien wünschen würden.

Mögen Sie Selbstgeißelung? In diesem Fall empfehle ich, eine Anwendung mit einem Bind Mount unter MacOS auszuführen. 🤣 Einzelheiten finden Sie in meinem vorherigen Beitrag.

Dies bedeutet nicht, dass wir so etwas niemals in Compose implementieren sollten. Wenn eine Änderung dazu führt, dass Benutzer etwas, das lokal in der Produktion funktioniert, nicht wiederverwenden können, möchten wir lieber innehalten und prüfen, ob es einen robusteren Weg gibt, um dasselbe Ziel zu erreichen.

@ chris-crone Ich denke, das ist ein großartiges Gefühl, weil die Leute allzu oft Anti-Patterns für Docker implementieren, z. B. Konfiguration und Daten nicht kurzlebig verwalten.

Ich frage mich, ob wir Docker und Apple irgendwie dazu bringen könnten, gemeinsam Leistungsprobleme mit Bind-Mounts zu beheben. Zumindest für mich würde ich keine Docker-Compose-CP-Option mehr benötigen, da ich Bind-Mounts für die Entwicklung verwenden würde. Im Moment ist es einfach zu schmerzhaft, Bind-Reittiere zu verwenden. Ich kann zu einer virtuellen Maschine mit Linux wechseln, weil mein Mac nur Bytes hat.

@ Megaeater

Wir betreiben Docker nicht in der Produktion, sondern nur zu Entwicklungszwecken. Das Problem bei der Verwendung von Volume (wenn ich es richtig verstehe) ist, dass der Simulator (Drittanbieter) über dieses Startskript verfügt, das die Datei beim Start löscht. Die Skriptausführung wird gestoppt, wenn das Löschen fehlschlägt. Daher müssten wir sie als rw bereitstellen. Und wenn das Löschen von Dateien zulässig ist, benötigen wir einen Mechanismus zum Erstellen eines temporären Verzeichnisses für die Bereitstellung dieser Dateien, damit die Originale nicht gelöscht werden. Wir müssten also eine Art fremde Skripte haben, um die Komposition auf Docker-Compose zu erhöhen.

Hmm .. Wenn Sie sich an den Simulatorhersteller wenden könnten, wäre dies meiner Meinung nach der beste Weg, um dieses Problem zu beheben. Sie könnten dies möglicherweise mit einem Einstiegspunktskript für den Simulator umgehen, der die Dateien nach Bedarf verschiebt. Zugegeben, das wäre chaotisch.

@ Gauravmanchanda

Es hat uns geholfen, die Bibliotheken / Konfiguration nur an einem Ort zu halten und sie zu kopieren, aber jetzt gibt es Probleme damit, dass .dockerignore ignoriert wird, egal wo ich sie platziere.
Es funktioniert, wenn ich Docker nur mit der neuen Option DOCKER_BUILDKIT , aber nicht, wenn Docker-Compose verwendet wird, versucht COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build , aber immer noch nicht funktioniert. Irgendwelche Ideen?

Ich bin froh, dass mehrstufige Builds geholfen haben! Welche Version von Docker und Docker-Compose verwenden Sie? Ich würde es mit dem neuesten versuchen und sehen, ob das Problem noch besteht. Es sollte die .dockerignore-Datei berücksichtigen.

@Marandil , es hört sich so an, als ob docker build Ihre Projektstruktur (dh die Verzeichnisstruktur) nicht behandelt, was das Problem ist. Möglicherweise können Sie docker buildx bake (https://github.com/docker/buildx) verwenden, um diesen Anwendungsfall zu lösen. Beachten Sie, dass an Buildx gearbeitet wird, es ist also noch nicht sehr stabil, aber es zielt darauf ab, einige Ihrer Probleme zu lösen.

@itscaro , danke für deine Eingabe! Was wir intern tun, um Dinge in Containern zu generieren, ist docker build um das Ergebnis aus einem FROM scratch Bild auszugeben. Dies funktioniert nur in Fällen, in denen Sie die Ausgabe eines einzelnen Containers benötigen.

@TrentonAdams Wir haben daran gearbeitet, die Dateisystemleistung für Docker Desktop zu verbessern, aber es ist schwierig. Das zugrunde liegende Problem ist das Überschreiten der VM-Grenze. Die Dateifreigabebits wurden kürzlich neu geschrieben (Sie können die neue Erfahrung aktivieren, indem Sie in den Einstellungen die Option "gRPC-Sicherung für Dateifreigabe verwenden" verwenden). Dies sollte einige der Probleme lösen, die bei der hohen CPU-Auslastung aufgetreten sind. Wir haben hier und hier einige Dokumentationen zur Leistungsoptimierung.

@ Chris-Crone

@Marandil , es hört sich so an, als würde docker build Ihre Projektstruktur (dh die Verzeichnisstruktur) nicht behandeln, was das Problem ist. Möglicherweise können Sie docker buildx bake (https://github.com/docker/buildx) verwenden, um diesen Anwendungsfall zu lösen. Beachten Sie, dass an Buildx gearbeitet wird, es ist also noch nicht sehr stabil, aber es zielt darauf ab, einige Ihrer Probleme zu lösen.

Danke, ich werde docker buildx bake . Es sieht vielversprechend aus, aber ich konnte keine gute Referenz oder Dokumentation dafür finden, und die Seiten auf docs.docker.com sind ziemlich leer (vgl. Https://docs.docker.com/engine/reference/commandline/buildx_bake) /). Bisher habe ich https://twitter.com/tonistiigi/status/1290379204194758657 gefunden, das auf einige Beispiele verweist (https://github.com/tonistiigi/fsutil/blob/master/docker-bake.hcl, https: // github .com / tonistiigi / binfmt / blob / master / docker-bake.hcl), das mag ein guter Ausgangspunkt sein, aber kaum eine gute Referenz.

@TrentonAdams Wir haben daran gearbeitet, die Dateisystemleistung für Docker Desktop zu verbessern, aber es ist schwierig. Das zugrunde liegende Problem ist das Überschreiten der VM-Grenze. Die Dateifreigabebits wurden kürzlich neu geschrieben (Sie können die neue Erfahrung aktivieren, indem Sie in den Einstellungen die Option "gRPC-Sicherung für Dateifreigabe verwenden" verwenden). Dies sollte einige der Probleme lösen, die bei der hohen CPU-Auslastung aufgetreten sind. Wir haben hier und hier einige Dokumentationen zur Leistungsoptimierung.

@ Chris-Crone Hölle ja, vielen Dank! Die neue Option bietet eine Verbesserung von 3 bis 4 Sekunden. Die Verwendung von "zwischengespeichert" bietet die gleiche Leistung wie das Ausführen außerhalb des Containers. Das ist also RIESIG für mich. Ich sehe Zeiten von nur 2800 ms Startzeit für unsere App, das sind also keine 11-18 Sekunden mehr. YAY! Ich brauche nichts anderes als zwischengespeichert, weil ich die Container sowieso jedes Mal neu erstelle.

@ chris-crone Gibt es einen Ort, an dem ich Performance-Artikel veröffentlichen sollte, um bei der Leistungsoptimierung und beim Feedback zu MacOS zu helfen? Ich frage mich, warum ein frisch gestarteter Container mit Bind Mount langsam ist, wenn nicht cached . Es muss eine seltsame Sache geben, bei der jede Datei beim Start hin und her überprüft wird, ob sie synchron ist, selbst wenn sie brandneu ist.

Anwendungsfall: Ich führe einen Container aus und er ändert eine Datei (insbesondere ändert Keycloak seine Konfigurationsdatei basierend auf Umgebungsvariablen usw.). Ich möchte eine Kopie dieser Datei auf meiner lokalen Festplatte, damit ich das Ergebnis dieser Änderung überprüfen und meinen Fortschritt im Laufe der Zeit verfolgen kann, während ich die Containerskripte ändere. Derzeit muss ich jedes Mal die neue Container-ID finden, damit ich docker cp .

Anwendungsfall:
Entwicklung im Docker.
Ich muss meine Sperrdatei zurück auf den Host-Computer übertragen, sonst wird sie überschrieben, wenn der Container den Projektordner bereitstellt.

Anwendungsfall: Ich muss eine Datei kopieren, die einen geheimen Schlüssel enthält. Die im Container ausgeführte App liest diese Datei in den Speicher und löscht sie von der Festplatte.

Anwendungsfall: Ich führe C ++ - Komponententests in einem Docker-Container aus. Ich möchte den Code bei jedem Lauf einfach in ein vorhandenes Image kopieren.

1) Wenn Sie dies mit einer separaten Docker-Datei COPY tun, wird der Code in ein neues, unnötiges Image geschrieben, und ich muss dieses Image löschen, um sicherzustellen, dass beim nächsten Durchlauf ein neues Image mit dem neuesten Code erstellt wird.

2) Wenn Sie dies mit docker-compose volumes yaml config tun, bedeutet dies, dass Docker den Quellcode als root:root chowniert (meine IDE wird vollständig daran gehindert,

@ shin- folge ich einem Anti-Pattern, indem ich Unit-Tests in einem Container durchführe? Wie würden Sie das ohne Anti-Muster lösen?

.... ich bleibe bei Option 1, da es der geringste Schmerz ist. Aber ich sehe Docker-Compose, das eine Kopierkonfiguration unterstützt, als solch eine großartige Verbesserung! Zumindest für diesen Workflow!

@soulseekah Verwenden Sie Geheimnisse nicht besser für diesen Anwendungsfall?

Ich habe eine Problemumgehung gefunden, die für mich funktioniert:

1. Erstellen Sie die Docker-Datei mit
   COPY a_filename .
2. Erstellen Sie das Image mit der Docker-Datei
   docker build -t myproject:1.0 .
3. Bearbeiten Sie die Docker-Komposition, um das gerade erstellte Image zu verwenden

version: "3.7"
services:
  app:
    image: myproject:1.0
    ports:
      - 3000:3000
    networks:
       - mynetwork
       - internal
    environment:
      MYSQL_HOST: mysql
      MYSQL_USER: root
      MYSQL_PASSWORD: not_so_secret_password # don't do this 
      # https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
      MYSQL_DB: appdb
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 100M

Keine perfekte Problemumgehung, aber es funktioniert in meinem Anwendungsfall.

@soulseekah Verwenden Sie Geheimnisse nicht besser für diesen Anwendungsfall?

Leider erfordert das Schwarm, als ich das letzte Mal versucht habe :(

@soulseekah Verwenden Sie Geheimnisse nicht besser für diesen Anwendungsfall?

Leider erfordert das Schwarm, als ich das letzte Mal versucht habe :(

@soulseekah Verwenden Problemumgehung , die ich verwende (über Ihnen)?

@ChristophorusReyhan Das Problem mit dieser Problemumgehung ist in

Wenn Sie dies mit einer separaten Docker-Datei COPY tun, wird der Code in ein neues, unnötiges Image geschrieben, und ich muss dieses Image löschen, um sicherzustellen, dass beim nächsten Durchlauf ein neues Image mit dem neuesten Code erstellt wird.

Während es eine funktionierende Lösung ist, kann es zu unerwünschten Wartungsarbeiten kommen. Zum Beispiel, um das unerwünschte Bild zu bereinigen und gleichzeitig alle Bilder zu erhalten, die Ihnen wichtig sind:

docker-compose up && docker-compose down --rmi local

Stellen Sie jedoch sicher, dass alle Bilder, die Sie interessieren, über ein benutzerdefiniertes Tag verfügen und das Test- / Dummy-Bild nicht