Docker of systemd.service? Een heroverweging van webapplicatie‑implementatiestrategieën op Linux

De afgelopen jaren is de formule “implementatie = Docker + container‑orchestratie (Kubernetes, ECS, etc.)” bijna een vanzelfsprekendheid geworden. Daardoor lijkt het nog steeds verouderd om een webapplicatie op een Linux‑server simpelweg als process + systemd‑service te draaien.

In de praktijk is het echter zo:

  • een enkele webapplicatie
  • een klein team / eenvoudige infrastructuur
  • on‑premise of een sterk gereguleerde omgeving

In deze gevallen is het vaak simpeler, betrouwbaarder en operationeel vriendelijker om te implementeren met een systemd‑service.

In dit artikel bekijken we welke voordelen systemd heeft ten opzichte van Docker bij het implementeren van een webapplicatie op Linux, en in welke situaties een systemd‑gebaseerde aanpak de voorkeur heeft.

1. Een korte introductie tot systemd en Docker

Commandbox 광고

Kort samengevat:

  • Docker
  • Pakt een applicatie in een image
  • Draait het als een container

  • Sterk punt: “omgeving volledig kapselen → overal identiek draaien”

  • systemd

  • De standaard init‑system van moderne Linux‑distributies
  • Start services (daemons) bij het opstarten, herstart ze bij falen, en beheert logs
  • Definieert en beheert processen via *.service‑unit‑bestanden

Docker is een tool om de applicatieomgeving te kapselen, terwijl systemd een tool is om processen op Linux te beheren.

Ze concurreren niet; vaak worden ze samen gebruikt, bijvoorbeeld door systemd te laten draaien binnen een Docker‑container of door Docker‑daemons te laten beheren door systemd.

In dit artikel richten we ons op het scenario waarin geen Docker wordt gebruikt en alles via systemd wordt beheerd.

2. Voordelen van systemd.service boven Docker

2‑1. Eenvoud: één laag minder

Met Docker voegt de implementatie extra lagen toe:

  • Docker‑daemon
  • Image‑build‑pipeline
  • Image‑registry
  • Container‑runtime‑rechten en -beheer

Met systemd‑gebaseerde implementatie:

  • Installeer de benodigde runtime (Python/Node/Java, etc.) op het OS
  • Deploy de applicatiecode
  • Registreer en start via een systemd‑service

Dit resulteert in een relatief eenvoudige structuur.

Voor kleine projecten of interne services kan het proces van “image bouwen → push → pull → redeploy” juist een last zijn, terwijl een eenvoudige SSH‑sessie met git pull + systemctl restart sneller en intuïtiever is.

2‑2. Natuurlijke integratie met Linux

Systemd is het “kantoor” van Linux en sluit naadloos aan op OS‑niveau functies:

  • Logs – journalctl -u myapp.service toont direct de service‑logs
  • Automatisch opstarten bij boot – systemctl enable myapp.service
  • Resource‑limieten (cgroup) – MemoryMax, CPUQuota, etc.
  • Afhankelijkheidsbeheer – After=network.target, After=postgresql.service

Bij Docker moet je logs, resources en netwerken zowel binnen als buiten de container scheiden, en bepalen of een probleem binnen de container of op de host ligt.

Voor een paar webservices is een direct gekoppelde systemd‑structuur vaak meer intuïtief.

2‑3. Minder resource‑overhead

Docker zelf heeft een klein overhead, maar vaak komt er extra bij:

  • Meerdere images/laag‑opslag → meer schijfruimte
  • Onnodige draaiende containers
  • Log‑ en volume‑beheer per container

Systemd‑gebaseerde implementatie vereist alleen OS + runtime + applicatiecode, wat vooral in schijf‑ of geheugen‑krappe omgevingen voordelig is.

Voor meerdere kleine VMs of embedded/laag‑spec hardware is systemd vaak lichter.

2‑4. Intuïtieve netwerkstructuur

Met Docker moet je:

  • Container‑intern IP en poort
  • Poort‑mapping host ↔ container
  • Bridge‑ of overlay‑netwerken

Met systemd bind je direct aan de host‑IP/poort, en firewall‑regels gelden op host‑niveau. Dit maakt netwerk‑debugging eenvoudiger:

  • Is de poort open?
  • Wordt het geblokkeerd door de firewall?
  • Conflict met andere services op dezelfde host?

