Docker Buildx : Comment créer des images de conteneurs multiplateformes ?

Cas d'utilisation avancés

Jusqu'à présent, je vous ai montré les commandes de base de Buildx et les cas d'utilisation. Buildx peut faire beaucoup plus, certaines fonctionnalités étant impossibles à mettre en œuvre avec le constructeur classique.

Explorons quelques techniques avancées pour faire passer votre flux de travail de conteneurisation au niveau supérieur.

Optimisation de la construction en plusieurs étapes

Les constructions en plusieurs étapes sont l'une des fonctionnalités les plus puissantes de Docker pour créer des images efficaces, et Buildx les rend encore meilleures.

Pour le démontrer, créons une application Python optimisée avec plusieurs étapes :

# Dockerfile.optimized
FROM python:3.13-slim AS base
WORKDIR /app
COPY requirements.txt .

FROM base AS builder
RUN pip install --no-cache-dir --target=/install -r requirements.txt

FROM base AS linter
COPY --from=builder /install /usr/local/lib/python3.13/site-packages
COPY app.py .
RUN pip install pylint && pylint app.py || exit 0

FROM base AS tester
COPY --from=builder /install /usr/local/lib/python3.9/site-packages
COPY app.py .
RUN pip install pytest && python -m pytest app.py -v || exit 0

FROM python:3.13-alpine AS final
WORKDIR /app
COPY --from=builder /install /usr/local/lib/python3.13/site-packages
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]

Avec Buildx, vous pouvez construire cela plus efficacement :

docker buildx build --file Dockerfile.optimized -t myapp:optimized --load .

Image 9 - Constructions en plusieurs étapes

Qu'est-ce qui fait la particularité de ce produit ? Buildx traite en parallèle des étapes indépendantes. Alors que le constructeur traditionnel exécuterait chaque étape de manière séquentielle, Buildx identifie que les étapes linter et tester ne dépendent pas l'une de l'autre et les construit simultanément.

Un autre avantage de cette optimisation de la construction est la réduction de la taille du fichier. Vous pouvez vérifier la taille de l'image en procédant comme suit :

docker images myapp

Vous obtiendrez quelque chose comme ceci :

Image 10 - Taille des images Docker

L'image finale alpine est beaucoup plus petite.

Intégration du pipeline CI/CD

Lorsque vous travaillez localement, vous pouvez toujours mettre en place des configurations Buildx qui reflètent votre environnement CI/CD.

Pour commencer, créez un fichier .dockerignore afin de garder les constructions propres :

.git
__pycache__
*.pyc
*.pyo
*.pyd
.Python
env
venv
*.so
.coverage
htmlcov

Créez ensuite un script de construction qui imite ce que votre pipeline de CI pourrait faire :

#!/bin/bash
# build.sh - Local CI/CD simulation

echo "Starting CI/CD build process..."

# Setup builder with emulation support
echo "Setting up builder..."
docker buildx create --name cibuilder --use || true
docker buildx inspect --bootstrap

# Run linting
echo "Running lint stage..."
docker buildx build --file Dockerfile.optimized --target linter .

# Run tests
echo "Running test stage..."
docker buildx build --file Dockerfile.optimized --target tester .

# Build for multiple platforms
echo "Building multi-platform image..."
docker buildx build --file Dockerfile.optimized \
  --platform linux/amd64,linux/arm64 \
  --tag myapp:$(date +%Y%m%d) \
  --tag myapp:latest \
  --load \
  --progress=plain \
  .

echo "Build process complete!"

En clair, ce script effectue les opérations suivantes :

• Crée un constructeur dédié à CI/CD.
• Exécute l'étape de mise en charpie.
• Exécute la phase de test.
• Construit l'image finale multiplateforme avec des balises versionnées.

Passons maintenant à la partie la plus amusante : rendez le script exécutable et exécutez-le :

chmod +x build.sh
./build.sh

Edition locale

L'un des problèmes les plus courants lorsque vous travaillez avec Docker est que chaque fois que vous modifiez le fichier source, vous devez reconstruire l'image et exécuter le conteneur. Cela prend trop de temps.

Voici la bonne nouvelle : pour un développement local avec des itérations plus rapides, vous pouvez créer une version de développement :

# Dockerfile.dev
FROM python:3.13-slim
WORKDIR /app

RUN pip install flask psutil python-dotenv

# Install development tools
RUN pip install pytest pylint watchdog

