Bella l’idea di base di Docker: crei il tuo container per risolvere il tuo problema, o per erogare il tuo servizio in un dato modo, ed una volta creata l’immagine dello stesso questa può girare ovunque: sul portatile dello sviluppatore, sul “serverino” Docker di sviluppo, fino ad arrivare all’orchestratore di propria scelta. Parafrasando Tolkien, “un’immagine per erogarli tutti”.

Questo “mondo idilliaco” però ha subito una brusca frenata in questi giorni con -finalmente- il rilascio di Docker Desktop per i nuovi portatili Apple con chip M1. Ricordiamo che questi portatili hanno la loro architettura basata su ARM64, ma occorre fare un passo indietro.

Innanzi tutto, nonostante la release sia totalmente funzionante sui chip M1 dell’azienda di Cupertino, ulteriori ricerche hanno dimostrato che non tutte le sue componenti sono state ricompilate per la nuova architettura: alcune componenti risultano ancora compilate per Darwin/AMD64 e, di conseguenza, richiedono uno strato di “interpretazione” di mezzo, Rosetta 2. Seppur come di consueto a livello di end-user la Apple ha reso la procedura di installazione e l’utilizzo assolutamente trasparente per l’utente, non si può ignorare -soprattutto a livello di performance- la presenza di un ulteriore strato software tra il chip (M1) ed il software compilato (Docker Desktop).

Ma se anche soprassedessimo a questa parte, bisogna sempre ricordare che essendo l’archittettura in questione ARM64, le immagini che andremo ad eseguire devono essere fatte ad-hoc. Poco male considerando la diffusione, ma alcuni componenti “abbastanza” utilizzate ancora non forniscono, in maniera ufficiale, supporto ai container su queste architetture. Per citarne uno tra tutti, MySQL.

Ma non è solo questo. Dai test effettuati da alcuni utenti pare che alcuni container basati su Intel vadano in crash per un errore di QEMU nell’esecuzione del container. Tutto questo ha fatto si che nonostante nel post di annuncio venisse annunciato che:

Docker has had support for multi-platform images for a long time, meaning that you can build and run both amd64(Intel) and arm64 (Apple Silicon) images on Docker Desktop today. The new Docker Desktop for Apple Silicon is no exception; you can build and run images for both x86 and ARM architectures without having to set up a complex cross-compilation development environment.

Docker ha il supporto per immagini multi-piattaforma da tanto tempo, dando la possibilità di creare ed eseguire sia immagini per amd64(Intel) che per arm64(Apple Silicon) su Docker Desktop. Il nuovo Docker Desktop per Apple Silicon non fa eccezione; puoi creare ed eseguire immagini sia per x86 che per architetture ARM senza dover configurarti un complesso ambiente di sviluppo cross-platform.

andando poi a guardare la pagina con la guida all’installazione del prodotto troviamo:

… we recommend that you run ARM64 containers on Apple Silicon machines. These containers are also faster and use less memory than Intel-based containers

… raccomandiamo che tu esegua container ARM64 sulle macchine Apple Silicon. Questi container sono anche più veloci ed utilizzano meno memoria dei container basati su Intel.

Quindi, compatibilità si, ma con riserbo. Se includiamo altri “piccoli” bug, come il fatto che al momento il ping non funziona da dentro i container, con il consiglio dalla stessa Docker di utilizzare tool come curl o wget per testare la connettività, allora forse questi nuovi portatili, per quanto interessanti dal punto di vista della durata della batteria e delle prestazioni, non sono ancora pronti al 100% per chi lavora o utilizza intensivamente Docker.

Ma a questo punto viene da pensare: il problema è questo nuovo uso di un’architettura, o l’idea di base che c’è dietro Docker? Se il punto di forza del prodotto è la sua estrema portabilità, e l’aggiunta di un chip ha creato questo polverone richiedendo a molti manutentori di container di iniziare a pensare di fornire il prodotto delle proprie build anche compilato per arm64, siamo davvero sicuri che sia tutto questo parco dei divertimenti?

Certo, non ci aspettiamo che nei prossimi anni escano in continuazione nuovi chip o nuove architetture che i manutentori di immagini debbano supportare, ma l’avvento di M1 ha sicuramente dimostrato come un nuovo player importante in gioco può rallentare lo sviluppo e dare vita ad una “corsa” per il supporto.

Con la speranza che le nuove iterazioni siano completamente compatibili con queste, altrimenti con l’avvento (che prima o poi avverrà) di M2 saremo punto ed a capo.

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.