docker run - Error: No such image

[Chris122]

Hallo liebe Forengemeinde!

Ich sitze jetzt seit zwei Tagen an folgendem Problem:

Ich habe bislang 4 Dockercontainer auf einer 716+ii, aktuellstes DSM, aktuellster Docker, einwandfrei laufen. Nun wollte ich noch einen Watchtower-Container hinzufügen und zwar wie folgt:

1. Docker-GUI in der DSM-Oberfläche geöffnet, parallel in der Shell als root eingeloggt.
2. Shell: docker pull containrrr/watchtower:0.3.4
3. Shell: docker run -d -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower:0.3.4 --debug

Soweit so gut, um die weitere optionale Umgebungsvariablen wollte ich mich später kümmern. Das Image also wurde heruntergeladen, der Container generiert. In diesem Moment ist mir aufgefallen, dass ich eigentlich das Image von v2tec und nicht von containrrr verwenden wollten und klickte ins Docker-GUI, um dort den frisch generierten Container zu stoppen und zu löschen (zwei Klicks kamen mir schneller vor als die commands über die Shell). Dabei fiel mir auf, dass nicht nur der Watchtower-Container, sondern auch noch ein weiterer Container generiert wurde (wohl vom Watchtower-Container, woher sonst?), der als brave_galileo bezeichnet war. Leider hab ich in dem Moment nicht aufgepasst und zu schnell beide Container über das Docker-GUI gelöscht.

In weiterer Folge hab ich also das containrrr-Image gelöscht und das eigentlich gewünschte Image v2tec/watchtower:latest geladen und sodann über die Shell wie in Punkt 3 versucht, wieder einen neuen Container, diesmal vom v2tec-Image, zu generieren. Das funktioniert auch soweit, aber die generierten Container stoppen sofort und geben folgende Log aus:

time="2019-04-30T18:03:17Z" level=fatal msg="Error: No such image: sha256:fb8e13603349ba1aa02bc3cd99e5a39e046990e8b5cf7d7db039a4b46c0e0b04"

Seither, hab ich x-Mal versucht neue Container aus allen möglichen Images zu generieren (immer über die Shell), hab dazu auch sowohl von containrrr als auch v2tec alle Images geladen die es gibt (pull -a), bekomm aber immer exakt den gleichen Error-Log.

Ich hab natürlich auch schon Google an den Rand des Gebrechens gebracht und gelesen, dass der sha256 scheinbar ein Docker-Registry-Eintrag ist, auf den immer wieder Bezug genommen wird. Der sha256 gehört also zu einem ganz bestimmten Image, welches ich so aber nicht mehr finde (ich hab alle sha256 mittels docker images ls -a geprüft, nachdem ich ALLE v2tec und containrrr/watchtower Images geladen hatte, der im Error-Log genannten ist nicht dabei). Dennoch nimmt docker run scheinbar immer wieder nur auf diesen einen sha256:fb8e136033[...] Bezug.

Nun meine Frage:
Was muss ich tun, dass docker run ganz wie gewohnt nicht statisch auf den oben genannten sha256-Wert Bezug nimmt (der keine Ahnung zu welchem Image gehört - jedenfalls keines mehr, was ich im Repository hab), sondern den sha256-Wert des im docker run Befehls angeführten Images:Tag heranzieht?

Ich hab Lösungen gefunden, von wegen Registry-Einträge manuell löschen, wo in manifest-Folders die sha256-Einträge liegen. Dabei stoße ich vor das Hinderniss, dass ich mit Curl keine Registryeinträge löschen kann (Error 405, not allowed) und mittels Shell-befehl rm keine Löschungen vornehmen kann, weil ich meine docker-registry nicht finden kann (jedenfalls nicht in /var/lib/...).

Ich bin für jeden Vorschlag sehr dankbar, da mein Docker im aktuellen Zustand "handlungsunfähig" ist.

