Qu’est ce qu’un Dockerfile : définition, rôle et instructions essentielles

Les instructions d’un Dockerfile (FROM, RUN, COPY, CMD)

Un Dockerfile se lit comme une recette : chaque ligne est une instruction suivie de ses arguments. Docker exécute ces instructions dans l’ordre pour fabriquer une image. Maîtriser une poignée de mots-clés suffit pour couvrir la grande majorité des besoins.

FROM, ARG et RUN : poser la base et exécuter

• FROM obligatoire, sauf ARG préalable : définit l’image de départ, comme python:3.11-slim ou alpine.
• ARG seule instruction avant FROM : permet de passer une variable de build dès la première ligne.
• Chaque RUN crée une couche : les commandes sont exécutées par /bin/sh -c et laissent une trace dans l’image.

COPY, ADD, ENV, CMD et ENTRYPOINT : copier et configurer

• COPY vs ADD : COPY copie des fichiers locaux, ADD gère en plus les URL et les archives compressées.
• ENV persistant au runtime : la variable reste disponible une fois le conteneur lancé.
• ARG limité au build : sa valeur disparaît après la construction de l’image.
• CMD remplaçable, ENTRYPOINT non : CMD peut être écrasée au démarrage, ENTRYPOINT reste figée.

Ces quelques instructions couvrent l’essentiel des Dockerfiles que vous croiserez. Pour aller plus loin, les options , chown et , chmod sur COPY permettent d’ajuster les droits des fichiers copiés sous certaines conditions. Un détail qui évite bien des erreurs de permissions en production.

Qu’est ce qu’un Dockerfile : définition et rôle

Un Dockerfile est un simple fichier texte brut, sans extension, qui décrit les étapes de création d’une image Docker. Il s’écrit avec un nom commençant obligatoirement par une majuscule (Dockerfile), et le daemon Docker l’exécute ligne par ligne, dans l’ordre, pour produire une image prête à l’emploi.

Sa raison d’être tient en une chaîne simple : Dockerfile vers image vers conteneur. Le fichier décrit la recette, l’image est le résultat figé de cette recette, et le conteneur est l’instance en cours d’exécution de cette image. Sans Dockerfile, chaque environnement devrait être reconstruit à la main.

Construire une image depuis un Dockerfile

Cette image peut ensuite être déployée sur un serveur exposé, où les connexions d’administration gagnent à transiter par un bastion informatique qui filtre les accès et journalise chaque session.

La commande docker build pas à pas

Tout part d’une seule commande : docker build. Lancée depuis le dossier qui contient votre fichier, elle envoie le contexte de build au démon Docker, qui lit chaque instruction et assemble les couches une par une.

• docker build -t mon-image . : construit et nomme l’image
• python:3.11-slim : image de base légère recommandée pour Python
• WORKDIR /app : crée le dossier et s’y positionne
• pip install, no-cache-dir : installe sans conserver le cache
• CMD [« python », « app.py »] : lance l’application au démarrage
• docker images : vérifie que l’image est bien créée

La structure du projet et le fichier final

Avant de lancer la construction, rangez votre projet proprement. Un dossier de travail, par exemple docker-python, contenant le fichier Dockerfile (sans extension), votre app.py et le fichier requirements.txt. Le nom prend une majuscule par convention.

Le fichier final ressemble à ceci : une ligne FROM python:3.11-slim, un WORKDIR /app, un COPY requirements.txt . suivi du RUN pip install, no-cache-dir -r requirements.txt, puis la copie du code et le CMD de lancement. Une fois la commande exécutée, docker images affiche votre image avec son identifiant et sa taille. Vous pouvez alors démarrer un conteneur et tester votre application.

Comment fonctionne un Dockerfile (layers et processus de build)

Quand vous lancez docker build, le daemon lit votre fichier ligne par ligne. Chaque instruction exécutée (FROM, RUN, COPY…) génère une nouvelle couche empilée sur la précédente. Ces couches sont en lecture seule : elles constituent la base immuable de l’image finale.

Au sommet de la pile, Docker ajoute une couche éditable réservée au conteneur en cours d’exécution. C’est ce qui explique la rapidité de démarrage : les couches basses ne bougent jamais, seul le dernier niveau est modifié. Une image n’est donc rien d’autre qu’un assemblage ordonné de couches.

Le cache de build découle directement de ce mécanisme. Docker compare chaque instruction à sa version précédente : si rien n’a changé, il réutilise la couche en cache au lieu de la reconstruire. Dès qu’une ligne diffère, toutes les couches suivantes sont régénérées. C’est pourquoi placer les instructions stables (installation des dépendances) avant les instructions volatiles (copie du code source) accélère considérablement vos builds.

