Apple Container (container) v0.7.1 動作検証レポート

📌 この記事は goose (gemini-3-flash-preview) が調査を行い記事を作成しました。

⚠️ Apple container は現在 v0.7.1 であり、多くの機能や最適化が開発途上です。現時点では Docker Desktop 等を置き換えるものではありません。

macOS で動作する Docker 代替のコンテナツール、Apple container コマンド (v0.7.1) の動作検証を行いました。 Homebrew でインストールした環境での結果をまとめます。

検証結果サマリー

項目結果備考
ポートマッピングの到達性🙆問題なくアクセス可能
ホスト名解決🙆container system dns create で有効化可能
exec -it の TTY 安定性🙆エディタ操作もスムーズ
exec 時の環境変数注入🙆
シグナル伝播 (Stop挙動)🙆即座に終了を確認
編集の即時反映 (Inotify)🙆ホスト側の変更を検知
パーミッションのマッピング🙆
読み取り専用マウント🙆-v ...:ro および --mount ...,readonly 両対応
--mount 構文の解釈🙆type=bind 等の指定が可能
Rosetta 2 経由の実行 (amd64)🙆Apple Silicon 上で x86_64 イメージが動作
host.docker.internal 互換性🙅Docker Desktop 固有の機能のため未対応
--add-host の解釈🙅オプション自体が存在しない
ユーザー定義ネットワークとDNS🙅名前空間が共有されており --network-alias も未実装

ネットワークとホスト疎通

ポートマッピングと名前解決

ポートマッピング (NET-03) は期待通り動作します。

container run -d --name port-test -p 8080:80 nginx

ホスト側から localhost:8080 でアクセス可能です。

また、ホスト名解決 (NET-04) については、専用の DNS を作成することで利用可能になります。

container system dns create my-dns
container system property set dns.domain my-dns

具体的には、ホスト (macOS) の /etc/resolver/containerization.my-dns というファイルが作成されます。 macOS の mDNSResponder はこのファイルを参照し、*.my-dns へのクエリを container が提供する DNS サーバー (127.0.0.1:2053) へ自動的に転送します。

DNS サーバーが正しく応答しているかは、以下のようにホスト (macOS) から直接クエリを投げて確認することも可能です。

dig +short @127.0.0.1 -p 2053 <コンテナ>.my-dns

ネットワークの制限

ユーザー定義ネットワーク (NET-05) については、ネットワークの分離自体は機能していますが、コンテナ間の名前空間が共有されているという特徴があります。 また、Docker でよく利用される --network-alias オプションが実装されていないため、柔軟な名前解決の設定には制限があります。

なお、ネットワークを作成・使用すると、macOS ホスト側では ifconfig で確認できる bridge100bridge101 といった仮想ネットワークインターフェースが作成されます。

ifconfig
bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
	options=63<RXCSUM,TXCSUM,TSO4,TSO6>
	ether xx:xx:xx:xx:xx:xx
	inet 192.168.65.1 netmask 0xffffff00 broadcast 192.168.65.255
	inet6 fe80::xxxx:xxxx:xxxx:xxxx%bridge100 prefixlen 64 scopeid 0x1b
	member: vmenet0 flags=20003<LEARNING,DISCOVER,VIRTIO>
	status: active

さらに、Docker Desktop でよく使われる host.docker.internal (NET-01) は利用できません。 --add-host (NET-02) オプションも現時点ではサポートされていないため、既存の Docker ワークフローをそのまま持ち込む際には注意が必要です。

コンテナ実行と操作

TTY とシグナル

exec -it (EXE-01) による TTY 安定性は高く、vi などのエディタ操作も崩れることなく行えます。 環境変数の注入 (EXE-02) も正常に機能します。

container exec -e TEST_VAR=hello exec-test env | grep TEST_VAR

コンテナの停止 (EXE-03) もスムーズで、SIGTERM が正しく伝播していることが伺えます。

ファイルシステムとリソース

ファイルマウント (Bind Mount)

ホスト側のファイルをマウントした際の Inotify (STO-01) は正常に動作しており、ホスト側でのファイル編集が即座にコンテナ内へ反映されます。パーミッションのマッピング (STO-02) も良好です。

また、--mount 構文 (STO-04) もサポートされており、type=bind を明示したマウントが可能です。 読み取り専用マウント (STO-03) についても、-v ...:ro--mount ...,readonly の両方の形式で正しく機能し、コンテナ内からの書き込みが拒否されることを確認しました。

container run --rm -v $(pwd):/data:ro alpine touch /data/test.txt

アーキテクチャ

Rosetta 2 (RES-02) を利用した amd64 イメージの実行に対応しています。

container run --rm --platform linux/amd64 alpine uname -m

Apple Silicon Mac 上でも x86_64 として動作し、QEMU ほど大きな遅延を感じることなく利用できました。

まとめ

Apple container コマンドは、非常に軽量で macOS との親和性が高いツールです。 Docker 固有の便利機能 (host.docker.internal など) に依存しているプロジェクトでは調整が必要ですが、シンプルなコンテナ実行環境としては十分に実用的です。 特に名前解決の仕組みが macOS の resolver と連携している点は、macOS ネイティブなツールらしさを感じます。