Appleのcontainerがv1.0.0に！！！

はじめに

Appleが公開している container 、ついにv1.0.0が出ました。以下containerだと一般名詞すぎて分かりにくいので containerと表現します。

名前だけ見ると「Apple版Docker？」と思ってしまいますが、実際には少し違います。container は、Mac上でLinuxコンテナを軽量VMとして作成・実行するためのCLIツールです。Swiftで書かれており、Apple silicon向けに最適化されています。また、OCI互換のコンテナイメージを扱えるため、標準的なコンテナレジストリからpullしたり、自分でbuildしたイメージをpushしたりできます。(GitHub)

この記事では、container が何をするものなのか、Docker Desktopと何が違うのか、Docker Desktopの代替になりそうなのかを整理します。

まだ実務レベルで使っていないため、実感というよりドキュメントベースでの話になります。

containerについて

container は、Mac上でLinuxコンテナを動かすためのツールです。

公式READMEでは、container は「Mac上でLinuxコンテナを軽量VMとして作成・実行するためのツール」と説明されています。Apple siliconに最適化されており、OCI互換イメージを読み書きできるため、Dockerなどで使われる一般的なコンテナイメージのワークフローに近い感覚で使えます。(GitHub)

例えば、コマンドとしては次のようなものがあります。

container run -it ubuntu:latest /bin/bash
container build -t my-app:latest .
container image pull alpine:latest

container run はイメージからコンテナを実行するコマンドです。container build はローカルのビルドコンテキストからOCIイメージを作成します。公式コマンドリファレンスでは、container run、container build、container create、container exec、container logs など、Docker CLIに近いコマンドが用意されています。(GitHub)

container はDockerそのものではないという点です。Docker風のCLIではありますが、Docker daemon互換の実装というより、AppleのContainerizationフレームワークを使ってLinuxコンテナを実行する別実装です。

container machine

container machine は、単発のアプリケーションコンテナというより、Mac上に永続的なLinux開発環境を作るための機能です。公式ドキュメントでは、container machineは高速・軽量・永続的で、標準OCIイメージをベースにでき、Mac側のユーザー名やホームディレクトリ共有といったホスト連携を提供すると説明されています。(GitHub)

例えば、次のように使えます。

container machine create alpine:latest --name dev
container machine run -n dev

container machineでは、Mac側のリポジトリをそのままLinux環境内から見られます。公式ドキュメントでは、Mac側の $HOME がcontainer machine内の /Users/<username> にマウントされ、MacのエディタやIDEで編集しつつ、Linux環境内でビルド・実行できると説明されています。(GitHub)

さらに、通常のアプリケーションコンテナとは違い、イメージのinit systemを起動できます。systemd が入ったイメージであれば、systemctl start postgresql のようにデータベースなどのサービスを起動してテストできます。(GitHub)

「Mac版WSL」っぽい使い方に近いです

Docker Desktopの代替になるか

では、container はDocker Desktopの代替になるのでしょうか。

Docker Desktopは、単にコンテナを実行するだけのツールではありません。公式ドキュメントでは、Docker DesktopはMac、Linux、Windows上でコンテナ化アプリケーションをビルド・共有・実行するためのアプリケーションであり、Docker Engine、Docker CLI、Docker Build、Docker Compose、Kubernetesなどを含む開発環境です。(Docker Documentation)

一方で、container はOCIイメージの実行・ビルド・レジストリ操作には対応していますが、Docker Desktopが提供しているエコシステム全体をそのまま置き換えるものではありません。

現時点で特に現場に導入しにくい点としてはDocker Composeをサポートしていないことです。

一応サードパーティの container-compose というツールは存在します。READMEでは、container に限定的なDocker Composeサポートを追加し、Composeファイルで複数コンテナアプリケーションを定義・起動できると説明されています。ただし、これはDockerやDocker Composeのラッパーではなく、Apple containerとComposeワークフローを橋渡しするツールです。(GitHub)Homebrewにも container-compose はあり、brew install container-compose で導入できます。(Homebrew Formulae) がせっかくファーストパーティのコンテナを手に入れたのにここだけサードパーティとなってしまうので、やはり導入の障壁はあります。

Docker Desktopとの違い

