Info Recovering from a bad image

[Telos]

I downloaded the lastest simply-shorten image today. After clearing and restarting the container I was greeted with "Docker API has failed". I repeated the registry download hoping to correct a corrupt download, but the same error message appeared. FWIW, I had previously backed up the container setting.

O Snap! What to do?

O wait... What about Portainer? I launched Portainer and there was the failed container along with my image history. Admittedly I'm clueless, but I decided to delete both copies of the faulty image. To remove the most current one (tagged:latest) required me to delete the container first. Fine. POOF! Gone.

Now I was staring at the image the last worked for me and seeing it was untagged, I selected it and clicked the Tag button, which appended the "latest" tag that image. I sensed I was getting closer.

I closed Portainer and located the "latest" image and launched it. But wait... I had already backed up the working container. So I closed the launched image which was waiting for me, hungering for ports and variables, and instead, I selected the container tab and imported the container settings from my backup. Seconds later the container appeared.

But would it launch?

With a nervous click, I started the container... No error window? WOOT!

Now to launch the container URL and see if it still worked. TOUCHDOWN.

Hopefully, this crazed write-up will help the novice who finds themself in such a predicament.

Key item: Portainer
2nd best item: Backed up container settings
... and a fearless demeanor

 

[one-eyed-king]

Congrats!

Though, there must be more to the magic. For the sake of understand, I'd like to look deeper into this

In your exported container config,json, can you check how the value for "image" looks like?

In my exports it looks like this:

...
  "image" : "plexinc/pms-docker:plexpass",
...

Though for it to have worked, it must have looked like this:

...
   "image" : "plexinc/pms-docker@sha256:ac69e2397d2d94ae5c70fc403d8c0d629503b012ab152d667e6257d57b1ec316",
...

Why is the 2nd version required? Because it uses the repo digest (=calculated sha256 checksum,) which is unique per image. It allows to address an image absolutly; regardless whether the image tag is immuntable or mutable and even if the image was untagged (this is what happens if you pull a newer image for a mutable tag).

if memory servs right, watchtower is the one beeing reponsible that containers are started using the repo digest.


My thesis: the solution only succeed, because the exports references the image using its repo digest.

 

[Telos]

can you check how the value for "image" looks like?

I'm unsure where you are getting that... My export (DockerUI) appears as "simply-shorten.syno.json" when I save it to one of my NAS folders... That file contains the container settings (ports/volumes/variables).

To add clarity to my OP, I was updating an existing container when the new image forced a rollback.

 

[one-eyed-king]

simply-shorten.syno.json <-- that's the file I want you to look at. Since the name differs for every containers export, i simply called it config.json.

Hint: If the file still is a flat string, you can open it with notepad++, visual studio code, sublime or whatever advanced editor that allow to reformat a json file.

 

[Telos]

So this section (copied from Notepad?

 "id" : "cc7914e32905d05858e429cc384573d85b72b94386de050feaabc0beff01b625",
   "image" : "draganczukp/simply-shorten:latest",
   "is_ddsm" : false,
   "is_package" : false,
   "links" : [],
   "memory_limit" : 0,
   "name" : "simply-shorten",

 

[one-eyed-king]

Yep this section. I would have expected to see the digest instead of {repo}:{tag}. With the repo digest, the whole operation would be trimmed down to "delete the current container, import the config".

Though, you worked arround the problem with this step:

Now I was staring at the image the last worked for me and seeing it was untagged, I selected it and clicked the Tag button, which appended the "latest" tag that image

in combination with deleting the current container, and importing the previsouly exported configuration, you got the solution.

Well done!