Maca z Apple silicon z systemem macOS 26, czyli takich samych wymagań, jak narzędzie container ogólnie.5 Narzędzie jest otwartoźródłowe na GitHubie, napisane w języku Swift.5

← Wszystkie wpisy

Container machines: trwałe środowisko Linux na Macu

9 min read

Narzędzie container od Apple osiągnęło wersję 1.0 podczas tygodnia WWDC, a jego sztandarowa funkcja odpowiada na lukę, którą deweloperzy na Macu obchodzili przez lata: container machine, trwałe środowisko Linux zachowujące się jak część macOS.² Sesja WWDC, która je przedstawia, sprowadza całą ideę do jednego zdania: „Container machine jest szybki i lekki jak kontener, a trwały jak maszyna wirtualna”.¹ Repozytoria i pliki konfiguracyjne są dostępne po obu stronach, użytkownik logowania odpowiada kontu na Macu, a maszyna zachowuje swój system plików między sesjami, więc łańcuch narzędzi Linux skonfigurowany we wtorek wciąż tam jest w piątek.³

Watch on Apple Developer ↗

Sesja 389, „Discover container machines”.

W skrócie

container machine jest dostarczany w container 1.0.0, wydanym na GitHubie w tygodniu WWDC. Zapewnia „długowieczne środowiska Linux z ścisłą integracją z hostem” w oparciu o framework Containerization, który Apple udostępniło jako open source na WWDC 2025.²
Tam, gdzie kontenery są „wzorowane na aplikacji”, container machine jest „wzorowany na środowisku Linux”: uruchamia własny system inicjalizacji obrazu, utrwala zmiany w systemie plików i jest tworzony ze standardowych obrazów OCI.³
Wyróżnikiem jest integracja z hostem. Użytkownik logowania w Linux odpowiada kontu na Macu z sudo bez hasła, a katalog domowy jest zamontowany wewnątrz maszyny,⁴ zaś interaktywna powłoka umieszcza Cię w tym samym katalogu roboczym, z którego przyszedłeś w macOS.¹
Pełny zestaw podpoleceń to create, run, list, inspect, set, set-default, logs, stop oraz delete, z m jako krótkim aliasem.⁴
Wydanie 1.0 wprowadza również jedną przełomową zmianę, o której warto wiedzieć przed aktualizacją: plik konfiguracyjny TOML w lokalizacji ~/.config/container/config.toml zastępuje dawne właściwości systemowe oparte na UserDefaults, a podpolecenia container system property zniknęły.²

Środowisko Linux, a nie piaskownica aplikacji

Dokumentacja Apple wytycza tę granicę precyzyjnie: „Kontenery są zazwyczaj wzorowane na aplikacji. Container machine jest wzorowany na środowisku Linux”.³ Rozróżnienie ujawnia się w trzech zachowaniach. Container machine uruchamia własny system inicjalizacji obrazu, taki jak systemd czy openrc, można więc rejestrować długo działające usługi i testować aplikację pod prawdziwym nadzorcą procesów: systemctl start postgresql działa tak, jak na maszynie z Linuksem.³ Utrwala modyfikacje, więc instalowane narzędzia gromadzą się w czasie, zamiast znikać wraz z procesem.¹ I uruchamia się z tych samych obrazów OCI, których używają kontenery, więc obraz zbudowany za pomocą container build służy zarazem jako punkt wyjścia dla maszyny.¹

Pull request, który wprowadził tę funkcję, jasno przedstawia motywację: container uruchamia każde obciążenie w efemerycznej maszynie wirtualnej, więc przed wersją 1.0 nie istniał wbudowany sposób na utrzymanie trwałego środowiska Linux, do którego można się zalogować i w nim pracować.⁴ W tle każdy container machine wciąż otrzymuje obsługę Containerization: własną lekką maszynę wirtualną z izolacją opartą na VM i poniżejsekundowymi czasami startu, wokół których zbudowano ten framework.¹

Sesja ujmuje cele projektowe w kategoriach przepływu pracy: przełączanie się między macOS a Linuksem powinno być łatwe, środowiska powinny być szybkie do utworzenia, a „szybkie tworzenie pozwala wielu projektom mieć własne, dedykowane środowisko, bez obawy o sprzeczne zależności czy łańcuchy narzędzi”.¹ Jedna maszyna na docelową dystrybucję to zamierzony wzorzec, a każda maszyna widzi ten sam katalog domowy i pliki konfiguracyjne z Twojego Maca.³

