#233 Container guidelines for systemd based containers
Closed 2 years ago Opened 3 years ago by jhogarth.

Some containers are better run with systemd as init.

This really then has a requirement on the host having oci-systemd-hook which is not present in Debian and cannot be relied on for certain cloud services.

Should we have a guideline forbidding this and mandating an entrypoint of a suitable reaper and script to run the services, or should we permit this and have a way to document a systemd capable container host as a requirement?

This seems particularly important in environments where zombie risks are high (eg php workers) and as a result for the owncloud container with mod_php the preference would be a systemd based container, but we could work around this if required.


Metadata Update from @dustymabe:
- Issue tagged with: containers

3 years ago

You can run systemd containers without oci-systemd-hook, it is just a helper app that completes the solution. Sadly upstream docker has rejected all efforts to support this type of containers.

You can run a systemd container by simply executing a docker run like the following

docker run -d --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup IMAGE

BTW Even if we got oci-systemd-hook into debian, we would still need to get projectatomic/docker in since docker rejected the patch to run hooks directly.

There are some benefits to running your apps in containers that use systemd as init. Such as logging / journald. I think it might help to lay out some of those benefits. That would enable the application developer to determine, that, in the event their app doesn't run under systemd whether it's worth the effort to port. Should they decide to use systemd, it would be nice to have clear directions on how to enable that.

BTW Even if we got oci-systemd-hook into debian, we would still need to get projectatomic/docker in since docker rejected the patch to run hooks directly.

Would it help if the execution of the hook was dependent on some label in the image? That way the container author could have more control over the behaviour and docker might be more inclined to allow that mechanism.

Not sure here is the best place, but I would start by saying

  1. Easily move applications from VM to container, using standard scripts. IE
    FROM fedora-init
    RUN dnf -y install httpd; systemctl enable httpd
    ADD MYPHP /var/www/html
    ...
  2. Proper Logging. Journalctl and syslog actually work
  3. Cleaning up Zombies
  4. Multi Service containers.
  5. Other systemd features like checking status, eventually additional cgroup (Requires CGROUPV2)

Metadata Update from @jberkus:
- Issue tagged with: VFAD

3 years ago

Metadata Update from @jberkus:
- Issue untagged with: VFAD
- Issue set to the milestone: 2017-03-10 VFAD

3 years ago

Just a quick note to verify the Dockerfile for the owncloud container review does indeed run with no oci-systemd-hook and using:

docker run -d -t -P --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup --name owncloud-test owncloud

Update from VFAD:

systemd images (images where PID1 is systemd) are permitted, if the complexity of the container makes it a good idea.

@jasonbrooks Dan Walsh to update guidelines, provide HOWTO.

Metadata Update from @jberkus:
- Issue assigned to jasonbrooks

3 years ago

How does this look?

@dwalsh

=== systemd-Based Containers ===

A systemd-based container includes the systemd system and service manager as part of its image in order to run one or more systemd-managed services within a single container, to take advantage of systemd's zombie-reaping capabilities, or to better handle container logging.

systemd-based containers' Dockerfiles have the following differences:

==== LABELS ====

Run/Usage: systemd-based containers should include a Run or Usage label that directs users to include "--tmpfs /run", "--tmpfs /tmp", and "-v /sys/fs/cgroup:/sys/fs/cgroup", which systemd requires to run. Container hosts running the default Fedora docker package and the oci-systemd-hook don't require these run options, but they should be included for compatibility with other container hosts.

For example:

LABEL Usage="docker run -d -P --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup -v owncloud-data:/var/lib/owncloud -v owncloud-config:/etc/owncloud owncloud"

==== CMD/ENTRYPOINT ====

systemd-based containers must include "/sbin/init" as an ENTRYPOINT or CMD, which will start systemd inside the container at run time. systemd will start up and manage services enabled with the Dockerfile using the standard "systemctl enable foo" commands in RUN statements.

For example:

FROM fedora:25
ENV container=oci

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

EXPOSE 80
CMD [ "/sbin/init" ]

It would be easier to deal with this in a google doc or an etherpad...

=== systemd-Based Containers ===

A systemd-based container runs systemd(/usr/bin/init) by default as its entrypoint. One or more services are configured using unit files, the say way they would be on a physical system or a virtual machine.

Systemd based containers have some advantages over running a service directly as the entrypoint (pid 1)
Support for multi service containers.
Support for unit file mechanism for starting the container.
Ability to reap zombie processes.
Population of /tmp with content needed to be run by a service
Proper handling of syslog messages
Proper handling of journalctl messages

Issues with systemd based containers.

