Wenn wir uns dafür entscheiden, bin ich eher für die RUNP-Option als für die
alle Container laufen im -privilegierten Modus.

Am Mittwoch, 18. September 2013 um 13:07, Benjamin Podszun
[email protected] schrieb :

Derzeit scheint es keine Möglichkeit zu geben, privilegierte Operationen außerhalb von auszuführen
docker run -privilegiert.

Das bedeutet, dass ich in einem Dockerfile nicht die gleichen Dinge tun kann. Meine letzten
Problem: Ich möchte Fuse (für encfs) in einem Container ausführen. Installation
Fuse ist schon ein Durcheinander mit Hacks und hässlichen Workarounds (siehe [1] und [2]),
weil mknod ohne einen privilegierten Build-Schritt fehlschlägt/nicht unterstützt wird.

Die einzige Problemumgehung besteht derzeit darin, die Installation manuell mit durchzuführen
run -privileged und erstellt ein neues 'fuse base image'. Was bedeutet, dass ich
kann nicht den gesamten Container beschreiben, von einem offiziellen Basisimage bis zum Ende,
in einem einzigen Dockerfile.

Ich würde daher vorschlagen, entweder hinzuzufügen

• ein Docker-Build -privilegiert
  dies sollte dasselbe tun wie run -privileged, dh alle entfernen
  Begrenzungen der Obergrenzen

oder

• ein RUNP-Befehl im Dockerfile
  das sollte .. naja .. RUN, aber mit _P_rivileges

Ich habe versucht, nach der Quelle zu suchen, aber ich bin mit go nutzlos und konnte keine finden
Anständiger Einstiegspunkt, um leider einen Machbarkeitsnachweis beizufügen. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514 (Kommentar) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub an
.

Victor VIEUX
http://vvieux.com

Tatsächlich müssen wir möglicherweise beides tun - dh RUNP + erfordert ein "-privilegiertes"
Flagge.

Wenn wir uns nur auf RUNP verlassen (ohne "-privileged"), dann würden wir
müssen sich fragen, wann wir einen Build erstellen "Ist dieser Build sicher?".
Wenn wir uns nur auf "-privilegierte" verlassen, verpassen wir die Informationen (im
Dockerfile), dass "diese Aktion erweiterte Berechtigungen erfordert".

Ich denke eine Kombination aus beidem ist der sicherste Weg.

Am Mittwoch, den 18. September 2013 um 04:07 Uhr, Benjamin Podszun
[email protected] schrieb :

Derzeit scheint es keine Möglichkeit zu geben, privilegierte Operationen außerhalb von auszuführen
docker run -privilegiert.

Das bedeutet, dass ich in einem Dockerfile nicht die gleichen Dinge tun kann. Meine letzten
Problem: Ich möchte Fuse (für encfs) in einem Container ausführen. Installation
Fuse ist schon ein Durcheinander mit Hacks und hässlichen Workarounds (siehe [1] und [2]),
weil mknod ohne einen privilegierten Build-Schritt fehlschlägt/nicht unterstützt wird.

Die einzige Problemumgehung besteht derzeit darin, die Installation manuell mit durchzuführen
run -privileged und erstellt ein neues 'fuse base image'. Was bedeutet, dass ich
kann nicht den gesamten Container beschreiben, von einem offiziellen Basisimage bis zum Ende,
in einem einzigen Dockerfile.

Ich würde daher vorschlagen, entweder hinzuzufügen

• ein Docker-Build -privilegiert
  dies sollte dasselbe tun wie run -privileged, dh alle entfernen
  Begrenzungen der Obergrenzen

oder

• ein RUNP-Befehl im Dockerfile
  das sollte .. naja .. RUN, aber mit _P_rivileges

Ich habe versucht, nach der Quelle zu suchen, aber ich bin mit go nutzlos und konnte keine finden
Anständiger Einstiegspunkt, um leider einen Machbarkeitsnachweis beizufügen. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514 (Kommentar) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub an
.

@jpetazzo https://twitter.com/jpetazzo
Neuester Blogbeitrag: http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

Klingt vernünftig. Für mich macht diese Funktion (in der Lage zu sein, Geräteknoten zu erstellen) die Möglichkeit, die Bereitstellung in Docker zu erstellen, aus oder unterbricht sie. Wenn ich helfen kann (meistens testen, habe ich versucht, die Quelle zu überprüfen, aber bisher gescheitert. Es scheint, dass die verfügbaren Befehle in einer Builddatei über Reflection gefunden werden, ich habe einen runp-Befehl hinzugefügt, der die config.privileged auf true setzt, aber bisher habe ich bin nicht in der Lage zu bauen und zu testen -> stecken geblieben) Ich würde gerne etwas Zeit investieren.

Ich würde vorschlagen RUNP + build -privileged .

_zündet einige Rauchzeichen an, um die Aufmerksamkeit von @shykes , @crosbymichael_ zu erregen

... Und dann müssen wir natürlich jemanden finden, der das umsetzt ☺
Wäre das etwas, das Sie ausprobieren möchten (natürlich mit entsprechender Anleitung und Feedback vom Kernteam) ?

Wenn der letzte Teil an mich gerichtet war: Klar, warum nicht. Ich spiele schon mit dem Go-Code herum (keine Sprache, mit der ich vertraut bin, aber siehe oben: Ich versuche sowieso herauszufinden, was los ist).

Mit ein paar Hinweisen / jemandem, der bei einigen Fragen anpingt, würde ich es auf jeden Fall versuchen.

Ich bin nicht auf RUNP oder Build-Privilegiert verkauft.

​

​Im Allgemeinen mag ich nichts, was verschiedene mögliche Builds derselben Eingabe einführt. Aus diesem Grund können Sie einem Build keine Argumente oder Umgebungsvariablen übergeben.

Insbesondere mag ich es nicht, überall Abhängigkeiten von "privilegiert" einzuführen, weil es eine Reihe von Fähigkeiten bezeichnet, die a) sehr groß und b) nicht klar spezifiziert oder definiert sind. Das ist als grober Mechanismus für Systemadministratoren in Ordnung, um die Sicherheit ganz oder gar zu umgehen - eine "Fluchtluke", wenn die standardmäßige Docker-Ausführungsumgebung nicht ausreicht. Es ist in dieser Hinsicht ähnlich zu bind-mounts und benutzerdefinierter lxc-conf.

—
@solomonstre
@getdocker

Am Fr, 20.09.2013 um 15:18 Uhr, Benjamin Podszun
[email protected] schrieb:

Wenn der letzte Teil an mich gerichtet war: Klar, warum nicht. Ich spiele schon mit dem Go-Code herum (keine Sprache, mit der ich vertraut bin, aber siehe oben: Ich versuche sowieso herauszufinden, was los ist).

Mit ein paar Hinweisen / jemandem, der bei einigen Fragen anpingt, würde ich es auf jeden Fall versuchen.

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

Nun, stimmen Sie zu, dass es möglich sein sollte, ein Docker-Image zu erstellen, das - zum Beispiel - Sicherung ausführt?
Dafür müssten wir mknod.

So wie ich es sehe, können diese Builds auf keinen Fall je nach Parameter unterschiedlich sein: Der Build wird funktionieren (Caps sind nicht / weniger eingeschränkt als jetzt) ​​oder fehlschlagen (Status Quo). Es besteht wenig bis gar kein Risiko, dass unterschiedliche "Versionen" derselben Build-Datei vorliegen, oder?

Ich beschäftige mich jetzt mit diesem Problem. Um das von mir benötigte Image zu erstellen, muss ich eine Reihe von run -privileged Schritten + einen commit Schritt ausführen, anstatt build ein Dockerfile zu erstellen. Idealerweise wäre es schön, die Schritte zur Image-Erstellung in einem Dockerfile auszudrücken.

Hat es auch mit mknod-Operationen zu tun?
Wenn Sie genau die Aktionen beschreiben könnten, die den privilegierten Modus erfordern in
Dein Fall wäre sehr hilfreich!
Vielen Dank,

Hey @jpetazzo , von der Mailingliste, hier ist das Problem, mit dem ich konfrontiert bin: https://groups.google.com/forum/#!topic/docker -user/1pFhqlfbqQI

Ich versuche, mount ein fs, das ich erstellt habe (erstellt, um aufs und etwas über das Journaling zu umgehen), innerhalb des Containers. Der spezifische Befehl, den ich ausführe, ist mount -o loop=/dev/loop0 /db/disk-image /home/db2inst1 , wobei /db/disk-image mit dd if=/dev/zero of=disk-image count=409600 und home/db2inst1 ist, wo ich versuche, db2 zu starten.

Wenn ich das richtig verstehe, brauchst du während des Installationsprozesses ein Nicht-AUFS-Verzeichnis – oder besser etwas, das O_DIRECT . Wenn dies der Fall ist, sollte Docker 0.7 das Problem lösen, da es ext4 (und Snapshots auf Blockebene) anstelle von AUFS verwendet.

Auch hierfür +1.

Die Installation von Paketen, die Änderungen an den Speichereinstellungen und der Kernelkonfiguration erfordern (zB Vertica DB, WebSphere MQ), kann nur im privilegierten Modus durchgeführt werden.

Versuchen wir, die Bedenken bezüglich des Ausführens / Erstellens mit "privilegiert" zu trennen: Es kann nur während des Builds erforderlich sein, nur während der Ausführung über docker run oder beides.

Es sollte möglich sein, einem Build zu erlauben, etwas zu tun, das etwas mehr Berechtigungen für einen Schritt (oder mehr) erfordert, wenn dies erforderlich ist. Ich brauchte dies für ein Projekt und musste die Hälfte eines Dockerfiles in ein Shell-Skript konvertieren, das den Build aufrief und die Dinge im privilegierten Modus weiter baute, daher wäre ein "privilegierter" Build nützlich.

Wir sollten jedoch nicht standardmäßig in den privilegierten Modus gehen, nur damit wir sysctl verwenden können, um einige Einstellungen zu ändern. Dies sollte über die Image-Konfiguration oder über Befehlszeilen-Argumente erfolgen, die an docker run .

Rechts. @orikremer , haben Sie Details zu den Parametern, die Vertica DB und WebSphere MQ zu ändern versuchten?

Wenn es sich um Dinge in /sys oder /proc handelt, könnte die beste Lösung darin bestehen, stattdessen ein Mock-up dort zu platzieren, anstatt in den privilegierten Modus zu wechseln (da die Änderungen sowieso nicht beibehalten werden).

Auf lange Sicht könnte ein Mock-Dateisystem die Änderung erfassen und in Dockerfile-Direktiven konvertieren, die der Laufzeit mitteilen, dass "hey, dieser Container muss so oder so optimiert werden".

@jpetazzo Es ist ein paar Tage her, seit ich das Bild erstellt habe. AFAIR Vertica beschwerte sich, dass es nicht genügend Speicher hat und beide versuchten, die maximale Anzahl geöffneter Dateien zu ändern.
Ich werde versuchen, das Image mit einem Dockerfile neu zu erstellen und Bericht zu erstatten.

Beachten Sie das Problem Nr. 2080, da es damit zusammenhängt.

@jpetazzo hat damit begonnen, das Image ohne -privileged neu zu erstellen. Bisher zwei Probleme:

• nice in der limit.conf: Vertica fügt "dbadmin - nice 0" zu /etc/security/limits.conf hinzu. Beim Versuch, zu diesem Benutzer zu wechseln, wenn er in einem nicht privilegierten Container ausgeführt wird, erhalte ich die Fehlermeldung "Sitzung konnte nicht geöffnet werden". In einem privilegierten Containerwechsel arbeitet der Benutzer ohne Fehler.
• max open files: da das im Container benötigte max höher war als das in host festgelegte, musste ich /etc/init/docker.conf auf dem Host ändern und "limit nofile" und dann ulimit -n im Container setzen. Ist das der richtige Ansatz?

Wenn Sie versuchen, zu diesem Benutzer zu wechseln,

Wie erfolgt der Wechsel? Ich verstehe nicht, wie -privileged beim Benutzerwechsel helfen würde; Vermutlich übersehe ich hier etwas :-)

max offene Dateien

Wenn ich das richtig verstehe, versucht das Vertical-Installationsprogramm, die maximale Anzahl geöffneter Dateien auf eine sehr hohe Zahl zu setzen, und das funktioniert nur, wenn Docker mit einer so hohen Zahl _oder_ mit dem -privileged Flag gestartet wurde; rechts?

Benutzerwechsel - su dbadmin schlägt mit diesem Fehler fehl.
Ich konnte reproduzieren durch:

• Ziehen Sie ein neues Image (centos-6.4-x86_64) und führen Sie es nicht privilegiert aus
• BenutzerTestbenutzer hinzufügen
• Bearbeiten Sie /etc/security/limits.conf, fügen Sie "testuser - nice 0" hinzu
• versuchen su testuser --> sollte mit "Konnte Sitzung nicht öffnen" fehlschlagen
  In einem -privilegierten Container funktioniert su testuser einwandfrei.

max offene Dateien - richtig. das Installationsprogramm versucht, eine höhere Zahl einzustellen, als der Host hat. Nur durch Erhöhen der Hosts-Einstellung oder Starten von -privileged funktioniert dies.

Ich habe es gerade mit folgendem Dockerfile versucht:

FROM ubuntu
RUN useradd testuser
RUN echo testuser - nice 0 > /etc/security/limits.conf
CMD su testuser

Und es funktioniert gut. Wie lautet der genaue Name des von Ihnen verwendeten Bildes?
(Ich habe es mit centos-6.4-x86_64 versucht, aber es sieht so aus, als könnte ich es nicht ziehen!)

@lukewpatterson Können Sie Laufen gebracht haben ?

@jpetazzo Ausführen dieser Docker-Datei

FROM backjlack/centos-6.4-x86_64
RUN useradd testuser
RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
RUN su testuser
RUN echo 'test' > ~/test.txt

gescheitert mit:

ori<strong i="10">@ubuntu</strong>:~/su_test$ sudo docker build .
Uploading context 10240 bytes
Step 1 : FROM backjlack/centos-6.4-x86_64
 ---> b1343935b9e5
Step 2 : RUN useradd testuser
 ---> Running in b41d9aa2be1b
 ---> 2ff05b54e806
Step 3 : RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
 ---> Running in e83291fafc66
 ---> 03b85baf140a
Step 4 : RUN su testuser
 ---> Running in c289f6e5f3f4
could not open session
Error build: The command [/bin/sh -c su testuser] returned a non-zero code: 1
The command [/bin/sh -c su testuser] returned a non-zero code: 1
ori<strong i="11">@ubuntu</strong>:~/su_test$

Ich habe das Debugging für das PAM-Modul aktiviert (indem ich debug zur Zeile pam_limits.so in /etc/pam.d/system-auth hinzugefügt habe), syslog installiert und versucht, su wieder, und das habe ich in /var/log/secure :

7. Okt. 14:12:23 8be1e7bc5590 su: pam_limits(su:session): Einstellungen aus '/etc/security/limits.conf' lesen
7. Okt. 14:12:23 8be1e7bc5590 su: pam_limits(su:session): process_limit: processing - nice 0 for USER
7. Okt. 14:12:23 8be1e7bc5590 su: pam_limits(su:session): Einstellungen aus '/etc/security/limits.d/90-nproc.conf' lesen
7. Okt. 14:12:23 8be1e7bc5590 su: pam_limits(su:session): process_limit: Verarbeitung von Soft-nproc 1024 für DEFAULT
7. Okt 14:12:23 8be1e7bc5590 su: pam_limits(su:session): Konnte Limit für 'nice' nicht setzen: Operation nicht erlaubt

Dann habe ich strace den su Prozess durchlaufen und festgestellt, dass der folgende Systemaufruf fehlgeschlagen ist:

setrlimit(RLIMIT_NICE, {rlim_cur=20, rlim_max=20}) = -1 EPERM (Operation not permitted)

Dies wiederum führt dazu, dass das Modul pam_limits einen Fehler meldet; und dies verhindert, dass su fortfährt.
Interessanterweise ist pam_limits Ubuntu standardmäßig nicht für su aktiviert; und selbst wenn Sie es aktivieren, schlägt der Aufruf von setrlimit fehl, aber su fortgesetzt und funktioniert trotzdem.
Es könnte mit dem Audit-Code zusammenhängen, ich bin mir nicht sicher.

Warum schlägt setrlimit fehl? Weil dem Container die sys_resource Funktion fehlt, die erforderlich ist, um jede Art von Limit zu erhöhen.

Ich denke, ich würde diese limits.conf Direktive einfach auskommentieren.
(Übrigens, es ist eine schlechte Praxis, Sachen direkt zu limits.conf hinzuzufügen; es sollte in eine separate Datei in limits.d , denke ich.)

Hinweis: Da Sie das Limit für die Anzahl der geöffneten Dateien für Docker bereits erhöht haben, können Sie auch das Limit für die maximale Priorität erhöhen; das sollte auch funktionieren!

Ich hoffe das hilft.

In diesem Dockerfile haben Sie die folgende Zeile für sich:

RUN su testuser

Dazu gibt es keinen entsprechenden Befehl (und es wird keine resultierende Shell auf nachfolgende RUN-Befehle angewendet), daher wäre ich nicht überrascht, wenn es wirklich fehlschlägt, eine Shell zu öffnen und nicht interaktiv zu sein, das Sinn macht (da docker build kein interaktiver Prozess ist). Ich habe gerade keine Zeit, dies zu bestätigen, aber es ist wahrscheinlich einen Versuch wert, wenn ein tatsächlicher Befehl an su .

@jpetazzo Danke für die ausführliche Beschreibung. Ich werde versuchen, die maximale Priorität für Docker zu erhöhen und sehen, ob das hilft.

(Übrigens, es ist eine schlechte Praxis, Sachen direkt zur limit.conf hinzuzufügen; ich denke, es sollte in eine separate Datei in limit.d gehen.)

Zugegeben, aber da dies der Vertica-Installationscode ist, der es dort ablegt, versuche ich, das zu umgehen.

@tianon Das gleiche passiert, wenn ich dies in einer interaktiven Shell (/bin/bash) ausführe.

Ich entschuldige mich, ich denke, es war trotzdem einen Versuch wert.

Der Punkt, dass diese Zeile im Dockerfile nicht viel Sinn macht, gilt jedoch immer noch. Sie wollten wahrscheinlich etwas Ähnliches (nachdem Sie die Grenzenprobleme herausgefunden haben):

RUN su testuser -c 'echo test > ~/test.txt'

@tianon du hast recht, es macht nicht viel sinn. Das war nur, um zu zeigen, dass die su selbst versagt.

Um wieder auf die ursprüngliche Diskussion: Ich glaube , es ist in Ordnung , von einem Standpunkt der Sicherheit zu ermöglichen (und nützlich!) setfcap und mknod Fähigkeiten in dem Build - Prozess (und wahrscheinlich auch in regelmäßigen Containern Ausführung als Gut). Sieht jemand ein Problem, das daraus resultieren könnte?

@jpetazzo Ganz im Gegenteil! Es würde viele Probleme lösen, auf die ich stoße. Ich denke, dies ist für Leute notwendig, die Docker-Container ausführen möchten, die sich eher wie eine echte Maschine verhalten/aussehen.

OK! Wenn das für Sie in Ordnung ist, schließe ich diese Ausgabe zugunsten von #2191, "Aktivieren Sie die mknod- und setfcap-Funktionen in allen Containern" dann :-)

Kennen wir solche Szenarien?

Am Sonntag, den 13. Oktober 2013 um 12:22 Uhr schrieb unclejack [email protected] :

2191 https://github.com/dotcloud/docker/issues/2191 löst das nicht

Problem für alle Szenarien, die docker build -privileged erfordern würden.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/dotcloud/docker/issues/1916#issuecomment -26224788
.

@jpetazzo https://twitter.com/jpetazzo
Neuester Blogbeitrag:
http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

@jpetazzo Dies ist erforderlich, wenn Sie ein Dockerfile verwenden möchten, um ein Betriebssystem-Image zu erstellen.

Ich habe meinen Kommentar beim Bearbeiten versehentlich gelöscht.

Bitte sehen Sie sich an, wie dies aussehen würde, ohne alles in einem Dockerfile zu tun:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh

build.sh

docker build -t mybuild .
docker run -i -t -privileged -cidfile mybuild.cid mybuild /root/build.sh
buildcid=`cat mybuild.cid`
rm mybuild.cid
docker commit $buildcid mybuild-final

Dies zwingt mich nur dazu, das Fehlen von runp im Dockerfile oder docker build -privileged umgehen, wodurch Dockerfiles nutzlos werden und ich ein Tool schreiben muss, um Dockerfile-ähnliche Funktionen zu duplizieren.

Offensichtlich wäre das Dockerfile mit runp oder docker build -privileged viel nützlicher:
runp-Beispiel:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
runp /root/build.sh

docker build -privileged Beispiel:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
run /root/build.sh

@unclejack : Entschuldigung, meine Frage war nicht genau genug!
Was ich meinte war "welche Berechtigung brauchst du genau (zusätzlich zu mknod und setfcap)?"

@jpetazzo Es ist schwer zu sagen, ich müsste dies irgendwie überprüfen, um herauszufinden, was benötigt wird. Mounten von Dateisystemen, Verwenden von Loopback-gemounteten Blockgeräten und ein paar anderen Dingen.

