-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
NixOS: Run Docker containers as declarative systemd services #55179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This pull request has been mentioned on Nix community. There might be relevant details there: https://discourse.nixos.org/t/deploying-docker-containers-declaratively/693/9 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to add a test for this module also.
I absolutely will add tests for this stuff. |
Is it too complicated for this PR to address mapping ports as well? Would this require |
It wouldn't be too hard to handle mapping ports here, as long as we don't try to cover all possible networking setups. I'll have a go at adding it. |
(and no, I don't believe this will require interacting with |
I've added support for publishing ports, setting environment variables, and overriding |
This comment has been minimized.
This comment has been minimized.
Looking forward to using this! I think it would be worthwhile to take a look at this repository: https://github.com/ibuildthecloud/systemd-docker as well as the linked discussions moby/moby#6791 and https://groups.google.com/forum/#!topic/coreos-dev/wf7G6rA7Bf4/discussion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good to me now (I haven't tested anything though)
Tested. Seems to work well and respond as expected to configuration.nix changes. There are some nuances to deal with like obtaining images (preloader seems difficult to setup), using hostnames or /etc/hosts in containers to avoid hard-coding IPs. Overall, good work! This can serve as a band-aid to deploy applications that are only feasible to run as upstream-provided docker images (or are difficult to port, eg: i got onlyoffice to work with nextcloud using docker-containers). |
thanks all! |
Woot! |
Just checking, but did anyone (@benley, @danbst) take a look at the link I posted: https://github.com/ibuildthecloud/systemd-docker as well as the linked discussions moby/moby#6791 and https://groups.google.com/forum/#!topic/coreos-dev/wf7G6rA7Bf4/discussion It's not really my area, but I couldn't see any handling of this edge case in this PR
|
Le 11 avril 2019 09:39:06 GMT+02:00, Joe Hermaszewski <notifications@github.com> a écrit :
Just checking, but did anyone ***@***.***, @danbst) take a look at the
link I posted: https://github.com/ibuildthecloud/systemd-docker as well
as the linked discussions moby/moby#6791 and
https://groups.google.com/forum/#!topic/coreos-dev/wf7G6rA7Bf4/discussion
It's not really my area, but I couldn't see any handling of this edge
case in this PR
>The short of it is that systemd does not actually supervise the Docker
container but instead the Docker client. This makes systemd incapable
of reliably managing Docker containers without hitting a bunch of
really odd situations.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#55179 (comment)
If you want to avoid ugly unit files you can use a daemon-less container runtime like rkt or podman. I would be more in favor of podman as it should be compatible with all docker CLI flags and is more active than rkt.
Daemon-less mean the CLI is forking as the container so if you kill it for example you kill the container.
--
Paul TREHIOU
|
Yes, I studied these cases extensively as I was putting this together. The way this is implemented in NixOS, systemd does not attempt to own the container or the processes within it. Instead, it just asks docker to run a thing, keeps it in the foreground, and if the container exits then systemd will know because the I would love to swap out the implementation at some point to avoid using the Docker daemon, using runc or podman or something like those, and I did try to build this in a way that would make that possible. |
@benley great, thanks! |
…5179) * WIP: Run Docker containers as declarative systemd services * PR feedback round 1 * docker-containers: add environment, ports, user, workdir options * docker-containers: log-driver, string->str, line wrapping * ExecStart instead of script wrapper, %n for container name * PR feedback: better description and example formatting * Fix docbook formatting (oops) * Use a list of strings for ports, expand documentation * docker-continers: add a simple nixos test * waitUntilSucceeds to avoid potential weird async issues * Don't enable docker daemon unless we actually need it * PR feedback: leave ExecReload undefined (cherry picked from commit c940053)
…5179) * WIP: Run Docker containers as declarative systemd services * PR feedback round 1 * docker-containers: add environment, ports, user, workdir options * docker-containers: log-driver, string->str, line wrapping * ExecStart instead of script wrapper, %n for container name * PR feedback: better description and example formatting * Fix docbook formatting (oops) * Use a list of strings for ports, expand documentation * docker-continers: add a simple nixos test * waitUntilSucceeds to avoid potential weird async issues * Don't enable docker daemon unless we actually need it * PR feedback: leave ExecReload undefined (cherry picked from commit c940053)
Is there any documentation for this? Figured it out: Here is an example:
And then the usual systemd interface:
|
@chrissound You should consider putting that in the nixos manual. |
https://search.nixos.org/options?channel=20.09&from=0&size=30&sort=relevance&query=oci-containers |
Motivation for this change
https://discourse.nixos.org/t/deploying-docker-containers-declaratively/693
#37553 #26075
Related to #26075 but the implementation is less general; this one just offers an interface to run containers as systemd units from pre-existing Docker images.
cc @copumpkin
TODO: