From mboxrd@z Thu Jan 1 00:00:00 1970 From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Subject: Re: Environment containers Date: Mon, 26 Oct 2015 15:37:59 +0100 Message-ID: <87y4epsnjs.fsf@T420.taylan> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqisW-0001IB-Ii for guix-devel@gnu.org; Mon, 26 Oct 2015 10:36:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqisV-00054X-FQ for guix-devel@gnu.org; Mon, 26 Oct 2015 10:36:04 -0400 Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:34400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqisV-00054Q-73 for guix-devel@gnu.org; Mon, 26 Oct 2015 10:36:03 -0400 Received: by wikq8 with SMTP id q8so167838635wik.1 for ; Mon, 26 Oct 2015 07:36:02 -0700 (PDT) In-Reply-To: (David Thompson's message of "Sun, 25 Oct 2015 21:27:14 -0400") 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: "Thompson, David" Cc: guix-devel "Thompson, David" 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