Beim Erstellen von Images gibt es mindestens drei separate Anforderungen: Berechtigungen, die während eines docker build erforderlich sind, Berechtigungen, die beim Ausführen eines Containers mit Docker erforderlich sind, und Laufzeitanforderungen für Prozesse während des Builds, der Ausführung oder beides (wie sysctls und andere) .

Ich denke, es wäre nützlich, docker build -privileged (oder runp , um den -privilegierten Modus nur für die Befehle zu verwenden, die ihn wirklich benötigen) zu haben.

Ah, Reittiere sind definitiv ein großes. Das ist ein sehr gültiger Anwendungsfall, und wir wollen sie _wahrscheinlich_ im allgemeinen Fall nicht zulassen. Ich öffne das Thema nochmal.

@jpetazzo RE: PAM-Modul (ich installiere auch Vertica) würden Sie vorschlagen, Docker neu zu kompilieren, nachdem Sie die sys_resource aus der lxc.cap.drop genommen haben?

Vielleicht können einige dieser Grenzen über die Datei docker.conf festgelegt werden?

Es sollte berücksichtigt werden, dass Docker selbst möglicherweise in einem begrenzten Satz von Funktionen ausgeführt wird, wodurch diese Berechtigungen für Docker möglicherweise nicht zum Delegieren an seine Container verfügbar sind. Dies gilt insbesondere für ein verschachteltes Docker-Szenario, das #2080 Land ausgeben sollte – dies könnte nicht privilegierte verschachtelte Docker ermöglichen.

Nichts, dass dies etwas ändert, außer dass Lösungen wie 'runp' oder '-priviledged' möglicherweise nicht in allen Docker-Umgebungen erfolgreich sind. Dies sollte beim Hinzufügen solcher Befehle und bei deren Dokumentation berücksichtigt werden.

@ramarnat @jpetazzo, nur um die Schleife bei der Vertica-Installation und dem netten Level-Problem zu schließen.
Ich habe versucht, das nette Limit in der docker.conf festzulegen, aber das hat bei mir nicht funktioniert und ich war gezwungen, die Bash privilegiert auszuführen und manuell zu installieren.

@orikremer @jpetazzo Ich konnte die Installation ausführen, indem ich sys_resource aus lxc_template.go entfernte und Docker neu kompilierte. Ich kann eine Pull-Anfrage stellen, aber ich warte, bis andere zu den Sicherheitsauswirkungen des Entfernens aus der lxc-Konfiguration Stellung nehmen.

@ramarnat : Je nach Szenario werden einige Leute denken, dass das Entfernen von sys_resource in Ordnung ist; für einige andere wird es ein Problem sein.

Eine Möglichkeit könnte sein, die Basislimits etwas höher zu erhöhen (Dateideskriptoren sind auch ein Problem für Elastic Search). Dies wäre so, als würde man behaupten, "eine minimale Docker-Laufzeit sollte in der Lage sein, 1.000.000 Dateideskriptoren zu verarbeiten". Wenn Docker das Limit beim Start nicht erhöhen kann, gibt es eine Warnung aus und fährt fort (wie bei der Speicher-/Swap-Controller-Gruppe).

Dies behebt jedoch nicht das Mount-/Loop-Szenario (ich schlafe immer noch auf diesem).

@jpetazzo bietet möglicherweise eine Möglichkeit, die hartcodierten Werte in lxc_template.go zu überschreiben. Es gibt bereits etwas für das Szenario mit der Befehlszeile -lxc_conf, aber es funktioniert nicht für die .drop-Natur dieser lxc-Konfigurationsdirektiven - ich habe es versucht!

Nun, das ist eine Möglichkeit, aber das ist auch ein guter Weg, um die zukünftige Kompatibilität zwischen verschiedenen Containerisierungssystemen zu unterbrechen :-) Wir werden sehen, ob wir nichts Besseres finden.

Könnten wir /dev/loop* im nicht-privilegierten Modus auf die Whitelist setzen? Ich nehme an, das Problem besteht darin, dass ich dadurch möglicherweise auf die in Schleife gemounteten Dateien anderer Container oder sogar auf die des Hosts zugreifen kann ...

@solomonstre
@Docker

Am Do, 17.10.2013 um 18:09 Uhr, Jérôme Petazzoni
[email protected] schrieb:

Nun, das ist eine Möglichkeit, aber das ist auch ein guter Weg, um die zukünftige Kompatibilität zwischen verschiedenen Containerisierungssystemen zu unterbrechen :-) Wir werden sehen, ob wir nichts Besseres finden.

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

@jpetazzo Das stimmt, aber ich denke, Docker wird eine Standardmethode zum Überschreiben der zugrunde liegenden Containerisierungssystemkonfiguration benötigen, wenn dies zulässig ist - zurück zu der privilegierten Build-Überlegung, denke ich!

@solomonstre Der Punkt ist, dass es eine Möglichkeit geben muss, docker build im privilegierten Modus zu bauen. Das Erlauben des Zugriffs auf /dev/loop* wird mir bei meinem speziellen Anwendungsfall nicht weiterhelfen.

@solomonstre : Whitelisting /dev/loop ist IMHO ein großes No-

Ich verstehe, dass einige Builds Loop-Geräte, Mounts und andere Dinge erfordern. Sehen wir uns unsere Optionen an:

1. docker build -privileged
   Praktisch, zieht aber die Grenze zwischen "normalen Builds" und "privilegierten Builds". Wenn Sie ein sehr nützliches Image haben, das einen privilegierten Builder erfordert, wird es schwierig sein, es auf öffentlichen Buildern zu erstellen. Wenn beispielsweise jemand einen Dienst startet, um Builds zu automatisieren, wird er wahrscheinlich keine privilegierten Builds anbieten (oder er muss zusätzliche Sicherheitsvorkehrungen treffen).
2. Berechtigungen im Builder etwas lockern
   Dies bedeutet (zumindest) das Aktivieren von cap_sysadmin (das lässt mich ein bisschen zittern) und vielleicht jedem Builder ein oder zwei Loop-Geräte geben. Dies würde die Gesamtzahl der parallel laufenden Builder begrenzen; Aber es ist keine große Sache, da Builds schnelle und vor allem aktive Prozesse sein sollen. IE, wenn 50 Builds parallel laufen, es sei denn, Sie haben eine Maschine mit einem Kickass-I/O-Subsystem, diese Builds werden nicht viel vorankommen.
3. Wickeln Sie den Build in eine weitere Ebene der Virtualisierung/Isolation ein.
   Anstatt den Build direkt in Docker auszuführen, führen Sie etwas wie QEMU-in-Docker oder UML-in-Docker aus. Aus Sicht eines Docker-Entwicklers ist dies eine coole Lösung, da sie keinen zusätzlichen Aufwand bedeutet; Dies ist aus Sicht eines DOcker-Benutzers eine schlechte Lösung, da es eine weitere Komplexitätsebene erfordert.

Ich frage mich, ob die richtige Lösung darin bestehen könnte, docker build -privileged` zuzulassen, und gleichzeitig über Hooks nachzudenken, die eine transparente Implementierung von Option 3 ermöglichen würden. Angenommen, ich bin ein "Docker-Build-Anbieter": if Wenn jemand einen privilegierten Build anfordert, muss ich nur irgendwo etwas einfügen, um seinen Build-Prozess in einer Sandbox-Umgebung auszuführen (QEMU und UML sind offensichtliche Kandidaten, aber andere könnten auch funktionieren; sie sind nur praktische Beispiele).

Was denkt ihr?

@backjlack , darf ich fragen, wie Sie diesen Container verwenden, nachdem er erstellt wurde? Was
passiert, wenn Sie es genau "docker ausführen", was ist die Anwendung? Gerade
versuchen, ein Gefühl für die Anwendungsfälle dafür zu bekommen.

Am Fr, 18. Okt 2013 um 9:59 Uhr, Jérôme Petazzoni
[email protected] schrieb :

@solomonstre https://github.com/solomonstre : Whitelisting /dev/loop ist,
IMHO, ein großes No-No, denn mit dem DM-Zweig würde es Lesen/Schreiben geben
Zugriff auf alles (da das Standardverhalten des DM-Zweigs verwendet wird
Loop-Geräte zum Speichern der Pools).

Mir ist bewusst, dass einige Builds Loop-Geräte, Mounts und andere erfordern
Dinge. Sehen wir uns unsere Optionen an:

1. docker build -privilegiert Praktisch, zieht aber die Grenze zwischen
   "normale Builds" und "privilegierte Builds". Wenn Sie zufällig eine sehr
   nützliches Image, das einen privilegierten Baumeister erfordert, wird es schwierig sein,
   bauen Sie es auf öffentlichen Bauherren. ZB wenn jemand einen Dienst startet, um ihn zu automatisieren
   Builds, werden sie wahrscheinlich keine privilegierten Builds anbieten (oder sie haben
   zusätzliche Sicherheitsvorkehrungen treffen).
2. Berechtigungen im Builder etwas lockern Das bedeutet (zumindest)
   cap_sysadmin aktivieren (das lässt mich ein bisschen zittern) und vielleicht
   Geben Sie jedem Bauherrn ein oder zwei Schleifengeräte. Dies würde die Gesamtzahl begrenzen
   Anzahl parallel laufender Bauherren; aber es ist keine große Sache da
   Builds sollen schnelle und vor allem aktive Prozesse sein.
   IE, wenn 50 Builds parallel laufen, es sei denn, Sie haben eine Maschine
   mit einem Kickass-I/O-Subsystem werden diese Builds nicht viel vorankommen.
3. Wickeln Sie den Build in eine weitere Ebene der Virtualisierung/Isolation ein.
   Anstatt den Build direkt in Docker auszuführen, führen Sie etwas wie
   QEMU-in-Docker oder UML-in-Docker. Dies ist eine coole Lösung von einem Docker
   Entwicklersicht, da keine zusätzliche Arbeit erforderlich ist; das ist ein armer
   Lösung aus DOcker-Anwendersicht, da es den Umgang mit
   eine weitere Komplexitätsebene.

Ich frage mich, ob die richtige Lösung darin bestehen könnte, Docker-Build-privilegiert zuzulassen.
und denken Sie gleichzeitig an Haken, die transparent machen würden
Implementierung von Option 3. Angenommen, ich bin ein "Docker-Build-Anbieter": if
Jemand fordert einen privilegierten Build an, ich muss nur einfügen
etwas irgendwo, um ihren Build-Prozess in einer Sandbox auszuführen
Umgebung (QEMU und UML sind offensichtliche Kandidaten, aber andere könnten funktionieren
auch; sie sind nur praktische Beispiele).

Was denkt ihr?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/dotcloud/docker/issues/1916#issuecomment -26612009
.

+1 - Ich würde gerne mknode-Funktionen zum Installieren von Fuse (zum Mounten von S3-Buckets) oder die Möglichkeit sehen, privilegierte Läufe in Dockerfiles auszuführen. Noch unsicher, was die beste Lösung ist.

+1. irgendwelche Updates zu diesem Thema?

+1
Am 17. November 2013 23:31 schrieb "yukw777" [email protected] :

+1. irgendwelche Updates zu diesem Thema?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/dotcloud/docker/issues/1916#issuecomment -28676216
.

Ich bin auch auf das Problem mit der Sicherung gestoßen, als ich versucht habe, Java zu installieren, und ich bin an einer Lösung interessiert. Ich habe den hier vorgeschlagenen Workaround ausprobiert https://gist.github.com/henrik-muehe/6155333, aber er funktioniert bei mir nicht auf Docker auf dem Raspberry Pi.

@jpetazzo : Ich mag die Gesamtstrategie, das Flag -privileged zu implementieren und gleichzeitig eine längerfristige Lösung zu erkunden. Zu diesem Zweck habe ich eine Pull-Anfrage eingereicht, um diese Funktion zu implementieren. Beachten Sie, dass der Befehl "RUNP" derzeit nicht implementiert wird, wie zuvor in diesem Thread beschrieben.

(Lassen Sie mich dies "quer posten", da die Leute hier möglicherweise nach einer Problemumgehung suchen)

Wenn Sie die Gerätedatei nicht wirklich verwenden (aber sie ist nur Teil eines Post-Inst-Skripts wie im Fall des Sicherungspakets), können Sie Folgendes tun:

fakeroot apt-get ...

oder:

dpkg-divert --local --rename --add /sbin/mknod && ln -s /bin/true /sbin/mknod`

Das ist sicher gut gemeint, aber der allererste Kommentar/mein Bericht enthielt bereits zwei Workarounds.
Um fair zu sein, Sie haben der Liste neue hinzugefügt, aber das Problem ist nicht 'Fuse kann nicht installiert werden' und das Lesen des ersten Beitrags sollte den Leuten helfen, die das Paket einfach installieren müssen, egal was passiert.

Das eigentliche Problem ist 'Ich muss mknod aufrufen' (oder allgemeiner: Ich brauche privilegierte Operationen, die bisher fehlschlagen).

@jpetazzo Das könnte das beheben, oder? https://lwn.net/Articles/564977/ - Bis dahin würde ich mich für 3) entscheiden, weil das Isolieren des Gerätezugriffs eine weitere Komplexitätsebene ist und irgendwo verwaltet werden muss.

Ich bin auch nicht davon überzeugt, dass eine Schleifenmontage oder Sicherung eine notwendige Funktion ist. Es fühlt sich verrückt an, einem Container im Nutzungsbereich Root-Rechte zu erteilen, um ein Dateisystem zu mounten, das sich (sicherung: Implementierung läuft, Schleife: Bilddatei ist) im Benutzerbereich befindet.

Wenn Sie ein Dateisystem-Image mounten oder fs verschmelzen müssen, können Sie es außerhalb des Containers mounten und als Volume-/Bind-Mount verwenden. Obwohl es eine nette Funktion sein könnte, entfernte Dateisysteme in Docker selbst zu unterstützen und zu verwalten. Vielleicht ein Dockerfile MOUNT/Einhängepunkt.

@discordianfish 3) ist so ziemlich eine

würde #2979 bei diesem Problem helfen?

Auch hier warte ich auf eine Lösung, aber nicht wegen mknod. Wir führen Centos-Container mit RPMs aus, die Limits für Benutzer einrichten, die /etc/security/limits.d/ verwenden, und ich verwende derzeit einen Vorschlaghammer-Workaround bestehend aus:

