Apple のオープンソース Swift ツール「Container」：Apple Silicon で軽量 VM として Linux コンテナを実行
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
MarkTechPost
Apple 研究チームが、Swift で記述されたコマンドラインツール「Container」を公開した。このツールは Apple Silicon 搭載 Mac 上で、常時稼働する Linux VM を不要とし、Linux コンテナを軽量な仮想マシンとして実行・管理可能にする。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るSource Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Apple の研究チームは最近、container プロジェクトをリリースしました。これは Swift で書かれたオープンソースのコマンドラインツールであり、Mac 上で軽量な仮想マシンとして Linux コンテナを作成して実行するものです。このプロジェクトは Apache 2.0 ライセンスの下で提供され、Apple シリコンを対象としています。
コンテナとは、ラップトップからデータセンターまで再現可能な環境を配送する方法です。Apple は現在、常に稼働している単一の Linux 仮想マシンを回避するネイティブなパスを提供しています。
Apple の container とは何か？
container は、イメージの構築、コンテナの実行、およびレジストリへのイメージの転送に使用できる CLI ツールです。OCI（Open Container Initiative）互換のコンテナイメージを読み込み、生成します。そのため、Docker Hub や GitHub Container Registry からイメージをプルして実行することもできます。また、自分で構築したイメージを任意の標準レジストリへプッシュすることも可能です。
container はオープンソースの「Containerization Swift」パッケージを利用しています。このパッケージは、コンテナ、イメージ、プロセス管理の低レベル処理を担当します。このツールには Apple シリコンを搭載した Mac が必要であり、Intel 搭載の Mac はサポートされていません。Apple は container を macOS 26 でサポートしており、そこでは仮想化およびネットワーク機能の強化が追加されています。macOS 15 でも実行可能ですが、ネットワーク機能に制限があります。
container はどのようにコンテナを実行するのか？
多くの macOS コンテナツールは、すべてのコンテナをホストする共有された Linux 仮想マシンを 1 つ実行します。Apple はこれとは異なるアプローチを採用しています。container は、作成した各コンテナに対して個別の軽量な仮想マシンを実行します。Apple はこの設計について以下の 3 つの特徴を挙げています：
セキュリティ：各コンテナは完全な仮想マシン（VM）と同様の分離性を備えています。コアユーティリティと動的ライブラリの最小限のセットにより、リソース使用量と攻撃対象領域が削減されます。
プライバシー：すべてのデータを共有するのではなく、各 VM が必要とするデータのみをマウントします。
パフォーマンス：これらのコンテナは完全な仮想マシンよりも少ないメモリを使用します。起動時間は共有 VM 内のコンテナと比較可能なレベルです。
ランタイムは複数の macOS フレームワークと統合されています。仮想マシンには Virtualization フレームワークを、ネットワークには vmnet フレームワークを使用します。プロセス間通信には XPC を、サービス管理には launchd を、レジストリ認証情報には Keychain サービスを利用しています。
コントロールプレーンにはいくつかの構成要素があります。container system start はランチエージェントである container-apiserver を起動します。その後、apiserver はイメージ管理とローカルコンテンツストアのための XPC ヘルパーである container-core-images と、仮想ネットワーク用の container-network-vmnet を起動します。各コンテナに対しては、コンテナごとの管理ヘルパーである container-runtime-linux が起動されます。
インタラクティブ解説
使用例と具体例
ローカルバックエンド開発。サービスを独自の分離された仮想マシンで実行し、ポートをループバックアドレスに転送します。
コードをコピーしました別のブラウザを使用
container run -d --rm -p 127.0.0.1:8080:8000 \
node:latest npx http-server -a :: -p 8000
curl http://127.0.0.1:8080
再現可能な CI スタイルのビルド。container build は BuildKit を使用するビルダーユーティリティコンテナを開始します。重いビルドには、ビルダー VM のサイズを調整できます。
Copy CodeCopiedUse a different Browser
container builder start --cpus 8 --memory 32g
container build --tag web-test:latest --file Dockerfile
データセンター展開用のクロスアーキテクチャイメージ。Apple Silicon と x86-64 サーバーの両方で動作する 1 つのイメージを構築できます。amd64 バリアントは Rosetta 翻訳の下で実行されます。
Copy CodeCopiedUse a different Browser
container build --arch arm64 --arch amd64 \
--tag registry.example.com/fido/web-test:latest
分析用のデータセットのマウント。--volume オプションを使用して、ホストのフォルダをコンテナに共有します。これは、ローカルのデータをコンテナ化されたジョブに供給する際に役立ちます。
Copy CodeCopiedUse a different Browser
container run --volume ${HOME}/Desktop/assets:/content/assets \
docker.io/python:alpine ls -l /content/assets
信頼できないコードや生成されたコードの隔離。各コンテナは共有カーネルではなく、独自の VM で実行されます。この境界線は、エージェントからのコードや不明なイメージから実行する際に、ホストへの露出を減らすのに適しています。
Hands-On: Core Commands
デフォルトのコンテナリソースは 1 GiB の RAM と 4 CPU です。これらは実行ごとにオーバーライドできます。
Copy CodeCopiedUse a different Browser
container run --rm --cpus 8 --memory 32g big
プロセス用の top コマンドと同様に、ライブのリソース使用状況を確認します。
Copy CodeCopiedUse a different Browser
container stats --no-stream my-web-server
デバッグ時に起動ログと初期化ログを仮想マシンから読み取るには、以下のコマンドを使用します。
Copy CodeCopiedUse a different Browser
container logs --boot my-web-server
macOS 26 では、隔離されたネットワークを作成できます。異なるネットワーク上のコンテナ同士は互いに到達できません。
Copy CodeCopiedUse a different Browser
container network create foo --subnet 192.168.100.0/24
container run -d --name web --network foo --rm web-test
デフォルトでは、コンテナは制限された Linux の機能（capabilities）セットで起動します。これらは明示的に調整する必要があります。
Copy CodeCopiedUse a different Browser
container run --cap-drop ALL --cap-add SETUID --cap-add SETGID alpine id
バージョン 1.0.0 では、コンテナマシンも追加されました。これは OCI イメージ（Open Container Initiative image）から構築された永続的な Linux 環境です。ホームディレクトリがマウントされ、ログインユーザーは Mac アカウントと一致します。ファイルシステムは停止および再起動後も維持されます。/sbin/init を含む任意のイメージはコンテナマシンとして認定されます。
1.0.0 の他の 2 つの変更点はアップグレーダーに影響します。システム設定は ~/.config/container/config.toml にある TOML ファイルへ移動しました。container システムプロパティの get および set サブコマンドは削除されました。また、ツールには list および inspect コマンド用の構造化された JSON、YAML、TOML 出力が追加され、自動化が容易になりました。
Apple container vs Docker Desktop
プロパティ Apple container Docker Desktop
隔離モデル コンテナごとに 1 つの軽量仮想マシン 共有 Linux 仮想マシン、共有カーネル
アイドル時のフットプリント 何も実行していない場合はほぼゼロ 常時バックグラウンドで動作する仮想マシン
イメージ形式 OCI 互換 OCI 互換
ビルドエンジン
BuildKit via builder VM BuildKit
ライセンス
Apache 2.0（大規模組織向けに商用利用条件あり）
ハードウェア
Apple シリコンのみ
Apple シリコンおよび Intel
Compose / GUI
組み込みなし
あり
最適な用途
単一コンテナの実行、ネイティブな分離
Compose ワークフロー、成熟したエコシステム
強みと制限
強み：コンテナごとの VM 分離により、共有カーネルと比較して攻撃対象領域が削減されます。停止中のコンテナはメモリ使用量を解放するため、アイドル時のメモリコストも低く抑えられます。OCI 互換性があるため、変換なしで他の環境でもイメージを実行できます。Apache 2.0 ライセンスには機能制限の壁がありません。
制限：macOS の Virtualization フレームワークは部分的なメモリーブローティングのみをサポートしています。コンテナ内で解放されたページが必ずしもホストに返却されるとは限りません。負荷の高いワークロードでは、メモリ使用量を削減するために定期的な再起動が必要になる場合があります。Docker Compose は組み込みで提供されていません。macOS 15 ユーザーはネットワーク制限に直面し、Intel Mac はサポート対象外です。
原文を表示
Apple research team recently released the container project. It is an open-source command-line tool written in Swift. It creates and runs Linux containers as lightweight virtual machines on a Mac. The project ships under the Apache 2.0 license and targets Apple silicon.
Containers are how you ship reproducible environments from a laptop to a datacenter. Apple now offers a native path that avoids a single always-on Linux VM.
What is Apple’s container ?
container is a CLI tool that can be used to build images, run containers, and move images to and from registries. It consumes and produces OCI-compatible container images. So you can pull from Docker Hub or GitHub Container Registry and run those images. You can also push images you build to any standard registry.
container uses the open-source Containerization Swift package. That package handles low-level container, image, and process management. The tool requires a Mac with Apple silicon. Intel Macs are not supported. Apple supports container on macOS 26, which adds virtualization and networking enhancements. You can run it on macOS 15, but with networking limitations.
How container Runs Your Containers
Most macOS container tools run one shared Linux VM that hosts every container. Apple takes a different path. container runs a separate lightweight VM for each container you create. Apple describes three properties of this design:
Security: Each container has the isolation of a full VM. A minimal set of core utilities and dynamic libraries reduces resource use and attack surface.
Privacy: You mount only the data each VM needs, instead of sharing everything.
Performance: These containers use less memory than full VMs. Boot times are comparable to containers in a shared VM.
The runtime integrates several macOS frameworks. It uses the Virtualization framework for the VMs, and the vmnet framework for networking. It uses XPC for interprocess communication, launchd for service management, and Keychain services for registry credentials.
The control plane has a few moving parts. container system start launches container-apiserver, a launch agent. The apiserver then starts an XPC helper container-core-images for image management and the local content store. It also starts container-network-vmnet for the virtual network. For each container, it launches container-runtime-linux, the per-container management helper.
Interactive Explainer
Use Cases With Examples
Local backend development. Run a service in its own isolated VM, then forward a port to your loopback address.
Copy CodeCopiedUse a different Browser
container run -d --rm -p 127.0.0.1:8080:8000 \
node:latest npx http-server -a :: -p 8000
curl http://127.0.0.1:8080
Reproducible CI-style builds. container build starts a builder utility container that uses BuildKit. You can size the builder VM for heavy builds.
Copy CodeCopiedUse a different Browser
container builder start --cpus 8 --memory 32g
container build --tag web-test:latest --file Dockerfile
Cross-architecture images for datacenter deployment. Build one image for both Apple silicon and x86-64 servers. The amd64 variant runs under Rosetta translation.
Copy CodeCopiedUse a different Browser
container build --arch arm64 --arch amd64 \
--tag registry.example.com/fido/web-test:latest
Mounting datasets for analysis. Share a host folder into the container with --volume. This is useful for feeding local data into a containerized job.
Copy CodeCopiedUse a different Browser
container run --volume ${HOME}/Desktop/assets:/content/assets \
docker.io/python:alpine ls -l /content/assets
Isolating untrusted or generated code. Each container runs in its own VM, not a shared kernel. That boundary suits running code from an agent or an unknown image with less host exposure.
Hands-On: Core Commands
Default container resources are 1 GiB of RAM and 4 CPUs. You override them per run.
Copy CodeCopiedUse a different Browser
container run --rm --cpus 8 --memory 32g big
Inspect live resource usage, similar to top for processes.
Copy CodeCopiedUse a different Browser
container stats --no-stream my-web-server
Read virtual machine boot and init logs when debugging startup.
Copy CodeCopiedUse a different Browser
container logs --boot my-web-server
On macOS 26, you can create isolated networks. Containers on different networks cannot reach each other.
Copy CodeCopiedUse a different Browser
container network create foo --subnet 192.168.100.0/24
container run -d --name web --network foo --rm web-test
By default, containers start with a restricted set of Linux capabilities. You tune them explicitly.
Copy CodeCopiedUse a different Browser
container run --cap-drop ALL --cap-add SETUID --cap-add SETGID alpine id
Version 1.0.0 also adds container machines. These are persistent Linux environments built from OCI images. Your home directory is mounted in, and the login user matches your Mac account. The filesystem survives stop and start. Any image containing /sbin/init qualifies as a container machine.
Two other 1.0.0 changes affect upgraders. System settings moved to a TOML file at ~/.config/container/config.toml. The container system property get and set subcommands were removed. The tool also added structured JSON, YAML, and TOML output for list and inspect, easing automation.
Apple container vs Docker Desktop
PropertyApple containerDocker Desktop
Isolation modelOne lightweight VM per containerShared Linux VM, shared kernel
Idle footprintNear-zero when nothing runsAlways-on background VM
Image formatOCI-compatibleOCI-compatible
Build engineBuildKit via builder VMBuildKit
LicenseApache 2.0Commercial terms for larger orgs
HardwareApple silicon onlyApple silicon and Intel
Compose / GUINot built inYes
Best fitSingle-container runs, native isolationCompose workflows, mature ecosystem
Strengths and Limitations
Strengths: Per-container VM isolation reduces shared attack surface versus a shared kernel. Idle memory cost is low, since stopped containers free their footprint. OCI compatibility means your images run elsewhere without conversion. The Apache 2.0 license carries no feature paywall.
Limitations: The macOS Virtualization framework supports only partial memory ballooning. Pages freed inside a container are not always relinquished to the host. Heavy workloads may need occasional restarts to reduce memory use. There is no built-in Docker Compose. macOS 15 users face networking restrictions, and Intel Macs are unsupported.
Check out the Repo here. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us
The post Meet container: Apple’s Open-Source Swift Tool for Running Linux Containers as Lightweight VMs on Apple Silicon appeared first on MarkTechPost.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み