Conteneurs — Création d’images

Docker & OCI

Lecture
Containers
Docker
Apprenez à créer, optimiser et publier des images de conteneurs Docker en utilisant des Dockerfiles, avec un focus sur les bonnes pratiques de sécurité et de performance.
Auteur
Affiliations

Emmanuel BRUNO

Université de Toulon

LIS UMR CNRS 7020

Date de publication

2026-02-01

Environnement et reproductibilite

Jupyter Kernel: bash

🖥️ Env Ubuntu 24.04.3 LTS / x86_64 • 🐳 Docker Client 29.1.5 / Server 29.1.5 • 🌿 Git Branch @ 7b914bd

Ce support a été généré par Quarto : les cellules sont exécutées par le noyau indiqué lors du rendu.

Certaines parties ont été rédigées avec l’assistance d’un modèle de langage ; le contenu a été relu et validé par l’auteur.

Objectifs

À la fin de ce cours, vous saurez :

  • Comprendre la structure d’une image OCI
  • Créer une image manuellement (et pourquoi éviter)
  • Construire une image avec un Dockerfile
  • Utiliser ENTRYPOINT et CMD
  • Optimiser avec les builds multi-étapes
  • Publier et analyser une image

Images de conteneurs (OCI)

Une image suit la spécification OCI (Open Container Initiative).

  • Ensemble de couches en lecture seule
  • Chaque couche = delta par rapport à la précédente
  • Métadonnées séparées (CMD, ENV, labels…)
  • Nom d’image formel — syntaxe générale : [[registry/][namespace/]repository[:tag][@digest]].
    • repository : partie obligatoire qui identifie le dépôt (nom du répertoire).
    • registry : hôte du registre (optionnel); si absent on entend en pratique le registre Docker Hub (docker.io).
    • namespace : segment optionnel pour regrouper les dépôts (sur Docker Hub, l’espace library est implicite pour les images officielles).
    • tag : référence optionnelle lisible (ex. :latest, :1.2.3); si aucun tag n’est fourni, latest est couramment utilisé comme valeur par défaut pour l’usage, mais l’absence de tag signifie que l’image peut aussi être désignée par un digest.
    • digest : identifiant immuable optionnel (forme sha256:<hex>); lorsqu’il est présent (@digest) il prend la priorité sur le tag pour désigner de façon exacte une image. (Les parties entre crochets [] sont optionnelles selon la spécification de référence des images.)

➡️ Une image n’est pas un conteneur mais le modèle de fichier utilisé pour en créer un ou plusieurs.

Exemple : Ubuntu

  • pull commande pour récupérer une image depuis un registry
    • Les registries sont des dépôts d’images (Docker Hub, GitHub Container Registry, etc.)
  • Image officielle Ubuntu : ubuntu:jammy
  • Basée sur plusieurs couches empilées
docker pull ubuntu:jammy
jammy: Pulling from library/ubuntu
Digest: sha256:c7eb020043d8fc2ae0793fb35a37bff1cf33f156d4d4b12ccc7f3ef8706c38b1
Status: Image is up to date for ubuntu:jammy
docker.io/library/ubuntu:jammy
  • Liste des couches
docker history ubuntu:jammy
IMAGE          CREATED       CREATED BY                                      SIZE      COMMENT
c7eb020043d8   2 weeks ago   /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B        
<missing>      2 weeks ago   /bin/sh -c #(nop) ADD file:b499000226bd9a7c5…   85.6MB    
<missing>      2 weeks ago   /bin/sh -c #(nop)  LABEL org.opencontainers.…   0B        
<missing>      2 weeks ago   /bin/sh -c #(nop)  LABEL org.opencontainers.…   0B        
<missing>      2 weeks ago   /bin/sh -c #(nop)  ARG LAUNCHPAD_BUILD_ARCH     0B        
<missing>      2 weeks ago   /bin/sh -c #(nop)  ARG RELEASE                  0B
  • dans docker history (même après un pull)
    • Docker ne peut pas afficher l’ID d’une couche.
      • l’historique stocké dans l’image ne contient pas toujours les IDs des couches,
      • ou Docker n’a pas conservé ces couches dans son cache local.

Architecture en couches

Avantages :

  • Mutualisation des couches communes
  • Réduction de l’espace disque
  • Téléchargement incrémental
  • Cache efficace lors des builds

Création manuelle d’une image