RUN /bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/*

ganz oben in meinem Dockerfile. (Wir sind nur am Prototyping, keine Sorge :))

Hallo @jpetazzo, ich habe beide Optionen ausprobiert, die Sie vorgeschlagen haben. Ich versuche, ein Image "oracle_xe" mit zu erstellen

sudo docker build - privilegiert -t oracle_xe weil ich in meinem Dockerfile diese 2 Befehle ausführen möchte

RUN mount -o remount,size=3G /dev/shm
RUN mount -a

Aber das funktioniert nicht, ich weiß nicht, ob die von mir verwendete Syntax falsch ist, der Fehler, den ich bekomme, ist
Flag bereitgestellt, aber nicht definiert: -privileged

Ich habe auch die zweite Möglichkeit versucht, RUNP zu verwenden, aber das hat auch nicht funktioniert, wenn ich das Image baue, überspringt es diesen Schritt und sagt

Überspringen der unbekannten Anweisung RUNP. Ich kann Ihnen das Dockerfile senden, das ich versuche zu erstellen. Bitte helfen Sie mir, dieses Problem zu lösen.

Vielen Dank.

Ich denke, weder RUNP noch "build --privileged" wurden implementiert.
Wenn möglich, zögern Sie nicht, das Dockerfile zu teilen; es könnte nützlich sein, also
wir können Ihnen den "wenig schlimmsten" Workaround geben :-)

Am Mittwoch, den 9. April 2014 um 7:44 Uhr schrieb Manoj7 [email protected] :

Hallo jpetazzo, ich habe beide Optionen ausprobiert, die Sie vorgeschlagen haben. ich versuche zu bauen
ein Bild "oracle_xe" mit

sudo docker build - privilegiert -t oracle_xe weil in meinem Dockerfile i
möchte diese 2 Befehle ausführen

RUN mount -o remount,size=3G /dev/shm
RUN mount -a

Aber wenn das nicht funktioniert, weiß ich nicht, ob die Syntax die ich verwendet habe
falsch. Ich habe auch die zweite Wahl versucht, RUNP zu verwenden, aber das hat auch nicht geklappt
funktioniert, wenn ich das Bild baue, überspringt es diesen Schritt und sagt
Überspringen der unbekannten Anweisung RUNP. Ich kann dir das Dockerfile schicken, das ich bin
versuchen zu bauen. Bitte helfen Sie mir, dieses Problem zu lösen.

Vielen Dank.

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/dotcloud/docker/issues/1916#issuecomment -39972199
.

@jpetazzo https://twitter.com/jpetazzo
Neuester Blogbeitrag:
http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

Hallo @jpetazzo , ich würde gerne ein "RUN sudo umount /etc/hosts" in meinem Dockerfile machen - gibt es dafür eine "am wenigsten schlimmere" Problemumgehung? ;)

@jpetazzo

Das Dockerfile, mit dem ich das Oracle_xe-Image erstellt habe

Von *

WARTER * * * * * * *

HINZUFÜGEN oracle-xe-11.2.0-1.0.x86_64.rpm.zip /appl/oracle/xe/oracle-xe-11.2.0-1.0.x86_64.rpm.zip
RUN mount -o remount,size=3G /dev/shm
RUN mount -a
RUN cd /appl/oracle/xe && oracle-xe-11.2.0-1.0.x86_64.rpm.zip entpacken
RUN cd /appl/oracle/xe/Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm
RUN cd /appl/oracle/xe && rm oracle-xe-11.2.0-1.0.x86_64.rpm.zip
ENV ORACLE_HOME /u01/app/oracle/product/11.2.0/xe
ENV ORACLE_SID XE

Das erste, was ich versucht habe, war

sudo docker build -privileged -t oracle_xe .

Dies hat nicht funktioniert und dann habe ich versucht, RUNP zu verwenden
RUNP mount -o remount,size=3G /dev/shm
RUNP-Halterung -a
dies hat auch nicht funktioniert, diese beiden Schritte wurden übersprungen.

@gatoravi : Leider

@Bhagat7 : richtig! Frage: Brauchen Sie das größere /dev/shm zur Laufzeit _und_ Installationszeit oder nur zur Laufzeit? Wenn es zur Build-Zeit ist, welcher Schritt schlägt fehl und wie?

@jpetazzo Ich möchte als Teil des Build-Prozesses meines Tools eine neue IP-Adresse zu /etc/hosts hinzufügen.
Etwas wie echo $IP $HOST >> /etc/hosts.

Ich kann das gut machen, wenn ich docker run --privileged und dann ein sudo umount \etc\hosts mache, aber es sieht so aus, als ob ich das nicht mit docker commit begehen kann, daher muss ich die umount wiederholen

Ich möchte \etc\hosts irgendwie beschreibbar und persistent machen, kann aber weder mit docker commit noch mit einem Dockerfile einen Weg finden.

@jpetazzo

Ich hatte dieses Problem

bash-4.1#/etc/init.d/oracle-xe konfigurieren
Geben Sie den HTTP-Port an, der für Oracle Application Express [8080] verwendet wird:

Geben Sie einen Port an, der für den Datenbank-Listener [1521] verwendet wird: 1521

Geben Sie ein Kennwort an, das für Datenbankkonten verwendet werden soll. Beachten Sie, dass das gleiche
Passwort wird für SYS und SYSTEM verwendet. Oracle empfiehlt die Verwendung von
unterschiedliche Passwörter für jedes Datenbankkonto. Dies ist nachher möglich
Anfangskonfiguration:
Bestätigen Sie das Passwort:

Soll Oracle Database 11g Express Edition beim Booten gestartet werden (j/n) [j]:j

Starten von Oracle Net Listener...Fertig
Datenbank konfigurieren...Fertig
Starten der Oracle Database 11g Express Edition-Instanz...Fertig
Installation erfolgreich abgeschlossen.
bash-4.1#cd /u01/app/oracle/product/11.2.0/xe/bin
base-4.1#sqlplus
Benutzername eingeben: system
Passwort eingeben: * **
Aber ich bekomme diesen Fehler
ORA-01034: ORACLE nicht verfügbar
ORA-27101: Shared Memory Realm existiert nicht
Linux-x86_64-Fehler: 2: Keine solche Datei oder kein Verzeichnis
Prozess-ID: 0
Sitzungs-ID: 0 Seriennummer: 0
df -h innerhalb des Containers zurückgegeben
Verwendete Dateisystemgröße Avail Use% Mounted on
tmpfs 64M 0 64M 0% /dev/shm

Als ich die Größe von tmpfs auf 3G erhöht habe, wurde dieser Fehler nicht angezeigt. Ich habe es gelöst, indem ich den Container als ausgeführt habe
sudo docker run -privileged -i -t oracle_xe /bin/bash. Ich habe die 2 Mount-Befehle im Container ausgeführt. Aber ich möchte es nicht so machen, stattdessen möchte ich sie in mein Dockerfile legen und bauen.

@gatoravi : OK, verstanden. Dann noch zwei Fragen: Brauchen Sie diese zusätzlichen Hosts in /etc/hosts während des Builds oder nur während der Ausführung? Und warum brauchst du es?

@Bhagat7 : Entschuldigung, ich habe dafür noch keine elegante Lösung:-( Ich würde vorschlagen, zwei Dockerfiles zu haben:

• ein erster, der alle Schritte ausführt (außer dem, der das größere /dev/shm erfordert) und ein CMD definiert, das prüft, ob der Container im privilegierten Modus läuft, das größere /dev/shm mountet und das spezielle ausführt Befehl;
• ein zweites Dockerfile, um weitere Schritte auszuführen (es sei denn, Sie benötigen auch /dev/shm zur Laufzeit, dann benötigen Sie vorerst ein privilegiertes Ding).

@jpetazzo Wir

@ Bhagat7 Ich konnte Oracle XE in einem Docker 0.9-Container mit einer Kombination aus

1. https://github.com/wnameless/docker-oracle-xe-11g
   und
2. auf dem Wirt...

sysctl -w kernel.msgmni=4096
sysctl -w kernel.msgmax=65536
sysctl -w kernel.msgmnb=65536
sysctl -w fs.file-max=6815744
echo "fs.file-max = 7000000" > /etc/sysctl.d/30-docker.conf
service procps start

@mikewaters Vielen Dank für die Antwort. Ich glaube, Sie haben Oracle XE auf Ubuntu aufgebaut. Aber ich versuche, es auf Centos aufzubauen.

@jpetazzo Vielen Dank für deinen Vorschlag

Hallo Leute,

Ich verwende Google-Chrome, das in /dev/shm schreiben muss, was normalerweise 777 zu sein scheint und hier 755 ist. Ich habe versucht, meinem /etc/fstab eine bestimmte Konfiguration hinzuzufügen, kann aber mout -a nicht ausführen, um die Änderungen auf einen Build anzuwenden. Natürlich habe ich die grundlegenden chmod oder chown ausprobiert, kann es aber auch nicht beim Build tun.

Wenn ich meine Befehle verwende, wenn ich im --privileged Modus eingeloggt bin, ist alles in Ordnung. Aber ich muss, wie andere Leute erklärt haben, dies beim Build tun.

Irgendein Vorschlag?

Dankeschön.

@tomav das "/dev/shm"-Berechtigungsproblem ist eigentlich #5126, das in #5131 behoben wurde und bereits in Master zusammengeführt ist (und in der nächsten Version sein wird)

Danke @tianon.

heute hatte ich diese idee: ich möchte einen container, der meine datenmengen verwaltet. einfach, aber da ich auf einem vps bin, möchte ich, dass diese Volumes verschlüsselt, aber wie üblich in klaren anderen Containern bereitgestellt werden. Der Punkt ist, einfach keine klaren Daten auf der virtuellen Festplatte zu haben und eine schnelle Möglichkeit zu haben, den Schlüssel zu löschen.

Ich habe einige der Schritte befolgt, die in diesem Artikel zum Erstellen eines cryptfs zum Einfügen von Containern wunderschön dokumentiert sind: https://launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

Beachten Sie, dass ich das _nicht_ versuche, sondern tatsächlich einen Container mit gemounteten cryptfs habe:
Daher sollte ein verschlüsseltes Dateisystem während des Builds über Docker erstellt, gemountet und formatiert werden.

das schlägt fehl:

• Wenn ich versuche, ein Loop-Gerät zu finden:

+ losetup -f
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)

• Seltsamerweise gelingt es genau der gleichen Dockerdatei _manchmal_, ein Loop-Gerät zu finden, dann:

+ losetup -f
+ LOOP_DEVICE=/dev/loop1
+ losetup /dev/loop1 /cryptfs/disk
+ cryptsetup luksFormat --batch-mode --key-file=/etc/cryptfs/random /dev/loop1
setpriority -18 failed: Permission denied
/dev/mapper/control: mknod failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

gibt es da schon einen weg? (außer dem Verschieben der Schritte zum Mounten/Formatieren der Festplatte in run )

+1 Es wäre besonders nützlich für "Docker in Docker"-Umgebungen

+1 dazu, iptables funktioniert nicht im unprivilegierten Modus, was dazu führt, dass alles fehlschlägt, wenn versucht wird, Firewall-Regeln einzurichten.

@PerilousApricot : Beachten Sie jedoch, dass selbst wenn Sie eine iptables-Regel in RUN festlegen könnten, diese sofort verloren geht, da ein Image nur den Zustand des Dateisystems enthält. Es weiß nichts über laufende Prozesse, Netzwerkrouten, iptables-Regeln usw.

Das ist für mich in Ordnung, da der Container nur bestimmte Ports haben würde
weitergeleitet, mir geht es nicht um die Firewall, ich will meistens nur die
Installateur, um überhaupt erfolgreich zu sein

Andrew Melo

@PerilousApricot Ich iptables mit /bin/true ? Das sollte auch den Installateur glücklich machen. (Oder einen ähnlichen Trick, um das Installationsprogramm zu täuschen?)

Ich habe das versucht, aber das Installationsprogramm muss auch die Ausgabe von analysieren
iptables, also ist es nicht ganz so einfach :)

Okay, ich weiß, das wird langsam hackig, aber – wie wäre es, stattdessen ein gefälschtes iptables einzusetzen? Was würde eine Dummy-Ausgabe erzeugen?

Ich verstehe total, dass es nicht großartig ist; aber im Ernst, diese Art von Installationsprogramm sollte in erster Linie behoben werden :)

Der Anwendungsfall Docker im Docker hat mich hierher gebracht. Nun, Docker in lxc, um genau zu sein, da unsere Entwicklungsumgebung lxc verwendet und ich möchte, dass Entwickler die Images in lxc erstellen können.

Ich möchte dies auch für Docker in Docker. Es gibt ein Image, das gezogen werden muss, bevor die Anwendung ausgeführt werden kann, das ziemlich groß ist, und ich würde es lieber als Teil von docker build ziehen und zwischenspeichern lassen, anstatt häufig ziehen und/oder festschreiben zu müssen Container, die es gezogen haben.

Diese Funktion ist IMHO ein Muss, eine Kombination aus RUNP zusammen mit build-privileged wäre toll.

Das reale/Produktionsszenario, gegen das ich gestoßen bin, sind Docker-Images, die mit Puppet-Bereitstellung in einem Zwischencontainer erstellt wurden. Bei bestimmten Diensten, die erhöhte Fähigkeiten erfordern, treten Fehler beim Build auf, die erfordern, dass der Container unter -privileged mit einem ENTRYPOINT oder CMD , das das Puppet-Skript erneut anwendet.

Dies verzögert die Startzeit des echten Dienstes innerhalb des Containers, da die Puppet-Konfiguration erstellt und dann angewendet werden muss, um einen ordnungsgemäßen Zustand sicherzustellen (und dies ist zeitaufwändig), und der laufende Container muss _möglicherweise_ nicht in tatsächlichen -privileged Modus, aber nur während der Auswertung bestimmter Zustände in einem Zwischencontainer während des Builds.

Ich hoffe das obige macht Sinn.

@jpetazzo Ich versuche, einen Webserver auf centos6 aufzubauen. Ich bin beim Konfigurieren von iptable-Regeln über das Dockerfile gestrandet. Es ähnelt dem Problem von

btw: Ich bin NICHT dafür, Hacks wie ein gefälschtes iptables zu implementieren.

@pmoust : Buildvorgänge erhöhte Berechtigungen erforderlich sind? Ich werde wahrscheinlich empfehlen, dem Problem auszuweichen, und mir ist völlig klar, dass dies für Sie möglicherweise nicht zufriedenstellend ist; aber trotzdem würde ich gerne verstehen, welche Art von Installer/Builder diese Privilegien benötigen könnte...

@passion4aix : Beachten Sie, dass wenn Sie iptables-Regeln in der Dockerfile festlegen, diese NICHT gespeichert werden. Docker speichert nur den Dateisystemstatus, nicht das Routing/Filtern/Ausführen von Prozessen... Es gibt Möglichkeiten, iptables-Regeln mit "Sidekick"-Containern einzurichten. Könnte das für Sie interessant sein?

@jpetazzo Der Bitrock-Installer ist ein Beispiel. Es erfordert, dass /tmp als tmpfs gemountet wird. Vielleicht möchten Sie einen Blick auf http://answers.bitrock.com/questions/3092/running-installer-inside-docker werfen

@jpetazzo oder im Grunde jedes Openstack-Installationsprogramm

Ich bin auch gerade auf ein ähnliches Problem gestoßen, als ich versuchte, TokuMX in einem Docker-Container auszuführen, da TokuMX erfordert, dass die Kerneloption 'transparent_hugepage' deaktiviert ist.

Gibt es Fortschritte zu diesem Thema? Es ist bereits über ein Jahr alt und wenn man sich die Kommentare ansieht, können die meisten Leute privilegierte Aktionen aus einem Dockerfile ausführen.

Persönlich würde ich mich nicht für den Build mit '--privileged'-Lösung entscheiden. Die RUNP-Lösung ist besser, da Sie dann einige Aktionen nur als privilegierter Benutzer ausführen können, anstatt die gesamte Installation als privilegiert auszuführen. Auf diese Weise müssen Sie sich zumindest überlegen, wann Sie RUNP einsetzen und nur bei Bedarf verwenden.

Mir scheint, die Frage ist nicht mehr, WENN diese Option hinzugefügt werden soll, sondern erst, wenn es fertig ist. Wann können wir diese Funktionalität erwarten?

@diversit Sie müssten gekoppelt werden. --privileged auf der Befehlszeile würde also die Möglichkeit bieten, RUNP , andernfalls wäre dies ein Sicherheitsalbtraum für Leute, die Builds von nicht vertrauenswürdigem Code (einschließlich DockerHub) erstellen.

Denken Sie jedoch auch daran, dass Sie dies außerhalb der Dockerfile-Syntax manuell tun können. Der Build-Prozess liest das Dockerfile, erstellt daraus einen Container und überträgt ihn zurück in ein Image.

@deas : Ich denke, das kann gelöst werden, indem man VOLUME /tmp tut.

@PerilousApricot : näher ausführen ? Ich verstehe nicht, warum irgendeine Art von Installationsprogramm spezielle Privilegien benötigt. (Ja, ich bin ein alter sturer Unix-Typ, das ist einer meiner Fehler :D)

@diversit : Für diesen speziellen Fall denke ich, dass der Administrator der Maschine vor dem Erstellen transparente Hugepages deaktivieren sollte. Denn wenn der Builder dies darf, wird er dies global tun (oder?) und möglicherweise andere Container zerstören, die die Funktion möglicherweise benötigen. Verstehst du, was ich meine? Es wäre schlecht, wenn das Erstellen von Container X den laufenden Container Y unterbricht ...

Alle: Ich verstehe total, dass es sehr frustrierend ist, wenn ein Dockerfile nicht funktioniert und alles, was Sie brauchen, ist dieses --privileged / RUNP Flag. Aber wenn wir anfangen, privilegierte Builds zu haben, wird eine Menge Dinge kaputt gehen (zB automatisierte Builds auf dem Docker Hub!), deshalb fühlen wir uns sehr schlecht deswegen. Und für das, was es wert ist, bin ich bereit, alle Szenarien zu untersuchen, die privilegierte Builds erfordern, und helfe, sie zu beheben :-) (Da ich persönlich davon überzeugt bin, dass diese Installer kaputt sind!)

@jpetazzo Viele/die meisten Openstack-Bereitstellungstools (z. B. https://openstack.redhat.com/Main_Page) legen iptables-Regeln fest. Ich möchte in der Lage sein, containerisierte Versionen der Anwendung zu rollen/bereitzustellen, daher ist es für mich wichtig, eine Dockerdatei erstellen und in einem Schritt ausführen zu können. Ich weiß, dass iptables-Regeln nicht nativ durch den Containerisierungsprozess beibehalten werden, sondern durch iptables-save beibehalten werden, sodass eine einfache iptables-Wiederherstellung im CMD-Prozess dazu führt, dass die Regeln neu geladen werden. Es ist viel komplizierter, iptables einfach zu "stuben", weil viele Bereitstellungstools CI-Tools wie Marionette oder Chef verwenden, um die eigentliche Bereitstellung durchzuführen. Sie müssten also irgendwie einen kompatiblen Stub erstellen, der am Ende alle emuliert die Ein-/Ausgänge zum "echten" iptables-Befehl.

Außerdem denke ich, dass es ein fairer Kompromiss ist zu sagen: "Wenn Sie ein Dockerfile haben, das privilegierte Builds erfordert, verlieren Sie die Funktionen X, Y, Z."

Oracle xe wird nicht ohne ausreichend freigegebenen Mem-Speicher ausgeführt. Alle Konten sind so, dass das Remountimg von tmpfs mit enuf space Oracle xe glücklich macht, zu starten und seine Konfiguration abzuschließen soll angeblich durch Erhöhung der Reittiergröße überwunden werden)

Während eines Builds
RUN tmpfs aushängen
scheitert mit
umount: /proc/kcore: muss Superuser für umount sein

gib mir RUNP oder gib mir den Tod .... oder .... zeig mir, was man anders machen könnte :)

Mein Beispiel ist ungültig; @jpefazzo steht immer noch :) Meine Oracle-Einstellungen haben die Probleme verursacht und es scheint keine Notwendigkeit zu geben, die tmpfs-Größe anzupassen ... zumindest für die Erstinstallation.

Ich stoße in CentOS 7.0 auf ein iptables Problem, das nur behoben wird, wenn run mit --privileged https://github.com/docker/docker/issues/3416

Ohne Unterstützung für privilegiertes Bauen bin ich mir nicht sicher, wie ich das Problem sonst umgehen soll

Step 24 : RUN iptables -I INPUT -p tcp --dport 80 -j ACCEPT
 ---> Running in 74ebc19b6935
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

@buley Ich glaube, mit den hinzugefügten security-opts in #8299 wird es möglich sein, dies ohne --privileged zu tun

@jpetazzo Ich sehe nicht, wie die Verwendung von VOLUME /tmp das Problem der Bitrock-Installer löst. Das mag für den Build funktionieren, aber es wird /tmp die AUFS-Schichtung für alle Container zu umgehen, die auf diesem Image basieren, oder? Am Ende des Tages scheint es, dass die Ursache in AUFS behoben werden sollte.

Hier ist mein Anwendungsfall: Ich möchte eine Chroot-Umgebung in einem Docker-Container erstellen. Das Problem ist, dass debootstrap nicht ausgeführt werden kann, weil es proc nicht in der Chroot einhängen kann:
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
Wenn ich den Container run --privileged schreibe, funktioniert es (natürlich)...
Ich würde wirklich gerne die Chroot im Dockerfile debootstrapieren (viel sauberer). Gibt es eine Möglichkeit, es zum Laufen zu bringen, ohne auf RUNP oder build --privileged warten zu müssen?

Danke vielmals!

+1 für --privilegiert oder mounten. Bedarf an automatisierten Glusterfs

Dies wirkt sich auf meine Bemühungen aus, ein Image aus dem Bitnami Tomcat-Installationsprogramm zu erstellen. 99% des Installationsvorgangs laufen ohne Probleme, aber wenn Tomcat zum ersten Mal gestartet wird, schlägt dies mit der folgenden Ausgabe in catalina-daemon.out fehl:

set_caps: Fähigkeiten konnten nicht gesetzt werden
Überprüfen Sie, ob Ihr Kernel Fähigkeiten unterstützt
set_caps(CAPS) für Benutzer 'tomcat' fehlgeschlagen
Service-Exit mit einem Rückgabewert von 4

Ich kann das Tomcat-Installationsprogramm erfolgreich manuell in einem Container ausführen, den ich mit "--cap-add ALL" erstelle. Es scheint seltsam, dass ich 'docker build' nicht verwenden kann, um ein Image zu erstellen, das ich manuell mit 'docker run' und dann 'docker commit' erstellen kann. Die Container, die während des Build-Prozesses verwendet werden, sollten alle Funktionen haben wie die Container, die Sie mit 'docker run' erstellen können.

@gilbertpilz Sie können das ausdrücklich nicht tun, um die Portabilität und Sicherheit des

@ cpuguy83 - Das macht keinen Sinn. Ich kann das gewünschte Bild von Hand erstellen, wenn ich Folgendes tue:

docker run --cap-add ALL .... /bin/bash
bitnami-tomcatstack-7.0.56-0-linux-x64-installer.run ...
Ausfahrt
Docker-Commit ....

Alles, was ich verlange, ist die Möglichkeit, "docker build" zu verwenden, um dasselbe zu tun, was ich hier manuell mache. Ich kann nicht sehen, wie "Portabilität und Sicherheit" "gewährleistet" werden, wenn ich das Image auf die eine Weise erstellen kann, aber nicht auf die andere.

Ok, lassen Sie mich Ihnen eine Docker-Datei geben, die /etc/passwd des Hosts in den Builder einhängt und diese zufällig an mich sendet.

Dieses Zeug kann gefährlich sein.
Beachten Sie auch, dass --privileged (und --cap-add ALL) dem Benutzer im Container die volle Kontrolle über den Host geben.

Das Zulassen dieser Dinge würde den gesamten DockerHub gefährden

@cpuguy83 - Sie müssen das Steuerelement nicht in das Dockerfile einfügen. Sie könnten die Option "--cap-add" (oder etwas Ähnliches) zum Befehl "docker build" hinzufügen. Wenn wir Ihrer Logik gefolgt sind, sollten Shell-Skripte die Verwendung des Befehls "sudo" nicht zulassen, da jemand ein Skript schreiben könnte, das schlechte Dinge tut.

Aber Sie würden niemandem ein Sudo geben, dem Sie die Schlüssel zum Königreich nicht anvertrauen.
Build muss in der Lage sein, nicht vertrauenswürdigen Code so sicher wie möglich auszuführen.

Die Einführung von CLI-Flags zum Aktivieren zusätzlicher Funktionen beim Build unterbricht die Portabilität des Builds, und deshalb wird er noch nicht hinzugefügt.

Das heißt, das Installationsprogramm liegt hier mit ziemlicher Sicherheit falsch und fordert Dinge an, auf die es selbst keinen Zugriff haben sollte.

Genau. Sie sollten Personen, denen Sie nicht vertrauen, nicht die Möglichkeit geben, Docker-Builds auszuführen, die Berechtigungen erfordern, aber Docker sollte Personen, denen Sie vertrauen, nicht daran hindern, dies zu tun. Dies ist eine politische Entscheidung, und ich mag es wirklich nicht, wenn Tools sich anmaßen, politische Entscheidungen für mich zu treffen. Ein gutes Werkzeug ermöglicht es mir, die von mir getroffenen politischen Entscheidungen klar und nicht überraschend umzusetzen.

Sie sehen nicht das größere Bild.

Dieses Ökosystem bietet mehr als Ihr Server und mein Server. DockerHub beispielsweise erstellt ständig nicht vertrauenswürdigen Code.

Dann sollte DockerHub definitiv _nicht_ das Hinzufügen von Funktionen für seine Builds aktivieren. Wenn dies bedeutet, dass ich meinen Docker-Build nicht auf DockerHub übertragen kann, bin ich damit einverstanden.

@cpuguy83 @tianon @jpetazzo -- Wenn die FUD beginnt, muss ich meine Stimme erheben :

Das Zulassen dieser Dinge würde den gesamten DockerHub gefährden

srsly?
Implementieren dieser Funktion == TEOTWAWKI ?

Natürlich würde DockerHub niemals docker build mit dem angeforderten --privileged Flag ausführen.
Ohne lange nachzudenken, gibt es mindestens zwei offensichtliche Möglichkeiten, es zu implementieren:

• Flag funktioniert nur, wenn Sie docker -d mit einem neuen Flag starten, wie zum Beispiel: --i-want-a-broken-security-model
• Erstellen Sie ein Flag zur Kompilierzeit, das den Codepfad aktiviert.

Insgesamt scheint hier das Verhältnis von zähneknirschenden zu ingenieurstechnischen Gründen gegen die Umsetzung sehr hoch zu sein.

@tamsky Und dann haben wir eine Situation, in der Builds an einem Ort funktionieren, aber nicht an einem anderen.
Ich erkläre, warum die Dinge so sind, wie sie sind, und argumentiere nicht über den einen oder anderen Fall.

Aber auch ... die meisten Dinge brauchen keinen privilegierten Zugriff, und diejenigen, die privilegierten Zugriff benötigen, brauchen ihn im Allgemeinen nicht _wirklich_, damit die Installation funktioniert. Wenn die Installation von etwas aus diesem Grund fehlschlägt, ist dieses Installationsprogramm defekt, wie es bei dem zitierten Tomcat-Problem der Fall ist.
Die Aktivierung einer solchen Funktion würde die Benutzer ermutigen, im privilegierten Modus zu arbeiten, anstatt das eigentliche Problem tatsächlich zu lösen.

@cpuguy83

Und dann haben wir eine Situation, in der Builds an einem Ort funktionieren, aber nicht an einem anderen.

Bitte stellen Sie sich für einen Moment vor, wir wurden auf magische Weise in eine Welt versetzt, in der die _Politik_ anders ist und einige Builds an einem Ort funktionieren, an einem anderen jedoch nicht...

Warum ist das eine große Sache?
Wen interessiert's genau?

Hat Docker Inc in Betracht gezogen, dass ihr Mantra/Anforderung auf dem kleinsten gemeinsamen Nenner "alle Builds müssen überall funktionieren" möglicherweise tatsächlich ein tatsächliches Kundenbedürfnis ignoriert?

Die derzeitige Richtlinie sieht vor, die Engineering-Kosten für Kunden zu externalisieren, um „X dazu zu bringen, Docker zu bauen“:

Anstatt diese Funktion in Docker bereitzustellen, zwingt Sie jedes 3rd-Party-Projekt auf der Welt, das "keinen privilegierten Zugriff benötigt" (aber tatsächlich tut), zuerst aktualisiert oder Monkeypatched zu werden, um den Docker-Build-Fall zu behandeln.

Wenn Docker auf mehreren Plattformen ausgeführt werden soll, funktioniert 'Docker Build' NICHT auf allen Systemen gleich. Das heißt, ein Build eines Windows-Containers, Solaris-Containers oder sogar ARM-Linux-Containers ist nicht derselbe wie auf x86-64-Linux. Der Sicherheitskontext für diese wird ebenfalls je nach Plattform unterschiedlich sein.

Das heißt, @cpuguy83 , wir können nicht immer davon ausgehen, dass Dockerfiles universell bleiben. Ich stimme jedoch zu, dass wir die Varianz zwischen ihnen minimieren müssen. Es könnte sich lohnen, die Überlegung für Benutzer, die diese Funktion wünschen, so gefährlich sie auch ist, in die Gespräche einzubeziehen, die letztendlich über die Unterstützung mehrerer Arches / Plattformen geführt werden müssen.

Die Builds funktionieren nicht überall, weil zum Beispiel App-Rüstungsprofile geladen sind.
Wie würden Sie auch Fall mit vorgespeicherten Docker-Containern machen, die in ein Image eingebrannt sind?

Am 18. 11. 2014 um 2:53 schrieb tamsky [email protected] :

@cpuguy83

Und dann haben wir eine Situation, in der Builds an einem Ort funktionieren, aber nicht an einem anderen.

Bitte stellen Sie sich für einen Moment vor, wir wurden auf magische Weise in eine Welt versetzt, in der die Richtlinien anders sind und einige Builds an einem Ort funktionieren, an einem anderen jedoch nicht...

Warum ist das eine große Sache?
Wen interessiert's genau?

Hat Docker Inc in Betracht gezogen, dass ihr Mantra/Anforderung auf dem kleinsten gemeinsamen Nenner "alle Builds müssen überall funktionieren" möglicherweise tatsächlich ein tatsächliches Kundenbedürfnis ignoriert?

Die derzeitige Richtlinie sieht vor, die Engineering-Kosten für Kunden zu externalisieren, um „X dazu zu bringen, Docker zu bauen“:

Anstatt diese Funktion in Docker bereitzustellen, zwingt Sie jedes 3rd-Party-Projekt auf der Welt, das "keinen privilegierten Zugriff benötigt" (aber tatsächlich tut), zuerst aktualisiert oder Monkeypatched zu werden, um den Docker-Build-Fall zu behandeln.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Es ist nicht "der Installer", der in dieser Situation "kaputt" ist, sondern Tomcat 7. Ich verwende den Tomcat-Stack von Bitnami, der Tomcat mit Apache und MySQL integriert. Docker steht am Ende einer Lieferkette von Quell-, Konfigurations-, Integrations-, Test- und Paketierungsservices. Von mir zu verlangen, Tomcat zu "reparieren", hindert mich daran, diese Lieferkette zu nutzen. Es ist viel einfacher, das gewünschte Image von Hand zu erstellen (einen Container mit "--privileged" starten, das Installationsprogramm ausführen, einen Snapshot des Containers erstellen usw.) als Tomcat zu "reparieren".

+1
Ich kann meine Chefrollen nicht auf Docker portieren, da sie alle die Verwendung von ufw zum Öffnen von Ports beinhalten.
Das Hinzufügen von --privileged to build würde dies beheben.

+1. Debootstrap kann nicht als Schritt in meinen Dockerfiles verwendet werden.

+1. Debootstrap kann nicht als Schritt in meinen Dockerfiles verwendet werden.

Es schien natürlich, mein Chroot über eine Dockerfile / build zu erstellen, stieß aber auf die gleichen Probleme wie bei @fbrusch erwähnt.

FROM ubuntu:utopic
ENV HOME /root
RUN sudo apt-get update
RUN sudo apt-get install -y eatmydata
RUN for i in /usr/bin/apt*; do sudo ln -s /usr/bin/eatmydata $(basename $i); done
RUN sudo apt-get install -y debootstrap qemu-user-static binfmt-support
RUN sudo debootstrap --foreign --arch arm64 trusty ubuntu-arm64-chroot
RUN ls ubuntu-arm64-chroot
RUN sudo cp /usr/bin/qemu-aarch64-static ubuntu-arm64-chroot/usr/bin
RUN sudo cp /etc/resolv.conf ubuntu-arm64-chroot/etc
RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log

scheitert mit:

Step 11 : RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log
 ---> Running in 2654257e860a
I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
W: Failure trying to run:  mount -t proc proc /proc
W: See //debootstrap/debootstrap.log for details
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using DSA key ID 437D05B5
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key <[email protected]>"
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using RSA key ID C0B21F32
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2012) <[email protected]>"
mount: block device proc is write-protected, mounting read-only
mount: cannot mount block device proc read-only
 ---> de534a4e5458
Removing intermediate container 2654257e860a
Successfully built de534a4e5458

Wie wäre es mit einem Build-Flag --insecure anstelle von RUNP --insecure .
Für alle RUN-Befehle würde der nachfolgende Container mit --add-cap=all . Dies statt privilegiert, da privilegiert auch andere Dinge tut...
Dies könnte sich jedoch ändern, um die vollständigen privileged Einstellungen bei Bedarf zu implementieren, ohne dass das Flag geändert werden muss.

@cpuguy83
Es macht mir nichts aus, ein Flag zu verwenden, das an Docker-Build übergeben wird, das es ermöglicht, RUN-Befehle zu privilegieren oder RUNP-Befehle zu aktivieren. Es ist von Vorteil, in der Lage zu sein, sich ein Dockerfile anzusehen und durch die Befehle oder etwas darin zu erkennen, dass es privilegierten Zugriff erfordert, und zur Laufzeit, anstatt zu Schritt 10 zu gelangen und Fehler zu machen, hätte es beim Start eine Verknüpfung mit der Dockerfile enthält Befehle, die Privilegien erfordern.

Der Anwendungsfall, der mich zu diesem Thread geführt hat, sind Bind-Mounts, die ich intracontainer ausführen möchte. Im Moment können Sie sie nur ausführen, wenn Sie den Container im privilegierten Modus ausführen. Es zwingt Sie, Befehle beim Start zu verketten oder ein Init-Skript zu verwenden, das ausgeführt wird, um die Einrichtung des Systems abzuschließen, bevor der Prozess ausgeführt werden soll.

Es wäre schön, nur in der Dockerfile zu haben:

RUN mount --bind /dir1 /dir2

Ich werde meinen Anwendungsfall genauer beschreiben, damit dies nicht nur eine allgemeine Anfrage mit privilegierten Befehlen ist. Mein besonderer Fall ist, dass ich ein Verzeichnis im Anwendungsbereich an ein angehängtes Datenvolume binden möchte.

z.B

/usr/local/application/data -> /mnt/data 
/mnt/data -> HOST:/var/datasets/dataset1

Dies könnte gelöst werden, indem auch das Volume direkt in den Anwendungsbereich gemountet wird, aber ich suche nach einer Möglichkeit, sie an einem gemeinsamen Ort bereitzustellen und den Anwendungscontainer seine spezifische Zuordnung durchführen zu lassen. Dies könnte auch mit Symlinks gelöst werden, aber einige Anwendungen spielen nicht gut mit Symlinks als Ziel- / Datenordner. Und wenn die Anwendung die Konfiguration des Speicherorts des Datenverzeichnisses unterstützt, könnte dies auch erfolgen, um auf den Volume-Mount-Bereich zu verweisen. In meinem Anwendungsfall unterstützt die Anwendung die Konfiguration des Speicherorts des Datenverzeichnisses nicht, und die Realität ist, dass es immer Anwendungen geben wird, bei denen Sie Bindungsmounts oder Symlinks ausführen müssen, um ihren Daten- und Anwendungsbereich richtig zu trennen.

Diese Fähigkeit, dies A -> B -> C zu tun, ermöglicht es, die Datencontainer generisch zu halten und bietet Flexibilität in den verschiedenen Kombinationen, die Sie mit --volumes-from mit Anwendungs- und Datencontainern erreichen können.

Sie könnten dies auch erreichen, indem Sie eine Kette von Containern mit --volumes-from :

GenericDataContainer -> ApplicationDataContainer -> ApplicationContainer

Dies mag die richtige Antwort sein, aber Sie könnten die Erstellung eines weiteren Containers für die Anwendungsdaten vermeiden, wenn der Anwendungscontainer einen Bind-Mount ausführen könnte.

Ich kann dies heute erreichen, indem ich den Container im privilegierten Modus ausführe und dann die Mount-Bindung ausführe, aber wie Sie unten sehen werden, gibt es keine Möglichkeit, dass diese Mount-Bindung bestehen bleibt und sie muss jedes Mal neu gestartet werden, wenn Sie den Container starten . Symlinks werden bei Commits beibehalten.

Die Antwort für meinen speziellen Anwendungsfall könnte darin bestehen, den 3-Ketten-Container-Ansatz oder das Init-Skript zu verwenden, aber die Möglichkeit, Mounts Intracontainer (oder andere privilegierte Befehle) aus der Dockerfile zu binden, wäre schön. Es gibt wahrscheinlich noch andere Anwendungsfälle für Bind-Mounts, die beschrieben werden könnten, die keine Host-zu-Container-Zuordnung beinhalten, die nicht durch das Verketten von Datencontainern gelöst werden kann.

Ich bin mir nicht sicher, ob dies mit einem bind-mount-spezifischen Problem zusammenhängt oder eher, aber wenn die Ergebnisse privilegierter Befehle bei einem Docker-Commit bestehen bleiben, können Sie das Erstellen des Docker-Images und die Ausführung des Docker-Images trennen. Sie könnten den Bereich steuern, in dem Sie den Docker-Build ausführen, und Endbenutzer erhalten nur den festgeschriebenen Container, den sie im unprivilegierten Modus ausführen können. Dies ist derzeit nicht die Ursache, wenn Sie einen Bind-Mount und einen Commit ausführen. Dies könnte jedoch eher damit zusammenhängen, wie /proc/mounts funktioniert.

Hier ist ein einfaches Beispiel

[root@ip-10-0-3-202 ~]# docker run --privileged -i -t --name test_priv centos:centos6 /bin/bash
[root<strong i="17">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Erstellen Sie ein Bind-Mount-Beispiel, erstellen Sie auch ein Symlink-Beispiel

[root<strong i="6">@d1d037cb170c</strong> /]# mkdir /var/data1
[root<strong i="7">@d1d037cb170c</strong> /]# mkdir /var/data2
[root<strong i="8">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2
[root<strong i="9">@d1d037cb170c</strong> /]# ln -s /var/data1 /var/data3

Datei anzeigen wird in allen 3 Verzeichnissen angezeigt

[root<strong i="13">@d1d037cb170c</strong> /]# touch /var/data1/test
[root<strong i="14">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="15">@d1d037cb170c</strong> /]# ls /var/data2
test
[root<strong i="16">@d1d037cb170c</strong> /]# ls /var/data3
test

/proc/mounts aktualisiert anzeigen

[root<strong i="21">@d1d037cb170c</strong> /]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 /var/data2 ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0

Verlassen Sie den Container, der ihn stoppt, und starten Sie dann erneut

[root<strong i="25">@d1d037cb170c</strong> /]# exit
[root@ip-10-0-3-202 ~]# docker start -a -i test_priv
test_priv

/proc/mounts fehlt das Bindemount

[root<strong i="7">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Symlink hat überlebt, aber Mount nicht gebunden

[root<strong i="11">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="12">@d1d037cb170c</strong> /]# ls /var/data2
[root<strong i="13">@d1d037cb170c</strong> /]# ls /var/data3
test
[root<strong i="14">@d1d037cb170c</strong> /]#

Bind-Mount neu starten

[root<strong i="18">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2

Anstatt den Container zu verlassen, trennen Sie ihn mit ctrl+p ctrl+q und übergeben Sie dann den Container

Übergeben Sie den Container als neues Image, starten Sie einen neuen Container aus dem Image im nichtprivaten Modus

[root@ip-10-0-3-202 ~]# docker commit test_priv test_priv
74305f12076a8a6a78f492fd5f5110b251a1d361e63dda2b167848f59e3799e2
[root@ip-10-0-3-202 ~]# docker run -i -t --name test_nonpriv test_priv /bin/bash

Überprüfen Sie die /proc/mounts
bind mount fehlt, nicht sicher, was die zusätzlichen /proc/[sys,sysrq-trigger,irq,bus,kcore]-Mounts ausgelöst hat

[root<strong i="5">@ba1ba4083763</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-ba1ba40837632c3900e4986b78d234aefbe678a5ad7e675dbab7d91a9a68469e / ext4 rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs ro,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
proc /proc/sys proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/sysrq-trigger proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/irq proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/bus proc ro,nosuid,nodev,noexec,relatime 0 0
tmpfs /proc/kcore tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0

Symlink hat überlebt

[root<strong i="9">@ba1ba4083763</strong> /]# ls /var/data1
test
[root<strong i="10">@ba1ba4083763</strong> /]# ls /var/data2
[root<strong i="11">@ba1ba4083763</strong> /]# ls /var/data3
test
[root<strong i="12">@ba1ba4083763</strong> /]# exit

Ich versuche derzeit, Docker-Images in meinem Build-Schritt mit dind auszuführen . Gibt es derzeit also keine Möglichkeit, Docker-Images in Ihrem Build zu verwenden?

Jeder, wenn Sie dies wünschen, versuchen Sie es mit '/usr/bin/unshare -f -m -u -i -n -p -U -r -- /path/to/binary'. Dadurch wird innerhalb Ihres Builds ein Container mit einem Benutzernamensraum erstellt. Sie können die Optionen zum Aufheben der Freigabe nach Bedarf anpassen. Ich verwende dies tatsächlich, um '/sbin/capsh' auszuführen, um die Fähigkeiten für meine Prozesse granular festzulegen.

Ich kann nicht sagen, dass dies alle Anwendungsfälle für privilegierte Builds löst, aber es sollte einigen von Ihnen helfen.

Ich stimme zu, dass dies Teil von Docker selbst werden sollte, und die Integration von Benutzernamensräumen scheint im Gange zu sein.

@saulshanabrook Sie können Docker-Images nicht in einem Build ausführen, nicht genau. Ich hoffe, dass dies eines Tages bald möglich sein wird. Ich habe dies untersucht und festgestellt, dass Sie innerhalb eines Builds einen "Docker-Pull" durchführen können, solange Sie VFS-Speicher verwenden. Praktischerweise funktioniert auch 'Docker Save'.

Es ist keine wirkliche Lösung für jemanden, der Docker-Images ausführen möchte, aber ich möchte darauf hinweisen, dass 'unshare' und 'capsh' funktionieren, daher ist es möglich, eine containerähnliche Laufzeit in nicht privilegierten Containern auszuführen (z. B. während eines Builds). ). Es ist wohl möglich, 'Docker Run' zu umgehen und diesen Schritt manuell auszuführen und Bilder erneut in Docker zu übertragen. Das meiste davon habe ich heute in Arbeit, auch wenn ich nicht alles in eine Schleife gewickelt habe. Irgendwann muss diese Funktionalität natürlich in Docker selbst integriert werden.

+1 für Docker Pull über RUNP

Die Unfähigkeit, Docker-Build privilegiert auszuführen, fördert das manuelle Erstellen mit einem Shell- und Docker-Commit, wodurch Dockerfiles sinnlos werden. Ich glaube nicht, dass das Hinzufügen eines privilegierten Flags zum Docker-Build eine Grenze zwischen Builds und privilegierten Builds ziehen würde; diese Linie wurde bereits gezeichnet, als das Flag zum Ausführen hinzugefügt wurde und muss unterstützt werden.

+1 Dies macht den Docker-Container zu einem beliebigen Zeitpunkt reproduzierbar (muss nur die Dockerdatei allein tragen)

+1 Ich muss meine Ansible-Basisrollen vollständig auseinandernehmen, nur um solche Dinge zu umgehen. Ich hatte wirklich gehofft, dass ich durch die Docker-Einführung einen Großteil meines vorhandenen Ansible-Codes verwenden kann, aber ich habe nicht nur bereits benutzerdefinierte Rollen für die Größe erstellt, sondern muss jetzt auch Probleme wie dieses umgehen.

@lsjommer was für Dinge musst du

Ich sage nicht, dass wir dies nicht implementieren sollten, aber lass uns real werden, worüber wir sprechen.

Auch dies wäre relativ einfach zu implementieren, wenn jemand darauf eingehen möchte...

@ cpuguy83 Dies ist von unserer Standard-
http://pastebin.com/P3QQxjNQ

Ich gebe zu, dass ich nicht ganz verstehe, wie Docker mit der Ressourcenfreigabe umgeht.

@ljsommer Das Einstellen von shm ist also insgesamt ein anderes Tier und würde sowieso nicht zwischen RUN-Befehlen bestehen (oder wenn Sie tatsächlich docker run ).

@ cpuguy83 Ja, ich denke, das war hauptsächlich meine Schuld, da ich auf ein Problem
Vielen Dank, dass Sie sich die Zeit genommen haben, zu antworten, und entschuldigen Sie, dass ich mich nicht angemessen erzogen habe, bevor Sie sich beschweren.
;)

Irgendeine Idee zu RUNP / -privilegiert während des Build-Prozesses?
Es wäre großartig, IP-Tabellen festzulegen, um den Docker-Zugriff auf angegebene IP-Adressen zu beschränken

Ich möchte auch RUNP und/oder "docker build --privileged".

FROM ubuntu:latest
MAINTAINER xyz

RUN apt-get -qq update
RUN apt-get -yq install iptables

RUN iptables -t nat -I OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8080 && iptables-save > /etc/iptables.rules

Dieses Dockerfile funktioniert aufgrund des folgenden Fehlers nicht, funktioniert aber mit "docker run --privileged" ...

getsockopt failed strangely: Operation not permitted

@malcm , @sakurai-youhei: selbst wenn Sie so etwas wie RUNP , würde es in diesem Szenario nicht funktionieren, da iptables-Regeln nicht im Dateisystem beibehalten werden.

Lassen Sie mich erklären: Wenn Sie RUN x ausführen, führt Docker x dann einen Snapshot des Dateisystems. Dinge außerhalb des Dateisystems (laufende Prozesse, Routing-Tabellen, iptables-Regeln, sysctl-Einstellungen...) werden nicht in Docker-Images gespeichert.

Wenn Sie benutzerdefinierte iptables-Regeln wünschen, ist eine Methode:

• starte deinen Container zB mit --name myapp
• einen anderen Container starten, privilegiert, einmalig, um die iptables-Regel einzurichten, zB docker run --net container:myapp --privileged iptablesimage iptables -t nat ...

Ist das sinnvoll?

@jpetazzo : Danke für deine Antwort. In meinem Fall setze ich den zweiten Befehl ein, damit die iptables-Regel als Daten im Dateisystem wie unten beschrieben bestehen bleibt. Dies sollte es mir ermöglichen, die iptables-Regel zu laden, nachdem ich den Container mit der Option --privileged gestartet habe.

RUN do-something-with-iptables && iptables-save > /etc/iptables.rules

Ohne RUNP oder "build --privileged" muss ich so schreiben:

ADD iptables.rules /etc/

Ja, dies könnte ausreichen, aber ich muss iptables.rules neben Dockerfile in meinem Repository hinzufügen.

Deshalb möchte (oder möchte ich schonend) RUNP haben. :)

@jpetazzo @strib
Abgesehen von iptables-Problemen, Mounts und anderen privilegierten Operationen, denke ich, dass es ein Build-Szenario gibt, das wir ansprechen sollten.

Wir liefern Appliances für den Einsatz in VMs und Bare-Metal-Installationen. Zum Testen verwenden wir jedoch Containerumgebungen. In diesen Geräten betreiben wir wiederum Container. Testcontainer müssen also auf Docker-in-Docker basieren. Stellen Sie sich nun vor, dass wir ein Service-Image haben, das im Test-Image vorab geladen werden muss (damit Service-Images in der Testzeit nicht aus der Registrierung heruntergeladen werden). Im Moment können wir das nicht tun, da wir den d-in-d-Container während des Builds des Dockerfiles, das d-in-d als Basis verwendet, nicht im privilegierten Modus ausführen können: Docker-Daemon startet nicht, "docker pull" " oder "Docker laden" funktioniert nicht.

Ich hatte ein Problem, bei dem su bei der Ausführung auf einem RHEL7-Host fehlschlagen würde, wenn der aktuelle Benutzer root war. Seltsamerweise funktionierte su gut, wenn der aktuelle Benutzer ein anderer war. Unabhängig davon bestand die Problemumgehung darin, dem Ausführungsbefehl das Flag --add-cap=SYS_RESOURCE ; Aufgrund dieses Problems war dies jedoch während des Build-Schritts nicht möglich.

+1 Scripting um Dockerfiles mit docker run und docker commit herum ist lächerlich. Bitte binden Sie diese Funktion ein.

+1 zur Notwendigkeit dieser Funktion. Ich denke, dass eine globale "Sicherheitsstufe" in einer Konfigurationsdatei konfiguriert werden könnte, die die Fähigkeiten einschränkt, die einem Container gegeben werden können. Es sollte einen sicheren Standard geben (wie heute) und ein Systemadministrator könnte ihn ändern, damit Container mit mehr Berechtigungen ausgeführt werden können. Dockerfiles mit einem solchen RUNP-Befehl könnten mit einer Meldung wie "diese Dockerfile erfordert die folgenden Fähigkeiten .... zum Erstellen" auf einem System mit solchen globalen Beschränkungen nicht ausgeführt werden.

Ich denke, dies ermöglicht ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit.

Wir haben dieses Problem auch beim Versuch, ein Image mit einer evli-proprietären DB zu erstellen, die namenlos bleiben soll.
Die DB möchte riesige Mengen an Speicher zuweisen, was Docker nicht erlaubt.

Unsere aktuelle Problemumgehung ist ein 2-Phasen-Build mit einem run --privileged-Schritt und einem separaten Commit-Schritt.

Vielleicht könnten wir Docker so konfigurieren, dass die Speicherzuweisung auf andere Weise möglich ist. Es ist ein bisschen schwierig herauszufinden, was die DB tatsächlich tun will, da sie proprietär ist.

+1
für diese Funktion.
für historische und Anwendungsfallbeispiele siehe dieses Dupe
https://github.com/docker/docker/issues/12138#issuecomment -90536998
danke @cpuguy83 für den Hinweis auf den Dupe

Ich habe auch dieses Problem. Der Versuch, sich während des Docker-Builds in eine cifs-Freigabe einzuklinken, ist nicht zulässig, es sei denn, das privilegierte Flag wird bereitgestellt.

Es gibt jetzt einen Pull-Request, der dies implementiert; Sie können dort den Fortschritt überprüfen; https://github.com/docker/docker/issues/12261

Wenn etwas einen privilegierten Modus erfordert, modifiziert dies möglicherweise den Host in irgendeiner Weise, was bedeutet, dass das Image möglicherweise nicht portierbar ist, da diese Änderungen auf anderen Hosts ausgeführt werden müssten, die versuchen, das Image zu konsumieren.

Sobald #13171 zusammengeführt ist, sollten wir dies meiner Meinung nach schließen, da dies das Rollen Ihres eigenen Builders trivial macht und daher --privilegiert ist.
Ich denke nicht, dass das eingebaute docker build zulassen sollte.

Also @cpuguy83 , wenn ich das richtig verstehe, besteht die Möglichkeit, dieses Problem zu unterstützen, darin, docker build vollständig neu zu implementieren, jedoch mit einem zusätzlichen Parameter?

Ich denke, wenn der andere Patch durchgezogen ist, müsste ich meine eigene Version von docker build (vielleicht docker pbuild ?) zusammenstellen, um die zusätzliche Funktionalität auszufüllen?

Gibt es Fortschritte zu diesem Thema? Ich habe die oben genannten PRs überprüft und alle sind fehlgeschlagen.
Ist es möglich, eine BUILD --privileged/--granted Option granularer zu gestalten und gewährte Zugriffe auf eine bestimmte Gruppe von Host-Ressourcen nur auf den Image-Builder/Eigentümer zu beschränken?

+1 für jede Lösung, die es mir ermöglicht, RUN docker pull in einem Dockerfile zu machen.

Anwendungsfall: Ich benötige eine Reihe von Tools für die Bildkonvertierung und Dokumentationserstellung, jedoch können alle diese Tools aufgrund widersprüchlicher Bibliotheken nicht in einem einzigen Image installiert werden. Deshalb trenne ich einige dieser Werkzeuge in ein separates Bild und möchte alle Werkzeuge in einem einzigen Bild, also Bild in einem Bild, verteilen. Deshalb möchte ich RUN docker pull in meinem Dockerfile machen.

@cpuguy83 es sieht nicht so aus, als ob dieses Problem zu jedermanns Zufriedenheit gelöst wurde. Ich muss unbedingt zu 100% in der Lage sein, während eines Builds etwas so langweiliges wie Schreiben in /proc/sys/kernel/core_pattern zu tun.

In der aktuellen Welt kann ich diese privilegierte Operation über einen run Workaround ausführen und dieses Image sowieso einfach an den Hub übertragen. Außerdem ist kein Dockerfile ich _jemals_ produziert habe, strikt reproduzierbar, da sie aus zufälligen, sich ständig ändernden öffentlichen Repos stammen. das hatte ich nicht gewusst

1. Der öffentliche Konsum meiner Bilder stand im Vordergrund.
2. Sie hatten jemals das Bedürfnis, reproduzierbar zu sein.

Die Leute _werden_ beschissene Workarounds machen, um privileged im Build zu bekommen. Ich denke, Sie sollten auf jeden Fall dorthin gehen, wo Ihre Benutzer sind, und dies im Core-Build-Tool zulassen. Fügen Sie bei Bedarf eine erschreckende Nachricht hinzu.

cc @thaJeztah , der mit dieser Position sympathisiert

Sehen Sie, ich habe eine PR erstellt, um dies zu ermöglichen, und sie wurde abgelehnt.
Ich sehe nicht, dass dies mit dem Builder in irgendeiner Form passiert.

Es schien, als hätten Sie den letzten Anruf getätigt. Ich werde dann im PR-Thread selbst agitieren.

Dies ist für die Installation der älteren JDK 1.6-Pakete unter CentOS erforderlich, da der Registrierungsversuch der RPMs binmft_misc fehlschlägt, ohne unter --privileged ausgeführt zu werden.

Dockerbuild ist ein Nicht-Stater, um damit Container zu bauen.

zu replizieren

VON Centos5.11
RUN yum intall -y jre-1.6.0_29-fcs

Wir müssen einen privilegierten Befehlsteil von build als optionales Flag haben. Ich versuche, eine unserer Anwendungen als POC auf Docker zu portieren, und es schlägt für eine unserer Komponenten fehl, da IPtables-Einstellungen nicht angewendet werden und der Build fehlschlägt. Ich kann die notwendigen Änderungen manuell vornehmen und festschreiben, aber was ist dann der Spaß am Docker-Build. Es ist nur ein Teil des Builds und sollte einfach zu portieren sein, da es bereits Teil der Hauptversion ist.

Docker sollte problemlos in der Lage sein, Zwischencontainer mit privilegierten Optionssätzen auszuführen.

@shubhamrajvanshi wir sind dabei, den "Builder" aus dem Daemon (und zum Client) zu verschieben, dies sollte die Tür für weitere Anpassungen des Build-Prozesses öffnen (einschließlich der Möglichkeit, benutzerdefinierte Builder zu implementieren). Eventuell kann in Betracht gezogen werden, "privilegierte" Builds zuzulassen, aber das ist eine Entscheidung, die nach dem Refactoring getroffen werden kann. (Siehe https://github.com/docker/docker/blob/master/ROADMAP.md#122-builder)

@shubhamrajvanshi Sie können aus gutem Grund keine Änderungen an iptables im Build vornehmen, die Einstellungen würden niemals haften.

Es gibt nur sehr wenige Dinge, die man mit --privileged machen kann, die im Build sogar Sinn machen.

@thaJeztah Danke das wäre hilfreich.
@ cpuguy83 Wäre dies der Fall, auch wenn ich das iptables-persistent-Paket für das Image verwende.

Dies würde die Regeln auf der Festplatte speichern, dann müssten sie leider immer noch neu geladen werden.

_BENUTZER-UMFRAGE_

_Der beste Weg, um über Änderungen in dieser Diskussion benachrichtigt zu werden, besteht darin, oben rechts auf die Schaltfläche Abonnieren zu klicken._

Die unten aufgeführten Personen haben Ihre aussagekräftige Diskussion mit einem zufälligen +1 gewürdigt:

@karelstriegel

Ich würde dies auch sehr gerne haben, um die Verwendung der CUDA-Treiber von nVidia mit Docker auf CoreOS zu ermöglichen. Das von ihnen bereitgestellte Installationsprogramm erstellt ein Kernelmodul anhand der Kernelquelle und installiert es dann mit modprobe. Ich kann nicht sehen, wie ich es ohne eine Art --privileged-Option zum Build zum Laufen bringen kann.

Warum nicht standardmäßig den privilegierten Modus beim Build unterstützen?

+1
Ich möchte den MySQL-Befehl in Dockerfile für centos7 verwenden.
Natürlich können wir entrypoint.sh verwenden, aber es ist nützlicher, wenn wir -privileged sowohl zum Erstellen als auch zum Ausführen verwenden können.

--privileged ist nicht erforderlich, um den MySQL-Befehl auszuführen.

Dieses Problem sollte geschlossen werden, da dies anscheinend nicht passieren wird (oder sogar passieren sollte).
Privileged in build zuzulassen bedeutet, dem Builder zu erlauben, Dinge auf dem Host zu ändern, was wiederum dazu führt, dass das Image nur auf diesem Host (oder auf Hosts mit ähnlichen Modifikationen) funktioniert.

Privileged in build zuzulassen bedeutet, dem Builder zu erlauben, Dinge auf dem Host zu ändern, was wiederum dazu führt, dass das Image nur auf diesem Host (oder auf Hosts mit ähnlichen Modifikationen) funktioniert.

Trifft dies auf den Benutzerfall chroot zu?

Ich versuche herauszufinden, wie man dpkg-depcheck -d ./configure ohne so etwas macht.

Während des Builds (oder der Ausführung ohne --priviledged) erhalte ich die folgende Fehlermeldung - ich habe keine Ahnung, wie ich herausfinden soll, welche Berechtigung es benötigt oder wie man es aktiviert.

dpkg-depcheck -d ./configure
strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Permission denied
strace: test_ptrace_setoptions_followfork: unexpected exit status 1
Running strace failed (command line:
strace -e trace=open,execve -f -q -o /tmp/depchJNii2o ./configure
devel<strong i="8">@98013910108c</strong>:~/src/cairo-1.14.2$ 

Nach ungefähr 3 Jahren und 162 Kommentaren denke ich, dass es genug Interesse hat. Die Bemerkungen, dass ein privilegierter Modus für die meisten der zitierten Fälle nicht erforderlich ist, sind wahr, sogar meine eigenen; sollte jedoch nicht verwendet werden, um Dinge zu verbieten, die für lokale, temporäre, explorative und/oder zweckmäßige Builds nützlich sein könnten. Veröffentlichen Sie Warnungen, bis die Kühe eine Harmonie herausfurzen, drucken Sie Befehlszeilenwarnungen aus, beschimpfen und verurteilen Sie ihre Verwendung, aber geben Sie den Menschen Flexibilität. Portabilität ist nicht immer das Hauptinteresse aller.

_BENUTZER-UMFRAGE_

_Der beste Weg, um über Updates informiert zu werden, ist die Schaltfläche _Abonnieren_ auf dieser Seite._

Bitte verwenden Sie keine "+1"- oder "Das habe ich auch"-Kommentare zu Problemen. Wir automatisch
sammle diese Kommentare, um den Thread kurz zu halten.

Die unten aufgeführten Personen haben dieses Problem positiv bewertet, indem sie einen +1-Kommentar hinterlassen haben:

@robeferre

+1

Ich muss wirklich ein NFS-Volume in einem Docker-Container mounten, bis jetzt konnte ich die NFS-Freigabe nicht ohne das Flag "--privileged=true" erstellen. Der beste Fall ist meiner Meinung nach, das Image mit einem privilegierten Befehl zu erstellen. Wie ist das möglich?

+1

Step 19 : RUN lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root
 ---> Running in 4c51b7cf0058
lxc_container: lxccontainer.c: create_run_template: 893 error unsharing mounts
lxc_container: lxccontainer.c: create_run_template: 1084 container creation template for percise failed
lxc_container: lxc_create.c: main: 274 Error creating container percise
The command '/bin/sh -c lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root' returned a non-zero code: 1

Ich versuche, gobject-introspection im Gentoo-System im Docker während des Builds zu installieren, aber es schlägt mit diesem Fehler fehl:

• ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation nicht erlaubt

Das gleiche Ergebnis, wenn ich versuche, es manuell im Container zu installieren, aber wenn ich es aus einem Container versuche, der im privilegierten Modus gestartet wurde (docker run --privileged), funktioniert es gut.

Das gleiche Problem, wenn ich versuche, glibc zu installieren.

Ich benötige also auch eine Möglichkeit, einen privilegierten Befehl während des Builds auszuführen.

Ich verwende Docker-Version 1.10.1 und das Problem mit glibc tritt in 1.9 nicht auf

In Version 1.10 ist etwas kaputt und wir können keine 32-Bit-Container bauen, weil das Netzwerk nicht verfügbar ist
--privileged oder --security-opt seccomp:unconfined für BUILD - ist wirklich notwendig.
Oder entsprechende Direktiven in Dockerfile

großes +1 von mir

Es ist ein echtes Problem für mich, dass ich den Befehl 'mount' während des Builds nicht verwenden kann.
Ich habe versucht, die Einschränkung zu überwinden, dass ein Hostverzeichnis während des Builds nicht in einen Container gemountet werden kann, also habe ich einen NFS-Server auf dem Host eingerichtet und versucht, eine NFS-Freigabe zu mounten, nur um herauszufinden, dass dies aufgrund des unprivilegierten Modus nicht möglich ist.

In meinem Anwendungsfall muss ich einige Dinge im Image installieren, ohne sie in den Build-Kontext zu kopieren, und sie vor der Installation HINZUFÜGEN.

Fühlt sich an, als ob ich ohne Optionen geblieben wäre.

thaJeztah verwies auf dieses Problem am 10. März
Regression im LTTng-Verhalten nach dem Upgrade auf 1.10.2 #20818 Geschlossen

Nein, es ist nicht geschlossen, wir verwenden 1.11.0-0~wily und in 32-Bit-Containern funktioniert das Neworking nicht seit 1.10.0, aber 1.9.x hat gut funktioniert.
Nur -privileged kann uns helfen, Container zu starten. Aber wir können nicht neu bauen

Ich bin erstaunt, dass etwas, das so offensichtlich von so vielen Leuten gebraucht wird, nicht implementiert wurde, obwohl die Leute 2,5 Jahre lang allein in diesem Thread darum gebettelt haben und da Leute PRs eingereicht haben, um diese Funktionalität zu implementieren.

Einverstanden @ctindel , dieses Problem ist einer der Gründe, warum ich von Docker zu rkt migriere .

@ctindel Es ist etwas, das wir nicht implementieren oder unterstützen können. Die Implementierung selbst ist ziemlich einfach (ich habe sie sogar selbst implementiert, damit wir diskutieren können), daran liegt es nicht.

--privileged ist ein Panzer, und es ist gefährlich, ihn beim Bau zuzulassen, und wirkt sich stark auf die Portabilität von Bildern aus.

Brian,

Wenn Sie einen Workaround haben, können Sie ihn bitte auch mit mir teilen. Ich würde
Ich weiß es zu schätzen.

Vielen Dank
Shubham Rajvanshi
669-300-8346

Am Montag, den 2. Mai 2016 um 14:30 Uhr schrieb Brian Goff [email protected] :

@ctindel https://github.com/ctindel Dazu sind wir noch nicht bereit
umsetzen oder unterstützen. Die Implementierung selbst ist ziemlich einfach (ich sogar
selbst implementiert, damit wir darüber diskutieren können), darum geht es nicht.

--privilegiert ist ein Panzer, und es ist gefährlich, ihn beim Bau zuzulassen, und
wirkt sich stark auf die Portabilität von Bildern aus.

—
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/1916#issuecomment -216369957

Ich verstehe die Auswirkungen auf die Portabilität nicht. Wie wirken sich privilegierte Operationen zur Build-Zeit auf die Portabilität aus? Ich meine, es ist nicht schwer, nicht tragbare Images auf verschiedene Weise mit oder ohne Privilegien zu erstellen, aber gibt es eine Möglichkeit, dass Images, die mit privilegierten Operationen erstellt wurden, notwendigerweise nicht portabel sind?

Ich glaube nicht, dass jeder Container tragbar sein muss. Einige Container werden erstellt, um sie für die Community freizugeben, und andere werden möglicherweise für die Bereitstellung interner Anwendungen erstellt.

Das Portabilitätsproblem bei einer App, die im privilegierten Modus ausgeführt werden muss, liegt in der App selbst.

Der privilegierte Modus ist der letzte Ausweg, um die App ohne Codeänderungen zum Laufen zu bringen.

Ich glaube, dass ein Image-Builder, der die Erstellung im privilegierten Modus erfordert, versteht, dass ein solcher Container möglicherweise auch im privilegierten Modus ausgeführt werden muss.

Es sollte klar dokumentiert werden, dass vom Bauen im privilegierten Modus abgeraten wird, da dies zu Portabilitätsproblemen führen kann.

Gesendet von Outlook Mobilehttps://aka.ms/blhgte

Am Montag, den 2. Mai 2016 um 14:53 -0700 schrieb "Trevor Blackwell" < [email protected] [email protected] >:

Ich verstehe die Auswirkungen auf die Portabilität nicht. Wie wirken sich privilegierte Operationen zur Build-Zeit auf die Portabilität aus? Ich meine, es ist nicht schwer, nicht tragbare Images auf verschiedene Weise mit oder ohne Privilegien zu erstellen, aber gibt es eine Möglichkeit, dass Images, die mit privilegierten Operationen erstellt wurden, notwendigerweise nicht portabel sind?

Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/docker/docker/issues/1916#issuecomment -216375159

@tlbtlbtlb Weil der privilegierte Modus Ihnen vollen Zugriff auf den Host gibt. Vielleicht habe ich etwas Einfaches wie shmmax oder etwas viel Schlimmeres eingestellt.
Ich garantiere, dass diese Dinge am ersten Tag passieren werden, an dem dies verfügbar ist.

@davidl-zend "portabel" bedeutet nicht, mit der Community zu teilen. Es bedeutet, von einer Maschine zur anderen zu wechseln.

@cpuguy83 Wie andere bereits darauf hingewiesen haben, gibt es auch viele andere Möglichkeiten, die Portabilität von

Angesichts der Kommentare, die ich in verschiedenen Foren gesehen habe, bin ich bereit zu wetten, dass VIELE Leute genau dies bereits tun, um die heute bestehende Docker-Beschränkung zu umgehen.

Wenn Sie eine Architektur haben, in der die Portabilität von Bildern auf Dutzende anderer Arten beeinträchtigt ist, was bringt es dann, sich gegen diese spezielle Windmühle zu neigen?

Offensichtlich könnten Sie Docker Hub oder travis-ci nicht mehr erstellen lassen, aber die Leute, die es mit dem Berechtigungsmodus benötigen, würden das sowieso verstehen.

@ctindel Ich würde gerne einige Beispiele dafür sehen, wie die Portabilität von

So etwas beim ersten Containerstart zu machen, ist _genau_ der richtige Weg.
Es handelt sich um eine Laufzeitkonfiguration, die nicht im Image enthalten sein sollte.

@ cpuguy83 Diskutieren Sie über die Tatsache, dass jemand einen teilweisen Build aus einer Dockerdatei durchführen, einen Container im privilegierten Modus hochfahren, weitere Änderungen vornehmen und dann einen Docker-Commit durchführen könnte? Inwiefern unterscheidet sich das von einem Build im privilegierten Modus? Denn das machen heute andere.

Ich versuche nicht, gereizt zu sein, ich sage nur, dass dies eine schwerwiegende Einschränkung der Plattform ist, an der die Leute auf unangenehme Weise arbeiten.

Zum Beispiel gibt es Debian-Pakete von Drittanbietern (und wahrscheinlich RPMs), die nicht korrekt installiert werden können, es sei denn, Sie haben bestimmte Fähigkeiten im System. Die Installation eines Debian-Pakets ist keine "Laufzeitkonfiguration", sondern ein verdammter Teil des Installationsprozesses.

@ctindel Ich diskutiere das überhaupt nicht. Der Unterschied besteht darin, das Verhalten zu unterstützen. Wenn es keinen Unterschied gäbe, würden wir diese Diskussion nicht führen.

Für mich bin ich ein zustimmender Erwachsener und möchte in der Lage sein, ein Packstack- Image über eine Reihe von Knoten zu rollen. Bauen mit Dockerfile-Bomben derzeit, also muss ich schummeln, um die Docker-Beschränkungen zu umgehen.

@cpuguy83 Es ist mir (und ich denke, anderen in diesem Thread) immer noch sehr unklar, was genau gewonnen wird, wenn diese Option nicht bereitgestellt wird, die die Leute auf andere Weise umgehen. Die Art von architektonischer Reinheit (ich habe kein besseres Wort dafür), für die Sie zu argumentieren scheinen, war in dem Moment, in dem die Commit-Option hinzugefügt wurde, sowieso verschwunden, daher verstehe ich wirklich nicht, was es für einen Unterschied gibt, ob es über a erfolgt Dockerfile mit privilegiertem Build oder über einen Docker-Commit in einem privilegierten Container.

Abgesehen davon, dass ein Weg eine verdammte PITA für die Leute ist und ein Weg sich sehr gut in den aktuellen Mechanismus des Bauens mit Dockerfile einfügt.

Außerdem hast du meine Frage nicht beantwortet. Warum betrachten Sie die einfache Installation eines Debian-Pakets (oder Packstack) eines Drittanbieters als "Laufzeitkonfiguration"?

@ctindel Portabilität. Nur weil etwas getan werden kann, heißt das nicht, dass es unterstützt wird, und es in build , was es für jeden bequem macht, bedeutet es, dass es unterstützt wird.
Wir _werden_ mit Problemen überflutet werden, in denen Images zwischen Hosts nicht funktionieren... was im Grunde den ganzen Grund für Docker zunichte macht.

Wenn ein Paket erfordert, dass --privileged überhaupt installiert wird, dann sollte es mit dem Paket adressiert werden. Die Installation sollte nicht --privileged erfordern ... und wenn sie es wirklich erfordert, dann ist dies ein Zeichen dafür, dass die Installation selbst nicht portabel ist (erfordert Änderungen auf dem Host) ... Sehen Sie, dass Docker in einem Container ohne --privileged lauffähig ist (beachten Sie, dass dies lauffähig ist, Sie können alles ohne Probleme ohne --privileged installieren, was Sie wollen).

Aber wenn es über Docker-Commit ausgeführt werden kann, wird es auch unterstützt!

Ich verstehe nicht, du zwingst viele Leute dazu, Einschränkungen in diesem Produkt zu umgehen, weil du befürchtest, dass sich jemand persönlich bei dir über irgendein nicht unterstütztes Bild beschweren wird?

Sie haben meine Frage immer noch nicht beantwortet, warum die Installation eines Pakets (ich rede hier nicht einmal von der Konfiguration) eine Aktion der "Laufzeitkonfiguration" ist. Nur "Portabilität" zu sagen, bedeutet nichts.

Gibt es etwas x86_64-spezifisches an Docker? Wird es nicht irgendwann Docker-Images geben, die für eine bestimmte CPU-Architektur erstellt werden? Sind sie dadurch nicht auch nicht tragbar? Ich meine, diese ganze Idee, dass man irgendwie immer in der Lage sein wird, jedes Docker-Image zu nehmen und es auf jedem Docker-Host der Welt auszuführen, unabhängig von Tonnen anderer Variablen, scheint sowieso unmöglich, also verstehe ich die superstarke Notwendigkeit nicht, zu pushen zurück zu dieser besonderen Funktion, nach der die Leute fragen.

Übrigens, ich möchte Ihnen hier für Ihre Antworten und Ihr fortgesetztes Engagement danken. Viele andere Github-Projekte, bei denen Issue-Threads ignoriert werden!

Ich stimme dem Punkt zu, dass Leute dies umgehen, indem sie docker run --privileged mit docker commit . Ich habe so eine Lösung bisher für zwei Firmen erstellt. Die Leute WERDEN solche Bilder machen, und es hat keinen Sinn, so zu tun, als ob es eine schreckliche, schreckliche Sache wäre.

Verdammt, wenn Sie Angst haben, Container zu unterstützen, die mit --privileged dann sagen Sie es einfach in der Dokumentation so klar, dass die Leute sich vollkommen bewusst sind, dass sie dies auf eigene Gefahr tun. Obwohl ich bisher keine negativen Auswirkungen gesehen habe. Aber andererseits haben wir nicht versucht, Container auf verschiedenen Distributionen auszuführen.

@PerilousApricot was verursacht eigentlich das Problem mit Packstack? Wir beheben gerne spezifische Probleme oder helfen dem Upstream bei deren Behebung, aber denken Sie nicht, dass das Hinzufügen von --privileged das einen völlig uneingeschränkten Root-Zugriff auf Ihren Hostserver ermöglicht, der richtige Weg ist, dies zu tun. Alle mir bekannten Fälle, in denen Leute spezifische Build-Probleme angesprochen haben, können im Allgemeinen behoben werden, da die meisten Dinge tatsächlich keinen Root-Zugriff auf dem Host-Rechner benötigen, um einen Build durchzuführen.

@justincormack Was ist die Lösung für ein Paket von Drittanbietern (dh kann nicht geändert werden), das seinen eigenen Dienst startet, bei dem das Init-Skript ein tmpfs-Dateisystem mounten muss? Ich meine, selbst wenn man --privileged ignoriert, gibt es vorerst auch keine Möglichkeit, ein --cap-add oder ein --security-opt apparmor:unconfined während eines Builds

@ctindel Es sollte nicht versucht werden, ein tmpfs bei der Installation einzuhängen. Wenn es zur Laufzeit tmpfs benötigt, ist es großartig, aber zur Installationszeit ist es mit Sicherheit nicht richtig.

@cpuguy83 Sie

Das ist der Sinn dieser ganzen Diskussion, Sie verhängen willkürliche Beschränkungen, die es viel schwieriger machen, Docker zu verwenden, weil Sie philosophische Bedenken bezüglich der Bitten um Unterstützung von Leuten haben, die "es falsch machen".

Das ist so, als würde man sagen, dass Betriebssysteme es nicht zulassen sollten, dass die Prozessplanungsklassen geändert werden, da dies zu einer Prioritätsinversion führen kann, wenn Sie es falsch machen. Oder dass niemand einen Hammer bauen sollte, weil man sich bei falscher Anwendung den Daumen schlagen kann.

Wie schon oft gesagt wurde, UNTERSTÜTZT Docker dies BEREITS über den Commit-Befehl, es ist nur für Ihre Benutzer schmerzhafter. Die Leute, die diese Funktion nicht wollen, werden sie nicht verwenden, und die zustimmenden Erwachsenen, die sie verwenden möchten, indem sie die Einschränkungen verstehen, können dies mit offenen Augen tun.

@ctindel Eher nein, du kannst mit dieser Atombombe nicht umgehen, weil du jeden in einem Umkreis von 50 km töten könntest.

Was braucht dieses Paket, um ein tmpfs während der Installation zu laden? Die Installation ist buchstäblich das Extrahieren von Dateien aus einem Archivformat in das Rootfs.

Alles kann geändert werden.
Es ist eine weitaus einfachere und sicherere Änderung im Upstream, kein tmpfs bei der Installation zu mounten, als Privileged on build zu aktivieren.

Bei Docker geht es um die Portabilität von Workloads. Das Aktivieren von Privileged on Build (oder zusätzliche Privilegien oder das Optimieren von Sicherheitsprofilen usw.) unterbricht dies grundlegend und ist etwas, das wir heute nicht akzeptieren können.

commit und build sind zwei sehr unterschiedliche Dinge, und nur weil es möglich ist, etwas auf eine Art zu machen, heißt das nicht, dass wir es auch auf jede andere Weise zulassen sollten.

FROM python

ENV PACKSTACK_VERSION 7.0.1
RUN cd /opt && git clone https://github.com/openstack/packstack.git \
  && cd packstack \
  && git checkout $PACKSTACK_VERSION \
  && rm -rf .git \
  && python setup.py install

Keine Berechtigungen erforderlich.

Die Kirche der Rentabilität.
Eines Tages wird die "erzwungene" Portabilität dieses Projekt zunichte machen - es tut es bereits.
So viele Funktionen werden wegen schwer fassbarer Portabilität verweigert, so viele Fortschritte werden deswegen nicht gemacht .....
Eines Tages wird jemand ein Projekt forken und die Portabilität optional machen. Träume ... Träume .... Amen.

Wenn wir es auf zwei Fälle herunterbrechen:

1. Installer, die leichtfertig privilegierte Operationen verwenden, wie das Mounten von tmpfs aus Leistungsgründen. Solche Installer könnten leicht repariert werden (aber möglicherweise nicht in naher Zukunft).

In diesem Fall ist es eine gültige Philosophie für Docker, sich schlecht verhaltende Installer zurückzudrängen. Die meisten Installer haben eine Art Workaround, der das Dockerfile nur etwas länger macht.

1. Installer, die grundsätzlich von privilegierten Operationen abhängen, wie die Installation von Kernelmodulen für GPU-Treiber. Auch diese sind grundsätzlich nicht tragbar. Sie funktionieren beispielsweise nicht auf Docker-Maschinen für Mac.

In diesem Fall ist die Docker-Erfahrung sowieso kaputt. Ich kann Docker-Rechner beispielsweise nicht auf einem Mac verwenden, ich kann das Image nur auf einem kompatiblen Ziel-Host-Rechner erstellen. Mein Anwendungsfall war die Installation der nVidia-GPU-Treiber auf einem Host-Betriebssystem (CoreOS), was von einer direkten Installation im Host-Betriebssystem abriet.

Also, ich glaube, ich bin gekommen, um die Tugend zu sehen, in jedem Fall --privilegierte nicht zu unterstützen. Ich denke, was mich dazu gebracht hat, meine Meinung zu ändern, ist die Bequemlichkeit, Bilder auf meinem Laptop mit der Docker-Maschine zu erstellen, anstatt meinen Code zuerst auf eine Ubuntu-Box zu übertragen und dort zu bauen.

@tlbtlbtlb Ich verstehe nicht, auf welche "Tugend" Sie sich beziehen. Betrachten Sie etwas, das nicht leichtfertig ist, aber es gibt Tonnen von Docker-Images, die in einer Umgebung ausgeführt werden können, in einer anderen jedoch nicht. Zum Beispiel können Sie ein Host-Volume in einen Mongodb-Container von Linux->Linux mounten, weil der mmapv1-Speichertreiber gut funktioniert, aber Sie können ein Mac OSX-Verzeichnis nicht über Virtualbox an einen Mongodb-Container auf Ihrem Laptop übergeben, weil die mmap-Sachen werden in diesem Fall nicht richtig funktionieren.

Mir ist klar, dass dies in Bezug auf das Erstellen kein Problem ist, aber die Idee, dass Docker-Images "portabel" sind und "überall laufen" können, ist an dieser Stelle völliger Unsinn. Wenn es der Fall ist, dass sie nirgendwo hinlaufen können, was ist dann die Tugend, zu sagen, dass sie in der Lage sein sollten, „überall bauen“ zu können?

Der Punkt ist, dass das Mongodb-Image überall funktioniert. Das Bereitstellen einer ungültigen Laufzeitkonfiguration ist ein anderes Tier.

Docker hat eine sehr spezifische und intestinale Trennung von tragbarer Konfiguration und nicht tragbarer Konfiguration.

Wie wäre es damit ?
Ich muss meine echten IPs im Container haben, um meine nginx-Konfigurationsüberprüfung durchzuführen.

das ist mein Dockerfile:

FROM ubuntu:14.04.4

RUN apt-get update
RUN apt-get install -y software-properties-common
RUN add-apt-repository ppa:nginx/stable
RUN apt-get update
RUN apt-get install -y nginx-full vim
RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
RUN ifconfig lo:1 192.168.168.57 netmask 255.255.255.0 up
RUN ifconfig lo:2 192.168.168.58 netmask 255.255.255.0 up

ADD . /etc/nginx

➜  nginx git:(ha-node-01) ✗ docker build -t nginx4test .
Sending build context to Docker daemon 976.4 kB
Step 1 : FROM ubuntu:14.04.4
 ---> 90d5884b1ee0
Step 2 : RUN apt-get update
 ---> Using cache
 ---> eea42cb6135d
Step 3 : RUN apt-get install -y software-properties-common
 ---> Using cache
 ---> 9db86ab17850
Step 4 : RUN add-apt-repository ppa:nginx/stable
 ---> Using cache
 ---> 5ed2266a93a9
Step 5 : RUN apt-get update
 ---> Using cache
 ---> 09fcfdc1fed3
Step 6 : RUN apt-get install -y nginx-full vim
 ---> Using cache
 ---> cc0c1662e009
Step 7 : RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
 ---> Running in 5d962ec4e35d
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFNETMASK: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
The command '/bin/sh -c ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up' returned a non-zero code: 255

Wenn ich den Container mit der Option Privilegien ausführe, kann ich natürlich die IP zur Loopback-Schnittstelle einrichten. Aber es ist ein weiteres Skript hinzuzufügen.

@cpuguy83 Ich habe ungefähr 20 Zeilen oder so von iptable Einträgen Ich würde gerne RUN in meinem Dockderfile eingeben, kann es aber nicht, da ich --cap-add=NET_ADMIN benötige. Diese Befehle sollten unabhängig davon ausgeführt werden, wer den Container ausführt und unabhängig davon, auf welchem ​​Computer er ausgeführt wird (der Container führt eine interne App aus). Wo/wie würden Sie vorschlagen, dass ich das basierend auf dem, was Sie oben besprochen haben, mache?

@MatthewHerbst Leider können/können iptables-Regeln das Bild nicht

@cpuguy83 Ich verwende ein centos:6 Image und kann /sbin/service iptables save ausführen, um die Regeln im Dateisystem beizubehalten. Ich glaube, es gibt eine ähnliche Funktion auf Ubuntu und anderen über das iptables-persistent- Paket.

Sie können einfach die iptables-Regeln für diese Datei generieren, das ist nicht erforderlich
diese tatsächlich anwenden. Die Netzwerksituation, in der der Container ausgeführt wird, kann
sehr unterschiedlich sein, also sollten Sie Regeln nur zur Laufzeit anwenden (wenn das so ist,
ist möglicherweise besser dran, wenn der Host sie generiert).

Am 16. Mai 2016 16:03 schrieb "Matthew Herbst" [email protected] :

@cpuguy83 Ich verwende CentOS und kann ausführen /sbin/service iptables speichern unter
die Regeln im Dateisystem beibehalten. Ich glaube, es ist ähnlich
unter Ubuntu und anderen über das Paket iptables-persistent.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an

@justincormack weiß nicht, warum ich nicht daran gedacht habe! Vielen Dank!

Wie sollen Sie Befehle ausführen, die Berechtigungen erfordern, wenn Sie docker service ? Ich muss den Hostnamen auf einigen meiner Maschinen festlegen, aber leider erfordert dies Privilegien.

@nostrebor das hat nichts mit diesem offenen Thema zu
Wir evaluieren, welche Optionen für Dienste vorhanden sein müssen, anstatt sie eins zu eins zu kopieren. Der privilegierte Modus wird es wahrscheinlich nicht in 1.12 für Dienste geben.

Ich versuche Docker-Builds, die etwas für die Installation kompilieren, aber es muss gegen Bibliotheken kompiliert werden, die auf einem CVMFS-Netzwerkdateisystem vorhanden sind. Natürlich kann ich CVMFS nicht mounten, ohne --privileged auszuführen, also kann ich es überhaupt nicht mit einer Dockerfile tun.

@cpuguy83 @tlbtlbtlb Dies ist ein Fall eines 'Installers', der grundlegend von privilegierten Aktionen

Ich verstehe nicht, wie das Einhängen eines Netzwerkdateisystems ein Portabilitätsproblem ist. (Alle unsere Zielumgebungen haben Zugriff auf dieses Dateisystem. Sie sind erforderlich, da sie anderen Code erstellen, der AUCH mit Binärcode im Netzwerkdateisystem verknüpft werden muss.)

Sollte ich einen anderen Ansatz versuchen? Sollte ich CVMFS auf dem Host mounten und dieses Verzeichnis mit dem Container teilen oder so? Ich möchte kein externes Build-System einrichten müssen, nur um dieses Image zu erstellen - das Image, auf dem es basiert, verfügt bereits über ein komplettes Build-System, das die Arbeit erledigt. Ich muss nur CVMFS mounten können.

Ich war aufgeregt, dies mit einem Dockerfile zu tun, aber es scheint, dass ich es mit einigen Skripten mit docker run --privileged die harte Tour machen oder etwas anderes anstelle von Docker verwenden muss. Gibt es eine Möglichkeit, ein Dateisystem in einem Container einzuhängen, _ohne_ privilegierten Zugriff zu haben?

Ich habe eine Problemumgehung gemacht, indem ich privilegierte Befehle in einem Skript platziert / echot und den CMD-Befehl verwendet habe, um das Skript am Container-Einstiegspunkt auszuführen. Nachdem ich ein solches Image erstellt habe, kann ich den Container einfach im privilegierten Modus ausführen und alles funktioniert.

@drstapletron , laut der CERN cvmfs-Dokumentation haben Sie vorerst zwei Möglichkeiten, entweder cvmfs vom Host in den Container zu mounten oder cvmfs in einem privilegierten Container zu installieren.

Für den zweiten Fall habe ich gerade eine Docker-Datei für cmssw-Jungs geschrieben, hier:
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

Mit dieser Datei können Sie einfach ein Image erstellen (oder Sie können es von cmssw dockerhub holen) und im P-Modus ausführen, und alles ist bereits im Container (ls /cvmfs/*)

Ich bin mir nicht sicher, ob dies oben behandelt wurde, da es sich um eine ziemlich lange Liste von Feedback zu diesem Thema handelt. Ich möchte auch --privileged build-Befehle haben. Mein aktueller Anwendungsfall besteht darin, ein Problem zu umgehen, auf das ich beim Erstellen des go ebuild auf einer Gentoo-Bühne gestoßen bin3. Wenn ich keinen Container verwende, führen die aktuellen Anweisungen im gentoo-Handbuch dazu, dass sich systemd unregelmäßig verhält, sobald ich 'umount -l /mnt/gentoo/dev{/shm,pts,} && umount -l /mnt/gentoo/{ proc,sys}' von einem System, das mit systemd gebootet wurde... Wenn ich meinen stage3-Build in einen Docker-Container verschiebe, funktioniert alles einwandfrei, bis ein Build ptrace oder eine andere eingeschränkte Funktion erfordert... was go-1.7.1. ebuild scheint zu erfordern.

Im Moment führe ich den Build einfach innerhalb eines Docker-Run-Befehls aus, übertrage und setze ihn dann fort, aber es wäre vorzuziehen, ptrace innerhalb des Docker-Build-Befehls selbst zu aktivieren, um die manuellen Schritte zu vermeiden.

Diese Funktion hätte ich auch gerne. Ich möchte eine Build-Umgebung erstellen, aber dafür ist ein Kernel-Modul erforderlich und modprobe kooperiert nicht mit mir, wenn ich baue. Gibt es Workarounds dafür?

Speziell:

modprobe vcan && \
ip link add type vcan && \
ifconfig vcan0 up

Scheint ein völlig vernünftiger Anwendungsfall zu sein.

@seltzy Ich schlage vor, nicht den Atem docker die Angemessenheit Ihres Anwendungsfalls anerkennt.

Wenn es um Architektur und Feature-Integration geht, sind sie sehr plump, pragmatisch, distanziert und neigen dazu, alle Anwendungsfälle zu ignorieren, die nicht in _ihre_ Roadmap passen.

Wir normalen Leute müssen verstehen, dass das docker Team Architekturentscheidungen trifft, die ihre eigenen (wahrscheinlich Geschäftskunden und eigennützigen) Bedürfnisse fördern, und diese Entscheidungen überschneiden sich selten mit unseren (dem öffentlichen Endbenutzer) sehr mühsam Themen , die wir hier einreichen.

Es steht ihnen natürlich frei, ihre Engineering-Ressourcen auf diese Weise zu verteilen.
Aber es bietet eine Erfolgsgeschichte, die die Fantasie anregen würde, wenn das Unternehmen jemals als "die Bedürfnisse der Benutzer ernst genommen" beschrieben würde.

@tamsky du hast es geschafft!

@tamsky Ich kann verstehen, warum Sie das denken, da das Projekt eine Funktion nicht akzeptiert hat, die Sie eindeutig wünschen.

Ich kann Ihnen versichern, dass dies nichts mit einer geschäftlichen Entscheidung zu tun hat. Tatsache ist, dass --privileged beim Build zu nicht tragbaren Images führt.
Dinge wie modprobe in der Build-Umgebung sind nicht hilfreich und können sogar dazu führen, dass zwei Builds völlig unterschiedliche Ergebnisse liefern.

Ich selbst habe --privileged auf Build implementiert. Es ist kein technisches Problem, und es ist wirklich ziemlich trivial zu implementieren. Es zu unterstützen, ist das Problem.
Für fortgeschrittene Benutzer kann ein benutzerdefinierter Builder implementiert werden, der sogar den vorhandenen Code wiederverwendet und die vorhandenen APIs verwendet, die privilegierte Unterstützung umfassen können.

Das heißt, dieses Thema ist aus einem bestimmten Grund noch offen. Das liegt daran, dass die Leute zuhören.

Vielen Dank dass Sie darüber nachdenken.

@cpuguy83 Danke für die Erklärung. Mir war nicht klar, dass es sich um ein Portabilitätsproblem handelt. Ich nehme an, mein Verlangen danach wird durch Missverständnisse geschürt.

Was ist der allgemeine philosophische Ansatz, wenn man der Versuchung ausgesetzt ist, privilegiert zu bauen?

@seltzy sei nicht so sicher, ob dein Anwendungsfall kein vernünftiges Beispiel für die Notwendigkeit dieser Funktion ist

@cpuguy83 Ich warte immer noch auf eine Antwort zu meinem Anwendungsfall. Das Build-System unserer Institution wird über ein Netzwerk-Dateisystem verteilt, das ich in meinen Container einhängen muss . Dies erfordert, dass der Container im privilegierten Modus ausgeführt wird. Die Entscheidung meiner Institution, ein Netzwerkdateisystem für die Softwareverteilung zu verwenden, ist für die Teilchenphysik nicht ungewöhnlich. Sie behaupten, dass --privileged beim Build nicht tragbare Bilder erstellt, aber dies hat nichts mit meinem Anwendungsfall zu tun. Unser Entwicklungsmodell hat bereits jede Portabilität aufgegeben, die wir _könnten_, weil wir ein Netzwerkdateisystem verwenden (wirklich?). Wir brauchen nur die Entwicklungsmaschine, um sie zu montieren.

@ cpuguy83 PS Sie haben einen benutzerdefinierten Builder erwähnt. Wo finde ich Informationen dazu? Vielen Dank!

Diese ganze Diskussion über die Portabilität von Containern ist sowieso ein riesiger Ablenkungsmanöver. Sie können dasselbe bereits erreichen, indem Sie ein Image der Stufe 1 erstellen, einen Container im privilegierten Modus starten, alles tun, was Sie tun müssen, und dann Docker Commit verwenden, um das endgültige Image aus diesem Container zu erstellen.

Sobald sie die Docker-Commit-Option hinzugefügt haben, ist jede Vorstellung von Image-Portabilität sowieso aus dem Ruder gelaufen. Die Leute dazu zu zwingen, dies in 3 statt in 1 Schritten zu tun, bringt nichts und dient nur dazu, Leute zu ärgern, die eine privilegierte Build-Option wirklich nutzen könnten.

@drstapletron Das Mounten eines Dateisystems ist nicht unbedingt etwas, das die Portabilität
Das Problem hier ist, dass die Fähigkeit, ein Dateisystem zu mounten, auch bedeutet, eine Reihe anderer unangenehmer Dinge tun zu können.

@ctindel Ja, Sie können in den von Ihnen erstellten Containern alles tun, was Sie möchten. Die Tatsache, dass docker build "die" unterstützte Methode zum Erstellen von Images ist, bedeutet jedoch, dass wir sicherstellen müssen, dass damit erstellte Images _portabel_ sind.

Tragbare Bilder sind kein Ablenkungsmanöver. Die Portabilität von Workloads ist das primäre Designziel von Docker. Unsere oberste Direktive sozusagen.

@seltzy Die meisten Dinge, die zusätzliche Berechtigungen erfordern, gehören zur Laufzeit, da die erhöhten Berechtigungen die meiste Zeit verwendet werden, um den Host in irgendeiner Weise zu ändern.
Trotzdem kann ich sicherlich verstehen, dass einige Dinge zur Build-Zeit erforderlich sind (wie der nfs-Mount oben).... aber selbst im Fall von NFS und dem manuellen Erstellen des Images (nicht mit docker build ) würde dem Container --privileged oder irgendwelche zusätzlichen Fähigkeiten überhaupt nicht geben, stattdessen würde ich den nfs-Export als Volume mounten.

@drstapletron mount erfordert nicht --privileged nur einen eingeschränkteren Funktionsumfang und ist viel wahrscheinlicher als ein vollständig privilegierter Modus, da dies vollen Root-Zugriff auf den Host gewährt, was die meisten Leute tun nicht wollen. (Es gibt immer noch Sicherheitsprobleme, aber sie sind besser zu handhaben).

Ich habe also einen vollständig tragbaren, nicht den Host ändernden Anwendungsfall. Es ist sogar Open Source und Sie können es hier sehen .

Grundsätzlich möchte ich Mock in einem tragbaren Docker-Container ausführen, um ein benutzerdefiniertes CentOS-ISO-Image zu erstellen. Mock, für diejenigen, die es nicht wissen, ist ein containerisierter RPM-Builder. Das Problem ist, da es Container verwendet, brauche ich --privileged oder --cap-add . Im Idealfall würde docker build wie eine Funktion funktionieren, die einige Argumente nimmt und ihr Endergebnis zurückgibt. Ohne diese Flags kann ich das jedoch nicht tun.

Hier gilt das gleiche ! Die Verwendung von Mock in Docker ist deswegen ein Albtraum :(

Sending build context to Docker daemon 9.728 kB
Step 1 : FROM centos
 ---> 980e0e4c79ec
Step 2 : MAINTAINER Gregory Boddin
 ---> Using cache
 ---> 93e709c87f25
Step 3 : RUN yum install -y spectool mock
 ---> Using cache
 ---> 7006ef8d0276
Step 4 : RUN useradd mock -g mock
 ---> Using cache
 ---> bfb931c56d89
Step 5 : ADD *.cfg /etc/mock/
 ---> Using cache
 ---> 15521d2822b1
Step 6 : RUN su mock -c"/usr/bin/mock -r edge-5-x86_64 --init"
 ---> Running in 542a742b6017
INFO: mock.py version 1.2.17 starting (python version = 2.7.5)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
ERROR: Namespace unshare failed.

@cpuguy83 schrieb:

Tatsache ist, dass --privileged on build zu nicht tragbaren Images führt.

Warum nicht --privileged für diejenigen zulassen, die keine weitreichende Portabilität benötigen?
Ein einfacher Hinweis in der offiziellen Dokumentation wäre ein vernünftiger Kompromiss (zB _Warnung: Die Übergabe von --privilege an den Befehl build kann zu einem weniger portierbaren Image führen!_). Dies würde fast alle Anforderungen erfüllen; einige Benutzer brauchen keine Portabilität, andere tun, eine Warnung würde ausreichen, um alle Bedürfnisse zu erfüllen.

Ich bin mir sicher, dass das Fehlen von build --privileged meinen aktuellen Anwendungsfall erheblich erschwert.

Es könnte --non-portable heißen. Ich habe die Bereitstellungsteile von Docker noch nicht verwendet, aber die Isolation + Overlay-Dateisystem-Zeug war ohne das wirklich nützlich.

Ich muss eine proprietäre Software verwenden, die zur Installation einen privilegierten Container erfordert. Ich kann nichts dagegen tun. Ich muss den 3-stufigen Build-, Run- und Commit-Prozess durchführen.

Container-Portabilität bedeutet weder für mich noch für mein Geschäft etwas, ich wette, es bedeutet für die überwiegende Mehrheit der Unternehmen überhaupt nichts. Wichtig ist, dass ich weniger Software warten möchte, daher denke ich, dass es für Docker nachteilig ist, in diesem Fall die Portabilität gegenüber der Benutzerfreundlichkeit zu wählen.

+1 dafür, im Build-Prozess verwenden wir setfacl, dies schlägt während des Builds fehl und Dienste können im Container nicht gestartet werden. Ich denke, dass wir als Endbenutzer nicht eingeschränkt sein sollten. Verwenden Sie die Option --priviledge nur, wenn Sie dies benötigen und die Standardeinstellung deaktiviert ist.

+1 dafür. In unserem Build-Prozess ist es erforderlich, /proc und /dev zu mounten. Idealerweise sollten wir in der Lage sein, den Mount-Schritt als Teil des Dockerfiles zu haben.

@samsun387 Warum erfordert Ihr Build-Prozess dies?

@skshandilya setfacl ist nicht portabel und ich wäre überrascht, wenn acls in einem Image beibehalten werden könnten.

@robhaswell "erfordert einen privilegierten Container" hilft nicht viel. Was wird eigentlich bei der Installation verwendet?

+1. mock init braucht das.
fast die ganze Ausgabe gelesen. Verstehe nicht, warum die Leute 3 Jahre lang immer wieder fragen "Warum brauchst du das?".

@Betriebsrat Weil "X das braucht" ist nicht wirklich hilfreich.
Was macht "X"? Warum braucht "X" das während der Build-Phase?

Zum Beispiel scheint der obige Fall mit den Fähigkeiten zum Mounten von /proc und /dev wirklich nicht der richtige Ort für die Build-Phase zu sein, und es scheint sogar so, als ob das Image in diesem Fall an den Host gebunden wäre ein Fall.

"privilegiert" ist auch ein Panzer. Es öffnet absolut alles, deaktiviert alle Sicherheitsfunktionen, gibt Schreibzugriff auf normalerweise schreibgeschützte Orte ... wo jemand wahrscheinlich nur in der Lage sein muss, eine ganz bestimmte Sache zu tun.

Diese Fragen werden uns gestellt, damit wir den tatsächlichen Anwendungsfall erhalten und wie wir einen solchen Fall erfüllen können.

Übrigens, wenn ich "Sicherheitsfunktionen" sage, meine ich zwei Dinge:

1. Dinge, um Hacking zu verhindern
2. Trennung von Anwendungsbedenken von Hostbelangen (dh die Imageerstellung sollte das Image nicht an den Host binden, auf dem es erstellt wurde).

Sieht so aus, als wäre meins von 21051 gelöst worden, ich bin vorerst draußen :)

@shykes sagte am 28. November 2013 @ https://github.com/docker/docker/pull/2839#issuecomment -29481246 ::

Entschuldigung, das aktuelle Design ist es, '1 source, 1 build' zu erzwingen, weshalb wir außer dem Quellverzeichnis keine anderen Argumente für Docker-Build zulassen.

Ich verstehe die Tatsache, dass einige Builds derzeit nicht ausgeführt werden können, weil sie privilegierte Operationen benötigen. Um dies richtig zu handhaben, müssen wir möglicherweise 1) einer Dockerdatei erlauben, die Notwendigkeit auszudrücken, privilegiert erstellt zu werden, und 2) ein Autorisierungs- / Trus-System implementieren, das es Docker ermöglicht, den Build zu pausieren, den Benutzer ordnungsgemäß vor dem Risiko zu warnen, Informationen zum Ursprung und zur Vertrauenswürdigkeit des Dockerfiles preisgeben und dann die Entscheidung des Benutzers erfassen, den Build zuzulassen oder abzulehnen.

@ cpuguy83 , hat sich das Design durch die Durchsetzung von "1 Quelle, 1 Build" überhaupt geändert?
Ist das Docker-Projekt bereit, dieses Design zu ändern und diese von der Community angeforderte Funktion zuzulassen?

Der obige Kommentar von Shykes scheint zu erklären, was "wir möglicherweise tun müssen", um dies in den Griff zu bekommen. Gleichzeitig scheint die verwendete Sprache ("might") dem Docker-Projekt viel Spielraum zu geben, um zusätzliche Gründe zu finden, diese Designänderung abzulehnen.

Das Hinzufügen einer NEEDS_PRIVILEGED-Deklaration ist sinnvoll, aber all diese Dinge über das Anhalten des Builds? Scheitern Sie einfach mit einem Fehler und lassen Sie den Operator die Option --privileged übergeben, wenn er den privilegierten Build tatsächlich zulassen möchte.

@cpuguy83 Die Sache ist die, Leute, die jemals den privilegierten Modus beim Build benötigen, sind normalerweise Power-User, die die Risiken der Verwendung genau kennen. Und die meisten von ihnen akzeptieren das und umgehen dies, indem sie einfach docker commit als Teil ihres Builds für den Schritt verwenden, der es benötigt.

Sie hindern die Leute in keiner Weise daran, den privilegierten Modus im Build zu verwenden, Sie machen es nur nervig.

Wenn Ihr Ziel darin besteht, es nervig zu machen, dann sagen Sie es einfach direkt und schließen Sie dieses Thema, anstatt es jahrelang fortzusetzen.

Sagen Sie "Wir werden dies nicht beheben, weil wir möchten, dass es lästig wird" und schließen Sie dieses Problem.

/Gewinde

@cpuguy83 , nach meinem Verständnis verwendet Mock unshare(2) mit dem CLONE_NEWNS Flag – und möglicherweise anderen – wenn es seine Chroot/Container-Umgebung erstellt. Dies erfordert mindestens CAP_SYS_ADMIN .

Was macht "X"? Warum braucht "X" das während der Build-Phase?

In unserem Anwendungsfall wissen wir es nicht. Es ist irgendein proprietärer Mist, den wir nicht ändern können. Die Sache ist die, unser Geschäft kümmert sich nicht um "Sicherheit" (in diesem Zusammenhang) oder Portabilität oder irgendwelche der aufgeführten Bedenken. Wir wollen dieses verdammte Stück Mist einfach in einen Container packen und etwas Wertvolles tun.

Wie @PonderingGrower sagt, werden wir es trotzdem tun, es kommt nur darauf an, wie viel Zeit wir dabei verschwenden.

Leute, die jemals den privilegierten Modus im Build benötigen, sind normalerweise Power-User, die die Risiken ihrer Verwendung genau kennen.

Dieser Annahme widerspreche ich vehement. Insgesamt sind Leute, die --privileged dieselbe Kategorie von Benutzern, die blindlings chmod -r 777 ausführen, "weil jemand geschrieben hat, dass es das Problem behoben hat"

In unserem Anwendungsfall wissen wir es nicht. Es ist irgendein proprietärer Mist, den wir nicht ändern können. Die Sache ist die, unser Geschäft kümmert sich nicht um "Sicherheit" (in diesem Zusammenhang) oder Portabilität oder irgendwelche der aufgeführten Bedenken.

"in diesem Kontext" bedeutet hier: "irgendein proprietären Mist" Root-Zugriff auf Ihrem Host gewähren.

@thaJeztah Damit habe ich kein Problem. Es ist Software, die wir gekauft haben und für die wir Support bezahlen. Wenn wir keine Container verwenden würden, wäre zur Installation immer noch Root erforderlich.

Wir benötigen diese Funktion, um dind während des Bauens zu verwenden, um einige Container innerhalb des zu erstellenden Containers vorzukonfigurieren.

Worüber diskutieren Sie hier seit 3 ​​Jahren?

docker run hat eine Option --cap-add , --cap-drop und andere. Der Befehl RUN in Dockerfile möchte also die gleichen Optionen haben. Also möchte Dockerfile Anfragen an den übergeordneten Rechner senden und ihn bitten, einige Privilegien hinzuzufügen/zu löschen.

Die übergeordnete Maschine kann mit diesen Anforderungen tun, was sie will. Sie können die Shell interaktiv machen, Sie können einen GUI-Bestätigungsdialog erstellen usw. Warum diskutieren Sie die Lösung dieser Anfragen in dieser Ausgabe?

Eine beträchtliche Anzahl von Docker-Benutzern möchte die Möglichkeit haben, im build-Befehl --cap-add oder --privileged zu imitieren, was im run-Befehl steht.

Aus diesem Grund ist dieses Ticket seit 3 ​​Jahren geöffnet und die Leute melden sich ständig an, obwohl die Betreuer nicht daran interessiert sind, den Benutzern in diesem speziellen Fall das zu geben, was sie wollen.

@ctindel Dies ist definitiv das Problem dieses Problems. Es gibt eine Lücke zwischen docker build --cap-add und RUN --cap-add .

Manche Leute möchten Privilegienanfragen vom untergeordneten Computer mit nur docker build --cap-add=caps_array auflösen. Was ist es? Das ist nur: caps_array.include? requested_cap .

Manche Leute wollen pre_requested_caps.include? requested_cap . Manche Leute wollen stdout << requested_cap, stdin.gets == 'y' .Einige Leute wollen gui_confirm requested_cap . Manche Leute werden definitiv UAC_fullscreen_dialog requested_cap .

Die Auflösungsmethode von requested_cap hängt vom Geschmack des Benutzers ab und ich denke, diese Frage wird nie gestellt.

Aber RUN --cap-add hat nichts mit dem Geschmack der Leute zu tun. Auf was warten wir?

@andrew-aladev Ich verstehe nicht wirklich, was dein Beitrag sagt. Der Punkt ist, dass die Leute über Software von Drittanbietern (RPMs, DEBs, was auch immer) verfügen, die nicht unter ihrer Kontrolle stehen, die sie zum Zeitpunkt des "Docker-Builds" in ein Image installieren möchten und die zusätzliche Fähigkeiten erfordert, um richtig zu installieren. Da es sich um RPMs von Drittanbietern handelt, gibt es keine Möglichkeit, die Anforderung nach erhöhten Berechtigungen während der Installationsphase zu lösen.

Sie umgehen das Problem, indem sie einen Container mit diesen erweiterten Funktionen ausführen, ihre Software installieren und dann ein Image aus diesem Container erstellen. Es ist mühsam und zeigt deutlich, dass es keinen funktionalen Grund gibt, das Hinzufügen von Caps zur Build-Zeit zu verbieten, da das gleiche Ziel auf Umwegen erreicht werden kann.

@ctindel Mein Englisch ist nicht sehr gut, sorry.

Ich kenne. Ich habe versucht, glibc zu emergen und habe ptrace not permitted .

docker kann Container mit erhöhten/verringerten Fähigkeiten selbst ausführen. RUN Befehl in Dockerfile sollte --cap-add , --cap-drop usw. unterstützen.

Stellen wir uns vor, dass unser Dockerfile RUN --cap-add=SYS_PTRACE -- emerge -v1 glibc . Wie würde es funktionieren?

1. Die untergeordnete Maschine sendet eine Anfrage an die Eltern und fragt nach SYS_PTRACE .
2. Parent ermöglicht erweiterte Funktionen.
3. Parent erstellt neuen Container mit zulässigem SYS_PTRACE.

Ich sehe, dass niemand in dieser Ausgabe wirklich darüber streitet. Die Leute streiten nur über eine Methode, um diese Fähigkeiten zuzulassen.

@thaJeztah sagte

Insgesamt handelt es sich bei Personen, die --privileged verwenden, um dieselbe Kategorie von Benutzern, die blindlings chmod -r 777 ausführen

Dieser Mann möchte eine flexiblere Methode zur Validierung der erforderlichen Fähigkeiten als nur log :info, requested_cap; return privileged? .

@ctindel hast du gesagt

Das Hinzufügen einer NEEDS_PRIVILEGED-Deklaration ist sinnvoll, aber all diese Dinge über das Anhalten des Builds? Scheitern Sie einfach mit einem Fehler und lassen Sie den Operator die Option --privileged übergeben, wenn er den privilegierten Build tatsächlich zulassen möchte.

Sie möchten Shell interaktiv machen. Sie wollen stdout << requested_cap, stdin.gets == 'y' . Dies ist die andere Methode zur Validierung der erforderlichen Fähigkeiten.

@cpuguy83 sagte

Jemand muss wahrscheinlich nur in der Lage sein, etwas ganz bestimmtes zu tun ... Dinge, um Hacking zu verhindern.

Dieser Mann will docker build --cap-add=caps_array caps_array.include? requested_cap . Dies ist die andere Methode zur Validierung der erforderlichen Fähigkeiten.

Also frage ich: Warum haben RUN in Dockerfile immer noch keine Unterstützung von --cap-add , --cap-drop usw.? Darüber streitet niemand. 3 Jahre sind vergangen!

@andrew-aladev Ich gehe davon aus, dass sich niemand für diese Syntax ausgesprochen hat, da klargestellt wurde, dass die Dockerfile-Syntax eingefroren ist, bis der Builder neu geschrieben / umgestaltet / von der Haupt-Engine entkoppelt wird. https://github.com/docker/docker/issues/29719#issuecomment -269342554

Genauer gesagt verlangen der Titel des Problems und das OP --privilegierte Build

das lässt einen Fonzie knallen: .

strace im build Schritt ausführen zu können, hilft sehr.
Momentan umgehe ich dies, indem ich alle Dinge, die ich zum Debuggen benötige, in den Schritt run - nicht ideal.

Weiß jemand, warum es im run build Schritt und nicht im
Gibt es eine Alternative zu strace , die ohne viel Erlaubnis oder Konfiguration funktioniert?

Es gibt einen Lösungsvorschlag/Workaround dafür in
https://github.com/docker/docker/issues/6800#issuecomment -50494871 :

Wenn Sie Probleme beim Docker-Build haben, können Sie einen "Builder-Container" verwenden:
docker run --cap-add [...] mybuilder | docker build -t myimage -

Könnte jemand (möglicherweise @tiborvass) dies näher erläutern? Was ist hier mybuilder ?
Der Bildname mit einem ENTRYPOINT ? Oder ist das Bild Teil von [...] und mybuilder verweist
zu einem Shell-Skript? Und wie überzeuge ich docker run , die context.tar.gz an die docker build - zu übergeben?
wenn das hier wirklich passiert. Danke im Voraus, Steffen

@sneumann mybuilder wäre ein Bildname und hätte tatsächlich einige CMD oder ENTRYPOINT . Der Vertrag, damit dieser Workaround funktioniert, ist, dass mybuilder tar den Kontext aus dem Container docker build ‚s stdin, dank das Shell - Rohr | und gilt als der Kontext sein , weil der Kontextpfad für docker build -t myimage - ist - .

Beim Betrachten des Codes scheint es etwas seltsam zu sein, dass diese Option im Befehl build verfügbar ist:

• run : Ich nehme an, dass container hier run - https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/container/opts.go #L485.
• build : https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/image/build.go#L108.

Hat jemand mehr Ahnung, warum es nicht angewendet wird?

@mbana das --security-opt ist für native Windows-Container, die "credentialspec" unterstützen https://github.com/docker/docker/pull/23389

ist es möglich, dies zu ändern und fortzusetzen, damit zukünftiges build ptrace aktivieren wird?

Für alle Interessierten hier ein paar gute Links:

• http://www.projectatomic.io/docs/docker-building-images/ - wie man das Image mit der oben beschriebenen Technik erstellt. dh, verwenden Sie run bis build das Bild.
• https://blog.afoolishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/ - misc

Ich habe viele Behauptungen von verschiedenen Leuten gesehen, dass diese Funktion nicht benötigt wird, weil Builds so geändert werden können, dass bestimmte privilegierte Operationen nicht erforderlich sind, aber keine Vorschläge, was mit dem Fall "Docker in Docker" zu tun ist. Wenn ein Build docker Befehle ausführen muss, um zum Beispiel einige Images herunterzuladen, die wir in diesem ausliefern möchten, oder um ein Unter-Image zu erstellen, wie sollen wir dies ohne irgendeine Art von Privilegien tun? Build-Option?

Im Moment werde ich dies mit docker run und docker commit aber es wäre großartig, wenn docker build diesen Anwendungsfall unterstützen könnte.

@scjody Klingt wie du willst #31257

@ cpuguy83 Ich bin mir nicht sicher, ob das abdeckt, was in diesem Fall vor sich geht, aber ich werde es

Hi, ich würde gerne meinen Namen in die Bitte-implementiere-diese Mütze werfen. Oder gibt es vielleicht eine andere Lösung für mein Problem (Docker Noob hier), auf die mich jemand hinweisen könnte?

Ich versuche, ein Image basierend auf dem offiziellen centos/systemd- Image zu bereitzustellen . Dazu muss der Salt-Minion-Daemon mit systemd gestartet (und möglicherweise neu gestartet) werden, was ohne den privilegierten Modus nicht möglich ist (AFAIK).

@onlyanegg Ich denke, in dieser Situation ersetzt Saltstack weitgehend die Funktionalität des Builders; Denken Sie daran, dass jede RUN Anweisung in einem neuen Container ausgeführt wird, an welchem ​​Punkt der vorherige Build-Container gestoppt und an ein Image / eine Ebene übergeben wird.

Haben Sie darüber nachgedacht, den Build durchzuführen, indem Sie einen Container ausführen und die Ergebnisse festschreiben ( docker commit )?

Danke für die Antwort, @thaJeztah. Ich wusste nicht, dass dies die Anweisung RUN tut. Ich habe den größten Teil dieses Problems gelesen, daher bin ich mir der Problemumgehung docker build -> docker run -> docker commit bewusst, die ich wahrscheinlich am Ende tun werde. Ich bin nur dafür, dass eine einzige Datei mein Bild beschreibt - scheint ordentlicher zu sein. Vielleicht kann ich all diese Schritte in Packer-Postprozessoren einfügen und dann habe ich das.

Warum wird dieser so ignoriert? In Zeiten von Containern, Kubernetes und Minikube und der Verwendung von Docker in der Vereinheitlichung von CI und Entwicklungsumgebung ist diese Funktionalität wirklich entscheidend.

@onlyanegg Sie sollten in der Lage sein, Dienste _ohne_ privilegierten Modus neu zu starten. Wenn Sie ein Dockerfile haben, das dies veranschaulicht (zB "der RUN Befehl in Zeile 8 dieses Dockerfiles funktioniert nicht, weil es einen privilegierten Modus erfordert"), würde ich mich sehr freuen, einen Blick darauf zu werfen!

@derberg genau! In Zeiten von Containern, CI, CD ist es wichtig, dass Build-Tools (im Sinne der Sicherheit) enthalten sein können. Wenn Sie den privilegierten Modus zulassen, müssen Sie die Verwendung von CI-Tools wie Jenkins, Travis, Codeship usw. drastisch ändern. Dieselbe Frage: Wenn Sie ein Dockerfile haben, das den privilegierten Modus erfordert, schaue ich gerne nach, um Alternativen vorzuschlagen.

Dankeschön!

@jpetazzo versuchen, ein Docker-Image mit Docker darin zu erhalten:

FROM ubuntu:16.04

# Get dependencies for curl of the docker
RUN apt-get update && apt-get install -y \
    curl \
    sudo \
    bash \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSL https://get.docker.com/ | sh

Jetzt bauen und starten. Führen Sie nach dem Start service docker start , um den Docker-Deamon zu starten. Überprüfen Sie dann den Status des Dienstes service docker status :

• mit privilegiertem Flag-Status ist in Ordnung und Sie können den Container ohne Probleme starten
• ohne die flagge geht es nie los

@jpetazzo ech, habe gerade bemerkt, dass du der Ersteller von https://github.com/jpetazzo/dind bist :) also

Wie auch immer, Sie wissen also, dass für die Ausführung ein privilegiertes Flag erforderlich ist. Jetzt können Sie sich also eine Gruppe von Leuten vorstellen, die an einer Umgebung arbeiten und eine vereinheitlichte Umgebung für die Entwicklung mit bereits vorkonfigurierten Dingen im Inneren haben möchten, zum Beispiel Minikube mit vorinstallierten Komponenten oder irgendetwas anderem

Gibt es also schon eine Möglichkeit, eine NFS- oder SMB-Freigabe in docker build zu mounten?

@derberg diese Schritte funktionieren nicht, selbst wenn der Build-Container --privileged ; Die Docker-Pakete (und das Installationsskript) installieren (zum Beispiel) Kernel-Pakete unter Ubuntu 16.04.
Das ist genau der Grund, warum --privileged für docker build eine schlechte Idee ist, weil es in der Lage wäre, Änderungen auf dem _host_ vorzunehmen.

Obwohl Docker beim _running_ privilegiert sein muss, benötigt die Installation selbst dies nicht; Hier sind beispielsweise die Schritte, die Sie ausführen würden, um Docker in Ihrem Image zu installieren;

docker build -t foo -<<'EOF'
FROM ubuntu:16.04

RUN apt-get update && apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common \
    && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable"
RUN apt-get update && apt-get install -y docker-ce \
    && rm -rf /var/lib/apt/lists/*
EOF

Und Sie können es problemlos ausführen (ich verwende hier --privileged , aber vielleicht sind detailliertere Berechtigungen möglich):

docker run -it --rm --privileged -v /var/lib/docker foo dockerd --debug

So umgehe ich dieses Problem für Leute, die wirklich ein Docker-Image im privilegierten Modus erstellen müssen. Es kann nicht alle Fälle lösen, aber in einigen helfen.

Diese Methode benötigt eine Dockerfile, eine docker-compse-Datei und ein Shell-Skript.

Das Dockerfile

Es ist das gleiche, wie Sie das Image erstellen müssen. Der einzige Unterschied besteht darin, dass Sie dort anhalten, wo Sie privilegierte Operationen ausführen müssen, und diese nicht einschließen. Sie müssen vom docker-compose als Skript ausgeführt werden. Zum Beispiel:

FROM ubuntu:16.04
RUN apt-get update && apt-get install <your packages>
# And more commands
......

## Below are the operations you intended to run in privileged mode when building the image, which does not work.
# More commands....
## But they now are moved to a separated shell script and it will be included in the image
COPY further-commands-to-run-in-privileged-mode.sh /

Diese weiteren Befehle, die im privilegierten Modus ausgeführt werden müssen, befinden sich jetzt in further-commands-to-run-in-privileged-mode.sh . Es ist im Image enthalten und wird später von Docker Composer ausgeführt, um den Build-Prozess abzuschließen.

Die Docker Compose-Datei

Die Compose-Datei ist der Schlüssel. Es erstellt das Image zuerst von oben Dockerfile und startet einen Container von diesem Image im privilegierten Modus , dann können Sie dort Ihre privilegierten Operationen ausführen. Zum Beispiel:

version: '3'

services:
  your_service:
    container_name: your_container
    # First build the image from the Dockerfile
    build:
      # Change this to where you keep above Dockerfile
      context: ../docker-build
    image: "your_image_name:your_image_tag"

    # Then start a container from the just built image in privileged mode to finish what's left
    entrypoint: /further-commands-to-run-in-privileged-mode.sh
    privileged: true

Bild erstellen

Die folgenden Schritte können auch in einem Shell-Skript gespeichert werden.

# First build the image and container(in privileged mode)
docker-compose -f docker-compose.yml up

# Then commit the temporary build container to a new image, change the ENTRYPOINT to what you want
docker commit \
    -c 'ENTRYPOINT ["/bin/bash"]' \
    <build container name> \
    <final image name>:<final image tag>

# Remove the temporary build container
docker rm <build container name>

@thaJeztah Ich habe kein Problem mit der Installation, ich habe Probleme damit, den Docker-Dienst während des

Fügen Sie das folgende Skript zu Ihrem Dockerfile hinzu und Sie werden sehen, dass der Docker-Dienst nie aufsteht

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

@derberg OK, ich dind Container aufnehmen wollte, würde ich sie herunterladen (zum Beispiel mit reg ) und ich würde sie beim ersten Start des Containers laden. Wieso den? Denn wenn Sie die Images während des Builds ziehen, funktioniert das Image _nur wenn dind mit demselben Speichertreiber gestartet wird_. Mit anderen Worten, Ihr Image kann auf einem anderen Computer funktionieren oder nicht.

Außerdem – wenn Ihre Bilder groß sind (dh alles andere als beispielsweise busybox oder alpine ), werden Sie am Ende ein wirklich großes DinD-Bild erhalten ...

Ich würde gerne mehr über Ihren endgültigen Anwendungsfall erfahren – denn ich bin sicher, wir können Ihnen helfen, einen effizienteren Weg zu finden, als ein riesiges DinD-Image zu backen :-)

(Ansonsten ist die von @kraml vorgeschlagene Lösung eher elegant!)

Siehe auch https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh
Lädt Bilder nur mit bash+curl+tar herunter.
Wir verwenden es hier: https://github.com/moby/moby/blob/master/Dockerfile#L171

@jpetazzo wir laufen bereits mit einem solchen Workaround build-run-commit, aber ja, es ist aus meiner Sicht immer noch ein Workaround. Der Anwendungsfall bezieht sich ziemlich spezifisch auf die Kubernetes- und Minikube-Umgebung und wir können im Moment nichts tun. Vorerst konnten wir minikube im docker nur mit docker als daemon starten, die Verwendung von virtualbox oder anderen VM-Treibern hat nicht funktioniert, daher sind wir auf den dind Ansatz angewiesen

Bei dem Versuch, ein Image mit einer Legacy-Anwendung zu erstellen (ziemlich normaler Anwendungsfall), bei dem das Installationsprogramm versucht hat, sysctl-Befehle auszuführen, ist dieses Problem aufgetreten.

Wenn wir auf diesen Thread zurückkommen und die gesamten 4 Jahre (!!!) des Hin und Her zum Thema hinzufügen, wie man dem Docker-Build-Befehl eine Art privilegierter Fähigkeiten hinzufügt, scheint es, dass die verfügbaren Optionen in dieser Situation entweder a fieser Haufen von sed-Befehlen, um den Installer so zu modifizieren, dass die sysctl-Aufrufe entfernt werden, oder ein mehrstufiger Build -> Ausführen -> Commit-Pipeline. Ich stimme @derberg zu, dass 'build -> run -> commit' sich wie ein Workaround anfühlt (imo ein grober / hackiger Workaround) und ich glaube nicht, dass mein Anwendungsfall so einzigartig ist. Beim Überprüfen anderer Threads habe ich viele Leute gesehen, die Probleme mit verschiedenen Anwendungs- und Datenbankinstallationen mit fehlgeschlagenen docker build Befehlen aufgrund fehlender Berechtigungen gemeldet haben.

An dieser Stelle unterstützt der Befehl docker run umfangreiche 'privilegierte' Optionen zusammen mit einer "feinkörnigen Kontrolle über die Fähigkeiten mit --cap-add und --cap-drop". Einwände aus sicherheitstechnischer oder technischer Sicht halte ich daher für gegenstandslos. Wenn die privilegierte Ausführungsoption zusammen mit '--cap-add' und '--cap-drop' hinzugefügt wird, könnte ein sicherheitsbewusster Ingenieur einen privilegierten Build einschränken, um nur die spezifischen Fähigkeiten zu enthalten, die für seinen Build erforderlich sind.

Hi ,

Das habe ich schon mal gemeldet, gleiches Problem.

Was ist mit denen, die nur einen Container pro VM mit derselben Benutzer-ID auf VM und Container ausführen möchten und Docker nur als Paketierungstool verwenden?

Gibt es diesbezüglich noch Sicherheitsbedenken?

Auf dieses Problem gestoßen. Könnte wirklich Fähigkeiten für den Build gebrauchen.

Bin auch auf dieses Problem gestoßen.
Es ist sehr nützlich, wenn Docker als CI/CD-Slaves verwendet wird, was eine privilegierte Berechtigung auf docker build erfordern könnte, um die CI/CD-Build/Test-Toolchains beim Erstellen des Slave-Docker-Image zu installieren.
Ich warte seit Jahren auf dieses Feature und hoffe sehr, dass es in Zukunft unterstützt wird.

Ich verstehe wirklich nicht, warum es so viel Widerstand von Entwicklern in Bezug auf --privileged for docker image gibt.
Wenn sich die User selbst in den Fuß schießen wollen, warum nicht lassen? Geben Sie einfach eine Warnmeldung ein und das war's. Es gibt bereits Workarounds, um dasselbe zu erreichen, warum es den Benutzern nicht einfacher machen, die es wirklich brauchen?
Es ist 4-5 Jahre her und es hat keine Fortschritte gemacht.
Einfach unglaublich...

Bis heute ist noch nicht einmal dieses Feature implementiert:
AUSFÜHREN --cap-add=SYS_PTRACE
was den Bedürfnissen vieler Benutzer entsprechen würde.

Könnten Sie bitte vorschlagen, wie ich dieses Dockerfile auf einem Gentoo-Linux-Host erstellen kann:

FROM gentoo/stage3-amd64
# Download and extract latest portage
RUN wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2 && \
    wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2.md5sum && \
    md5sum -c portage-latest.tar.bz2.md5sum 
RUN tar -xjvf portage-latest.tar.bz2 -C /usr
RUN emerge dev-lang/go

weil ich diesen Fehler erhalte, wenn ich dev-lang/go auftauche:

##### Building Go bootstrap tool.
cmd/dist
 * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:_do_ptrace():75: failure (Operation not permitted):
 * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted
/usr/lib64/libsandbox.so(+0xb692)[0x7fd10e265692]
/usr/lib64/libsandbox.so(+0xb778)[0x7fd10e265778]
/usr/lib64/libsandbox.so(+0x6259)[0x7fd10e260259]
/usr/lib64/libsandbox.so(+0x6478)[0x7fd10e260478]
/usr/lib64/libsandbox.so(+0x7611)[0x7fd10e261611]
/usr/lib64/libsandbox.so(execve+0x3f)[0x7fd10e2634ff]
bash[0x41d8ff]
bash[0x41f387]
bash[0x420138]
bash[0x4219ce]
/proc/330/cmdline: bash ./make.bash 

 * ERROR: dev-lang/go-1.9.2::gentoo failed (compile phase):
 *   build failed
 * 
 * Call stack:
 *     ebuild.sh, line 124:  Called src_compile
 *   environment, line 1034:  Called die
 * The specific snippet of code:
 *       ./make.bash || die "build failed"
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/go-1.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/go-1.9.2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-lang/go-1.9.2/work/go/src'
 * S: '/var/tmp/portage/dev-lang/go-1.9.2/work/go'

Wie kann ich es ohne --cap-add=SYS_ADMIN --device /dev/fuse oder --privileged ausführen?

RUN apt-get -y install unionfs-fuse
RUN unionfs-fuse -o cow dir1=RW:dir2=RO dir3/

Ich kann dies mit einer separaten Bash-Datei im Einstiegspunkt tun, aber ich brauche ein einzelnes Dockerfile

@amd-nick was erwartest du von der RUN unionfs-fuse ... Zeile während des Builds? Selbst wenn das funktionieren würde, würde das Dateisystem nur während dieses einzelnen RUN gemountet und im nächsten Schritt verschwunden sein.

@thaJeztah es ist schwer für mich zu erklären. Ich versuche, dieses Repo zu ändern. Kann ich diese Zeile am Gebäude einfach überspringen?

Hi

Zufällig wählte der Docker-Build einen Hostnamen, der mit Null '0' beginnt, was unsere Anwendung unterbricht.

Ich hätte auch gerne die Möglichkeit, den Docker-Build mit RUNP auszuführen oder den Hostnamen während des Builds auszuwählen.

Hat jemand versucht, diese Art von Bildern mit Kaniko zu @maneamarius ' Dockerfile auf Docker für Mac gemacht und es scheint erfolgreich zu bauen, sobald Sie Kanikos docker run "build" -Befehl mit --cap-add=SYS_PTRACE aufrufen. Obwohl ich ein bisschen Probleme habe, den resultierenden Tarball lokal zu laden, ist die RAM-Auslastung etwas hoch, da keine Overlayfs verwendet werden können und das Layer-Caching immer noch WIP ist. Die Dinge könnten einfach funktionieren, wenn ich auf eine Registrierung drücke, aber das habe ich noch nicht versucht.

docker run --cap-add=SYS_PTRACE --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --context=/workspace --tarPath=/workspace/test.tar --destination=test  --single-snapshot

Diese Funktion würde die Bemühungen zum Erstellen von Docker-Images über Puppet auf Redhat/CentOS-Basis-Images erheblich unterstützen.

Seit ich das letzte Mal gepostet habe, habe ich die Änderungen in Kaniko verfolgt . Sie speichern nicht mehr im Speicher und speichern auf die Festplatte, was bedeutet, dass Dockerfiles unterstützt werden, die große Bilder beschreiben. Layer - Caching ist immer noch ein WIP , aber sie haben eine Option für das Zwischenspeichern der Basisbilder für den Moment (Das bedeutet noch keine schnellen RUN Iteration speichern und Art der Arbeit laufen , aber wir können cachen alpine , ubuntu , und was auch immer es für beliebte Basen gibt).

Es ist in einem Zustand, in dem es mir gelungen ist, @maneamarius ' Dockerfile zu erstellen, das Golang in einem Gentoo-Image in diesem Projekt / dieser Demo auftaucht , ohne zerhacken (BEARBEITEN : Ich habe seitdem musste das Dockerfile ändern, um das Gentoo-Basisimage an die Version anzuheften, die zum Zeitpunkt dieses Beitrags latest . Andernfalls ist es immer noch unverändert. ) :

https://github.com/nelsonjchen/kaniko-privileged-maneamarius-moby-1916

Ich habe Azure Pipelines auch so konfiguriert, dass das Dockerfile mit Kaniko mit --cap-add=SYS_PTRACE in ein Image integriert wird, Kanikos Ausgabe-Tarball geladen und go version im generierten Image ausgeführt wird. Ich dachte mir, ein interaktiver "Beweis des Lebens" wäre interessant. Einige der früheren Kommentare hier betrafen auch CI-Systeme, daher dachte ich, ich werde auch ein öffentliches CI-System konfigurieren, damit es funktioniert. Übrigens, Travis CI wurde in Betracht gezogen, aber die Build-Ausgabe war zu lang und wurde beendet und Azure ist mit 166k Ausgabezeilen vollkommen zufrieden. Wenn das Dockerfile mit etwa 70k weniger Ausgabezeilen erstellt worden wäre, wäre es wahrscheinlich auf Travis CI gelungen. Ein Link zu den Azure Pipeline-Buildausgaben befindet sich oben in der README-Datei.

Benutze buildah Luke

Ich schließe dieses Problem, da die Funktion jetzt als docker buildx build --allow security.insecure verfügbar ist

https://github.com/docker/buildx/blob/master/README.md# --allowentitlement
https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run ---securityinsecuresandbox

@AkihiroSuda Ich habe meinen Docker auf Version buildx auszuprobieren. Als ich den von dir erwähnten Befehl ausprobiert habe, bekomme ich einen Fehler

$ docker buildx build --allow security.insecure -t sample-petclinic -f Dockerfile .
[+] Building 0.0s (0/0)                                                                                                                                                         
failed to solve: rpc error: code = Unknown desc = entitlement security.insecure is not allowed

Docker version :

Client: Docker Engine - Enterprise
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        c92ab06
 Built:             Tue Sep  3 15:57:09 2019
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       c92ab06
  Built:            Tue Sep  3 15:55:37 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

buildx-Dokumente: For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

Danke @AkihiroSuda . Es hat jetzt funktioniert.

nur um einen weiteren Anwendungsfall hinzuzufügen.
Ich versuche, einen Dockerfile-Build eines ibmdb2-Containers mit einer Testdatenbank zu reparieren
IBM hat das v10-Image vom Hub entfernt. Aber das v11 DB-Image beginnt nur mit --privileged.
Daher ist der gesamte Code zum Einrichten der Datenbank in der Dockerfile jetzt nicht mehr funktionsfähig, da db2 nicht ohne Privilegien startet. :(
Bei der Verwendung von Docker Run und Docker Commit scheint es eine komplizierte Problemumgehung zu geben.
In einer produktiven Build-Pipeline erzeugt dies eine Menge zusätzlicher Komplexität.

Ich muss wie https://github.com/maneamarius in https://github.com/moby/moby/issues/1916#issuecomment -361173550 fragen

Warum ist es so wichtig, dies zu unterstützen? Der Build führt einen Lauf unter der Haube aus.

In diesem speziellen Anwendungsfall würde eine privilegierte Build-Option eine Art "Abwärtskompatibilität" unterstützen und ich weiß, dass ich nicht der einzige bin, der dieses Problem nach meiner Web-Recherche hatte.

@uvwild Ich bin mir nicht sicher, ob dies Ihrem Anwendungsfall hilft, aber Sie können versuchen, mit Kaniko zu bauen. Ihr Image wird ohne Docker-Deamon erstellt und Sie können das Image extrahieren, sobald es fertig ist Sie können --privileged oder --cap-add <capability which is needed> die Ihr Problem möglicherweise lösen.

Ich akzeptiere, dass dies keine vollständige Lösung ist, die Sie erwartet haben, sondern eine einfachere Problemumgehung, die möglicherweise in Ihre Build-Pipeline passt.

BEARBEITEN: Wie @alexey-vostrikov sagte, könnte buildah eine praktikablere Lösung für Anwendungsfälle sein, die --privileged benötigen, um ein Image aufzubauen