Apple lansează o alternativă Docker alimentată de Swift pentru macOS

Apple a introdus o alternativă open-source, bazată pe Swift, la Docker pentru rularea containerelor Linux pe macOS, concentrată pe securitate și izolare.

Apple a lansat în tăcere un nou proiect open-source care ar putea schimba semnificativ modul în care sunt rulate containerele pe macOS. Numele său simplu este container și introduce un runtime pentru containere, nativ pentru Apple și bazat pe Swift, proiectat special pentru sistemele macOS, în special pentru cele care rulează pe Apple Silicon.

În esență, container permite utilizatorilor să traga, să construiască, să ruleze și să împingă containere Linux standard compatibile cu OCI. Totuși, spre deosebire de Docker, care de obicei se bazează pe o mașină virtuală partajată pentru toate containerele pe macOS, abordarea Apple rulează fiecare container într-o micro-VM proprie, ușoară, completă cu un kernel Linux izolată și un stack de rețea. Conform paginii GitHub a proiectului:

Instrumentul consumă și produce imagini de containere compatibile OCI, astfel încât puteți prelua și rula imagini din orice registru standard de containere. De asemenea, puteți încărca imaginile pe care le creați în acele registre și rula imaginile în orice altă aplicație compatibilă OCI.

Acest model reflectă conceptul de microVM-uri popularizat de instrumente precum Firecracker, dar a fost integrat strâns în macOS prin Virtualization.framework, interfața nativă de hypervisor a Apple.

Deși Apple nu promovează acest lucru ca pe o înlocuire completă pentru Docker, instrumentul acoperă multe dintre aceleași aspecte pentru cazurile de utilizare în dezvoltarea locală. CLI-ul este familiar și accesibil: cu comenzi precum container image pull alpine sau container run -ti alpine sh.

Ceea ce diferențiază acest instrument este integrarea sa perfectă în sistemul de operare macOS în sine. În loc să emuleze un mediu Linux cu unelte externe, soluția Apple folosește Swift pentru o mare parte din partea sa de utilizator, inclusiv un mic sistem init numit vminitd care pornește containerele în câteva milisecunde.

Proiectul include, de asemenea, un pachet Swift, „Containerization”, care expune API-uri de nivel jos pentru gestionarea imaginilor, volumelor, rețelelor și proceselor de pornire, oferind utilizatorilor avansați și dezvoltatorilor de instrumente o bază puternică.

Ok, până acum totul bine, dar acum, permiteți-mi să împărtășesc câteva gânduri proprii pe această temă. Sincer, sunt puțin confuz de această mișcare a Apple. Și o să explic imediat de ce.

Mai întâi, să clarificăm un lucru – nu există ceva numit containerizare nativă adevărată pe vreun sistem de operare în afară de Linux, și există un motiv simplu pentru asta. Docker se bazează pe funcționalități ale nucleului Linux, cum ar fi cgroups, namespaces și sistemele de fișiere overlay, pe care nucleul macOS nu le poate oferi.

Din acest motiv, noul proiect Apple folosește o mașină virtuală Linux separată și ușoară pentru a rula fiecare container în parte. În același timp, abordarea Docker este să ruleze totul într-o singură mașină virtuală (creată cu LinuxKit) care găzduiește Docker Engine și toate containerele.

Așadar, în cazul Apple, fiecare container se află în propriul său VM separat, ceea ce înseamnă multe VM-uri (indiferent cât de ușoare sunt), ceea ce nu pare cea mai eficientă abordare.

Pe de altă parte, VM-urile separate au totuși unele avantaje. De exemplu, un avantaj cheie al noului proiect Apple este că oferă fiecărui container propriul său kernel Linux dedicat, spre deosebire de Docker, care împarte un singur kernel între toate containerele (nu poți combina versiuni diferite de kernel pentru fiecare container).

În plus, utilizează și stiva de rețea nativă a macOS, în timp ce Docker se bazează în general pe o mașină virtuală cu NAT sau rețea în punte. Pentru a clarifica acest lucru, am întocmit un tabel comparativ rapid:

În ciuda tuturor diferențelor, ideea de bază este aceeași în ambele cazuri—construirea, rularea și lucrul cu imagini de containere conforme OCI. Din această perspectivă, Docker oferă în continuare mult mai multă flexibilitate și capacități decât noul proiect al Apple.

De exemplu, nu există încă un echivalent docker-compose, iar ecosistemul de instrumente (de exemplu, fără un panou de control GUI, orchestrare limitată) are încă nevoie să fie dezvoltat și îmbunătățit.

Așadar, mă întreb de ce Apple a depus atâta efort pentru a crea acest lucru. În afară de „Made by Apple”, se pare că doresc să își ia partea din această nișă uriașă, aproape complet dominată de Docker, oferind o integrare mai bună cu macOS, folosind API-uri native ale sistemului în loc de demoni terți și, în cele din urmă, o izolare mai bună a securității, ceea ce reduce suprafața de atac.

Deoarece proiectul este încă în fazele sale incipiente, va fi interesant de văzut cum va evolua și dacă va putea să atingă așteptările Apple, înlocuind în cele din urmă Docker sau Podman ca instrument preferat pentru containere pentru dezvoltatori pe macOS.