containerとDocker Desktopの一番大きな違いは、VMの使い方です。

MacはLinuxカーネルを持っていないため、Mac上でLinuxコンテナを動かすには、どこかでLinux環境を仮想化する必要があります。AppleのWWDCセッションでも、macOS上でLinuxコンテナを動かすにはLinux環境を仮想化する必要があり、従来の解決策は大きなVMを起動して、その中で複数のコンテナをホストする方式だったと説明されています。(Apple Developer)

Docker Desktop for MacもVMを使います。Dockerの公式ドキュメントでは、Docker Desktop on Macは、コンテナを実行するLinux VMを動かすために複数のVirtual Machine Managerをサポートしていると説明されています。(Docker Documentation)

図にすると、ざっくりこうです。

Docker Desktop for Mac:
macOS
  └─ Docker Desktop Linux VM
       ├─ container A
       ├─ container B
       └─ container C

一方、containerはコンテナごとに軽量VMを起動します。

Apple container:
macOS
  ├─ lightweight VM ─ container A
  ├─ lightweight VM ─ container B
  └─ lightweight VM ─ container C

Appleのtechnical overviewでは、macOSでLinuxコンテナを動かす典型的な方法は「すべてのコンテナをホストするLinux VM」を起動することだと説明したうえで、container は各コンテナごとに軽量VMを実行すると説明しています。(GitHub)

この設計により、各コンテナはフルVMに近い隔離性を持ちます。また、ホストのディレクトリを共有する場合も、必要なデータだけを各VMにマウントできるため、プライバシー面でも利点があると説明されています。(GitHub)

じゃあcontainerの方が起動が遅かったりメモリを使うのかというとそうでもないようです。 Apple公式は、container で作成されるコンテナはフルVMより少ないメモリで済み、起動時間は共有VM内のコンテナに近いと説明しています。(GitHub) その一方で、macOS Virtualization frameworkのmemory ballooningは部分的なサポートに留まり、コンテナVM内のLinuxで解放されたメモリページがホストmacOSに返らない場合があるとも説明されています。メモリを多く使うコンテナを多数動かす場合は、再起動が必要になることがあるようです。(GitHub)

Dockerコマンドの対応状況

containerはDocker風のコマンドを持っていますが、完全にDocker CLI互換というより、似た操作体系を持つ別CLIです。

公式コマンドリファレンスを見ると、container run、container build、container create、container exec、container logs などはかなりDockerユーザーに馴染みやすい構成です。container run ではCPUやメモリの指定、ポート公開、volume mount、network指定、Rosetta、SSH agent forwardingなどのオプションも用意されています。(GitHub)

GitHub上の議論によるとcontainerは、Docker Engine API互換を提供する方向ではなさそうです。そのため、既存の docker コマンドや docker compose をそのままApple containerに向ける、いわゆるDocker Desktopのドロップイン代替としては期待しにくいです。https://github.com/apple/container/issues/66#issuecomment-3009450447

慣れ親しんだdockerコマンドからcontainerを叩くことは、shellレベルの置き換えとかで対応できるのでエンドユーザー的には変わらないかもしれません。

対応OS

公式READMEでは、container の実行にはApple silicon Macが必要で、macOS 26がサポート対象だと説明されています。macOS 26の仮想化・ネットワーク機能を活用しているため、古いmacOSでしか再現しない問題は基本的にサポートしない方針です。(GitHub)

Homebrew formulaでは brew install container が用意されており、stableは1.0.0、要件はarm64アーキテクチャ、macOS 15以上、ビルドにはXcode 26以上とされています。(Homebrew Formulae)

また、公式technical overviewでは、macOS 15でも実行はできるものの、ネットワーク分離、複数ネットワーク、IPアドレスまわりに制約があると説明されています。例えば、macOS 15では container network コマンドが使えず、全コンテナがデフォルトのvmnetネットワークに接続されます。(GitHub)

そもそもMacの上でDockerがどう動くか

Linux上でDockerを使う場合、コンテナは基本的にホストのLinuxカーネル上で動きます。namespaceやcgroupsなどを使ってプロセス、ネットワーク、ファイルシステム、リソースを分離するわけです。

しかし、macOSはLinuxカーネルではありません。そのため、Mac上でLinuxコンテナを動かすにはLinux環境が必要になります。

