Documentation

[vsoch]

Is there any documentation for using this? I tried the usual place:

inception --help
-c [image_name]
-x #copy environment

and there doesn't seem to be much in the repository after install. I'd like to get a glimpse at how this works before launching on my computer :) Thank you!

[matthewsucar]

Pull requests will be at least looked at :-)

If you look at the source, you'll find that there are a couple other undocumented options that can be convenient in a scripted environment, but that's basically it for the end user UI. Nearly all of our users interact with this though a wrapper of some sort, generally a batch scheduler (mostly PBSPro in our case, at least for now). I certainly plan to write up how to do that at some point, but haven't had a chance to do so yet.

The idea here is to provide a curated library of images to our end users, provided by someone like a sysadmin. The initial source might be something like Docker or SingularityHub, but the admin has to integrate the image into their environment a bit. This process is currently a bit manual (we're working on automating it, but I don't have anything I can share yet). At the very least, this includes either removing or configuring mounts over top of anything authentication related (sudoers/sudoers.d, passwd/shadow/group, any setuid binaries, etc). Typically we also mount sockets for things like our batch scheduler, munge, MTA, etc. For some images, we also upgrade (actually, usually downgrade) the image's OFED, graphics libraries, etc to match the outer system as necessary. Of course, this completely destroys what little credibility the idea that containers make things reproducible may have, but it does allow things to actually work.

There's a very basic example of a config file in the repository. The file format is very simple and intended to be self documenting, basically just a list of mounts. I anticipate adding a few more tags in the near future, but it won't change much. I'd like to be able to handle a subset of the open container format eventually, but this meets out needs for now.

As far as building images by end users goes, that's on the plan for the summer/fall, now that we're finally looking at updating to kernels that might be able to support it reasonably securely. For now, this runs regularly on kernels as old as 2.6.32.

[vsoch]

ah ok this makes sense - so it sounds like building an image (even just importing from another container) isn't quite ready to try out yet? I wanted to find some of the big names and do a comparison of commands so likely the minimum working inception would need to be able to bootstrap another container (or similar). If I read correctly, at some point the config file will also allow for things beyond mounts (like a bootstrap?) Are there any examples of actually doing a build that are substantial enough so I could try it? If not, I'm definitely ok to wait, we can leave the issue open and you ping me when there is something exciting happening! :)

[matthewsucar]

building an image certainly isn't publicly automated, and in our environment is an infrequent operation. For the most part, it's done by either exporting tarballs from docker or using rsync against a running system and then patching result. We've also used rpm or debootstrap a few times - it depends on the use-case. Regardless, it's done on a standalone system and the result is copied to the shared system (typically an HPC cluster). Somewhat similar to the ideas behind SingularityHub I think.

I think you're after a slightly different use-case than this tool is intended to solve. This has to (at least for now) run on kernels with incomplete kernel/namespace support, so for security reasons we really can't allow local building of images by unprivileged users (and relatively few of our users have a real need to do so anyway). Inception is really just a fancy wrapper around mount namespaces, which is enough for 90% of our use-cases.

I do see this changing, maybe over the summer as our infrastructure moves to newer kernels. Whether we continue inception or just switch to something like runc is still an open question.

For now, there isn't anything that maps one to one to something like "docker build" or the image manipulation ch-* commands. From your comparison, I think Inception is most similar to ch-run.

I see no problem leaving this bug open for a while.

[vsoch]

ah I see, that makes sense. Sounds like a plan - leave open and await further notice. Thanks for your help!