GoogleContainerTools
Mount when invoking kaniko plain
It would be useful to be able to mount a directory (even just the build context) to make it accessible within the Dockerfile.
This is obviously possible when using Kubernetes, but there doesn't seem to be any option to /kaniko/executor that has the effect of --mount (as how /kaniko/executor takes --build-arg).
The functionality apparently already exists (though I haven't been able to figure out how it's done in the kaniko source code), since RUN ls /kaniko shows a directory that is populated with a number of files including the Dockerfile itself. (Of course, if it's a string we can put in the Dockerfile, then we could just include it in a RUN line directly.)
(If mounting is currently possible, it would be good to note this in the documentation. Right now it says "If you wish to use this option, you will need to mount in your build context into the container as a directory." but doesn't suggest how that might be possible, if it is possible without Kubernetes.)
(It's very useful to be able to run kaniko without provisioning a Kubernetes cluster in advance --- for example, https://gitlab.com/guided-explorations/containers/kaniko-docker-build provides a template anyone can use to immediately build a Docker image with nothing but a gitlab-runner. I'm working on a version of that https://gitlab.com/dHannasch/container-wrapper-for-python-package for allowing anyone to take any Python application and wrap it in a Docker container for deployment in five minutes.)
(I gather from #489 and #707 that using mounts is the recommended way to share secrets that are required for the Docker build, since kaniko does not allow direct interaction with the Docker BuildKit --secrets.)
Of course, if https://github.com/GoogleContainerTools/kaniko/issues/1327 is intended behavior, then --build-arg is a great way to pass in secrets.
docker run -it -v LOCAL_PATH:CONTAINER_PATH gcr.io/kaniko-project/executor:latest KANIKO_ARGS
There are several examples in the kaniko README.
Your example requires to use Docker.
In our case (running Kaniko in Docker [GitLab CI/CD runner]), we cannot do that.
@ddgenome in addition to what @gajus said, it appears that what you're trying to do is something else entirely. The point is not to get anything mounted into the running gcr.io/kaniko-project/executor:latest kaniko container --- that's easy. The point is to get a string into the image that is being built, as it is being built.
Looking at e.g. https://gitlab.com/guided-explorations/containers/kaniko-docker-build/-/blob/master/Dockerfile, there is a Dockerfile for the Docker image that kaniko is building, as distinct from the Docker image that is kaniko.
The Dockerfile has something like
FROM $BASE_IMAGE
# want to mount in user-specific configuration here
RUN pip install --no-cache-dir nameless # this step uses user-specific configuration
It's easy to get anything into the gcr.io/kaniko-project/executor:latest kaniko container itself; the problem is getting it from there to the image it's building.
@gajus you could see some of our examples here https://github.com/GoogleContainerTools/kaniko/blob/master/examples/pod.yaml#L15
You can mount directories your want using the VolumeMounts in PodSpec
It would be useful to be able to mount a directory (even just the build context) to make it accessible within the Dockerfile. This is obviously possible when using Kubernetes, but there doesn't seem to be any option to
/kaniko/executorthat has the effect of--mount(as how /kaniko/executor takes--build-arg).The functionality apparently already exists (though I haven't been able to figure out how it's done in the kaniko source code), since
RUN ls /kanikoshows a directory that is populated with a number of files including the Dockerfile itself. (Of course, if it's a string we can put in the Dockerfile, then we could just include it in a RUN line directly.)(If mounting is currently possible, it would be good to note this in the documentation. Right now it says "If you wish to use this option, you will need to mount in your build context into the container as a directory." but doesn't suggest how that might be possible, if it is possible without Kubernetes.)
(It's very useful to be able to run kaniko without provisioning a Kubernetes cluster in advance --- for example, https://gitlab.com/guided-explorations/containers/kaniko-docker-build provides a template anyone can use to immediately build a Docker image with nothing but a gitlab-runner. I'm working on a version of that https://gitlab.com/dHannasch/container-wrapper-for-python-package for allowing anyone to take any Python application and wrap it in a Docker container for deployment in five minutes.)
(I gather from #489 and #707 that using mounts is the recommended way to share secrets that are required for the Docker build, since kaniko does not allow direct interaction with the Docker BuildKit --secrets.)
Of course, if #1327 is intended behavior, then
--build-argis a great way to pass in secrets.
@dHannasch I have exactly the same issue, do you have the answer?
@dHannasch did you develop a solution to this issue? I just encountered it now trying to move over another docker project to kaniko. The legacy build had a Dockerfile with a docker --mount line in it and since Kaniko doesn't support mount I'm looking for a workaround...
@sposten I had an issue with ssh mounting. You can see here what I have done. https://link.medium.com/nnEY55BIolb
@yossicohn thanks! I'm not sure that will work for me due to other security considerations.
The possibility to mount into the image that is being built, as it is being built (as @dHannasch said) is pretty useful for injecting SSH keys to a single layer, injecting secrets and for caching. BuildKit has these features, it would be awesome to have them on kaniko as well. Here are three examples for the situations I described above:
- SSH mount type (for cloning private repositories):
RUN --mount=type=ssh git clone [email protected]:myorg/myproject.git myproject
Docker build command with the --ssh flag:
docker build --ssh default .
- Secret mount type (injecting secrets temporarily):
RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar
So you run docker build with the --secret flag:
docker build --secret id=mysecret,src=mysecret.txt .
- Cache mounts (caching
aptorpipon the build process):
RUN --mount=type=cache,target=/var/cache/apt \
apt-get update && \
apt-get install -yqq --no-install-recommends \
package-name \
&& rm -rf /var/lib/apt/lists/*
