Refactor the interface to avoid such issues in the future.
BuildKit own mounts are stateless and not affected but
a different mountable implementation could get confused.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
There were two bugs: Mount was matched by Type which is actually
`cgroup`, not `sysfs`. And the second problem was that copy of the value
was modified, not value in the slice.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This patch allows downstream code to pass a DNSConfig that is
then used by executor/oci.GetResolvConf.
This would allow the BuildKit-based builder in Docker to honor
the docker daemon's DNS configuration, thus fixing a feature gap
with the legacy builder.
Signed-off-by: Tibor Vass <tibor@docker.com>
This flag allows DOCKER_BUILDKIT to be running on minikube host: https://github.com/kubernetes/minikube/issues/4143
moby/builder/build-next needs to be updated to set NoPivot when
$DOCKER_RAMDISK is set.
This flag is deprecated from its birth and not exposed to the standalone buildkitd OCI worker.
See https://github.com/kubernetes/minikube/issues/3512
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Note that this mode allows build executor containers to kill (and potentially ptrace) an arbitrary process in the BuildKit host namespace.
This mode should be enabled only when the BuildKit is running in a container as an unprivileged user.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
This fixes the issues where buildkit and callers do not have to be a
subpreaper in order to use networking. I can add CNI provider later,
with a hidden sub command to create a new network namespace and bind
mount it to buildkit's state dir.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
e.g. with busybox image:
OCI runtime create failed: container_linux.go:348:
starting container process caused "process_linux.go:402:
container init caused \"rootfs_linux.go:58:
mounting \\\"proc\\\" to rootfs \\\"/.../rootfs\\\" at \\\"/proc\\\"
caused \\\"mkdir /.../rootfs/proc: read-only file system\\\"\"": unknown
This is because we were setting the underlying snapshot readonly so the various
mountpoints (here /proc) cannot be created. This would not be necessary if
those mountpoints were present in images but they typically are not.
The right way to get around this (used e.g. by `ctr`) is to use a writeable
snapshot but to set root readonly in the OCI spec. In this configuration the
rootfs is writeable when mounts are processed but is then made readonly by the
runtime (runc) just before entering the user specified binary within the
container.
This involved a surprising amount of plumbing.
Use this new found ability in the dockerfile converter's `dispatchCopy`
function.
Signed-off-by: Ian Campbell <ijc@docker.com>