Apple lanceert een Swift-aangedreven Docker-alternatief voor macOS

Apple heeft een door Swift aangedreven, open-source alternatief voor Docker geïntroduceerd om Linux-containers op macOS te draaien, met de nadruk op veiligheid en isolatie.

Apple heeft stilletjes een nieuw open-sourceproject uitgebracht dat de manier waarop containers op macOS worden uitgevoerd aanzienlijk zou kunnen veranderen. Het eenvoudig genaamde container introduceert een Swift-aangedreven, Apple-native container-runtime die speciaal is ontworpen voor macOS-systemen, vooral voor systemen die draaien op Apple Silicon.

In de kern stelt container gebruikers in staat om standaard OCI-compatibele Linux-containers te downloaden, bouwen, uitvoeren en uploaden. In tegenstelling tot Docker, dat op macOS meestal afhankelijk is van een gedeelde virtuele machine voor alle containers, draait bij de aanpak van Apple elke container echter in zijn eigen lichte micro-VM, compleet met een geïsoleerde Linux-kernel en netwerkstack. Volgens de GitHub-pagina van het project:

Het hulpmiddel verbruikt en produceert OCI-conforme containerafbeeldingen, zodat je afbeeldingen kunt ophalen en uitvoeren vanaf elk standaard containerregister. Je kunt ook afbeeldingen die je bouwt naar die registers pushen en de afbeeldingen uitvoeren in elke andere OCI-conforme toepassing.

Dit model weerspiegelt het concept van microVM's dat populair is gemaakt door tools zoals Firecracker, maar het is nauw geïntegreerd in macOS via het Virtualization.framework, de native hypervisor-interface van Apple.

Hoewel Apple dit niet aanprijst als een volwaardige vervanging van Docker, dekt de tool wel veel van hetzelfde terrein voor lokale ontwikkelingsscenario's. De CLI is vertrouwd en toegankelijk: met commando's zoals container image pull alpine, of container run -ti alpine sh.

Wat dit hulpmiddel onderscheidt, is de naadloze integratie in het macOS-besturingssysteem zelf. In plaats van een Linux-omgeving te emuleren met externe tools, gebruikt de Apple-oplossing Swift voor het grootste deel van zijn gebruikersomgeving, inclusief een klein init-systeem genaamd vminitd dat containers binnen enkele milliseconden opstart.

Het project bevat ook een Swift-pakket, „Containerization”, dat low-level API's biedt voor het beheren van images, volumes, netwerken en opstartprocessen, en daarmee geavanceerde gebruikers en toolbouwers een krachtige basis biedt.

Oké, tot nu toe gaat alles goed, maar laat me nu een paar gedachten van mezelf over het onderwerp delen. Eerlijk gezegd ben ik een beetje in de war door deze zet van Apple. En ik zal meteen uitleggen waarom.

Laten we eerst één ding duidelijk maken: er bestaat geen echte native containerisatie op enig besturingssysteem anders dan Linux, en daar is een eenvoudige reden voor. Docker is afhankelijk van Linux-specifieke kernelfuncties zoals cgroups, namespaces en overlay-bestandssystemen, die de kernel van macOS niet kan bieden.

Om die reden gebruikt het nieuwe Apple-project een aparte lichtgewicht Linux-VM om elke afzonderlijke container uit te voeren. Tegelijkertijd is de benadering van Docker om alles binnen een enkele virtuele machine (gebouwd met LinuxKit) te draaien die de Docker Engine en alle containers host.

Dus, in het geval van Apple zit elk container in zijn eigen aparte VM, wat betekent dat er veel VM's zijn (ongeacht hoe licht ze ook zijn), wat niet de meest efficiënte aanpak lijkt.

Aan de andere kant hebben afzonderlijke VM's wel enkele voordelen. Zo is een belangrijk voordeel van het nieuwe project van Apple dat het elke container zijn eigen toegewijde Linux-kernel geeft, in tegenstelling tot Docker, dat één enkele kernel over alle containers deelt (je kunt de kernelversies niet per container mixen).

Bovendien maakt het ook gebruik van de native macOS-netwerkstack, terwijl Docker doorgaans afhankelijk is van een virtuele machine met NAT of bridged networking. Om dit duidelijker te maken, heb ik een korte vergelijkende tabel samengesteld:

Ondanks alle verschillen is het kernidee in beide gevallen hetzelfde—het bouwen, uitvoeren en werken met OCI-conforme containerafbeeldingen. Vanuit dat perspectief biedt Docker nog steeds veel meer flexibiliteit en mogelijkheden dan het nieuwe project van Apple.

Bijvoorbeeld, er is nog geen docker-compose-equivalent, en het tooling-ecosysteem (bijv. geen GUI-dashboard, beperkte orkestratie) moet nog worden ontwikkeld en verbeterd.

Dus ik vraag me af waarom Apple al deze moeite heeft gestoken in het creëren hiervan. Afgezien van ‘Made by Apple’, lijken ze hun aandeel te willen krijgen van deze enorme niche, die bijna volledig door Docker wordt gedomineerd, door betere macOS-integratie te bieden, gebruik te maken van systeem-native API’s in plaats van third-party daemons, en uiteindelijk betere beveiligingsisolatie, wat het aanvalsoppervlak verkleint.

Aangezien het project nog in de beginfase zit, zal het interessant zijn om te zien hoe het zich ontwikkelt - en of het kan voldoen aan de verwachtingen van Apple door uiteindelijk Docker of Podman te vervangen als het standaard containerprogramma voor ontwikkelaars op macOS.