Docker pull not getting image tagnames - docker

I'm running docker with boot2docker on OS X 10.10.
I'm following the main tutorial and doing a docker pull ubuntu
It gets the image okay, however when I then do docker images it only lists ubuntu:latest
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu latest 5506de2b643b 3 weeks ago 199.3 MB
instead of the full list of images as the tutorial says:
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
training/webapp latest fc77f57ad303 3 weeks ago 280.5 MB
ubuntu 13.10 5e019ab7bf6d 4 weeks ago 180 MB
ubuntu saucy 5e019ab7bf6d 4 weeks ago 180 MB
ubuntu 12.04 74fe38d11401 4 weeks ago 209.6 MB
ubuntu precise 74fe38d11401 4 weeks ago 209.6 MB
ubuntu 12.10 a7cf8ae4e998 4 weeks ago 171.3 MB
ubuntu quantal a7cf8ae4e998 4 weeks ago 171.3 MB
ubuntu 14.04 99ec81b80c55 4 weeks ago 266 MB
ubuntu latest 99ec81b80c55 4 weeks ago 266 MB
ubuntu trusty 99ec81b80c55 4 weeks ago 266 MB
ubuntu 13.04 316b678ddf48 4 weeks ago 169.4 MB
ubuntu raring 316b678ddf48 4 weeks ago 169.4 MB
ubuntu 10.04 3db9c44f4520 4 weeks ago 183 MB
ubuntu lucid 3db9c44f4520 4 weeks ago 183 MB
If I do docker images -a I see this:
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu latest 5506de2b643b 3 weeks ago 199.3 MB
<none> <none> 22093c35d77b 3 weeks ago 199.3 MB
<none> <none> 3680052c0f5c 3 weeks ago 192.7 MB
<none> <none> e791be0477f2 3 weeks ago 192.7 MB
<none> <none> ccb62158e970 3 weeks ago 192.7 MB
<none> <none> d497ad3926c8 3 weeks ago 192.5 MB
<none> <none> 511136ea3c5a 17 months ago 0 B
Anybody knows why this is happening?

When you do a docker pull <image> you will only get the latest tag for that image. This is expected behaviour.
To pull a specific tag, use docker pull <image>:<tag>.
The list there in the documentation should only be expected if you've followed the full guide and used all those images. You usually only need one tag for an image.

Related

Docker no space left on device on Mac M1

I want to run container and receive error:
docker run -ti --rm grafana/promtail:2.5.0 -config.file=/etc/promtail/config.yml
docker: Error response from daemon: mkdir /var/lib/docker/overlay2/0cad6a6645e2445a9985d5c9e9c6909fa74ee1a30425b407ddfac13684bd9d31-init: no space left on device.
At first, I thought I have a lot of volumes and images cached. So I clean docker with:
docker prune
docker builder prune
But in a while, the same error occur. When I check my Docker Desktop configuration, I can see I am using all available disk size for images:
Disk image size:
59.6 GB (59.5 GB used)
I have 13 images on my system and together its less than 5GB:
REPOSITORY TAG IMAGE ID CREATED SIZE
logstashloki latest 157966144f3b 3 days ago 761MB
minio/minio <none> 717586e37f7f 4 days ago 232MB
grafana/grafana <none> 31a8875955e5 9 days ago 277MB
docker.elastic.co/beats/filebeat 8.3.2 e7b210caf528 3 weeks ago 295MB
k8s.gcr.io/kube-apiserver v1.24.0 b62a103951f4 2 months ago 126MB
k8s.gcr.io/kube-scheduler v1.24.0 b81513b3bfb4 2 months ago 50MB
k8s.gcr.io/kube-controller-manager v1.24.0 59fad34d4fe0 2 months ago 116MB
k8s.gcr.io/kube-proxy v1.24.0 66e1443684b0 2 months ago 106MB
k8s.gcr.io/etcd 3.5.3-0 a9a710bb96df 3 months ago 178MB
grafana/promtail 2.5.0 aa21fd577ae2 3 months ago 177MB
grafana/loki 2.5.0 369cbd28ef9b 3 months ago 60MB
k8s.gcr.io/pause 3.7 e5a475a03805 4 months ago 514kB
k8s.gcr.io/coredns/coredns v1.8.6 edaa71f2aee8 9 months ago 46.8MB
From output of docker system df there is no suspicious size of container, images or volumes:
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 13 13 2.35GB 69.57MB (2%)
Containers 21 21 35.15kB 0B (0%)
Local Volumes 2 0 2.186MB 2.186MB (100%)
Build Cache 20 0 0B 0B
I am new to MacOS and cannot determine what take all my space and how to clean all that space and where are all that data stored on system?

