Docker Desktop 4.38 : Bake GA, Gordon et Kubernetes multi-nœuds

Le 5 février 2025, Docker a livré la version 4.38 de Docker Desktop avec trois nouveautés qui méritent l'attention des équipes backend : Docker Bake passe en General Availability, Agent Gordon arrive en bêta publique dans le CLI, le Dashboard et Docker Hub, et le support Kubernetes multi-nœuds en local via kind débarque. Voici ce que ça change concrètement quand tu gères des stacks PHP.

Docker Bake en GA : fini les <code>docker build</code> artisanaux

Bake existait en expérimental depuis plusieurs versions, mais le passage en GA dans 4.38 change la donne pour la maintenabilité à long terme. Le principe : décrire l'ensemble de tes builds dans un fichier docker-bake.hcl versionné, puis lancer docker buildx bake pour orchestrer plusieurs images en parallèle avec héritage de variables, targets nommées et matrix builds. Pour une stack Symfony — app, worker, cron — c'est exactement le cas d'usage qui justifiait jusqu'ici des scripts shell fragiles et non reviewés.

# docker-bake.hcl
variable "TAG" {
  default = "latest"
}

variable "REGISTRY" {
  default = "ghcr.io/mon-org"
}

group "default" {
  targets = ["app", "worker"]
}

target "base" {
  dockerfile = "Dockerfile"
  context    = "."
  args = {
    PHP_VERSION = "8.4"
  }
  cache-from = ["type=registry,ref=${REGISTRY}/cache:buildcache"]
  cache-to   = ["type=registry,ref=${REGISTRY}/cache:buildcache,mode=max"]
}

target "app" {
  inherits = ["base"]
  tags     = ["${REGISTRY}/app:${TAG}"]
  target   = "app"
}

target "worker" {
  inherits = ["base"]
  tags     = ["${REGISTRY}/worker:${TAG}"]
  target   = "worker"
}

En CI, un seul appel TAG=1.4.2 docker buildx bake --push remplace plusieurs docker build séquentiels et partage le cache entre toutes les targets. Le fichier HCL vit dans le repo, est reviewé comme du code, et garantit la reproductibilité des builds entre postes et pipelines. C'est la vraie promesse du passage en GA : on peut désormais s'appuyer sur Bake en production sans craindre une rupture d'API à la prochaine mise à jour.

Agent Gordon : l'IA contextuelle dans Docker, pour quoi faire ?

Gordon arrive en bêta via le Dashboard, Docker Hub et la commande docker ai. C'est un assistant qui lit tes Dockerfiles, tes fichiers Compose et les logs de tes conteneurs pour répondre en langage naturel. Concrètement, tu peux lui soumettre une stack trace d'un conteneur PHP-FPM qui redémarre en boucle et lui demander d'en identifier la cause. Voici ce qu'il sait faire — et ce qu'il ne maîtrise pas encore.

• Diagnostiquer un conteneur en boucle de redémarrage à partir de ses logs (OOM, signal, dépendance absente)
• Détecter les anti-patterns dans un Dockerfile : layers trop larges, COPY avant ARG, absence de .dockerignore
• Suggérer des correctifs Compose : depends_on avec condition, healthchecks manquants, restart policy inadaptée
• Expliquer les erreurs de build BuildKit avec leur contexte — pas seulement le message brut
• Pas encore : génération fiable de Dockerfile from scratch, lecture du code source PHP, intégration directe au pipeline CI

En pratique sur un projet Symfony 7.2, Gordon se révèle un outil de diagnostic, pas de génération. Il excelle sur les erreurs d'extension PHP manquante, les incompatibilités de version entre l'image de base et une dépendance système, ou les healthchecks Nginx mal configurés. Rappel important : c'est une bêta — les réponses peuvent être imprécises — et la fonctionnalité nécessite un opt-in explicite dans les settings de Docker Desktop. À intégrer comme premier niveau de triage dans ton flux de debug, pas comme oracle automatisé.

Kubernetes multi-nœuds en local : tester l'anti-affinité sans cluster distant

Avant 4.38, le cluster Kubernetes intégré à Docker Desktop était mono-nœud — suffisant pour valider des manifests basiques, insuffisant pour simuler des scénarios de scheduling réels. Docker intègre désormais kind (Kubernetes in Docker) pour monter des clusters multi-nœuds directement depuis l'interface. Pour les équipes qui déploient Symfony sur Kubernetes avec HPA, PodDisruptionBudget ou règles d'anti-affinité, c'est un changement de workflow significatif.

# kind-config.yaml — chargeable depuis Docker Desktop 4.38 > Kubernetes
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

Le cluster démarre avec kind sous le capot et reste entièrement compatible kubectl et Helm. Pour une stack PHP-FPM + Nginx + Redis, tu peux désormais tester en local qu'un rolling update ne coupe pas le trafic, vérifier que tes readinessProbes bloquent bien le routage vers un pod non prêt, ou valider qu'un PodDisruptionBudget empêche la suppression simultanée de deux workers Symfony Messenger. Ce que tu repoussais jusqu'ici sur staging devient validable dès le développement.

Ce qu'il faut retenir pour tes projets PHP

• Migre tes scripts de build vers un docker-bake.hcl : Bake est désormais stable, supporté long terme et reviewable comme du code
• Active Gordon en opt-in et utilise-le comme premier niveau de triage sur les erreurs de conteneur — pas comme oracle infaillible
• Si tu déploies sur Kubernetes, exploite le multi-nœuds pour valider tes manifests de scheduling dès le développement local
• PHP 8.4 est l'image de base recommandée : toutes les images officielles php:8.4-fpm sont disponibles et stables

Docker Desktop 4.38 est une release solide qui comble plusieurs lacunes réelles : reproductibilité des builds avec Bake GA, assistance contextuelle avec Gordon, et fidélité de l'environnement local Kubernetes. Si tu veux auditer ta stack Docker PHP — Dockerfiles, sécurité des images, pipeline CI/CD, configuration Compose ou Kubernetes — c'est le type d'intervention couvert par un Bear Scan : un regard externe, pragmatique, centré sur ce qui freine réellement tes livraisons.