Docker Build Args : Le guide ultime pour les professionnels des données

Implications en matière de sécurité et atténuation des risques

Bien que les arguments de construction offrent de la flexibilité, ils introduisent également des risques de sécurité potentiels que vous devez comprendre pour garder vos images Docker sécurisées.

Vecteurs de fuite d'arguments

Les arguments en faveur de la construction ne sont pas aussi privés que vous le pensez. Les valeurs des args de compilation peuvent fuir à travers plusieurs vecteurs que de nombreux développeurs négligent. Tout d'abord, l'historique de l'image Docker expose tous vos args de construction, ce qui signifie que toute personne ayant accès à votre image peut exécuter docker history pour voir les valeurs que vous avez utilisées pendant la construction, y compris des informations potentiellement sensibles telles que les clés d'API ou les jetons.

docker history flaskapp:dev

Image 4 - Historique de Docker

Les couches intermédiaires peuvent également laisser échapper des arguments de construction. Même si vous utilisez une compilation en plusieurs étapes et que vous ne copiez pas la couche contenant des informations sensibles, les valeurs arg de la compilation restent dans le cache de la couche sur la machine de compilation. Cela signifie que toute personne ayant accès au démon Docker sur votre serveur de construction peut potentiellement extraire ces informations.

Les journaux CI/CD présentent un autre risque important. La plupart des systèmes CI/CD enregistrent l'intégralité de la commande de compilation, y compris les arguments de compilation transmis sur la ligne de commande.

Par exemple, l'ensemble de cette commande, y compris API_KEY, sera visible dans les journaux de CI/CD :

docker build --build-arg API_KEY=secret123 -t myapp:latest .

Ces journaux sont souvent accessibles à un groupe plus large de développeurs ou même stockés dans des systèmes tiers, ce qui augmente la surface d'exposition des valeurs sensibles.

Alternatives sécurisées

Pour les informations sensibles, vous devriez utiliser la fonction secrets de Docker BuildKit au lieu des args de construction. BuildKit vous permet de monter des secrets pendant le processus de construction sans les persister dans l'image finale ou dans l'historique.

Voici un exemple de fichier Docker qui utilise les secrets de Docker BuildKit :

FROM python:3.13-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

# Use secret mount instead of build arg
RUN --mount=type=secret,id=api_key \
    cat /run/secrets/api_key > api_key.txt

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

Pour construire cette image avec un secret, créez d'abord le fichier api_key.txt:

echo "my-secret-api-key" > api_key.txt

Ensuite, construisez l'image avec le secret :

DOCKER_BUILDKIT=1 docker build \
  --secret id=api_key,src=api_key.txt \
  -t flaskapp:secure .

Image 5 - Construire des images avec les secrets de BuildKit

Pour la configuration qui doit être disponible au moment de l'exécution, les variables d'environnement restent l'approche préférée. Ils peuvent être définis au démarrage d'un conteneur sans être intégrés à l'image :

# Set environment variables at runtime
docker run -e API_KEY=secret123 -p 5000:5000 flaskapp:latest

Pour gérer en toute sécurité une configuration sensible en production, envisagez d'utiliser des plateformes d'orchestration de conteneurs comme Kubernetes, qui proposent des méthodes sécurisées comme Secrets pour gérer les informations sensibles. Docker Swarm offre également des capacités similaires avec sa gestion des secrets.

> Docker n'est pas la seule plateforme de conteneurisation. Lisez Podman pour savoir quel outil est le mieux adapté à votre situation.

Rappelez-vous, la règle de base est la suivante : utilisez les args de compilation pour la configuration de la compilation qui n'est pas sensible, utilisez les secrets BuildKit pour les besoins sensibles de la compilation, et utilisez les variables d'environnement ou les secrets de la plateforme d'orchestration pour la configuration de l'exécution.

Intégration avec les écosystèmes de conteneurs

Maintenant que les bases sont posées, explorons comment exploiter les arguments de construction dans les écosystèmes Docker plus larges et les outils de construction modernes.

Docker Compose

Docker Compose facilite la définition et le partage des arguments de construction dans vos applications multi-conteneurs.

Si vous voulez suivre, voici une structure de projet complète pour deux services Flask simples :

flask-project/
├── docker-compose.yml         # Main compose configuration
├── .env                       # Environment variables for compose
├── web/
│   ├── Dockerfile             # Web service Dockerfile
│   ├── app.py                 # Flask application
│   └── requirements.txt       # Python dependencies
├── api/
│   ├── Dockerfile             # API service Dockerfile
│   ├── app.py                 # API Flask application  
│   └── requirements.txt       # API dependencies

