Docker Desktop 4.34 : containerd par défaut et host networking PHP

Docker Desktop 4.34, sorti en septembre 2024, introduit deux changements structurels dans les options par défaut : le containerd image store est désormais actif d'emblée sur toute nouvelle installation et après chaque factory reset, tandis que la couche host networking a été refondée. Pour la majorité des équipes PHP, la mise à jour se déroule sans accroc. En revanche, si tu onboardes un nouveau développeur, effectues un factory reset ou t'appuies sur des comportements réseau spécifiques dans ton docker-compose.yml, voici ce qu'il faut anticiper avant que ça casse en dev local.

Deux ruptures de comportement, pas une mise à jour anodine

Jusqu'à 4.34, le containerd image store était une option expérimentale à activer manuellement dans Settings → Experimental Features. Désormais, toute nouvelle installation repart avec ce backend actif par défaut — idem après un factory reset : tu retrouves une instance vierge en mode containerd. Le deuxième changement porte sur le networking : Docker Desktop consolide la résolution DNS via host.docker.internal et formalise host-gateway comme mécanisme recommandé pour joindre les services de la machine hôte. Ces deux évolutions ont des effets concrets sur les stacks PHP locales — et elles n'agissent pas nécessairement au même moment, ce qui rend le diagnostic délicat.

containerd image store par défaut : migration invisible ou surprise au redémarrage ?

Le piège, c'est la continuité apparente. Si tu mets à jour Docker Desktop sans factory reset, ton ancien backend (snapshotter overlayfs du daemon Docker classique) est préservé. Mais un collègue qui installe Docker Desktop pour la première fois démarrera directement en mode containerd — et ne verra pas les images locales que tu lui aurais pré-construites dans l'ancien store. Les layers ne sont pas compatibles entre les deux backends : docker images liste uniquement les images du store actif, sans mélange ni fallback silencieux.

• Les images buildées avec docker build fonctionnent normalement : rien à changer dans ton Dockerfile.
• Les builds multi-plateforme via docker buildx sont plus stables : le containerd store gère nativement les index OCI multi-arch sans recourir à un registry intermédiaire.
• Les OCI artifacts (Helm charts, modules WASM, binaires versionnés) peuvent désormais être stockés et poussés comme des images ordinaires — un avantage concret pour les équipes qui versionnent des assets de déploiement.
• Après un factory reset, re-pull toutes tes images de base : php:8.3-fpm, nginx:1.27-alpine, mysql:8.0. Elles ne sont plus là.
• Vérifie le backend actif avec la commande ci-dessous avant de te lancer dans un debug de layers introuvables.

# Vérifier quel backend est actif
docker info | grep -E "Storage Driver|containerd"

# Résultat avec containerd store activé :
# Storage Driver: overlayfs
#  driver-type: io.containerd.snapshotter.v1

# Résultat avec l'ancien daemon Docker :
# Storage Driver: overlay2

Host networking refondu : Xdebug et services locaux

Sur macOS et Windows, Docker tourne dans une VM Linux (LinuxKit). Le flag --network host ne mappe jamais le réseau de ta machine physique, mais celui de la VM — ce comportement a toujours existé, mais il était rarement documenté clairement. Docker Desktop 4.34 clarifie et consolide cette réalité : host.docker.internal devient la voie officielle pour joindre des services de l'hôte (base MySQL locale, serveur SMTP de dev, IDE en écoute Xdebug). Les configs qui contournaient ce comportement avec des IPs codées en dur ou des hacks réseau cassent souvent après la mise à jour. La correction est simple, mais elle doit être appliquée partout dans l'équipe.

; docker/php/conf.d/xdebug.ini
[xdebug]
xdebug.mode=debug
xdebug.start_with_request=yes
; Ne plus utiliser 127.0.0.1 ni l'IP de la VM — toujours host.docker.internal
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.idekey=PHPSTORM
xdebug.log=/var/log/xdebug.log

Le docker-compose à jour pour une stack Symfony 7.1 / PHP 8.3

Voici un docker-compose.yml minimal, compatible Docker Desktop 4.34, qui évite les pièges de résolution DNS. La ligne host.docker.internal:host-gateway est la clé : elle garantit qu'Xdebug peut joindre ton IDE sur le port 9003, que tu développes sur macOS ou Linux, sans adresse IP codée en dur. Le healthcheck MySQL, lui, évite les depends_on optimistes qui plantent systématiquement au premier docker compose up d'un onboarding.

# docker-compose.yml — compatible Docker Desktop 4.34
services:
  php:
    build:
      context: .
      dockerfile: docker/php/Dockerfile
    volumes:
      - .:/var/www/html:cached
    environment:
      APP_ENV: dev
      XDEBUG_MODE: debug
    # Indispensable pour Xdebug et tout service écoutant sur l'hôte
    extra_hosts:
      - "host.docker.internal:host-gateway"
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started

  nginx:
    image: nginx:1.27-alpine
    ports:
      - "8080:80"
    volumes:
      - .:/var/www/html:ro
      - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - php

  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: app
      MYSQL_USER: app
      MYSQL_PASSWORD: app
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 5s
      timeout: 5s
      retries: 10

  redis:
    image: redis:7.4-alpine
    # Désactive la persistence en dev pour économiser les I/O
    command: redis-server --save "" --appendonly no

volumes:
  db_data:

Le passage au containerd image store est une bonne nouvelle sur le long terme : le support des OCI artifacts et les builds multi-arch en bénéficient directement. L'essentiel est de le documenter dans ton README d'onboarding et de t'assurer que chaque membre de l'équipe a re-pullé ses images de base après un éventuel factory reset. Si ta stack Docker a accumulé des workarounds similaires au fil du temps, c'est le bon moment pour un audit complet. Mon offre Bear Scan couvre exactement cette dette technique : Dockerfile, compose, CI/CD et sécurité des layers — contacte-moi pour en discuter.