Méthode possible mais déconseillée :

  1. Lancer un conteneur
  2. Modifier le système de fichiers
  3. Valider avec docker commit
  • ❌ Non reproductible
  • ❌ Historique opaque
  • ❌ Mauvaise pratique en production

Exemple : installer Git manuellement

  • Lancer un conteneur Ubuntu : docker run --name my-ubuntu --interactive ubuntu:jammy bash

  • Installer Git en interactif : apt-get update && apt-get install -y git

  • Valider l’image et supprimer le conteneur intermédiaire.

docker commit my-ubuntu mygit:latest
docker rm my-ubuntu
sha256:b2d89165b41699efa2f726735b3d02bff153a97a14e26237ee9bdbe36d524057
my-ubuntu
  • Une nouvelle image mygit:latest est créée.
docker run --rm mygit git --version
git version 2.34.1
  • Historique de l’image mygit.
docker history mygit
IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
b2d89165b416   3 seconds ago   bash -                                          156MB     
c7eb020043d8   2 weeks ago     /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B        
<missing>      2 weeks ago     /bin/sh -c #(nop) ADD file:b499000226bd9a7c5…   85.6MB    
<missing>      2 weeks ago     /bin/sh -c #(nop)  LABEL org.opencontainers.…   0B        
<missing>      2 weeks ago     /bin/sh -c #(nop)  LABEL org.opencontainers.…   0B        
<missing>      2 weeks ago     /bin/sh -c #(nop)  ARG LAUNCHPAD_BUILD_ARCH     0B        
<missing>      2 weeks ago     /bin/sh -c #(nop)  ARG RELEASE                  0B

➡️ Une seule couche opaque ajoutée

Dockerfile (méthode recommandée)

  • Fichier texte avec instructions pour construire une image

Avantages :

  • Reproductible
  • Versionnable (Git)
  • Automatisable
  • Lisible
# Exemple simple
FROM ubuntu:jammy
RUN apt-get update && apt-get install -y git
ENTRYPOINT ["git"]
CMD ["--version"]

Exercice 1 — Une Image Docker simple

Faire l’exercice :

Pratique Container Image — Exercice 1

Dockerfile — Structure de base

✅ Cloned new repository: ebpro/notebook-containers-intro-sample-python-helloworld

Détails 
git clone -b develop https://github.com/ebpro/notebook-containers-intro-sample-python-helloworld
/home/jovyan/work/examples/github/ebpro/notebook-containers-intro-sample-python-helloworld
├── Dockerfile
├── hello.py
└── requirements.txt

1 directory, 3 files
# syntax=docker/dockerfile:1

# Choose the parent image
FROM python:3.12-slim

# An argument sets at build command with --build-arg
# It as a default value
ARG BUILD_DATE=1970-01-01T00:00:00Z

# key-value pair as image metadata
LABEL maintainer="emmanuel.bruno@univ-tln.fr"
# See http://label-schema.org/rc1/ for a list of usefull labels
LABEL org.label-schema.build-date=$BUILD_DATE

# An environment variable
ENV NAME="John Doe"

# Creates and moves to a directory
WORKDIR /app

# Copy the requirements them in the new image.
# Done before the copy of the src to limit cache invalidations
# when only source code changes.
COPY requirements.txt ./

# Installation of the dependencies
RUN pip install --requirement requirements.txt

# Copy the sources
COPY hello.py ./

# Set the entrypoint for the image (keeps command arguments overrideable)
ENTRYPOINT ["python", "/app/hello.py"]

Build d’une image

  • Commande docker image build
  • Contexte de build : répertoire avec Dockerfile
docker image build \
  --quiet \
  .
sha256:4007cbc112f99c2c400495e28dafdc296fbf9f5810ac91f95d1b9c6215ed7360

ℹ️ Le . est le contexte de build

Gestion des tags 1/2

Bonnes pratiques :

  • Option --tag / -t pour nommer l’image
  • Tag multiples pour une même image avec versionnage sémantique (semver) :
    • Versions complètes : 1.2.3
    • Versions majeures : 1, 1.2
    • Alias : latest
  • Format : [registry/][namespace/]repository:tag
    • ${DOCKERHUB_USERNAME} = votre nom d’utilisateur Docker Hub (ou autre registry)

Gestion des tags 2/2

Tag à la construction (--tag / -t) :

docker image build \
  --quiet \
  --tag docker.io/${DOCKERHUB_USERNAME}/helloworld:0.0.1 \
  .
sha256:0ed25399830b08cbe01874b88ad89c81adc5c9d16293de0aebe82d0617c9e4ad

Tag additionnels (docker tag) :

