Heim >Backend-Entwicklung >C++ >Eine elegante Möglichkeit, Benutzer-IDs in Docker-Containern mithilfe von docker_userid_fixer zu reparieren
Es handelt sich um ein eher technisches Problem bei der Verwendung von Docker-Containern, die mit dem Docker-Hostcomputer interagieren, im Allgemeinen im Zusammenhang mit der Verwendung des Host-Dateisystems innerhalb des Containers.
Dies geschieht insbesondere im reproduzierbaren Forschungskontext.
Ich habe ein Open-Source-Dienstprogramm entwickelt, das bei der Lösung dieses Problems hilft.
Der anfängliche und Hauptanwendungsfall eines Docker-Containers: eine eigenständige Anwendung, die nur über einige Netzwerkports mit dem Hostsystem interagiert.
Stellen Sie sich eine Webanwendung vor: Der Docker-Container enthält normalerweise einen Webserver und eine Webanwendung, die beispielsweise auf Port 80 (im Container) ausgeführt wird. Der Container wird dann auf dem Host ausgeführt, indem der interne Container-Port 80 an einen Host-Port (z. B. 8000) gebunden wird.
Dann erfolgt die einzige Interaktion zwischen der Container-App und dem Hostsystem über diesen gebundenen Netzwerkport.
Container als Ausführungsumgebungen sind völlig unterschiedlich:
Um diese Ausführungsumgebungen nutzen zu können, müssen diese Container jedoch Zugriff auf das Hostsystem haben, insbesondere auf das Host-Benutzerdateisystem.
Angenommen, Sie haben eine IDE containerisiert, z. Rstudio.
Ihr Rstudio ist im Docker-Container installiert und wird ausgeführt, muss jedoch Dateien in Ihrem Projektordner lesen und bearbeiten.
Dazu binden Sie das Mounten Ihres Projektordners (in Ihrem Host-Dateisystem) mit der Docker-Run-Option --volume.
Dann sind Ihre Dateien über den Docker-Container zugänglich.
Die Herausforderung sind nun die Dateiberechtigungen. Angenommen, Ihr Host-Benutzer hat die Benutzer-ID 1001 und der Benutzer, der den Rsudio-Prozess im Container besitzt, ist entweder 0 (root) oder 1002.
Wenn der Containerbenutzer root ist, treten beim Lesen Ihrer Dateien keine Probleme auf.
Sobald Sie jedoch einige vorhandene Dateien bearbeiten oder neue erstellen (z. B. PDF, HTML), gehören diese Dateien zum Root auch im Host-Dateisystem!.
Das bedeutet, dass Ihr lokaler Host-Benutzer sie nicht verwenden oder löschen kann, da sie zum Root gehören.
Wenn die Container-Benutzer-ID nun 1002 ist, kann Rstudio Ihre Dateien möglicherweise nicht lesen, bearbeiten oder keine neuen Dateien erstellen.
Auch wenn dies möglich ist, kann Ihr lokaler Hostbenutzer aufgrund der Einstellung einiger sehr freizügiger Berechtigungen diese möglicherweise nicht verwenden.
Natürlich besteht eine Brute-Force-Methode zur Lösung dieses Problems darin, sowohl auf dem Host-Computer als auch im Docker-Container mit Root ausgeführt zu werden. Dies ist nicht immer möglich und wirft einige offensichtliche kritische Sicherheitsbedenken auf.
Da wir nicht im Voraus wissen können, wie die Host-Benutzer-ID lautet (hier 1001), können wir keine Vorkonfiguration vornehmen
die Benutzer-ID des Docker-Container-Benutzers.
docker run bietet jetzt eine Option --user, die es ermöglicht, einen Pseudobenutzer mit einer angegebenen Benutzer-ID
zu erstellen
zur Laufzeit. Beispielsweise erstellt docker run --user 1001 ... einen Docker-Container, der mit Prozessen ausgeführt wird
gehört einem Benutzer mit der Benutzer-ID 1001.
Was besprechen wir also noch zu diesem Thema? Ist es nicht gelöst?
Hier einige Besonderheiten dieses dynamisch erstellten Benutzers:
Wir können diese Probleme umgehen, aber es kann mühsam und frustrierend sein.
Was wir wirklich gerne hätten, wäre, einen Docker-Container-Benutzer vorzukonfigurieren und seine Benutzer-ID zur Laufzeit...
docker_userid_fixer ist ein Open-Source-Dienstprogramm, das als Docker-Einstiegspunkt verwendet werden soll, um das gerade angesprochene Benutzer-ID-Problem zu beheben.
Sehen wir uns an, wie man es verwendet: Sie legen es als Ihren Docker-ENTRYPOINT fest, geben an, welcher Benutzer verwendet werden soll, und lassen seine Benutzer-ID dynamisch ändern:
ENTRYPOINT ["/usr/local/bin/docker_userid_fixer","user1"]
Seien wir präziser:
Dann gibt es bei der Container-Laufzeiterstellung zwei Optionen:
In der Praxis löst dies also unser Problem:
Eine Anleitung zur Einrichtung finden Sie hier.
Aber es läuft darauf hinaus:
Erstellen oder laden Sie die kleine ausführbare Datei (17 KB) herunter
Kopieren Sie es in Ihr Docker-Image
Machen Sie es als Setuid-Root ausführbar
konfigurieren Sie es als Ihren Einstiegspunkt
Ich habe einige kurze Notizen hinterlegt https://github.com/kforner/docker_userid_fixer#how-it-works
aber ich werde versuchen, es umzuformulieren.
Der Kern der Implementierung ist das Setuid-Stammverzeichnis der ausführbaren Datei docker_userid_fixer im Container.
Wir benötigen Root-Berechtigungen, um die Benutzer-ID zu ändern, und diese Setuid ermöglicht diese privilegierte Ausführung nur für
das docker_userid_fixerprogram, und das nur für sehr kurze Zeit.
Sobald die Benutzer-ID bei Bedarf geändert wurde, wechselt docker_userid_fixer den Hauptprozess
an den angeforderten Benutzer (und die Benutzer-ID!) senden.
Wenn Sie an diesen Themen interessiert sind (Docker, reproduzierbare Forschung, R-Paketentwicklung, Algorithmen, Leistungsoptimierung, Parallelität...), zögern Sie nicht, mich zu kontaktieren, um Job- und Geschäftsmöglichkeiten zu besprechen.
Das obige ist der detaillierte Inhalt vonEine elegante Möglichkeit, Benutzer-IDs in Docker-Containern mithilfe von docker_userid_fixer zu reparieren. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!