What does "in use" mean for an image?

What does "in use" mean and how can I get that info from the CLI?
Reference: docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.State}}\t{{.Image}}"
CONTAINER ID
NAMES
STATE
IMAGE
07bce6924796
laughing_wozniak
exited
vsc-volume-bootstrap
6d37d8744a77
angry_brahmagupta
exited
vsc-quickstarts-d91f349952ba5208420f1403c31b2955-uid
0bce117a827c
dapr_placement
running
daprio/dapr:1.5.0
1232bf715593
dapr_zipkin
running
openzipkin/zipkin
c128e546a0b6
dapr_redis
running
redis
dc44e1006831
miked
exited
my-first-fsharp-web
ce3cf77a0eb9
minikube
running
gcr.io/k8s-minikube/kicbase:v0.0.28
Reference: docker image ls
REPOSITORY
TAG
IMAGE ID
CREATED
SIZE
vsc-microsoftvscodeinsiders-572e00dcd0f79c5ee8d7d39c18e7c701-features
latest
9f05ea6535d4
12 hours ago
6.36GB
vsc-volume-bootstrap
latest
81646861762b
12 hours ago
180MB
vsc-quickstarts-d91f349952ba5208420f1403c31b2955-uid
latest
453bd2943e10
40 hours ago
9.7GB
vsc-quickstarts-d91f349952ba5208420f1403c31b2955
latest
10de525681a7
40 hours ago
9.7GB
openzipkin/zipkin
latest
6a9714eacfd9
2 days ago
153MB
miked.azurecr.io/my-first-fsharp-web
96e7948ee30c
5 days ago
211MB
my-first-fsharp-web
latest
e36fabe64a1c
5 days ago
211MB
miked.azurecr.io/my-first-fsharp-web
1
e36fabe64a1c
5 days ago
211MB
miked.azurecr.io/my-first-fsharp-web
latest
e36fabe64a1c
5 days ago
211MB
counter-image
latest
22dfe0305c55
7 days ago
208MB
redis
latest
40c68ed3a4d2
8 days ago
113MB
daprio/dapr
1.5.0
bff1855a0302
2 weeks ago
214MB
vsc-azure-container-apps-demo-41dcd784881293406771e08c255554b9
latest
1af591496e8a
4 weeks ago
337MB
gcr.io/k8s-minikube/kicbase
v0.0.28
e2a6c047bedd
8 weeks ago
1.08GB
It indicates if the image is used by a container (running or already stopped).
You cannot get this via the CLI using docker images, but listing the containers docker ps -a you can see the associated image.

Docker disk memory : can I remove intermediate images?

