4 ms·

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

by ihucos 8y ago

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.

miduil 8y ago
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?
- ihucos 8y ago
  > 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.
ihucos 8y ago
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!

by ihucos 8y ago

miduil 8y ago

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?

ihucos 8y ago
> 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.

ihucos 8y ago

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!