Docker Desktopもcontainerも、MacでLinuxコンテナを動かす以上、VMは使っています。今回containerは軽量VMを採用しています。

軽量VMとは何か

Appleのドキュメントでは主に「lightweight VM」という表現が使われていますが、これは一般にmicroVM的な発想に近いものです。

普通のVMは、仮想PCや仮想サーバを1台立てる感覚に近いです。OSを入れて、ログインして、デーモンを起動して、長く使うことを想定します。

一方で、軽量VMやmicroVMは、より小さな単位のワークロードを隔離するために、必要なものを絞ったVMです。コンテナのように作って壊すことを想定しつつ、隔離境界としてはVMを使う、というイメージです。

Containerizationは各コンテナを独自の軽量VM内で実行しながら、sub-second start timesを提供すると説明されています。また、各コンテナに専用IPアドレスが割り当てられ、サービスにアクセスする際に個別のポートマッピングを不要にできる利点も説明されています。(Apple Developer)

さらに、VM内では vminitd というSwift製の小さなinit systemが最初のプロセスとして動きます。vminitd はネットワークインターフェースの設定、ファイルシステムのマウント、プロセスの起動・監督などを担当します。Appleは、攻撃面を減らすために、この最小ファイルシステムにはcore utilities、dynamic libraries、libc implementationを含めない設計だと説明しています。(Apple Developer)

このあたりはかなりAppleらしい設計です。

コンテナの手軽さを残しつつ、VMの隔離性を持ち込む。そのために、VMをできるだけ小さくし、起動も速くする。containerのコアはここにあると思います。

`container`の今後の可能性

Docker Desktop代替

単発コンテナの実行、OCIイメージのビルド、レジストリ操作、簡易的なサンドボックス用途では、かなり現実的な選択肢になりそうです。container run や container build はすでに用意されており、Dockerユーザーにも理解しやすいCLIになっています。(GitHub)

Mac版WSL的なLinux開発環境

container machine は、MacのホームディレクトリをLinux環境にマウントし、Macのエディタで編集しつつLinux側でビルド・実行できます。systemd入りのイメージであれば、データベースなどのサービスも起動できます。これは、従来の「単発コンテナ」よりも、開発用Linuxマシンに近い体験です。(GitHub)

ローカルサンドボックス基盤

Apple containerはコンテナごとに軽量VM境界を置くため、信用しきれないコードを試す、実験環境を分ける、CIに近いローカル環境を作る、AI Agentを動かすといった用途と相性がよさそうです。Apple自身も、Containerizationの設計目標としてセキュリティ、プライバシー、パフォーマンスを挙げています。(Apple Developer)

一方で、課題もあります。

特に、Docker Compose、Docker API互換、Kubernetes、既存のDocker Desktop依存ワークフローまで含めると、まだDocker Desktopのほうが実用的な場面は多いと思います。Docker DesktopはDocker Engine、Docker CLI、Docker Build、Docker Compose、Kubernetesを含む統合環境として提供されているため、チーム開発でそのまま置き換えるには差分が大きいです。(Docker Documentation)

まとめ

Docker Desktopを今日から完全に置き換えるという感じではなさそうですが、Mac上のLinuxコンテナ実行にApple公式の新しい選択肢containerがv1.0.0を迎えました。

Docker DesktopもApple containerも、Mac上でLinuxコンテナを動かすためにVMを使います。違いは、Docker Desktopが共有Linux VM上で複数コンテナを動かすのに対し、Apple containerはコンテナごとに軽量VMを起動する点です。(GitHub)

正直Compose中心のマルチコンテナ開発でどれだけローカルマシンのパワーを必要とするかは試してみないとわかりません。一方で、単発コンテナ、サンドボックス、Mac上の永続Linux開発環境、Apple siliconに最適化されたコンテナ実行基盤としては既存のDocker Desktopより隔離性が高く安全です。

特に container machine は、Mac上にLinux開発環境を自然に作る機能として期待できます。Macでコードを書き、Linuxでビルド・実行する。必要ならsystemdサービスも動かす。この体験がApple公式ツールとして整っていくなら、Docker Desktopとは別の方向でかなり便利になりそうです。

この記事は Zenn にも転載しています。