Da es sich scheinbar um ein docker-spezifisches Problem handelt: würde im worst case eine Docker De- und Reinstallation über das Paketzentrum nützen, um den verkorxten Zustand auf "Werk" zurücksetzen?

Ist es möglich mittels docker run nicht nur auf das gewünschte Image:Tag (zB containrrr/watchtower:0.3.4) zu verweisen, sondern docker run direkt anzuweisen, ein bestimmtes Image mit einem bestimmten sha256 zur Containererstellung zu verwenden? Somit könnte ich diesen "automatischen" Verweis auf den nicht existenten sha256:fb8e136033[...] doch gewissermaßen übergehen ...

Lieber wäre mir aber natürlich, docker run würde wie gewohnt einfach das Image mit dem Tag (und dem damit verbundenen sha256) heranziehen, welches ich ihm im run commando übergebe.

Vielen Dank schonmal für eure Rückmeldungen!

LG
Chris


EDIT:
Ich habs gestern nicht mehr gefunden und heute am ersten Blick am Schirm gehabt: ich kann mittels docker run image@digest scheinbar auf einen ganz bestimmten sha256-Wert verweisen, müsste so also laufende Container aus meinem gewünschten Image im Repository erzeugen können. Ich kann es nur leider frühestens in 2 Tagen wieder testen, da ich bis dahin keinen Shell-Zugriff auf meine Syno hab (SSH-Ports sind nur lokal offen, ich bin unterwegs).

Aber selbst wenn das funktionieren würde, müsste ich dann künftig trotzdem bei jedem Container den ich erstellen möchte, zwingend mit @digest arbeiten, solange Docker von sich aus nur auf diesen einen bestimmten sha256:fb8e136033[...] verweist, wenn er nur einen Tag (zB latest) übergeben bekommt (was aber die wesentlich benutzerfreundlichere Variante ist

 

[haydibe]

Ohne alles gelesen zu haben:
1. Deine DockerID Credentials nicht in der Docker-UI hinterlegen, dass führt bei den meisten zu Problemen
2. Synology hat Docker so verbogen, dass die Host-Seite eines Binds NUR auf einem Share liegen darf. Leg Dir einen Symlink auf /var/run/docker.sock innerhalb eines Shares an und verwende diesen als Host-Seite deines Binds.

 

[Chris122]

1) geht klar
2) ich leg den Symlink an und versuchs nochmal

Wie oben geschrieben kann ich's aber erst morgen Abends testen, da ich solange nicht mittels SSH auf die DS zugreifen kann.

Das Digest-Problem spielt sich ja rein image-seitig ab, wenn ich das richtig verstanden habe ... wenn der Container startet, bezieht sich der Error-Log ja darauf, dass er das Image mit dem angegebenen Digest sha265-Hexwert nicht findet. Zur Anbindung kommt es ja erst gar nicht, da der Container mangels Image anhält ... oder kommt es schon und daher kein Log diesbzgl. Oder seh ich das falsch?

Danke für deine Antwort!

 

[haydibe]

Jedes Tag zeigt auf ein oder mehr Image-Layer, die jeweils über die SHA256 checksum eindeutig identifiziert werden können. Die SHA256 ID wird eigentlich nur dann verwendet, wenn ein Tag mutable verwendet wird und immer wieder neue Images unter dem selben Tag abgelegt werden (bspw. latest). Mit der SHA256 kann man das exakte Image wieder aus dem Hut zaubern.

Watchtower ermittelt tatsächlich auch neue Image-Layer über die SHA256 ID und verwendet diese beim pullen des Images und aktuallisieren des Containers. Davon sollte man eignetlich nichts mitbekommen. Irgendeiner Deiner Container referenziert ein Image via SHA256 ID und dieses scheinst Du weder lokal zu haben, noch scheint es das remote zu geben, bzw. dein lokaler Cache scheint inkonsitent zu sein. Ich würde alle aktuellem Container löschen ( "docker rm $(docker ps -aq)" ), die Images löschen ( "docker image rm $(docker image ls -q)" ) und dann neu anlegen lassen.

