Systemd.service statt Docker? Ein neuer Blick auf die Bereitstellung von Webanwendungen unter Linux

In den letzten Jahren hat sich die Formel „Bereitstellung = Docker + Container‑Orchestrierung (Kubernetes, ECS usw.)“ fast zu einer Selbstverständlichkeit entwickelt. Deshalb wirkt die klassische Variante, eine Webanwendung einfach als Prozess + systemd‑Service auf einem Linux‑Server zu betreiben, manchmal veraltet.

In der Praxis ist das jedoch nicht immer so. Für

  • eine einzelne Webanwendung
  • ein kleines Team / einfache Infrastruktur
  • On‑Premise‑ oder stark regulierte Umgebungen

kann die Bereitstellung über systemd oft die einfachere, stabilere und betriebsfreundlichere Wahl sein.

In diesem Beitrag schauen wir uns an, welche Vorteile systemd gegenüber Docker bietet und in welchen Situationen ein systemd‑basierter Ansatz besonders hilfreich ist.

1. Systemd und Docker kurz erklärt

Commandbox 광고

Kurz gefasst:

  • Docker
  • Packt die Anwendung in ein Image
  • Läuft als Container

  • Stärken: komplette Umgebung kapseln → überall gleich

  • systemd

  • Standard‑Init‑System moderner Linux‑Distributionen
  • Startet Dienste beim Booten, startet sie neu, verwaltet Logs
  • Definiert Prozesse über *.service‑Unit‑Dateien

Docker kapselt die Anwendungsumgebung, systemd verwaltet Prozesse unter Linux. Sie konkurrieren nicht, sondern ergänzen sich häufig – z. B. systemd startet den Docker‑Daemon oder läuft innerhalb eines Containers.

Hier konzentrieren wir uns jedoch auf den Fall, keinen Docker‑Container zu verwenden und die Anwendung ausschließlich über systemd zu betreiben.

2. Vorteile von systemd statt Docker

2‑1. Einfachheit: Ein Layer weniger

Mit Docker kommen zusätzliche Komponenten hinzu:

  • Docker‑Daemon
  • Image‑Build‑Pipeline
  • Registry
  • Container‑Runtime‑Berechtigungen

systemd‑basierte Bereitstellung ist dagegen:

  • Installiere die benötigten Laufzeitumgebungen (Python/Node/Java usw.)
  • Deploye den Anwendungscode
  • Registriere einen systemd‑Service

Das Ergebnis ist ein relativ schlankes Setup. Für kleine Projekte oder interne Dienste kann das „Image‑Build → Push → Pull → Redeploy“‑Verfahren sogar mehr Aufwand bedeuten als ein einfacher git pull + systemctl restart.

2‑2. Natürliche Integration mit Linux

systemd ist tief im Betriebssystem verankert und bietet:

  • Logs – journalctl -u myapp.service
  • Automatischer Start beim Booten – systemctl enable myapp.service
  • Ressourcen‑Limits – MemoryMax, CPUQuota
  • Abhängigkeits‑Management – After=network.target, After=postgresql.service

Bei Docker muss man zwischen Container‑ und Host‑Logs, Ressourcen und Netzwerken unterscheiden. Für ein oder zwei Web‑Services ist die direkte systemd‑Verbindung oft intuitiver.

2‑3. Geringerer Ressourcen‑Overhead

Docker selbst verursacht nicht viel Overhead, aber zusätzlich:

  • Mehrere Image‑Layer → mehr Speicher
  • Unbenutzte Container
  • Separate Log‑ und Volume‑Verwaltung

systemd‑Deployment benötigt lediglich OS + Laufzeit + Anwendungscode. In ressourcenbeschränkten Umgebungen (z. B. kleine VMs, Embedded‑Server) ist das deutlich schlanker.

2‑4. Intuitive Netzwerk‑Struktur

Mit Docker muss man sich mit:

  • Container‑IP und Ports
  • Port‑Mapping
  • Bridge‑/Overlay‑Netzwerken

verstehen. systemd bindet direkt an die Host‑IP/Port, Firewall‑Regeln gelten host‑weit. Das vereinfacht Netzwerk‑Debugging erheblich.

