Docker-Upgrade – immer wieder für eine Überraschung gut

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. 

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:

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:

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:

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:

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:

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:

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 

gefolgt von einem 

Man will ja schließlich nachschauen, was genau updated werden soll. Aber – nichts zu finden:

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:

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:

Das sieht doch ganz gut aus, mal schnell testen:

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:

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:

Nun gibt es das Kommando docker daemon nicht mehr, sondern wurde durch „dockerd“ ersetzt. Somit geändert:

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:

und den Docker-Daemon starten:

Das sieht nun wieder besser aus! Client und Server laufen:

Das bestätigt auch der Blick ins systemd-Log:

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:

Insofern lief der Docker-Daemon auch nach dem Upgrade wieder. Und nicht zuletzt legt das systemd-Konfigurationsfile unter /lib/systemd/system/docker.service.

Ähnliche Beiträge

Tags:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.