- Containerizationは、macOSでLinuxコンテナを実行できるようにするSwiftベースのオープンソースツール
- Apple Silicon搭載Macで動作し、Virtualization.frameworkを活用して軽量仮想マシン内に各コンテナを分離して実行
- OCIイメージ管理、リモートレジストリ連携、ext4ファイルシステム生成、コンテナ環境制御など多様な機能を含む
- Rosetta 2を活用し、Apple Silicon上でもx86_64プロセスの実行をサポート可能
- 超短時間起動、軽量環境の提供、カーネルバージョンのカスタマイズなどにより、開発者の柔軟性と性能を高める
プロジェクト概要
- Containerizationは、アプリケーションがLinuxコンテナを利用できるようにするSwiftパッケージ
- Swift言語で実装されており、Apple SiliconベースのMacでVirtualization.frameworkを活用して動作する
- APIを通じて以下の機能を提供する
- OCIイメージ管理
- リモートコンテナレジストリ連携
- ext4ファイルシステムの生成と配置
- Netlinkソケットファミリーとの相互作用
- 高速起動のための最適化されたLinuxカーネルの提供
- 軽量仮想マシンの作成と管理
- 仮想マシンの実行環境の制御
- コンテナ化されたプロセスの生成と制御
- Rosetta 2を活用したApple Silicon上でのx86_64プロセス実行
- APIドキュメントは公式ページで確認可能
デザインと構造
- 各Linuxコンテナは独立した仮想マシン内で実行される
- コンテナごとに専用IPアドレスを割り当てられるため、ポートフォワーディングなしでもネットワーク管理が容易
- 最適化されたカーネル設定と軽量ルートファイルシステムにより、1秒未満でのコンテナ起動が可能
- vminitdはContainerizationのサブプロジェクトで、仮想マシン内で初期プロセスとして動作する軽量initシステム
- GRPC APIを通じて実行環境を設定し、コンテナプロセスの運用管理を支援する
- 入出力、シグナル、イベント処理を呼び出し元のプロセスへ受け渡す
要件
- Apple Silicon Macが必要
- パッケージのビルドには
- macOS 15以降とXcode 26 Beta
- またはmacOS 26 Beta 1以降が必要
- macOS 15を使用する場合、以下の機能に制限がある
- 非分離コンテナネットワーキング: 同じvmnetネットワーク上のコンテナ間通信は不可
使用例
- cctl実行ファイルを提供: APIのさまざまな機能を試せるプレイグラウンド的な位置づけ
- 主なコマンド例
- OCIイメージの操作
- コンテナレジストリへのログイン
- ルートファイルシステムブロックの生成
- シンプルなLinuxコンテナの実行
Linuxカーネル構成
- コンテナ向け軽量仮想マシンの実行にはLinuxカーネルが必要
- Containerizationが提供する最適化カーネル設定は
kernelディレクトリに配置されている
- この設定は最小限の機能だけを含み、高速起動と軽量環境を実現する
- 必要に応じて、コンテナごとにカーネル設定とバージョンを異なるものに指定できるAPIが用意されている
- Kata Containersプロジェクトが提供する
vmlinux.containerなどの事前コンパイル済みカーネルも利用可能
- ただし、VIRTIOドライバーがカーネルに組み込み済み(compiled-in)である必要がある
開発およびテストプロセス概要
- Swift、Static Linux SDKなどの環境準備が必要
- ソースコードのビルドとテストが可能 (
make all、make test integrationコマンドなど)
- gRPC/Protobuf関連の特定バージョンを利用する依存関係構成をサポート
- APIドキュメントの自動生成とローカルプレビュー機能を搭載
オープンソースへの貢献とプロジェクト状況
- 貢献歓迎
- 0.1.0が最初の公式リリースであり、ソースの安定性はマイナーバージョン範囲内でのみ保証される
- 今後のマイナーリリースで方針が変更される可能性がある
要約
- Containerizationは、macOS上で開発者が最適化された環境によりLinuxコンテナを管理・実行・開発できるようにする革新的なSwiftパッケージ
- 各コンテナを軽量な専用仮想マシンで動作させることで、分離、性能、ネットワーキング、カーネルカスタマイズの利点を提供する
- オープンソースのコンテナ環境をmacOSネイティブ体験へ拡張したい開発者に適したソリューション
1件のコメント
Hacker Newsの意見
最も驚きで興味深い部分だと思った内容を共有
Appleのオープンソースコミュニティ参加は、それほど驚くことではないという意見
Swiftおよび関連フレームワークにも、オープンソースコミュニティからの貢献が多いことに言及
このプロジェクトはLinuxを扱う以上、Linuxのコピーレフト（強いオープンソースライセンス）のためにAppleが協業方式を取らざるを得ない、という見方
関連動画としてWWDC 2025発表映像(https://developer.apple.com/videos/play/wwdc2025/346/)を推薦
各コンテナは軽量なLinux VMとして分離される構造
containerツールをダウンロードして直接実行可能(https://github.com/apple/container/releases)、macOS 26が必要今回の投稿は https://github.com/apple/containerization であり、
containerプロジェクトとは別物containerizationはアプリがコンテナのサイドカーと一緒に配布される用途なので、より興味深いニュース一方
containerは、開発者がdocker run ...のような環境を使うためのものcontainer関連については別のHNスレッド(https://news.ycombinator.com/item?id=44229239)を案内macOS 15でも動作可能だが、一部のネットワーキング機能は制限される可能性がある点に注意
プレスリリースおよびWWDCセッションで、CLIツールが https://github.com/apple/container にあることに言及
こうしたツールに強い関心がある立場として、最新のXcode Betaに標準同梱されることを期待していたが、まだ入っていない
prebuiltパッケージは現在準備中だが、作業状況は公開Issue(https://github.com/apple/container/issues/54)で確認できる
コメントのちょうど1分後にprebuiltパッケージ公開(https://github.com/apple/container/releases/tag/0.1.0)の知らせを共有
関連議論は別のHNスレッド(https://news.ycombinator.com/item?id=44229239)で進行中
Dockerの立場からすると、どんな気分なのか気になる
Docker for Desktopユーザーのかなりの割合がMacを使っていそうだと想像
今回の変化は、むしろDocker Desktopの開発をずっと容易にするという意見
これで独自にLinux VMをセットアップしなくても済むため、開発難易度が下がる
それでも多くのユーザーは、慣れ親しんだCLI、Docker Compose、多様なDocker独自のUXのために従来のDocker Desktopを好むだろうという予測
コンテナランタイムを切り替えるのは簡単なことではないという説明
Dockerの立場では、podmanに対するときと似た感情ではないかという推測
Docker Desktopはクローズドソースの商用ソフトウェアで、今回のプロジェクトは自由ソフトウェアなので、ユーザーにとっては良いニュースだという考え
この技術がLinuxコンテナをmacOSアプリにバンドルするのに使えるのか気になる
例として、GPTのようなツールがrootのCLIコマンドなしにLinux環境へアクセスできるようにする際に必要性がある
macOS 26でのみ動けばよいなら、まさにその目的にすぐ使えるという案内
そうでなければVirtualization.frameworkを直接使っても可能だが、追加作業がより必要だという説明
まさにこの目的のために出てきた技術だという確信
コンテナごとにそれぞれ分離されたVMで実行され、完全な隔離や独立したIP付与など興味深い構造だが、こうした設計はLinuxやWindowsでは一般的ではない
開発チームに1人でもMacを使わない人がいるとローカル開発モデルが崩れてしまうという欠点
Docker/Composeの置き換えになるのは簡単ではないという結論
主要デスクトップOS 3つのうち2つが、いまや公式にLinux VMを動かしてLinuxネイティブアプリケーションを実行できるようになった
この流れを見ると、Linuxが事実上勝ったと言えるという主張が可能
LinuxのシステムコールAPIは、今やほぼどこでも動く汎用APIの位置にある
2つの主要な非Linux OS上でLinuxベースのアプリケーション開発が普通に行われなければならないという事実自体を、「Linuxの勝利」と見るのは難しいという反論
デスクトップLinuxの現実は依然として不安定で、人に勧めにくいという体験談
毎年Fedora/Ubuntuを最新のPCやノートPCに入れてみても、依然として使い勝手と安定性を感じられないという率直なフィードバック
むしろ他の2つのプラットフォームがLinuxを離れずに使える手段を提供することで、デスクトップ市場におけるLinux自体のシェア拡大を遅らせるという見方
グラフィックス、オーディオ、GUIまわりには、まだまともなソリューションがないという欠点を強調
「ゲームに参加しているプレイヤーが自分しかいないなら勝ちなのか」という疑問を提起
普通のWindowsやMacユーザーに言っても、Linuxが何なのかすら分からないだろうという冗談
「Linuxと共にあるmacOS」という事実自体がインパクトだという意見
彼らがメモリ管理（必要以上にVMがメモリを使わない構造）も最適化しているのか気になる
正確にどんな過程なのかは分からないが、ビルド速度がかなり遅く感じる
-c,-mオプションでCPU/メモリ資源をさらに増やしてみたが、効果をあまり感じなかった過去にApple Silicon Mac + Rancher Desktopの組み合わせでx86イメージをビルドしているつもりだったが、実際のx86ハードウェアではそのイメージがまともに動かなかった経験を共有
短いデモ(https://developer.apple.com/videos/play/wwdc2025/346)で、数百ミリ秒単位でVMを起動できる点が印象的
Virtualization.frameworkで動作しており、これはDocker desktop/Colima/UTMなども選択的に使っていた技術
コンテナを複数並列で回したときのメモリオーバーヘッドが気になる