Docker Desktop 4.33 : Debug et Build Checks passent en GA

Le 29 juillet 2024, Docker Desktop 4.33 franchit un cap discret mais significatif : Docker Debug et Docker Build Checks passent en disponibilité générale après plusieurs mois de bêta. Pour les équipes qui tournent en conteneurs — et notamment les stacks PHP/Symfony en production — ces deux outils comblent des lacunes réelles. Le premier rend enfin débuggable ce qui ne l'était pas, le second déplace la détection d'erreurs avant même le premier RUN. Tour rapide de ce que ça change concrètement.

Docker Debug : inspecter les conteneurs sans shell

Depuis les premières heures des images distroless, le problème est identique : l'image est légère, la surface d'attaque réduite, mais impossible d'y poser un docker exec pour lancer un bash — il n'y en a pas. La solution habituelle consistait à reconstruire l'image en mode debug avec un shell temporaire, perdre du temps et souiller son registre de couches inutiles. Docker Debug, en GA depuis la 4.33 après une bêta ouverte depuis la 4.27, règle ça proprement. L'outil injecte une toolbox légère dans le namespace du conteneur cible — sans modifier l'image elle-même. Vous pouvez inspecter les fichiers, lancer des commandes, lire les logs, tracer les processus, même sur un conteneur stoppé après un crash.

# Inspecter un conteneur en cours d'exécution (avec ou sans shell embarqué)
docker debug my-app-container

# Inspecter directement une image distroless sans la lancer
docker debug --image=gcr.io/distroless/php8.3-debian12

# Inspecter un conteneur stoppé (crash au démarrage)
docker debug crashed-worker

La toolbox embarquée inclut vim, nano, curl, wget, htop, strace et quelques autres utilitaires courants, téléchargés une fois et mis en cache localement. En pratique, cela signifie que vous pouvez maintenir des images de production vraiment minimales — sans layer debug caché, sans embarquer d'outils inutiles en prod — et débugger tout de même lorsque c'est nécessaire, sans friction. À noter : Docker Debug nécessite un abonnement Docker Personal, Pro, Team ou Business.

Docker Build Checks : le lint de Dockerfile intégré à la CLI

Docker Build Checks, c'est la fonctionnalité qu'on attendait : un validateur de Dockerfile qui tourne avant le premier layer. Plus besoin d'intégrer hadolint en CI avec une configuration séparée à maintenir — les checks sont désormais natifs dans docker build via le flag --check. Aucun layer n'est construit, aucune image n'est poussée : c'est une analyse statique rapide et cohérente entre le poste local et la CI.

# Valider le Dockerfile avant de builder (aucun layer créé)
docker build --check .

# Avec Docker Build Cloud — même comportement, exécution distribuée
docker buildx build --check --builder cloud-myorg/mybuilder .

Les règles couvertes à la GA incluent notamment : l'usage de latest comme tag de base (non reproductible), les instructions RUN sans apt-get update préalable, les COPY vers des chemins absolus sans WORKDIR défini, ou les ARG déclarés après leur premier usage. Le résultat est structuré, avec un niveau de sévérité et une référence vers la règle concernée.

# Dockerfile qui déclenche des warnings Build Checks
FROM php:8.3-fpm-alpine

# Warning: WORKDIR non défini avant COPY
COPY . /var/www/html

# Warning: --no-cache absent sur apk
RUN apk add git

---

# Version corrigée — aucun warning
FROM php:8.3-fpm-alpine

WORKDIR /var/www/html

COPY composer.json composer.lock ./
RUN apk add --no-cache git \
    && docker-php-ext-install opcache pdo pdo_mysql

COPY . .

Ce que ça change pour vos pipelines

L'intégration native à la CLI est le vrai gain. Avant, intégrer hadolint dans une pipeline GitHub Actions demandait une action dédiée, une config .hadolint.yaml à maintenir, et souvent un alignement laborieux entre ce que l'outil considère comme une erreur et ce que l'équipe accepte réellement. Avec docker build --check, la validation s'insère dans le même step que le build, avec un comportement identique en local et en CI, sans dépendance supplémentaire.

• docker build --check s'ajoute à n'importe quel pipeline existant sans nouvelle dépendance
• Les erreurs bloquantes retournent un exit code non nul — le pipeline s'arrête avant toute image construite
• Docker Build Cloud supporte le flag --check — utile si vous déléguez déjà les builds lourds au cloud
• Docker Debug ne nécessite aucune modification de vos images existantes ni de votre registre
• Les deux fonctionnalités sont disponibles sur macOS, Windows (WSL2) et Linux

Docker Debug et Build Checks en GA dans la 4.33, c'est deux maturations d'outils qui simplifient des workflows souvent bricolés : du debug en production sans sacrifier la légèreté de vos images, et de la validation Dockerfile au plus proche du build. Si votre équipe tourne avec des images PHP slim ou distroless et que vos pipelines manquent encore de rigueur sur la qualité Dockerfile — de la construction d'image jusqu'au déploiement — un Bear Scan peut cartographier précisément ce qui mérite d'être consolidé.