Structure et syntaxe d’un Dockerfile

Un Dockerfile se lit comme un fichier de recette : chaque ligne est une consigne que le docker daemon exécute dans l’ordre, du haut vers le bas. La syntaxe est volontairement simple, ce qui explique pourquoi un débutant peut écrire son premier fichier valide en quelques minutes. Voici les règles structurelles à connaître avant de rédiger quoi que ce soit.

• Commentaires avec # : le préfixe # transforme une ligne en commentaire ignoré par le build.
• Directives parser une seule fois : les directives comme syntax se placent en tête, jamais ailleurs.
• Une instruction par ligne : chaque ligne porte une seule commande, sans exception.
• Instruction suivie d’arguments : FROM python:3.11-slim illustre ce schéma instruction plus arguments.
• Commentaires supprimés au build : les lignes # disparaissent de l’image finale.

Directives parser et positionnement

Les directives parser ne sont pas des instructions à proprement parler. Elles indiquent au moteur comment interpréter le fichier et doivent apparaître une seule fois, tout en haut du Dockerfile.

La directive la plus courante est # syntax=docker/dockerfile:1. Elle fixe la version du parseur et conditionne l’accès à certaines options comme , chown et , chmod sur l’instruction COPY, disponibles sous certaines conditions seulement. Sans cette ligne, ces options peuvent être rejetées au build.

Lignes, commentaires et lisibilité

Chaque instruction occupe une ligne distincte et se compose d’un mot clé suivi de ses arguments. Les lignes de commentaire, préfixées par #, sont retirées de l’image finale : elles n’alourdissent donc jamais le résultat.

Pour les commandes longues, il est courant d’utiliser le backslash en fin de ligne afin de poursuivre l’instruction sur la ligne suivante. Cette pratique améliore la lisibilité sans casser la règle d’une instruction par ligne logique.

Exemple concret : premier Dockerfile pas à pas

Rien de tel qu’un projet simple pour comprendre la mécanique. Nous allons dockeriser une petite application Flask rangée dans un dossier nommé docker-python. L’objectif n’est pas de maîtriser Flask, mais de voir comment un Dockerfile transforme quelques fichiers en une image exécutable.

Préparation du projet Flask

Commencez par créer le dossier docker-python, puis placez-y trois éléments : un fichier app.py qui affiche un message, un fichier requirements.txt listant flask, et le futur Dockerfile. Cette séparation est volontaire : les dépendances dans un fichier dédié permettent de profiter du cache de build lors des reconstructions.

Le fichier requirements.txt contient une seule ligne, le nom du paquet Flask. Quant à app.py, il définit une route qui renvoie un texte de bienvenue. Une fois ces deux fichiers en place, le projet est prêt à être décrit par le Dockerfile.

Écriture et test du Dockerfile

Créez maintenant un fichier texte portant exactement le nom Dockerfile, sans extension, avec une majuscule. Son contenu s’articule autour de quelques instructions simples.

• Directive syntax en tête pour indiquer la version Docker utilisée
• WORKDIR /app rappelé avant le COPY pour définir la destination
• Nom sans extension obligatoire pour que le daemon le reconnaisse
• Builder puis lister l’image via docker build et docker images

Lancez ensuite docker build -t mon-app . depuis le dossier du projet. Le daemon lit chaque ligne et construit l’image couche par couche. Une fois terminé, docker images affiche votre image dans la liste locale.

Il ne reste plus qu’à démarrer un conteneur avec docker run pour vérifier que l’application répond correctement.

Bonnes pratiques et optimisation d’un Dockerfile

Pour des images fiables et légères, évitez le tag latest et préférez des versions figées ou des digests. Choisissez des bases minimales comme alpine ou des variantes slim, telles que python:3.11-slim, afin de réduire drastiquement la taille finale de l’image.

Chaînez vos commandes RUN avec && pour limiter le nombre de couches, et ajoutez des options comme , no-cache-dir pour pip ou , no-cache pour Alpine. Créez un fichier .dockerignore pour exclure les fichiers inutiles du contexte de build et accélérer la construction.

Adoptez le multi-stage pour séparer l’environnement de build de celui d’exécution, ce qui allège considérablement l’image finale. Ne stockez jamais de secrets dans les instructions ENV ou ARG : ils resteraient visibles dans l’historique de l’image.