Aller au contenu principal

Docker

Statut

Document de cadrage DevOps — version initiale.

Position

Docker peut être utile pour standardiser les environnements, mais ne doit pas être présenté comme obligatoire si le projet ne l'utilise pas encore clairement.

La stratégie DMV privilégie la simplicité opérationnelle et la réversibilité.

État actuel visible

Aucun Dockerfile, docker-compose.yml ou fichier Compose projet n'a été trouvé dans le workspace inspecté hors dépendances.

Les scripts visibles privilégient une installation directe sur VPS Debian avec Nginx, PHP-FPM, Redis, Supervisor et cron.

Usages possibles en vision cible

UsageIntérêt
Développement localRéduire les écarts entre machines.
StagingReproduire plus facilement l'environnement cible.
WorkersIsoler des traitements spécifiques.
IA futurePréparer des workers spécialisés ou GPU si nécessaire.
Tests CIExécuter services reproductibles.

Limites

Docker ne doit pas être ajouté uniquement par principe.

Il peut introduire :

  • complexité réseau ;
  • gestion d'images ;
  • registry ;
  • configuration secrets ;
  • monitoring supplémentaire ;
  • débogage plus difficile pour une petite équipe.

Doctrine

  • Conserver l'approche VPS actuelle tant qu'elle reste efficace.
  • Introduire Docker si un problème réel est identifié.
  • Documenter les images, volumes, réseaux et secrets.
  • Éviter de dupliquer les chemins de déploiement.
  • Ne pas mélanger production Docker et production non Docker sans stratégie claire.

Scénario cible raisonnable

Docker peut être introduit progressivement :

  1. environnement local ;
  2. services de test ;
  3. staging ;
  4. production uniquement si les bénéfices dépassent la complexité.

Points à clarifier

  • Besoin réel de conteneurisation.
  • Compatibilité avec le VPS actuel.
  • Gestion des volumes médias.
  • Stratégie de registry.
  • Monitoring des conteneurs.
  • Coût opérationnel pour l'équipe.