du verkettest sie :)

Wenn Sie also beispielsweise eine Dockerfile haben, die Ihren generischen Postgres-Client und die generische Python-App-Umgebung einrichtet, markieren Sie das Ergebnis dieses Builds (zB mygenericenv ), und dann verwenden Ihre nachfolgenden Dockerfiles FROM mygenericenv .

für zB

## Dockerfile.genericwebapp might have FROM ubuntu
cat Dockerfile.genericwebapp | docker build -t genericwebapp -
## Dockerfile.genericpython-web would have FROM genericwebapp
cat Dockerfile.genericpython-web | docker build -t genericpython-web -
## and then this specific app i'm testing might have a docker file that containers FROM genericpython-web
docker build -t thisapp .

Ich kann sehen, wie das geht, dh genericA --> specificA aber gibt es eine Möglichkeit, so etwas zu tun:

genericA --
            \
             ---> specificAB
            /
genericB --

?

Nicht mit offiziellen Mitteln, aber einige Leute hatten Glück, die Bildhierarchie manuell zu ändern, um dies zu erreichen (aber wenn Sie dies tun, tun Sie dies auf eigene Gefahr und Sie dürfen alle Teile behalten).

Der Grund, warum dies nicht offiziell unterstützt wird, ist, dass ich mir vorstellen möchte, "ubuntu" zu nehmen und "centos" obenauf zu übertragen. Es wird viele wirklich lustige Konflikte geben, die einen Support-Albtraum verursachen. Wenn Sie also solche Dinge tun möchten, sind Sie auf sich allein gestellt.

Okay, ich verstehe warum. Ich habe nach zusammensetzbaren Funktionsblöcken gesucht, aber vielleicht ist dies nicht der Docker-Anwendungsfall ... es scheint, als ob ich es verwenden sollte, um die Rohcontainer einzurichten und dann etwas wie Ansible oder Saltstack darüber auszuführen, um die Software darin zu konfigurieren.

Die Idee hinter Containern ist, dass die kleinste Einheit der realen Komposition der Container ist. Das heißt, ein Container ist das kleinste Ding, das Sie im Voraus produzieren können, ohne zu wissen, mit was es sonst noch kombiniert wird, und hat starke Garantien dafür, wie es sich verhält und mit anderen Komponenten interagiert.

Daher kann jede Einheit, die kleiner als ein Container ist – sei es ein Ruby- oder Shell-Skript, ein C++-Quellbaum, eine eigenständige Binärdatei, ein Satz Konfigurationsdateien, ein Systempaket usw. – nicht sicher zusammengestellt werden, da sie sich verhält sehr unterschiedlich, abhängig von den Build-Abhängigkeiten, Laufzeitabhängigkeiten und den anderen Komponenten, die Teil der Komposition sind.

Diese Realität kann teilweise durch rohe Gewalt maskiert werden. Eine solche brachiale Gewalt kann pragmatisch und "gut genug" sein (riesiges Makefile, das alles automatisch erkennt, um eine portablere Zusammenstellung Ihrer App zu ermöglichen) oder übermäßig grandios ("lasst uns im Voraus jede mögliche Permutation jeder Abhängigkeit und Interferenz zwischen Komponenten modellieren und ausdrücken sie in einer Abstraktion auf hoher Ebene!")

Wenn Sie sich auf Ansible, Chef oder ein anderes Konfigurationsmanagement verlassen, um "zusammensetzbare Komponenten" zu erstellen, verlassen Sie sich auf eine undichte Abstraktion: Diese Komponenten sind tatsächlich nicht zusammensetzbar. Von einem System zum nächsten werden sie Builds produzieren, die sich auf millionenfache Weise unterschiedlich verhalten. All die zusätzliche Abstraktion wird Ihnen am Ende sehr wenig bringen.

Mein Rat ist, sich auf 2 Dinge zu konzentrieren: 1) den Quellcode und 2) den ausführbaren Container. Dies sind die einzigen 2 zuverlässigen Punkte der Zusammensetzung.

Am Sonntag, 29. Dezember 2013 um 13:46 Uhr, anentropic [email protected]
schrieb:

Okay, ich verstehe warum. Ich habe nach zusammensetzbaren Funktionsblöcken gesucht, aber vielleicht ist dies nicht der Docker-Anwendungsfall ... es scheint, als ob ich es verwenden sollte, um die Rohcontainer einzurichten und dann etwas wie Ansible oder Saltstack darüber auszuführen, um die Software darin zu konfigurieren.

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/dotcloud/docker/issues/3378#issuecomment -31326172

Danke für die weitere Perspektive.

Sie sagen also, dass für die Wiederverwendung von Teilen von Dockerfiles das einzige verfügbare Werkzeug das Kopieren und Einfügen ist? Aus der Sicht von "Entwicklern" und nicht von "Ops" fühlt es sich ein bisschen falsch an.

Vielleicht ist es ein Fehler, den öffentlichen Bilderindex zu haben, es sieht so aus, als könnten Sie wiederverwendbare Bausteine ​​​​vage analog zu den Rezepten von Chefkoch teilen, aber meine bisherige Erfahrung ist, dass dies nicht nützlich ist, weil:
a) für die meisten Bilder gibt es keine Informationen darüber, was es tut und was drin ist
b) die Dokumente ermutigen dazu, Ihre Arbeit in den Index aufzunehmen (damit Sie sie später abrufen können), obwohl das, was Sie gemacht haben, für andere wahrscheinlich nicht nützlich ist

Ich habe das Gefühl, dass die Dokumentation Sie im Moment nicht wirklich anleitet, Docker sinnvoll zu verwenden

@anentropic Der richtige Weg, dies mit Dockerfiles zu tun, besteht darin, mehrere Images mit mehreren Dockerfiles zu erstellen.
Hier ein Beispiel: Dockerfile 1 erstellt ein generisches Image auf einem Ubuntu-Basis-Image, Dockerfile 2 verwendet das resultierende Image von Dockerfile 1, um ein Image für einen Datenbankserver zu erstellen, Dockerfile 3 verwendet das Datenbankserver-Image und konfiguriert es für eine spezielle Rolle .

docker build sollte recht einfach zu bedienen sein und unnötige Komplexität sollte nicht hinzugefügt werden.

Der öffentliche Bilderindex ist äußerst nützlich. Docker-Images sind normalerweise dazu gedacht, einen Dienst oder eine Reihe von Diensten auszuführen, die nicht in separaten Containern ausgeführt werden können. Sie können normalerweise ohne großen Aufwand ein Image abrufen, ausführen und einige nützliche Software zum Laufen bringen.

Verstanden ... also in dem Szenario, das ich oben mit ASCII-Kunst skizziert habe, wäre der Docker-Weg:

• Beginnen Sie mit Dockerfiles für unabhängige Images GenericA und GenericB
• Um ein Image SpecificAB erstellen, würde ich den Inhalt des GenericB Dockerfiles kopieren und in ein neues Dockerfile einfügen, das mit FROM GenericA beginnt

Das Problem, das ich sehe, ist, dass, wenn das 'Rezept' (um einen Chef-Begriff zu leihen) für GenericB ziemlich komplex ist und viele Schritte umfasst, ich diese Informationen nicht weitergeben kann, außer indem ich das Dockerfile _to Github_ veröffentliche dass andere die relevanten Teile _kopieren und einfügen_ in ihr eigenes Dockerfile.

Haben Sie versucht, den öffentlichen Index zu verwenden? Ich habe zum Beispiel nach "postgres" gesucht ... wie beurteile ich die Nützlichkeit von (oder unterscheide in irgendeiner Weise) Bilder wie diese:

• https://index.docker.io/u/cthulhuology/postgres/
• https://index.docker.io/u/alvin/postgres/
• https://index.docker.io/u/antihero/postgres/
• https://index.docker.io/u/dbraden/postgres/

?

Welchen Wert bieten diese, wenn der einzige Weg, um sicherzustellen, dass ich einen Postgres-Server so eingerichtet habe, wie ich es möchte, auf einem bestimmten Basis-Image, in dem nichts Zwielichtiges versteckt ist, darin besteht, ihn selbst von Grund auf neu zu erstellen.

Ich kann den Wert einiger „offiziell gesegneter“ Basisbilder in einem öffentlichen Index erkennen. Ich kann den Wert eines privaten Indexes meiner eigenen benutzerdefinierten Bilder erkennen, die zum Abrufen bereitstehen.

Aber es scheint eine Schande , dass es keine Möglichkeit gibt (abgesehen von Copy & Paste) , um die Reihe von Befehlen in der Dockerfile als Rezept zu teilen ... wie der Vorschlag für einen ‚include‘ Befehl, hier wurde abgelehnt https: // Github .com/dotcloud/docker/pull/2108

@anentropic Sie können ein vertrauenswürdiges Image verwenden und Sie können auch eine Postgres-Dockerdatei finden, um das Image selbst zu erstellen.

Bilder sind normalerweise nützlicher, wenn Sie das Dockerfile anpassen, um sicherzustellen, dass sie genau Ihren Anforderungen entsprechen. Aus diesem Grund haben Sie festgestellt, dass mehr Benutzer ein Image für dieselbe Software in die Registrierung hochgeladen haben.

Vorhandene spezifische Bilder wie die Postgres-Bilder entsprechen möglicherweise nicht Ihren speziellen Anforderungen, aber es gibt auch Basisbilder, die sofort verwendet werden können, um etwas Nützliches für Sie zu erstellen.

