Cas pratiques Docker

Contexte : Une équipe front-end souhaite livrer un site statique HTML/CSS via un conteneur pour uniformiser les environnements de test. Le Problème : Aucune configuration Docker n'existe actuellement et l'application doit être servie via Nginx. Contraintes : Utiliser l'image officielle nginx:alpine. Le site doit être servi sur le port 80. Aucun outil de build n'est requis. Livrable attendu : Rédiger un Dockerfile simple permettant de copier les fichiers statiques dans le bon répertoire Nginx et d'exposer le port approprié.

Contexte : Vous intégrez une équipe qui souhaite conteneuriser une petite API Node.js utilisée pour des tests internes. Le projet fonctionne parfaitement en local mais échoue une fois déployé dans Docker. Le Problème : Le conteneur se build correctement mais au démarrage, l'erreur "Cannot find module '/app/server.js'" apparaît. L'équipe soupçonne un problème dans le Dockerfile. Contraintes : Vous ne pouvez pas modifier le code applicatif. L'image doit rester basée sur node:18 et exposer le port 3000. Aucune optimisation avancée n'est requise. Dockerfile actuel : FROM node:18 WORKDIR /app COPY package.json ./ RUN npm install EXPOSE 3000 CMD ["node", "server.js"] Livrable attendu : Fournir un Dockerfile corrigé permettant au conteneur de démarrer correctement avec l'ensemble du code présent.

Contexte : Votre équipe a conteneurisé une application Express destinée à être testée en environnement QA. Le Problème : Le conteneur démarre sans erreur mais l'application est inaccessible depuis le navigateur malgré un mapping de port effectué au lancement. Contraintes : Vous devez corriger uniquement le Dockerfile. L'application écoute sur le port 4000 en interne. L'image doit rester basée sur node:18. Dockerfile actuel : FROM node:18 WORKDIR /app COPY . . RUN npm install CMD ["node", "index.js"] Livrable attendu : Modifier le Dockerfile afin que l'application soit accessible correctement depuis l'hôte.

Contexte : Une application interne simple en Node.js doit être exécutée dans un conteneur pour une démonstration client. Le Problème : Le conteneur se lance puis s'arrête immédiatement sans afficher d'erreur claire. Après analyse, le problème semble lié à l'instruction CMD. Contraintes : Vous devez conserver node:18 comme image de base et ne pas modifier les fichiers applicatifs. Dockerfile actuel : FROM node:18 WORKDIR /app COPY . . RUN npm install EXPOSE 3000 CMD node server.js Livrable attendu : Corriger l'instruction de démarrage pour garantir un comportement stable du conteneur.

Contexte : Une application Node nécessite une phase de build avant exécution. Le Problème : L'image finale contient des outils inutiles et devient volumineuse. Contraintes : Utiliser un build multi-stage pour séparer la phase de build et la phase d'exécution. Image finale basée sur node:18-alpine. Livrable attendu : Rédiger un Dockerfile utilisant deux stages afin de produire une image plus légère et adaptée à la production.

Contexte : Une petite application Node.js doit communiquer avec une base PostgreSQL pour les tests d'intégration. Le Problème : Les développeurs lancent les services séparément, ce qui crée des incohérences de configuration. Contraintes : Utiliser docker-compose. L'API doit dépendre de la base de données et se connecter via le nom du service. Aucun outil externe. Livrable attendu : Fournir un fichier docker-compose.yml définissant les deux services, leurs variables d'environnement essentielles et la dépendance entre eux.

Contexte : Une application nécessite une variable d'environnement API_KEY pour fonctionner correctement. Le Problème : Lors du lancement du conteneur, la variable n'est pas accessible dans l'application. Contraintes : Vous devez configurer correctement la variable via Dockerfile ou docker run sans modifier le code source. Livrable attendu : Fournir une configuration permettant à l'application d'accéder à la variable d'environnement au runtime.

Contexte : Une base MySQL est exécutée dans un conteneur pour des tests locaux. Le Problème : À chaque redémarrage du conteneur, toutes les données sont perdues. Contraintes : Vous devez utiliser un volume Docker pour assurer la persistance. L'image doit rester mysql:8. Livrable attendu : Définir une configuration docker run ou docker-compose permettant de monter un volume persistant et garantir la conservation des données.

Contexte : L'équipe DevOps remarque que chaque modification mineure du code déclenche une réinstallation complète des dépendances lors du build Docker. Le Problème : Le Dockerfile actuel invalide le cache à chaque modification, rallongeant considérablement le temps de build. Contraintes : Vous devez optimiser le Dockerfile sans changer la base node:18 ni ajouter d'outils externes. Dockerfile actuel : FROM node:18 WORKDIR /app COPY . . RUN npm install CMD ["node", "server.js"] Livrable attendu : Proposer une version optimisée du Dockerfile permettant de tirer parti du cache Docker efficacement.

Contexte : Une équipe data a dockerisé un microservice Python utilisant Flask. En local tout fonctionne, mais dans le conteneur certaines dépendances semblent absentes. Le Problème : Au lancement, l'erreur "ModuleNotFoundError: No module named 'flask'" apparaît alors que le fichier requirements.txt existe dans le projet. Contraintes : Vous devez corriger uniquement le Dockerfile. L'image doit être basée sur python:3.11-slim et démarrer via python app.py. Dockerfile actuel : FROM python:3.11-slim WORKDIR /app COPY . . RUN pip install -r requirements.txt CMD ["python", "app.py"] Livrable attendu : Corriger le Dockerfile pour garantir l'installation correcte des dépendances et un démarrage sans erreur.

Contexte : Une plateforme interne regroupe trois microservices HTTP distincts devant être accessibles via un seul point d'entrée. Le Problème : Les développeurs exposent actuellement chaque conteneur sur un port différent, ce qui complique l'accès et la configuration. Contraintes : Utiliser docker-compose et intégrer un reverse proxy basé sur nginx. Les services doivent rester isolés sur un réseau interne. Livrable attendu : Proposer une architecture docker-compose intégrant un service reverse proxy configuré pour router les requêtes vers les microservices internes.

Contexte : Une application Node.js écrit des fichiers générés dans un dossier /data monté via un volume Docker. Le Problème : En environnement Linux, l'application échoue avec une erreur EACCES permission denied lors de l'écriture dans le volume. Contraintes : Vous devez corriger la configuration Docker sans modifier le code. L'image est basée sur node:18-alpine. Le volume doit rester monté sur /data. Dockerfile actuel : FROM node:18-alpine WORKDIR /app COPY . . RUN npm install VOLUME ["/data"] CMD ["node", "server.js"] Livrable attendu : Proposer une solution garantissant les permissions correctes sur le volume monté.

Contexte : Une application composée d'une API Node.js et d'un service Redis est orchestrée via docker-compose pour un environnement de staging. Le Problème : L'API ne parvient pas à se connecter à Redis et retourne une erreur de connexion refusée. Les développeurs utilisent localhost comme hôte. Contraintes : Vous devez corriger uniquement le fichier docker-compose.yml. Aucun changement dans le code. Les services doivent communiquer via un réseau Docker dédié. Fichier actuel : version: '3' services: api: build: . ports: - "3000:3000" redis: image: redis:7 Livrable attendu : Fournir une configuration fonctionnelle permettant la communication inter-services correcte.

Contexte : L'entreprise souhaite intégrer la construction d'images Docker dans son pipeline CI. Le Problème : Les builds sont instables et non reproductibles à cause de versions flottantes et d'un cache mal maîtrisé. Contraintes : L'image doit être déterministe. Les versions doivent être figées. Aucun outil externe hors Docker. Livrable attendu : Proposer une stratégie Dockerfile et bonnes pratiques garantissant des builds reproductibles et optimisés pour un pipeline CI.

Contexte : Une application nécessite des clés API et identifiants de base de données pour fonctionner. Le Problème : Les développeurs les ont intégrés directement dans le Dockerfile, exposant les secrets dans l'image finale. Contraintes : Utiliser les mécanismes Docker adaptés pour éviter d'inclure les secrets dans l'image. Aucun changement du code applicatif. Livrable attendu : Proposer une configuration sécurisée pour injecter les variables sensibles au runtime sans les intégrer dans l'image.

Contexte : Une API déployée via Docker génère des logs critiques pour le monitoring. Le Problème : Les logs sont actuellement stockés dans des fichiers internes au conteneur, rendant leur consultation complexe. Contraintes : Vous devez adapter la configuration Docker pour permettre la centralisation ou l'accès simplifié aux logs sans modifier le code. Livrable attendu : Proposer une configuration adaptée permettant une gestion efficace des logs en environnement Docker.

Contexte : Une application traite des données sensibles et inclut un service interne d'administration. Le Problème : Tous les services partagent actuellement le même réseau Docker, exposant inutilement le service d'administration. Contraintes : Utiliser docker-compose avec au moins deux réseaux distincts. Le service admin ne doit pas être accessible depuis l'extérieur. Livrable attendu : Fournir une configuration docker-compose garantissant une isolation réseau appropriée et sécurisée.

Contexte : Une API interne est utilisée par plusieurs microservices. En cas de panne, les conteneurs restent marqués comme actifs alors qu'ils ne répondent plus. Le Problème : Aucun mécanisme de healthcheck n'est défini dans l'image Docker, empêchant l'orchestrateur de détecter les conteneurs défaillants. Contraintes : Vous devez ajouter un HEALTHCHECK dans le Dockerfile sans modifier le code. L'application expose un endpoint /health sur le port 3000. Livrable attendu : Fournir un Dockerfile intégrant une instruction HEALTHCHECK adaptée permettant de détecter automatiquement les conteneurs non fonctionnels.

Contexte : Une application React buildée via Node est déployée dans un conteneur unique en production. L'image dépasse 900MB, ce qui ralentit les déploiements CI/CD. Le Problème : L'image contient les dépendances de build, les sources complètes et des fichiers inutiles en runtime. Contraintes : Utiliser un build multi-stage. L'image finale doit être basée sur nginx:alpine. Aucun outil externe autorisé. Dockerfile actuel : FROM node:18 WORKDIR /app COPY . . RUN npm install && npm run build EXPOSE 80 CMD ["npm", "start"] Livrable attendu : Proposer un Dockerfile optimisé produisant une image légère et adaptée à la production.

Contexte : Vous reprenez un microservice Node.js conteneurisé pour un projet SaaS. L'application fonctionne, mais un audit interne de sécurité révèle que le conteneur s'exécute en tant qu'utilisateur root. Le Problème : L'exécution en root augmente la surface d'attaque et ne respecte pas les bonnes pratiques DevSecOps de l'entreprise. Contraintes : Vous devez modifier uniquement le Dockerfile. L'image doit rester basée sur node:18-alpine. Aucune modification du code applicatif n'est autorisée. Le port 3000 doit rester exposé. Dockerfile actuel : FROM node:18-alpine WORKDIR /app COPY package.json ./ RUN npm install COPY . . EXPOSE 3000 CMD ["node", "server.js"] Livrable attendu : Fournir une version sécurisée du Dockerfile utilisant un utilisateur non-root et respectant les bonnes pratiques de sécurité.

Contexte : Une plateforme combine un frontend React et une API Go dans un même dépôt monorepo. L'équipe souhaite produire une image unique optimisée. Le Problème : Le Dockerfile actuel compile tout dans une seule image lourde contenant Node, Go et outils de build inutiles en production. Contraintes : Utiliser un build multi-stage avancé. L'image finale doit être minimale et ne contenir que le binaire Go et les assets statiques. Livrable attendu : Concevoir un Dockerfile multi-stage structuré séparant clairement build frontend, build backend et runtime final léger.

Contexte : Une API critique doit être déployée sans interruption de service. Le Problème : Les déploiements actuels arrêtent le conteneur existant avant de démarrer le nouveau, provoquant des coupures. Contraintes : Utiliser uniquement Docker et docker-compose. Aucun orchestrateur externe. Livrable attendu : Proposer une architecture blue-green permettant bascule contrôlée entre deux versions sans downtime.

Contexte : Une architecture microservices fonctionne correctement en local mais échoue en environnement Docker avec des erreurs DNS intermittentes. Le Problème : Certains services ne résolvent pas les noms internes malgré leur présence dans le même docker-compose. Contraintes : Vous devez corriger la configuration réseau uniquement via docker-compose. Plusieurs réseaux sont utilisés, dont un externe. Fichier actuel : version: '3.8' services: api: build: . networks: - public worker: build: . networks: - private networks: public: private: Livrable attendu : Proposer une configuration réseau robuste garantissant une résolution DNS fiable entre services concernés.

Contexte : Une application backend est buildée avec des tokens privés pour télécharger des dépendances depuis un registry interne. Un audit révèle que les secrets sont récupérables dans l'historique des couches Docker. Le Problème : Le Dockerfile injecte un ARG TOKEN puis exécute un RUN npm config set avec ce token, laissant une trace persistante dans les layers. Contraintes : Vous devez empêcher toute persistance du secret dans l'image finale. Utiliser les mécanismes modernes Docker (buildkit si nécessaire). Aucune modification du code applicatif. Dockerfile actuel : FROM node:18 ARG NPM_TOKEN WORKDIR /app COPY package.json ./ RUN npm config set //registry.npmjs.org/:_authToken=$NPM_TOKEN RUN npm install COPY . . CMD ["node", "server.js"] Livrable attendu : Proposer un Dockerfile sécurisé garantissant qu'aucun secret ne soit stocké dans les couches finales.

Contexte : Plusieurs microservices Docker génèrent des logs critiques pour le monitoring. Le Problème : Les logs sont dispersés et difficiles à agréger pour analyse. Contraintes : Utiliser une solution basée sur Docker uniquement (ex: ELK via compose). Aucun outil externe hors conteneurs. Livrable attendu : Proposer une architecture docker-compose intégrant un système de centralisation des logs multi-services.

Contexte : Une plateforme manipule des données sensibles et exige une segmentation réseau stricte entre services publics et internes. Le Problème : Tous les conteneurs communiquent librement sur le même réseau bridge par défaut. Contraintes : Concevoir une architecture docker-compose avec plusieurs réseaux isolés et accès contrôlés. Aucun accès externe pour les services internes. Livrable attendu : Fournir une configuration démontrant une segmentation réseau claire et sécurisée adaptée à un environnement critique.

Contexte : Une entreprise fintech impose des standards de sécurité stricts pour ses conteneurs en production. Le Problème : L'image actuelle s'exécute en root et conserve toutes les Linux capabilities par défaut. Contraintes : Vous devez renforcer l'isolation via Dockerfile et docker-compose. Réduction des capabilities et exécution non-root obligatoires. Aucun changement applicatif. Livrable attendu : Fournir une configuration sécurisée incluant USER non-root et suppression explicite des capabilities inutiles.

Contexte : L'entreprise souhaite héberger ses images Docker dans un registry privé interne. Le Problème : Les images sont actuellement poussées vers un registry public non sécurisé. Contraintes : Déployer un registry Docker privé avec authentification basique et stockage persistant. Livrable attendu : Proposer une configuration docker-compose complète permettant de déployer un registry sécurisé prêt à l'emploi.

Contexte : Un projet Node possède des dépendances différentes selon l'environnement (dev et prod). Les builds Docker sont trop fréquents et invalidés inutilement. Le Problème : Le Dockerfile actuel copie l'intégralité du projet avant installation, détruisant toute efficacité du cache. Contraintes : Vous devez maximiser l'utilisation du cache et séparer dépendances prod/dev. Image finale minimale. Dockerfile actuel : FROM node:18 WORKDIR /app COPY . . RUN npm install CMD ["node", "server.js"] Livrable attendu : Proposer un Dockerfile structuré optimisant les layers et séparant clairement les dépendances de production.

Contexte : Une application de traitement asynchrone nécessite plusieurs workers Docker pour absorber les pics de charge. Le Problème : L'équipe lance manuellement plusieurs conteneurs, rendant la gestion instable. Contraintes : Utiliser docker-compose avec scaling contrôlé. Les workers doivent partager une même file Redis. Livrable attendu : Proposer une architecture permettant de scaler proprement les workers tout en maintenant la cohérence réseau.