Skip to content
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

Integrate the container's systemd with the host's systemd #48

Open
basvandijk opened this issue May 9, 2019 · 5 comments
Open

Integrate the container's systemd with the host's systemd #48

basvandijk opened this issue May 9, 2019 · 5 comments

Comments

@basvandijk
Copy link

It would be nice to have a deep integration between the host's and containter's systemd such that the host's systemd recognises the docker containers:

machinectl
 MACHINE                          CLASS     SERVICE
 9aa1f884bdae630ecaee76c0ca85441f container docker
 cb7c2ddeba36e450d4214f51a8529e18 container docker

And we can see the container's logs on the host using:

journalctl --machine <container_id>

To implement this we could consider the tricks that RedHat pulled off to run systemd inside unprivileged docker containers.

In particular they used runc hooks to register the container with machinectl on the host and another hook (oci-systemd-hook) that does a bunch of things including mounting /var/log/journal into the container so that the journal entries from inside the container are visible on the host using.

@roberth
Copy link
Member

roberth commented May 9, 2019

That would be nice indeed. It seems to have both host and container parts. Systemd already runs in the container. The host is not really part of arion's scope. I suppose someone has to try it and see if arion needs to do anything extra :)

@basvandijk
Copy link
Author

It seems a long debate has been going on from at least 2015 between RedHat and Docker trying to get a better integration between systemd and docker. The last remaining missing feature in docker is support for hooks which allow a program to be called at container startup like oci-register-machine and oci-systemd-hook to integrate the container with the host's systemd.

The progress on this, or better said: the lack of progress, is documented in moby/moby#36987.

@roberth
Copy link
Member

roberth commented May 31, 2021

With #117, arion becomes compatible with the podman runtime and since NixOS/nixpkgs#123841 (not backported to 21.05 yet) you can use podman as an implementation of the docker socket. Perhaps this combination achieves what you want.

It seems a long debate has been going on from at least 2015 between RedHat and Docker trying to get a better integration between systemd and docker.

This seems to have gotten worse. Since cgroupsv2, systemd won't run in docker anymore. Docker is not the best runtime (coordinator?) for arion at this point.

@roberth
Copy link
Member

roberth commented Oct 28, 2021

Tangentially related to #140, for those who are interested in adding arion projects immutably to a NixOS system as part of its configuration.

@deliciouslytyped
Copy link

Regarding docker, this may be related/viable: https://github.com/awslabs/oci-add-hooks

Sidenote, #117 is not strictly necessary for using podman due to podman's drop-in compatibility design goal.
I run with this overlay:

  overlay = (self: super: {
    docker-compose-compat =
      (self.runCommand "podman-compose-docker-compat" {} ''
        mkdir -p $out/bin
        ln -s ${self.podman-compose}/bin/podman-compose $out/bin/docker-compose
        '');

    #the arion nixpkgs expression embeds a reference to docker-compose_1 and uses it via PATH
    arion = (super.arion.overrideAttrs (o: {
      postInstall = ''
        mkdir -p $out/libexec
        mv $out/bin/arion $out/libexec
        makeWrapper $out/libexec/arion $out/bin/arion \
          --unset PYTHONPATH \
          --prefix PATH : ${self.lib.makeBinPath [ self.docker-compose-compat ]} \
          ;
        '';
      }));
    });

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants