WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Meet Containerization

Meet Containerization

開発ツール
元の動画を見る

ハイライト

Containerization は Apple がオープンソースとして公開している Swift フレームワークです。各 Linux コンテナは独自の軽量 VM 内で動作し、サブ秒単位で起動、独立した IP を持ち、コンテナ実行時のリソースオーバーヘッドはゼロです。

主要内容

Mac 上で Linux コンテナを動かすには、これまで主流な方法が一つしかありませんでした。大きな VM を一つ起動し、すべてのコンテナをその中に詰め込んで共用する方法です。リソースは VM 内部で割り当てられ、ディレクトリ共有は VM にマウントしてからコンテナに通し、ポートはマッピングが必要で、攻撃対象領域も大きな VM とともに拡大します。開発者は Linux 環境は手に入れますが、セキュリティと分離性は妥協を余儀なくされます。

Apple は WWDC25 で別のアプローチを提示しました：Containerization です。これは Swift で書かれたオープンソースフレームワークで、イメージ管理、コンテナ実行、Swift 実装の init システムを提供します。最も重要なトレードオフは、各コンテナが独自の軽量 VM 内で動作することで、起動時間はサブ秒単位になります。各コンテナは独立した IP を取得し、ポートマッピングは不要です。ディレクトリはコンテナ単位で共有され、リクエストを発行したコンテナのみが内容を確認できます。コンテナが動作していないときのリソースオーバーヘッドはゼロです。フレームワークの上にはオープンソースの CLI ツール container も提供されており、数百ミリ秒で Alpine コンテナのシェルに入ることができます（11:03）。

詳細

イメージ管理について（04:10）。イメージはファイルシステムの内容とデフォルト設定を組み合わせた配布物で、新しいコンテナのテンプレートとして機能します。Containerization は Registry からプルする API を提供し、応答をローカルに書き込みます。イメージのファイルシステムはファイル単位で展開されるのではなく、ブロックデバイスとしてフォーマットされます。大きなファイルを作成し、EXT4 でフォーマットします。EXT4 は Linux で広く使われているファイルシステムで、フレームワークは Swift パッケージを提供しており、Swift 側から直接フォーマット、ディレクトリ構造の作成、EXT4 コンテンツの填充が可能です（05:41）。

仮想マシン内部は vminitd が引き継ぎます（07:14）。これは Swift で書かれた init システムで、VM の最初のプロセスとして動作し、ネットワークインターフェースへの IP 割り当て、イメージブロックデバイスが公開するファイルシステムのマウント、VM 内のすべてのプロセスの起動と監視、そしてホスト側にプロセスを起動するための API を公開します。Containerization が提供する最小ファイルシステムには libc、動的ライブラリ、cd/cp/ls のような core utilities は含まれていません（08:22）。vminitd がこの環境で動作するように、Swift Static Linux SDK でクロスコンパイルされ、静的リンクに対応した musl という libc 実装にリンクされた静的バイナリになっています（08:43）。

container CLI はこれらを組み合わせて開発者が利用可能な入り口を提供します（09:26）。CLI と複数の XPC サービスで構成され、それぞれ Storage、イメージ管理、Network（IP 割り当てと DNS）、そしてコンテナランタイムを担当します。イメージのプル：

container image pull alpine:latest

重要なポイント：

  • container は Containerization フレームワークに基づいて構築されたオープンソース CLI ツールです
  • image pull サブコマンドは Registry に Alpine 最新版のファイルシステムと設定を要求します
  • プルプロセスはローカルにブロックファイルを作成し、EXT4 でフォーマットされたイメージ内容を格納します

対話的なシェルを起動（10:43）：

container run -t -i alpine:latest sh

重要なポイント：

  • run はイメージのファイルシステムと設定を使ってコンテナを作成し、フレームワーク経由で軽量 VM を起動します
  • -t は TTY 端末デバイスを要求し、-i は現在の入力をコンテナに接続します。これらを組み合わせると対話的なシェルになります
  • 最後の二つはイメージ名と実行するコマンドで、ここでは直接 sh を実行します
  • デモではコンテナが数百ミリ秒でシェルに入り、uname -a で Linux 環境が表示され、ps aux では自身のシェルと ps プロセスしか見えず、ホストや他のコンテナのプロセスは見えません（11:08）

設計全体のセキュリティ上の利点は二つの要素の組み合わせから生まれます。各コンテナの分離境界が完全な VM と同等であること、そして VM 内部には core utilities や動的ライブラリがないため、攻撃者が侵入後に利用できるツールが極めて限られていることです。

重要ポイント

  • ローカル開発ではまず container CLI で Docker Desktop を置き換えて動作確認：なぜやるのか――大きな VM のリソース常駐オーバーヘッドを回避でき、コンテナが動いていないときはメモリを消費しない。独立した IP により複数サービスのデバッグでポートマッピングを山のように書く必要がなくなる。どう始めるのか――container image pull でよく使うベースイメージをプルし、チームの Dockerfile をローカルで container run で一通り試して、動作が一致することを確認する。
  • Swift Static Linux SDK で依存関係ゼロの Linux バイナリを作る：なぜやるのか――vminitd は Swift でクロスコンパイルすれば libc 依存のない静的 Linux 実行ファイルを作れることを証明しており、任意の最小イメージにデプロイしても動的ライブラリの問題を心配する必要がない。どう始めるのか――Mac 上で Static Linux SDK を設定し、Go/Rust で書かれた小さなツールを一つ選んで Swift で書き直し、musl にリンクして、サイズと起動速度を確認する。
  • EXT4 Swift パッケージをイメージ/ディスクツールチェーンに活用する：なぜやるのか――以前は macOS 側から Linux ファイルシステムを構築するには e2fsprogs や Docker に頼る必要があったが、今は純粋な Swift でフォーマット、ディレクトリ作成、内容の填充が可能。どう始めるのか――Containerization リポジトリの EXT4 パッケージを参考に、ローカルディレクトリを EXT4 ブロックファイルにパッケージングする CLI を書き、VM のルートディスクとして使う。
  • コンテナごとの独立 IP でローカルマルチサービスデバッグを再構築する：なぜやるのか――独立 IP は本番環境の service-to-service 呼び出しパターンをそのままローカルに持ってくることで、NAT のメンタルオーバーヘッドが一つ減る。どう始めるのか――プロジェクト内で相互に呼び出し合う複数のサービスをそれぞれ別のコンテナで動かし、コンテナ IP で直結して localhost:portN を置き換え、ついでに .env のポートマッピングを削除する。

関連セッション

コメント

GitHub Issues · utterances