docker image tag docker.io/${DOCKERHUB_USERNAME}/helloworld:0.0.1 \
  docker.io/${DOCKERHUB_USERNAME}/helloworld:0
docker image tag docker.io/${DOCKERHUB_USERNAME}/helloworld:0.0.1 \
  docker.io/${DOCKERHUB_USERNAME}/helloworld:latest

Utilisation de l’image

  • Commande docker run
  • -e / --env pour variables d’environnement dans le conteneur
docker run --rm docker.io/${DOCKERHUB_USERNAME}/helloworld
WARNING:root:Hello John Doe,  I'm Python in a container !
docker run --rm -e NAME=Pierre docker.io/${DOCKERHUB_USERNAME}/helloworld:0.0.1
WARNING:root:Hello Pierre,  I'm Python in a container !

Exercice 2 — ARG et ENV

Faire l’exercice :

Pratique Container Image — Exercice 1

Publication sur un registry

Étapes :

  1. Build + Tag correct : registry + namespace (nom d’utilisateur).
  2. Authentification sur le registry
docker push docker.io/${DOCKERHUB_USERNAME}/app:latest
echo $DOCKERHUB_TOKEN | docker login \
  --username ${DOCKERHUB_USERNAME} \
  --password-stdin
  1. Push
docker push docker.io/${DOCKERHUB_USERNAME}/app:latest

HEALTHCHECK

L’instruction HEALTHCHECK permet de définir une commande pour vérifier la santé d’un conteneur en cours d’exécution. Docker exécute périodiquement cette commande et utilise son code de retour pour déterminer l’état du conteneur : 0 (sain), 1 (non sain) ou 2 (réservé).

Exemple :

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD curl --max-time 30 -f http://localhost/ || exit 1

Options principales :

  • --interval: fréquence de vérification (ex. 30s).
  • --timeout: délai maximum d’exécution de la commande (ex. 3s).
  • --start-period: délai initial avant la première vérification (ex. 5s).
  • --retries: nombre d’échecs consécutifs avant de considérer le conteneur comme non sain.

Les HEALTHCHECK sont utiles pour l’orchestration (restart policies, load balancers) et pour détecter des services défaillants.

Sécurité — Bonnes pratiques

