I've used docker-compose push for years now with no issues, till today. I'm confused by this one. Basically it looks like it's only pushing the local changes in my Dockerfile, but not the entire image based on my Dockerfile and the original source image.
$ docker-compose build
...
...
Successfully tagged registry.gitlab.com/<path_obfuscated>:21.10.02
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
...
registry.gitlab.com/<obfuscated-path---------------------------> 21.10.02 3c8d770f0649 23 minutes ago 1.2GB
...
So you can see the image is 1.2 GB.
Now I run: docker-compose push
It happens superfast, and when I look at the image on my registry, it's only 388 MB, instead of the expected 1.2 GB.
Does someone know why this is happening? I've been using the same method for years now, and this is the first that I ran into this issue.
Some extra bits:
$ docker version
Client:
Version: 20.10.8
API version: 1.41
Go version: go1.16.6
Git commit: 3967b7d28e
Built: Wed Aug 4 21:24:10 2021
OS/Arch: linux/amd64
Context: default
Experimental: true
Server:
Engine:
Version: 20.10.8
API version: 1.41 (minimum version 1.12)
Go version: go1.16.6
Git commit: 75249d8
Built: Wed Aug 4 21:26:30 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.4.9
GitCommit: e25210fe30a0a703442421b0f60afac609f950a3
runc:
Version: 1.0.1
GitCommit:
docker-init:
Version: 0.19.0
GitCommit: de40ad0
$ docker-compose --version
docker-compose version 1.25.5, build unknown
According to this issue in Docker GitHub:
docker images shows the uncompressed size. During a docker push, the engine compresses (gzip) the image before sending to the registry. The size shown in the Hub UI is the compressed size, and roughly represents how much work a fresh docker pull would need to do. The network transfer size is probably the more important number when deploying containers.
Related
This question already has an answer here:
Can't use ARG in docker multistage build
(1 answer)
Closed 27 days ago.
In my Dockerfile I have a typical setup for an image tag but I'm trying to make a multi-stage build:
FROM docker.io/library/alpine as first-stage
RUN echo "test"
ARG VERSION="latest"
FROM docker.io/library/hello-world:${VERSION} as second-stage
but when I try to build it with a command like:
docker build \
--tag=img-name-dev:latest \
.
(running from the directory that the Dockerfile lives in)
I get in my real code:
failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to parse stage name "link.to.my/image:": invalid reference format
or in the minimal reproducible example:
Step 4/4 : FROM docker.io/library/hello-world:${VERSION} as second-stage
invalid reference format
which indicates to me that the VERSION is empty, rather than being filled with latest. If I remove the ${VERSION} and replace it simply with latest it works (so it's not a permissions issue pulling the image).
What am I doing wrong?
Docker version:
Client: Docker Engine - Community
Version: 20.10.23
API version: 1.41
Go version: go1.18.10
Git commit: 7155243
Built: Thu Jan 19 17:34:12 2023
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.23
API version: 1.41 (minimum version 1.12)
Go version: go1.18.10
Git commit: 6051f14
Built: Thu Jan 19 17:32:03 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.15
GitCommit: 5b842e528e99d4d4c1686467debf2bd4b88ecd86
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Docker Compose version v2.13.0
Any ARG that is used within a FROM command must occur before the first FROM statement. So move your ARG to the very top of your file -- above the additional first stage that you mentioned in the comments. See the Dockerfile reference.
I recently installed Docker on my setup from https://docs.docker.com/desktop/install/mac-install/. When I try to pull any image in my terminal, it throws following error:
(base) harshgoyal#lawn-128-61-61-143 ~ % docker pull docker/getting-started
Using default tag: latest
Error response from daemon: Get "https://registry-1.docker.io/v2/": EOF
(base) harshgoyal#lawn-128-61-61-143 ~ %
(base) harshgoyal#lawn-128-61-61-143 ~ % docker version
Client: Docker Engine - Community
Version: 20.10.23
API version: 1.41
Go version: go1.19.5
Git commit: 715524332f
Built: Wed Jan 18 20:42:16 2023
OS/Arch: darwin/arm64
Context: default
Experimental: true
Server: Docker Desktop 4.16.2 (95914)
Engine:
Version: 20.10.22
API version: 1.41 (minimum version 1.12)
Go version: go1.18.9
Git commit: 42c8b31
Built: Thu Dec 15 22:25:43 2022
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.6.14
GitCommit: 9ba4b250366a5ddde94bb7c9d1def331423aa323
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
(base) harshgoyal#lawn-128-61-61-143 ~ %
System: Macbook Air M1 silicon chip with MacOS Ventura
Solutions tried:
Restarting docker
Reinstalling docker after cleaning all cache files.
Nothing has helped yet. Could someone please help me debug this issue?
Please try to switch the network if you are facing this issue. It worked once I moved to personal hotspot. Seems my university network caused the problem.
Reference thread: https://forums.docker.com/t/docker-pull-throwing-eof-exceptions/134219
I'm trying to create an ECS context using Docker so that I can deploy to AWS using the Docker Compose CLI
docker context create ecs <my context name>
But am receiving the following error:
"docker context create" requires exactly 1 argument.
See 'docker context create --help'.
Usage: docker context create [OPTIONS] CONTEXT
Create a context
I've edited my /etc/docker/daemon.json to include
{
"experimental": true
}
My Docker Compose CLI is version 2.14.2 and both the Client and Server show experimental as true
Client:
Version: 20.10.22
API version: 1.41
Go version: go1.19.4
Git commit: 3a2c30b63a
Built: Tue Dec 20 20:43:40 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server:
Engine:
Version: 20.10.22
API version: 1.41 (minimum version 1.12)
Go version: go1.19.4
Git commit: 42c8b31499
Built: Tue Dec 20 20:42:46 2022
OS/Arch: linux/amd64
Experimental: true
containerd:
Version: v1.6.14
GitCommit: 9ba4b250366a5ddde94bb7c9d1def331423aa323.m
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d1
docker-init:
Version: 0.19.0
GitCommit: de40ad0
This should be available in Docker since 19.03
https://docs.docker.com/cloud/ecs-integration/#install-the-docker-compose-cli-on-linux
So far I've only been able to create an ECS context by installing Docker with the experimental Arch package for Docker Desktop instead of Docker Compose Standalone. The weird thing is, Docker Desktop's Docker Compose version is only 2.13.
This also might be related to this question:
docker context create ecs myecs - requires exactly one argument
OS: Ubuntu cinammon 20.04
I followed the directions from here: docker documentation
When I get to the step to run the Hello-world image.
$ sudo docker run hello-world docker: Error response from daemon: open /var/lib/docker/aufs/layers/9cd449051217b6dc5c24c81e1a02ef897eeb90ee62421d6a227ddfbeddc2b70c-init: no such file or directory. See 'docker run --help'.
`
I've stopped and started the daemon.
sudo service docker stop sudo service docker start
and
systemctl restart docker
The image exists locally per:
$ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE hello-world latest bf756fb1ae65 6 months ago 13.3kB
I've been Googling this and getting nowhere. I've seen other places where restarting the daemon fixes it, but I'm just not that lucky.
Any ideas??
More info:
$ sudo 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:45:44 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:44:15 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
I have been trying to pull a docker image; which has been pushed successfully to the private jfrog repository using the same terminal and in same session. There comes no issues while pushing the image, however on doing a pull it is getting failed with the following region.
[xxxx#xxxx~]$ sudo docker pull docker-repo/xxxx-xxxx-xxx/xx/tomcat-xx:latest
Error response from daemon: missing signature key
If anyone can help what could be reason for this? The difference I can see wrt to the image I pushed through this terminal and the images which are already present in jfrog repo is that manifest has cetain properties associated with them. However, there are no properties present in jfrog repo wrt to image I pushed from this terminal.
Following are the details for reference:
$ sudo docker version
Client: Docker Engine - Community
Version: 19.03.5
API version: 1.40
Go version: go1.12.12
Git commit: 633a0ea
Built: Wed Nov 13 07:25:41 2019
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.5
API version: 1.40 (minimum version 1.12)
Go version: go1.12.12
Git commit: 633a0ea
Built: Wed Nov 13 07:24:18 2019
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.2.10
GitCommit: b34a5c8af56e510852c35414db4c1f4fa6172339
runc:
Version: 1.0.0-rc8+dev
GitCommit: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
docker-init:
Version: 0.18.0
GitCommit: fec3683
Is there anything I am missing at configuration end. Kindly help.
Thanks.
I had the same problem with JFrog Artifactory. For me, it helped to give annotate permissions to the user pushing the image, as suggested here.