- Mac'te Linux konteynerlerini hafif sanal makineler biçiminde oluşturup çalıştıran bir araç
- WWDC26'da yeni eklenen Container Machine, home dizini ile depoların otomatik olarak mount edildiği hızlı, hafif ve kalıcı bir Linux ortamı çalıştırabiliyor
- Mevcut uygulama düzeyindeki konteynerlerden farklı olarak Linux ortamının tamamını modelliyor (WSL2'ye benzer)
- İmajın init sistemini çalıştırarak uzun süre çalışan servisleri kaydetmek veya bir süreç yöneticisi altında uygulamaları test etmek mümkün
systemd yüklü imajlarda systemctl start postgresql gibi gerçek Linux servisleri çalıştırılabiliyor- Kullanıcı adı ve home dizinini otomatik eşleyerek depoların ve dotfile'ların hem macOS hem Linux tarafında paylaşılmasını sağlıyor
- Depolar macOS
$HOME altında bulunuyor ve içeride /Users/<username> konumuna mount ediliyor; macOS editörü ya da IDE ile düzenlerken içeride derleyip çalıştırmak mümkün
- Profiler, tarayıcı, GUI debugger gibi macOS yerel araçları aynı dosyaları görüyor; derleme ile inceleme arasında kopyalama adımına gerek kalmıyor
alpine, ubuntu, debian gibi hedef dağıtım sayısı kadar Container Machine oluşturulabiliyor; her biri aynı $HOME ve dotfile'ları paylaştığı için farklı dağıtımlarda hızlı test yapılabiliyor
/sbin/init içeren herhangi bir Linux imajı doğrudan Container Machine imajı olarak kullanılabiliyor
- OCI uyumlu konteyner imajlarını tüketip ürettiği için standart konteyner registry'lerinden Docker imajları da pull/push yapılabiliyor
- Diğer OCI uyumlu uygulamalarda da bu imajlar çalıştırılabiliyor
- Düşük seviyeli konteyner, imaj ve süreç yönetimi Containerization Swift paketine dayanıyor
- Çalıştırmak için Apple silicon içeren bir Mac gerekiyor, macOS 26 üzerinde destekleniyor
- macOS 26'daki yeni sanallaştırma ve ağ özellikleriyle iyileştirmelerden yararlanıyor; önceki macOS sürümleri desteklenmiyor
- Apache-2.0 lisansı
Çalıştırma komutları
container machine create alpine:latest --name dev
container machine run -n dev whoami # your host username, not root
container machine run -n dev pwd # /home/<you> — your Mac home dir, mounted in
container machine run -n dev # interactive shell; cd into your repos in $HOME
container machine ls # list all container machines
container machine inspect dev # JSON detail for one
container machine stop dev # stop the container machine
container machine rm dev # delete, including its persistent storage
container machine set -n dev cpus=4 memory=8G
container machine stop dev
container machine run -n dev -- nproc
- Containerization, WWDC 25'te açık kaynak olarak yayımlanan ve macOS'te Linux konteynerlerini çalıştırmanın temelini oluşturan bir Swift framework'ü
- Her konteyner için sanal makine tabanlı izolasyon sağlayacak şekilde tasarlanmış; hafif sanal makineler sayesinde hızlı performans ve 1 saniyenin altında açılış süresi sunuyor
- Container machine, Containerization üzerine inşa edilen yeni bir özellik; konteynerlerin kullanılabilirliği ve hızını sanal makinelerin kalıcılığıyla birleştiriyor, ayrıca entegrasyon özellikleri sayesinde Linux ortamının macOS'in bir uzantısı gibi hissettirmesini sağlıyor
-
Tasarım ilkeleri
- Container machine, mevcut iş akışlarına entegre olabilmesi için hızlı ve hafif olmalı
- macOS ile Linux arasında geçiş kolay olmalı
- Kullanıcılar yeni ortamları hızlıca oluşturup özelleştirebilmeli; böylece birden çok proje, bağımlılık veya toolchain çakışması endişesi olmadan kendine özel ortamlara sahip olabilmeli
- Geliştirme yaşam döngüsü boyunca gereken araçlar ve bağımlılıklar değişebileceği için, kalıcı bir ortamda araç eklemek ve bunları zaman içinde yeniden kullanabilmek mümkün olmalı
- Birden fazla platformu hedefleyerek geliştirme yaparken büyük bir bağlam değişimi ya da yeni araçlar öğrenme ihtiyacı olmamalı
3 yorum
Yeterli performans çıkar mı?
Ne kadar baksam da bu, sanki WSL2’nin Mac sürümü gibi; host volume eşlerken I/O performansının ciddi şekilde düşmesi gibi bir durum olmaz mı acaba?
Şu anda da
limactlile VM üzerinde container çalıştırıyorum, çok da farklı değilmiş gibi geliyor bana.Hacker News yorumları
Burada birkaç şeyi netleştireyim, bu sadece OCI container anlamına gelmiyor
Container Machines kalıcılığı ve dosya sistemi mount etmeyi destekliyor, bu yüzden macOS kullanan geliştiriciler için harika bir hafif Linux ortamı oluyor
Ayrıntılar burada: https://developer.apple.com/videos/play/wwdc2026/389
OrbStack bana çok iyi uyuyor
Performans açısından bununla karşılaştırınca nasıl olduğunu merak ediyorum
Virtualization.framework yerine, dosya sistemi paylaşımı gibi özellikler için özel aygıtlar ve protokoller içeren Rust tabanlı bir sanallaştırma yığınını doğrudan kullanıyoruz
Linux makineleri ve container çalıştırma için özel olarak yüksek düzeyde optimize edilmiş, dikey entegre bir yığın bu
En büyük performans/kaynak kazancı dinamik bellek; kullanılmayan belleği macOS'e geri vererek bellek kullanımını ciddi biçimde azaltıyor
Containerization dahil diğerleri bunu desteklemiyor
Container Machines'i deneyince, OrbStack makinelerinden çok varsayılan bind mount eklenmiş OCI container'lara daha yakın göründü
Daha az entegrasyon özelliği var ve systemd ya da genel bir init sistemi çalıştırmadığı için servisleri çalıştırmak zor
Şimdilik Podman ya da Colima kullanmayı tercih ederim
Bana oldukça benzer görünüyor
İsteğe bağlı olarak dockerd de çalıştırabiliyor ve https://github.com/cpuguy83/crucible Containerization framework ile buildkitd veya dockerd çalıştırıp sonra docker/buildx CLI ya da istediğiniz istemci aracıyla bağlanıyor
Containerization framework, Virtualization framework üstüne kurulu bir kütüphane olduğu için her container kendi VM'idir
Machine ise Containerization framework üzerinde, VM içindeki container üzerinde çeşitli işler çalıştıran bir araçtır
Bu container'lar ortak bir kernel mi paylaşıyor? Yoksa her biri ayrı bir VM'de mi çalışıyor?
Düzeltme: her container için bir VM var https://github.com/apple/container/blob/main/docs/technical-...
Apple container'ları AI kodlama ajanları için sandbox sağlamak adına iyi görünüyor
Tüm kodlama ajanlarının kolayca keşfedebilmesi için bunu MCP olarak hazırladım
https://github.com/instavm/coderunner
Container volume'lerini örneğin bir harici sürücüye taşımanın mümkün olup olmadığını merak ediyordum
Şu anda QMEU ve qcow2 imajlarıyla bunu yapıyorum ve fena çalışmıyor
macOS'in neden WSL1 tarzı bir yaklaşımı denemediğini merak ediyorum
Bunun Windows'ta neden tam başarıya ulaşmadığını anlıyorum ama macOS de başka bir *nix olduğu için, Windows'ta zor olan pek çok şey Mac'te daha kolay olabilir gibi geliyor
Birkaç yeni API eklense Linux uygulamalarının çoğunu macOS üzerinde yerel olarak çalıştırmak mümkün görünüyor
BSD'de aslında bunun bir örneği zaten var
Linux kerneline kıyasla ABI çok daha basit ve kararlı sonuçta
Bu, Docker Desktop benzerlerinin yerini alıp yanda çalışan pahalı bir Linux VM'ini ortadan kaldırabilir mi?
Docker Desktop overhead'i oldukça yüksek, bu yüzden bunun DD'ye yerel olarak gelmesi güzel olurdu
Docker'ın tarihsel olarak performansı iyileştirmeye çalışıp sonra platform sınırlarını hızla kabullenmek zorunda kaldığını düşününce mümkün görünüyor; DD'yi container tarafına taşımak da doğal bir adım gibi
Podman iş yükümü Apple container'a taşımayı denedim: https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...
Kısacası RAM/depolama kullanımı azalıyor ve sistemde neredeyse görünmez hâle geliyor
Docker Desktop'tan kaçınarak çalışmanın acısı büyük
Sanki birkaç günde bir
rm -rf ~/.colimaçalıştırıyorumApple'ın bunu yapacak kadar önem vermesi şaşırtıcı
Yine de ben hâlâ Linux kullanmak isterim ama MacBook'un değeri gerçekten çok yüksek
Bu aracı kullanabilirim
Apple'ın Linux container'larını öne çıkardığını her gördüğümde bunu yenilgiyi kabul etmekten başka türlü görmek zor
Hâlâ yeterli kapasitesi olsaydı Darwin ile de bunu yapabilirdi
Ciddi bir geliştirici, özellikle production sunucuda, debug edip düzeltemeyeceği kapalı kaynak kodu neden kullansın?
Ciddi geliştiricilerin ya da hacker'ların macOS kullanmamasının nedeni de aynı
Geliştirici olmanın temel parçalarından biri, hangi katman olursa olsun kodun içine inip debug edebilmek ve düzeltebilmektir
Apple sunucu pazarından 10 yıl önce vazgeçti ve ondan önce de gerçekte neredeyse hiç desteği yoktu
Darwin container desteği sunsa bile bunun ne anlamı olurdu ki? Kelimenin tam anlamıyla kimse onu hedefleyerek build almazdı; Linux kazandı
Bu yeni bir özellik mi?
Zaten vardı sanıyordum
Test ettiğimde, çok sayıda küçük dosyada
statyapan Node/Rust geliştirme ortamlarında dosya sistemi performansı kullanılabilir düzeyde değildiGüncelleme: yeni olan şey
container machinealt komutuDenemeye çalıştım ama benim ortamımda container hiç çalışmadı: https://github.com/apple/container/issues/1681
Hâlâ yapılacak işler var ama test edilecek iş yüklerine açığız
OrbStack'in özel dosya sistemi paylaşım protokolünde küçük dosyaları ve yaygın geliştirici iş yüklerini optimize etmek için çok emek verdik
Standart virtiofs değil
Zaten mevcut olan container framework'ü kullanarak machine çalıştırıyor
Hem root yetkili hem de rootless mod mümkün