I'm running out of disk memory.
If I run docker images, I get a lot of results:
app_mongodb latest 355f8f37c385 17 hours ago 568.1 MB
app_web latest a31db2244a8b 18 hours ago 868.2 MB
<none> <none> 71e586165d46 18 hours ago 568.1 MB
<none> <none> 422c281541d3 18 hours ago 568.1 MB
<none> <none> 1b16da634fa1 18 hours ago 535.4 MB
website_web latest e4442589e2f4 2 days ago 793.6 MB
<none> <none> 5445f9b915e6 3 days ago 535.4 MB
<none> <none> e825b94d5938 3 days ago 868 MB
<none> <none> ea1ddc53d17f 3 days ago 535.4 MB
<none> <none> 90531b8bd2d3 5 days ago 855.6 MB
<none> <none> 774895648397 5 days ago 535.4 MB
<none> <none> 0f474dc179c4 5 days ago 855.6 MB
<none> <none> 37cd4d180580 5 days ago 535.4 MB
<none> <none> 5f701c2e3fac 5 days ago 535.4 MB
<none> <none> 6837158ac191 5 days ago 535.4 MB
<none> <none> f3eecd70620e 5 days ago 535.4 MB
<none> <none> 27b3e1701f05 5 days ago 535.4 MB
<none> <none> 64763f09b1d4 5 days ago 535.4 MB
<none> <none> b58542e468e6 5 days ago 855.6 MB
app2_web latest 01c45018b686 5 days ago 645.5 MB
redis latest e4a35914679d 11 days ago 182.9 MB
<none> <none> 8d6737f884f8 12 days ago 854.7 MB
<none> <none> 27f7742e8b2b 2 weeks ago 792.1 MB
api_web latest 59ec56265675 2 weeks ago 906.4 MB
<none> <none> 33c328f5a271 2 weeks ago 782.2 MB
<none> <none> 53d4ad25e6c2 2 weeks ago 782.1 MB
<none> <none> 01ac14f597ba 2 weeks ago 854 MB
app3_web latest 2aaa4675cc58 3 weeks ago 929.9 MB
<none> <none> bde15910281e 3 weeks ago 789.5 MB
postgres latest ecd991538a0f 4 weeks ago 265.5 MB
app4_web latest c8b0de070d78 7 weeks ago 1.088 GB
<none> <none> 67e3ef67081b 7 weeks ago 859.2 MB
<none> <none> 451229f8dedb 7 weeks ago 859.2 MB
server_web latest 72bd5165f262 9 weeks ago 665.4 MB
<none> <none> c7f0d2b67986 9 weeks ago 660.9 MB
app5_web latest 7477b8e5ef63 3 months ago 690 MB
<none> <none> ee7de82e0cf0 3 months ago 856.7 MB
mdillon/postgis latest ee2a84576d15 3 months ago 600.2 MB
<none> <none> d8ee634a8581 4 months ago 685.3 MB
memcached latest 5fdd5c36cc9a 4 months ago 126.1 MB
app6_web latest 813fb5eac7d1 5 months ago 823.7 MB
app7_web latest 3b6a87b67359 5 months ago 645.5 MB
node argon 3b6a87b67359 5 months ago 645.5 MB
mongo latest 48b8b08dca4d 6 months ago 366.4 MB
ruby 2.2.1 aca1c061bdd2 23 months ago 775.1 MB
I know what all the named dockers correspond to, I can easily manage them and remove those I don't need anymore. But they are not majority!
Regarding the other ones, I guess they are intermediate dockers.
I wonder if I remove those, will the named one be broken or it's simply that if I rebuild them (eg. with the --no-cache option), docker will have to re-download them? (which is fine)
Eg. Does a docker based on the ruby one needs it to start or only to build?
These are probably images you built in the past, but then when you rebuilt the image, the relevant tag moved to another image, leaving these images untagged. Thus they show up as <none> <none>.
Looking at a sampling of your output, I'd guess a lot of them are old builds of app_mongodb:latest and app_web:latest. Based on the sizes.
app_mongodb latest 355f8f37c385 17 hours ago 568.1 MB
app_web latest a31db2244a8b 18 hours ago 868.2 MB
<none> <none> 71e586165d46 18 hours ago 568.1 MB
<none> <none> 422c281541d3 18 hours ago 568.1 MB
<none> <none> 1b16da634fa1 18 hours ago 535.4 MB
website_web latest e4442589e2f4 2 days ago 793.6 MB
<none> <none> 5445f9b915e6 3 days ago 535.4 MB
<none> <none> e825b94d5938 3 days ago 868 MB
<none> <none> ea1ddc53d17f 3 days ago 535.4 MB
<none> <none> 90531b8bd2d3 5 days ago 855.6 MB
<none> <none> 774895648397 5 days ago 535.4 MB
<none> <none> 0f474dc179c4 5 days ago 855.6 MB
<none> <none> 37cd4d180580 5 days ago 535.4 MB
<none> <none> 5f701c2e3fac 5 days ago 535.4 MB
<none> <none> 6837158ac191 5 days ago 535.4 MB
<none> <none> f3eecd70620e 5 days ago 535.4 MB
<none> <none> 27b3e1701f05 5 days ago 535.4 MB
<none> <none> 64763f09b1d4 5 days ago 535.4 MB
<none> <none> b58542e468e6 5 days ago 855.6 MB
It is most likely safe to delete them. If you try to delete them and they are being used by a container or another image, then Docker will complain about that.
In recent versions of Docker (I believe >= 1.13) you can use the prune command to clean up images not referenced by an image or container.
docker image prune
in the newer docker versions, you can simply do:
docker image prune
refer to: https://docs.docker.com/engine/reference/commandline/image_prune/#description
Using docker images -f dangling=true -q we can find <none><none> images. Then we can delete them using below command,
docker rmi -f $(docker images -f dangling=true -q --no-trunc)
We may need -f option to delete them forcefully.

