Lecodeestdanslepre

Docker et les containers : parce-qu'il faut expliquer avec des pancakes

10 min de lecture

Docker et les conteneurs, c'est encore un mystère opaque pour beaucoup. Je l'utilise au quotidien dans mon environnement de travail. Et puisque l'abstraction, ça peut être compliqué, on va parler de pancakes.

Sans Docker : cauchemar en cuisine

Imagine un restaurant. Ouais, un vrai. Avec des clients chiants qui veulent TOUS un pancake différent :

  • Jean-Michel veut des pancakes aux myrtilles.
  • Sophie veut des pancakes au chocolat.
  • Cyril veut un kebab.

Mais il y a un problème : tu n'as qu'une seule cuisine, une seule poêle et une seule table pour tout préparer. Résultat : les ingrédients sont tous mélangés et les pancakes ont tous le même goût (et il y a des morceaux de kebab dans les pancakes aux myrtilles, sympa).

En informatique, c'est pareil. Sans Docker, toutes tes applications tournent sur le même serveur, partagent les mêmes bibliothèques, les mêmes dépendances. Et à la moindre mise à jour…

Docker : L'illumination divine des pancakes

Docker, c'est le mec intelligent du groupe qui débarque et dit :
"Et si… chaque pancake était préparé dans sa propre mini-cuisine ?"

Maintenant, chaque type de pancake a son propre espace de cuisson, ses propres ingrédients, sa propre poêle :

  • Isolation totale : Les pancakes ne se mélangent plus, chacun a son goût distinct.
  • Zéro conflit : Pas de gluten qui traîne dans le vegan, pas de chocolat dans la myrtille.
  • Facilité de nettoyage : Un pancake est raté ? Pouf, on le jette et on recommence.

En gros, Docker encapsule chaque application avec tout ce dont elle a besoin : son runtime, ses dépendances, et son environnement, dans un joli petit conteneur hermétique.

Images et Containers : la recette et le pancake final

Docker fonctionne avec des images, qui sont en gros des recettes toutes prêtes :

  • Une image Docker = une recette de pancakes (Pancake au chocolat 1.0).
  • Un container = un pancake en train de cuire sur la poêle.

Tu veux refaire un pancake identique ? Pas besoin de tout refaire à la main. Tu relances un nouveau container depuis l'image, et ça donne un pancake parfait, à l'identique.

Exemple de Dockerfile

# On prend une base d'image avec PHP préinstallé
FROM php:8.2-cli 

# On installe des extensions PHP nécessaires pour interagir avec une base de données
RUN docker-php-ext-install pdo pdo_mysql 

# On copie notre code source dans le conteneur, dans le dossier /app
COPY . /app

# On définit le dossier de travail par défaut pour exécuter nos commandes
WORKDIR /app

# On spécifie la commande par défaut qui sera exécutée lorsque le conteneur démarre
CMD ["php", "index.php"]

Explication ligne par ligne :

  • FROM php:8.2-cli : Utilise une image officielle de PHP en ligne de commande comme base.
  • RUN docker-php-ext-install pdo pdo_mysql : Installe des extensions PHP pour interagir avec MySQL.
  • COPY . /app : Copie tous les fichiers de ton projet local vers /app dans le conteneur.
  • WORKDIR /app : Définit /app comme répertoire de travail pour toutes les commandes exécutées après.
  • CMD ["php", "index.php"] : Définit la commande par défaut qui s'exécutera quand le conteneur démarre (ici, lancer php index.php).

Docker Compose : parce qu'un seul pancake, c'est triste