2‑5. Docker kann in manchen Umgebungen nicht eingesetzt werden

  • Finanz-, öffentliche oder medizinische On‑Premise‑Umgebungen
  • Richtlinien, die Container‑Runtime verbieten
  • Netzwerke ohne Internetzugang, sodass externe Registries nicht erreichbar sind

In solchen Fällen ist die einzige praktikable Option OS + systemd. Mit gutem Verständnis von systemd lassen sich automatische Neustarts, Log‑Management, Ressourcen‑Limits und sogar rudimentäre Health‑Checks realisieren.

3. Beispiel: Web‑Anwendung mit systemd.deployen

Commandbox 광고

Angenommen, wir betreiben eine Django/Flask‑App mit Gunicorn.

3‑1. Unit‑Datei

/etc/systemd/system/myapp.service:

[Unit]
Description=My Web Application (Gunicorn)
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/srv/myapp
EnvironmentFile=/etc/myapp.env
ExecStart=/usr/bin/gunicorn \
    --workers 4 \
    --bind 0.0.0.0:8000 \
    config.wsgi:application

Restart=on-failure
RestartSec=5

# Optional: Ressourcen‑Limits
# MemoryMax=512M
# CPUQuota=50%

[Install]
WantedBy=multi-user.target

Umgebungsvariablen in /etc/myapp.env:

DJANGO_SETTINGS_MODULE=config.settings.prod
SECRET_KEY=super-secret-key
DATABASE_URL=postgres://...

3‑2. Befehle

# Service registrieren & beim Booten starten
sudo systemctl enable myapp.service

# Starten / Stoppen / Neustarten
sudo systemctl start myapp.service
sudo systemctl restart myapp.service
sudo systemctl stop myapp.service

# Status & Logs
sudo systemctl status myapp.service
sudo journalctl -u myapp.service -f

Für ein Team, das bereits mit Linux‑Servern vertraut ist, ist das ein sofort einsatzbereites Setup.

4. Wann ist systemd besser als Docker?

Zusammengefasst gilt:

4‑1. Einfache, kleine Services ohne komplexe Orchestrierung

  • 1–2 Web‑Apps
  • Managed DB (z. B. RDS)
  • Wenige Server (1–5)

In solchen Fällen überwiegt der Aufwand für Docker + Orchestrierung.

4‑2. Teams, die bereits mit Linux‑Servern vertraut sind

  • Bestehende Systeme laufen auf systemd
  • Betriebspersonal kennt systemctl, journalctl, rsyslog

Ein zusätzlicher Layer (Docker) ist oft unnötig.

4‑3. Regulatorisch eingeschränkte Umgebungen

  • Finanz-, öffentliche, medizinische, militärische Systeme
  • Geschlossene Netzwerke

Docker kann hier ein Risiko darstellen.

4‑4. Debugging & Performance‑Analyse

  • Direkter Zugriff auf strace, perf, /proc
  • Keine zusätzliche Container‑Schicht

4‑5. Ressourcen‑beschränkte Hardware

  • Embedded‑Server, kleine VMs
  • Geringer Speicher/CPU

5. Docker hat ebenfalls klare Vorteile

Natürlich gibt es auch Szenarien, in denen Docker die bessere Wahl ist:

  • Einheitliche Umgebung von Entwicklung bis Produktion
  • CI/CD‑Integration
  • Multi‑Service‑Setups (Web + Worker + Cron + DB)
  • Mehrere Server/Umgebungen mit identischem Stack

Die Entscheidung hängt letztlich davon ab, welche Komplexität und welchen Aufwand die jeweilige Umgebung erfordert.

image

6. Fazit: Das Werkzeug ist nur ein Mittel

Bei der Bereitstellung von Web‑Anwendungen unter Linux gilt:

  • Nicht immer Docker
  • Nicht immer systemd
  • Das passende Werkzeug hängt von Service‑Größe, Team‑Kompetenz und Infrastruktur ab.

Wenn Sie bereits Linux‑Server nutzen, lohnt es sich, die Frage zu stellen:

  • „Brauche ich Docker wirklich?“
  • „Könnte systemd die Dinge vereinfachen?“

Einfachheit und Betriebskomfort sind langfristig die wichtigsten Erfolgsfaktoren.