Docker for AWS lokal steuern

Mit Docker for AWS fällt das Einrichten eines Docker-Swarm-Clusters in der Cloud leicht. Allerdings lässt sich Docker von Haus aus nur lokal ansprechen, man muss sich also stets zunächst per SSH anmelden, was einige Nachteile mit sich bringt. Wie lässt sich das besser lösen?

In Pocket speichern vorlesen Druckansicht
Lesezeit: 5 Min.
Von
  • Golo Roden
Inhaltsverzeichnis

Mit Docker for AWS fällt das Einrichten eines Docker-Swarm-Clusters in der Cloud leicht. Allerdings lässt sich Docker von Haus aus nur lokal ansprechen, man muss sich also stets zunächst per SSH anmelden, was verschiedene Nachteile mit sich bringt. Wie lässt sich das besser lösen?

Das Einrichten eines Docker-Swarm-Clusters auf AWS ist dank Docker for AWS in wenigen Minuten erledigt. Die zur Verfügung gestellte CloudFormation-Vorlage erfragt lediglich einige wenige Werte und richtet anschließend alles automatisch ein.

Zu den erfragten Werten gehören unter anderem die Anzahl der Manager und der Worker, aber auch der zu verwendende SSH-Schlüssel. Diesen nutzt Docker for AWS, um den Zugriff auf die einzelnen EC2-Instanzen zu konfigurieren, wobei der Zugriff von außen lediglich auf die Manager gestattet ist. Der Zugriff auf die Worker ist nur von den Managern aus möglich.

Das ist aus der Sicherheitsperspektive sinnvoll und funktioniert auf den ersten Blick auch problemlos. Meldet man sich per SSH auf einem der Manager an und führt beispielsweise das Kommando

$ docker service create -p 80:80 -p 443:443 --replicas 3 nginx

aus, startet der Manager wie erwartet drei Instanzen von Nginx und verteilt sie im Cluster. Schwieriger wird es allerdings, wenn man das Gleiche mit einem privaten Image durchführen möchte. Dann fehlt nämlich die Authentifizierung. Das ließe sich durch das Kommando

$ docker login

beheben, doch hinterlässt das kein gutes Gefühl. Immerhin verbleiben persönliche Zugangsdaten, die nur sporadisch benötigt werden, auf einem Server.

Versucht man als Nächstes, ein Image auf Basis einer Dockerfile-Datei zu bauen, bemerkt man, dass der Build-Kontext nicht mehr dem des lokalen Systems entspricht und ein docker build daher nicht funktionieren kann. Das ist wenig verwunderlich, denn man hat per SSH auf ein anderes System gewechselt.

Als Ausweg bietet sich scheinbar an, den Docker-Endpunkt des Managers anzusprechen. Die Vermutung liegt nahe, dass man dazu lediglich die lokale Umgebungsvariable DOCKER_HOST auf den passenden Wert setzen muss. Die Authentifizierung, so erwartet man, müsste dann per Zertifikat möglich sein. Doch welches Zertifikat ist zu verwenden?

Wie sich herausstellt, konfiguriert Docker for AWS die Manager gar nicht derart, dass sich deren jeweiliger Docker-Endpunkt über das Netzwerk ansprechen ließe. Das funktioniert ausschließlich lokal über /var/run/docker.sock. Darauf lässt sich jedoch nicht von einem entfernten System zugreifen.

Die Lösung liegt darin, mithilfe von SSH einen Tunnel zu öffnen, der /var/run/docker.sock eines Managers mit einem Port des lokalen Systems verbindet. Dazu dient in SSH der Parameter -L. Außerdem muss man SSH mitteilen, dass es lediglich den Tunnel öffnen, aber kein Kommando ausführen soll. Das lässt sich mit dem Parameter -N erledigen. Zu guter Letzt ist der zu verwendende SSH-Schlüssel mit dem Parameter -i anzugeben:

$ ssh -i aws.pem -N -L 2375:/var/run/docker.sock docker@$IPADDRESS

Das öffnet die Verbindung und ermöglicht den lokalen Zugriff auf Docker. Dazu ist die Umgebungsvariable DOCKER_HOST auf den Wert tcp://localhost:2375 zu setzen. Alle anderen eventuell von docker-machine festgelegten Umgebungsvariablen müssen mithilfe von unset entfernt werden:

$ unset DOCKER_TLS_VERIFY
$ unset DOCKER_CERT_PATH
$ unset DOCKER_MACHINE_NAME
$ export DOCKER_HOST=tcp://localhost:2375

Führt man nun beispielsweise das Kommando

$ docker ps

aus, greift der lokale Docker-Client über den SSH-Tunnel auf den Docker-Manager zu, der auf AWS läuft. Der Tunnel bleibt so lange geöffnet, bis man das ssh-Kommando durch einen Tastendruck auf Strg[Icaps] + [caps]C abbricht. Nun funktioniert auch docker build wie erwartet.

Problematisch ist allerdings weiterhin der Zugriff auf private Images, beispielsweise bei der Verwendung von docker service create. Da der Manager in dem Fall den Workern lediglich die Aufgabe erteilt, das passende Image herunterzuladen, statt das selbst durchzuführen, scheitern diese an der Authentifizierung.

Als Ausweg dient der Parameter --with-registry-auth, der die Authentifizierung des lokalen Docker-Clients durchschleift. Auf dem Weg funktioniert dann auch das Kommando docker service create wie erwartet.

tl;dr: Docker for AWS ermöglicht das einfache Einrichten eines Docker-Swarm-Clusters auf AWS. Nicht ganz so einfach ist allerdings die bequeme Verwaltung des Clusters vom lokalen Rechner. Ein SSH-Tunnel schafft Abhilfe. ()