Docker won't update image

Help docker
1

I'm running pi-hole in docker and using tag pihole/pihole:v5.0.

When I see the sha256:788fa841f00633e23f5c40775dad6844262b6546d021441626639984cd5f710a it does not match the current sha256:27d9514c4c580f1d1a3ab33586b90652554e71d7be682c5c948ef346359c6479

from the dockerhub site. Mine is over 20 days old and I've been trying to update it to ones that are tagged as being newer. Or at least match / have some commonality to ones in dockerhub.

I have deleted my container rmi the image to ensure I don't have an image and then when I do a docker pull pihile/pihole:v5.0 I get the same over version not listed in dockerhub.

I'm sure I'm doing something wrong. My goal is to be able to use docker to automate the image pull but I really like to verify that I have the version that I should have.

Thanks for the help.

2

Did you try pihole/pihole:latest yet?

3

I will give that a try right now.

It just pulled: sha256:788fa841f00633e23f5c40775dad6844262b6546d021441626639984cd5f710a

docker images
pihole/pihole latest 788fa841f006 19 days ago 295MB

4

What is the output from docker info? Specifically the Architecture.

5

Here is my output from docker info. This is a Debian VM running on top of Proxmox, the host has an Intel Xeon (amd64) arch.

docker@docker:~$ docker info
Client:
 Debug Mode: false

Server:
 Containers: 5
  Running: 5
  Paused: 0
  Stopped: 0
 Images: 5
 Server Version: 19.03.9
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 4.19.0-8-amd64
 Operating System: Debian GNU/Linux 10 (buster)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 23.54GiB
 Name: docker
 ID: CB7Z:WMLG:T47K:B5JW:FPWX:JDRW:5LHC:AISL:FDE6:ADA2:R63C:KFW2
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support
6

Okay, and your question was that you see the wrong hash for pihole/pihole:v5.0? What does the local image store show for the pulled versions? docker image ls | grep pihole

7

Here is what it show.

pihole/pihole         latest              788fa841f006        2 weeks ago         295MB

but when I do a docker image inspect pihole/pihole, this is the ID that I get which doesn't seem to match what's on docker hub.

"Id": "sha256:788fa841f00633e23f5c40775dad6844262b6546d021441626639984cd5f710a",
8

sha256:788fa841f00633e23f5c40775dad6844262b6546d021441626639984cd5f710a is version 5.0, a.k.a latest.

9

To confirm run docker run --rm --entrypoint 'pihole-FTL' pihole/pihole --version

10

What about this from docker hub:
pihole/pihole:latest
DIGEST:sha256:27d9514c4c580f1d1a3ab33586b90652554e71d7be682c5c948ef346359c6479
and
pihole/pihole:v5.0
DIGEST:sha256:27d9514c4c580f1d1a3ab33586b90652554e71d7be682c5c948ef346359c6479

docker run --rm --entrypoint 'pihole-FTL' pihole/pihole --version
v5.0

11

Digest and ID are not the same thing.

12

Well that would explain why I couldn't find mine on Docker Hub. Is there a way I can visually use Docker Hub to verify that it's pulling the right Digest / ID?

13

docker images --digests | grep pihole

14

Thanks, I can't find the one that comes up in Docker Hub.

docker@docker:~$ docker images --digests | grep pihole
pihole/pihole         latest              sha256:d586f1a05c2a81b224d2c30d33ab9081b8baa0471f87d900d55e6155ed89cb08   788fa841f006        2 weeks ago         295MB
15

Chances are you probably won't. It has to do with Docker and manifests and a few other variables. Without a deep dive the best you will have is to trust the tags.

Generally it's a bad idea to use latest as that will move to a different image without your involvement. Pin to a versioned release, so use pihole/pihole:v5.0 instead. That will always be version 5.0.

16

I can tell you that you are on the version 5.0 image however.

docker images --digests | grep pihole
pihole/pihole                                                   latest              sha256:d586f1a05c2a81b224d2c30d33ab9081b8baa0471f87d900d55e6155ed89cb08   788fa841f006        2 weeks ago         295MB
pihole/pihole                                                   v5.0                sha256:d586f1a05c2a81b224d2c30d33ab9081b8baa0471f87d900d55e6155ed89cb08   788fa841f006        2 weeks ago         295MB
pihole/pihole                                                   v4.4                sha256:8c172c4cf344232a137202811b0c13a0542551076798d7635ef5368f40d1fe71   694e8aa9d588        2 months ago        289MB
17

Ok, thank you for your help troubleshooting. I mentally struggle with trusting something that I can't verify myself.

For now, I'll make sure to go in and pin it to v5.0.

Until I'm more comfortable with Dockers in general, I'll probably go back to a Pi-hole VM where I have some scripts to automate the base os updates and can run pihole -up manually.

Thanks again for the troubleshooting and amazing project!

18

If it's the pihole/pihole image then you can be pretty confident that it's our image. It would be pretty difficult for someone to put an image up in our place. (And we'd know it really quickly, we'd tell you about it as well.)

As for the :latest tag, this is a good post on the topic: What's Wrong With The Docker :latest Tag? ยท vsupalov.com