GoogleContainerTools / kaniko

Build Container Images In Kubernetes
Apache License 2.0
14.91k stars 1.44k forks source link

Add Syntax Support #1713

Open vguaglione opened 3 years ago

vguaglione commented 3 years ago

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

LeaTaka commented 3 years ago

+1 Yesss, this would be a welcome feature !

guillaume-d commented 2 years ago

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?

GeunSam2 commented 1 year ago

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
aaron-prindle commented 1 year ago

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!

vguaglione commented 1 year ago

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

aaron-prindle commented 1 year ago

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

jfpoirier-x2o commented 1 year ago

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.

willzhang commented 1 year ago

same here with argo-workflows

image

NfNitLoop commented 1 year ago

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. 😞

greatvovan commented 8 months ago

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
Antiarchitect commented 7 months ago

Any progress on this? :)

utkuaydn commented 6 months ago

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

jredel commented 6 months ago

Any news ? We want to use Kaniko and our Dockerfile use heredocs :(

palmobar commented 4 months ago

Hello, any news on this? This issue is older than my daughter and she already can walk and say a few words.

vguaglione commented 4 months ago

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

AminaEmenena commented 2 months ago

Any updates on this? Its been a while since status has been provided AND since someone has checked in on this in the comments.