ハイライト
Container machineはContainerizationフレームワークの新機能です。macOS上で軽量かつ永続的なLinux環境を提供し、自動ユーザーマッピング、ファイルシステム共有、シームレスなワークフロー統合を備えています。
概要
macOSでLinux向けのサーバーアプリを開発するとき、開発者は長く悩ましい選択を迫られてきました。
従来の仮想マシンは完全なLinux環境と永続的な状態を提供しますが、起動が遅く、リソース消費も大きくなりがちです。Dockerなどのコンテナソリューションは軽量で高速ですが、起動するたびに新しい環境になり、変更は標準では永続化されません。さらに重要なのは、どちらの方式でもmacOSとの間を行き来するときに、ファイル同期、ユーザー権限、パスマッピングなどの処理が必要になり、開発の流れが途切れてしまうことです。
AppleがWWDC25でオープンソース化したContainerizationフレームワークは、新しい方向性を示しました。軽量な仮想マシンを使い、コンテナレベルの分離と起動速度を実現するという考え方です。その土台の上に、WWDC26で発表されたContainer machineは、コンテナの軽さと仮想マシンの永続性を組み合わせ、さらにmacOSとの深い統合によってプラットフォーム切り替えの摩擦を減らします。
Container machineの設計は、軽量で高速、管理しやすい、状態が永続化される、ネイティブに統合される、という4つの原則を中心にしています。コンテナと同じOCIイメージ形式を使い、ほぼ瞬時に起動し、変更を保持できます。自動ユーザーマッピングによってLinux環境内のユーザー名はmacOSとそろい、ファイルシステムは自動共有され、現在の作業ディレクトリも対応します。これらの設計により、Linux環境はmacOSの自然な延長のように感じられます。
詳細
Container machineはContainerizationフレームワークの上に構築されています。各Container machineは独立した軽量仮想マシン内で動作し、標準のOCIイメージを使い、containerツールの第一級機能として扱われます。
基本コマンド(4:41)
container machineコマンドは、実行できる操作の概要を表示します。
container machine
要点:
- create、run、stopなどの利用可能な操作を表示します
- 引数なしで使うとヘルプ情報として機能します
新しいContainer machineを作成します。
container machine create --name demo --set-default alpine
要点:
--nameでマシン名を指定します--set-defaultでデフォルトのマシンに設定し、以後のコマンドで名前を繰り返し指定しなくてよくなりますalpineはよく使われる軽量Linuxイメージです- コンテナと同じOCIイメージ形式を使います
Container machine内でコマンドを実行します。
container machine run echo hi
要点:
- Linux環境で単一のコマンドを実行します
- コマンドの実行が終わると戻ります
システム種別の違いを確認します。
container machine run uname
要点:
- macOS上では
unameが”Darwin”を返します - Container machine内では”Linux”を返します
- コードがLinux環境で実行されていることを確認できます
自動統合機能(5:39)
Container machineはmacOSのユーザー名と現在の作業ディレクトリを自動的に反映します。
# macOS上で
whoami # 現在のユーザー名を返します
pwd # 現在のユーザーディレクトリを表示します
Container machine内で同じコマンドを実行すると、同じユーザー名とパスが返ります。
要点:
- ユーザーマッピングによる自動ユーザー作成
- ファイルシステムの自動共有
- 作業ディレクトリの一貫性
- マッピング関係を手動で設定する必要がありません
インタラクティブシェルを起動します。
container machine run
要点:
- 引数なしで使うとインタラクティブセッションを開始します
- 完全なLinuxシェル環境に入れます
- 複数ステップの操作を実行できます
マシンの一覧表示と管理(8:01)
container machine list
要点:
- すべてのContainer machineの名前を表示します
- 各マシンのIPアドレスを表示します
- リソース使用状況を表示します
- IPアドレスはネットワークアクセスに使います
クロスプラットフォーム開発ワークフロー(7:03)
デモでは、典型的なクロスプラットフォーム開発の流れが示されます。macOS上のXcodeでコードを編集し、Linux環境でビルドして実行し、Safariで結果をテストする流れです。
プロジェクト構成:
Package.swift
Source/
Public/ # 静的アセット
Container machine内でVaporサーバーを実行します。
container machine run
swift run
要点:
- 共有ファイルシステムを通じてプロジェクトファイルにアクセスします
- Container machineは独立したネットワークを持ちます
- macOSからアクセスするにはマシンのIPアドレスを使います
Vaporの設定では、Container machineのIPアドレスを使って外部インターフェイスをリッスンする必要があります。
要点:
- Xcodeで設定を変更します
- 変更はすぐにContainer machine内で利用できます
- 再起動やリロードは不要です
示されたワークフロー:
- Xcodeでコードを編集する
- Container machine内でビルドして実行する
- Safariでアクセスしてテストする
- Icon Composerでアイコンを変更する
- Safariを更新すると変更が反映される
- ファイルコピーや同期操作は不要
アーキテクチャ(1:00)
Containerizationフレームワークは次を提供します。
- ストレージAPI
- ネットワークAPI
- 実行API
- Linux initシステム
各コンテナは仮想マシンベースの分離を得て、起動時間は1秒未満です。
要点:
- 軽量仮想マシンが性能面の利点を提供します
- 仮想マシンレベルの安全な分離
- 高速起動により頻繁な切り替えを支えます
実践アイデア
-
マイクロサービスのローカル開発環境
- マイクロサービスごとに1つのContainer machineを用意し、ツールチェーンと依存関係を分離します
- 「自分のマシンでは動く」問題を避けられます
- 入口:
container machine create --name service-a
-
CI/CDパイプラインの予行演習
- Container machineで本番Linux環境を再現します
- デプロイスクリプトと設定をローカルで検証します
- 入口: 本番環境のOCIイメージからマシンを作成します
-
複数言語プロジェクトの統一開発
- macOSでフロントエンドを扱い、Container machineでバックエンドサービスを実行します
- プロジェクトファイルを共有し、同期は不要です
- 入口: 対象言語のツールチェーンを含むイメージを導入します
-
ツールチェーンのバージョン分離
- プロジェクトごとに異なるNode.js、Python、Goのバージョンを使えます
- バージョン管理ツールを使わず、各マシンを独立した環境にできます
- 入口: ツールチェーンのバージョンに基づく専用マシンを作成します
-
安全なサンドボックステスト
- 信頼できないコードを分離されたLinux環境でテストします
- 仮想マシンレベルの分離がホストを保護します
- 入口:
container machine runでテストコマンドを実行します
関連セッション
- 121 Siriの新機能 — Agentシステムのアーキテクチャは、コンテナ化されたデプロイから恩恵を受けられる可能性があります
- 242 Agenticアプリを構築する — Agenticアプリのローカルサーバーコンポーネントは、Container machineで開発できます
- 268 アプリの応答性を最適化する — ローカルで実行しているLinuxサービスをInstrumentsで分析します
- 319 Private Cloud Computeを知る — PCCアーキテクチャにおけるコンテナ化技術
- 241 Foundation Modelsを知る — 大規模モデルをローカルにデプロイするためのコンテナ化アプローチ
コメント
GitHub Issues · utterances