Compose: Fügen Sie der yaml-Konfiguration `copy` hinzu

Was ist die Semantik von copy hier? Kopieren wir Dateien vom Host, von dem aus docker-compose mit docker cp in den neu ausgeführten Container ausgeführt wird?

AFAIK gibt es keine aktuelle Möglichkeit, dies zu tun:

Sehen:

`` `#! bash
$ docker cp -h

Verwendung: docker cp [OPTIONEN] BEHÄLTER: PATH HOSTDIR | -

Kopieren Sie Dateien / Ordner von einem PATH auf dem Container in ein HOSTDIR auf dem Host
Ausführen des Befehls. Verwenden Sie '-', um die Daten als TAR-Datei in STDOUT zu schreiben.

--help = false Drucknutzung
`` `

Was ist die Semantik der Kopie hier? Kopieren wir Dateien von dem Host, von dem aus Docker-Compose ausgeführt wird, mit Docker-CP in den neu ausgeführten Container?

Ja

AFAIK gibt es derzeit keinen Weg, dies zu tun:

Ich sehe, dass der Befehl docker cp nicht kann. Dennoch ist es immer noch möglich, auf die Containerdaten auf der Hostseite zuzugreifen (was meiner Meinung nach hässlich ist).

http://stackoverflow.com/a/24805696/210090

Ja, ich werde nicht befürworten, dass wir das überhaupt tun. Dies wird viele Dinge und Annahmen über Docker zerstören. Dies hängt auch stark vom verwendeten zugrunde liegenden Speichertreiber ab. Docker soll agnostisch sein. Ich denke, wir sollten eine andere Lösung für Ihr Problem finden :)

Nachdem Docker-1.8 die Unterstützung für das Kopieren in einen Container über docker cp und swarm-0.4.0-rc2 die Unterstützung für docker cp hinzugefügt hat, wäre es großartig, dieses Problem auf der Ebene der Komposition erneut zu betrachten. Hier ist der Anwendungsfall (der das widerspiegelt, was wir derzeit in der Produktion fast tun):

Eine docker-compose.yml-Datei, in der viele Container nach CI-erstelltem Image-Tag erwähnt werden (dh wir verwenden in der Produktion nicht build: ; vielleicht könnten wir das jetzt, aber es hat in früheren Versionen nicht gut mit Swarm gespielt). Alle benötigen z. B. statische Hadoop-Konfigurationsdateien, die genau der Bereitstellungsumgebung entsprechen. Derzeit muss das Verzeichnis, in dem sich docker-compose.yml befindet, manuell mit dem genauen Pfad auf jeder Ziel-Docker-Maschine im Schwarm synchronisiert werden. Dann fügt man einen Stapel von volume: Zeilen hinzu.

