Docker Desktop 4.73 su Windows 11: attenzione alla migrazione automatica containerd e ai volumi WSL2

Negli ultimi giorni abbiamo riscontrato un comportamento critico su un ambiente Windows 11 Pro aggiornato con Docker Desktop 4.73.

Dopo l’aggiornamento:

  • Docker Desktop non si avviava più;
  • i processi com.docker.* comparivano e sparivano immediatamente;
  • la distribuzione WSL2 docker-desktop-data risultava nello stato Uninstalling;
  • tutti i container, le immagini e i volumi sembravano scomparsi.

Nel nostro caso erano coinvolti oltre 100 GB di dati Docker tra:

  • container persistenti,
  • database PostgreSQL/MariaDB,
  • ambienti Odoo,
  • stack Docker Compose,
  • immagini personalizzate.

Fortunatamente il file VHDX contenente i dati era ancora presente e recuperabile.

La causa

Durante l’aggiornamento alla versione 4.73, Docker Desktop ha abilitato automaticamente la funzionalità:

Use containerd for pulling and storing images

Questa opzione introduce il nuovo image store basato su containerd e modifica il modo in cui Docker Desktop gestisce:

  • immagini,
  • snapshot,
  • metadata,
  • runtime storage.

Nel nostro caso la migrazione non è stata completata correttamente, lasciando WSL2 in uno stato incoerente.


Sintomi riscontrati

  • Docker Desktop non si avvia
  • docker-desktop-data in stato Uninstalling
  • nessun container visibile
  • backend Docker che crasha subito
  • reinstallazione che non corregge il problema

Procedura di recupero adottata

  1. Backup immediato del file .vhdx
  2. Arresto completo WSL2
  3. Disinstallazione controllata di Docker Desktop
  4. Installazione Docker Desktop 4.72
  5. Disabilitazione della funzione containerd image store
  6. Ripristino manuale del file docker_data.vhdx
  7. Riavvio ambiente WSL2

Dopo il ripristino:

  • tutti i container,
  • le immagini,
  • i volumi persistenti

sono tornati operativi senza perdita dati.


Considerazioni tecniche

Questo episodio conferma quanto sia importante:

  • effettuare backup dei file VHDX WSL2;
  • evitare aggiornamenti immediati in ambienti critici;
  • testare nuove release Docker Desktop;
  • mantenere dump indipendenti dei database;
  • valutare l’uso diretto di Docker Engine su Linux.

Per workload professionali persistenti, Linux rimane generalmente più prevedibile e stabile rispetto al layer Docker Desktop su Windows.


Conclusione

Docker Desktop resta uno strumento estremamente utile per sviluppo e test, ma quando vengono introdotte modifiche profonde al backend storage/runtime, è fondamentale prestare attenzione agli aggiornamenti automatici e alle migrazioni containerd.

Nel nostro caso il backup preventivo del file VHDX ha evitato una potenziale perdita di oltre 100 GB di ambienti containerizzati.

Contattaci: per approfondimenti e info tecniche.