cli
cli copied to clipboard
docker
docker build exits successfully but no built image show up in the docker images
Description i have successfully run docker build command but image does not show up in the docker images command.
Steps to reproduce the issue: Using the Dockerfile:
FROM python:3
WORKDIR /usr/src/app
COPY . .
RUN pip install --no-cache-dir -r requirements.txt
EXPOSE 5000
CMD ["python", "./app.py"]
Describe the results you received: Successfully build builds image and exits successfully, but the image named "manjeet28/catnip:latest" does not show up in the docker images command.
docker build -t manjeet28/catnip .
Sending build context to Docker daemon 8.704kB
Step 1/6 : FROM python:3
3: Pulling from library/python
d6ff36c9ec48: Pull complete
c958d65b3090: Pull complete
edaf0a6b092f: Pull complete
80931cf68816: Pull complete
bc1b8aca3825: Pull complete
edfe96a4dd20: Pull complete
4e7c0e94bdeb: Pull complete
8dffdfc294e3: Pull complete
036c588c629e: Pull complete
Digest: sha256:2c1045587e4452d49544c6dce92efe21c3b4b33864cfb56fdee66a2c8585c769
Status: Downloaded newer image for python:3
---> 79cc46abd78d
Step 2/6 : WORKDIR /usr/src/app
---> Running in 273df206b7be
Removing intermediate container 273df206b7be
---> 7726cbc419bb
Step 3/6 : COPY . .
---> 6b71a105b7bd
Step 4/6 : RUN pip install --no-cache-dir -r requirements.txt
---> Running in b1c52400d86d
Collecting Flask==1.0
Downloading Flask-1.0-py2.py3-none-any.whl (97 kB)
Collecting itsdangerous>=0.24
Downloading itsdangerous-1.1.0-py2.py3-none-any.whl (16 kB)
Collecting Jinja2>=2.10
Downloading Jinja2-2.11.2-py2.py3-none-any.whl (125 kB)
Collecting Werkzeug>=0.14
Downloading Werkzeug-1.0.1-py2.py3-none-any.whl (298 kB)
Collecting click>=5.1
Downloading click-7.1.2-py2.py3-none-any.whl (82 kB)
Collecting MarkupSafe>=0.23
Downloading MarkupSafe-1.1.1-cp38-cp38-manylinux1_x86_64.whl (32 kB)
Installing collected packages: itsdangerous, MarkupSafe, Jinja2, Werkzeug, click, Flask
Successfully installed Flask-1.0 Jinja2-2.11.2 MarkupSafe-1.1.1 Werkzeug-1.0.1 click-7.1.2 itsdangerous-1.1.0
Removing intermediate container b1c52400d86d
---> b035e1019f17
Step 5/6 : EXPOSE 5000
---> Running in 11a623ec3d1f
Removing intermediate container 11a623ec3d1f
---> 771b073d5225
Step 6/6 : CMD ["python", "./app.py"]
---> Running in d3d8abcdaac1
Removing intermediate container d3d8abcdaac1
---> 58eff21b7c69
Successfully built 58eff21b7c69
Successfully tagged manjeet28/catnip:latest
Describe the results you expected: image should show up in the docker images command
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
Client:
Version: 19.03.6
API version: 1.40
Go version: go1.12.17
Git commit: 369ce74a3c
Built: Fri Feb 28 23:45:43 2020
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 19.03.6
API version: 1.40 (minimum version 1.12)
Go version: go1.12.17
Git commit: 369ce74a3c
Built: Wed Feb 19 01:06:16 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.3.3-0ubuntu1~18.04.2
GitCommit:
runc:
Version: spec: 1.0.1-dev
GitCommit:
docker-init:
Version: 0.18.0
GitCommit:
Output of docker info:
Client:
Debug Mode: false
Server:
Containers: 23
Running: 12
Paused: 0
Stopped: 11
Images: 9
Server Version: 19.03.6
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:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 5.3.0-28-generic
Operating System: Ubuntu 18.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.458GiB
Name: kubernetes-master
ID: W2WL:T6CQ:K4FW:6JSD:77JE:XZTX:SPS2:CDC7:AXC2:QXZO:W4TM:UMJ5
Docker Root Dir: /var/lib/docker
Debug Mode: false
Username: manjeet28
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
Additional environment details (AWS, VirtualBox, physical, etc.): os : ubuntu 18.04
i tried same, it works successfully. If you have too many images, you might be missing it. Try "docker run -it manjeet 28/catnip:latest" or "docker image inspect manjeet28/catnip:latest" command for understand that exist or not.
Hi there. @manjeetsorout can you run your docker build command and paste here the output from docker images?
docker build -t image_id .
docker images > output.txt
From the output of your docker version and docker info, I think you have the distro-package of Docker installed. Those versions are not maintained by us and there are some differences in how those packages are built. Unfortunately, I've seen various cases where those packages were broken (sometimes due to incompatible versions of build-dependencies being used in their builds)
Are you able to reproduce the problem on the official docker packages as well? https://docs.docker.com/engine/install/ubuntu/
Do you have more details about your docker install, perhaps logs/output of the build, and steps to reproduce?
I met the issue with the following system info:
cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.7 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.7"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.7 (Maipo)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.7:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.7
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.7"
# docker version
Client: Docker Engine - Community
Version: 19.03.12
API version: 1.40
Go version: go1.13.10
Git commit: 48a66213fe
Built: Mon Jun 22 15:46:54 2020
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.12
API version: 1.40 (minimum version 1.12)
Go version: go1.13.10
Git commit: 48a66213fe
Built: Mon Jun 22 15:45:28 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version: 0.18.0
GitCommit: fec3683
Does the image show up if you run docker image inspect <name of your image> ?
Does the image show up if you run
docker image inspect <name of your image>?
Nope.
I am also running into this issue with the following config:
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
scan: Docker Scan (Docker Inc., v0.5.0)
Server:
Containers: 29
Running: 29
Paused: 0
Stopped: 0
Images: 8
Server Version: 20.10.5
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
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 io.containerd.runc.v2 io.containerd.runtime.v1.linux
Default Runtime: runc
Init Binary: docker-init
containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
init version: de40ad0
Security Options:
seccomp
Profile: default
Kernel Version: 4.19.121-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 5.81GiB
Name: docker-desktop
ID: XRTK:27XD:ESSD:WCVL:EMCE:HYVJ:5QM6:HDAB:SDZI:YLNL:OLD2:4IWT
Docker Root Dir: /var/lib/docker
Debug Mode: true
File Descriptors: 118
Goroutines: 107
System Time: 2021-04-22T21:28:24.479144159Z
EventsListeners: 4
HTTP Proxy: gateway.docker.internal:3128
HTTPS Proxy: gateway.docker.internal:3129
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
and docker version is:
Client: Docker Engine - Community
Cloud integration: 1.0.9
Version: 20.10.5
API version: 1.41
Go version: go1.13.15
Git commit: 55c4c88
Built: Tue Mar 2 20:13:00 2021
OS/Arch: darwin/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.5
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: 363e9a8
Built: Tue Mar 2 20:15:47 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.3
GitCommit: 269548fa27e0089a8b8278fc4fc781d7f65a939b
runc:
Version: 1.0.0-rc92
GitCommit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
docker-init:
Version: 0.19.0
GitCommit: de40ad0
I'm having the same issue.
These won't work, the all look like they build from cache but don't register the new image with docker.
docker build .
docker buildx build --platform linux/amd64 --load .
docker buildx build --platform linux/amd64 --progress=plain --load .
How ever, the only command I can get to build is:
docker buildx build --progress=plain --load .
My issue is I need to specify --platform linux/amd64 as I'm on the apple m1 chipset. So am blocked here.
Client:
Cloud integration: 1.0.17
Version: 20.10.7
API version: 1.41
Go version: go1.16.4
Git commit: f0df350
Built: Wed Jun 2 11:56:23 2021
OS/Arch: darwin/arm64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.7
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: b0f5bc3
Built: Wed Jun 2 11:55:36 2021
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.4.6
GitCommit: d71fcd7d8303cbf684402823e425e9dd2e99285d
runc:
Version: 1.0.0-rc95
GitCommit: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
docker-init:
Version: 0.19.0
GitCommit: de40ad0
@daithi-coombes in your example, I see you're not setting -t / --tag, which means no image will be tagged; can you see a new image appear if you docker build / docker buildx build with a --tag set?
Currently running into this issue in the latest docker for mac:
DOCKER_BUILDKIT=1 docker build -f Dockerfile --no-cache -t axis-relay:0.0.1 ..
[+] Building 18.9s (11/11) FINISHED
=> [internal] load build definition from Dockerfile 0.4s
=> => transferring dockerfile: 37B 0.3s
=> [internal] load .dockerignore 0.4s
=> => transferring context: 2B 0.3s
=> [internal] load metadata for docker.io/library/golang:1.16 0.0s
=> [builder 1/5] FROM docker.io/library/golang:1.16 0.0s
=> [internal] load build context 0.3s
=> => transferring context: 6.11kB 0.3s
=> CACHED [builder 2/5] WORKDIR /build 0.0s
=> [builder 3/5] COPY . . 0.1s
=> [builder 4/5] RUN go mod download 13.6s
=> [builder 5/5] RUN GOOS=linux CGO_ENABLED=0 go build -o relay ./relay 4.3s
=> [stage-1 1/2] COPY --from=builder /build/relay . 0.1s
=> exporting to image 0.1s
=> => exporting layers 0.1s
=> => writing image sha256:6b43580b1dc4738c81831a75bae5b5451b5fbbcc5e985f254353e1ed62528cbd 0.0s
=> => naming to docker.io/library/axis-relay:0.0.1 0.0s
Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
➜ relay git:(master) ✗ docker image ls -a
REPOSITORY TAG IMAGE ID CREATED SIZE
➜ relay git:(master) ✗ docker image inspect axis-relay:0.0.1
[]
Error: No such image: axis-relay:0.0.1
Docker Version:
Client:
Cloud integration: 1.0.17
Version: 20.10.7
API version: 1.41
Go version: go1.16.4
Git commit: f0df350
Built: Wed Jun 2 11:56:22 2021
OS/Arch: darwin/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.7
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: b0f5bc3
Built: Wed Jun 2 11:54:58 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.6
GitCommit: d71fcd7d8303cbf684402823e425e9dd2e99285d
runc:
Version: 1.0.0-rc95
GitCommit: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
docker-init:
Version: 0.19.0
GitCommit: de40ad0
@thaJeztah my bad I hadn't put the -t flag in my comment. Issue was happening with the -t flag.
@khumps I had to downgrade to docker desktop 3.4.0 and this (plus other) issues went away
What worked for me was to delete the previously-created version image. (With the same name/tag)
Currently running into this issue in the latest docker for mac:
DOCKER_BUILDKIT=1 docker build -f Dockerfile --no-cache -t axis-relay:0.0.1 .. [+] Building 18.9s (11/11) FINISHED => [internal] load build definition from Dockerfile 0.4s => => transferring dockerfile: 37B 0.3s => [internal] load .dockerignore 0.4s => => transferring context: 2B 0.3s => [internal] load metadata for docker.io/library/golang:1.16 0.0s => [builder 1/5] FROM docker.io/library/golang:1.16 0.0s => [internal] load build context 0.3s => => transferring context: 6.11kB 0.3s => CACHED [builder 2/5] WORKDIR /build 0.0s => [builder 3/5] COPY . . 0.1s => [builder 4/5] RUN go mod download 13.6s => [builder 5/5] RUN GOOS=linux CGO_ENABLED=0 go build -o relay ./relay 4.3s => [stage-1 1/2] COPY --from=builder /build/relay . 0.1s => exporting to image 0.1s => => exporting layers 0.1s => => writing image sha256:6b43580b1dc4738c81831a75bae5b5451b5fbbcc5e985f254353e1ed62528cbd 0.0s => => naming to docker.io/library/axis-relay:0.0.1 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them ➜ relay git:(master) ✗ docker image ls -a REPOSITORY TAG IMAGE ID CREATED SIZE ➜ relay git:(master) ✗ docker image inspect axis-relay:0.0.1 [] Error: No such image: axis-relay:0.0.1Docker Version:
Client: Cloud integration: 1.0.17 Version: 20.10.7 API version: 1.41 Go version: go1.16.4 Git commit: f0df350 Built: Wed Jun 2 11:56:22 2021 OS/Arch: darwin/amd64 Context: default Experimental: true Server: Docker Engine - Community Engine: Version: 20.10.7 API version: 1.41 (minimum version 1.12) Go version: go1.13.15 Git commit: b0f5bc3 Built: Wed Jun 2 11:54:58 2021 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.4.6 GitCommit: d71fcd7d8303cbf684402823e425e9dd2e99285d runc: Version: 1.0.0-rc95 GitCommit: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7 docker-init: Version: 0.19.0 GitCommit: de40ad0
I am getting this same issue on MacOS M1 with Docker 20.10.7
(env) ➜ docker build . -f Dockerfile --tag my-image:0.0.1
[+] Building 533.5s (12/12) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 556B 0.0s
=> [internal] load .dockerignore 0.0s
[...]
=> exporting to image 3.8s
=> => exporting layers 3.8s
=> => writing image sha256:a0d1196b2332f31dab7c34ba48e1566f8fb0d9e103f49a6c94f5beca1f9a3230 0.0s
=> => naming to docker.io/library/my-image:0.0.1 0.0s
Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
(env) ➜ docker image inspect my-image:0.0.1
[]
Error: No such image: my-image:0.0.1
@thaJeztah my bad I hadn't put the
-tflag in my comment. Issue was happening with the-tflag. @khumps I had to downgrade to docker desktop3.4.0and this (plus other) issues went away
How did you go about downgrading?
@khumps uninstall and re-install. For apple macs (silicon) I grabbed 3.4.0 from here: https://docs.docker.com/docker-for-mac/release-notes/#docker-desktop-340
@crazy-max PTAL - could this be if a custom (container) builder is set, and build is run without --load ?
It might be that you have done a docker buildx install in the past so docker build will be docker buildx build and you have created a docker-container builder that will not load the image by default in docker store. If you could provide the output of the following commands, that would help to see what's wrong:
$ docker buildx ls
$ cat ~/.docker/config.json | jq '.aliases'
@crazy-max
I think we're getting a related issue: docker compose up -d --build some.service has been working fine. Since upgrading to docker desktop 4.6.1 the build is working but the image is not being recreated.
Causing quite the headache for our dev team.
Any thoughts based on the above?
docker compose up -d --build some.servicehas been working fine. Since upgrading to docker desktop 4.6.1 the build is working but the image is not being recreated.
@totalitydevelopment I recently ran into an issue where docker compose up --build built the image (docker image ls showed a new image that was built), but when checking the container that was started, it was still running the old version of the image (docker ps showed the image ID of the old build); if that's what you're running into, you can use the --force-recreate option to make sure compose creates a new container that uses the latest build of the image.
Thanks @thaJeztah
One of the team has had that working so that's definately an option.
Would be good to understand/not need to, presumably the previous behaviour would have been the correct one?
Yes, I don't think it should be needed to pass that flag (at least not when --build was used). I saw this behavior on compose v2.3.3, and it worked as expected on v2.2.3 (IIRC), but haven't checked yet if it's fixed in compose v2.4.x
I checked with someone who's working on compose, and there was indeed an issue around this; see https://github.com/docker/compose/pull/9261 - that fix is in the compose v2.3.4 and above, and will be included in the next release of Docker Desktop (to be released soon)