Die Unterstützung von docker cp würde das Entfernen einer benutzerdefinierten Konfigurationsdateisynchronisierung in unserer Systembereitstellungsmethode ermöglichen und eine bessere Kontrolle darüber ermöglichen, wann Konfigurationsänderungen eingefügt werden (da sich jeder, der die in den Zeilen volume: genannten Dateien ändert, darauf auswirkt Alle zuvor bereitgestellten Container (und zu jedem Zeitpunkt, zu dem die internen Implementierungen diese Konfiguration erneut lesen, möglicherweise erst beim nächsten Neustart des Containers, möglicherweise wenn verschiedene Tools im Container gestartet werden; was unerwartet sein kann) und in der Zukunft (was erwartet wird).

OTOH (wie oben kurz erwähnt), vielleicht sollten wir build: . Der Nachteil hierbei ist, dass wir pro Bereitstellungscontainertyp eine zusätzliche Docker-Datei schreiben müssen. Eine für die von CI erstellten Images und eine zweite für den Injektor für statische Konfigurationsdateien. copy: in compose, unterstützt durch die jüngsten Änderungen an docker cp würde es uns ordentlich ermöglichen, all diese Doppelarbeit zu vermeiden.

Es scheint immer noch so, als wäre die Verwendung eines Volumes ein besserer Weg, dies zu tun. Es muss kein Host-Volume sein, es sollte mit einem Daten-Volume-Container funktionieren.

Bedies docker-machine hat sowieso docker-machine scp was Sie mit der Vorbereitung der Maschine tun können; und dann können Sie Host-Volumes wie gewohnt mit docker oder docker-compose hosten

"Es scheint immer noch so, als ob die Verwendung eines Volumes ein besserer Weg ist, dies zu tun. Es muss kein Host-Volume sein, es sollte mit einem Datenvolumen-Container funktionieren."
Ich verstehe nicht, wie das am besten ist, wenn das Ziel ein Schwarm ist. AFAICS, man kann nicht ausdrücken, dass an jedem möglichen Schwarmknoten ein Datenvolumencontainer vorhanden sein sollte.

Können Sie einen Datenvolumencontainer nicht über Swarm selbst auf einem Knoten bereitstellen, wie Sie es mit jeder anderen Planungsstrategie für Container tun können?

"Bedies Docker-Maschine hat sowieso Docker-Maschine scp, was Sie mit der Vorbereitung der Maschine tun können; und dann können Sie Host-Volumes auf die normale Weise wie Docker oder Docker-Compose erstellen."
Ich mache das gerade. Es ist schmerzhaft. Personen, die Bereitstellungen verwalten, vergessen, die Konfigurationsdateien zu verschieben. Wenn es in Docker-Compose-XML unterstützt wird, geschieht dies immer dann, wenn ein Container ohne die manuellen Schritte neu erstellt wird.

"Können Sie einen Datenvolumencontainer nicht über einen Schwarm selbst auf einem Knoten bereitstellen, wie Sie es mit jeder anderen Planungsstrategie für Container tun können?"
Vielleicht könnten wir es, aber ich gebe zu, dass ich angesichts der Skalierung nicht sehe, wie.

"Können Sie einen Datenvolumencontainer nicht über einen Schwarm selbst auf einem Knoten bereitstellen, wie Sie es mit jeder anderen Planungsstrategie für Container tun können?"
Humm, wenn ich weiß, dass mein Schwarm Größe 10 Knoten hat; Kann ich den Datenvolumencontainer einfach auf die Größe 10 skalieren, mit der Richtlinie, dass auf einem bestimmten Docker-Engine-Knoten keine Dups zulässig sind? Das Problem (es sei denn, ich habe etwas verpasst) ist, dass beispielsweise Container, die auf dieses Datenvolumen verweisen müssen, keine Möglichkeit haben, aus einem Container mit einem übereinstimmenden Index --volume - zu erstellen. Leute, ich habe mir dieses Problem jetzt seit 2 Monaten angesehen. Das Beste, was ich tun kann, ist ein Skript zu erstellen, das docker-machine scp . Es ist jedoch ein manueller Schritt nach dem Bearbeiten einer Konfigurationsdatei und vor docker-compose up . Es erfordert auch, dass man den genauen Pfad auf die Zielmaschinen des Schwarms als Wurzel der docker-compose.yml schreiben kann (dh es riecht nach einem großen Hack).

Vielleicht können meine Bemühungen in der Fabrik dazu beitragen, diesen Prozess des Hochfahrens von Docker-Maschinen und Schwarmcluttern mit den "richtigen" Daten, die dort zur Verfügung stehen, zu automatisieren? (_ obwohl es sich noch in der frühen Entwicklung befindet und ich es verwende, um docker-machine und docker-compose in einem einzigen setp_0 zu kombinieren.

copy ist eine Operation, die nicht Teil der Dienstkonfiguration ist und daher nicht in die Erstellungsdatei gehört.

Docker 1.9 fügt eine neue Volume-API hinzu, und Volume-Treiber sind bereits vorhanden. Volumes sind wirklich der richtige Weg, um dies zu unterstützen. Ich versuche nicht, Dateien zu kopieren.

Danke für den Vorschlag! aber ich denke nicht, dass dies wirklich zum Design von Compose passt.

Kopieren ist eine Operation, die nicht Teil der Dienstkonfiguration ist und daher nicht in die Erstellungsdatei gehört.

Was ist, wenn man nur eine Konfigurationsdatei kopieren möchte? (zu einem Docker-Schwarm, damit volume_from nicht funktioniert)

Ich habe genau die gleiche Situation, möchte benutzerdefinierte MySQL-, Nginx-, Haproxy- usw. Konfigurationsdateien kopieren, wir haben Cluster in der Produktion und anstatt nur einen Kopierbefehl zum Kopieren von Konfigurationen von lokal nach remote zu verwenden

Ich muss Images verwenden, jedes Mal erstellen, ziehen, während es überhaupt keine Notwendigkeit gibt, und nur ein Kopierbefehl spart viel Bereitstellungs- und Entwicklungszeit

Das ist sehr überraschend für mich, dass mehr Leute kein Problem damit haben, dass dies nicht ohne weiteres skriptfähig ist. Denke ich falsch an Docker? Ich denke, meine Lösung wäre jetzt, ansible zu verwenden, um die Konfigurationsdateien auf den Host zu kopieren und dann das Volume vom Host auf die Container zu mounten, die es benötigen

Das gleiche Problem treffen. Ich verwende eine Docker-Datei für N verschiedene Dienste wieder und möchte nicht N verschiedene Docker-Dateien mit einem eigenen COPY-Befehl erstellen oder nur dafür ein Volume erstellen.

Übrigens löse ich das derzeit, indem ich Dutzende Zeilen von sed-Befehlen ausführe - http://unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

Möglicherweise keine optimale Lösung, funktioniert aber, wenn man bedenkt, dass Docker-Compose das Kopieren von Dateien nicht unterstützt.

Übrigens ist das Mounten und Kopieren natürlich möglich, aber es widerspricht den automatisierten Docker-Compose-Angeboten - wenn ich lieber alles manuell machen würde, würde ich Docker-Compose nicht verwenden, oder?

Je mehr ich mich in Docker vertieft habe, desto mehr scheint es, als ob viele dieser Werkzeuge gut für "Hallo Welt" / "Schau, wie schnell ich dieses coole Ding mit \ shell \ command \ like \ this \" auf einem drehen kann Anwendungsfälle für einzelne Maschinentypen (Docker-Compose enthalten). Wenn es weit darüber hinaus geht, werden die Dinge ziemlich kompliziert und IMO fällt ein wenig auseinander. Hier können traditionelle Bereitstellungstools eingesetzt werden, um den Tag zu retten, wenn sie angemessen verwendet werden.

Ich habe festgestellt, dass die Verwendung von Ansible zum idempotenten Einrichten von Computern sehr einfach ist, wenn maschinenspezifische Volumes, Dateien und Vorlagenkonfigurationsdateien vorhanden sind, damit das Docker-Image gestartet werden kann. Am Ende kann ich dann Ansible verwenden, um Docker-Compse aufzurufen, oder sogar das Ansible-Docker-Modul verwenden, dessen Syntax fast genau der von Docker Compose entspricht, mit einigen netten zusätzlichen Bonusfunktionen.

Letztendlich ermöglicht der obige Ansatz, dass alles skriptgesteuert, idempotent und vor allem in die Quellcodeverwaltung eingecheckt wird.

@dnephin Einige der oben Wäre es sinnvoll, die Annahme zu überdenken, dass CP nur für Vorgänge und nicht für die Konfiguration vorgesehen ist.

Ein einfaches Beispiel ist das Erstellen eines Containers, das Kopieren der Konfiguration an der richtigen Stelle und das Starten des Containers, sobald die Konfiguration kopiert wurde.

Auf diese Weise können Images erstellt werden, in die die eigentliche Konfiguration nicht eingebettet ist, und die Konfiguration wird erst bereitgestellt, wenn der Container gestartet wird.

Wird auf jeden Fall sehr hilfreich sein. Ich arbeite jetzt mit dem Postgres-Image als Datenbank-Backend und möchte es nicht neu erstellen, nur um ein Skript im Ordner /docker-entrypoint-initdb.d zu aktualisieren.

Warum öffnet ihr dieses Problem nicht erneut, bis die Funktion implementiert ist oder eine praktikable Lösung gefunden wurde, die den Leuten gefällt, da hier niemand die vorgeschlagenen Optionen mag?

Dieses Problem sollte erneut geöffnet werden, wie @ctindel erwähnt.

+1 für das erneute Öffnen des Problems

+1 auch zum Öffnen.

+1 zum erneuten Öffnen.

+1 zum erneuten Öffnen.

+1 zum erneuten Öffnen.

+1 zum erneuten Öffnen.

+1 zum erneuten Öffnen.

+1 zum erneuten Öffnen.

Was ist los mit einem schreibgeschützten Volume?

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

@ Michaelarnauts sehen dies .

👍 zum erneuten Öffnen

+1 zum erneuten Öffnen.

+1 zum erneuten Öffnen.

+1 zum erneuten Öffnen

+1 zum erneuten Öffnen

+1 zum erneuten Öffnen

+1 zum erneuten Öffnen

+1 zum erneuten Öffnen

+1 zum erneuten Öffnen

Hier ist meine Begründung für das Zulassen einer Kopie in Compose.

Ich habe eine Anwendung, die auf zahlreichen Containern ausgeführt wurde. Nehmen wir aus Gründen der Argumentation an, dass alle Apache ausführen. Sie alle haben DocumentRoot-Definitionen, die auf Dinge wie "/ var / www / partX" verweisen. Die Docker-Datei kennt den Inhalt der Apache-Konfiguration nicht und die Compose definiert die Volume-Referenz für / var / www / partX. Dies funktioniert hervorragend für die Entwicklung, da ich Code debuggen und optimieren kann, ohne den Inhalt des Containers zu ändern.

Das Problem ist, wenn ich bereitstellen möchte. Eine der Hauptattraktionen von Docker ist, dass ich einen Container bereitstellen kann, der sein eigenes Universum ist. Um alles in den Container zu bekommen, muss ich die Dateien kopieren, was bedeutet, dass ich separate Dockerfile- und Compose-Definitionen von dem haben muss, was ich für die Entwicklung verwende. Bei einem großen Projekt bedeutet dies, dass ich zwei Sätze von Definitionsdateien verwalten muss, was die Möglichkeit von Fehlern erhöht.

Ich würde es vorziehen, einen einzelnen Satz von Docker-Dateien zu verwalten und die Orchestrierung für die Compose-Datei durchzuführen. Beim Verfassen definiere ich, ob ich / var / www / partX als freigegebenes Volume einrichten oder Dateien in den Container kopieren möchte.

Die Bereitstellung mit gemeinsam genutzten Volumes scheint eine Dose Würmer zu sein. Wenn ich eine vorhandene Version in der Produktion aktualisiere, die von einem freigegebenen Volume abhängt, kann ich dieses freigegebene Volume nicht aktualisieren, ohne ein Wartungsfenster einzurichten oder ein Schema für die Versionierung meines freigegebenen Volumes zu erstellen. Ich kopple Container eng mit externen Dateien, und wenn ich diese Art von Komplexität einführe, negiere ich einige der Vorteile der Verwendung von Docker.

Es scheint, als könnte ich Änderungen an den Dockerfile-Definitionen per Skript vornehmen, um Dateien bedingt zu kopieren, aber es scheint "logischer" zu sein, meine gesamte Docker-Logik im Docker-Universum zu handhaben, und Compose scheint ein logischer Ort dafür zu sein.

+1 zum erneuten Öffnen.

+1. Es wäre sehr hilfreich, eine Konfigurationsdatei in die Datei docker-compose.yml anstelle von Dockerfile zu kopieren.

+1. Ich bin gerade darauf gestoßen und habe versucht, eine Konfigurationsdatei für den Dienst bereitzustellen. Das schreibgeschützte Volume scheint eine Option zu sein, möchte es jedoch lieber kopieren.

Das einfache Mounten eines Volumes könnte den Trick machen:

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

@raszi - Yah, die gemountete Konfiguration ist die Richtung, in die wir jetzt gehen werden. Eines der Dinge, die ich an Docker wirklich mochte, war die Vorstellung eines in sich geschlossenen Containers, auf dem ich Integrationstests ausführen konnte, ohne Rücksicht auf externe Abhängigkeiten (wie die verknüpfte Konfiguration). Wenn ich Blau / Grün- oder A / B-Bereitstellungen durchführe und es Unterschiede in den Konfigurationen gibt, die von verschiedenen Versionen von Containern verwendet werden, können die Dinge etwas zerbrechlich werden. Ich kann dies umgehen, indem ich beispielsweise Konfigurationsdateien in einem gemeinsam genutzten Volume jeder meiner Umgebungen versioniere, aber es scheint nur komplexer oder spröder zu sein, als es sein könnte.

"Docker-Container verpacken eine Software in ein vollständiges Dateisystem, das alles enthält,

Ich stimme zu, es wäre großartig, diese Funktion zu haben. Ich habe gerade meine Lösung veröffentlicht, um anderen zu helfen.

+1 zum erneuten Öffnen.

+1

+1 für Wiedereröffnung oder andere Lösung ohne Volumen.

Derzeit werden Umgebungsvariablen in docker-compose.yml und j2 in docker-entrypoint.sh verwendet, um sie in Konfigurationsdateien zu analysieren, bevor die Haupt-App des Containers ausgeführt wird. Funktioniert für mich, obwohl es sich um ein benutzerdefiniertes Bild handelt und es nicht sofort mit bereits verfügbaren vollständigen Bildern verwendet werden kann.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 zum erneuten Öffnen

Hinzufügen der Möglichkeit, für jeden Container eine andere Yaml-Datei anstelle einer auf Umgebungsvariablen basierenden Konfiguration zu haben

+1 sehr benötigte Funktion

+1, schön, Feature zu haben!

+1

+1

+1

+1

+1 Wiedereröffnung. Lesezeichen

+1 Dies ist eine dringend benötigte Funktion.

Wenn es eine Möglichkeit gäbe, ein freigegebenes Volume als Ebene zu markieren, sodass das Volume RO bleibt, aber die Schreibvorgänge auf eine Ebene oben angewendet werden, würde ich ohne eine copy -Anweisung glücklich leben. Ich möchte beispielsweise ein extrahiertes Build-Artefakt freigeben, aber der Dienst schreibt in dieses Verzeichnis (Protokolle oder PID-Datei usw.).

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 Zum erneuten Öffnen, da dies eine sehr nützliche Funktion wäre

Vielleicht kann die Vorlagenfunktion von https://github.com/jwilder/dockerize einigen von Ihnen helfen

+1

+1

+1

+1

+1

+1, um das Problem erneut zu öffnen

+1

Verwenden Sie Docker-Geheimnisse. In diesem Beispiel werden Geheimnisse mit dem Nginx-Image verwendet, um das Serverzertifikat und die Konfigurationsdatei zu kopieren
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secret-with-a-nginx-service

Das ist ein guter Punkt. Ehrlich gesagt scheint es, dass wir, da wir bereits Geheimnisse haben, eine Kopie haben sollten, da Geheimnisse in gewisser Weise nur eine bestimmte Art von Datei sind, über die Sie kopieren würden. Eine, die sorgfältiger bereitgestellt wird und die wir für Konfigurationsdateien nicht benötigen.

Es übertrifft das Host-Mounten eines Volumes für jede Konfigurationsdatei, die Sie aufnehmen möchten.

Wie gesagt:

...
Bände:
- ./nginx/default.conf:/etc/nginx/conf.d/default. conf: ro
- ./nginx/nginx.conf:/etc/nginx/nginx. conf: ro
...

Der Grund für die Kopie ist besser: a) In Schwarmumgebungen, in denen Hosts tatsächlich separate Computer sind, sollten Sie nicht auf jedem Computer genau dieselbe Datei an derselben Stelle haben müssen. b) Das Kopieren kann auch auf den Ordner beschränkt werden, in dem sich das Erstellen befindet, während für ein Host-Mount ein absoluter Pfad erforderlich ist. c) Ich denke, der Sinn von Docker besteht darin , die Anzahl der Stellen zu die Verantwortung, Dateien zu bewahren . Wir sollten keine Host-Mounts verwenden müssen, um dieses einfache Problem zu lösen.

