“Ça marche sur ma machine”

Si t’as jamais entendu cette phrase, soit tu bosses seul, soit tu mens. L’app tourne nickel sur ton laptop, tu push, et ça explose en prod. Mauvaise version de Python. Librairie manquante. Chemin de config foireux. Un classique

Docker règle ça en empaquetant ton app avec tout ce qu’il lui faut pour tourner. Même environnement partout. Ton laptop, le laptop du collègue, la staging, la prod. Identique

L’analogie du container maritime

Avant les containers standardisés, le transport de marchandises c’était le bordel. Chaque navire avait des cales différentes. Chaque port avait des équipements différents. Charger un bateau prenait des semaines parce que les dockers devaient trouver comment empiler des trucs de tailles bizarres

Et puis quelqu’un a inventé le container standard. Même taille partout. Les navires sont conçus pour. Les ports sont équipés. Maintenant tu peux envoyer des marchandises de Shanghai à Rotterdam sans jamais ouvrir la boîte

Les containers Docker c’est la même idée pour le software. Tu packages ton app une fois, tu la fais tourner n’importe où y a Docker. L’hôte s’en fout de ce qu’il y a dedans. Une app Python? Java? Un truc legacy bizarre de 2008? Osef. C’est un container, ça tourne

Les containers c’est pas des VMs

Ça embrouille beaucoup de monde. Les machines virtuelles émulent des ordinateurs entiers. Elles ont leur propre kernel, leur propre OS, leur propre tout. C’est lourd, lent à démarrer, gourmand en ressources

Les containers partagent le kernel de l’hôte. Ce sont juste des process isolés avec leur propre système de fichiers. Léger, rapide à démarrer, efficace

Vois ça comme ça: une VM c’est louer un appart entier. T’as ta propre cuisine, ta salle de bain, tes murs. Un container c’est avoir ta chambre dans une coloc. T’as ton intimité et tes affaires, mais tu partages la plomberie et l’électricité

C’est pour ça que tu peux faire tourner 50 containers sur un laptop mais galérer avec 5 VMs

Y a quoi dans un container

Une image de container contient:

• Le code de ton app
• Le runtime (Python, Node, Java, ce que tu veux)
• Les librairies système dont ton app a besoin
• Les fichiers de config
• Les variables d’environnement

Le tout empilé en couches. La couche de base c’est peut-être Ubuntu minimal. La couche suivante ajoute Python. Celle d’après tes dépendances. Celle du dessus ton code

Quand tu mets à jour ton code, Docker rebuild que la couche du haut. Le reste vient du cache. Des builds rapides, des téléchargements légers

Les bases

Pull une image:

docker pull python:3.11

Lance un container:

docker run -it python:3.11 python

T’es maintenant dans un shell Python à l’intérieur d’un container. Tu sors et il disparaît. Propre

Lance un truc utile:

docker run -d -p 8080:80 nginx

Ça fait tourner Nginx en tâche de fond, le port 80 dans le container mappé sur le 8080 de ta machine. Va sur localhost:8080, tu verras la page d’accueil Nginx

Liste les containers qui tournent:

docker ps

Arrêtes-en un:

docker stop <container_id>

Construis ta propre image

Voilà une app Python simple. Crée un fichier app.py:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
    return 'Hello from Docker!'

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Maintenant crée un Dockerfile:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY app.py .

EXPOSE 5000
CMD ["python", "app.py"]

Et un requirements.txt:

flask

Build:

docker build -t myapp .

Lance:

docker run -d -p 5000:5000 myapp

Va sur localhost:5000. Ton app tourne dans un container. Push cette image sur un registry et n’importe qui peut faire tourner exactement la même chose

L’argument du “j’ai qu’à utiliser virtualenv”

Ouais, virtualenv isole les packages Python. Mais ça isole pas:

• Les librairies système
• La version de Python elle-même
• Les dépendances au niveau OS
• Les chemins de fichiers
• Les variables d’environnement

Ton app a besoin d’ImageMagick? Faut espérer que le serveur de prod a la même version. Elle a besoin d’un OpenSSL spécifique? Bonne chance

Les containers embarquent tout ça. L’environnement entier voyage avec ton app

Quand Docker a du sens

Bons cas d’usage:

• Des environnements de dev cohérents dans une équipe
• Les pipelines CI/CD
• Déployer chez n’importe quel cloud provider
• Faire tourner plusieurs services en local
• Isoler les dépendances entre projets

Overkill:

• Des scripts simples que tu lances une fois
• Des outils locaux qui marchent très bien en natif
• Quand t’es le seul à faire tourner le truc

Containerise pas tout juste parce que tu peux. Mais pour tout ce qui doit tourner ailleurs, les containers te sauvent du “ça marche sur ma machine” pour toujours

Une dernière analogie

Pense à une recette vs un plat

Un Dockerfile c’est une recette. Elle liste les ingrédients (image de base), les étapes de préparation (commandes RUN), et comment servir (CMD)

Une image c’est un plat surgelé. Préparé une fois, stocké, réchauffable n’importe où

Un container c’est le plat en train d’être mangé. Actif, en train de faire son taf, terminé quand c’est fini

T’écris la recette une fois. Docker prépare le plat surgelé. Tu le fais tourner quand t’en as besoin, où t’en as besoin

Voilà. Les containers c’est pas magique. C’est juste une très bonne façon d’empaqueter du software pour qu’il tourne pareil partout. Une fois que t’as pigé ça, le reste c’est que des commandes et de la config