Un seul pancake, c'est bien. Mais un petit-déj complet, c'est mieux :

  • Pancakes
  • Café
  • Sirop d'érable
  • Serveur web (parce qu'on bosse un peu quand même)

Plutôt que de tout démarrer à la main, Docker Compose dit : "t'inquiète, je gère tout ça d'un coup."

Avec un fichier compose.yml, tu définis tous tes containers et leurs interactions. Et en une seule commande, ton petit-déjeuner est prêt. Magie.

Exemple de compose.yaml

services:
  web:
    image: nginx:latest # Utilise Nginx comme serveur web
    ports:
      - "8080:80" # Redirige le port 8080 de la machine hôte vers le port 80 du conteneur
    volumes:
      - ./public:/usr/share/nginx/html # Monte le dossier local public/ vers le dossier web de Nginx
  php:
    build: . # Construit l'image à partir du Dockerfile défini plus haut
    volumes:
      - .:/app # Monte le code source local dans le conteneur
  db:
    image: mysql:latest # Utilise MySQL comme base de données
    environment:
      MYSQL_ROOT_PASSWORD: root # Définit le mot de passe root de MySQL
      MYSQL_DATABASE: myapp # Crée automatiquement une base de données "myapp"

Explication ligne par ligne :

  • services: : Liste des services (conteneurs) que Docker Compose va gérer.
  • web: : Définition du service Nginx (serveur web).
  • image: nginx:latest : Utilise l'image officielle Nginx.
  • ports: - "8080:80" : Redirige le port 8080 de l'ordinateur vers le port 80 du conteneur.
  • volumes: - ./public:/usr/share/nginx/html : Monte le dossier ./public local dans le conteneur pour servir du contenu.
  • php: : Définition du service PHP.
  • build: . : Construit l'image PHP à partir du Dockerfile fourni.
  • volumes: - .:/app : Monte le code source local pour qu'il soit accessible dans le conteneur.
  • db: : Définition du service MySQL.
  • image: mysql:latest : Utilise MySQL comme image.
  • environment: : Définit des variables d'environnement pour MySQL.

Les volumes Docker : ne pas perdre sa garniture de pancake

C'est bien beau de faire des pancakes, mais si tu dois jeter toute la garniture à chaque fois que tu changes de poêle, ça devient vite chiant.

Les volumes Docker, c'est comme avoir un tupperware à côté de ta cuisine temporaire :

  • Tu détruis ton container ? Tes données précieuses survivent.
  • Tu veux réutiliser les mêmes données dans un nouveau container ? Pas de problème.
volumes:
  - ./mes_donnees:/data/application # Volume de type bind mount
  ma_base_mysql:                     # Volume nommé géré par Docker

Dans cet exemple :

  • Le premier volume monte un dossier local dans le container (pratique pour le dev).
  • Le deuxième crée un espace de stockage géré par Docker (idéal pour la prod).

En gros, c'est la différence entre ramener ta propre garniture et utiliser celle du restaurant.

Les réseaux Docker : la table commune des pancakes

Tes containers ont besoin de communiquer entre eux. Ton PHP doit parler à ta base de données, ton serveur web doit choper ton PHP... C'est tout un écosystème de pancakes qui doivent s'échanger des trucs.

Par défaut, Docker Compose crée un réseau avec lequel tous tes services se voient automatiquement. C'est la magie :

# Dans ton docker-compose.yml
services:
  php:
    # ...
  db:
    # ...

# PHP peut accéder à la DB simplement avec "db" comme hostname.
# Exemple dans le code PHP : $db = new PDO('mysql:host=db;dbname=myapp');

Tu peux aussi créer des réseaux personnalisés pour isoler certains containers :

networks:
  frontend:  # Réseau pour l'interface web
  backend:   # Réseau pour les services internes

Les variables d'environnement : le sel secret des pancakes

Comme un chef qui ajuste l'assaisonnement selon le restaurant, tes applications ont besoin de s'adapter à leur environnement :

environment:
  - APP_ENV=production
  - DATABASE_URL=mysql://user:pass@db:3306/app

Ou avec un fichier .env pour ne pas mettre tes mots de passe en clair :

env_file:
  - .env.production

C'est comme avoir ta recette secrète à part, que tu peux changer sans toucher à ta cuisine.

Docker Hub : le livre de recettes collaboratif

Pourquoi inventer une recette de pancake quand des millions de chefs en ont déjà partagé ? Docker Hub, c'est le GitHub des images Docker :

docker pull mysql:8.0
docker pull php:8.2-fpm-alpine
docker pull nginx:alpine

Tu peux aussi y publier tes propres images :

docker build -t mon-username/mon-image:latest .
docker push mon-username/mon-image:latest

Maintenant, n'importe qui peut utiliser ta recette parfaite de pancake au chocolat fondant.

Dockerfile multi-stage : la préparation pro des pancakes

En cuisine pro, on prépare d'abord tous les ingrédients, puis on les assemble. En Docker, c'est pareil avec les builds multi-étapes :

# Étape de build - cuisine où on prépare tout
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Étape de production - juste ce qu'il faut pour servir
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

Résultat : une image finale minuscule qui ne contient que ce dont tu as besoin. Pas de déchets, pas d'outils de compilation, juste un pancake parfait prêt à être servi.

Les commandes Docker essentielles : le vocabulaire du chef pancake

Pour devenir un vrai pro du pancake, il faut connaître ces commandes :

# Construire une image
docker build -t mon-image:v1 .

# Lancer un container à partir d'une image
docker run -p 8080:80 mon-image:v1

# Voir les containers en cours d'exécution
docker ps

# Arrêter un container
docker stop mon-container

# Supprimer un container
docker rm mon-container

# Voir les logs d'un container
docker logs mon-container

# Exécuter une commande dans un container
docker exec -it mon-container bash

Avec Docker Compose, c'est encore plus simple :

# Démarrer tous les services
docker-compose up -d

# Voir les logs de tous les services
docker-compose logs

# Arrêter tous les services
docker-compose down

La sécurité Docker : parce que les pancakes empoisonnés, c'est pas cool

Ne fais pas tourner tes containers en tant que root, c'est comme laisser les clés de ta cuisine à un inconnu :

# Créer un utilisateur spécifique avec des droits limités
RUN adduser --disabled-password --gecos "" pancakeuser
USER pancakeuser

Et surveille les permissions sur les volumes :

volumes:
  - ./config:/app/config:ro  # ro = read-only

Pourquoi Docker ?

Parce que sans Docker, c'est ça :

  • "Ça marche sur ma machine" mais pas sur celle du collègue.
  • Des heures perdues à configurer des environnements.
  • Des conflits de dépendances qui te donnent envie de tout casser.
  • Des déploiements manuels qui te font suer à 2h du matin.

Avec Docker, c'est plutôt ça :

  • Chaque application est isolée (pas de conflit entre dépendances).
  • Déploiement instantané (t'appuies sur un bouton, c'est en prod).
  • Plus jamais un "ça marche chez moi, mais pas en prod".
  • Scaling horizontal facile quand ton site explose en popularité.

Pour aller plus loin : l'orchestration des pancakes à grande échelle

Quand ton restaurant de pancakes devient une chaîne mondiale, tu as besoin d'un système qui gère des milliers de mini-cuisines automatiquement. C'est là qu'interviennent :

  • Kubernetes : L'orchestrateur ultime qui gère des clusters entiers de containers. Il répartit la charge, remplace les containers qui tombent, et scale automatiquement.
  • Docker Swarm : La version simplifiée intégrée à Docker pour gérer des clusters.

Ces outils permettent de faire passer ta production de pancakes d'une cuisine amateur à une usine industrielle automatisée.

Conclusion : les pancakes Docker, c'est la vie

En résumé, Docker, c'est comme si chaque application avait sa propre petite cuisine avec tous ses ingrédients, ses ustensiles, et sa recette. Plus de conflits, plus de "mais chez moi ça marchait", plus de galères de déploiement.

Alors la prochaine fois qu'on te demande ce que tu fais dans la vie, tu peux dire : "Je suis un chef pancake spécialisé dans les micro-cuisines industrielles standardisées."

Et si on te regarde bizarrement, c'est qu'ils n'ont jamais goûté à la magie des containers.

Confidentialité

Ce site utilise Umami pour analyser le trafic de manière anonyme. Acceptez-vous la collecte de données anonymes ?