Wenn das nicht hilft, kannst Du Deinen Docker Package in der Paketverwaltung stoppen und die Docker Root löschen ("docker info | grep Root"), müsste /volume?/@docker sein. Dann einfach "rm -rf /volume?/@docker/*" verwenden und alles löschen. Danach das Docker Package wieder neu starten und Du hast eine jungräuliche Docker-Umgebung. Aber: dabei gehen alle laufenden Docker Container, lokal gecachten Docker Images, angelegte Volumes und angelegte Netzwerke verloren.

Möglicher Workaround: alle Container über die UI stoppen, alle Container auf die DS exportieren, mit einem Editor die .json Konfiguration anschauen, ob und in welchem Container das "Image:"-Element am Ende kein ":latest" bzw. ein konkretes Tag stehen hat.Den entsprechenden Container über die UI oder CLI löschen, das Tag in der json-Datei ergänzen und den Container neu importieren und starten. GGf. muss das Image vorher noch gepulled werden.

Viel Erfolg!

 

[Chris122]

Solved!!

Danke erstmal für deine Ausführungen zu den einzelnen Punkten. Da war schon der eine oder andere Aha-Moment dabei!

Irgendeiner Deiner Container referenziert ein Image via SHA256 ID und dieses scheinst Du weder lokal zu haben, ...

Nicht nur irgendein Container, sondern jeder Container, der mittels docker run erzeugt wurde, zeigte auf den oben angeführten Sha256.

... und dieses scheinst Du weder lokal zu haben, noch scheint es das remote zu geben, bzw. dein lokaler Cache scheint inkonsitent zu sein.

Genauso seh ich das auch, insb. gibt es diesen Sha256 tatsächlich nicht - wie du schreibst auch nicht remote!! Ich dachte ursprünglich mehr an die Registry als die Cache ... Wobei aber natürlich die Frage ist, inwieweit das run command auf Registy-Einträge zugreift ... dazu kenn ich mich insb. mit der Registry zu wenig aus. Übrigens war ich nach docker info erstaunt, dass der Syno-Docker noch Registry v1 verwendet.

Watchtower ermittelt tatsächlich auch neue Image-Layer über die SHA256 ID

Das wäre meine nächste Frage gewesen

Ich würde alle aktuellem Container löschen ( "docker rm $(docker ps -aq)" ), die Images löschen ( "docker image rm $(docker image ls -q)" )

Jep, hatte ich schon versucht, sicherheitshalber auch system prune drübergejagt - hatte ich vergessen zu schreiben. Das hatte keine Auswirkungen.

Wenn das nicht hilft, kannst Du Deinen Docker Package in der Paketverwaltung stoppen und die Docker Root löschen ("docker info | grep Root"), müsste /volume?/@docker sein. Dann einfach "rm -rf /volume?/@docker/*" verwenden und alles löschen.

Das meinte ich in meinem ersten Post, ob ich nicht den "Werkszustand" von Docker mittels de-/reinstallation des Docker-Pakets im Paketzentrum erreichen kann. Deine Variante ist natürlich deutlich professioneller - danke für die commands!!

Ich habs dann auch so gemacht, hab zuvor nur die Containereinstellungen gesichert (ich hab noch sehr wenige laufen, daher nicht so tragisch) und dann den Inhalt vom Docker-Rootpath gelöscht. Datenverluste hatte ich sonst keine, da ich die Speicherpfade der Container die Datenbanken erzeugen, ohnehin auf einen shared-folder gemountet hatte.

Nachdem ich das Docker-Paket, wie du schreibst "jungfräulich" wieder gestartet hatte, hab ich mir die Images wieder geholt und die Containerdaten aus den Sicherungen importiert. Die Wiederherstellung aller Dienste dauerte keine 5 Minuten.

Und das wichtigste: ES FUNKTIONIERT DANKE DIR!!

