Patterns et bonnes pratiques

Les patterns de containerisation ne sont pas des règles arbitraires. Chacun répond à un problème concret : reproductibilité, opérabilité, sécurité, maintenabilité. Les ignorer se paye en production.

Un processus par container

Le principe fondamental. PID 1 dans un container = le processus principal. Quand il s'arrête, le container s'arrête. Lancer plusieurs processus (nginx + php-fpm + cron) dans un seul container rend les logs, le monitoring, les rolling updates et les redémarrages sélectifs impossibles.

• nginx dans un container, php-fpm dans un autre, cron dans un troisième
• Exception admise : les processus supervisés par un vrai init (tini, s6, runit)

Tini : init system minimal

FROM debian:13-slim
RUN apt-get update && apt-get install -y tini && rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["myapp"]

Sans init system, le PID 1 est l'application elle-même. Si elle ne gère pas correctement SIGTERM, les containers mettent 10 secondes à s'arrêter (timeout par défaut de Docker). Tini forward les signaux et adopte les processus zombies.

# Alternative : flag docker run
docker run --init myapp:latest

Images immuables

• Ne jamais modifier une image en production via docker exec + changements persistants
• Chaque déploiement = une nouvelle image avec un tag unique (jamais muter latest en production)
• Les configurations par environnement passent par des variables ou des volumes, pas par des images distinctes

Principes 12-factor appliqués aux containers

• Config : toujours via variables d'environnement, jamais hardcodée dans l'image
• Logs : écrire sur stdout/stderr, jamais dans des fichiers dans le container
• Processus : stateless. L'état persiste dans des volumes ou des services externes
• Disposability : démarrage rapide, arrêt graceful (SIGTERM handled, connexions en cours terminées)

Pattern sidecar

services:
  app:
    image: myapp:latest
    volumes:
      - shared-logs:/var/log/app

  log-shipper:
    image: fluent/fluentd:latest
    volumes:
      - shared-logs:/var/log/app:ro   # lit les logs de l'app
    # Envoie vers Elasticsearch, Loki, etc.

volumes:
  shared-logs:

Le sidecar étend les fonctionnalités d'un container principal sans modifier son image : log shipping, métriques, TLS termination, service mesh proxy.

Convention de labels OCI

LABEL org.opencontainers.image.title="Mon Application"
LABEL org.opencontainers.image.description="Description courte"
LABEL org.opencontainers.image.version="1.0.0"
LABEL org.opencontainers.image.source="https://github.com/org/app"
LABEL org.opencontainers.image.created="2026-02-01T00:00:00Z"
LABEL org.opencontainers.image.revision="abc123"
LABEL org.opencontainers.image.licenses="MIT"