GoogleContainerTools
Add Syntax Support
We are starting to make use of heredoc syntax in our dockerfiles and are requesting the addition of this support in the kaniko container.
A quick test revealed the executor can not parse the syntax in the dockerfile. Below is a sample dockerfile that implements the syntax and the resulting error by the executor:
# syntax=docker/dockerfile:1-3-labs
FROM bitnami/php-fpm:latest
EXPOSE 9000
WORKDIR /app
RUN <<EOF
apt-get update -y
apt-get install -y php-mbstring php-mysqli
EOF
error building image: parsing dockerfile: Dockerfile parse error line 15: unknown instruction: APT-GET
As heredocs seems to be a purely syntactic feature, kaniko might get it for free as soon as it uses BuildKit >= v0.10.1 (as seems to already have happened for some dockerfile:1.2 stuff, see https://github.com/GoogleContainerTools/kaniko/issues/1568#issuecomment-1113512645): That BuildKit version was the first one to include a Dockerfile frontend as the built-in one with a syntax >= 1.4 (1.4.1), which is required for here-documents. However bumping BuildKit might be technically simple, but checking that kaniko still works with it is probably a major testing endeavour, but maybe we mere users could help with that?
I think all issue relate with Dockerfile's new features would make many similar issues. If the kaniko tool does not support the syntax method, It's Pour water over a duck's back.
# syntax = docker/dockerfile:1.4
In attempting to build the Dockerfile in the issue description with the latest version of kaniko - v1.11.0 I am seeing build success:
aprindle@aprindle-ssd ~/kaniko [main]./run_in_docker.sh /workspace/Dockerfile /usr/local/google/home/aprindle/kaniko-ctx-dir gcr.io/<repo>/kaniko-test:latest false
INFO[0000] Retrieving image manifest bitnami/php-fpm:latest
INFO[0000] Retrieving image bitnami/php-fpm:latest from registry index.docker.io
INFO[0001] Built cross stage deps: map[]
INFO[0001] Retrieving image manifest bitnami/php-fpm:latest
INFO[0001] Returning cached image manifest
INFO[0001] Executing 0 build triggers
INFO[0001] Building stage 'bitnami/php-fpm:latest' [idx: '0', base-idx: '-1']
INFO[0001] Unpacking rootfs as cmd RUN <<EOF requires it.
INFO[0004] EXPOSE 9000
INFO[0004] Cmd: EXPOSE
INFO[0004] Adding exposed port: 9000/tcp
INFO[0004] WORKDIR /app
INFO[0004] Cmd: workdir
INFO[0004] Changed working directory to /app
INFO[0004] No files changed in this command, skipping snapshotting.
INFO[0004] RUN <<EOF
INFO[0004] Initializing snapshotter ...
INFO[0004] Taking snapshot of full filesystem...
INFO[0006] Cmd: /bin/bash
INFO[0006] Args: [-o pipefail -c <<EOF]
INFO[0006] Running: [/bin/bash -o pipefail -c <<EOF]
/bin/bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
INFO[0006] Taking snapshot of full filesystem...
INFO[0006] No files were changed, appending empty layer to config. No layer added to image.
INFO[0006] Pushing image to gcr.io/<repo>/kaniko-test:latest
INFO[0011] Pushed gcr.io/<repo>/kaniko-test@sha256:c4b2601ef76a8260ac4091b2ed89af083ed301e71ee55c8f33b787a98acf25ed
aprindle@aprindle-ssd ~/kaniko [main]
@guillaume-d thanks for the detailed info on the issue and and the linked issue. Currently kaniko is using buildkit v0.11.6 which I believe solves this from the analysis you gave:
https://github.com/GoogleContainerTools/kaniko/blob/main/go.mod#L30
NOTE: while I believe parsing such Dockerfiles will no longer fail, the additional flags added in these dockerfile(s) 1.[2|3|4].0 version are not fully supported in kaniko. See these related issues: https://github.com/GoogleContainerTools/kaniko/issues/1712 https://github.com/GoogleContainerTools/kaniko/issues/1568 https://github.com/GoogleContainerTools/kaniko/issues/2193
Can anyone in the thread here confirm if the issue here is resolved? From my investigation it seems the # syntax usage and Dockerfile parsing w/ these additional features is now supported (by virtue of updating buildkit - see the NOTE above regarding the gap in actual 1:1 functionality), would appreciate some additional comment here if anyone else has tried this or had friction here. Thanks!
I have tested and 1.11.0 does seem to solve the problem. Kaniko output of a manual run from the debug container listed below:
INFO[0000] Retrieving image manifest bitnami/php-fpm:latest
INFO[0000] Retrieving image bitnami/php-fpm:latest from registry index.docker.io
INFO[0001] Built cross stage deps: map[]
INFO[0001] Retrieving image manifest bitnami/php-fpm:latest
INFO[0001] Returning cached image manifest
INFO[0001] Executing 0 build triggers
INFO[0001] Building stage 'bitnami/php-fpm:latest' [idx: '0', base-idx: '-1']
INFO[0001] Unpacking rootfs as cmd RUN <<EOF requires it.
INFO[0024] EXPOSE 9000
INFO[0024] Cmd: EXPOSE
INFO[0024] Adding exposed port: 9000/tcp
INFO[0024] WORKDIR /app
INFO[0024] Cmd: workdir
INFO[0024] Changed working directory to /app
INFO[0024] No files changed in this command, skipping snapshotting.
INFO[0024] RUN <<EOF
INFO[0024] Initializing snapshotter ...
INFO[0024] Taking snapshot of full filesystem...
INFO[0032] Cmd: /bin/bash
INFO[0032] Args: [-o pipefail -c <<EOF]
INFO[0032] Running: [/bin/bash -o pipefail -c <<EOF]
/bin/bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
INFO[0032] Taking snapshot of full filesystem...
INFO[0036] No files were changed, appending empty layer to config. No layer added to image.
INFO[0036] Skipping push to container registry due to --no-push flag
Going to close this as the issue specifically outlined - kaniko parser failing when encountering new docker syntax - is resolved now. As @guillaume-d noted, there still mismatches/not-implemented features that the new syntax adds for docker/dockerfile:1.[2|3|4|etc.] that kaniko will ignore. Bugs related to supporting these features are below for those who want to watch/comment: https://github.com/GoogleContainerTools/kaniko/issues/1568 https://github.com/GoogleContainerTools/kaniko/issues/1594 https://github.com/GoogleContainerTools/kaniko/issues/1712 https://github.com/GoogleContainerTools/kaniko/issues/1713 https://github.com/GoogleContainerTools/kaniko/issues/1751 https://github.com/GoogleContainerTools/kaniko/issues/2035 https://github.com/GoogleContainerTools/kaniko/issues/2193
Sorry folks, but heredocs syntax is not supported by Kaniko (as of v1.12.1) properly, as your logs above show:
INFO[0032] Args: [-o pipefail -c <<EOF] INFO[0032] Running: [/bin/bash -o pipefail -c <<EOF] /bin/bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
The Args: values should have been [ -o pipefail <<EOF (script code) ] as per Buildkit. or at least something better than only the heredoc instruction (bash is complaining that the heredoc was not terminated, as it only got the <<EOF line and the rest of the script was ignored).
Further proof is the line following this: INFO[0036] No files were changed, appending empty layer to config. No layer added to image.
That would not hold if the script had actually run, since it was making filesystem changes. In short, we end up with an empty step.
I can confirm that this is still a problem as I am facing similar behaviour when trying to use the heredoc feature -- it works in Buildkit but fails in Kaniko as per above.
The step doesn't fail, but no code runs.
The worst part about this bug is that Kaniko, on seeing heredoc syntax, gives no error and continues on with the build as if it had successfully executed the RUN statement. I spent lots of time debugging errors further down in my build before I noticed that the heredoc step was essentially just being skipped. 😞
I was stunned today to find out that kaniko does not support heredocs in 2024:
$ /kaniko/executor $DOCKER_BUILD_ARGS --context $DOCKER_FILE_FOLDER --dockerfile ${DOCKER_FILE:-$DOCKER_FILE_FOLDER/Dockerfile} --destination $CORE_ACR_LOGIN_SERVER/$IMAGE_NAME:$IMAGE_TAG
error building image: parsing dockerfile: dockerfile parse error line 23: unknown instruction: CURL
^ In Gitlab CI
For a Dockerfile like
RUN <<EOF
curl -sO https://www.unixodbc.org/unixODBC-2.3.12.tar.gz
...
EOF
I am not sure if this is the appropriate issue to mention this, but the --security=<sandbox|insecure> flag for RUN also can not be parsed while using # syntax=docker/dockerfile:1-labs
Hello, any news on this? This issue is older than my daughter and she already can walk and say a few words.
Hello, any news on this? This issue is older than my daughter and she already can walk and say a few words.
I love this reply :) Yes, it's been a while since they provided a status on this issue
Any updates on this? Its been a while since status has been provided AND since someone has checked in on this in the comments.
I've also stumbled upon this when i tries to use labs syntax (in my case COPY --exclude)
From looking at the following files:
- file
I think (and I might be wrong!) that the root of the problem is that Kaniko's RunCommand struct currently doesn't handle the Files field of the ShellDependantCmdLine struct embedded in Buildkit's RunCommand struct (yes, Kaniko and Buildkit have their own structs named RunCommand).
The way Buildkit and Docker handle heredocs is much like how an actual shell might go about it:
- Parse the heredoc into a structure containing the heredoc's contents and a filename.
-
Assign the heredoc to an AST node, transform the AST node into a
ParseRequest, then transform theParseRequestinto a BuildkitRunCommand(see the call toparseShellDependantCommand. - Later on, when dispatching the
RunCommand, files from theFilesfield are handled, with the file contents being written to a pipe, being handled directly, or being passed to the shell as appropriate.
While this doesn't appear completely trivial to implement, it doesn't appear to require a large amount of work either. Much of the logic can probably be based upon what Buildkit does.
