Der docker Das CLI-Programm ist unabhängig vom Docker-Daemon, der Ihre Container ausführt. Obwohl beide Komponenten normalerweise auf Ihrem lokalen Computer ausgeführt werden, können Sie docker ausführen Befehle gegen einen entfernten Docker-Host.
Die Verwendung eines Remotehosts kann in einigen Szenarien hilfreich sein. Sie könnten eine gemeinsam genutzte Docker Engine-Installation für ein kleines Entwicklungsteam einrichten. Jeder Entwickler könnte dann mit seinem lokalen docker exec eine Verbindung zu den Remote-Containern herstellen Befehl.
Remote-Hosts sind häufiger wertvoll, wenn Sie einen leistungsstarken Server haben, der ungenutzt bleibt. Wenn Ihr Laptop langsam ist oder keinen Speicherplatz mehr hat, kann die Verwendung eines dedizierten Docker-Hosts in Ihrem Netzwerk die Leistung erheblich steigern. Sie haben immer noch den ganzen Komfort des lokalen docker CLI in Ihrem Terminal.
Einrichten des Remote-Hosts
Stellen Sie sicher, dass Docker auf dem System installiert ist, das Ihr Remote-Host sein wird. Sie benötigen lediglich das docker-cli Paket auf Ihrem lokalen Computer, da Sie Docker Engine nicht ausführen werden.
Eine frische Docker-Installation stellt standardmäßig einen Unix-Socket bereit. Für den Fernzugriff ist ein TCP-Socket erforderlich. Führen Sie dockerd aus (die ausführbare Docker-Daemon-Datei) mit -H Flag, um die Sockets zu definieren, an die Sie binden möchten.
sudo dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375
Dieser Befehl bindet Docker an den Standard-Unix-Socket und Port 2375 auf der Loopback-Adresse Ihres Computers. Sie können zusätzliche Sockets und IP-Adressen binden, indem Sie -H wiederholen Flagge.
Die Flags müssen jedes Mal übergeben werden, wenn Sie dockerd ausführen . Wenn Sie möchten, dass sie nach Neustarts bestehen bleiben, erstellen Sie entweder einen Shell-Alias oder ändern Sie die Definition des Docker-Dienstes. So können Sie letzteres mit systemd erreichen , die die meisten Linux-Distributionen für die Dienstverwaltung verwenden.
Bearbeiten Sie /etc/systemd/system/docker.service.d/options.conf (oder erstellen Sie es, wenn es nicht existiert). Suchen Sie den [Service] Abschnitt und ändern Sie den ExecStart Zeile:
[Service] ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375
Laden Sie Ihr systemd neu Konfiguration, um die Änderungen zu übernehmen:
sudo systemctl daemon-reload
Wenn Docker bereits ausgeführt wird, verwenden Sie sudo systemctl restart docker um den Dienst neu zu starten. Der Docker-Daemon bindet sich jetzt bei jedem Start an den TCP-Port 2375. Stellen Sie sicher, dass der Datenverkehr zum Port von Ihrer Firewall-Konfiguration zugelassen wird. Wenn Sie ufw verwenden, führen Sie ufw allow 2375 aus um den Port zu öffnen.
Herstellen einer Verbindung zum Remotehost
Die Docker-CLI verwendet den DOCKER_HOST Umgebungsvariable, um den Host zu bestimmen, zu dem eine Verbindung hergestellt werden soll. Der Unix-Socket des lokalen Daemons wird verwendet, wenn die Variable nicht gesetzt ist.
Sie können einen Remote-Host für einen einzelnen docker verwenden Befehl, indem Sie DOCKER_HOST voranstellen Variable:
DOCKER_HOST=tcp://192.168.0.1:2375 docker run httpd:latest -d
Dadurch wird ein neuer Container von httpd:latest gestartet image mit der Docker-Engine unter 192.168.0.1:2375 .
Wenn Sie mehrere Befehle in einer Sitzung ausführen, exportieren Sie DOCKER_HOST Variable in Ihre Shell:
export DOCKER_HOST=tcp://192.168.0.1:2375 docker run httpd:latest -d --name httpd docker ps docker rm httpd --force
Sie können docker erstellen Verwenden Sie immer einen Remote-Host, indem Sie DOCKER_HOST festlegen global in der Konfigurationsdatei Ihrer Shell. So würden Sie das in Bash machen:
echo "export DOCKER_HOST=tcp://192.168.0.1:2375" >> ~/.bashrc
Nun der DOCKER_HOST Umgebungsvariable wird jedes Mal gesetzt, wenn Ihre Shell startet.
Verbesserte Sicherheit
Der grundlegende TCP-Socket ist ungeschützt. Jeder, der Ihren Computer über das Netzwerk erreichen kann, kann den Docker-Socket verwenden, um Ihre Container zu steuern.
Docker unterstützt SSH statt TCP. Dies ist normalerweise eine bessere Option, wenn der Host über einen SSH-Server verfügt. Es verhindert, dass nicht authentifizierte Benutzer Zugriff erhalten. Die Verwendung von SSH erfordert keine zusätzliche Konfiguration. DOCKER_HOST lässt Sie eine SSH-Verbindungszeichenfolge übergeben:
DOCKER_HOST=ssh://user@hostname docker run -d --name httpd
Alternativ können Sie SSH-Bindungen verwenden, um den Docker-Unix-Socket des Remote-Hosts direkt an Ihren lokalen Computer zu binden:
ssh -L /var/run/docker.sock:/var/run/docker.sock
Jetzt müssen Sie DOCKER_HOST nicht mehr verwenden überhaupt. Die entfernte docker.sock wird an sein lokales Gegenstück gebunden. Docker erkennt dies automatisch als Standard-Unix-Socket.
Die Verwendung einer der SSH-basierten Lösungen ist der bevorzugte Weg, um die Docker-Daemon-Sicherheit anzugehen. Docker unterstützt auch TLS, wenn Sie eine Zertifizierungsstelle sowie Server- und Clientschlüssel angeben:
dockerd --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=0.0.0.0:2375
Jetzt können sich Clients auf Port 2375 verbinden, wenn sie ein gültiges SSL-Zertifikat präsentieren, dem die Zertifizierungsstelle ca.pem vertraut .
VERBUNDEN: Was ist eine PEM-Datei und wie wird sie verwendet?
Kontexte erstellen
Mit Docker können Sie mehrere „Kontexte“ für die Verbindung zu verschiedenen Hosts einrichten. Kontexte können anstelle von DOCKER_HOST verwendet werden Umgebungsvariable. Sie erleichtern das Wechseln zwischen mehreren Remote-Hosts.
docker context create --docker host=tcp://192.168.0.1:2375 --description remote docker context create --docker host=unix:///var/run/docker.sock --description local
Diese Befehle erstellen zwei verschiedene Kontexte – einen für Ihre lokale docker.sock und eine für eine Remote-Verbindung.
Sie können mit docker context use zwischen Kontexten wechseln Befehl:
docker context use remote # Container is started on "remote" docker run httpd:-latest -d docker context use local # Lists containers running on "local" docker ps
Kontexte sind nützlich, wenn Sie mit mehreren Docker-Hosts arbeiten. Sie sind weniger umständlich als das ständige Zurücksetzen des DOCKER_HOST Variable, wenn Sie sich zwischen Hosts bewegen.
Nachteile von Remote-Hosts
Wir haben bereits angemerkt, dass ein Remote-Host die Build-Leistung verbessern kann. Diese Aussage trifft nur zu, wenn die Maschine, auf der Docker Engine ausgeführt wird, schneller ist als Ihre lokale Hardware. Der größte Nachteil eines Remote-Hosts ist der zusätzliche Aufwand für die Interaktion über das Netzwerk. Sie werden auch vom Netzwerk abhängig – wenn Sie die Verbindung verlieren, können Sie Ihre Container nicht mehr verwalten.
Sie sollten über eine zuverlässige Hochgeschwindigkeits-Netzwerkverbindung verfügen, wenn Sie einen Remote-Host als Haupt-Build-Server verwenden. Der erste docker build stage sendet den Inhalt des Build-Kontexts Ihres Images (normalerweise Ihr Arbeitsverzeichnis) an Docker Engine. Dies ist schnell, wenn Docker lokal ausgeführt wird, aber das Hochladen auf einen Remote-Computer kann viel länger dauern.
Das Offenlegen einer Docker-Daemon-Instanz über das Netzwerk ist ein Sicherheitsrisiko. Sie müssen sicherstellen, dass der Zugriff auf autorisierte Benutzer und Geräte beschränkt ist. Die unbeabsichtigte Offenlegung eines Docker-Daemon-Sockets könnte Angreifern unbegrenzten Zugriff auf den Host verschaffen. Docker wird normalerweise als root ausgeführt Daher ist es wichtig, dass nur vertrauenswürdige Personen Container starten können.
Schlussfolgerung
Durch das Einrichten eines Remote-Docker-Hosts können Sie Ihre Containerinstanzen von Ihrem lokalen Entwicklungscomputer trennen. Ein dedizierter Docker-Build-Server kann eine verbesserte Leistung und mehr Bildspeicherplatz bieten.
Sie sollten darauf achten, die Sicherheit Ihrer Implementierung zu überprüfen. Ein einfacher TCP-Socket kann in einem privaten Netzwerk sicher sein, sollte aber nicht in sensiblen Umgebungen eingesetzt werden. Die Verwendung von SSH trägt dazu bei, die Risiken zu mindern, wenn Sie eine gute SSH-Sicherheitshygiene praktizieren, wie z. B. eine obligatorische schlüsselbasierte Authentifizierung.