Ich denke, das Kopieren könnte ähnlich wie der docker build -Prozess modelliert werden, bei dem das Dockerfile normalerweise zusammen mit allen Dateien, die zum Senden an den Build-Kontext benötigt werden, in einem Git-Repository geliefert wird. Das Dockerfile darf nichts senden, was außerhalb seiner Verzeichnisstruktur existiert, selbst wenn es korrekt verknüpft ist. Ähnliches könnte beim Komponieren der Fall sein, bei dem src auf das Verzeichnis (und die folgenden) des docker-compose.yml . Grundsätzlich würde der Workflow lauten: docker-compose erstellt den Container. Suchen Sie dann für jedes src:dst -Paar die src unter dem aktuellen Verzeichnis und kopieren Sie sie in den nicht gestarteten Container. Starten Sie dann den Container.

Derzeit kann das Vermeiden von Host-Mounts erreicht werden, indem zusätzliche Dockerfiles hinzugefügt und die conf -Dateien in geänderte Bilder integriert werden. Dies scheint mir jedoch ein Overkill zu sein, da ein neues Image neu markiert oder Benutzer gezwungen werden müssen Verwenden des Attributs docker-compose build anstelle des Attributs image (IMO). Wenn Sie bereits das Attribut build in Ihrer Service-Definition verwenden und die Dinge auf diese Weise ausführen möchten, müssen Sie Ihren ansonsten agnostischen Image Builder mit einer Konfigurationsdatei mit hoher Meinung verschmutzen, die nur zum Verfassen gehören sollte und der Bereitstellungsprozess.

