Apple lanserar ett Swift-baserat Docker-alternativ för macOS

Apple introducerade ett Swift-baserat, open source-alternativ till Docker för att köra Linux-containrar på macOS, med fokus på säkerhet och isolering.

Apple har tyst lanserat ett nytt open-source-projekt som kan förändra hur containrar körs på macOS. Projektet, som enkelt heter container, introducerar en Swift-baserad, Apple-native container-miljö som är speciellt utformad för macOS-system, särskilt de som körs på Apple Silicon.

I grunden tillåter container användare att hämta, bygga, köra och skicka standard-OCI-kompatibla Linux-containrar. Men, till skillnad från Docker, som vanligtvis använder en delad virtuell maskin för alla containrar på macOS, kör Apples metod varje container i sin egen lätta mikro-VM, komplett med en isolerad Linux-kärna och nätverksstack. Enligt projektets GitHub-sida:

Verktyget använder och producerar OCI-kompatibla containerbilder, så du kan hämta och köra bilder från vilken standardcontainerregister som helst. Du kan också skicka bilder som du bygger till dessa register och köra bilderna i vilken annan OCI-kompatibel applikation som helst.

Den här modellen speglar konceptet med microVMs som populariserats av verktyg som Firecracker, men den har integrerats tätt i macOS genom Virtualization.framework, Apples inbyggda hypervisorgränssnitt.

Även om Apple inte marknadsför detta som ett fullfjädrat alternativ till Docker, täcker verktyget mycket av samma område för lokala utvecklingsfall. CLI är bekant och lättillgänglig: med kommandon som container image pull alpine eller container run -ti alpine sh.

Det som skiljer detta verktyg åt är dess sömlösa integration i själva macOS-operativsystemet. Istället för att emulera en Linux-miljö med externa verktyg använder Apples lösning Swift för stora delar av sitt användarland, inklusive ett litet init-system kallat vminitd som startar containrar på bara några millisekunder.

Projektet inkluderar också ett Swift-paket, „Containerization“, som exponerar låg-nivå API:er för att hantera bilder, volymer, nätverk och uppstartsprocesser, vilket erbjuder avancerade användare och verktygsutvecklare en kraftfull grund.

Okej, hittills har det gått bra, men nu låt mig dela några egna tankar om ämnet. Ärligt talat är jag lite förvirrad över detta drag från Apple. Och jag ska förklara varför genast.

Först och främst, låt oss klargöra en sak—det finns ingen riktig äkta native-containerisering på något operativsystem annat än Linux, och det finns en enkel anledning till det. Docker är beroende av Linux-specifika kärnfunktioner som cgroups, namespaces och overlay-filsystem, vilka macOS-kärnan inte kan erbjuda.

Av den anledningen använder det nya Apple-projektet en separat lättvikts-Linux-VM för att köra varje enskild container. Samtidigt är Dockers tillvägagångssätt att köra allt inom en enda virtuell maskin (byggd med LinuxKit) som rymmer Docker Engine och alla containers.

Så, i Apples fall är varje container i sin egen separata VM, vilket innebär många VMer (oavsett hur lätta de är), vilket inte verkar vara det mest effektiva tillvägagångssättet.

Å andra sidan har separata virtuella maskiner vissa fördelar. Till exempel är en viktig fördel med Apples nya projekt att varje container får sin egen dedikerade Linux-kärna, till skillnad från Docker, som delar en enda kärna mellan alla containrar (du kan inte blanda kärnversioner per container).

Dessutom använder det även den inbyggda nätverksstacken i macOS, medan Docker vanligtvis är beroende av en virtuell maskin med NAT eller bryggat nätverk. För att göra detta tydligare har jag satt ihop en snabb jämförelsetabell:

Trots alla skillnader är kärnidén densamma i båda fallen—att bygga, köra och arbeta med OCI-kompatibla containerbilder. Ur det perspektivet erbjuder Docker fortfarande mycket mer flexibilitet och fler funktioner än Apples nya projekt.

Till exempel finns det ännu ingen motsvarighet till docker-compose, och verktygsekosystemet (t.ex. ingen GUI-instrumentpanel, begränsad orkestrering) behöver fortfarande utvecklas och förbättras.

Så jag undrar varför Apple lade all denna ansträngning på att skapa detta. Förutom „Made by Apple“ verkar de vilja ta sin del av denna enorma nisch, nästan helt dominerad av Docker, genom att erbjuda bättre macOS-integration, använda systeminbyggda API:er istället för tredjepartsdaemoner och i slutändan bättre säkerhetsisolering, vilket minskar attackytan.

Eftersom projektet fortfarande är i sin linda blir det intressant att se hur det utvecklas – och om det kan leva upp till Apples förväntningar genom att så småningom ersätta Docker eller Podman som det främsta containerverktyget för utvecklare på macOS.