Docker ou systemd.service ? Repenser la stratégie de déploiement d’applications web sous Linux

Docker ou systemd.service ? Repenser la stratégie de déploiement d’applications web sous Linux

Au cours des dernières années, la formule « déploiement = Docker + orchestration (Kubernetes, ECS, etc.) » est devenue quasi‑obligatoire. C’est pourquoi la méthode traditionnelle de lancer une application web sur un serveur Linux en tant que processus + service systemd peut sembler dépassée.

En réalité, cependant :

• application web unique
• petite équipe / infrastructure simple
• environnement on‑premise ou fortement réglementé

…le déploiement via systemd reste souvent plus simple, plus fiable et plus opérationnel.

Dans cet article, nous comparons les avantages de systemd par rapport à Docker et identifions les situations où un déploiement basé sur systemd est préférable.

1. Bref rappel : systemd vs Docker

Docker

• Packager l’application dans une image
• Exécuter l’image dans un conteneur
• Avantage : encapsulation complète de l’environnement → exécution identique partout

systemd

• Système d’initialisation par défaut des distributions Linux modernes
• Démarrer, redémarrer et gérer les services (démons)
• Définir les processus via des fichiers *.service

Docker est un outil d’encapsulation d’environnement, tandis que systemd est un gestionnaire de processus. Ils ne sont pas concurrents ; on les combine souvent (exécuter systemd à l’intérieur d’un conteneur ou gérer le daemon Docker via systemd). Ici, nous nous concentrons sur le cas où on déploie une application web sans Docker, uniquement avec systemd.

2. Avantages du déploiement via systemd.service

2‑1. Simplicité : une couche de plus disparaît

Avec Docker, on ajoute :

• le daemon Docker
• la chaîne de construction d’images
• un registre d’images
• la gestion des droits d’exécution du conteneur

Avec systemd, on se contente de :

• installer le runtime requis (Python, Node, Java, etc.)
• déployer le code
• enregistrer le service dans systemd

Cette architecture est plus légère, surtout pour les projets de petite taille ou les services internes.

2‑2. Intégration naturelle avec Linux

• Logs : journalctl -u myapp.service
• Démarrage automatique : systemctl enable myapp.service
• Limites de ressources : MemoryMax, CPUQuota
• Gestion des dépendances : After=network.target, After=postgresql.service

Avec Docker, il faut séparer logs, ressources et réseau entre l’hôte et le conteneur, ce qui complique le diagnostic.

2‑3. Moins de surcharge de ressources

Docker introduit une légère surcharge, mais souvent on voit :

• accumulation de couches d’images
• conteneurs inutilisés
• volumes et logs de conteneurs

Systemd ne nécessite que l’hôte, le runtime et le code, ce qui est idéal pour les VM à ressources limitées ou les serveurs embarqués.

2‑4. Réseau plus transparent

Les conteneurs utilisent des IP internes, des mappages de ports et des réseaux (bridge, overlay). Avec systemd, l’application écoute directement sur l’IP/port de l’hôte, rendant le débogage réseau plus simple.

2‑5. Cas où Docker est interdit

• environnements réglementés (finance, santé, défense)
• politiques d’entreprise interdisant les runtimes de conteneurs
• réseaux isolés sans accès aux registres publics

Dans ces scénarios, l’option OS + systemd est souvent la seule viable.

3. Exemple de déploiement systemd.service pour une application web

Supposons un service Django/Flask exécuté par gunicorn.

3‑1. Fichier d’unité

/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

# Limites de ressources (facultatif)
# MemoryMax=512M
# CPUQuota=50%

[Install]
WantedBy=multi-user.target

3‑2. Variables d’environnement

/etc/myapp.env :

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

3‑3. Commandes courantes

# Enregistrement et démarrage automatique
sudo systemctl enable myapp.service

# Démarrer / arrêter / redémarrer
sudo systemctl start myapp.service
sudo systemctl restart myapp.service
sudo systemctl stop myapp.service

# Vérifier l’état et les logs
sudo systemctl status myapp.service
sudo journalctl -u myapp.service -f

Les équipes Linux expérimentées peuvent déployer rapidement sans courbe d’apprentissage supplémentaire.

4. Quand privilégier systemd plutôt que Docker

5. Quand Docker reste la meilleure option

Docker excelle quand :

• On déploie le même stack sur plusieurs serveurs ou environnements (dev, staging, prod)
• On a besoin d’une isolation forte ou d’une cohérence d’environnement
• On gère plusieurs services (web, worker, cron, base de données) dans un même cluster
• On intègre un pipeline CI/CD qui construit et pousse des images

En fin de compte, le choix dépend de la simplicité, de la fiabilité et de la facilité d’exploitation dans votre contexte.

6. Conclusion : l’outil n’est qu’un moyen, la situation prime

Déployer une application web sous Linux ne doit pas être une décision « Docker = obligatoire » ou « Docker = mauvais ». Il s’agit de choisir l’approche qui rend le déploiement plus simple, plus fiable et plus opérationnel pour votre équipe et votre infrastructure.

• Service unique, infrastructure simple, contraintes réglementaires : systemd.service est souvent la solution la plus pragmatique.
• Multi‑services, environnements multiples, déploiements fréquents : Docker apporte une valeur ajoutée significative.

Si vous utilisez déjà Linux, prenez un moment pour vous demander :

• « Est‑ce que Docker est vraiment indispensable ? »
• « Pourrait‑je simplifier en passant à systemd ? »

Les outils sont des moyens, pas des fins. La simplicité et la facilité d’exploitation sont les clés de la productivité à long terme.