Principes essentiels pour réduire la surface d’attaque et rendre les images sûres :

  • Images minimalistes : choisir des bases petites (Alpine, distroless) ou builder multi-étapes pour ne garder que l’exécutable final.
  • Éviter les secrets dans l’image : ne jamais écrire de mots de passe/jetons dans les Dockerfile. Utiliser BuildKit secrets (--mount=type=secret) ou des volumes/variables d’environnement au runtime.
  • Ne pas exécuter en root : définir un utilisateur non-root dans le Dockerfile.
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
  • Pinning & immutabilité : référencer des images par digest (@sha256:...) ou pinner les versions de paquets pour éviter des mises à jour non contrôlées.
  • Nettoyage des artefacts : supprimer les caches d’installateurs et réduire le nombre de layers (ex. apt-get clean && rm -rf /var/lib/apt/lists/*).
  • Scanner et vérifier : utiliser des scanners (ex. docker scan, trivy) et générer un SBOM. Ex : trivy image --severity HIGH,CRITICAL myimage:latest.
  • Limiter les privilèges au runtime : appliquer des profiles seccomp/AppArmor, retirer les capacités inutiles (--cap-drop), monter le FS en lecture seule quand possible (--read-only).
  • Ressources et isolation : définir limites mémoire/CPU et pids pour limiter l’impact d’un processus compromis.

ENTRYPOINT vs CMD

  • Pour définir le comportement par défaut d’une image
    • Une image peut définir un ENTRYPOINT et un CMD
  • ENTRYPOINT + CMD = commande complète
  • Si CMD absent, arguments passés à docker run sont ajoutés à ENTRYPOINT
  • Si ENTRYPOINT absent, docker run utilise CMD ou les arguments passés
  • ENTRYPOINT : commande principale
  • CMD : arguments par défaut
Directive Rôle
ENTRYPOINT Comportement principal
CMD Paramètres remplaçables 
ENTRYPOINT ["git"]
CMD ["--version"]
docker run mygit
docker run mygit status

➡️ Image utilisable comme un programme

Multi-stage build

Objectifs :

  • Séparer build et runtime
  • Réduire la taille finale
  • Supprimer toolchains et sources

Fonctionnement :

  • Plusieurs étapes FROM dans un Dockerfile
  • Chaque étape peut copier des artefacts de l’étape précédente (COPY --from=...)
  • L’étape finale est l’image résultante

Exemple multi-étapes (C)

✅ Cloned new repository: ebpro/notebook-containers-intro-sample-c

Détails 
git clone -b develop https://github.com/ebpro/notebook-containers-intro-sample-c
# Build stage
FROM gcc:14-bookworm AS builder

# An argument sets at build command with --build-arg
# It as a default value
ARG BUILD_DATE=1970-01-01T00:00:00Z

# key-value pair as image metadata
LABEL maintainer="emmanuel.bruno@univ-tln.fr"
# See http://label-schema.org/rc1/ for a list of usefull labels
LABEL org.label-schema.build-date=$BUILD_DATE

WORKDIR /src/app
COPY helloworld.c .
RUN gcc -Wall -Wextra -Werror -O2 -fPIE -pie -D_FORTIFY_SOURCE=2 -static-libgcc helloworld.c -o helloworld

# Runtime stage
FROM debian:bookworm-slim

# Create non-root user
RUN groupadd -r appuser && useradd -r -g appuser appuser
WORKDIR /app

# Copy only the compiled binary
COPY --from=builder --chown=appuser:appuser /src/app/helloworld /app/helloworld

# Switch to non-root user
USER appuser

# Set executable permissions
RUN chmod 550 /app/helloworld

ENTRYPOINT ["/app/helloworld"]
docker image build \
     --quiet \
     --tag ${DOCKERHUB_USERNAME}/helloworld_c:0.0.1 \
     .

docker run --rm ${DOCKERHUB_USERNAME}/helloworld_c:0.0.1 Paul
sha256:83c16f8c089cb38f210e331393a13b70cf799de456d510d68dca2eefb96bf214
Hello Paul!

Résultat

  • Chaîne de build est versionnable, reproductible (gcc, sources, etc. dans le Dockerfile)
  • Image finale très légère (uniquement l’exécutable + libs)
    • Aucun compilateur présent
    • Sécurité accrue
    • Démarrage rapide

Exposition des ports

  • EXPOSE dans le Dockerfile pour documenter les ports utilisés
  • -p / --publish dans docker run pour mapper les ports
  • Exemple : application web sur le port 80

Dans le Dockerfile :

EXPOSE 80
docker run -p 8080:80 myapp

ℹ️ EXPOSE ne publie pas le port, il documente seulement.

Exercice 3 — Multi-stage build

Faire l’exercice :

Pratique Container Image — Exercice 3

Sécurité — Bonnes pratiques

  • Images minimalistes
  • Utilisateur non-root
  • Pas de secrets dans l’image
  • Scan des vulnérabilités

Utilisateur non-root

RUN adduser -D appuser
USER appuser

Secrets avec BuildKit

  • Attention : ne pas inclure de secrets dans l’image finale
    • JAMAIS dans ENV ni non plus dans ARG (persistants dans l’image)
    • Utiliser les secrets temporaires de BuildKit
FROM alpine:3.18

# Dépendance nécessaire
RUN apk add --no-cache curl

# ARG pour une valeur non sensible (ex : URL ou nom d'environnement)
ARG API_URL=https://example.com/secure-data

# Utilisation du secret via BuildKit
RUN --mount=type=secret,id=api_key \
    curl --max-time 30 -H "Authorization: Bearer $(cat /run/secrets/api_key)" \
    ${API_URL} -o /tmp/data.json

# On peut ajouter un step pour vérifier que le fichier existe
RUN test -f /tmp/data.json

CMD ["cat", "/tmp/data.json"]
docker build \
  --secret id=api_key,src=./api_key.txt \
  -t myapp:latest .

Multi-architecture (buildx)

  • Construire pour plusieurs architectures (amd64, arm64, etc.)
  • Utiliser docker buildx ou docker build --platform
#| echo: true
#| output: true
docker build \
  --platform linux/amd64,linux/arm64 \
  -t docker.io/${DOCKERHUB_USERNAME}/helloworld_c:0.0.1 \
  .
  • ℹ️ Pour publier une image multi-architecture sur un registry, utiliser docker buildx build --push.

À retenir

  • Une image ≠ un conteneur
  • Dockerfile pour créer des images
  • ENTRYPOINT définit le comportement
  • CMD fournit des arguments par défaut
  • Multi-stage sépare build et runtime
  • push Publier sur un registry
  • Toujours penser sécurité & reproductibilité

Réutilisation