Pętla: edycja na Macu, kompilacja wewnątrz Linuksa

Demo z sesji to serwer WWW oparty na Vapor, a przepływ pracy, który prezentuje, jest tu sednem sprawy.¹ Projekt jest edytowany w Xcode na macOS. Kompilacja i uruchomienie odbywają się wewnątrz container machine z zainstalowanym łańcuchem narzędzi Swift. Safari na Macu wczytuje działający serwer po adresie IP i porcie. Gdy prezenter ponownie eksportuje ikonę aplikacji z Icon Composer na Macu i nadpisuje plik, odświeżenie przeglądarki pokazuje nowy zasób bez kroku kopiowania, ponieważ maszyna i Mac współdzielą te same pliki.¹

Dokumentacja Apple uogólnia ten wzorzec: repozytorium znajduje się w $HOME na macOS i jest zamontowane wewnątrz maszyny, więc natywne narzędzia macOS (profilery, przeglądarki, graficzne debugery) widzą te same pliki, które widzi środowisko Linux. Jak ujmuje to dokumentacja, nie ma kroku kopiowania między „zbudowałem to” a „badam to”.³

Integracja z hostem sięga głębiej niż współdzielony punkt montowania. Maszyna automatycznie tworzy użytkownika Linux odpowiadającego nazwie użytkownika na Macu, nadaje mu sudo bez hasła i odzwierciedla bieżący katalog roboczy, więc whoami i pwd odpowiadają tak samo wewnątrz i na zewnątrz.¹ Jedynym poleceniem, które zmienia swoją odpowiedź, jest uname: Darwin na Macu, Linux w maszynie.¹

Jeden element tarcia pierwszego dnia warto poznać, zanim się na niego natkniesz: container machine ma izolowaną sieć, a sesja wprost stwierdza, że serwer wewnątrz niej musi nasłuchiwać na interfejsie zewnętrznym, zanim przeglądarka na Macu zdoła do niego dotrzeć.¹ Demo radzi sobie z tym tak, jak Ty to zrobisz: container machine list wyświetla adres IP każdej maszyny obok jej nazwy i zasobów, konfiguracja serwera przypina się do tego adresu, a Safari dociera do aplikacji pod adresem IP i portem maszyny.¹ Należy uwzględnić krok z adresem IP w każdym przepływie pracy, który obsługuje ruch wychodzący z maszyny.

Polecenia

Szybki start to cztery linie:³

container machine create alpine:latest --name dev
container machine run -n dev whoami       # your host username, not root
container machine run -n dev pwd          # your Mac home directory, mounted in
container machine run -n dev              # interactive shell

container machine run pełni podwójną rolę: z poleceniem wykonuje je raz i kończy działanie, bez polecenia otwiera interaktywną powłokę, a jeśli maszyna jest zatrzymana, najpierw ją uruchamia.³ Maszyna domyślna usuwa flagę -n z każdego wywołania:

container machine set-default dev
container machine run                     # operates on dev

Zarządzanie to znajome czasowniki: ls, inspect, logs, stop oraz rm, gdzie usunięcie maszyny usuwa również jej trwały magazyn.³ Zasoby można dostosować po utworzeniu za pomocą container machine set -n dev cpus=4 memory=8G, ze skutkiem przy następnym zatrzymaniu i uruchomieniu; pamięć domyślnie wynosi połowę pamięci hosta, a punkt montowania katalogu domowego może być rw (domyślnie), ro lub none.³ Każde polecenie akceptuje też m jako alias, więc m run i m ls działają.⁴

Przynieś własny obraz maszyny

Każdy obraz Linux zawierający /sbin/init działa jako container machine.³ Dokumentacja Apple dostarcza gotowy plik Dockerfile, który zamienia ubuntu:24.04 w obraz maszyny z systemd, OpenSSH i typowymi narzędziami wiersza poleceń, a następnie maskuje jednostki systemd, które nie mają sensu wewnątrz lekkiej maszyny wirtualnej.³ Buduje się go za pomocą container build i przekazuje tag do container machine create.

Provisioning ma furtkę awaryjną. Domyślnie container uruchamia wbudowany skrypt konfiguracyjny przy pierwszym rozruchu, aby utworzyć odpowiadającego użytkownika. Plik wykonywalny /etc/machine/create-user.sh w obrazie zastępuje ten skrypt; uruchamia się on jeden raz, jako root, przy pierwszym rozruchu, z ustawionymi CONTAINER_USER, CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME i CONTAINER_MACHINE_ID, dzięki czemu organizacja może zakodować własną konfigurację użytkownika we wspólnym obrazie bazowym.³

