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 で確認できる bridge100 や bridge101 といった仮想ネットワークインターフェースが作成されます。
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 ネイティブなツールらしさを感じます。