Re: Environment containers

[Taylan Ulrich Bayırlı/Kammer]

"Thompson, David" <address@hidden> writes:

> Hello Guix hackers,
>
> I am pleased to announce that the patch for adding Linux container
> support to 'guix environment' has just landed in master!
>
> Why is this cool, you ask?  Well, it enables one to truly isolate
> development environments from the rest of the system, much more so
> than --pure does.  The --pure option only clears the environment
> variables, but --container goes further and "unshares" kernel
> resources (such as the user, mount, and pid namespaces) and creates a
> chroot environment that has no file system access to what might be
> considered "impurities."  The only file systems from the host that
> make it into the container by default are the current working
> directory and the store paths for all of the needed software.  This is
> especially useful when running Guix on top of another host distro,
> where sometimes things from the host sneak into your build environment
> because a tool decided to inspect the contents of /usr or something.
>
> You can use it like this:
>
>     guix environment --container guix
>
> The above command will create an isolated container with everything
> you need to build Guix from source.
>
> There's more fun to be had, too.  Sometimes it's nice to make ad-hoc
> sandboxes just to play around in.  The below command will run a
> sandboxed Guile REPL:
>
>     guix environment --container --ad-hoc guile -- guile
>
> By default, containers have no network access.  To share the host
> network, use the --network flag.
>
> This is just the beginning!  There's lots more to do.  It would be
> nice to be able to create a network bridge so that the container can
> have network access without sharing the host devices, a la Docker and
> friends.  It would also be great to incorporate cgroups to arbitrarily
> restrict container resources.
>
> Coming soon is 'guix system container', which creates full-blown
> GuixSD containers.
>
> Since I mentioned Docker, I'd like to point some significant
> advantages that Guix containers have over other implementations:
>
> 1) The container tools I'm working on are completely declarative.  No
> imperative Dockerfiles!  This means that you don't have to worry about
> order of operations, something that you have to think about constantly
> when using Docker, especially when trying to maximize the use of the
> image cache.
>
> 2) There are no disk images.  Disk images are opaque blobs that are
> often not reproducible, whereas the items in the Guix store tell you
> the full story of how the software came to be.  Thus, Guix containers
> do not worry at all about the complications involved with layering
> disk images in an overlayfs-style setup.  They are simply not needed.
>
> 3) Software and other files shared amongst many containers are
> deduplicated system-wide.  This is a big deal from my perspective.
> With Docker, container images *must* share as many base image layers
> as possible to take advantage of deduplication, and there's
> limitations to how smart overlay file systems can be to do
> deduplication in memory (citation missing because I can't find the
> article that explained the issues.)  Some people say that Docker is a
> higher-level form of static linking, but instead of static linking the
> executables, you "statically link" an entire, albeit more minimal,
> operating system for each application that you run.  I'm inclined to
> agree, and I'm happy to say that Guix doesn't have this problem.  A
> store item present in N containers exists in exactly one place: in the
> host store.  We take great advantage of bind mounts to share
> everything without duplication.  Once again the fundamental building
> block of every Guix tool, the immutable store, proves to be an
> invaluable asset in overcoming the problems of our imperative
> predecessors and contemporaries.
>
> I hope this excites some of you.  Containers are all the rage right
> now, and they have some seriously good properties if you can look past
> the Docker hype.  I'd love to get some more hands to help make Guix
> containers more featureful and robust in order to compete with the
> mainstream tools.
>
> Until next time, happy hacking!
>
> - Dave

After some PEBKAC David helped me sort out over IRC, I got this running.
Thanks! :-)


Also, for Debian 8 users and maybe others, this might help:

    sudo sysctl -w kernel.unprivileged_userns_clone=1

Credit goes to Efraim.

Taylan