Ich mag Docker. Wirklich. Und zugegebenermaßen habe ich mich jetzt eine Weile nicht mehr so intensiv mit Docker beschäftigt wie z.B. vor einem Jahr. Momentan baue ich ein kleines Docker-Image für Backups, und so kam es dazu, dass ich mich kurz auf den Docker-Seiten umgesehen habe. Der Docker Hub ist nun also veraltet und wurde durch Docker-Cloud ersetzt. Ok… Die Webseiten unterliegen ebenfalls einiger Veränderung, nur was soll dieser Farbwechsel im Header, der direkt aus der Demo-Hölle entsprungen zu sein scheint? Diese ignorierend bin ich zur Docker-Cloud vorgedrungen und konnte immerhin feststellen, dass die Images aus dem Docker Hub übernommen worden sind. Und der Login bzw. die Docker-ID gilt ebenfalls noch. Wunderbar.
Docker – Versionen und Namen
Ein wenig überrascht hat mich die Versionsangabe in der rechten oberen Ecke der Docker-Dokumentation. Dort stand zu lesen, dass Docker v17.06 (current) anscheinend die aktuelle sei. Auf meinen Maschinen läuft zwar bereits die dreimal umbenannte und aktuelle Fassung namens „docker-ce„, aber bei der Version wurde ich stutzig. Schnell geprüft:
$ docker version Client: Version: 17.05.0-ce API version: 1.29 Go version: go1.7.5 Git commit: 89658be Built: Thu May 4 22:20:42 2017 OS/Arch: linux/amd64
Also nicht ganz aktuell – nicht weiter tragisch, aber da es sich nicht um produktive Systeme handelt, sondern um private Test-Server, wollte ich schon gerne die aktuelle Version installieren. Sollte ja kein Problem sein. Also wie üblich:
geschke@pirita:~$ sudo apt update Holen:1 http://security.ubuntu.com/ubuntu zesty-security InRelease [89,2 kB] OK:2 http://de.archive.ubuntu.com/ubuntu zesty InRelease OK:3 http://de.archive.ubuntu.com/ubuntu zesty-updates InRelease OK:4 http://de.archive.ubuntu.com/ubuntu zesty-backports InRelease OK:5 https://apt.dockerproject.org/repo ubuntu-zesty InRelease Es wurden 89,2 kB in 0 s geholt (118 kB/s). Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Alle Pakete sind aktuell.
Ok… Hat Docker neue Versionen? Ist „current“ nicht „current“? Haben sie die v17.06 noch nicht auf die Öffentlichkeit los gelassen?
Ergo kurzerhand nach der Installationsanleitung für Ubuntu gesucht. Allein der Weg dorthin war anfangs ein wenig steinig, denn bei „Product Manuals“ wurden einem unter „Tools“ zwar „Installation guides“ beim Punkt „Docker for Linux“ angeboten, nur war in der seitlichen Navigation davon nichts zu finden. Danach befand man sich aber im Haupt-Navigationspunkt „Guides“, und nach weiteren zwei Klicks immerhin auf der Ubuntu Anleitung für die Docker Community Edition Installation.
Das mag bis hierhin Meckern auf hohem Niveau sein, immerhin bietet Docker mittlerweile Tonnen an Informationen und Dokumentation an, allerdings merkt man die stetige und sehr schnelle Veränderung den Web-Seiten auch an. Mitunter leidet damit die Konsistenz, jedenfalls habe ich nicht zum ersten Mal nach der richtigen Stelle im Manual gesucht.
Nach kurzer Durchsicht wurde klar, was das Problem sein könnte. Zwar hatte ich die letzte Docker-Version nach Anleitung installiert, aber damals war wieder alles anders. Die aktuell vorhandene Paket-Download-Location in der Datei /etc/apt/sources.list.d/docker.list sah wie folgt aus:
deb [arch=amd64] https://apt.dockerproject.org/repo ubuntu-zesty main
Einige der Vorbereitungen waren bereits getroffen, so mussten die Packages für apt nicht mehr installiert werden – schließlich lief Docker bereits auf dem System!
Weiter also mit dem – wie es aussah ebenfalls neuen – GPG-Key:
geschke@pirita:~$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
OK
geschke@pirita:~$ sudo apt-key fingerprint 0EBFCD88
pub rsa4096 2017-02-22 [SCEA]
9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88
uid [ unbekannt ] Docker Release (CE deb) <docker@docker.com>
sub rsa4096 2017-02-22 [S]
Verglichen mit dem Fingerprint auf den Docker-Seiten – sah ok aus.
Danach hieß es, die aktuelle Download-Location anzugeben. Docker schlägt dazu folgendes vor:
$ sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable"
Das geht zwar schön automatisch in einem Satz, aber leider wird damit das Repository der Haupt-Datei /etc/sources.list hinzugefügt. Wozu gibt es das Verzeichnis /etc/apt/sources.list.d/ mit der Möglichkeit, dort explizit Locations anzugeben, die nicht zur Distribution gehören? Das erspart nicht zuletzt Ärger bei weiteren Upgrades. Und ich meine sogar, dass dieses Verfahren in irgend einer der früheren Docker-Varianten vorgeschlagen bzw. sogar ausgeführt wurde, da gab es doch mal ein Shellskript zur Installation…
Somit erstmal das o.g. Kommando ausgeführt – unter der Prämisse, später die Datei /etc/apt/sources.list wieder aufräumen zu müssen. Folgende zwei Zeilen wurden hinzugefügt:
deb [arch=amd64] https://download.docker.com/linux/ubuntu zesty stable # deb-src [arch=amd64] https://download.docker.com/linux/ubuntu zesty stable
Diese Zeilen ersetzten damit den Inhalt der Datei /etc/sources.list.d/docker.list, aus der Haupt-Datei /etc/apt/sources.list habe ich die Zeilen dann wiederum entfernt.
Danach ein beherztes
sudo apt update
gefolgt von einem
sudo apt -s upgrade
Man will ja schließlich nachschauen, was genau updated werden soll. Aber – nichts zu finden:
geschke@pirita:~$ sudo apt -s upgrade Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Paketaktualisierung (Upgrade) wird berechnet... Fertig 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Ok.. Da war noch ein Hinweis, man solle alte Versionen deinstallieren. Aber so alt war meine Version doch gar nicht, „docker version“ gab immerhin ein 17.05.0-ce aus. Insofern schien die „Community Edition“ installiert zu sein?
Aber der Paketname war ein anderer bzw. lautete noch nicht docker-ce! Daher der Hinweis, zuvor alle bisherigen Versionen zu entfernen, darin fanden sich inzwischen bereits drei Bezeichnungen:
sudo apt-get remove docker docker-engine docker.io
Bei mir reichte ein „sudo apt remove docker-engine“ – immerhin sollten die relevanten Verzeichnisse für Images und Container ja erhalten bleiben.
Nun endlich docker-ce installiert:
geschke@pirita:/etc/apt/sources.list.d$ sudo apt install docker-ce Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Die folgenden NEUEN Pakete werden installiert: docker-ce 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. Es müssen 20,6 MB an Archiven heruntergeladen werden. Nach dieser Operation werden 96,2 MB Plattenplatz zusätzlich benutzt. Holen:1 https://download.docker.com/linux/ubuntu zesty/stable amd64 docker-ce amd64 17.06.0~ce-0~ubuntu [20,6 MB] Es wurden 20,6 MB in 2 s geholt (8.709 kB/s). Vormals nicht ausgewähltes Paket docker-ce wird gewählt. (Lese Datenbank ... 97238 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von .../docker-ce_17.06.0~ce-0~ubuntu_amd64.deb ... Entpacken von docker-ce (17.06.0~ce-0~ubuntu) ... docker-ce (17.06.0~ce-0~ubuntu) wird eingerichtet ... Trigger für ureadahead (0.100.0-19) werden verarbeitet ... Trigger für systemd (232-21ubuntu5) werden verarbeitet ... Trigger für man-db (2.7.6.1-2) werden verarbeitet ...
Das sieht doch ganz gut aus, mal schnell testen:
geschke@pirita:/etc/apt/sources.list.d$ docker version Client: Version: 17.06.0-ce API version: 1.30 Go version: go1.8.3 Git commit: 02c1d87 Built: Fri Jun 23 21:18:10 2017 OS/Arch: linux/amd64 Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? geschke@pirita:/etc/apt/sources.list.d$ docker images Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Leider doch weniger gut – zwar ist Docker in der neuen Version 17.06-ce nun installiert, aber der Daemon läuft nicht. Damit lässt sich somit nichts anfangen.
Wie erwartet konnte der Docker-Daemon nicht erfolgreich gestartet werden:
geschke@pirita:/etc/apt/sources.list.d$ sudo systemctl status docker.service
● docker.service
Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2017-07-24 16:03:45 CEST; 3min 48s ago
Main PID: 7996 (code=exited, status=1/FAILURE)
CPU: 18ms
Jul 24 16:03:45 pirita systemd[1]: Started docker.service.
Jul 24 16:03:45 pirita docker[7996]: `docker daemon` is not supported on Linux. Please run `dockerd` directly
Jul 24 16:03:45 pirita systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jul 24 16:03:45 pirita systemd[1]: docker.service: Unit entered failed state.
Jul 24 16:03:45 pirita systemd[1]: docker.service: Failed with result 'exit-code'.
Wieder eine kleine, aber auffällige Änderung. Immerhin ist die Fehlermeldung relativ eindeutig, nichtsdestotrotz habe ich mich noch im Netz umgeschaut und u.a. diese Diskussion eines bislang ungelösten Falles gefunden. Anscheinend tritt das Problem nicht nur bei Upgrades auf, sondern auch bei mit „docker-machine“ neu eingerichteten Docker Hosts, bei denen die entsprechende Konfigurationsdatei (die Quelle nennt /etc/systemd/system/docker.service.d/10-machine.conf) nicht erzeugt wird.
Bei mir war die Ursache in der Datei /etc/systemd/system/docker.service zu finden. Der bisherige Inhalt lautete wie folgt:
[Service] ExecStart=/usr/bin/docker daemon -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --storage-driver btrfs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label instance=xlarge --label provider=generic MountFlags=slave LimitNOFILE=1048576 LimitNPROC=1048576 LimitCORE=infinity Environment= [Install] WantedBy=multi-user.target
Nun gibt es das Kommando docker daemon nicht mehr, sondern wurde durch „dockerd“ ersetzt. Somit geändert:
[Service] ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --storage-driver btrfs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label instance=xlarge --label provider=generic [...]
Hinweis: Auch die Existenz der Datei /etc/systemd/system/docker.service ist den bisherigen Updates geschuldet bzw. es kann sein, dass Docker sich inzwischen wieder eine andere Stelle überlegt hat, an der die Systemd-Konfigurationsdatei zu finden ist.
Nun noch systemd den geänderten Inhalt beibringen:
$ sudo systemctl daemon-reload
und den Docker-Daemon starten:
$ sudo systemctl start docker.service
Das sieht nun wieder besser aus! Client und Server laufen:
$ docker version Client: Version: 17.06.0-ce API version: 1.30 Go version: go1.8.3 Git commit: 02c1d87 Built: Fri Jun 23 21:18:10 2017 OS/Arch: linux/amd64 Server: Version: 17.06.0-ce API version: 1.30 (minimum version 1.12) Go version: go1.8.3 Git commit: 02c1d87 Built: Fri Jun 23 21:17:03 2017 OS/Arch: linux/amd64 Experimental: false
Das bestätigt auch der Blick ins systemd-Log:
$ sudo systemctl status docker.service
● docker.service
Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2017-07-24 16:30:32 CEST; 1min 29s ago
Main PID: 8895 (dockerd)
Tasks: 27 (limit: 4915)
Memory: 36.9M
CPU: 5.883s
CGroup: /system.slice/docker.service
├─8895 /usr/bin/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --storage-driver btrfs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label instance=xlarge --label provider=generic
└─8910 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcontainerd/containerd --shim docker-containerd-shim --runtime docker-runc
[...]
Nun heißt es jedoch, diese doch recht manuellen Schritte auf den anderen Docker Hosts ebenso auszuführen.
Fazit
Ich mag Docker ja noch immer. Aber man merkt dem System an, dass es schnell wächst, mitunter etwas zu schnell, so dass manches außen vor bleibt.
Einen Upgrade-Prozess gibt es de-facto nicht. Das fängt bei der Änderung der Repository-URL an und hört bei der Streichung eines Kommandos noch lange nicht auf. Immerhin gibt Docker den richtigen Hinweis aus – von wegen „docker daemon“ wurde durch „dockerd“ ersetzt, den Rest muss man jedoch umständlich manuell erledigen.
Ebenfalls existiert keine Dokumentation des Upgrade-Prozesses, oder wenigstens eine FAQ, die derartige Probleme klar bezeichnet und Lösungen beschreibt. Die Diskussionen bzw. Fehlereinträge auf Github sprechen für sich. Was mich daran wundert, ist, dass trotz der schnellen Weiterentwicklung jene Fälle doch recht lange geöffnet bleiben und keine zügige Behebung stattfindet.
Zwar läuft nun alles wieder – zumindest bis zum nächsten Upgrade, zur nächsten Repository-Änderung, Umbenennung usw..
Nachtrag
Im Zuge des Upgrade-Reigens wollte ich Docker auch auf einem anderen Host aktualisieren, dessen Grundlagen ein wenig neuer waren. Immerhin gab es dabei weniger Probleme, da der letzte Schritt nicht mehr notwendig war. Das systemd-Konfigurationsfile beinhaltete bereits den Aufruf von dockerd:
geschke@waren:/etc/apt/sources.list.d$ systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2017-07-24 22:50:54 CEST; 2min 15s ago
Docs: https://docs.docker.com
Main PID: 24336 (dockerd)
CGroup: /system.slice/docker.service
├─24336 /usr/bin/dockerd -H fd://
└─24343 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --m
[...]
Insofern lief der Docker-Daemon auch nach dem Upgrade wieder. Und nicht zuletzt legt das systemd-Konfigurationsfile unter /lib/systemd/system/docker.service.