Je vais passer rapidement en revue le contenu des fichiers un par un :

web/app.py

from flask import Flask, render_template

app = Flask(__name__)


@app.route("/")
def index():
    return render_template("index.html", title="Flask Web App")


@app.route("/about")
def about():
    return "About page - Web Service"


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000, debug=True)

web/requirements.txt

flask==3.1.0

web/Dockerfile

# Web service Dockerfile
ARG PYTHON_VERSION=3.13

FROM python:${PYTHON_VERSION}-slim

# Redeclare the build arg to use it after FROM
ARG PYTHON_VERSION
ARG ENVIRONMENT=production

# Set environment variables
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
ENV FLASK_ENV=${ENVIRONMENT}

WORKDIR /app

# Copy and install requirements
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy application code
COPY . .

# Create a simple template folder and file if not exists
RUN mkdir -p templates && \
    echo "<html><body><h1>Hello from Web Service</h1><p>Python version: ${PYTHON_VERSION}</p><p>Environment: ${ENVIRONMENT}</p></body></html>" > templates/index.html

EXPOSE 5000

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

api/app.py

from flask import Flask, jsonify

app = Flask(__name__)


@app.route("/api/health")
def health():
    return jsonify({"status": "healthy"})


@app.route("/api/data")
def get_data():
    return jsonify(
        {"message": "Hello from the API service", "items": ["item1", "item2", "item3"]}
    )


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000, debug=True)

api/requirements.txt

flask==3.1.0

api/Dockerfile

ARG PYTHON_VERSION=3.13

FROM python:${PYTHON_VERSION}-slim

# Redeclare the build arg to use it after FROM
ARG PYTHON_VERSION
ARG ENVIRONMENT=production

# Set environment variables
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
ENV FLASK_ENV=${ENVIRONMENT}

WORKDIR /app

# Copy and install requirements
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy application code
COPY . .

# Add metadata label based on build args
LABEL python.version="${PYTHON_VERSION}" \
      app.environment="${ENVIRONMENT}"

EXPOSE 8000

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

.env

PYTHON_VERSION=3.10
ENVIRONMENT=development

docker-compose.yml

services:
  web:
    build:
      context: ./web
      dockerfile: Dockerfile
      args:
        PYTHON_VERSION: ${PYTHON_VERSION:-3.13}
        ENVIRONMENT: ${ENVIRONMENT:-development}
    ports:
      - "5000:5000"
    depends_on:
      - api
    
  api:
    build:
      context: ./api
      dockerfile: Dockerfile
      args:
        PYTHON_VERSION: ${PYTHON_VERSION:-3.13}
        ENVIRONMENT: ${ENVIRONMENT:-production}
    ports:
      - "8000:8000"

En bref, il s'agit d'un moyen très simple de démarrer deux applications dans des environnements isolés, toutes les deux en même temps, toutes les deux avec un ensemble spécifique d'arguments de construction.

Vous pouvez utiliser cette commande pour exécuter la configuration multi-conteneurs :

docker compose up --build

Image 6 - Construire des args avec Docker Compose

Après quelques secondes, vous verrez les deux services fonctionner :

Image 7 - Construire des args avec Docker Compose (2)

C'est une configuration assez verbeuse pour des applications aussi simples que ces deux-là, mais vous avez une vue d'ensemble - les arguments de construction sont définis dans le fichier compose et référencés dans les Dockerfiles individuels.

Par ailleurs, vous pouvez également passer des valeurs variables de votre environnement aux args de construction, ce qui est pratique pour les pipelines CI/CD :

services:
  web:
    build:
      context: .
      args:
        - PYTHON_VERSION=${PYTHON_VERSION:-3.10}

Pour remplacer ces valeurs lors de l'exécution de docker-compose, vous pouvez utiliser des variables d'environnement :

PYTHON_VERSION=3.10 docker-compose up --build

Cette approche vous permet de maintenir des constructions cohérentes au sein de votre équipe tout en offrant une certaine flexibilité en cas de besoin.

Caractéristiques de BuildKit

BuildKit, le moteur de construction moderne de Docker, renforce votre processus de construction avec des fonctionnalités qui rendent l'utilisation des args de construction encore plus puissante. Lorsque vous activez BuildKit (en définissant DOCKER_BUILDKIT=1), vous débloquez quelques nouvelles fonctionnalités.

Le cache en ligne améliore les performances de construction en exploitant le cache de construction de l'image distante. Vous pouvez spécifier une image source à utiliser comme cache avec l'option --cache-from, et BuildKit utilisera intelligemment les couches de cette image :

