dockerfile: allow heredocs for CMD instruction

[jedevc]

Revisits #2265, introducing support for using heredocs for the CMD instruction

I came across a use case for this in #2773. In prototyping jedevc/buildkit-syft-scanner, the last couple of commands were always COPY and then set the CMD to the created script - the heredoc syntax simplifies this:

COPY <<-"EOF" /scan-script.sh
	#!/bin/sh
	...
EOF
CMD sh /scan-script.sh

Heredocs here work identically to the heredocs for RUN, with a couple of differences for shebang scripts:

• We create a new layer writing the script contents to /mnt/pipes/

  Usually CMD does not create a new layer, however, the file is required to run the script as we would with RUN, since we want to avoid manual parsing of the shebang line.

• We have to use /mnt/pipes instead of /dev/pipes, since /dev/pipes is mounted at runtime.

Tests would be needed for this, but will hold off until getting some feedback first 😄

[jedevc]

🤦 🤦 woops, didn't realize that #2265 was already a PR (and not an issue), I prefer the implementation in that one, closing here to re-open there.

[tonistiigi]

For your use case, doesn't using the CMD sh /scan-script.sh leave a much clearer message of what is happening in the docker history and docker inspect output?

[jedevc]

So a Dockerfile:

FROM alpine

CMD <<EOF
#!/bin/sh
echo test
EOF

Would produce:

$ docker history test
IMAGE          CREATED          CREATED BY                                      SIZE      COMMENT
b042135a1e36   17 minutes ago   CMD ["/bin/sh" "-c" "/mnt/pipes/EOF"] # buil…   16.4kB    buildkit.dockerfile.v0
<missing>      4 weeks ago      /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B        
<missing>      4 weeks ago      /bin/sh -c #(nop) ADD file:2a949686d9886ac7c…   6.2MB     

$ docker inspect test
...
            "Cmd": [
                "/bin/sh",
                "-c",
                "/mnt/pipes/EOF"
            ],
...

Agreed, the final CMD isn't perfect in this case, however, we would normally perform a shell prefix operation, so there is some precedence for (lightly) modifying the CMD in the Dockerfile. I cleaned up the history a little bit in the other PR, but I think seeing the pipe files here is acceptable, since that's what we already have for the RUN history items.

If adding a new layer like this isn't really acceptable at all for CMD we could always support the variations where they are simply passed directly to the shell as command parameters - those keep the Cmd json field completely readable, we'd only have to not support the variant with shebangs.

[tonistiigi]

It seems like a special case. If the user adds one more line to the Dockerfile instead of using this then the history and inspect output would be cleaner and likely the Dockerfile itself would be easier to understand as to understand what CMD <<eof exactly means you would need to look at the docs. When we add this then it is confusing why the same doesn't work for ENTRYPOINT and the scope keeps growing. When -v /mnt etc. is used the image quite unexpectedly gets undefined entrypoint behavior.