"Thompson, David" <dthomps...@worcester.edu> 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’.