# Mount app code at runtime instead of copying
CMD ["python", "app.py"]

Exécutez-le avec un montage de volume pour recharger le code en direct :

docker buildx build -f Dockerfile.dev -t myapp:dev --load .
docker run -it --rm -p 5000:5000 -v $(pwd):/app myapp:dev

Vous pouvez maintenant éditer votre fichier app.py localement, et les changements seront immédiatement reflétés dans le conteneur en cours d'exécution !

Passons maintenant à la question de la performance.

Considérations sur les performances

Personne n'aime un flux de travail de développement lent, et la puissance de la parallélisation avec Docker Buildx peut aider.

Voyons comment optimiser vos constructions et tirer parti des fonctions de performance de Buildx pour créer des images plus rapidement.

Construire des techniques de parallélisation

L'un des principaux avantages de Buildx est sa capacité à construire des étapes en parallèle. Le constructeur Docker traditionnel exécute chaque étape de manière séquentielle, mais Buildx analyse votre fichier Docker et identifie les étapes qui peuvent être exécutées en même temps.

Pour illustrer mon propos, j'utiliserai deux fichiers : Dockerfile.standard et Dockerfile.parallel. Voici le contenu des deux :

Dockerfile.standard

FROM python:3.13-slim
WORKDIR /app

# System dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# Python dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Application code
COPY app.py .

# Linting
RUN pip install pylint && pylint app.py || true

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

Dockerfile.parallel

FROM python:3.13-slim AS python-base
WORKDIR /app

# Independent stage for installing system dependencies
FROM python-base AS system-deps
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# Independent stage for installing Python dependencies
FROM python-base AS python-deps
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Independent stage for static code analysis
FROM python-deps AS linting
COPY app.py .
RUN pip install pylint && pylint app.py || true

# Final stage that combines dependencies
FROM python-base AS final
# Copy from system deps stage
COPY --from=system-deps /usr/bin/gcc /usr/bin/gcc
# Copy from Python deps stage
COPY --from=python-deps /usr/local/lib/python3.13/site-packages /usr/local/lib/python3.13/site-packages
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]

Mesurons comment cette structure parallèle améliore les temps de construction :

# Time the standard sequential build
time docker build -t myapp:standard -f Dockerfile.standard .

# Time the parallel-optimized build with Buildx
time docker buildx build --load -t myapp:parallel -f Dockerfile.parallel .

À titre de référence, la construction standard a pris 18,48 secondes, tandis que la construction parallèle n'a pris que 1,17 seconde !

Pour améliorer encore les performances, vous pouvez essayer d'utiliser les drapeaux --cache-from et --cache-to pour tirer parti de la mise en cache des disques locaux:

# First build - create cache
docker buildx build --load -t myapp:latest --cache-to type=local,dest=./buildcache .

# Subsequent builds - use cache
docker buildx build --load -t myapp:latest --cache-from type=local,src=./buildcache .

Vous pouvez également limiter la taille du contexte en utilisant soigneusement les fichiers .dockerignore:

# Create a comprehensive .dockerignore
cat > .dockerignore << 'EOF'
.git
.github
.dockerignore
.pytest_cache
__pycache__
*.pyc
*.pyo
*.pyd
.Python
venv
env
node_modules
.coverage
htmlcov
.DS_Store
EOF

En bref, en structurant vos fichiers Docker avec la parallélisation à l'esprit et en tirant parti de la mise en cache avancée de Buildx, vous passerez moins de temps à attendre les builds et plus de temps à développer des fonctionnalités.

Intégration de l'écosystème

Docker Buildx n'existe pas de manière isolée. Il est conçu pour s'intégrer de manière transparente aux autres outils de votre environnement de développement.

Voyons comment Buildx fonctionne avec les outils de développement locaux et rend votre flux de travail plus efficace.

Clusters de construction Kubernetes

Kubernetes offre de puissantes fonctionnalités pour l'exécution d'opérations Docker Buildx distribuées sur un cluster. En intégrant Buildx avec Kubernetes, vous pouvez obtenir des constructions plus rapides et plus résilientes qui évoluent avec les besoins de votre projet.

> Vous êtes novice en matière de Kubernetes ? Le site Kubernetes vs Docker : Differences Every Developer Should Know post is your next stop.

L'utilisation de Kubernetes pour votre infrastructure de construction présente plusieurs avantages :

1. Mise à l'échelle automatique : Kubernetes peut faire évoluer vos nœuds de construction vers le haut ou vers le bas en fonction de la demande, en allouant les ressources de manière efficace dans votre cluster. Vous pouvez même définir des règles de mise à l'échelle automatique basées sur l'utilisation du processeur.
2. Optimisation des ressources : L'ordonnancement Kubernetes garantit que vos constructions obtiennent les ressources dont elles ont besoin sans surcharger les nœuds individuels. Vous pouvez définir des limites de ressources et des demandes pour garantir des performances constantes.
3. Haute disponibilité : En distribuant les instances BuildKit sur plusieurs nœuds, votre infrastructure de construction reste disponible même si des nœuds individuels tombent en panne.
4. Des environnements cohérents : Chaque membre de l'équipe se connecte à la même infrastructure de construction, ce qui élimine les problèmes de "fonctionne sur ma machine".
5. Exécution parallèle : Les constructions complexes comportant de nombreuses étapes peuvent être exécutées en parallèle sur plusieurs nœuds, ce qui permet de réduire considérablement les délais de construction. Un projet qui peut prendre 15 minutes à réaliser localement peut être achevé en 3-4 minutes lorsqu'il est distribué.

Considérez cette section comme plus "théorique", car plonger plus profondément dans Kubernetes est un sujet avancé en soi.

Pour commencer, créez un fichier nommé buildkit-deployment.yaml avec le contenu suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: buildkit
  namespace: buildkit
spec:
  replicas: 3
  selector:
    matchLabels:
      app: buildkit
  template:
    metadata:
      labels:
        app: buildkit
    spec:
      containers:
      - name: buildkit
        image: moby/buildkit:latest
        args:
        - --addr
        - tcp://0.0.0.0:1234
        ports:
        - containerPort: 1234
        securityContext:
          privileged: true
---
apiVersion: v1
kind: Service
metadata:
  name: buildkit
  namespace: buildkit
spec:
  type: ClusterIP
  ports:
  - port: 1234
    targetPort: 1234
  selector:
    app: buildkit

L'étape suivante consiste à appliquer ce fichier à votre cluster Kubernetes :

kubectl create namespace buildkit
kubectl apply -f buildkit-deployment.yaml

Enfin, connectez-vous à ce déploiement à partir de votre machine locale :

docker buildx create --name k8s-builder \
  --driver remote \
  --driver-opt endpoint=tcp://<cluster-ip>:1234 \
  --use

Et voilà, vous êtes prêt à partir !

Support des plugins IDE

Les IDE comme Visual Studio Code offrent une excellente intégration avec Docker Buildx grâce à son extension Docker. Cette intégration facilite la gestion de vos flux de travail Buildx directement depuis votre environnement de développement.

Pour commencer à utiliser Docker Buildx dans VS Code, installez l'extension "Docker" à partir de la place de marché VS Code.

Une fois installé, vous bénéficierez de plusieurs fonctionnalités propres à Buildx :

• Cliquez avec le bouton droit de la souris sur n'importe quel fichier Docker pour afficher un menu contextuel avec une option "Build Image..." qui prend en charge Buildx.
• Accès aux arguments de construction, aux cibles de plate-forme et aux options de sortie via l'interface utilisateur.
• Capacité à gérer et à passer d'une instance de constructeur à l'autre.
• Intégration avec le terminal VS Code pour l'exécution de commandes Buildx complexes.

Image 11 - Extension Docker pour VSCode

Voici un exemple de personnalisation des tâches VS Code pour utiliser Buildx en créant un fichier .vscode/tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Docker: Buildx Build",
      "type": "shell",
      "command": "docker buildx build --load -t ${input:imageName} .",
      "group": {
        "kind": "build",
        "isDefault": true
      }
    },
    {
      "label": "Docker: Buildx Multi-Platform",
      "type": "shell",
      "command": "docker buildx build --platform linux/amd64,linux/arm64 -t ${input:imageName} ."
    }
  ],
  "inputs": [
    {
      "id": "imageName",
      "description": "Image name (with tag):",
      "default": "myapp:latest",
      "type": "promptString"
    }
  ]
}

Avec cette configuration, vous pouvez accéder rapidement aux commandes Buildx courantes à partir du menu Tâches de VS Code(Terminal > Exécuter une tâche). L'extension fournit également une coloration syntaxique utile pour les Dockerfiles et une autocomplétion pour les commandes Docker courantes, ce qui rend votre flux de travail Buildx plus productif.

Dépannage et débogage