DOCKER_BUILDKIT=1 docker build \
  --build-arg PYTHON_VERSION=3.10 \
  --cache-from flaskapp:dev \
  -t flaskapp:latest .

Les sorties déterministes, qui garantissent la reproductibilité de vos constructions, constituent une autre fonctionnalité précieuse de BuildKit. C'est essentiel lorsque vous souhaitez obtenir exactement la même image, quel que soit le moment ou l'endroit où elle est construite :

# Build with deterministic output
DOCKER_BUILDKIT=1 docker build \
  --build-arg PYTHON_VERSION=3.10 \
  --build-arg BUILD_DATE=2025-05-01 \
  --output type=docker,name=flaskapp:stable \
  .

La rédaction secrète des journaux de BuildKit protège les informations sensibles pendant la construction. 

Contrairement aux args de compilation classiques, qui apparaissent dans les journaux de compilation, BuildKit cache automatiquement les valeurs des secrets :

# Create a file with the API key
echo "my-api-key-value" > ./api-key.txt

# Build with secret (value won't appear in logs)
DOCKER_BUILDKIT=1 docker build \
  --secret id=api_key,src=./api-key.txt \
  -t flaskapp:secure .

Dans votre fichier Docker, vous accédez à ce secret avec :

RUN --mount=type=secret,id=api_key \
    cat /run/secrets/api_key > /app/config/api_key.txt

Ces fonctionnalités de BuildKit travaillent ensemble avec les args de construction pour créer un système de construction plus sûr, plus efficace et plus reproductible qui peut s'adapter à pratiquement n'importe quel flux de travail de conteneurisation.

Meilleures pratiques pour l'adoption par les entreprises

La mise en œuvre d'arguments de construction Docker au sein de grandes équipes nécessite des approches standardisées, du moins si vous souhaitez minimiser la confusion et maximiser les avantages en termes de sécurité et de performance.

Lorsque vous adoptez des arguments de compilation dans des environnements d'entreprise, commencez par une validation correcte des arguments. 

Fournissez toujours des valeurs par défaut raisonnables pour chaque argument de construction afin de vous assurer que les constructions n'échouent pas de manière inattendue lorsque les arguments ne sont pas fournis. Vous devez également ajouter des contrôles de validation dans votre fichier Docker pour vérifier que les paramètres de construction critiques répondent à vos exigences.

Voici un exemple qui valide la version de Python :

ARG PYTHON_VERSION=3.9
# Validate Python version
RUN if [[ ! "$PYTHON_VERSION" =~ ^3\.[0-9]+$ ]]; then \
      echo "Invalid Python version: ${PYTHON_VERSION}. Must be 3.x"; \
      exit 1; \
    fi

L'optimisation de la mise en cache des couches est cruciale pour réduire les délais de construction dans les pipelines CI/CD. 

Ordonnez les instructions de votre fichier Docker pour maximiser le nombre de visites dans le cache en plaçant le contenu rarement modifié (comme l'installation de dépendances) avant le contenu fréquemment modifié (comme le code de l'application). 

Lorsque vous utilisez des args de construction susceptibles de changer souvent, placez-les après des opérations stables afin d'éviter d'invalider l'ensemble du cache :

FROM python:3.13-slim

WORKDIR /app

# Dependencies change less frequently - good cache utilization
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Build args that might change often come AFTER stable operations
ARG BUILD_NUMBER
ARG COMMIT_SHA
# Now these args won't invalidate the dependency cache

La gestion des métadonnées par le biais des args de construction améliore la traçabilité et la conformité. Utilisez les args de construction pour injecter des métadonnées de construction sous forme d'étiquettes :

ARG BUILD_DATE
ARG VERSION
ARG COMMIT_SHA
ARG BUILD_URL

LABEL org.opencontainers.image.created="${BUILD_DATE}" Can you please provide me with access to this document?
      org.opencontainers.image.version="${VERSION}" \
      org.opencontainers.image.revision="${COMMIT_SHA}" \
      org.opencontainers.image.url="${BUILD_URL}"

Ces étiquettes normalisées suivent les spécifications de l'Open Container Initiative (OCI), ce qui signifie que vos images seront compatibles avec différents outils de gestion de conteneurs.

La documentation est souvent négligée, mais elle est essentielle à l'adoption par les entreprises. 