+1 für Docker-Compose-Kopierfunktion

+1

+1

+1

+1 zum Kopieren.

+1 für Docker-Compose-Kopierfunktion. Ich denke, die obigen Argumente sind überzeugend.

+1 zum Kopieren

+1 zum Kopieren.

Obwohl in meinem POV. Es kann praktisch sein, aber es kann auch für viele Benutzer außer Kontrolle geraten oder missbraucht werden und sogar das Volumen überflüssig machen. Wenn Sie nur Dateien benötigen, die speziell für den Schwarm auf den Container gelegt werden sollen, können Sie einfach Konfigurationen oder Geheimnisse verwenden. Aber für meinen Fall, wie das Ablegen statischer Ordner in einem Nginx-Container, muss ich mehrstufige Builds in meiner Docker-Datei verwenden, um diese statischen Ordner in den Container zu legen, was viel Prozess erfordert, bevor mein Ziel erreicht wird. Daher denke ich, dass das Hinzufügen einer Kopieroption sehr nützlich sein könnte

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 zum erneuten Öffnen

+1

+1 zum erneuten Öffnen

Würde eine Funktion, die auf einem Volume ausgeführt wird, nachdem der Container (oder selbst) bestimmte Statuszustände erreicht hat, nicht funktionieren?
Es könnte eine Flagge wie readonly sein, aber stattdessen copyonly ! Dann hätten Sie die Pipeline / Syntax für reguläre Volumes-Operationen mit der zusätzlichen Funktionalität, den Link zu entfernen, nachdem ein Synchronisierungsstatus im Container erreicht wurde ...

