Running Rocky Linux with systemd inside a Docker container requires some specific considerations because Docker’s default process management is different from a traditional operating system. Docker typically expects a single foreground process to be the container’s main entry point. However, systemd is a suite of system management daemons, including the init system that manages all other processes.

Method 1: Using a Custom Dockerfile with systemd as the Entrypoint

This involves creating a custom Docker image based on Rocky Linux and configuring systemd to be the primary process.

1. Create a Dockerfile:

Dockerfile.systemd

FROM rockylinux/rockylinux:9

# Install necessary packages for systemd
RUN yum -y update && \
    yum -y install systemd systemd-sysv initscripts

# Create a systemd directory
RUN mkdir -p /run/systemd/system

# Define the entrypoint to be systemd
ENTRYPOINT ["/sbin/init"]

# Optional: Expose any ports your services might need
# EXPOSE 80
# EXPOSE 22

# Optional: Define volumes for persistent data
# VOLUME /var/lib/mysql

Explanation:

  • FROM rockylinux/rockylinux:9: Starts with the official Rocky Linux 9 image.
  • RUN yum -y update && yum -y install systemd systemd-sysv initscripts: Installs the systemd, systemd-sysv (for compatibility with SysVinit scripts), and initscripts packages.
  • RUN mkdir -p /run/systemd/system: Creates the necessary directory for systemd unit files.
  • ENTRYPOINT ["/sbin/init"]: Sets /sbin/init (which is usually a symlink to systemd) as the main process to run when the container starts.
  • EXPOSE: (Optional) Specifies the ports your services within the container will listen on.
  • VOLUME: (Optional) Defines mount points for persistent data.

2. Build the Docker Image:

Save the Dockerfile (e.g., as Dockerfile.systemd) and build the image:

docker build -t rocky-systemd -f Dockerfile.systemd .

3. Run the Docker Container:

Now you can run the image:

docker run --privileged -d --name rocky-systemd-container rocky-systemd
  • --privileged: This flag is often necessary for systemd to function correctly within a container. It grants the container extended privileges on the host. Use this flag with caution as it can have security implications.
  • -d: Runs the container in detached mode (in the background).
  • --name rocky-systemd-container: Assigns a name to the container.
  • rocky-systemd: The name of the image you built.

4. Interact with the Container:

You can now use docker exec to run commands inside the container:

docker exec -it rocky-systemd-container bash

You should be able to interact with the systemd environment within the container. For example, you can try to start and stop services (if you’ve installed any).

Method 2: Using a Specialized Base Image (Less Common for Rocky Linux)

Some specialized Docker base images are designed to run systemd or init systems. However, for standard distributions like Rocky Linux, the custom Dockerfile approach is more common.

Important Considerations and Potential Issues:

  • Privileged Mode (--privileged): Granting --privileged can weaken the isolation between the container and the host system. Carefully consider the security implications before using it in production environments.
  • cgroup Version: Ensure your Docker host is using cgroup v1. systemd in containers traditionally works better with cgroup v1. Docker has been transitioning to cgroup v2, which might require additional configuration or compatibility layers.
  • Resource Management: Managing resources (CPU, memory) for individual services managed by systemd within the container can be more complex than relying on Docker’s built-in resource management.
  • Complexity: Running a full init system inside a container adds complexity and can deviate from the typical “one process per container” philosophy of Docker. This can make debugging and management more challenging.
  • Alternative Approaches: Before going down the systemd route, consider if you can achieve your goals using Docker’s native process management. You might be able to run individual services in separate containers and use Docker Compose to manage them.

When might you need systemd in a Docker container?

  • Running applications that heavily rely on systemd for process management.
  • Migrating legacy systems that are tightly integrated with systemd without significant modification.
  • Testing system-level configurations that involve systemd units.
  • In most modern Docker workflows, it’s often preferred to run individual services as isolated processes within separate containers, managed by Docker. However, if you have specific requirements that necessitate running systemd, the custom Dockerfile approach with the --privileged flag (used with caution) is a common method.