Watchtower läuft einwandfrei, hab mir testweise im debugmode die Logs genau angesehen - alles bestens!!

Synology hat Docker so verbogen, dass die Host-Seite eines Binds NUR auf einem Share liegen darf.

Ohne den Symlink aus deinen vorherigen Post, wärs aber auch nicht gegangen - der ist schon essentiell. Danke nochmals für's etwas ausführlicher werden - der eben zitierte Satz war mir so noch nicht bewusst, erklärt aber einiges, wenn man mit Docker noch nicht so vertraut ist.


Vielleicht kann jemand anderer deinen Workaround gut brauchen/testen, der deutlich mehr Container/Netzwerke laufen hat bzw. Datenverluste beim root-clearing zu befürchten hätte. Ich hab auf Github gesehen, dass das Problem mit der Sha256-ID scheinbar auch während des (ansich schon länger problemlos) laufenden Watchtower-Dienstes auftreten kann.


Jetzt hätte ich noch eine Frage: kann ich mir aus einem laufenden Container, alle Umgebungsvariablen die der Container unterstützt (weil grundsätzlich definiert), irgendwie ausgeben lassen? Nämlich auch die leeren Variablen, von denen ich vielleicht gar nicht weiß, dass es sie gibt (weil's nur ne miese oder gar keine Doku zum Image gibt)? Mit docker container inspect seh ich meines erachtens doch nur ENV-Variablen, die auch tatsächlich vom Container verwendet werden (also wenn sie, woher auch immer, einen Wert übergeben bekommen haben).


Danke nochmal für deine Bemühungen! Find ich echt super, dass man in einem Hilfe-Forum auch tatsächlich noch (wirklich gute) Hilfe bekommen kann!!

 

[haydibe]

Danke erstmal für deine Ausführungen zu den einzelnen Punkten.

Gerne. Es macht tatsächlich mehr spass zu unterstützen, wenn der Unterstützungsuchende so ausführlich erklärt was das Problem ist und was bisher probiert wurde.

Übrigens war ich nach docker info erstaunt, dass der Syno-Docker noch Registry v1 verwendet.

Dockerhub wird bei Syno-Docker mittels v1-API angesprochen. Solange Docker die auf Dockerhub nicht abschaltet haben wir kein Problem.

Ich hab auf Github gesehen, dass das Problem mit der Sha256-ID scheinbar auch während des (ansich schon länger problemlos) laufenden Watchtower-Dienstes auftreten kann.

Ich habe Watchtower seit Jahren auf drei Hosts laufen... ich hatte das Problem bisher nicht einmal.

Jetzt hätte ich noch eine Frage: kann ich mir aus einem laufenden Container, alle Umgebungsvariablen die der Container unterstützt (weil grundsätzlich definiert), irgendwie ausgeben lassen? Nämlich auch die leeren Variablen, von denen ich vielleicht gar nicht weiß, dass es sie gibt (weil's nur ne miese oder gar keine Doku zum Image gibt)? Mit docker container inspect seh ich meines erachtens doch nur ENV-Variablen, die auch tatsächlich vom Container verwendet werden (also wenn sie, woher auch immer, einen Wert übergeben bekommen haben).

Je nach Image werden für ENV-Variablen Default-Werte gesetzt und wären über 'docker inspect' einsehbar - das ist nicht immer der Fall. Dazu kommt das bei manchen Images ENV auch für Variablen verwendet wird, die zur Laufzeit gar nicht geändert werden dürfen ODER keine Wirkung haben. Solche Variablen hätten als ARG und nicht als ENV im Dockerfile deklariert werden müssen.

Bei guten Images sollte die Beschreibung auf Dockerhub auch gleichzeitig die Dokumentation sein oder darauf verwaisen... In der Regel werden Images mit ordentlicher Beschreibung auch öfter gepflegt, als Images mit keiner oder schlechter Beschreibung.

Wenn man trotzdem ein schlecht beschriebenes Image verwenden will:
1. Dockerfile auf Dockerhub bzw. der verlinkten Github-Seite anschauen
2. Verwendete environment-Variablen des Containers ausgeben lassen mit `docker exec -ti {containerid} env` - wenn Variablen mit Default-Werten initiert werden, sollten sie hier zu sehen sein - diese KÖNNEN relevant sein , müssen aber nicht (Erklärung weiter unten).
3. Entrypoint-Skript aus dem Dockerfile auf der verlinkten Github-Seite analysieren
- Alternative1: mit 'docker exec -ti {containerid} /bin/bash' (manchmal gibt es nur /bin/sh) ein Terminal im Container aufmachen und im Container ansehen
- Alternative2: mit `docker cp {containerid}:{pfad/zum/entrypoint/script} {pfad/zur/lokalen/kopie} aus dem Container kopieren und dann auf der DS anschauen oder in einen Share legen und bequem mit VisualStudio Code ansehen

Alle Variablen die im Entrypoint-Skript oder in einem davon aufgerufenen Skript genutzt, aber nicht deklariert werden, bzw. bei der Deklaration eine "bestehende Variable" als Default verwenden, sind Kandidaten für ENV-Variablen. Meist sind das Varianten in der die Variable mit einem Default-Wert überschrieben wird, wenn diese leer ist wird sie durch einen Default-Wert ersetzen = 'ENV-VAR=${Default-Wert:-ENV-VAR}' oder eine neue Variable eingeführt wird, die dann den Wert erhält: 'TEMP=${Default-Wert:-ENV-VAR}' .

Bei Image mit Init-Systemen ist das vorgehen ähnlich, nur muss man sich dort mit der jeweiligen Konvention auseinandersetzen wo die eignetlichen Init-Skripte liegen. Bei Linuxserver-Images wird zum Beispiel "s6-overlay" verwendet, dessen Skripte in /etc/cont-init.d (ENV-Variablen in Konfigurationen übertragen) und /etc/services.d/ (Service Deklaration).

 

[Chris122]

Ich habe Watchtower seit Jahren auf drei Hosts laufen... ich hatte das Problem bisher nicht einmal.

Ich glaub es haben auch nur 3 User von > 1 Mio. Pulls gemeldet ... scheint nicht das größte Problem von dem Programm zu sein natürlich musste es gerad mich erwischen ...

Je nach Image werden für ENV-Variablen Default-Werte gesetzt und wären über 'docker inspect' einsehbar - das ist nicht immer der Fall.

Meist sind das Varianten in der die Variable mit einem Default-Wert überschrieben wird, wenn diese leer ist wird sie durch einen Default-Wert ersetzen = 'ENV-VAR=${Default-Wert:-ENV-VAR}' oder eine neue Variable eingeführt wird, die dann den Wert erhält: 'TEMP=${Default-Wert:-ENV-VAR}' .

Ich würde mal vermuten, dass es sehr darauf ankommt, um welchen Variablentyp es sich handelt. Integer bekommen aber doch immer als default automatisch 0, während bspw. Strings einfach leer bleiben, oder? Kommt vl. auch auch die Programmiersprache darauf an, anders hätte ich es aber nie gesehen. Dh. docker inspect müsste mir jedenfalls alle per manuell default gesetzten ENV und alle automatischen 0-default-ENV's (also alle als Zahl deklarierte Variablen) ausgeben, lediglich wirklich leere, auch manuell ohne default-Werte gesetzte Variablen dürften verborgen sein.

Bei guten Images sollte die Beschreibung auf Dockerhub auch gleichzeitig die Dokumentation sein oder darauf verwaisen...

Jep, sollte ... eine Doku und insb. eine gute Programmdoku mit Programmablaufplänen, Prozessbeschreibungen, etc., bekommt man idR aber nur von User, die das Programmieren auch beruflich betreiben, denn nur dort lernen sie - und werden gezwungen - vernünftige Programmdokus zu erstellen. Meine Programmierzeiten sind zwar schon viele Jahre vorbei, aber ich machte die Erfahrung, dass niemand eine Doku zu seinem Programm schreibt, wenn er nicht muss ... und müssen tut man halt nur im Job oder wenn das ganze derart komplexe Strukturen annimmt, dass sich der Programmierer selbst nicht mehr durchsieht.

In der Regel werden Images mit ordentlicher Beschreibung auch öfter gepflegt, als Images mit keiner oder schlechter Beschreibung.

Manchmal kommen einem Programm unter, die extrem gute Ideen versuchen zu verwirklichen, wobei es dann oft am nötigen Wissen zur Umsetzung scheitert oder das Projekt aus persönlichen Gründen des Erstellers nicht weiter verfolgt wird. Da schau ich mir die Sache dann trotzdem gerne genauer an ... vielleicht zieht man aus solchen Programmanalysen auch Erkenntnisse, die einem anderen Entwickler, der solche Projekte dann weiterpflegen will, nützlich sind.

Danke dir jedenfalls (wieder) für die Beschreibung - damit bin ich jetzt mal gut beschäftigt! Diskstations, Docker und Netzwerke sind für mich eine neue Welt, aber mit ein bisschen altem Grundverständnis wird das schon

 

[haydibe]

Ich würde mal vermuten, dass es sehr darauf ankommt, um welchen Variablentyp es sich handelt. Integer bekommen aber doch immer als default automatisch 0, während bspw. Strings einfach leer bleiben, oder? Kommt vl. auch auch die Programmiersprache darauf an, anders hätte ich es aber nie gesehen. Dh. docker inspect müsste mir jedenfalls alle per manuell default gesetzten ENV und alle automatischen 0-default-ENV's (also alle als Zahl deklarierte Variablen) ausgeben, lediglich wirklich leere, auch manuell ohne default-Werte gesetzte Variablen dürften verborgen sein.

ENV's werden im Container immer zu Strings. `Docker inspect` zeigt alle im Dockerfile definierten und von Dir bei der Erzeugung des Container (`docker create` bzw. `docker run`) angegebenen -e bzw. --env Variablen an. Variablen die im Container während des Betriebs erzeugt werden sind flüchtig und beim beenden des Containers weg.

Jep, sollte ... eine Doku und insb. eine gute Programmdoku mit Programmablaufplänen, Prozessbeschreibungen, etc., bekommt man idR aber nur von User, die das Programmieren auch beruflich betreiben, denn nur dort lernen sie - und werden gezwungen - vernünftige Programmdokus zu erstellen. Meine Programmierzeiten sind zwar schon viele Jahre vorbei, aber ich machte die Erfahrung, dass niemand eine Doku zu seinem Programm schreibt, wenn er nicht muss ... und müssen tut man halt nur im Job oder wenn das ganze derart komplexe Strukturen annimmt, dass sich der Programmierer selbst nicht mehr durchsieht.

Eine Image Beschreibung entspricht eher einer Endbenutzer-Doku abzgl. hübscher Screenshots

Ein Docker-Image kapselt die Installation von Abhängigkeiten, einer Hauptanwendung, der für den Betrieb der Hauptanwendung notwendigen Konfigurationen und Entrypoint-Skripten, die während des Container-Starts die ENV-Variablen in die Konfigurationen übernehmen. Installationen, Pfade für Dateien (=-v?) und Entrypoint-Skripte sind höchst individuel - ohne Beschreibung hat man kaum eine Chance das volle Potential eines Docker-Containers auszuschöpfen.

Wenn mich ein Image wirklich interessiert, dann hangel ich mich durch die Entrypoint-Skripte auf Github.

 

[Typ1er]

Ich habe jetzt genau den selben Fehler Watchtower läuft, kann aber kein einziges Paket mehr aktualisieren. Welche Ordner muss ich den endgültig löschen u den Fehler wegzubekommen? Aufgetreten ist der Fehler sicher erst weil Watchtower und Portainer als Root laufen.