Reszta wersji 1.0, w tym przełomowa zmiana

Funkcja maszyny jest gwiazdą wydania, ale wersja 1.0 niesie zmiany, które dotyczą obecnych użytkowników.²

Tą przełomową jest konfiguracja. Plik TOML zastępuje właściwości systemowe oparte na UserDefaults, a podpolecenia container system property get i set zostały usunięte.² Usługa odczytuje ~/.config/container/config.toml przy uruchamianiu, z priorytetem pierwszego dopasowania (Twój plik użytkownika, następnie opcjonalny plik dostarczony z instalacją pakietu, na końcu zakodowane na stałe wartości domyślne), a zmiany wymagają ponownego uruchomienia usługi, aby zaczęły obowiązywać.⁶

Udogodnienia: polecenie container cp do kopiowania plików, opcja --stop-signal w container run oraz uporządkowane dane wyjściowe w postaci strukturalnej (JSON, YAML, TOML) dla poleceń ls i inspect w odniesieniu do kontenerów, obrazów, sieci i wolumenów.² Sieć otrzymuje poprawkę zgodności, która wykorzystuje połączenia XPC jako dzierżawy, aby powstrzymać wycieki adresów IP.² Zgodność z interfejsami API XPC w wersji 0 została usunięta, z obietnicą wersjonowanego API w późniejszym wydaniu.²

Wymagania pozostają niezmienne względem linii 0.x: Mac z Apple silicon, z systemem macOS 26. Opiekunowie projektu stwierdzają, że zazwyczaj nie zajmują się problemami, których nie można odtworzyć na macOS 26.⁵

Dlaczego przepływy pracy agentów powinny się tym interesować

Spostrzeżenie z mojej perspektywy, a nie twierdzenie Apple: container machine to dokładnie taki kształt środowiska, jakiego pragną agenty kodujące. Agenty działające na Macu potrzebują miejsca do wykonywania kompilacji, uruchamiania serwerów i instalowania zależności bez ingerencji w hosta: szybkiego w tworzeniu, izolowanego prawdziwą granicą VM, na tyle trwałego, by łańcuch narzędzi zainstalowany w jednej sesji przetrwał do następnej. Dotychczas odpowiedziami na Macu były maszyny wirtualne w stylu Docker Desktop (ciężkie, jedno wielkie współdzielone środowisko) albo efemeryczne kontenery (izolowane, lecz zapominające). Maszyna na projekt, utworzona z wersjonowanego obrazu OCI, z zamontowanym repozytorium i sudo bez hasła w środku, odpowiada temu, jak piaskownice agentów już działają na hostach Linux.

Ta sama właściwość służy zwykłej pracy wieloplatformowej. Server-side Swift jest oczywistym beneficjentem: demo z sesji to Vapor, a framework Foundation Models staje się otwartym oprogramowaniem tego lata z obsługą Linuksa, więc środowisko testowe dla pytania „czy mój kod Swift działa na Ubuntu” jest teraz o jedno container machine create od Ciebie. Porównaniem, które nasunie się każdemu, kto korzystał z Windowsa, jest WSL, a kierunek integracji jest taki sam: prawdziwe jądro Linux o powłokę od Ciebie, z plikami widocznymi po obu stronach. Wersja Apple przybywa z już dołączonym przepływem pracy opartym na obrazach.

FAQ

Czym jest container machine?

Container machine to trwałe środowisko Linux na macOS, dostarczane jako funkcja otwartoźródłowego narzędzia container od Apple, począwszy od wersji 1.0.0.² Działa we własnej lekkiej maszynie wirtualnej za pośrednictwem frameworka Containerization, uruchamia się ze standardowych obrazów OCI, działa system inicjalizacji obrazu i utrwala zmiany w systemie plików między sesjami.¹ Integracje z hostem montują katalog domowy w środku, dopasowują użytkownika Linux do konta na Macu z sudo bez hasła i utrzymują spójny katalog roboczy po obu stronach granicy.⁴

Czym różni się od zwykłego kontenera?

Dokumentacja Apple ujmuje to w jednym zdaniu: kontenery są „wzorowane na aplikacji”, a container machine jest „wzorowany na środowisku Linux”.³ Zwykłe obciążenie container run jest efemeryczne i skupione na procesie. Maszyna jest stanowa, działa systemd lub openrc i ma być odwiedzana wielokrotnie w czasie, niczym maszyna wirtualna z szybkością tworzenia kontenera.¹