+1 zum erneuten Öffnen. Volumenmontage ist nicht immer eine Option. Deshalb poste ich heute hier. Aufgrund eines einzigartigen Szenarios, in dem das Mounten von Volumes verboten ist, muss eine große Anzahl von Containern von Hand geändert werden, um Dateien zu kopieren.

+!

+1

+1 für Docker-Compose-Kopierfunktion

+1

+1

Ich fange an zu denken, dass dies sinnlos ist. Docker fügt nur Funktionen für den speziellen Anwendungsfall hinzu, für den Docker erstellt wurde. Dies ist eine der Funktionen außerhalb des Anwendungsfalls, sodass sie diese wahrscheinlich nie hinzufügen werden.

+1

@stuaxo Nur weil viele Leute nach Fußgewehren fragen, heißt das nicht, dass wir sie automatisch implementieren sollten.

In diesem Fall sollten Dateien, die ein Dienst zum Ausführen benötigt, entweder in den Build eingebrannt (in Dockerfile deklariert), über Volumes verfügbar gemacht werden oder (im Fall von docker stack / Swarm-Modus) als Konfiguration vorhanden sein oder geheime Objekte. Das Kopieren von Dateien in potenziell mehrere Ziele zur Laufzeit ist langsam, fehleranfällig und nicht ausfallsicher.