STDOUT/STDERR of the container does not come back though the container runtime logging system.
systemd adds some requirements on the mechanism that containers are run.

  • systemd requires that a tmpfs be mounted at /run.
  • systemd requires that /sys/fs/cgroup be available inside of the container
  • systemd requires that the signal to stop the container is SIGRTMIN+3
  • systemd likes if /tmp is a tmpfs.

For more information on systemd in a container read this link.

https://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container/

Installing the oci-systemd-hook and oci-register-machine package, takes care or most of the setup for running a systemd container, with the docker package shipped in Fedora.

==== LABELS ====

If you do not want to use oci-systemd-hook and oci-register-machine packages you can still run systemd based containers, by executing a command like:

docker run -d -P --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup SYSTEMDIMAGE

Note: Log files will not appear on the host, since not using oci-systemd-hook and oci-register-machine, there is no way to have the logs available outside of the container.

You can set up labels inside of your image, if you would like to have this done automatically using the atomic command.

Run/Usage: systemd-based containers should include a Run or Usage label that directs users to include "--tmpfs /run", "--tmpfs /tmp", and "-v /sys/fs/cgroup:/sys/fs/cgroup", which systemd requires to run. Container hosts running the default Fedora docker package and the oci-systemd-hook don't require these run options, but they should be included for compatibility with other container hosts.

For example:

LABEL Usage="docker run -d -P --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup -v owncloud-data:/var/lib/owncloud -v owncloud-config:/etc/owncloud owncloud"

==== CMD/ENTRYPOINT ====

systemd-based containers must include "/sbin/init" as an ENTRYPOINT or CMD, which will start systemd inside the container at run time. systemd will start up and manage services enabled with the Dockerfile using the standard "systemctl enable foo" commands in RUN statements.

For example:

FROM fedora:25
ENV container=oci

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

STOPSIGNAL SIGRTMIN+3

EXPOSE 80
CMD [ "/sbin/init" ]

Fedora now also provides a base-init container called fedora-init. This image is setup to running systemd containers by default. This means your Dockerfile could be as simple as

LABEL Usage="docker run -d -P --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup -v owncloud-data:/var/lib/owncloud -v owncloud-config:/etc/owncloud owncloud"

==== CMD/ENTRYPOINT ====

systemd-based containers must include "/sbin/init" as an ENTRYPOINT or CMD, which will start systemd inside the container at run time. systemd will start up and manage services enabled with the Dockerfile using the standard "systemctl enable foo" commands in RUN statements.

For example:

FROM fedora-init:25
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

I made some edits (I made them in a google doc and sent you the link if you want that):

=== systemd-Based Containers ===

A systemd-based container runs systemd(/usr/bin/init) by default as its entrypoint. One or more services are configured using unit files, the say way they would be on a physical system or a virtual machine.

systemd based containers have some advantages over running a service directly as the entrypoint (pid 1):

Support for multi service containers.
Support for unit file mechanism for starting the container.
Ability to reap zombie processes.
Population of /tmp with content needed to be run by a service
Proper handling of syslog messages
Proper handling of journalctl messages

==== Issues with systemd based containers ====

STDOUT/STDERR of the container does not come back though the container runtime logging system. systemd adds some requirements on the mechanism that containers are run:

systemd requires that a tmpfs be mounted at /run.
systemd requires that /sys/fs/cgroup be available inside of the container
systemd requires that the signal to stop the container is SIGRTMIN+3
systemd likes if /tmp is a tmpfs.

For more information on systemd in a container read this link.
https://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container/

==== LABELS ====

Run/Usage: Installing the oci-systemd-hook and oci-register-machine packages alongside the docker packaged shipped in Fedora takes care of most of the setup for running a systemd container. However, in order to provide compatibility with other container hosts, systemd-based containers should include a Run or Usage label that directs users to include the "--tmpfs /run", "--tmpfs /tmp", and "-v /sys/fs/cgroup:/sys/fs/cgroup" that systemd requires to run.

For example:


LABEL Usage="docker run -d -P --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup SYSTEMDIMAGE"

Note: On a container host without oci-systemd-hook and oci-register-machine, log files will not appear on the host, since there’ll be no way to make the logs available outside of the container.

==== CMD/ENTRYPOINT ====

systemd-based containers must include "/sbin/init" as an ENTRYPOINT or CMD, which will start systemd inside the container at run time. systemd will start up and manage services enabled with the Dockerfile using the standard "systemctl enable foo" commands in RUN statements.

For example:


FROM fedora:25
ENV container=oci
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
STOPSIGNAL SIGRTMIN+3
EXPOSE 80
CMD [ "/sbin/init" ]

Fedora now also provides a base-init container called fedora-init. This image is setup to running systemd containers by default. This means your Dockerfile could be as simple as

FROM fedora-init:25
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80

Metadata Update from @jberkus:
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata