apple/container、Container Machine機能を追加

(github.com/apple)

6 ポイント投稿者 xguru 5 시간 전 | 3件のコメント | WhatsAppで共有

MacでLinuxコンテナを軽量仮想マシンの形で作成・実行するツール
WWDC26で新たに追加された**Container Machine** は、ホームディレクトリとリポジトリが自動的にマウントされた高速・軽量・永続的なLinux環境を実行可能
従来のアプリケーション単位のコンテナとは異なり、Linux環境全体をモデル化（WSL2に近い）
イメージのinitシステムを実行し、長時間稼働するサービスの登録や、プロセスマネージャ配下でのアプリケーションテストが可能
systemdがインストールされたイメージでは、systemctl start postgresqlのような実際のLinuxサービスを実行可能
ユーザー名とホームディレクトリを自動マッピングし、リポジトリやdotfileをmacOSとLinuxの両方で共有
リポジトリはmacOSの$HOMEにあり、内部の/Users/<username>にマウントされるため、macOSのエディタやIDEで編集しながら内部でビルド・実行できる
プロファイラ、ブラウザ、GUIデバッガなどのmacOSネイティブツールが同じファイルを認識し、ビルドと検査の間でコピー手順が不要
alpine、ubuntu、debianなど対象ディストリビューションの数だけContainer Machineを作成可能で、それぞれ同じ$HOMEとdotfileを共有するため、複数ディストリビューションで素早くテストできる
- /sbin/initを含むあらゆるLinuxイメージを直接Container Machineイメージとして使用可能
OCI互換コンテナイメージを利用・生成するため、標準コンテナレジストリからDockerイメージのpull・pushが可能
- 他のOCI互換アプリケーションでもそのイメージを実行可能
- 低レベルのコンテナ・イメージ・プロセス管理はContainerization Swiftパッケージに依存
実行にはApple silicon搭載Macが必要で、macOS 26でサポート
- macOS 26の仮想化・ネットワーキングの新機能および改善点を活用しており、以前のmacOSバージョンは非対応
Apache-2.0ライセンス

動作コマンド

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

WWDC26の紹介動画 - Container Machineを見る

ContainerizationはWWDC 25でオープンソースとして公開されたSwiftフレームワークで、macOSでLinuxコンテナを実行するための基盤
各コンテナに仮想マシンベースの隔離を提供するよう設計されており、軽量仮想マシンのため高速な性能と1秒未満の起動時間を提供
Container machineはContainerization上に構築された新機能で、コンテナの使いやすさと速度に仮想マシンの永続性を組み合わせ、統合機能によってLinux環境がmacOSの拡張のように感じられるようにする
設計原則
- Container machineは既存ワークフローに統合できるよう、高速で軽量であるべき
- macOSとLinuxの間を容易に切り替えられるべき
- ユーザーが新しい環境を素早く作成してカスタマイズできるべきであり、これにより複数プロジェクトが依存関係やツールチェーンの衝突を心配せず専用環境を持てる
- 開発ライフサイクルの間に必要なツールや依存関係は変化しうるため、永続的な環境でツールを追加し、時間が経っても再利用できるべき
- 複数プラットフォーム向けに開発するとき、大きなコンテキストスイッチや新しいツールの学習が不要であるべき

3件のコメント

recast7838 19 분 전

十分な性能は出るでしょうか？

click 4 시간 전

どう見てもMac版のWSL2ですが、ホストのボリュームをマッピングするときにI/O性能が大きく落ちることはないんでしょうか。
今も limactl でVM上でコンテナを動かしていますが、あまり大きな違いはないようにも感じます

GN⁺ 4 시간 전

Hacker Newsのコメント

いくつか明確にしておくと、これはOCIコンテナだけを指すものではない
Container Machines は永続性とファイルシステムのマウントをサポートしていて、macOS を使う開発者にとって優れた軽量 Linux 環境になる
詳細はこちら: https://developer.apple.com/videos/play/wwdc2026/389
- ああ、Linux 向けのDarwin/BSD サブシステムというわけか
OrbStack は自分にはかなり合っている
パフォーマンス面でこれと比べてどうなのか気になる
- OrbStack の開発者です
  Virtualization.framework の代わりに、ファイルシステム共有のような機能のためのカスタムデバイスやプロトコルを備えたRust ベースの仮想化スタックを独自に使っています
  Linux マシンとコンテナの実行に特化して高度に最適化した垂直統合スタックです
  最大の性能・リソース面の利点は動的メモリで、未使用メモリを macOS に返すことでメモリ使用量を大きく減らします
  Containerization を含め、他のものはこれをサポートしていません
  Container Machines を試したところ、OrbStack のマシンというよりデフォルトの bind mount が付いた OCI コンテナにかなり近いように見えました
  統合機能が少なく、systemd や一般的な init システムを動かさないので、サービスを実行しづらいです
- OrbStack はコンセプトとしては気に入っているが、オープンソースで無料の代替が多い中で、年額96ドルのライセンスを正当化するのは難しいと思う
  今ならむしろ Podman や Colima を使う
- https://tart.run/ との比較も見てみたい
  自分にはかなり似ているように見える
- 完全な Docker 環境ではなく、ビルド用途を狙って作られたものだ
  オプションで dockerd も実行できるし、https://github.com/cpuguy83/crucible は Containerization フレームワークで buildkitd や dockerd を実行して、docker/buildx CLI や好みのクライアントツールに接続する
  Containerization フレームワークは Virtualization フレームワークの上に載るライブラリなので、各コンテナがそれぞれ独自の VM になる
  Machine は Containerization フレームワークの上で、VM 内のコンテナに対して複数のタスクを実行するためのツールだ
- OrbStack は本当に気に入っているし、現時点ではなぜ代わりにContainer Machinesを使うべきなのかまだよく分からない
これらのコンテナは共通カーネルを共有するのか？それともそれぞれ別の VM で動くのか？
修正: コンテナごとに VM が1つある https://github.com/apple/container/blob/main/docs/technical-...
Apple のコンテナはAI コーディングエージェントにサンドボックスを提供するのに向いている
すべてのコーディングエージェントが簡単に見つけられるよう、MCP として用意してある
https://github.com/instavm/coderunner
コンテナのボリュームを、たとえば外付けドライブに変更できるのか気になっていた
今は QMEU と qcow2 イメージを使ってそうしていて、そこそこうまく動いている
macOS がなぜWSL1 方式を試さないのか気になる
Windows でそれが完全には成功しなかった理由は理解できるが、macOS は別の *nix なので、Windows では難しかった多くの部分も Mac では簡単なはずだ
少し新しい API を足すだけで、大半の Linux アプリケーションを macOS 上でネイティブ実行できそうに見える
BSD には実際すでにこういうものがある
- いずれにせよ Apple が必要とするVM インフラに対して、どんな利点があるのだろう？
  Linux カーネルに比べれば ABI ははるかに単純で安定しているのに
これは Docker Desktop 系を置き換えて、横で動いている高コストな Linux VMをなくせるのだろうか？
- 自分も最初にそう思った
  Docker Desktop のオーバーヘッドはかなり大きいので、これが DD にネイティブに入ってくれたらいいのにと思う
  Docker が歴史的に性能改善を試みつつも、プラットフォームの限界をすぐ受け入れざるを得なかったことを考えると可能性はありそうで、DD をコンテナ側に寄せるのは自然に見える
- 大きな共有バックグラウンド VM をほぼなくして、より小さくより隔離されたApple ネイティブ VMに置き換える形だ
  自分の Podman ワークロードを Apple container に移す実験をしてみた: https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...
  要するに RAM とストレージ使用量が減り、存在感が最小限になる
- ここでも他の人が触れているが、自分は最近Colimaに乗り換えた
  Docker Desktop を回避しながら作業するのはつらい
- そうなってくれたら本当にうれしい
  数日に一度 rm -rf ~/.colima をやっている気がする
Apple がこれをやるほど気にかけていたことに驚く
それでも自分はやはり Linux を使いたいが、MacBook の価値は非常に高い
- 自分も常に Linux を使いたいが、たまに会社が MacBook を支給してくる
  このツールは使うかもしれない
Apple が Linux コンテナを誇示するのを見るたび、敗北の認識以外には見えない
まだ十分な力があったなら、Darwin でも同じことができたはずだ
- Apple は macOS をプロプライエタリコードにすると決めた時点で、サーバー市場と開発者市場で負ける舞台を自ら整えた
  本気の開発者が、特に本番サーバーで、デバッグも修正もできないクローズドソースのコードをなぜ使うだろうか？
  本気の開発者やハッカーが macOS を使わない理由も同じだ
  開発者であることの本質の一つは、どのレイヤーのコードでも潜ってデバッグし、修正できる能力だからだ
- インターネットの歴史を30年分変えればいいだけだ
- 代わりに何があるだろう？
  Apple は10年前にサーバー市場を諦めており、その前から実質的なサポートもほとんどなかった
  Darwin コンテナをサポートしたところで何の意味があるのか？文字通り誰もそれ向けにはビルドしないだろうし、Linux の勝ちだ
これは新機能なのか？
以前からあったものだと思っていた
自分が試したときは、小さなファイルを大量に stat する Node/Rust の開発環境ではファイルシステム性能が実用的な水準ではなかった
更新: 新しいのは container machine サブコマンドのこと
試そうとしたが、自分の環境では container 自体が起動しなかった: https://github.com/apple/container/issues/1681
- OrbStack を試したことがあるか気になる
  まだやることはあるが、テストしたいワークロードは歓迎だ
  OrbStack のカスタムファイルシステム共有プロトコルでは、小さなファイルや一般的な開発者向けワークロードの最適化にかなり力を入れている
  標準の virtiofs ではない
- ちなみにPodmanは macOS でも動く
  既存の container フレームワークを使ってマシンを実行する
  root 権限方式でも rootless 方式でも可能だ