Prost, entschuldige, wenn das mürrisch rüberkam.
Wenn Sie "Ausführen eines Dienstes" sagen, meinen Sie damit eine lange laufende Sache wie einen Webdienst. Docker hat dies gut abgedeckt.

Das Überlagern und Zwischenspeichern von Dockern ist für andere Dinge praktisch.

Ich habe mein altes WordPress-Blog in Docker gestellt, aber manchmal nur einige Minuten lang ausgeführt, damit ich Daten exportieren oder überprüfen kann, wie ein Beitrag dort aussieht.

Die Verwendung von Docker Compose zum Trennen von MySQL und Apache erforderte ein wenig Arbeit, aber es wäre mir egal, ob sie alle zusammen waren.

Das Zwischenspeichern von Dockern macht Spaß, wenn Sie mit dem Erstellen von Desktop-Bibliotheken wie Kairo experimentieren. Bei den meisten Dingen, die ich versucht habe, habe ich die Details vergessen, aber ich bin eher auf der Seite des Baus als etwas, das mit dem Ausführen von Diensten zu tun hat.

+1 Docker-Compose-Kopie muss hinzugefügt werden. Es ermöglicht einen viel einfacheren Fluss von Konfigurationsdateien und Aktualisierungen von Containern.

Verwenden Sie Docker CP und Docker-Konfiguration

Am Fr, 2. März 2018 um 21:19 schrieb James Hahn [email protected] :

+1 Docker-Compose-Kopie muss hinzugefügt werden. Es ermöglicht einen viel einfacheren Fluss
von Konfigurationsdateien und Aktualisierungen von Containern.

- -
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/1664#issuecomment-370055493 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ABOv-q5VO9n9HDvBP6YJ1BCePz5tGu-pks5tabdrgaJpZM4FTTPg
.

>

James Mills / Prologic

E: [email protected]
W: prologic.shortcircuit.net.au

+1 für Docker-Compose-Kopie. Die Idee ist, nur Kopien für Dateien zu haben, wie hier beschrieben

