Architecting Process Management: The Technical Divergence and Integration of Docker and Systemd

The modern landscape of application deployment is often defined by the tension between isolation and integration. At the heart of this architectural divide lie two fundamentally different approaches to process management: Docker and Systemd. While both are designed to ensure that an application runs, remains stable, and restarts upon failure, they operate at different layers of the computing stack. Docker provides a containerized abstraction, treating the application and its entire user-space environment as a single, portable artifact. Systemd, conversely, acts as the foundational init system for Linux, managing the boot process and the lifecycle of services directly on the host operating system.

Understanding the intersection of these two technologies is critical for DevOps engineers and system administrators. The goal is often to achieve a balance between the portability and agility of containers and the granular control and deep system integration provided by a native init system. When these two worlds collide—such as attempting to run Systemd inside a Docker container—complexities regarding cgroups, privileged modes, and the "one process per container" philosophy emerge. This exploration delves into the mechanics of both systems, the practicalities of deploying applications like Pocketbase using both methods, and the advanced configurations required to bridge the gap between containerization and system-level process management.

Conceptual Framework of Docker and Systemd

To understand why a choice must be made between these two technologies, one must first examine their core identities and operational goals.

Docker is a comprehensive platform designed for the creation, execution, and management of containers. In technical terms, a container is not a virtual machine; it does not emulate hardware or run a separate kernel. Instead, Docker leverages Linux kernel features—such as namespaces and control groups (cgroups)—to create a sandboxed environment. This isolation ensures that an application and its specific dependencies are bundled together, mimicking a virtual machine's consistency without the heavy resource overhead of a full Guest OS. The primary value proposition of Docker is environmental consistency: an image that runs on a developer's laptop will run identically on a production server.

Systemd is the standard init system and process manager for a vast majority of modern Linux distributions. As the first process that starts (PID 1), it is responsible for bootstrapping the entire user space. Its role extends beyond simple process launching; it manages service dependencies (ensuring a database starts before a web server), handles logging via journald, and monitors resource allocation. Unlike Docker, which isolates the process from the host, Systemd integrates the process into the host's lifecycle. It is the mechanism that ensures a service is automatically started after a hardware reboot.

The following table delineates the fundamental differences between these two management paradigms:

Deployment Analysis: The Pocketbase Case Study

The practical difference between these two approaches is best illustrated through the deployment of Pocketbase, a lightweight backend server.

Implementation via Docker

When deploying Pocketbase using Docker, the application is encapsulated. This means the binary and its required environment are pulled from a registry and executed in an isolated slice of the host's kernel.

To execute this, the following command is used:

docker run -d -p 8090:8090 -v ~/pocketbase_data:/pocketbase pocketbase/pocketbase

This command triggers several technical layers of configuration:

• The -d flag initiates the container in detached mode. This allows the process to run in the background, freeing the terminal while the Docker daemon manages the container's lifecycle.
• The -p 8090:8090 flag manages network mapping. Because containers are isolated by their own network namespace, the host's port 8090 must be explicitly mapped to the container's port 8090 to allow external traffic to reach the application.
• The -v ~/pocketbase_data:/pocketbase flag creates a bind mount. Since Docker containers are ephemeral (data is lost when the container is deleted), this mounts a local directory from the host into the container. This ensures that the database and uploaded files of Pocketbase persist across restarts.
• The pocketbase/pocketbase argument specifies the image, ensuring that the exact version of the software and its dependencies are used regardless of the host OS.

The impact of this approach is a streamlined setup. The user does not need to worry about whether the host has the correct libraries or environment variables; the image provides everything.

Implementation via Systemd

Running Pocketbase as a native service involves integrating the binary directly into the host's process tree. This requires the creation of a unit file, typically located at /etc/systemd/system/pocketbase.service.

The configuration file is structured as follows:

```ini
[Unit]
Description=Pocketbase Application
After=network.target

[Service]
ExecStart=/usr/local/bin/pocketbase serve --http=0.0.0.0:8090
WorkingDirectory=/home/yourusername/pocketbase
Restart=always
User=yourusername
Group=yourgroup

[Install]
WantedBy=multi-user.target
```

The technical layers of this configuration include:

• The After=network.target directive ensures that the application does not attempt to start until the network stack is initialized, preventing startup failures.
• The ExecStart directive points to the exact location of the binary and passes the necessary flags to bind the server to all available network interfaces on port 8090.
• The WorkingDirectory directive is critical because it tells the process where to look for its data files and configuration, mapping the execution context to a specific path on the host disk.
• The Restart=always policy instructs the kernel to automatically revive the process if it crashes, providing a level of resilience similar to Docker's restart policies.
• The User and Group settings enforce the principle of least privilege, ensuring the application does not run as root.

To activate this service, the administrator must execute the following sequence:

sudo systemctl daemon-reload
sudo systemctl start pocketbase
sudo systemctl enable pocketbase

This method provides deeper integration. The process is managed by the host's native tools, allowing for more granular control over resource allocation and logging via the system journal.

