From 404af20f7c041264282a4ca09b79660da6f9d616 Mon Sep 17 00:00:00 2001 From: Akihiro Suda Date: Fri, 26 Apr 2019 02:41:38 +0900 Subject: [PATCH] README.md: update BuildKit/img comparison (#642) Latest BuildKit/img no longer necessarily requires procMount to be unmasked, by not unsharing PID namespaces. The current drawback of BuildKit/img compared to kaniko is that BuildKit/img requires seccomp and AppArmor to be disabled so as to create nested containers. https://github.com/moby/buildkit/pull/768 https://github.com/genuinetools/img/pull/221 Signed-off-by: Akihiro Suda --- README.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 6efe487a6..823b0712b 100644 --- a/README.md +++ b/README.md @@ -450,6 +450,7 @@ You may be able to achieve the same default seccomp profile that Docker uses in Similar tools include: +- [BuildKit](https://github.com/moby/buildkit) - [img](https://github.com/genuinetools/img) - [orca-build](https://github.com/cyphar/orca-build) - [umoci](https://github.com/openSUSE/umoci) @@ -459,10 +460,10 @@ Similar tools include: All of these tools build container images with different approaches. -`img` can perform as a non root user from within a container, but requires that -the `img` container has `RawProc` access to create nested containers. `kaniko` -does not actually create nested containers, so it does not require `RawProc` -access. +BuildKit (and `img`) can perform as a non root user from within a container, but requires +seccomp and AppArmor to be disabled to create nested containers. `kaniko` +does not actually create nested containers, so it does not require seccomp and AppArmor +to be disabled. `orca-build` depends on `runc` to build images from Dockerfiles, which can not run inside a container (for similar reasons to `img` above). `kaniko` doesn't