Dockerfile ARG not being properly set in FROM [duplicate] - docker

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.

Related

Create ECS Context with Docker without Docker Desktop

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

docker-compose push incorrect image size

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.

Why does FROM registry.hub.docker.com/library/centos:centos7 fail in my docker build?

The following line in my Dockerfile:
FROM registry.hub.docker.com/library/centos:centos7
fails with the following error:
Sending build context to Docker daemon 1.664MB
Step 1/17 : FROM registry.hub.docker.com/library/centos:centos7
Get https://registry.hub.docker.com/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
I am running behind a proxy and I tried to follow the instructions on this website, but still no success (same error). So I have a file in my ~/.docker/config.json that pretty much looks like what the link says, and I inserted my internal proxy IP address information. However, I still get the same "request canceled" error message shown above.
Here is some information about my CentOS 7 system:
Linux localhost.localdomain 3.10.0-1160.15.2.el7.x86_64 #1 SMP Wed Feb 3 15:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
docker version
Client: Docker Engine - Community
Version: 20.10.5
API version: 1.41
Go version: go1.13.15
Git commit: 55c4c88
Built: Tue Mar 2 20:33:55 2021
OS/Arch: linux/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:32:17 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.4
GitCommit: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
runc:
Version: 1.0.0-rc93
GitCommit: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
docker-init:
Version: 0.19.0
As richyen said, the correct image is centos:7 and should make it work.
You are speaking about a proxy : the method you used to set a proxy up works, but if your system uses systemd (which is centos7 case I think) you should use this method to set your docker proxy up. I had a lot of troubles with that in the past.

Getting docker error, daemon is missing signature key on docker pull

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.

Named stage returns: Error parsing reference: "golang:1.7.3 as builder" is not a valid repository/tag

On Gentoo Linux kernel 4.12.12
added docker info and version below
docker info : https://pastebin.com/Ph9ibMna
> docker version
Client:
Version: 17.06.2-ce
API version: 1.27 (downgraded from 1.30)
Go version: go1.8.3
Git commit: cec0b72
Built: Thu Sep 28 07:14:33 2017
OS/Arch: linux/amd64
Server:
Version: 17.03.2-ce
API version: 1.27 (minimum version 1.12)
Go version: go1.8.3
Git commit: f5ec1e2
Built: Wed Sep 13 23:43:20 2017
OS/Arch: linux/amd64
Experimental: false
command:
> docker build -t some-test .
Sending build context to Docker daemon 234.9MB
Step 1/1 : FROM golang:1.7.3 as builder
Error parsing reference: "golang:1.7.3 as builder" is not a valid repository/tag: invalid reference format
from Dockerfile:
FROM golang:1.7.3 as builder
example taken from name-your-build-stages
The issue is your client is 17.06.2-ce and server is 17.03.2-ce. Multi stage build came in 17.06 i believe, so you need that version on the server. It is the server that processes the build. The client will only send the information to the server
So upgrade your server and it will work fine

Resources