+1

+1

In diesem Fall sollten Dateien, die für die Ausführung eines Dienstes erforderlich sind, entweder in den Build eingebettet (in Dockerfile deklariert), über Volumes verfügbar gemacht werden oder (im Fall des Docker-Stack- / Swarm-Modus) als Konfigurations- oder geheime Objekte vorhanden sein. Das Kopieren von Dateien in potenziell mehrere Ziele zur Laufzeit ist langsam, fehleranfällig und nicht ausfallsicher.

Außer in vielen Fällen ist alles, was Sie wollen, das Aktualisieren einer einzelnen Konfigurationsdatei. In diesem Fall ist das Backen Ihres eigenen Images eines offiziellen Standard-Images eine schlechte Praxis und verursacht eine Menge technischer Schulden für die Zukunft. Die Volumes sind X10 übertrieben und Sie nicht will oder die Dateien müssen die Synchronisierung zu halten nicht die Probleme des haben zu erwähnen , mit dem ganzen Ordner und nicht nur eine einzelne Datei in einem Standard - Speicherort beschäftigen, und Sie müssen nicht nur eine Systemdatei aktualisieren , eine Konfigurationseinstellung erhalten.

Ich verstehe Ihre Bedenken, aber nur allen zu sagen, dass ihre Bedürfnisse nicht real sind, wird die Menschen nur von Ihrem Projekt und der Community, die es nutzen und Ihre Arbeit unterstützen möchte, abbringen. Wir möchten hier mit Ihnen zusammenarbeiten, um eine Lösung zu finden, die funktioniert. Sie möchten jedoch nur sagen, dass wir nicht das brauchen, was wir für nötig halten.

Wow, ich kann nicht glauben, dass dies noch nicht getan wurde. Ich dachte, dass diese grundlegende Funktionalität inzwischen in Docker-Compose vorhanden gewesen wäre. Oh, die Schönheit von OSS-Projekten ...

Es wurde mit docker-compose --force-recreate --rebuild gelöst und kopiert die neuen Dateien, wenn sie geändert wurden (oder so scheint es). Nicht ideal, aber es funktioniert.

+1

+1

+1

+1

+1 das ist zurückhaltend macht mich verrückt, es scheint albern, ein Volume nur für eine Konfigurationsdatei mounten zu müssen.

+1

Wir haben die Möglichkeit, Dateien mithilfe von Docker Compose mit Volumes zu einem Container hinzuzufügen. Ich habe festgestellt, dass die Compose-Dokumentation jetzt die Einstellung configs , sodass wir auch einzelne Dateien hinzufügen können.

https://docs.docker.com/compose/compose-file/#configs

Ich glaube jedoch, dass die Leute eine Möglichkeit haben möchten, Dateien vom Host in ein Verzeichnis im Container zusammenzuführen, wobei overwrite if exists bevorzugt wird, so wie Sie es von einer Kopie erwarten würden.

Es ist seltsam für mich, dass die volumes -Konfiguration in der Erstellungsdatei eine nocopy -Option hat:

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

Welches ist so beschrieben:
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

Also deaktiviert es genau das, was gewünscht wird?

Mein gewünschter Anwendungsfall sind Webanwendungen für die Entwicklung. Ich möchte, dass das Image alles enthält, was für die Bereitstellung einer Website erforderlich ist, einschließlich einer Standardwebsite, die bereitgestellt werden soll. Ich habe jedoch die Möglichkeit, diese Dateien mit dem aktuellen Arbeitsstatus einer Website zusammenzuführen / zu überschreiben, ohne dass eine andere Konfiguration (der Schlüssel) vorliegt, als die Dateien enthalten der richtige Ort auf dem Host. Dateien, die beim Kopieren in den Container kurzlebig sind. Das heißt nicht in einer Netzwerkfreigabe.

Ein Beispiel für ein Framework, das davon profitieren würde, ist so etwas wie Laravel. Wo ich ein Image erstelle, das in der Lage ist, die Laravel-Begrüßungsseite ohne andere Konfiguration (Volumes, Netzwerkfreigaben usw.) bereitzustellen, aber die Compose-Datei so geschrieben wird, dass Dateien vom Host in das Laravel-Stammverzeichnis des Containers kopiert werden überschrieben.

Die Verwendung einer Netzwerkfreigabe hierfür ist eine zusätzliche Wartung für eine kurzlebige Umgebung (die Entwicklung ist nicht immer konstant). Für die Verwendung eines Volume-Mount mit einem Framework wie Laravel muss die App in diesem Volume erstellt werden. Dies bedeutet, dass PHP und Composer auf dem Host installiert oder der Speicherort auf dem Host freigegeben wird, auf dem die App erstellt werden soll. Beides schafft mehr Wartung.