Docker run -d <private image> gives fatal. On other hosts it's ok?

Let the commands speak for themselves:
on a host called: coreworker
core#coreworker-1 ~ $ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
hub-docker-repo:5000/485d5874-c786-4b90-93ac-8db5342a6059 1 bbd5d4d98156 31 minutes ago 139.3 MB
ec2-54-169-239-164.ap-southeast-1.compute.amazonaws.com:5000/hub-action-repository latest 66ecb895d185 14 hours ago 856.4 MB
ec2-54-169-239-164.ap-southeast-1.compute.amazonaws.com:5000/hub-ext-node-base 0.12.7 f2f1afc202e4 8 days ago 136.6 MB
...
core#coreworker-1 ~ $
on a host called devhost
core#devhost ~ $ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
<none> <none> 67e45ce93dee 48 minutes ago 725 MB
node 0.12.7 a4b45afffe4a 5 days ago 642.2 MB
jwnintex/mesos-worker latest 42f1b41b0089 5 weeks ago 504 MB
jwnintex/nginx-port-router latest 11edcdf1a5fc 9 weeks ago 126.4 MB
jwnintex/consul latest e66fb6787628 10 weeks ago 69.4 MB
jwnintex/mesos-master latest 187d84106a3e 3 months ago 561.8 MB
jwnintex/marathon latest b1d8dd91146a 3 months ago 699.3 MB
jwnintex/zookeeper latest 9b72d56707c9 4 months ago 304.3 MB
jwnintex/registrator latest b1c29d1a74a9 6 months ago 11.79 MB
but when I do:
core#devhost ~ $ docker images -a hub-docker-repo:5000
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
now run the image on devhost residing in hub-docker-repo
veryify it's up:
core#devhost ~ $ ping hub-docker-repo
PING hub-docker-repo.service.consul (172.17.8.150) 56(84) bytes of data.
64 bytes from coreworker-1.node.dc1.consul (172.17.8.150): icmp_seq=1 ttl=63 time=8.27 ms
64 bytes from coreworker-1.node.dc1.consul (172.17.8.150): icmp_seq=2 ttl=63 time=5.19 ms
now try it
core#devhost ~ $ docker run -d hub-docker-repo:5000/485d5874-c786-4b90-93ac-8db5342a6059:1
Unable to find image 'hub-docker-repo:5000/485d5874-c786-4b90-93ac-8db5342a6059:1' locally
Pulling repository hub-docker-repo:5000/485d5874-c786-4b90-93ac-8db5342a6059
FATA[0000] Error: image 485d5874-c786-4b90-93ac-8db5342a6059:1 not found
Now try it on coreworker which is actually hosting the registry (as a docker image)
core#coreworker-1 ~ $ docker run -d hub-docker-repo:5000/485d5874-c786-4b90-93ac-8db5342a6059:1
98d642c1bafd30569d853e92167c7b4fe720bd67f65ec0d0719ec5a36bb6616f
Why am I not able to run that remote image? Or better, even discover it?
It turns out the image had never been pushed and so couldn't be seen by the other host.

