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 <suda.akihiro@lab.ntt.co.jp>
This commit is contained in:
Akihiro Suda
2019-04-25 10:41:38 -07:00
committed by Sharif Elgamal
parent 7901c76127
commit 404af20f7c
+5 -4
View File
@@ -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