[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Update on GuixSD containers
From: |
Ludovic Courtès |
Subject: |
Re: Update on GuixSD containers |
Date: |
Tue, 09 Jun 2015 23:28:22 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
"Thompson, David" <address@hidden> skribis:
> I'd like to give a quick update on the state of wip-container branch.
> As of this morning, one can run the below commands and have a somewhat
> functional GuixSD container:
>
> # Hardcoded /tmp/container as the container root directory until I
> # add a command line switch.
> mkdir /tmp/container
> guix system container container-config.scm
Wonderful! I’ve given it a try, and it works as advertised. ;-)
I was a bit afraid the first time I ran the ‘run-container’ script as
root, but everything went like a charm.
I tried adding this dummy service:
(define (bash-service)
(with-monad %store-monad
(return (service
(documentation "Run Bash from PID 1.")
(provision '(shell))
(start #~(make-forkexec-constructor
(string-append #$bash "/bin/bash")))
(stop #~(make-kill-destructor))
(respawn? #t)))))
... but it dies for some reason. So no shell prompt.
> So, this is cool, but much work remains to be done. Our containers
> operate in 5 of 6 possible Linux namespaces: mount, PID, UTS, IPC, and
> network. The remaining namespace to get working is the user
> namespace, which is especially tricky. I don't think even Docker can
> use user namespaces properly yet, but I might be wrong. Additionally,
> our containers have a loopback device, but have no way of accessing an
> outside network such as your LAN or a virtual network on the host
> system. There's also no support for cgroups, which would allow us to
> limit the resource usage of containers like you can with a VM
> hypervisor.
OK.
> For the long term, we'll need a container daemon to keep track of all
> containers on the system to allow for easily starting and stopping
> them (right now you have to 'sudo kill -9 <dmd pid>'), spawning new
> processes within them (for example, launching bash for an interactive
> environment), and whatever else we might want.
Having launched a bunch of containers and then hacked to kill all the
dmds, I can see why keeping track of containers matters. :-)
Until there’s a daemon to keep track of containers, “guix system
container” could return the PID of the container’s PID1, to make it
easier to kill it later?
> In closing, things aren't exactly usable, but I encourage
> brave/curious people to take 'guix system container' for a spin and
> hack on it to make Guix the best container management tool yet! Also,
> I think the code is very easy to follow (unlike Docker's
> libcontainer), so if you want to understand what containers *really*
> are beyond a buzzword, have a look at gnu/build/linux-container.scm
> and gnu/system/linux-container.scm.
Indeed I find the new code easy to read and well integrated; I like it!
It’s a shame that only CLONE_NEWUSER is available to non-root users. I
wonder what the rationale was. AIUI, Docker’s daemon performs clone(2)
on behalf of clients, right?
Thanks for the great work!
Ludo’.
- Update on GuixSD containers, Thompson, David, 2015/06/08
- Re: Update on GuixSD containers,
Ludovic Courtès <=
- Re: Update on GuixSD containers, Thompson, David, 2015/06/11
- Re: Update on GuixSD containers, Ludovic Courtès, 2015/06/12
- Re: Update on GuixSD containers, Thompson, David, 2015/06/12
- Re: Update on GuixSD containers, Ludovic Courtès, 2015/06/13
- Re: Update on GuixSD containers, Thompson, David, 2015/06/13
- Re: Update on GuixSD containers, Ludovic Courtès, 2015/06/13
- Re: Update on GuixSD containers, Thompson, David, 2015/06/16
- Re: Update on GuixSD containers, Ludovic Courtès, 2015/06/19