Why the images information provided by docker info is different from docker images

Hi I'm trying to extract the number of docker images I have in my machine
If I run the command docker info it gives me this:
Containers: 15
Images: 27
Driver: aufs
Root Dir: /var/lib/docker/aufs
Dirs: 57
Username: miggom
Registry: [https://index.docker.io/v1/]
WARNING: No swap limit support
If I run the command docker images -a it gives me this:
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
<none> <none> 2b1cf54887a8 20 minutes ago 139.5 MB
<none> <none> 14e148a673c8 3 hours ago 204.4 MB
<none> <none> bf3d7d4f575d 13 days ago 273.9 MB
<none> <none> c3553dd60b1e 13 days ago 273.9 MB
mgs/my-site latest 268ffd69fb60 13 days ago 273.9 MB
miggom/mySite latest 268ffd69fb60 13 days ago 273.9 MB
my-site latest 268ffd69fb60 13 days ago 273.9 MB
mgsMySite latest 268ffd69fb60 13 days ago 273.9 MB
mgs_mySite latest 268ffd69fb60 13 days ago 273.9 MB
<none> <none> b055dfd3f223 13 days ago 273.9 MB
apache2 latest 826c4bc6368a 2 weeks ago 273.9 MB
<none> <none> 7aa770719eb1 2 weeks ago 273.9 MB
<none> <none> 1850570b7316 2 weeks ago 273.9 MB
<none> <none> 44943615dd35 2 weeks ago 273.9 MB
<none> <none> 994c3e50a608 2 weeks ago 273.9 MB
<none> <none> a97583e98230 2 weeks ago 273.9 MB
<none> <none> 635d880c0c38 2 weeks ago 273.9 MB
<none> <none> b8735e7272ef 2 weeks ago 224.3 MB
baselDaemon latest 4e892058b0b2 2 weeks ago 204.4 MB
ubuntu saucy 9f676bd305a4 4 weeks ago 178 MB
ubuntu 13.10 9f676bd305a4 4 weeks ago 178 MB
<none> <none> 1c7f181e78b9 4 weeks ago 0 B
ubuntu 13.04 eb601b8965b8 4 weeks ago 166.5 MB
ubuntu raring eb601b8965b8 4 weeks ago 166.5 MB
<none> <none> f323cf34fd77 4 weeks ago 0 B
ubuntu 12.10 5ac751e8d623 4 weeks ago 161 MB
ubuntu quantal 5ac751e8d623 4 weeks ago 161 MB
<none> <none> 321f7f4200f4 4 weeks ago 0 B
ubuntu 10.04 9cc9ea5ea540 4 weeks ago 180.8 MB
ubuntu lucid 9cc9ea5ea540 4 weeks ago 180.8 MB
ubuntu precise 9cd978db300e 4 weeks ago 204.4 MB
ubuntu 12.04 9cd978db300e 4 weeks ago 204.4 MB
ubuntu latest 9cd978db300e 4 weeks ago 204.4 MB
<none> <none> 6170bb7b0ad1 4 weeks ago 0 B
<none> <none> 7a4f87241845 5 weeks ago 0 B
<none> <none> 511136ea3c5a 8 months ago 0 B
learn/tutorial latest 8dbd9e392a96 10 months ago 128 MB
So, the problem is that the number of the images shown in docker info doesn't match with the number of images shown in docker images. I don't know how to get the correct number of images beacuse if you also execute the docker images without flags, it doesn't match with the number of images shown in docker info
I don't know which type of information I can get from docker info because in docker.io there is just an example of the documentation.
Thank you in advance
The point here is not whether an image is flagged or not. Take note of the Image ID when you count the images. Several (differently tagged) images with the same ID count as one image, because well... they are the same image :)
If I manually count the different IDs, I find 27.
A lot of those images are intermediary images and are used for caching when you want to rebuild your Dockerfile.
By default when you run docker images it hides these intermediate images, but if you pass the -a argument it'll show them all

Resources