From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Environment containers Date: Sun, 25 Oct 2015 21:27:14 -0400 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqWZC-0003fH-MG for guix-devel@gnu.org; Sun, 25 Oct 2015 21:27:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqWZ9-00073y-Fp for guix-devel@gnu.org; Sun, 25 Oct 2015 21:27:18 -0400 Received: from mail-yk0-f178.google.com ([209.85.160.178]:36282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqWZ9-00073o-Bf for guix-devel@gnu.org; Sun, 25 Oct 2015 21:27:15 -0400 Received: by ykba4 with SMTP id a4so163642536ykb.3 for ; Sun, 25 Oct 2015 18:27:14 -0700 (PDT) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel 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