Czego wymaga?

Maca z Apple silicon z systemem macOS 26, czyli takich samych wymagań, jak narzędzie container ogólnie.⁵ Narzędzie jest otwartoźródłowe na GitHubie, napisane w języku Swift.⁵

Czy aktualizacja do 1.0 coś psuje?

Jedną rzecz: konfiguracja systemowa przenosi się z właściwości opartych na UserDefaults do pliku TOML w lokalizacji ~/.config/container/config.toml, a podpolecenia container system property get/set zostają usunięte.² Informacje o wydaniu 1.0 zawierają odnośnik do samouczka dotyczącego migracji.² Usunięto również zgodność z interfejsem API XPC w wersji 0, co ma znaczenie, jeśli zbudowano klientów względem tego API.²

Container machines wpisują się w tę samą opowieść, którą to WWDC nieustannie snuło: Mac jako poważny dom dla rozwoju wieloplatformowego i agentowego. Uruchamianie agentowej AI na Macu z MLX obejmuje część tej opowieści dotyczącą udostępniania modeli, a Co nowego w Swift (2026) obejmuje prace nad językiem, które czynią Swift-on-Linux celem pierwszej klasy. Pełnym centrum serii jest Apple Ecosystem Series.

Bibliografia

Apple, WWDC 2026 session 389, Discover container machines. Official transcript. Source for the definition (“A Container machine is fast and lightweight, like a container, and persistent like a virtual machine”), the Containerization recap (Swift framework for Linux containers on macOS, VM-based isolation, sub-second start times, open-sourced at WWDC 2025 along with the container tool), the design principles (including “quick creation allows multiple projects to have their own, dedicated environment, without the worry of conflicting dependencies or toolchains”), the OCI image reuse, statefulness, automatic user mapping and working-directory mirroring, the uname Darwin/Linux demo, and the Vapor workflow demo (edit in Xcode on macOS, build and run inside the machine, load from Safari by machine IP, Icon Composer asset update visible without a copy step). ↩↩↩↩↩↩↩↩↩↩↩↩↩↩
Apple, container 1.0.0 release notes, GitHub. Source for the 1.0.0 release, the “long-lived Linux environments with tight host integration” description, the breaking TOML configuration change (replacing UserDefaults-backed system properties and removing the container system property get and set subcommands, with a linked migration tutorial), the container cp command, the --stop-signal option, the structured output cleanup for ls and inspect across containers, images, networks, and volumes, the XPC-connection-as-lease fix for IP address leaks, and the removal of version 0 XPC API compatibility with a versioned API promised in a subsequent release. ↩↩↩↩↩↩↩↩↩↩↩↩
Apple, Container machine documentation, apple/container repository. Source for the application-versus-environment framing (“Containers are typically modeled after an application. A container machine is modeled after a Linux environment”), the init-system behavior including the systemctl start postgresql example, the edit-on-Mac/build-inside workflow and the no-copy-step framing, the one-machine-per-distro pattern with shared $HOME and dotfiles, the quickstart commands, run booting a stopped machine, set-default, the management verbs with rm deleting persistent storage, set for cpus/memory taking effect after stop and start, the half-of-host-memory default, the rw/ro/none home-mount modes, the /sbin/init requirement for machine images, the Ubuntu 24.04 Dockerfile example, and the /etc/machine/create-user.sh first-boot hook with its CONTAINER_USER, CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME, and CONTAINER_MACHINE_ID variables. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩
Apple, pull request #1662: Add container machine for managing persistent Linux environments, apple/container repository, merged June 8, 2026. Source for the motivation (each workload runs in an ephemeral VM, with no built-in way to keep a persistent Linux environment to log into), the login user matching the host account with passwordless sudo, the home directory mount, the machine keeping its filesystem and running the image’s own init system such as systemd or openrc, the full subcommand list (create, run, list/ls, inspect, set, set-default, logs, stop, delete/rm), and the m alias. ↩↩↩↩↩
Apple, container README, GitHub. Source for the requirements (a Mac with Apple silicon; supported on macOS 26, with maintainers typically not addressing issues that cannot be reproduced on macOS 26) and the description of the tool as written in Swift and optimized for Apple silicon. ↩↩↩
Apple, container configuration tutorial, apple/container repository. Source for the configuration file location at ~/.config/container/config.toml, the first-match-wins precedence (user file, then an optional file shipped with the package install, then hardcoded defaults), and the service reading the file once at startup so changes require a restart. ↩