Eine elegante Möglichkeit, Benutzer-IDs in Docker-Containern mithilfe von docker_userid_fixer zu reparieren

Worum geht es?

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.

Docker-Container als Ausführungsumgebungen

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:

• Statt einer Containerisierung einer Anwendung ist es das Anwendungserstellungssystem, das containerisiert wird.
  • Es könnte ein Compiler, eine IDE, eine Notebook-Engine, ein Quarto-Publishing-System sein...
• Die Ziele sind:
  • um eine standardisierte Umgebung zu haben, die einfach zu installieren und zu teilen ist
    • Stellen Sie sich eine komplexe Build-Umgebung mit festen Versionen von R, Python und Millionen externer Pakete vor. Alles mit den richtigen Versionen zu installieren, kann eine sehr schwierige und zeitaufwändige Aufgabe sein. Durch das Teilen eines Docker-Images, das alles bereits installierte und vorkonfigurierte enthält, können Sie wirklich Zeit sparen.
  • um eine reproduzierbare Umgebung zu haben
    • Durch die Verwendung können Sie einige Analyseergebnisse reproduzieren, da Sie dieselbe kontrollierte Umgebung verwenden
    • Sie können Fehler auch einfach reproduzieren, was der erste Schritt zu deren Behebung ist

Um diese Ausführungsumgebungen nutzen zu können, müssen diese Container jedoch Zugriff auf das Hostsystem haben, insbesondere auf das Host-Benutzerdateisystem.

Docker-Container und das Host-Dateisystem

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.

Lösung des Dateieigentümerproblems Teil 1: die Docker-Option run --user

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:

• es ist ein Pseudobenutzer
• Es gibt kein Home-Verzeichnis (/home/xxx)
• es erscheint nicht in /etc/passwd
• es kann nicht vorkonfiguriert werden, z.B. mit einem Bash-Profil, einigen Umgebungsvariablen, Anwendungsstandards usw.

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...

Lösung des Dateieigentümerproblems Teil 2: Geben Sie docker_userid_fixer ein

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:

• Der Zielbenutzer ist der Benutzer, der für docker_userid_fixer angefordert wird, hier Benutzer1
• Der angefragte Benutzer ist der von Docker Run bereitgestellte Benutzer, d. h. der Benutzer, der (zunächst) Eigentümer des ersten Prozesses (PID 1) ist

Dann gibt es bei der Container-Laufzeiterstellung zwei Optionen:

• entweder stimmt die angefragte-Benutzer-ID (bereits) mit der Ziel--Benutzer-ID überein, dann muss nichts geändert werden
• Oder es tut es nicht. Beispielsweise lautet die angeforderte-Benutzer-ID 1001 und die Ziel--Benutzer-ID ist 100. Dann korrigiert docker_userid_fixer die Benutzer-ID des Ziel-Benutzers Benutzer1 von 1000 auf 1001, direkt im Container-Hauptprozess.

In der Praxis löst dies also unser Problem:

• Wenn Sie Ihre Container-Benutzer-ID nicht korrigieren müssen, verwenden Sie einfach Docker Run wie gewohnt (ohne die Option --user)
• Oder Sie verwenden die Option --user. Dann wird Ihr Hauptprozess nicht nur mit einer von Ihnen angeforderten Benutzer-ID ausgeführt, sondern Ihr vorkonfigurierter Benutzer wird auch in Ihre angeforderte Benutzer-ID geändert, sodass Ihr Container mit Ihrem beabsichtigten und beabsichtigten Benutzer ausgeführt wird Benutzer-ID.

docker_userid_fixer-Setup

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

die blutigen Details

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!