Bug#915237: RFP: systemd-docker -- Wrapper for "docker run" to handle systemd quirks
As a followup, I can't help but think this is all a huge horrible hack
and that we're over thinking this problem completely.
A container is what:
* an image "filesystem" (a tarball of tarballs really)
* a manifest (which volumes should be exported, ports, etc)
* a running process (or multiple, if you're into that kind of heresies)
under a vague set of constraints (cgroups, apparmor, selinux,
namespaces, pick your worst)
systemd supports the latter more or less natively, but does not support
Docker (or OCI) images and manifests out of the box. All the work
systemd-docker is doing is trying to bridge that gap, with Docker.
What if there would be a (better, simpler) way of doing this (almost)
without Docker?
I've found this inspiring post that tries to run Docker container using
`systemd-nspawn` instead of Docker:
https://seanmcgary.com/posts/run-docker-containers-with-systemd-nspawn/
The basic approach is similar to systemd-docker: hijack the pre/post
hooks to do magic things. Example:
ExecStartPre=/bin/bash -c 'docker pull quay.io/seanmcgary/nspawn-test:latest || true'
ExecStartPre=/bin/bash -c 'mkdir /home/core/containers/nspawntest_new || true'
ExecStartPre=/bin/bash -c 'docker export "$(docker create --name nspawntest quay.io/seanmcgary/nspawn-test true)" | tar -x -C /home/core/containers/nspawntest_new'
ExecStartPre=/bin/bash -c 'docker rm nspawntest || true'
ExecStartPre=/bin/bash -c 'mv /home/core/containers/nspawntest_new /home/core/containers/nspawntest_running'
ExecStart=/bin/bash -c 'sudo systemd-nspawn --machine nspawntest --directory /home/core/containers/nspawntest_running /run.sh'
ExecStop=/bin/bash -c 'sudo machinectl terminate nspawntest'
Now there's way too much bash -c in there for me to be happy, but I like
the idea. I can't help but think that `docker pull` could be replaced by
[Skopeo][] and [docker export][] replaced by ... something?
In any case, I wouldn't advise using the autistici packages for now, as
all dependencies are vendored inside the package which means they might
not be updated as regularly as we might expect.
A.
PS: This is one of those days where when I look for answers to a problem
I find a very detailed article full of wit and wisdom but not quite any
answers, written by myself a year ago:
https://anarc.at/blog/2017-12-20-docker-without-docker/
yaaay.... thanks for nothing, past anarcat!
--
We are discreet sheep; we wait to see how the drove is going, and then go
with the drove.
- Mark Twain
Reply to: