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-26 02:41:38 +09:00 committed by Sharif Elgamal
parent 7901c76127
commit 404af20f7c
1 changed files with 5 additions and 4 deletions

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