Hacker News Reader

Comment by miduil | Hacker News Reader

Really cool, I like the documentation on the website - would be nice if the README was actual HTML though.

Does that mean I can build container images within a running container (for example the GitLab-CI) without doing a stunt like docker-in-docker or fakechroot/fakeroot?

What are you using instead of fakeroot? I've seen people like [zwischenzugs][0] using User Namespaces - which makes it impossible to be run within a container. Author also points out that kaniko still requires you to use root, not sure if the situation has changed with gVisor support, at least a related issue [1] hasn't been marked as resolved.

Have you investigated into creating reproducible containers?

Thank you in advance!

[0]: https://zwischenzugs.com/2018/04/23/unprivileged-docker-buil...

[1]: https://github.com/GoogleContainerTools/kaniko/issues/105

Edit: Why the downvote? Am I misunderstanding something?

View on HN

Thank you :-)

> Does that mean I can build container images within a running container (for example the GitLab-CI) without doing a stunt like docker-in-docker or fakechroot/fakeroot?

Sure, plash's unit tests involve building and they run inside a plash instance at travis CI.

I'll have lunch now and then continue with the reply after.

I think you can already build Docker images via Docker within travis CI, because they somehow provide you (semi?-)privileged access to the required Linux cgroup and namespace features.

If you are running within a regular Docker container commands such as

     sysctl -w kernel.unprivileged_userns_clone=1

are not possible, due to /sys being read-only.

Am I doing something wrong?

> I think you can already build Docker images via Docker within travis CI, [...]

The nice think about plash is that you don't have to worry about "official" support.

> [...] due to /sys being read-only.

Dammit, no, so yeah, apparently unfortunately for regular docker containers (not privileged ones) you need to disable unsharing in plash (export PLASH_NO_UNSHARE=1). In that case the only requirements are chroot, a rudimentary mount binary and overlay OR unionfs-fuse and root access. So it should even run in BSD/Minix/macOS and stuff like that, BUT the mountpoints will not get cleaned up. For an instance running for a while that would be a problem, for a temporary docker container not.

To continue the reply...

plash uses along others linux namespaces and chroot. So inside a linux namespace you can actually use the vanilla chroot:

  ihucos@macbook:~/plash$ # get an example rootfs
  ihucos@macbook:~/plash$ mkdir /tmp/m
  ihucos@macbook:~/plash$ plash mount --from ubuntu -- /tmp/m
  ihucos@macbook:~/plash$ 
  ihucos@macbook:~/plash$ unshare --map-root --user --mount
  root@macbook:~/plash# chroot /tmp/m
  root@macbook:/# type apt
  apt is /usr/bin/apt
  root@macbook:/# exit

> Have you investigated into creating reproducible containers?

Interesting topic. I wanted to, but did not come very far. Maybe now that I "finished" plash and have more time haha.

btw: I just tested and you can just run unprivileged plash containers inside a unprivileged plash process! But you need to install unionfs-fuse in the first container. When/If I port plash to C maybe that dependency can be statically linked or something like that, lets see.

> Really cool, I like the documentation on the website - would be nice if the README was actual HTML though.

Thanks, the README is not in markup so it's one little dependency less when I have to migrate out from Github at some point (M$)

EDIT:

> Edit: Why the downvote? Am I misunderstanding something?

It wasn't me, I think they where great questions!

Reply on news.ycombinator.com