Een extra netwerk‑laag (container) wordt vermeden.

2‑5. Docker kan niet in bepaalde omgevingen

Dit gebeurt vaker dan je denkt:

  • Financiële, publieke, medische omgevingen met strenge regelgeving
  • Beleid dat container‑runtime verbiedt
  • Netwerk‑beperkingen waardoor externe registries niet bereikbaar zijn

In zulke gevallen is de enige realistische optie OS + systemd. Met een goed begrip van systemd kun je:

  • Automatische herstart
  • Log‑beheer
  • Resource‑limieten
  • Indirecte health‑checks

implementeren zonder Docker.

3. Voorbeeld van een systemd.service voor een webapplicatie

Commandbox 광고

Stel dat we een Django/Flask‑applicatie draaien met gunicorn.

3‑1. Unit‑bestand voorbeeld

/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

# Herstart bij falen
Restart=on-failure
RestartSec=5

# Optionele resource‑limieten
# MemoryMax=512M
# CPUQuota=50%

[Install]
WantedBy=multi-user.target

En de omgevingsvariabelen in /etc/myapp.env:

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

De commando’s zijn eenvoudig:

# Service registreren & automatisch starten bij boot
sudo systemctl enable myapp.service

# Start / stop / herstart
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

Een team dat vertrouwd is met Linux‑servers kan zonder extra leercurve direct opereren.

4. Wanneer is systemd‑implementatie beter dan Docker?

Samengevat: overweeg systemd‑implementatie als:

4‑1. Eén of een paar eenvoudige services, geen complexe orchestratie

  • 1–2 webapplicaties
  • DB via een managed service (RDS, etc.)
  • Beperkt aantal servers (1–5)

In dit geval kan de extra kosten van Docker + orchestratie groter zijn dan de voordelen.

4‑2. Het team is al vertrouwd met “Linux‑servers + services”

  • Bestaande systemen draaien al op systemd
  • Team is bekend met systemctl, journalctl, rsyslog, logrotate

Het toevoegen van een nieuwe laag (Docker) kan onnodig complex zijn.

4‑3. Strenge regelgeving of beperkingen op Docker

  • Financiële, publieke, militaire, medische omgevingen
  • Gesloten netwerken
  • Beperkingen op container‑beveiliging of certificering

In zulke gevallen is een bewezen OS‑gebaseerde aanpak vaak de veiligste keuze.

4‑4. Debuggen / prestatie‑analyse direct op hostniveau

  • Gebruik van strace, perf, /proc
  • Eén keer de netwerk‑, bestandssysteem‑ of resource‑issues bekijken

Een container voegt een extra laag toe die het analyseren bemoeilijkt.

5. Er zijn ook situaties waarin Docker beter past

Hoewel systemd voordelen heeft, zijn er duidelijke voordelen van Docker:

  • Image‑build → identieke omgeving overal
  • Vermindert verschillen tussen lokaal, staging en productie
  • Naadloze integratie met CI/CD‑pijplijnen
  • Multi‑service‑configuratie (web + worker + cron + DB)

Wanneer je dezelfde stack op meerdere servers/omgevingen moet implementeren, of wanneer team‑omgevingen sterk variëren, kan Docker de betere keuze zijn.

Het belangrijkste is om te vragen:

“Welke tool maakt onze service het simpelst, het meest betrouwbaar en het gemakkelijkst te beheren in onze huidige omgeving?”

6. Afsluiting: het juiste hulpmiddel voor de juiste situatie

Bij het implementeren van webapplicaties op Linux is het niet zo simpel als “altijd Docker” of “Docker is slecht, systemd is beter”.

  • Eén service, eenvoudige infrastructuur, strenge regelgeving → systemd.service kan realistischer zijn
  • Multi‑service, verschillende omgevingen, frequente deploys → Docker levert meer waarde

Als je al Linux‑servers gebruikt, overweeg dan eens:

  • “Is Docker echt nodig?”
  • “Kan systemd het eenvoudiger maken?”

Tools zijn slechts middelen; simplicity en operationele eenvoud leveren op de lange termijn de grootste productiviteit.

image