Créez une section README claire qui documente tous les args de compilation disponibles, leur objectif, leurs valeurs par défaut et des exemples d'utilisation. Indiquez quels arguments de construction sont obligatoires ou facultatifs, et documentez les interactions entre les différents arguments. Pensez à ajouter ces informations aux fichiers de configuration de votre pipeline CI/CD sous forme de commentaires, afin d'aider les développeurs à comprendre quelles valeurs ils doivent fournir :

# Example documented CI configuration
build_job:
  script:
    # BUILD_NUMBER: Unique identifier for this build (required)
    # ENVIRONMENT: Target deployment environment [dev|staging|prod] (required)
    # PYTHON_VERSION: Python version to use (optional, default: 3.9)
    - docker build
      --build-arg BUILD_NUMBER=${CI_PIPELINE_ID}
      --build-arg ENVIRONMENT=${DEPLOY_ENV}
      --build-arg PYTHON_VERSION=${PYTHON_VERSION:-3.9}
      -t myapp:${CI_PIPELINE_ID} .

Pour une adoption au niveau de l'entreprise, envisagez de mettre en œuvre un schéma d'arguments de construction qui peut être versionné et validé. Cette approche vous permet de faire évoluer votre configuration de construction au fil du temps tout en conservant une compatibilité ascendante.

Analyse comparative : Args de construction vs. Variables d'environnement

Si vous souhaitez créer des images Docker sécurisées et flexibles qui respectent les meilleures pratiques, vous devez comprendre quand utiliser les arguments de construction et quand utiliser les variables d'environnement.

Voici un tableau que vous pouvez consulter à tout moment :

La différence essentielle réside dans le moment et l'objectif.La différence essentielle réside dans le calendrier et l'objectif. Les arguments de construction configurent le processus de construction lui-même, tandis que les variables d'environnement configurent l'application en cours d'exécution. Par exemple, vous utiliserez un argument de construction pour sélectionner l'image de base à utiliser (ARG PYTHON_VERSION=3.10), mais vous utiliserez une variable d'environnement pour indiquer à votre application le port sur lequel elle doit écouter (ENV PORT=8080).

Du point de vue de la sécurité, build args présentent un risque plus élevé pour les informations sensibles car elles restent dans l'historique de l'image.

Considérez ce flux de travail pour traiter les différents types de configuration :

# Build-time configuration (non-sensitive)
ARG PYTHON_VERSION=3.13
FROM python:${PYTHON_VERSION}-slim

# Build-time secrets (use BuildKit secrets)
RUN --mount=type=secret,id=build_key \
    cat /run/secrets/build_key > /tmp/key && \
    # Use the secret for build operations
    rm /tmp/key

# Runtime configuration (non-sensitive)
ENV LOG_LEVEL=info

# Runtime secrets (should be injected at runtime, not here)
# This would be provided at runtime with:
# docker run -e API_KEY=secret123 myimage

Dans la pratique, un schéma courant consiste à convertir les arguments de compilation sélectionnés en variables d'environnement lorsqu'ils doivent être disponibles au moment de l'exécution :

ARG APP_VERSION=1.0.0
# Make the version available at runtime
ENV APP_VERSION=${APP_VERSION}

Pour les applications d'entreprise, la séparation permet à différentes équipes de gérer différents aspects du cycle de vie de l'application. Les équipesDevOpspeuvent modifier les paramètres de construction des images, tandis que les opérateurs peuvent ajuster les variables d'environnement pendant le déploiement sans reconstruire les images.

Récapitulation des arguments de construction de Docker

Les args de construction Docker ne sont pas simplement une autre fonctionnalité technique - ils sont votre outil de référence pour créer des images qui fonctionnent de manière cohérente au sein de votre équipe et de vos environnements. 

J'ai expliqué comment les utiliser dans des projets Python simples, tout en protégeant vos informations sensibles. Vous avez également vu comment intégrer des args de construction avec des outils comme Docker Compose.

Considérez les args de construction comme la base d'une stratégie de conteneurisation flexible. Commencez modestement en paramétrant votre version de Python dans votre prochain projet. Une fois que vous vous sentez à l'aise, essayez d'ajouter une logique conditionnelle pour différents environnements. En un rien de temps, vous créerez des constructions sophistiquées en plusieurs étapes que votre équipe pourra personnaliser sans modifier le fichier Docker.

Prêt à approfondir ? Ces cours de DataCamp sont votre meilleur prochain arrêt :

• Introduction à Docker
• Docker intermédiaire
• Concepts de conteneurisation et de virtualisation
• Conteneurisation et virtualisation avec Docker et Kubernetes
• CI/CD pour l'apprentissage automatique