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:
parent
7901c76127
commit
404af20f7c
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue