Guide du débutant sur les images et conteneurs Docker

Vous venez de rejoindre une équipe frontend, et tout le monde parle de « lancer des conteneurs » et « récupérer des images ». Votre application React fonctionne parfaitement sur votre machine, mais son déploiement semble mystérieux. Docker résout exactement ce problème — et comprendre les bases des images Docker est plus simple que vous ne le pensez.

Ce guide couvre ce que sont réellement les images et conteneurs Docker, comment ils sont liés, et comment les utiliser dans votre workflow frontend pour le développement local, les tests et les déploiements simples.

Que sont les images et conteneurs Docker ?

Une image Docker est un package en lecture seule contenant tout ce qui est nécessaire pour exécuter une application : code, runtime, bibliothèques et configuration. Considérez-la comme une classe en programmation orientée objet — un modèle qui définit la structure mais n’exécute rien par elle-même.

Un conteneur est une instance en cours d’exécution de cette image. Lorsque vous exécutez docker run, Docker crée un environnement isolé à partir de l’image où votre application s’exécute réellement. Vous pouvez lancer plusieurs conteneurs à partir de la même image, chacun fonctionnant de manière indépendante.

Cette distinction entre image Docker et conteneur est importante : les images sont des modèles statiques stockés sur disque, tandis que les conteneurs sont des processus actifs avec leur propre système de fichiers et réseau.

Les images Docker suivent la spécification OCI (Open Container Initiative), ce qui signifie qu’elles fonctionnent avec différents runtimes de conteneurs — pas seulement Docker. Cette standardisation garantit que vos images restent portables.

Comprendre les registres et les tags

Les images résident dans des registres — Docker Hub étant le plus courant des registres publics. Lorsque vous référencez une image comme node:20-alpine, vous spécifiez un dépôt (node) et un tag (20-alpine).

Voici quelque chose qui déroute les débutants : le tag latest n’est pas magique. Il ne pointe pas automatiquement vers la version la plus récente. C’est simplement un tag par défaut que les mainteneurs d’images peuvent mettre à jour ou non. Utilisez toujours des tags explicites comme node:20-alpine pour des builds prévisibles.

Exécuter votre premier conteneur

Exécutons un conteneur simple en utilisant l’image officielle Node.js :

docker run -it --rm node:20-alpine node -e "console.log('Hello from Docker!')"

Les flags -it activent le mode interactif avec un terminal. Le flag --rm supprime automatiquement le conteneur lorsqu’il se termine.

Pour un exemple plus pratique, vous pouvez exécuter un serveur de développement. Créez d’abord un répertoire de projet avec votre code frontend, puis :

docker run -d -p 3000:3000 -v $(pwd):/app -w /app node:20-alpine sh -c "npm install && npm run dev"

Le flag -d exécute le conteneur en arrière-plan. Le -p 3000:3000 mappe le port 3000 à l’intérieur du conteneur vers le port 3000 sur votre machine. Le flag -v monte votre répertoire courant dans le conteneur, et -w définit le répertoire de travail.

Construire des images personnalisées avec des Dockerfiles

Pour des projets réels, vous créerez des images personnalisées. Voici un Dockerfile pour une application React :

FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
EXPOSE 80

Cela démontre un build multi-étapes — une bonne pratique Docker essentielle. La première étape construit votre application ; la seconde étape copie uniquement les fichiers de production dans une image nginx minimale. Votre image finale reste légère et sécurisée.

Construisez et exécutez-la :

docker build -t my-frontend-app .
docker run -d -p 8080:80 my-frontend-app

Volumes Docker et persistance

Les conteneurs sont éphémères — lorsqu’ils s’arrêtent, toutes les données écrites à l’intérieur disparaissent. Pour le développement local, utilisez des bind mounts pour synchroniser votre code source :

docker run -v $(pwd)/src:/app/src -p 3000:3000 my-frontend-app

Pour les données qui doivent persister (comme les fichiers de base de données), utilisez des volumes nommés :

docker volume create app-data
docker run -v app-data:/data my-app

Comprendre les volumes Docker et la persistance est essentiel : ne stockez jamais de données importantes uniquement dans le système de fichiers d’un conteneur.

Bases de la sécurité Docker

Quelques pratiques pour sécuriser vos conteneurs :

Exécutez en tant que non-root. Ajoutez un utilisateur dans votre Dockerfile :

RUN adduser -D appuser
USER appuser

Utilisez des images de base minimales. Les images basées sur Alpine ont moins de vulnérabilités que les distributions complètes.

Analysez régulièrement les images. Des outils comme Docker Scout ou Trivy identifient les vulnérabilités connues.

N’intégrez jamais de secrets dans les images. Les variables d’environnement ou les outils de gestion de secrets gèrent les identifiants — les coder en dur crée des risques de sécurité qui persistent dans les couches d’images.

Simplifier les configurations multi-conteneurs avec Compose

Lorsque votre frontend nécessite une API backend et une base de données localement, Docker Compose orchestre le tout :

services:
  frontend:
    build: ./frontend
    ports:
      - "3000:3000"
  api:
    build: ./api
    ports:
      - "4000:4000"

Exécutez docker compose up et les deux services démarrent ensemble. Utilisez docker compose down pour arrêter et supprimer tous les conteneurs.

Conclusion

Les images Docker sont des modèles ; les conteneurs sont des instances en cours d’exécution. Maintenez les images légères avec des builds multi-étapes, utilisez des tags explicites au lieu de latest, séparez l’état des conteneurs en utilisant des volumes, et reconstruisez régulièrement les images pour capturer les mises à jour de sécurité. Ces fondamentaux vous serviront que vous exécutiez un environnement de développement ou déployiez une application frontend simple.

FAQ

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.