Comparative Analysis of Performance and Management

The choice between Docker and Systemd is not merely technical but strategic, based on the specific requirements of the deployment environment.

Ease of Setup and Portability

Docker wins in terms of speed and portability. Because the environment is defined in an image, the "it works on my machine" problem is eliminated. The setup is streamlined, and the application can be moved from an Ubuntu server to a CentOS server without changing the configuration. Systemd requires a more manual approach, involving the creation of service files and the manual installation of dependencies on the host.

Isolation and Conflict Resolution

Docker provides full isolation. If an application requires a specific version of a library that conflicts with the host's version, Docker solves this by providing a separate user space. Systemd runs the application directly on the host. While this allows for better performance, it increases the risk of dependency hell, where two different services require different versions of the same system library.

Management and Monitoring

Docker simplifies management through a unified API. Scaling an application involves launching more containers. Monitoring is handled via docker logs or integrated container orchestration tools. Systemd provides a more traditional but powerful set of tools. Using systemctl status provides immediate insight into the process's health, and journalctl allows for deep inspection of system logs.

Performance Considerations

There is a negligible performance overhead associated with Docker due to the containerization layer. For most applications, this is unnoticeable. However, for high-performance, long-running processes that require direct hardware access or extremely low latency, Systemd is superior because it eliminates the abstraction layer entirely and runs the process natively on the host system.

The Paradox of Systemd inside Docker

A common point of confusion and technical failure occurs when users attempt to run Systemd as the primary process inside a Docker container. This is fundamentally contrary to the Docker philosophy, which dictates that a container should be a single process.

The "One Process Per Container" Philosophy

In standard container architecture, the ENTRYPOINT or CMD of a Dockerfile defines the main process of the container. If that process exits, the container stops. Systemd is designed to be PID 1, the ancestor of all other processes. When Systemd is placed inside a container, it attempts to manage other services, but it often fails because it lacks the necessary permissions to interact with the host's kernel and cgroups.

For instance, users attempting to use systemctl enable ServiceName inside a container often find that the service does not start automatically upon container reboot. This is because the container's lifecycle is managed by the Docker daemon, not by the internal Systemd instance.

Technical Requirements for Systemd Containers

Despite the philosophical opposition, there are cases where a base image specifically designed for Systemd is required. The centos/systemd image is an example of such a base. To successfully run Systemd inside a container, specific privileges and mounts are required to allow the init system to manage cgroups.

A sample Dockerfile for an Apache (httpd) service using Systemd would look like this:

dockerfile FROM centos/systemd MAINTAINER "Your Name" <[email protected]> RUN yum -y install httpd; yum clean all; systemctl enable httpd.service EXPOSE 80 CMD ["/usr/sbin/init"]

To launch this container, the standard docker run command is insufficient. It requires the --privileged flag and a specific mount for the cgroup filesystem:

docker run --privileged --name httpd -v /sys/fs/cgroup:/sys/fs/cgroup:ro -p 80:80 -d httpd

The technical reasons for these requirements are:

• The --privileged flag grants the container access to the host's kernel features, which Systemd requires to manage processes.
• The -v /sys/fs/cgroup:/sys/fs/cgroup:ro mount allows Systemd to see the control group hierarchy, which is essential for tracking and limiting resource usage of the services it manages.
• The CMD ["/usr/sbin/init"] ensures that the init process starts as PID 1, allowing it to spawn other services like httpd.

Conclusion: Architectural Decision Analysis

The decision to use Docker versus Systemd—or the complex attempt to nest Systemd within Docker—depends on the specific operational goals of the deployment.

If the priority is rapid deployment, portability across different cloud providers, and strict isolation from the host environment, Docker is the undisputed choice. It transforms the application into a portable commodity that can be versioned and rolled back with ease. The trade-off is a slight increase in overhead and a layer of abstraction that can make deep kernel debugging more difficult.

If the priority is maximum performance, deep integration with host hardware, and the use of standard Linux administration tools, Systemd is the correct approach. It allows the application to behave as a native part of the operating system, benefiting from the host's optimized resource management and boot sequence.

The attempt to run Systemd inside Docker is generally an anti-pattern. The conflict arises from the fact that Systemd expects to own the system, while Docker expects to own the process. When users struggle with services not starting automatically in containers (such as the pgagent in a PostgreSQL replication setup), the solution is usually to move the service logic into the Docker ENTRYPOINT script rather than attempting to install a full init system inside a sandboxed environment.

Ultimately, the modern DevOps path favors the "one container per service" model. Rather than using Systemd to manage multiple services inside one container, the architectural standard is to deploy multiple containers—each running a single process—and orchestrate them using tools that provide the same lifecycle management and dependency resolution that Systemd provides at the host level.

Sources

1. Systemd vs Docker: Exploring a Surprising Alternative
2. CentOS Systemd Docker Hub
3. How to run systemd inside a docker container - Docker Forums