Bearbeiten:

Nach dem Testen scheinen die Dateien, die im Image an diesem Speicherort vorhanden waren, beim Mounten eines Volumes auf das persistente Volume kopiert zu werden, wobei der ursprüngliche Inhalt des Volumes bevorzugt wird. Das heißt, es wird nicht überschrieben.

Ich denke tatsächlich, dass dies eine Lösung für das gewünschte Ergebnis ist.

Hey, Leute, nur zu Ihrer Information, es ist besser, auf die Top-Nachricht zu diesem Thema mit dem Daumen nach oben zu reagieren, als einen "+1" -Kommentar hinzuzufügen, da die Probleme nach der Anzahl der erhaltenen Reaktionen sortiert werden können.

+1

+1 Bitte Docker-Team, berücksichtigen Sie Ihre Community.

@ shin- Das Problem im Moment ist, dass die Volume-Funktion es unmöglich macht, eine einzelne Konfigurationsdatei von einem externen Volume in einen Container einzufügen.

Angenommen, ich möchte eine Nginx-Konfigurationsdatei in /etc/something/whatever.conf einfügen, ohne alles andere in diesem Ordner zu vernichten. Sie können kein benanntes Volume für eine einzelne Datei erstellen (siehe moby / moby # 30310), und Sie können auch kein Verzeichnis-Volume erstellen, das eine einzelne Datei enthält, und diese bestimmte Datei dann in den Container einbinden (siehe moby / moby #). 32582).

Die einzige Möglichkeit, die Ihnen bleibt, besteht darin, feste Speicherorte in Ihrem tatsächlichen Docker-Host mit den Konfigurationsdateien zu verschmutzen und diese dann zu binden. Dies ist natürlich schwierig, wenn Sie zwischen Docker-Hosts wechseln oder mit einem Docker arbeiten möchten Host, auf den Sie keinen Dateisystemzugriff haben (z. B. Online-CI), oder einfach nur mehrere Stapel gleichzeitig ausführen.

Hier muss etwas nachgeben, entweder muss sich die Volumes-Funktion in Docker ändern, damit wir sie tatsächlich zum Einfügen von Konfigurationsdateien in unseren Stack verwenden können, oder wir müssen sie beim Erstellen mit so etwas wie einem copy config Option.

FWIW Ich bin kein Compose-Betreuer mehr, aber es scheint mir, dass dieser Anwendungsfall am besten durch Einfügen der Konfigurationsdatei beim Erstellen mithilfe einer Docker-Datei erreicht werden kann.

@ shin- Leider sind die Konfigurationsdateien zum Zeitpunkt der Erstellung nicht bekannt. Die Images werden auf einem CI-Server vorbereitet, lange bevor wir wissen, wo und in welcher Konfiguration wir sie bereitstellen werden.

Ich bin bei @masaeedu , ich verstehe das konzeptionelle Ideal, die Funktion des Komponierens vor dem Kriechen zu

A) eine Art abscheuliche Skriptarbeit zusammenschustern zu müssen, um die fraglichen Container aufzurichten (genau das, was komponiert wurde, sollte helfen, zu standardisieren und uns davon abzuhalten, etwas zu tun),

B) Sie müssen ein anderes Tool hinzufügen, das unsere gesamte Konfiguration verwaltet (was zwar funktioniert, aber einen großen Aufwand für kleine bis mittelgroße Projekte mit sich bringt, die wirklich nur eine bestimmte .conf und .env in jeden Container kopieren müssen, etwas, das Sie tun Sie möchten dies nicht zur Image-Erstellungszeit tun. Dies entspricht der Aussage, dass Sie, anstatt dass Ihre Software über eine Konfigurationsdatei verfügt, alle Ihre Optionen fest in C ++ codieren sollten. Dies führt dazu, dass Dutzende zusätzlicher Images gewartet werden müssen

C) Wir müssen ein separates Image für jede mögliche Konfiguration einer bestimmten Software verwalten, die wir jemals benötigen / erstellen werden, jedes Mal, wenn wir eine geringfügige Konfigurationsänderung vornehmen müssen. Dies ist in der realen Welt nicht möglich von Produktionssoftware und macht es auch unmöglich, die Art von robuster QS- und Test-Pipeline zu haben, die wir für Produktionssoftware benötigen.