Basis-Images wie ubuntu , centos und einige Images von stackbrew/* sind Images, die Sie verwenden können, um das zu erstellen, was Sie brauchen.

Ein Beispiel für ein großartiges gebrauchsfertiges Bild ist stackbrew/registry . Mit diesem Image können Sie mit einer privaten Docker-Registrierung herumspielen, sobald docker pull stackbrew/registry und docker run -p stackbrew/registry mit der Ausführung fertig sind.

Das Ziel von Docker ist es, bei der Bereitstellung zu helfen und die Umgebung vorzubereiten, in der Ihre Software ausgeführt wird. Dies bedeutet, dass Builds linear sind und nur während des ersten Builds ausgeführt werden, Sie jedoch jedes Mal genau dieselbe Software ausführen.

Konfigurationsverwaltungssysteme ermöglichen Ihnen möglicherweise etwas mehr zu tun oder andere Tricks anzuwenden, aber sie sind nicht so "unveränderlich", und Sie können am Ende zwei Hosts mit subtilen Unterschieden haben, die von der Konfigurationsverwaltungssoftware nicht erkannt werden.

Ich hasse es, einen alten Thread zu vernichten, wollte aber etwas anbieten, das IMHO hilft, das Problem des ursprünglichen Posters zu lösen und anderen helfen kann, die hier nach einer ähnlichen Lösung für dieses Problem suchen.

Nehmen wir der Einfachheit halber an, dass sie alle das gleiche Basis-Image R . Stellen Sie sich vor, ich habe den Dienst A und den Dienst B . Ich möchte sie in separaten Docker-Images und beide auf demselben Docker-Image.

Schreiben Sie ein Skript zum Installieren des Dienstes A und schreiben Sie ein separates Skript zum Installieren des Dienstes B . Dann haben Sie ein Git-Repo mit dem Skript für A und ein weiteres für das Skript B . Erstellen Sie Git-Repos für alle drei Docker-Images, die erstellt werden. Jedes enthält git-Submodule mit den Installationsskripten, die verwendet werden. Jedes Dockerfile wird einfach ADD ein Installationsskript und dann RUN das Installationsskript und dies für eines oder beide Skripte tun. Wenn Sie das/die Skript(s) aus dem Image entfernen möchten, heften Sie dies nach der Ausführung an.

Auf diese Weise gibt es eine Kopie jedes Installationsskripts und aller Docker-Images, die Sie verwenden möchten. Dies vermeidet unnötiges Kopieren von Code und hält den Wartungsaufwand minimal. Der einzige doppelte Aufwand besteht darin, den von den Submodulen verwendeten Commit nach oben zu verschieben, was deutlich besser ist als die Alternative und wahrscheinlich automatisiert werden könnte.

Ich glaube, ich verstehe die Funktionsweise falsch, daher antworte ich, um eine Klarstellung zu erhalten. Ich möchte Ubuntu 11 mit den offiziellen Selen-Docker-Images verwenden. Sie verwenden Ubuntu 15.

https://github.com/SeleniumHQ/docker-selenium/blob/master/Base/Dockerfile

Wie mache ich das richtig? Um dieses Repository zu klonen und alle Dateien zu bearbeiten, um Ubuntu 11 und nicht 15 zu sagen? Das kann nicht richtig sein, oder? Dies würde bedeuten, dass jeder, der mit irgendeinem Aspekt der offiziellen Bilder nicht einverstanden ist, diese nicht verwenden kann, ohne den Code für sie zu duplizieren. Ich glaube, ich liege falsch, kann mir das jemand erklären? Was ist der richtige Weg, um das offizielle Selen-Image mit Ubuntu 11 zu verwenden?

@rjurney ja, so würde das funktionieren; in Ihrem Beispiel wurde das gesamte Dockerfile unter Berücksichtigung von Ubuntu:15.04 entwickelt; Sind diese Pakete auf ? Arbeiten Sie? Läuft Selen darauf? Es besteht die Möglichkeit, dass Änderungen am Dockerfile vorgenommen werden müssen, damit es auf einer anderen Version von Ubuntu funktioniert.

Das "Swapping" des Basis-Image eines bestehenden Images würde auch nicht funktionieren, da Docker nur die _Unterschiede_ zwischen dem Basis-Image und dem Image speichert. Die Verwendung eines anderen Basis-Image führt daher zu unvorhersehbaren Ergebnissen (zB "Datei X entfernen", wobei "Datei X" im ursprünglichen Basis-Image vorhanden ist, aber nicht in dem von Ihnen ausgewählten Basis-Image). Außerdem sind die Pakete/Binärdateien in Bildern, die "auf" einem Basis-Image aufbauen, Pakete, die für _diese_ Version erstellt wurden. Diese Binärdateien sind möglicherweise nicht mit einem anderen Basis-Image kompatibel.

Dies würde bedeuten, dass jeder, der mit irgendeinem Aspekt der offiziellen Bilder nicht einverstanden ist, diese nicht verwenden kann, ohne den Code für sie zu duplizieren

Ja. Die offiziellen Images werden von den Betreuern dieser Images unterstützt (in diesem Fall die Betreuer von Selenium). Wenn Sie der Meinung sind, dass Änderungen an diesen Bildern erforderlich sind, öffnen Sie am besten eine Funktionsanfrage in ihrem Repository. Wenn diese Funktionsanforderung nicht akzeptiert wird, sollten Sie wahrscheinlich Ihre eigene Version erstellen.

(Beachten Sie auch, dass es kein offizielles ubuntu:11 Bild gibt)

Im Rest der Softwarewelt wird die einfache Vererbung nicht als
ausreichend, um die benötigte Semantik angemessen auszudrücken. Es führt zu viel Code
Duplizierung, die als Fehler gewertet würde. Warum wird das so gesehen?
akzeptabel für Docker? Selbst wenn Sie einen Dienst nach dem anderen erstellen,
Komposition ist auf Betriebssystemebene erforderlich. Ich will nicht schlagen
totes Pferd, aber diese Grenze scheint ein wenig extrem. Könnte es besser sein
als Best Practice ausgedrückt? Aufgrund der Strenge dieser
Entscheidung, jemand wird ein Werkzeug bauen, das Komposition oder Multiples macht
Vererbung und drückt sie durch einfache Vererbung und Vervielfältigung aus.
Wenn sich dies außerhalb von Docker befindet, dient dies der Docker-Community nicht.

Am Mittwoch, 9. Dezember 2015, Sebastiaan van Stijn <
[email protected]> schrieb:

@rjurney https://github.com/rjurney ja, so würde das funktionieren; in
Ihr Beispiel, das gesamte Dockerfile wurde unter Berücksichtigung von Ubuntu:15.04 entwickelt;
Sind diese Pakete auf ? Arbeiten Sie? Läuft Selen?
auf sie? Es besteht die Möglichkeit, dass Änderungen im Dockerfile vorgenommen werden müssen
damit es auf einer anderen Ubuntu-Version funktioniert.

Das "Swapping" des Basis-Image eines bestehenden Images würde auch nicht funktionieren, weil
Docker speichert nur die _Unterschiede_ zwischen dem Basis-Image und dem
Bild. Die Verwendung eines anderen Basis-Image führt daher zu unvorhersehbaren
Ergebnisse (z. B. "Datei X entfernen", wobei "Datei X" in der ursprünglichen Basis vorhanden ist
Bild, aber nicht im ausgewählten Basisbild). Auch die Pakete/Binärdateien
in Bildern, die "auf" einem Basis-Image aufbauen, sind Pakete, die gebaut werden
für _diese_ Version sind diese Binärdateien möglicherweise nicht mit einer anderen kompatibel
Basisbild.

Dies würde bedeuten, dass jeder mit einer Meinungsverschiedenheit über irgendeinen Aspekt von
offizielle Bilder können sie nicht verwenden, ohne den Code für sie zu duplizieren

Ja. Die offiziellen Bilder werden von den Betreuern dieser Bilder unterstützt
(die in diesem Fall die Betreuer von Selenium sind). Wenn du denkst, dass sich ändert
für diese Bilder benötigt werden, öffnen Sie am besten eine Feature-Anfrage in
ihr Repository. Wenn diese Funktionsanfrage nicht akzeptiert wird, sollten Sie
wahrscheinlich bauen Sie Ihre eigene Version.

(Beachten Sie auch, dass es kein offizielles Ubuntu:11-Bild gibt)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/3378#issuecomment -163188299.

Russell Jurney twitter.com/rjurney-russell. [email protected] relato.io

@rjurney Mehrfachvererbung ist auch äußerst komplex und nicht nur etwas, das Sie einfach hinzufügen, ohne über Konsequenzen, nachzudenken .

12749 war der jüngste Versuch, eine solche Funktionalität hinzuzufügen – letztendlich abgelehnt, weil zuerst andere Arbeiten zu erledigen sind.

Es wird viel am Builder gearbeitet, einschließlich der Aktivierung von Client-gesteuerten Builds, die dies ziemlich öffnen können.

Dockerfiles mit einfacher Vererbung funktionieren für die (überwiegende) Mehrheit der Anwendungsfälle, daher besteht keine Eile, dies zu verbessern. Es muss richtig und bewusst gemacht werden.
Und basierend auf Ihren obigen Kommentaren würde ich sagen, dass Sie eigentlich keine Mehrfachvererbung benötigen, sondern nur eine Möglichkeit, ein Basis-Image anzugeben, mit dem das Dockerfile ausgeführt wird, ohne den vorhandenen Code zu duplizieren.

Das würde meine Bedürfnisse befriedigen, ja. In der Lage sein, einige Eigenschaften des zu ändern
Kette von Dockerfiles.

Ok, es freut mich zu hören, dass Sie darüber informiert sind. Danke für Ihre Geduld :)

Am Mittwoch, den 9. Dezember 2015 um 9:59 Uhr schrieb Brian Goff [email protected] :

@rjurney https://github.com/rjurney Mehrfachvererbung ist auch
extrem komplex und nicht nur etwas, das man einfach ohne nachzudenken hinzufügt
für Konsequenzen, Eckfälle und Inkompatibilitäten.

12749 https://github.com/docker/docker/pull/12749 war das neueste

Versuch, eine solche Funktionalität hinzuzufügen - wurde letztendlich abgelehnt, weil es
andere Arbeiten, die zuerst erledigt werden müssen.
Es wird viel am Builder gearbeitet, einschließlich der Aktivierung
Client-gesteuerte Builds, die dies ziemlich öffnen können.

Dockerfiles mit einfacher Vererbung funktionieren für die (überwiegende) Mehrheit der Anwendungsfälle,
Daher besteht keine Eile, dies zu verbessern. Es muss richtig gemacht werden und
bewusst.
Und basierend auf Ihren obigen Kommentaren würde ich sagen, dass Sie nicht wirklich mehrere brauchen
Vererbung, nur eine Möglichkeit, ein Basis-Image anzugeben, auf dem das Dockerfile ausgeführt wird
gegen, ohne den vorhandenen Code zu duplizieren.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/3378#issuecomment -163340165.

Russell Jurney twitter.com/rjurney-russell. [email protected] relato.io

@rjurney Woher bekommen Sie Ihre Informationen. Meines Wissens hat Java nie mehrfache Vererbung gehabt und wird es auch nie. Das gilt sicher auch für viele Sprachen. Viele halten die Mehrfachvererbung für äußerst schädlich, da sie zu fast unmöglich vorhersehbarem Code führen kann. Das gleiche würde für einen Docker-Container gelten.

Was wir für Docker aus meiner Sicht brauchen, ist nicht das Konzept der Mehrfachvererbung, sondern das Konzept eines Include oder externer Abhängigkeiten. zB Sie können Container zur Laufzeit mounten. Was wirklich gebraucht wird, ist ein Weg zum Äquivalent mit Bildern. So könnten Sie beispielsweise ein Image haben, das auf Fedora 22 basiert, und ein Oracle-Image mounten, um Datenbankfunktionen hinzuzufügen.

Dies kann beim Ausführen von Containern recht erfolgreich durchgeführt werden, es gibt jedoch keine Syntax, um dies mit Bildern anzugeben. Bis zur Laufzeit gibt es also keine Möglichkeit, dass Docker von diesen Abhängigkeiten erfahren oder sie für Sie verwalten kann.

Bitte beachten Sie, dass ich Mehrfachvererbung und Zusammensetzung erwähnt habe.
Komposition ist definitiv der bevorzugte Weg, dies zu tun.

Ich stimme allem anderen zu, was Sie gesagt haben, also +1.

Am Mittwoch, 9. Dezember 2015, Bill C Riemers [email protected]
schrieb:

@rjurney https://github.com/rjurney Woher bekommen Sie Ihre Informationen.
Meines Wissens hat Java nie mehrfache Vererbung gehabt und wird es auch nie.
Das gilt sicher auch für viele Sprachen. Viele betrachten mehrere
Vererbung äußerst schädlich, da es fast unmöglich sein kann,
vorhersehbarer Code. Das gleiche würde für einen Docker-Container gelten.

Was wir für Docker aus meiner Sicht brauchen, ist nicht das Konzept von Multiple
Vererbung, sondern das Konzept eines Include oder externe Abhängigkeiten. z.B
Sie können Container zur Laufzeit mounten. Was wirklich gebraucht wird, ist ein Weg, um
das Äquivalent mit Bildern. So könntest du zum Beispiel ein Bild haben, das
wurde als auf Fedora 22 basierend definiert und mounte ein Orakel-Image zum Hinzufügen
Datenbankfunktionalität.

Dies kann beim Ausführen von Containern recht erfolgreich durchgeführt werden, aber es gibt
nur keine Syntax für die Angabe mit Bildern. Also bis zur Laufzeit gibt es kein
wie Docker von diesen Abhängigkeiten erfahren oder sie trotzdem verwalten kann
Sie.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/3378#issuecomment -163351035.

Russell Jurney twitter.com/rjurney-russell. [email protected] relato.io

Ich werde danach die Klappe halten, aber ich habe diese Schimpfworte aus Versehen in die oben genannte Pull-Anfrage anstelle dieses Tickets eingefügt. Also stelle ich es hier ein.

Jemand wird das bauen. Wenn Sie einen Pull, der INCLUDE hinzufügt, nicht akzeptieren, wird diese Funktion verzögert und externalisiert. Dies sollte hier die Entscheidungsgrundlage sein: Soll dies Inside Docker oder Outside Docker sein?

Ein Beispiel fällt mir ein. In Apache Pig hat das Team die Entscheidung getroffen, trotz vieler Anfragen keine Schleifen einzuschließen, da entschieden wurde, dass Pig großartig für DAG-Datenflüsse sein sollte, und das war's. Stattdessen wurde eine Integration zum Skripten von Pig-Skripten erstellt, sodass Sie Skripte aus jeder JVM-Sprache durchlaufen können. Beachten Sie, dass dies eine bewusste Entscheidung war und Alternativen verfolgt wurden. Dies ist meiner Meinung nach der Modellprozess.

Ein anderes Pig-Beispiel fällt mir ein... Pig-Makros. Sie existierten nicht und waren "un Pig", bis jemand (ok, ich) einen Thread darüber startete, wie unglaublich hässlich ihr großes Pig-Projekt war und dass es keine Möglichkeit gab, dieses Problem zu beheben, ohne Pig von einem externen Tool zu generieren, das war unerwünscht. Viele Leute stimmten zu und das Pig-Team fügte Makros hinzu. Makros machen sauberes Schwein möglich, und die Gemeinschaft profitierte.

Ich schlage vor, dass Sie die Entscheidung direkt ansprechen und eine Diskussion darüber führen, die hier noch nicht stattgefunden hat und aus Gründen der Auffindbarkeit wahrscheinlich hierher gehört. Dies wird existieren. Das Duplizieren von Skripten in domänenspezifischen Sprachen ist schrecklich. Das Volk wird es fordern. Wird sich diese Funktion innerhalb von Docker oder außerhalb von Docker befinden? Wie werden Sie dieses Verhalten außerhalb von Docker ermöglichen?

Tut mir leid, mir fehlt wahrscheinlich viel Kontext auf der Mailingliste, aber als neuer Docker-Benutzer ... bin ich sehr zögerlich, viel mit Docker zu tun, ohne die Möglichkeit, Dockerfiles aus vorhandenen Rezepten zu erstellen. Ich bin mit Pig diese Straße entlang gegangen, und es hat mich fast umgebracht. Ich denke, viele Menschen werden so empfinden.

Falls es jemanden interessiert...

Die halb übernommene Präsentation über Schleifen und Makros in Pig: http://wiki.apache.org/pig/TuringCompletePig
Schweinemakro JIRA: https://issues.apache.org/jira/browse/PIG-1793
API-Schnittstelle zu Pig JIRA: https://issues.apache.org/jira/browse/PIG-1333
Eine, die komplett abgelehnt wurde, um Apache Hive zu respektieren ... SQL zu Pig hinzufügen: https://issues.apache.org/jira/browse/PIG-824

Schließlich hatte ich eine Idee, die diese Änderung leicht machen könnte ... Was ist, wenn INCLUDE-Dateien nicht vererbt werden können? dh Sie würden Einwände vermeiden, indem Sie die Dinge super einfach halten. Behandeln Sie den Rest später, wenn Sie mehr erfahren. Es könnte zum Beispiel ein einfaches Dockerfile geben, das die Pre-Reqs und Binärdateien installiert und Daemons für MySQL auf Ubuntu einrichtet. Bei Bedarf kann dies nach Version von Ubuntu und MySQL versioniert werden. Ich persönlich werde ein Dienstprogramm hacken, um diese einfachen INCLUDEs auszuführen, und es verwenden, um meine Dockerfiles auf diese Weise zu organisieren. Ich kann es kaum erwarten, meinen Code zu bestellen und wiederzuverwenden.

+1 für die INCLUDE-Idee. Obwohl ich glaube, dass das Verbot der Vererbung das Problem nur verschieben wird, da Sie jetzt das Mainstream-Image ändern können, von dem Sie erben, aber nicht die anderen Images, die Sie einschließen. Grundsätzlich wäre es sinnvoll, wenn Sie ein Image als "includable" angeben könnten, da es keine Betriebssysteminhalte liefert, die vorhandenes Basis-Image beschädigen könnten. Dieses Flag müsste vom Docker-Build-Prozess gesetzt werden und würde verhindern, dass nicht ausreichend gekennzeichnete Bilder eingeschlossen werden. Und ich meine, seien wir ehrlich. Wenn Sie mit Dockerfiles spielen, sind Sie wahrscheinlich keine Person, die seinen Computer am ersten Tag sieht, also würde ich glauben, dass es zwar sinnvoll ist, den Endbenutzer von Docker daran zu hindern, dumme Dinge zu tun, aber es sollte ein bisschen mehr geben Freiheit für die Jungs, die diese Bilder tatsächlich erschaffen. Und ich meine im Ernst, in der Lage zu sein, ein Basis-Image auszuwählen und alles einzubeziehen, was ich möchte, um meine App bereitzustellen, wäre verdammt großartig.

+1 für EINSCHLIESSEN. Ich brauche einfach Nginx- und SSH-Image in einem kombiniert. Warum muss das so schwer sein?

Die Vorstellung, dass dies nicht erforderlich ist, ist ehrlich gesagt verwirrend
unaufrichtig. Die meisten Benutzer werden dies verwenden, wenn es erstellt wurde. "ssh hinzufügen zu
ubuntu" und "nginx zu ubuntu hinzufügen" sind ziemlich häufige Aufgaben, die jeder
muss nicht wiederholt werden. Was Docker HQ wirklich zu sagen scheint, ist,
„Natürlich nötig, aber wir denken, dass es zu hässlich wird. Also tun wir so, als ob.“ Es
wäre besser, wenn du das ehrlich und offen sagen könntest.
Tut mir leid, wenn ich launisch bin.

Am Samstag, 23. Januar 2016 um 18:22 Uhr schrieb Vazy [email protected] :

+1 für EINSCHLIESSEN. Ich brauche einfach Nginx- und SSH-Image in einem kombiniert. Warum
muss das so schwer sein?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/3378#issuecomment -174243875.

Russell Jurney twitter.com/rjurney-russell. [email protected] relato.io

@rjurney warten wir auf das Build-Spin-Out; denn auf diese Weise gibt es mehr als eine Möglichkeit, Bilder zu erstellen (und daher könnte ein benutzerdefinierter Builder erscheinen, der dies tut). Einer der Gründe, warum Docker-Maintainer (die für Docker arbeiten oder nicht arbeiten) fröhlich sind, ist, dass dies die Komplexität erhöhen würde, wo wir Flexibilität und Einfachheit hinzufügen möchten. Durch das Extrahieren des Builders haben wir eine bessere Trennung der Bedenken (zwischen dem Erstellen von Images und deren Ausführung) und viele Anwendungsfälle werden in benutzerdefinierten Buildern freier implementiert.

Auch hier, verdrängst du das aus dem Projekt? Benutzerdefinierte Sounds... nicht
die standardmäßige, enthaltene Weise. In der Tat sind Einschlüsse ein einfaches Bedürfnis, das
fast jeder hat. Sich zu wiederholen ist komplex. Nur Vererbung ist
Komplexität. Beinhaltet auf einfachste Weise ein Bedürfnis, das jeder hat
möglich.

Am Sonntag, 24. Januar 2016, Vincent Demeester [email protected]
schrieb:

@rjurney https://github.com/rjurney warten wir auf das Build-Spin-Out ;
denn auf diese Weise gibt es mehr als eine Möglichkeit, Bilder zu erstellen (und somit
ein benutzerdefinierter Builder könnte erscheinen, der dies tut). Einer der Gründe Docker
Betreuer (die für Docker arbeiten oder nicht arbeiten) sind munter damit, ist
weil es die Komplexität erhöhen würde, wo wir Flexibilität hinzufügen möchten und
Einfachheit. Durch das Extrahieren des Builders haben wir eine bessere Trennung von
Bedenken (zwischen dem Erstellen und Ausführen von Bildern) und vielen Anwendungsfällen
wird in benutzerdefinierten Buildern freier implementiert.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/3378#issuecomment -174423973.

Russell Jurney twitter.com/rjurney-russell. [email protected] relato.io

+1, das Kombinieren von Bildern wäre äußerst nützlich. Stellen Sie sich einen (Gott bewahre) C++-Anwendungsfall vor. Ich baue ein Imagine mit Boost, ein anderes mit beispielsweise Qt, alle mit demselben Compiler usw. Sagen wir nun, ich möchte eine App sowohl mit Boost als auch mit Qt erstellen, ich muss nur die beiden kombinieren und schon ist eine Entwicklungsumgebung fertig. Dies wäre unglaublich nützlich.

Ich persönlich halte dieses Thema für zu wichtig, um es nicht anzugehen. Davon abgesehen müssen wir uns ein gutes Verständnis der Probleme und des Umfangs verschaffen, unabhängig davon, wo sie implementiert werden.

Ich sehe diese Probleme also, die durch das Zusammenführen entstehen.

1. Umgang mit Zusammenführungskonflikten.
2. Auflösen verschiedener Basen (Ubuntu und CentOS).

Beim ersten denke ich, ist die einfache Antwort nicht. Für mich klingt es zu kompliziert und potenziell problematisch und würde eine Reihe von Tools erfordern, um es zu lösen, und es könnte immer noch zu magisch sein. Wenn dies also hinzugefügt würde, sollten Zusammenführungskonflikte einfach fehlschlagen. Ich nehme an, es könnte später noch einmal besucht werden, aber das scheint mehr Ärger zu sein, als es wert ist.

Im zweiten Fall scheint es, als könnten Sie eine Einschränkung hinzufügen, dass sie einige Basisschichten teilen. Jetzt stellt sich die Frage, wie viel ist genug. Ich denke, die richtige Antwort beim Start wäre, dass die beiden Bilder, die zusammengeführt werden, dasselbe FROM Bild haben müssen. Möglicherweise müssen hier mehr Einschränkungen gelten, aber es ist mir nicht klar, dass diese Fälle nicht unter Problem 1 fallen würden, die durch einfaches Ablehnen gelöst wurden.

Gibt es noch andere Probleme, die ich hier übersehe?

Ich denke, es sollte keinen Versuch geben, zusammenzufügen... Ich kann nicht sehen, dass das passiert

Ein realistischere Ansatz könnte eine Templat Art der Lösung sein, das heißt , damit INCLUDE ein Dockerfile _fragment_ (das keines hat FROM Klausel, nur eine Liste von Befehlen) zu einem echten Dockerfile ... des Fragmente können geteilt, wiederverwendet und gegen jedes kompatible Basis-Image Dockerfile eingebunden werden

http://docktitude.io

Ich bin völlig neu bei Docker und lerne bescheiden. Aber ich dachte, der Hauptpunkt von Docker war es, sehr kleine _wiederverwendbare_ Anwendungen zu erstellen, um sie später auf beliebige Weise zu großartigen großen Endanwendungen wie in einer Web-App zu kombinieren. Wenn dem so ist, ist IMHO eine Anweisung wie INCLUDE obligatorisch.

@jmcejuela in vielen Fällen besteht "Wiederverwendung" darin, Bilder für einen bestimmten Dienst zu erstellen und diese Bilder/Container zu kombinieren, um Ihre Anwendung zu bilden. Die einzelnen Komponenten Ihrer Anwendung sind wiederverwendbar (evtl. unterscheidet sich nur die Konfiguration des Containers), aber die Art und Weise, wie Sie sie kombinieren, bildet die eigentliche Anwendung.

@thaJeztah Ich verstehe, danke.

Aber um es konkret zu machen, wie die Leute zuvor gepostet haben, sagen wir, ich baue eine Web-App, die eine Scala-Anwendung ausführt (image A ), dann den Webserver mit nginx (image B ), dann habe ssh (Bild C ) und benötigen eine zusätzliche Python-Anwendung (Bild D ). Angenommen, ich habe jeweils 4 Dockerfiles erstellt. Wie kombiniere ich sie mit Docker, um meine endgültige Web-App zu erstellen (Bild E ?)

Ich brauche nur eine einfache Möglichkeit, dies zu tun. Ich interessiere mich nicht für philosophische Streitigkeiten über Mehrfachvererbung, einschließen oder nicht, komponieren oder nicht usw. Obwohl ich sicherlich nicht kopieren und einfügen möchte, wie es zuvor vorgeschlagen wurde.

Vielen Dank für deine Zeit. Ich lerne noch Docker.

@jmcejuela Sie würden die _images_ nicht kombinieren, Sie würden sie als separate Container ausführen und sie zusammenarbeiten lassen, um die Anwendung zu bilden. Sie können dies mit Docker Compose tun, mit dem Sie Ihren "Stack" definieren können. Siehe zum Beispiel https://github.com/docker/example-voting-app/blob/master/docker-compose.yml (und die README; https://github.com/docker/example-voting-app/ blob/master/README.md)

Für den "ssh"-Teil hängt es wirklich davon ab, wofür Sie es verwenden möchten; insgesamt werden Container als "unveränderlich" betrachtet, Sie werden also nicht per SSH in einen Container einsteigen und ihn ändern, sondern einen neuen Container starten, um den alten zu ersetzen; Daten, die über den Lebenszyklus eines Containers hinaus bestehen bleiben müssen, werden dann in einem Volume gespeichert, damit der neue Container diese Dateien verwenden kann.

@jmcejuela Docker Builder akzeptiert Dockerfile-Inhalte auf STDIN, also könnte man "relativ" leicht einen generieren? Wenn ein Kontext übergeben werden muss, sollte alles getarnt und in docker build eingespeist werden. Meiner Erfahrung nach ist dies der einfachste Weg, um eine Komposition zu erhalten.

Ich entwickle (und spiele damit) einen Ansatz, der auf dem obigen Konzept aufbaut. Eine nodejs-Anwendung bereitet eine TAR-Datei im Speicher vor (mit Dockerfile und hinzugefügten Dateien) und legt sie in STDOUT ab. Der STDOUT wird in docker build . Composable Parts werden versioniert, getestet und als NPM-Module freigegeben. Ich habe ein sehr kurzes Beispiel erstellt, das ein Testbild für crond demonstriert - http://pastebin.com/UqJYvxUR

Danke @thaJeztah Am Ende brauche ich nur eine einzige Datei, die meine Co-Entwickler ausführen können, um den gesamten Dev-Stack zu haben und ihn dann bei Bedarf auch auf Prod ausführen zu können. Ich werde mir Docker Compose genauer ansehen.

Außerdem wurde vor langer Zeit INCLUDE vorgeschlagen ( https://github.com/docker/docker/issues/735 ).

@jmcejuela Tatsache ist, dass die meisten Docker-Benutzer ssh installieren und verwenden, um Container

Nur wenn du es falsch machst, den Befehl docker exec gibt es schon eine ganze Weile und ich habe ssh seitdem nie mehr gebraucht...

@anentropic Das gilt nur, wenn Sie einfache Dienste ohne Abhängigkeiten bereitstellen. Wenn Sie eine komplexe Kette von Abhängigkeiten für einen Dienst haben, beispielsweise alles, was mit maschinellem Lernen zu tun hat, duplizieren Sie Code, um Dienste bereitzustellen. Und es gibt keinen triftigen Grund, das zu tun. Nur weil Docker eine domänenspezifische Sprache ist, bedeutet das nicht, dass der Großteil des Wissens über Programmiersprachen weggeworfen wird und keine der alten Lektionen zutrifft. Die Vernunft muss immer noch eine Rolle spielen. Das Kopieren und Einfügen von Rezepten ist Wahnsinn.

Es gilt auch nur, wenn Sie das Weltbild des 'Single Service' abonnieren, das nicht allen Docker-Benutzern entspricht.

@anentropic Laut der Docker- Roadmap kann die Bereitstellung von Containern durch docker exec ebenso falsch sein.

PS Die rkt- Engine hat v1.0 erreicht.

@rjurney , :100:

Mehrfachvererbung, ob geliebt oder gehasst, ist ein komplexes Merkmal und wird zweifellos auf Widerstand stoßen. Include verwandelt Dockerfiles von einem Build-Rezept in eine Sprache mit schwer zu lösenden Pfadproblemen.

Was wäre, wenn wir das Problem anders betrachten. Was wäre, wenn wir in der Lage wären, " ADD / COPY " Dateien aus einem anderen Docker-Image in ein zu erstellendes Image auszuwählen. Auf diese Weise kann man von der Wiederverwendung von Funktionen profitieren und Codeduplizierung vermeiden. Da wir FROM mehrmals in einem Bild verwenden, sondern nur Binärdateien explizit kopieren, sollte sich dies auf eine genau definierte Weise verhalten, und wenn dies nicht der Fall ist, ist dies ein Fehler. Da dies mit Docker-Images funktioniert und Registrierungen als Lösung anstelle eines neuen Suchpfads nutzen kann, hoffe ich, dass dies ein vernünftiger Vorschlag ist. Ein zusätzlicher Bonus ist, dass wir denselben Code nicht mehrmals wiederholen müssen. Außerdem konnte hoffentlich ein massiver Wechsel beim Bauherrn vermieden werden. Die Gedanken?

Vielleicht wird dies an anderer Stelle vorgeschlagen, in diesem Fall wäre ein Link schön.

Hallo,
Welche Lösung auch immer gewählt wird, die Erstellung eines Bildes aus mehreren unabhängigen Quellen ist etwas, das mich sehr überrascht hat und das unmöglich ist.
Ich hätte gerne die Image-Vorbereitung übersprungen, da wir diesen Prozess zur Laufzeit ausführen können, sodass zur Laufzeit eine Reihe von Images bereitgestellt wird und nicht jedes Mal, wenn eine Abhängigkeit geändert wird, das Image neu erstellt werden muss.
Ich habe nach Alternativen gesucht, noch keine gültigen gefunden, das ist eine große Nutzungslücke.
Sieht mit ACI ganz einfach aus.
Danke!

:+1: würde gerne eine Lösung dafür finden und froh, dass zumindest darüber gesprochen wird. Auch wenn es erfordert, dass die Basisbilder gleich sind.

Es stellte sich heraus, dass das Kopieren von anderen Bildern an anderer Stelle vorgeschlagen wird. Dies ist das Problem ( https://github.com/docker/docker/issues/18596 ).

danke @jakirkham ..

+1 für Docker-Mehrfachvererbungsfunktion

BEARBEITEN:

Siehe auch: https://github.com/docker/docker/issues/13026

Ich denke, das Problem, auf das Sie stoßen, ist, dass die Unfähigkeit, Rezepte zu verfassen, keinen Sinn ergibt. Docker Compose eignet sich hervorragend für die Verwendung mehrerer Container in einer Anwendung. Docker Swarm eignet sich hervorragend, um dasselbe mit mehreren Knoten zu tun. Aber es gibt in vielen Fällen keine Möglichkeit, die Arbeit anderer auf Quellcode-Ebene einzubeziehen. Sie müssen es einmal erben oder neu erstellen, was einschränkend ist.

Am Fr, 18. März 2016 um 9:01 Uhr, Alvin Chevolleaux < [email protected]

schrieb:

Die Antwort von @thaJeztah https://github.com/thaJeztah ist sehr
aufschlussreich. Ich bin neu bei Docker und verstehe nicht, warum man nicht kombinieren kann
mehrere _images_ zusammen, aber Docker Compose scheint die Lösung zu sein
Kombinieren mehrerer _Container_ in einer Anwendung, die ich gesucht habe
Pro.

Ich glaube, das Problem für mich ist, dass ich zuerst dachte, ich hätte Docker verstanden
aber jetzt finde ich heraus, dass ich es nicht tue. Ich gehe zurück und mache noch mehr
lesen!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/3378#issuecomment -198426036

Russell Jurney twitter.com/rjurney-russell. [email protected] relato.io

@rjurney Ja, nachdem Sie sich Docker Compose etwas genauer angesehen haben, haben Sie debian:jessie aber ich möchte, dass mein Setup Centos-basiert ist. Wenn ich also ein bestimmtes Image verwenden möchte, muss ich den Rest des Setups akzeptieren oder die Quell-Dockerdatei kopieren und einfügen und mein eigenes Bild von Grund auf neu erstellen, es scheint keinen Mittelweg zu geben, in dem ich Bilder mischen und anpassen kann.

BEARBEITEN:
Nur zur Verdeutlichung verstehe ich, warum Sie Ubuntu- und Centos-basierte Images nicht miteinander mischen können, aber ich sehe nicht, warum Sie keine hierarchische Struktur haben könnten. Anstatt ein ganzes Bild herunterzuladen, laden Sie dann einfach die Änderungen von einem Bild zum anderen herunter.

INCLUDE wäre auch für mich wahnsinnig nützlich. Ohne es bleibt mir das Kopieren und Einfügen überlassen.

@RomanSaveljev Ich verstehe es nicht:

Laut der Docker- Roadmap kann die Bereitstellung von Containern durch docker exec ebenso falsch sein.

Es heißt nicht, dass docker exec veraltet sein wird. docker exec schon immer ein Debugging-Tool, und das sollte auch SSH in einem Docker-Container sein.

Ich komme mir blöd vor, daran teilzunehmen, aber was soll's... Ich schlage das noch einmal vor:

Warum vereinfachen wir das Problem nicht und implementieren zunächst INCLUDE, damit es keine Vererbung zulässt? Mit anderen Worten, Sie können nur Dateien einschließen, die kein FROM haben.

Das würde viele Anwendungsfälle bewältigen, und der Impuls würde von den Dateien ausgehen, die die Leute EINSCHLIESSEN, um auf jedem vernünftigen Betriebssystem zu arbeiten. uname existiert aus einem bestimmten Grund. Dies wäre ein erster Schritt, und Feedback zu dieser Implementierung würde helfen, alles Weitere zu definieren.

Das scheint eine leichte Entscheidung zu sein. Es wäre nicht viel Arbeit. Es wäre nicht komplex. Richtig?

@rjurney genau das macht https://github.com/docker/docker/pull/12749

@rjurney :

1. Wie kombiniere ich mehrere unabhängige Arbeiten?
2. Wie speichert man solche Zusammenstellungen effizient?
3. Wie kombiniere ich mehrere Arbeiten auf binärer Ebene, nicht auf Build-Ebene?

Es gibt wahrscheinlich noch mehr Elemente, die dieser Liste hinzugefügt werden könnten. Die INCLUDE-Lösung behandelt den ersten Aufzählungspunkt. Sobald dies eingerichtet ist, bildet dies einen Standardrahmen, in dem die Effizienz der Binärspeicherung für den Endbenutzer transparent verbessert werden könnte. Sobald dies eingerichtet ist, ist es sinnvoll, über Tools zu sprechen, die die gleichen Manipulationen an den Bilddateien direkt vornehmen. Allerdings ist dieser letzte Schritt natürlich sehr fragwürdig. Sobald Sie dies direkt auf den Bilddateien tun, besteht ein enormes Potenzial, einfach nur ein defektes Bild zu erhalten. Wenn jedoch davon ausgegangen wird, dass nur Power-User (diejenigen, die genau wissen, was sie tun) die dritte Option wählen, erscheint mir dies nicht wie eine unvernünftige Ergänzung ... schließlich.

Für diejenigen, die auf diese Weise etwas wirklich Zusammenstellbares wollen, können Sie sich Nix (NixOS, ein Linux-Distributions- und Paketverwaltungssystem) ansehen. Sie müssen lediglich Ihre gesamte Software, die normalerweise aus dem Quellcode erstellt wird, neu verpacken und alles aufgeben, was Sie über Linux zu wissen glaubten ;). Es ist ein schönes System, aber es erfordert viel Arbeit, da es nicht viele Leute benutzen, aber ich hoffe aufrichtig, dass es sich durchsetzt.

Wie andere bereits gesagt haben, geht es bei der Docker-Komposition eher um das Komponieren auf Dienstebene.

:+1: Es lohnt sich auf jeden Fall, über ein Composable-Modell nachzudenken - es wäre brillant, wenn Sie Verhalten in eine Dockerdatei importieren könnten. zum Beispiel habe ich jetzt einen Anwendungsfall, bei dem ich Apache Thrift in eine Reihe von sehr unterschiedlichen Build-Containern basierend auf Alpine-Linux einbinden möchte - einige bauen Java-Dienste, andere PHP und andere Node.

Es wäre gut, in der Lage zu sein, die Sparsamkeitsinstallation einzuschließen, anstatt sie zu kopieren und einzufügen - ich denke, ich kann leicht genug in ein Shell-Skript extrahieren und es HINZUFÜGEN und AUSFÜHREN.

Wie verwende ich also sowohl Ruby-2.3- als auch Java-8-Images? Sie verwenden dasselbe Debian-Jessie-Image wie die Basis (ich habe die Dockerfiles gelesen). Ich möchte nur die Befehle ausführen, die in beiden vorhanden sind. So wie es aussieht musste ich das Java Dockerfile in das Ruby Dockerfile kopieren/einfügen. Die App braucht beides, daran komme ich absolut nicht vorbei.

Ich habe die Gelegenheit genutzt, einige Dockerfile-Befehle zu entfernen, während ich sie einfügte - sie waren nicht schädlich, sondern einfach überflüssig, da die "Basis" Dockerfile (in die ich Befehle eingefügt habe) diese Schritte bereits ausgeführt hat. Ich kann also das Argument sehen, dass ich nicht wirklich ein "Ruby"- und "Java"-Image wollte, sondern ein drittes "Ruby + Java-All-in-One" -Image erstellte.

In diesem speziellen Fall scheinen die Befehle in diesen beiden Bildern jedoch vollständig kompatibel zu sein - wenn ich sie einfach verketten würde, sollten sie funktionieren. Es wäre nützlich, solche Umstände angeben zu können. Ich bin kein großer Fan des Copy/Paste-Ansatzes - in meinem Fall waren die Java- und Ruby-Dockerfiles einfach genug, aber einige Dockerfiles sind viel komplexer.

Jedoch an alle anderen wie mich, die diese Funktion haben möchten – ich sehe viele Situationen, in denen dies problematisch wäre. Es geht also nicht nur darum, die Möglichkeit bereitzustellen, "nginx" und dann "ssh" auf demselben Docker-Image auszuführen - die gleiche Funktionalität würde es Ihnen auch ermöglichen, "debian" und "centos" auszuführen, was definitiv kein brauchbares Bild. Wenn es jemals eingeführt wird, scheint es sich um eine experimentelle Option zu handeln, die standardmäßig deaktiviert ist und an die viele Warnungen angehängt sind.

Was auch immer die Schnittstelle zu dieser Funktion ist, es muss sehr klar sein, dass die Verantwortung für die richtigen wiederverwendbaren Verhaltensweisen (Befehlssätze) beim Dockerfile-Entwickler liegt.

EDIT: Ah, ich habe die Diskussion über INCLUDE verpasst.

Warum vereinfachen wir das Problem nicht und implementieren zunächst INCLUDE, damit es keine Vererbung zulässt? Mit anderen Worten, Sie können nur Dateien einschließen, die kein FROM haben.

Das würde viele Anwendungsfälle bewältigen, und der Impuls würde von den Dateien ausgehen, die die Leute EINSCHLIESSEN, um auf jedem vernünftigen Betriebssystem zu arbeiten. uname existiert aus einem bestimmten Grund. Dies wäre ein erster Schritt, und Feedback zu dieser Implementierung würde helfen, alles Weitere zu definieren.

Das scheint eine leichte Entscheidung zu sein. Es wäre nicht viel Arbeit. Es wäre nicht komplex. Richtig?

:+1:

@rjurney das ist im Grunde das, was #12749 tut

:+1: perfekt, bin gespannt, was das in seiner endgültigen Form leisten kann.

Sehr interessiert an diesem Konzept auch. Ein "INCLUDE"-Mechanismus ist eine sehr grobe Lösung, würde aber ehrlich gesagt einen ziemlich großen Fortschritt in der Wartbarkeit eines Satzes von Docker-Dateien darstellen.

Persönlich möchte ich nicht, dass es _fehlschlägt, wenn es auf ein FROM trifft, ich möchte, dass es das FROM _ignoriert_ und einfach den Rest der Befehle nacheinander anwendet.

Dass dies ohne FROM-Unterstützung noch nicht passiert ist, ist Open Source
Travestie.

Am Donnerstag, 19. Januar 2017 um 10:19 Uhr, Ken Williams [email protected]
schrieb:

Sehr interessiert an diesem Konzept auch. Ein "INCLUDE"-Mechanismus ist ein sehr
grobe Lösung, wäre aber ehrlich gesagt ein ziemlich großer Schritt vorwärts in
Wartbarkeit eines Satzes von Docker-Dateien.

Persönlich würde ich nicht wollen, dass es scheitert, wenn es auf ein FROM trifft, ich würde
Ich möchte, dass es das FROM
Reihenfolge.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/3378#issuecomment-273854850 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AACkpS8-EQ7r0BHid75rxeBDhOUDFRXlks5rT6kXgaJpZM4BWkJ9
.

--
Russell Jurney twitter.com/rjurney-russell. [email protected] relato.io

Hier ist die Sache, ich brauche nicht unbedingt Merge. Ich denke, viele der Probleme könnten mit einem Rebase gelöst werden. Mein normaler Anwendungsfall ist

A (ubuntu) -> B (zB nginx)
A (ubuntu) -> C (zB Knoten)

Und ich möchte ein kombiniertes B & C-Image. Normalerweise haben sie nichts miteinander zu tun, daher würde es ausreichen, einfach alle Diffs zwischen A und C auf B umzuwandeln

A -> B -> C'

Das scheint ein einfacher zu lösendes Problem zu sein.

@cloutiertyler Normalerweise benötigen Node.js-Anwendungen diese Funktion nicht, um mit Nginx zu arbeiten (meiner Meinung nach). Der Docker-Weg wäre zwei Container, einer für Nginx, der andere für Node. Wir konfigurieren den Node-Container so, dass er seinen Port nur dem Nginx-Container zugänglich macht, und lassen den Nginx-Container auf den öffentlichen Port (wie 80) hören. Gibt es einen Grund, warum sich Nginx im selben Container wie Node befinden muss?

Eine Docker Compose-Beispieldatei kann sein:

version: "2.1"

services:
  app: # Node.js application image
    build: .
  nginx: # Nginx container who can make request to app container
    image: nginx:1.10-alpine
    depends_on:
      - app
    ports:
      - "${PORT:-8080}:80" # public port, you may want PORT=80

@franklinyu Ich

Übrigens, es ist nicht gerade ein Rebasing, eröffnet aber viele Anwendungsfälle für Dockerfiles.
Dockerfile unterstützt jetzt mehrstufige Builds. Beispiel:

FROM golang AS myapp
COPY . /myapp
RUN cd /myapp && go build

FROM scratch
COPY --from=myapp /myapp /usr/bin/myapp

Sie können so viele Stufen haben, wie Sie möchten.
Der Parameter --from schaltet den Kontext grundsätzlich auf den angegebenen Build-Zielnamen um.
Wenn Sie docker build -t myapp . , stammt das resultierende Bild mit dem Namen myapp:latest aus der letzten Phase.
Sie können beispielsweise auch mit docker build --target=myapp bestimmte Stufen erstellen.

Es gibt noch ein paar andere sehr schöne Dockerfile-Verbesserungen in 17.05 (derzeit als RC1 erhältlich), probieren Sie es aus!

Das ist jetzt interessant! Ich wusste nicht, dass du das kannst. Ich muss das ausprobieren, um zu sehen, ob es meine allgemeinen Anwendungsfälle löst.

Obwohl dies eine großartige Funktion ist, löst sie nach dem Ausprobieren nicht wirklich mein häufigstes Problem. Ich bin heute gerade wieder darauf gestoßen.

Ich möchte ein Jenkins-Image, auf dem Docker installiert ist, damit ich aus dem Container heraus bauen kann. Tatsache ist, dass dies nicht möglich ist, ohne den Installationsprozess des einen oder anderen in meinem Dockerfile zu replizieren.

Dies ist ein Fall, in dem die blöden Argumente, dass dies nicht erforderlich ist, da jeder Container nur ein Dienst sein sollte, offensichtlich nicht zutreffen. Mein „One Service“ vereint die Funktionalität von Docker und Jenkins.

Tatsache ist, dass dies nicht möglich ist, ohne den Installationsprozess des einen oder anderen in meinem Dockerfile zu replizieren.

Sie möchten also zwei Dockerfiles in eine zerlegen, damit Sie nichts kopieren/einfügen müssen?

Kopieren/Einfügen ist in diesem Fall das Äquivalent zu Forking. Was ich tun möchte, ist, ein Dockerfile zu vermeiden, damit ich keine Fehler-/Sicherheitsverbesserungen oder andere Änderungen verpasse, wenn es sich später unweigerlich ändert.

Kann nicht einfach vorbeigehen. Suchen Sie nach einer Möglichkeit, Änderungen über eine lange Kette von Bildvererbungen (tiefer als 2) zu verteilen. Mehrstufig scheint nicht das zu sein, was ein Problem verdeutlicht. Eine Entität zu haben, die nur einen Block von Direktiven enthalten könnte, was es mir ermöglicht, sie zusammen mit der Basis-Image-Funktionalität in alle meine Erbbilder aufzunehmen, sieht nach einer rationalen Evolution aus.

Für diejenigen, die sich fragen, wie dies aus Docker-Perspektive richtig ist, nehmen Sie sich ein paar Minuten Zeit, um Folgendes zu überprüfen:
https://github.com/floydhub/dockerfiles

Hier erstellt er einen ganzen Baum von Dockerfiles. Wenn Sie den Baum nach unten gehen, finden Sie verschiedene Kombinationen von Abhängigkeiten, jede VON der Ebene darüber im Baum. Also, wenn du dem Baum gefolgt bist von
-ubuntu->common-deps->python3->deepLearningBase->pyTorch
und du wolltest wirklich

-ubuntu->common-deps->python3->deepLearningBase->pyTorch 
+
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow 

Alles, was Sie tun würden, ist, für beide einen Knoten (Ordner) unter deepLearningBase hinzuzufügen, z
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow-pyTorch

Jetzt müssen Sie noch eine Dockerdatei erstellen, die pyTorch- und TensorFlow-Dockerdateien kombiniert, aber
Der Schlüssel ist, dass diese Dateien SEHR EINFACH sind, nur ein paar Installationszeilen zusätzlich zu deepLearningBase.

Was also wirklich benötigt wird, sind mehrere größere Github-Repositorys wie dieses, für verschiedene "Welten", wie Webentwicklung, Deep Learning, eingebettete Software usw.

Dann würden Sie einfach dem Baum zu Ihrem gewünschten Build folgen, und wenn es noch niemand anders geschafft hat, fügen Sie einfach einen Knoten hinzu und kombinieren Sie 2 oder 3 apt-get-Zeilen und erstellen Sie Ihre neue Umgebung.

Das sieht nach dem Kompositionsstil "Wähle dein eigenes Abenteuer" aus. INCLUDE wäre viel einfacher. Verdammt, ich möchte nur ein angegebenes gcc Image mit nano damit ich nano nicht jedes Mal von apt-get installieren muss!

Ich stimme @chambm in seinem obigen Kommentar zu. Es gibt keinen Grund, warum dies in den meisten Fällen nicht möglich sein sollte (Konflikte sollten ziemlich selten sein, da sie bei manuell verwalteten Betriebssystemen der Fall sind).

Dies ist ein Anwendungsfall ganz ähnlich den @cloutiertyler kommentiert , in der weder @franklinyu ‚s Lösung , weder mehrstufiges Builds kommentiert von @ cpuguy83 gelten:

• A (debian:stretch-slim)
  
  
  
  • dockerfileAB -> B (python:slim-stretch)
  
  
  • dockerfileAC -> D ([build-stage] python-slim)
    
    
    
    
    
    • dockerfileDE -> E (ghdl/ext:vunit)
    
    
    
  
  
  • dockerfileAC -> C (ghdl/run:stretch-mcode)
  
  

wo:

• Die Schritte von A nach C sind genau die gleichen wie die von B nach D (dockerfileAC).
• Das Entwicklungsteam von B weiß nichts über C, D oder E.
• Das Entwicklerteam von C weiß nichts über B, D oder E.

Ein Benutzer, der D (und/oder E) erstellen möchte, muss Zugriff auf dockerfileAC haben, muss jedoch nicht über dockerfileAB Bescheid wissen. Daher muss der Benutzer eine Abhängigkeit (C) besser verstehen als die andere (B). Im Idealfall sollte es möglich sein, sich auf die Teams A und B zu verlassen und D einfach als A + (diff(B,A) + diff(C,A)) (Merge) oder A + diff(B,A) + diff(C,A) (Rebase) zu erstellen.

Da GHDL kein Webservice und VUnit kein Webclient ist, müssen beide Tools im selben Image/Container (E) installiert werden. Mehrstufige Builds sind nicht sinnvoll, da wir eine (wahrscheinlich unbekannte) Dockerdatei mit zwei FROM Labels erstellen müssen, es handelt sich nicht um eine einzelne Vorwärtskette.

Wenn Sie diesen Anwendungsfall ähnlich dem Zusammenführen/Rebase von zwei Git-Zweigen finden: manchmal gibt es keine Konflikte, manchmal sind die Konflikte leicht zu lösen, manchmal kann er überhaupt nicht zusammengeführt werden, weil es keinen gemeinsamen Verlauf gibt... Gibt es ein Tool, entweder offiziell oder extern, das bietet diese Funktion? Beachten Sie, dass es in Ordnung ist, wenn das Tool nur zwei Bilder in Git-Branches exportiert und tatsächlich Git für die Zusammenführung verwendet.

@1138-4EB Siehe https://github.com/moby/buildkit

Erstaunlich, dass dies immer noch ein Thema und Thema ist. Wie schwer ist es, "irgendwas Image einzubauen", dann beim Parsen die Basis auf Kompatibilität prüfen (in der FROM-Kette) und wenn ja, den Rest dieser Datei an dieser Stelle ausführen (als ob ich das Dockerfile aus dem Projekt kopiert hätte) und in meine eingefügt)?

Die ganze Entschuldigung "Menschen werden schlimme Dinge tun, die sie nicht wissen" ist in diesem Zusammenhang absurd. Das ist schon wahnsinnig komplex und deshalb brauchen wir es, um es zu vereinfachen.

@rainabba Dies ist ein völlig wenig hilfreicher Kommentar.
Es gibt im Wesentlichen zwei Gründe dafür, warum es auch nicht gemacht wird:

1. Es ist nicht so einfach
2. Niemand hat sich die Zeit für die Arbeit genommen.

In Wirklichkeit ist es normalerweise beides.

1. Es ist ein Parsing- und String-Ersetzungsproblem, das jeder neue Coder in nur 10 Minuten lösen könnte, wenn er wüsste, wo im Code. Ich sage nicht, dass es in allen Fällen verwendbar wäre, aber für die begrenzten Fälle, die hier immer wieder vorgeschlagen werden (wo Basen effektiv üblich sind), ist es ein toter Ringer.

2. Natürlich nicht, dieser Thread liefert ~102 Gründe, warum er nicht gemacht werden kann oder sollte, also warum sollte jemand daran denken, es trotzdem zu tun?

Andererseits dient mein Kommentar (wie SO viele andere hier auch) dazu, die Notwendigkeit aufzuzeigen und in der Hoffnung, entweder die behindernden Einstellungen zu beeinflussen oder zumindest als Mahnung zu dienen. Wenn das "völlig nicht hilfreich" ist, haben Sie gerade erklärt, warum dieses Problem (ignorierte Funktionsanfrage) immer noch vorhanden und aktiv ist und kein technisches ist.

Es ist viel mehr als das Parsen eines Strings.
Docker und das Dockerfile wird von Millionen von Menschen verwendet. Das Hinzufügen von APIs ist eine wichtige Sache ... selbst außerhalb davon besteht die zugrunde liegende Implementierung nicht darin, "eine Zeichenfolge zu analysieren".

Auf jeden Fall gibt es viele Vorschläge zur Lösung des Problems und dies ist ein sehr altes und abgeschlossenes Thema.

Ich denke, wenn Docker keine saubere Lösung für dieses Szenario findet, wird es wahrscheinlich durch ein beliebiges Tool ersetzt, das es herausfindet.

Mir ist aufgefallen, dass einer meiner Kollegen das folgende Muster verwendet, das eine anständige Problemumgehung sein könnte:

ARG from
FROM $from
... rest of dockerfile

Ich habe es jedoch nicht selbst ausprobiert, daher bin ich mir nicht sicher, wie es in der Praxis funktionieren würde, z. B. wie es sich beim Caching verhält usw.

Dies ist in der Tat ein sehr wichtiges Problem und wurde nicht richtig angegangen. Ich bin erstaunt, dass ein so großes Unternehmen wie Docker es noch nicht in Angriff genommen hat.

Nur meine zwei Cent... Ich lerne gerade mehr über Docker und denke, dass etwas wie INCLUDE sehr nützlich wäre. Ich mochte das Beispiel der Mehrfachvererbung oben und wollte die Kommentare zu möglichen Problemen und Konflikten damit adressieren.

Mehrfachvererbung ist in jeder Sprache, die sie unterstützt, schwierig, aber wenn ein Konflikt auftritt, liegt es in der Verantwortung des Docker-Dateierstellers, seine Vorgehensweise zu überdenken und von vorne zu beginnen. Docker sollte nur das Image erstellen und nicht versuchen zu beweisen, dass der Build keine Probleme hat.

@cosminonea

Ich denke, so etwas wie INCLUDE wäre sehr nützlich

Ich habe Unterstützung für Makros in https://github.com/larytet/dockerfile-generator/ Ich könnte auch "include" unterstützen.

Das würde den Sinn verfehlen. Das Ziel ist nicht, das Dockerfile einzuschließen
Definition. Das Ziel besteht darin, das Docker-Image einzuschließen. Das wird
erscheinen absurd, weil es mir aus dem Kopf geht:

von Fedora
ubuntu /ubuntu . einschließen
Debian einschließen /debian

Vernünftigerweise würde ich erwarten, dass dies mit dem Bild von Fedora beginnt.
Fügen Sie dann das Image für Ubuntu unter dem Ordner /ubuntu hinzu. Dann fügte die hinzu
Image für Debian unter /debian .

Das ist natürlich absurd, insofern möchte ich einen Haufen Betriebe mischen
Systeme in ein Bild? Aber ein nützlicheres Beispiel könnte sein:

von Fedora
plex einschließen /plex
Kommerzieller Entferner /plex/add-on/kommerzieller Entferner einschließen

In diesem Fall macht es jetzt mehr Sinn. Darin, wenn dies andere Bilder sind
Ich habe keine betriebsspezifischen Komponenten Ich habe eine einfache Möglichkeit, Dinge zu machen
modular.

Am Mittwoch, 8. August 2018 um 15:48 Uhr, Arkady Miasnikov [email protected]
schrieb:

Ich fühle mich wie INKLUSIVE
Ich habe Unterstützung für Makros in
https://github.com/larytet/dockerfile-generator/ Ich könnte "einschließen" hinzufügen
auch unterstützen.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/3378#issuecomment-411529506 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADBcWAtBDEp_LXpW3HUkHd3Pw5IVAXvqks5uO0ChgaJpZM4BWkJ9
.

Letzteres ist bereits möglich; COPY --from akzeptiert sowohl eine Build-Phase als auch ein Image, also zum Beispiel;

FROM busybox

COPY --from=alpine:latest / /
COPY --from=docker:latest /usr/local/bin/docker /usr/local/bin/

Bearbeiten; oder um das tatsächliche Beispiel zu nehmen;

FROM fedora

COPY --from=ubuntu:latest / /ubuntu/
COPY --from=debian:latest / /debian/

Exakt. Aus diesem Grund würde ich das Update 2017 in Betracht ziehen, das "COPY . hinzugefügt hat
--from" als die ursprüngliche Anfrage abgeschlossen haben. Es gibt absolut
Nichts mehr habe ich von diesem Ticket gesucht.

Ideen, die später aufkamen, wie das automatische Rebasing des Includes, wären
schöne Funktionen. Aber sie gehen über die ursprüngliche Anfrage hinaus.

Grüße,

Rechnung

Am Do, 9. August 2018 um 12:55, Sebastiaan van Stijn [email protected]
schrieb:

Letzteres ist bereits möglich; COPY --from akzeptiert beide a
Build-Stage oder ein Bild, also zum Beispiel;

VON busybox

KOPIE --from= alpin:neueste / /
COPY --from= docker :latest /usr/local/bin/docker /usr/local/bin/

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/3378#issuecomment-411824851 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADBcWPE738cs9xf3ZHSOaUd1foI1XVIQks5uPGmYgaJpZM4BWkJ9
.

@thaJeztah Wenn Sie dafür mehrstufige Builds verwenden, müssen Sie immer noch wissen, welche Dateien _genau_ von jedem Bild kopiert werden sollen; Das ist noch schwieriger zu verwalten, als den Setup-Code aus einem anderen Image zu kopieren und einzufügen.

Natürlich ist das Zusammenführen von Docker-Images nicht trivial. Da während des Builds beliebige Skripte ausgeführt werden können, widersetzt sich der Build-Prozess jedem allgemeinen Versuch einer automatischen Konflikterkennung; das halteproblem sagt hallo! Das Beste, was Sie tun können (abgesehen davon, die Möglichkeiten von Builds erheblich einzuschränken), ist eine genaue Semantik zu definieren: Sagen Sie, dass die letzten FROM / INCLUDE gewinnen (zB wenn sie dieselbe Datei "schreiben") oder bei einem Konflikt auf Dateisystemebene fehlschlagen oder ....

Das manchmal genannte Problem unterschiedlicher "Basis"-Images (Stretch vs. Ubuntu vs. Alpine vs. ...) ist jedoch _ist_ einfach: erfordert, dass der DAG von Image-Abhängigkeiten nicht nur eine einzige Quelle (das aktuelle Image) hat, sondern auch eine einzige Senke (der gemeinsame "Vorfahr" aller Bilder in der "Hierarchie").

Letztendlich würden Sie natürlich Müll-in-Garbage-out bekommen – ist das wirklich jemals anders?

FWIW, meine Anwendungsfälle sind:

1. Ausführen einer Tomcat-Webanwendung mit einer PostgreSQL-Datenbank und einem S3-Objektspeicher.
   Obwohl dies mit Docker Compose gelöst werden kann, kann ein einzelner Container besser sein.
2. Mehrsprachige Builds laufen in Docker-Containern (zB auf Jenkins, Circle CI, ...).
   Es gibt offizielle Images für die meisten gängigen Toolchains, aber einen einzelnen Container zu bekommen, der für mehr als eine Ausführung ausgestattet ist, wird genau in dem hier diskutierten Thema behandelt.

@reitzig , wenn Sie eine dynamische Generierung von Dockerfiles benötigen, schlage ich vor, eine domänenspezifische Sprache hinzuzufügen. Es gibt ein paar Beispiele, die mir bekannt sind

• https://github.com/avirshup/DockerMake
• http://docteurklein.github.io/2015/01/11/docker-auto-builds-and-me/
• https://blog.dockbit.com/templating-your-dockerfile-like-a-boss-2a84a67d28e9
• https://github.com/larytet/dockerfile-generator/

@reitzig Dies ist nicht die einzige Option. Die richtige Option besteht darin, INCLUDEs einzuschränken, um große Probleme zu vermeiden. INCLUDEs können nicht vererbt werden. Da ist es. Einfach. Trotzdem unglaublich nützlich.

Diese Funktionsanfrage ist beliebt, aber Docker ist kostenlos wie in Beer, aber keineswegs kostenlos wie in Freedom.

@rjurney Mit der Buildkit-Unterstützung seit 18.06 können Benutzer ihren eigenen Frontend-Parser für den Builder bereitstellen. Es gibt bereits einen offiziellen (von Docker Inc) experimentellen Dockerfile-Parser, der viele neue Funktionen enthält (Unterstützung für Geheimnisse für den Anfang).

Sie können natürlich auch Ihr eigenes "INCLUDE"-Verhalten in einem benutzerdefinierten Dockerfile-Frontend hinzufügen, oder Sie können etwas völlig anderes tun, das überhaupt nicht Dockerfile ist (es gibt ein Beispiel für buidpacks).

Um ein benutzerdefiniertes Frontend zu verwenden, müssen Sie Docker nur auf ein Image zeigen, das damit umgehen kann. Tun Sie dies als Kommentar in der ersten Zeile Ihres Dockerfiles (oder was auch immer es sein wird) syntax = myCustomFrontendImage

Weitere Details hier:
https://docs.docker.com/develop/develop-images/build_enhancements/#overriding -default-frontends

Wenn das Buildkit aktiviert ist, kann Docker alles erstellen, was Sie möchten (muss nicht einmal ein Dockerfile-Format sein) mit allen Funktionen, die Sie benötigen.

Diese Funktionsanfrage ist beliebt, aber Docker ist kostenlos wie in Beer, aber keineswegs kostenlos wie in Freedom.

So offtopic diese Anmerkung auch ist, ich denke, es sollte beachtet werden, dass Sie sich irren. Dank der Apache-Lizenzierung von Docker hat jeder die Freiheit, seinen eigenen Interpreter für Dockerfiles zu forken und zu entwickeln, der die hier entwickelten Funktionen bereitstellt. Wenn sie vorsichtig sind, sind die resultierenden Images mit vorhandenen Docker-Laufzeiten/-Tools kompatibel.
Den Betreuern des Docker-Projekts steht es natürlich ebenso frei, ein solches Feature nicht in ihren Fork (das Original?) einzubinden.

@reitzig Das ist offensichtlich nur bedeutungsloses Gerede, ohne tatsächlich auf freie Software zu verweisen. Moby ist natürlich kostenlose Software.

Ich wusste nicht, dass es jetzt Apache lizenziert ist. Ich entschuldige mich für die Bemerkung und
finde das super!

Russell Jurney @rjurney http://twitter.com/rjurney
russell. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

Am Mittwoch, 16. Januar 2019 um 4:17 Uhr schrieb Raphael R. [email protected] :

Diese Funktionsanfrage ist beliebt, aber Docker ist kostenlos wie in Beer, aber nicht von
jedes Mittel Frei wie in Freiheit.

So offtopic diese Notiz auch ist, ich denke, es sollte beachtet werden, dass Sie es sind
falsch. Dank der Apache-Lizenzierung von Docker hat jeder die Freiheit,
fork und entwickeln einen eigenen Interpreter für Dockerfiles, der die
hier entwickelte Funktionen. Wenn sie vorsichtig sind, werden die resultierenden Bilder
kompatibel mit bestehenden Docker-Laufzeiten/-Tools.
Den Betreuern des Docker-Projekts steht es natürlich ebenso frei, dies nicht zu tun
ein solches Feature in ihren Fork (das Original?) einbinden.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/3378#issuecomment-454758482 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AACkpdj_YO76ge79bm4G8FBmhOdbjhO9ks5vDxhvgaJpZM4BWkJ9
.

Es tut mir leid, ich habe nicht gut geschlafen und einen Fehler gemacht. Mein Kommentar steht.
Frei wie in Beer bedeutet Apache. Frei wie in Freiheit bedeutet gemeinschaftliche Kontrolle.
Ein Apache-Projekt oder eine andere Form der Governance.

Russell Jurney @rjurney http://twitter.com/rjurney
russell. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

Am Mittwoch, 16. Januar 2019 um 12:32 Uhr Russell Jurney [email protected]
schrieb:

Ich wusste nicht, dass es jetzt Apache lizenziert ist. Ich entschuldige mich für die Bemerkung und
finde das super!

Russell Jurney @rjurney http://twitter.com/rjurney
russell. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

Am Mittwoch, 16. Januar 2019 um 04:17 Uhr Raphael R. [email protected]
schrieb:

Diese Funktionsanfrage ist beliebt, aber Docker ist kostenlos wie in Beer, aber nicht von
jedes Mittel Frei wie in Freiheit.

So offtopic diese Notiz auch ist, ich denke, es sollte beachtet werden, dass Sie es sind
falsch. Dank der Apache-Lizenzierung von Docker hat jeder die Freiheit,
fork und entwickeln einen eigenen Interpreter für Dockerfiles, der die
hier entwickelte Funktionen. Wenn sie vorsichtig sind, werden die resultierenden Bilder
kompatibel mit bestehenden Docker-Laufzeiten/-Tools.
Den Betreuern des Docker-Projekts steht es natürlich ebenso frei
ein solches Feature nicht in ihren Fork (das Original?) einbinden.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/3378#issuecomment-454758482 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AACkpdj_YO76ge79bm4G8FBmhOdbjhO9ks5vDxhvgaJpZM4BWkJ9
.

Frei wie in Beer bedeutet Apache.

Verschiedener Meinung sein. Freeware kann proprietäre Software sein.

Frei wie in Freiheit bedeutet gemeinschaftliche Kontrolle.

Was ist Community-Kontrolle? Projekte einer Stiftung? Sie würden also VS Code, Atom Editor und Ubuntu als unfreie Software betrachten? Dann unterscheidet sich Ihre Definition deutlich von der von FSF, EFF und vielen anderen Organisationen vorgeschlagenen.

Ich stimme zu, dass Docker Inc. zu diesem Thema nicht aktiv mit der Community diskutiert, aber dies hat nichts mit "Frei wie in Freiheit" zu tun.

Sorry Leute, lasst uns diese Art von Diskussionen über den Issue Tracker nicht führen.

Ich stimme zu, dass Docker Inc. in dieser Angelegenheit nicht aktiv mit der Community diskutiert

Wir haben es möglich gemacht, jedes gewünschte Build-Format über docker build . Das "offizielle" Dockerfile-Format unterstützt diese Option nicht, aber das bedeutet nicht, dass docker build sie nicht verwenden kann.
Sehen Sie sich https://matt-rickard.com/building-a-new-dockerfile-frontend/ als Beispiel für die Erstellung eines benutzerdefinierten Frontends an, das mit docker build funktioniert.
Beachten Sie, dass dieses Frontend ein Beispiel dafür ist, wie Sie etwas völlig anderes als das Dockerfile-Format machen können, aber das ist nicht notwendig. Sie können das vorhandene Dockerfile-Format verwenden und Ihre eigenen Funktionen hinzufügen, wenn Sie möchten.

Was das Hinzufügen von etwas zum offiziellen Dockerfile-Format angeht.... Ich sage, Vorschläge sind immer willkommen, das Format wird in https://github.com/moby/buildkit gepflegt
Denken Sie jedoch daran, dass jede neue Funktion eine neue Belastung für die Wartung bedeutet, einschließlich der Einschränkung, was in Zukunft getan werden kann.

Ich denke, es ist wahrscheinlich, dass viele der Anwendungsfälle zum Kombinieren mehrerer Dockerfiles tatsächlich mit neuen Funktionen in Dockerfile gelöst werden können ... insbesondere die Möglichkeit, COPY --from und RUN --mount aus beliebigen Bildern zu erstellen.

Wenn dieses hypothetische INCLUDE nur die zusätzlichen Container als Impl-Detail erstellen könnte, ohne dass ich @#$% angeben müsste, würde dies die Frustration im Zusammenhang mit dem impliziten und zwielichtigen Verkaufsgespräch von Composable-Containern erheblich reduzieren. Ich möchte wirklich nur zurück zur Anwendung und zur Bereitstellung der Funktionalität. Entschuldigung für die schlechte Stimmung, aber ich bin Docker/Container-Noob und bin in die gleiche Verwirrung geraten, die viele andere Poster bereits zum Ausdruck gebracht haben.

Was wäre, wenn Sie dies tun könnten:

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   custom image (with both python and rust)
             \                                 /
              \----- rust:1.44-alpine3.12 ----/

_Beachten Sie, dass beide Bilder Nachkommen desselben Bildes sind. Das ist der Schlüssel!_

So einfach geht's:

FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

_Im Vergleich zur Verwendung der "COPY --from image"-Anweisung (mehrstufige Builds) müssen Sie sich keine Gedanken über die Implementierungsdetails machen (welche Dateien/Umgebungsvariablen kopiert werden)._

Wie es gerade aussieht, wenn Sie die Bilder kombinieren möchten

FROM alpine:3.12.0

# INCLUDE rust:1.44-alpine3.12
COPY --from=rust:1.44-alpine3.12 / /
ENV RUSTUP_HOME=/usr/local/rustup \
    CARGO_HOME=/usr/local/cargo \
    PATH=/usr/local/cargo/bin:$PATH \
    RUST_VERSION=1.44.1

# INCLUDE python:3.8.3-alpine3.12
COPY --from=python:3.8.3-alpine3.12 / /
ENV PATH /usr/local/bin:$PATH
ENV LANG C.UTF-8
ENV GPG_KEY E3FF2839C048B25C084DEBE9B26995E310250568
ENV PYTHON_VERSION 3.8.3
ENV PYTHON_PIP_VERSION 20.1.1
ENV PYTHON_GET_PIP_URL https://github.com/pypa/get-pip/raw/eff16c878c7fd6b688b9b4c4267695cf1a0bf01b/get-pip.py
ENV PYTHON_GET_PIP_SHA256 b3153ec0cf7b7bbf9556932aa37e4981c35dc2a2c501d70d91d2795aa532be79

_ENV-Anweisungen werden aus den Dockerfiles dieser Images kopiert._

Dies würde auch eine viel bessere Wiederverwendung von Containern ermöglichen und es extrem einfach machen, Dinge zusammenzufügen, deren Kompilierung oder Erstellung sonst ewig dauern könnte!

Bedenken Sie, dass bei diesem Ansatz ein Programm nur einmal pro Plattform-/Basis-Image-Version kompiliert werden muss - und es einfacher wiederzuverwenden ist, als es selbst zu implementieren. Denken Sie nur daran, wie oft das "Rad" in C++ aufgrund des Fehlens eines guten/universellen Paketmanagers neu implementiert wurde. Wollen wir, dass für Docker eine ähnliche Situation entsteht?

@bergkvist , siehe https://github.com/moby/moby/issues/3378#issuecomment -381449355 und https://github.com/moby/moby/issues/3378#issuecomment -381641675.

Ich habe das Gefühl, dass keine der von Ihnen vorgeschlagenen Lösungen dem Diagramm entspricht. Stattdessen tun Sie Folgendes:

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   \
             \                                   \
              \----- rust:1.44-alpine3.12 --------\ custom image 

Daher wird jede Datei, die in Rost geändert wurde, von Python überschrieben. Sie zu kombinieren, ohne sie übereinander zu kopieren, würde einige Zusammenführungen erfordern.

@eine Ja, bei Konflikten werden Dateien überschrieben. Das stimmt. Die Symmetrie der Figur wäre also ein Sonderfall, wenn sich keine (relevanten) Dateien überschneiden. Ihre Version der Figur ist allgemeiner.

Mein Punkt, wenn beide Bilder von demselben exakten Bild erben, ist, dass die Wahrscheinlichkeit kritischer Konflikte gering sein könnte.

Ich kann mir vorstellen, dass es zu Konflikten im Zusammenhang mit den Paketmanagerdateien kommen könnte. Wenn beide Images den Paketmanager verwendet haben, um verschiedene Dinge zu installieren. Ich bin mir nicht sicher, ob es noch andere "gewöhnliche Konflikte" gibt, die mit einem speziellen Fall behandelt werden könnten.

Das Zusammenführen von zwei Dateien ist alles andere als einfach. Ich denke, im Allgemeinen ist es vielleicht besser, einfach zu überschreiben, als zu versuchen, schlau zu sein. Zumindest ist es dann einfacher zu debuggen, wenn etwas nicht funktioniert.

Da ich hier vor 4 Tagen einen Kommentar abgegeben habe, habe ich beschlossen, Golang zu lernen und mir den Frontend-Code für den Moby/Buildkit-Code anzuschauen.

Ich habe jetzt ein benutzerdefiniertes Frontend erstellt, das INCLUDE-Anweisungen akzeptiert, wie ich oben besprochen habe.

#syntax=bergkvist/includeimage
FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

Um die benutzerdefinierte Syntax zu verwenden, denken Sie daran, beim Erstellen DOCKER_BUILDKIT=1 zu setzen.

DOCKER_BUILDKIT=1 docker build -t myimage .

Den Code gibt es hier: https://github.com/bergkvist/includeimage
Und Bild auf Docker Hub: https://hub.docker.com/r/bergkvist/includeimage