Chaque outil de développement nécessite parfois (trop souvent) un dépannage, et Docker Buildx ne fait pas exception. Dans cette section, je vais vous présenter quelques problèmes courants afin que vous puissiez les diagnostiquer vous-même rapidement et reprendre le cursus.

Problèmes courants et solutions

Lorsque vous travaillez avec Buildx, vous pouvez rencontrer quelques défis communs. Voici les problèmes les plus fréquents et leurs solutions :

• La création d'un constructeur échoue. Si vous rencontrez des erreurs lors de la création d'un constructeur avec docker buildx create, vérifiez votre version de Docker :

docker version

Buildx nécessite Docker 19.03 ou une version plus récente. Si vous utilisez une version plus ancienne, mettez à jour Docker pour accéder aux fonctionnalités de Buildx.

Pour les erreurs "no such plugin", assurez-vous que Buildx est correctement installé en exécutant :

docker buildx version

• Échecs de la compilation multiplateforme. Lorsque vous construisez pour plusieurs plateformes et que vous obtenez des erreurs telles que "exec format error" ou "no matching manifest", vérifiez si QEMU est installé :

docker buildx inspect --bootstrap

Si nécessaire, installez des émulateurs de plate-forme :

docker run --privileged --rm tonistiigi/binfmt --install all

• Problèmes liés au cache. Pour les problèmes de mise en cache, essayez de vider votre cache de compilation local :

# Remove specific builder's cache
docker buildx prune -b mybuilder

# Remove all build cache
docker buildx prune --all

> Qu'est-ce que la commande Docker prune ? Apprenez à l'aide d'une multitude d'exemples pratiques.

• Problèmes de connexion du démon BuildKit. Si vous voyez "failed to solve" ou des erreurs de connexion, redémarrez le constructeur :

docker buildx rm mybuilder
docker buildx create --name mybuilder --use
docker buildx inspect --bootstrap

• Questions liées aux performances. Pour les constructions lentes, essayez la sortie de débogage pour identifier les goulots d'étranglement :

docker buildx build --progress=plain --no-cache .

Cette sortie verbale permet d'identifier les étapes de construction qui prennent le plus de temps, ce qui vous permet d'optimiser votre fichier Docker en conséquence.

• Échecs de la commande "Load". Si vous rencontrez "error : docker exporter does not currently support exporting manifest lists" lorsque vous utilisez --load avec des constructions multiplateformes, rappelez-vous que le chargement simultané de plusieurs plateformes dans le démon Docker n'est pas pris en charge. Au lieu de cela :

# Build for your current platform and load it
docker buildx build --platform linux/amd64 --load -t myapp:latest .

• Pratiques de débogage. Pour les problèmes plus complexes, ces méthodes de débogage vous aideront :

# Enable BuildKit debug logs
BUILDKIT_DEBUG=1 docker buildx build .

# Inspect the builder's internal state
docker buildx inspect

# Check system requirements
docker info

# For specific stage failures, build only up to that stage
docker buildx build --target problem-stage .

# Verify your Docker context
docker context ls

En suivant systématiquement ces étapes de dépannage, vous pouvez résoudre la plupart des problèmes liés à Buildx et maintenir un flux de construction de conteneurs efficace.

Résumé du guide Docker Buildx

Nous avons couvert beaucoup de terrain dans cet article de Docker Buildx ! Vous avez vu comment ce puissant outil peut rendre vos constructions de conteneurs plus rapides et plus flexibles.

Rappelez-vous les principaux avantages : Vous pouvez créer des images pour plusieurs plateformes à l'aide d'une seule commande, accélérer vos créations grâce à la mise en cache avancée et sécuriser vos images grâce à une gestion appropriée des secrets. Les améliorations de performance sont réelles, en particulier lorsque vous structurez vos fichiers Docker pour tirer parti de la construction parallèle.

Je l'utilise tout le temps sur mon Macbook à puce M, car toutes les images ne sont pas disponibles pour ARM.

Que vous soyez un développeur solitaire ou que vous fassiez partie d'une grande équipe, Buildx vous offre des outils qui s'adaptent à votre flux de travail. Vous pouvez exécuter des builds localement, les distribuer dans des conteneurs ou même les faire évoluer vers des clusters Kubernetes au fur et à mesure que vos besoins augmentent.

Pour en savoir plus sur Docker et Docker Buildx, je vous recommande de vous inscrire aux cours DataCamp suivants :

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