-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support bind Build Mounts (RUN --mount=type=bind / RUN --mount) like BuildKit and Buildah do #1568
Comments
We are looking to use a single
As a start, we could simply parse and ignore the ones that are not supported, like Also the above error is pretty generic, and it would make more sense to do a check of the syntax directive, and fail there: # syntax = docker/dockerfile:1.2 |
any update on this? |
Congratulations on 1 year anniversary of this issue. Will it be every added? |
The problem of this issue is that mount operation requires extra permissions.
I think the first option is better, because this will not violate the Dockerfile specification. Or we can make this behavior configurable via executor flag, eg: |
The intend is to have files in a folder, from a previous layer (or a special device from /dev) available while building, but to not include it within the layer. Anything that makes this possible will be appreciated. |
A cache could typically be a few gigabytes. I think it would be advisable to at least have the option of symlink/mount instead of a plain copy. |
Starting from kaniko 1.8.0, the mere syntax for the credentials is supported, as well as all other syntax added by syntax=docker/dockerfile:1.2.0.
As said above, parsing those already works, but this does not offer much more, there are few things to be gained for just the syntax being accepted, even WRT compatibility with BuildKit: only few useful things require only syntax and/or are completely backward-compatible: # syntax=docker/dockerfile:1.2
# purely syntactic, so it indeed works,
# see <https://gitlab.com/iguillaumed/playground/dockerfile-standard/-/jobs/2395435878>:
ARG k1=v1 k2=v2
# purely syntactic, so it indeed works,
# see <https://gitlab.com/iguillaumed/playground/dockerfile-standard/-/jobs/2395435878>:
ADD --chown=$owner:$group ARG...
# when purely syntactic, the key will never be available, so
# required=true will not work as expected / could be insecure:
RUN --mount=type=ssh CMD
# when purely syntactic, the secret will never be available, so
# required=true will not work as expected / could be insecure:
RUN --mount=type=secret CMD In the future (some kaniko version after 1.8.1): # syntax=docker/dockerfile:1.3
# the default:
RUN --network=default CMD
# insecure when purely syntactic, but functionally equivalent to no --network:
RUN --network=none CMD # syntax=docker/dockerfile:1.4
# in most cases functionally equivalent to no --link
# (just make sure by testing with a full implementation like BuildKit that --link may really be used),
# but no performance gain of course when purely syntactic:
COPY --link ARG...
# to be explicit when/if --link cannot be used:
COPY --link=false ARG...
# the same as above but with ADD instead of COPY
# just speculating here, but heredocs should be purely syntactic:
RUN <<EOT
apt-get update
apt-get install -y vim
EOT
As one can see in my compatibility tests' result for dockerfile:1.3 using kaniko v1.8.1, the error messages have not gotten better (this time for
However they might come directly from BuildKit, so maybe they could(/must?) be improved there instead, for example as suggested below:
Even more precise error messages WRT the needed syntax would go against BuildKit's syntax modularity idea (and against the flow of time itself 😉): one syntax's parser would have to know about all other syntaxes' parsers or future syntaxes! |
Concerning
Also now we know the syntax already works, see my previous comment. |
FYI Buildah >= 1.24 (which is shipped with Podman >= 4) also supports RUN --mount=type=bind. |
At least if these options aren't supported, they should cause a Kaniko build to fail so the user doesn't think they're getting these advantages (cacheing) or go off on wild goose chases trying to figure out why files are missing when in reality |
Any news on this topic? Support for build mounts would be very useful. |
@rd-danny-fleer Look at this and the following sections within the docs https://docs.docker.com/reference/dockerfile/#run---mount And if all of these aren't enough you can always opt for a multi stage build to squash all layers into one:
HOWEVER instead of this approach that looses all of the layer information I'd suggest first trying to statically link your application and have a container with only your applications binary copied into (aka without any linux user land) |
For more details see https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/syntax.md
That would help avoiding contortions in the Dockerfile due to COPY's silly "partial flattening" of file hierarchies...
Also for performance some of the other types would be nice:
RUN --mount=type=tmpfs
RUN --mount=type=cache
, but this is Mount cache directory inside build container #969 already (please vote at Mount cache directory inside build container #969 (comment) if you are interested!)but these as a first step may be no-op implementations (just to have better compatibility with BuildKit), whereas
RUN --mount=type=bind
cannot be fakedThe text was updated successfully, but these errors were encountered: