Open mih opened 6 years ago
Here is a possibly complete example call:
% sudo systemd-nspawn
-q # do not talk, just output from the execution inside the container
-D /tmp/chroot/test # run this chroot, there is also -i for images, and --overlay for more fun
--ephemeral # pretty much COW behavior for the container filesystem
--machine dataladtest # call it something nice (embed dataset ID, etc...)
--bind=$HOME # full RW access to HOME, not desired for us, I think
--chdir=$PWD # could be used to force-enter the root of a dataset
--bind-ro=/etc/passwd # make system users known, needed for next
-u $USER # become the outside user inside the container
--bind=/tmp # useful when persistent temp storage is needed
--bind=$PWD # could be used to make the dataset in question accessible inside the container
Here is a similar (but much more limited setup with linux-user-chroot
):
% linux-user-chroot --mount-bind $PWD $PWD --chdir $PWD /tmp/chroot/test ...
@mih Cool find. My quick, stream of thought (as I'm jumping on a train soon): 1) requirement of sudo is a big loss vs singularity 2) while most distros have systemd, not /all/ of them do. Singularity lets us be on all modern linux, regardless of systemd 3) I don't know if Ubuntu has moved to systemd yet, or if they're still using their "upstart"
Other than that... I think it's a cool find in the swamp that is systemd's feature creep. I'm curious to see the perf comparisons. IIRC, systemd allows auto pulling and updating of docker images. If going this way, it's probably worth spelunking into their other features.
---Alex
There seems to be no way to keep a chroot directory in a git repo and still have it functional. Hence any exploration of this kind would require a set of management scripts (like those we outlined for docker): untar, run, throw away directory.
Here is the info: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
Advantages:
Disadvantages:
systemd-nspawn
, i.e. become root (typically via sudo)What needs to be implemented:
Alternatives: