世界を動かす技術を、日本語で。

macOSコンテナマシン

概要

  • Container machine はMac上でシームレスに動作する 統合Linux環境 を提供
  • 高速・軽量・永続的 な特性を持ち、標準OCIイメージに基づく
  • ユーザー名・ホームディレクトリ自動共有 により、どこからでも簡単アクセス
  • macOSのエディタやツール と連携し、編集とビルドを分離可能
  • 複数ディストリビューション のテスト環境を迅速に構築

Container machineの特徴

  • Mac上で 本物のLinux環境 を提供
    • /sbin/init によるinit system起動、サービス登録やプロセス監督可能
  • 標準OCIイメージを利用
    • alpine, ubuntu, debian など様々なディストリビューションに対応
  • ユーザー名・ホームディレクトリ を自動マッピング
    • Macの $HOME/Users/<username> としてLinux環境にマウント
  • リポジトリ・dotfiles の共有
    • macOSとLinux環境の両方で同じ設定・資産を利用
  • macOSのエディタ・IDE とLinuxビルド環境の共存
    • 編集はMac、ビルド・実行はLinuxで分業
  • macOSネイティブツール との連携
    • プロファイラ・スクリーンショット・GUIデバッガなどが同じファイルを参照
  • Linuxサービスのテスト
    • 例:systemctl start postgresqlで本番同様のサービス起動

使い方・コマンド例

  • コンテナマシンの作成・起動
    • container machine create alpine:latest --name dev
    • container machine run -n dev whoami(ユーザー名確認)
    • container machine run -n dev pwd(ホームディレクトリ確認)
    • container machine run -n dev(対話型シェル起動)
  • コマンド実行・デフォルト設定
    • container machine run -n dev uname -a(コマンド一回実行)
    • container machine set-default dev(デフォルト指定)
    • container machine run(-n省略可能に)
  • 管理コマンド
    • container machine ls(一覧表示)
    • container machine inspect dev(詳細情報表示)
    • container machine stop dev(停止)
    • container machine rm dev(削除・ストレージ含む)
    • エイリアス:m ls, m runなども利用可能

設定変更・カスタマイズ

  • CPU・メモリ・ホームマウントの変更
    • container machine set -n dev cpus=4 memory=8G
    • container machine stop dev
    • container machine run -n dev -- nproc(反映確認)
    • メモリはデフォルトでホストの半分
    • ホームマウントはrw(デフォルト)、ro、noneから選択

独自イメージの利用

  • 任意のLinuxイメージ (/sbin/init必須)をコンテナマシンに利用可能
    • 例:Ubuntu 24.04 + systemd + 基本ツールのDockerfile
  • イメージのビルド・作成手順
    • container build -t local/ubuntu-machine:latest .
    • container machine create local/ubuntu-machine:latest --name ubuntu
  • 初回起動時のユーザー作成カスタマイズ
    • /etc/machine/create-user.sh(実行可能スクリプト)を用意
    • 初回起動時、root権限で一度だけ実行
    • 環境変数:CONTAINER_GID, CONTAINER_HOME, CONTAINER_MACHINE_ID, CONTAINER_UID, CONTAINER_USER

Container machine活用のメリット

  • 本番に近いLinux環境 での開発・テスト
  • 複数ディストリビューション 間の迅速な切替・検証
  • macOSとLinuxの資産・ツールのシームレスな統合
  • 開発効率の大幅向上 とテスト環境の柔軟性

Hackerたちの意見

OrbStackは私にはすごく合ってる。パフォーマンス的にはどうなんだろうね。

(OrbStackの開発者です。)Virtualization.frameworkの代わりに、私たちはファイルシステム共有などのためのカスタムデバイスとプロトコルを持つカスタムRust仮想化スタックを使ってるんだ。これは私たちのLinuxマシンとコンテナを実行するために特化した、高度に最適化された垂直統合スタックなんだ。私たちの最大のパフォーマンス/リソースの向上は動的メモリで、未使用のメモリをmacOSに返すことでメモリ使用量を大幅に減らしてる。他のものはこれをサポートしてないし、Containerizationもそう。Container Machinesを試してみたけど、デフォルトのバインドマウントでOCIコンテナにかなり近い感じだった。統合が少なくて、systemdや他の通常のinitシステムを動かせないから、サービスを実行するのが難しいんだよね。

OrbStackがすごく好きなんだけど、今のところContainer Machinesを使う理由がよくわからないな…。

https://tart.run/との比較も見てみたいな。私の見た感じでは、かなり似てると思う。

完全なDocker環境ではないけど、ビルドをするためにこれを目指してるんだ。ただ、オプションとしてdockerdを実行することもできるよ。 https://github.com/cpuguy83/crucible は、コンテナ化フレームワークを使ってbuild kitdかdockerdを実行し、それをdocker/buildx CLI(または使いたいクライアントツール)に接続するんだ。コンテナ化フレームワークは、仮想化フレームワークの上にレイヤーとして存在するライブラリなんだ。だから、各コンテナはそれぞれ独自のVMになる。マシンは、コンテナ化フレームワークの上で複数のものをVM内のコンテナで実行するためのツールだよ。

ここでいくつかコメントを明確にしておくと、これはOCIコンテナだけじゃないんだ。コンテナマシンは永続性やファイルシステムのマウントをサポートしていて、macOSを使ってる開発者にとっては軽量なLinux環境としてすごく便利なんだよ。詳しくはここを見てね: https://developer.apple.com/videos/play/wwdc2026/389

ああ、Darwin/BSDのLinuxサブシステムね。

これらのコンテナは共通のカーネルを共有してるの?それともそれぞれ別のVMで動いてるの?編集: コンテナごとにVMがあるよ。 https://github.com/apple/container/blob/main/docs/technical-...

これって新しいの?前からあったと思ってたけど。私のテストでは(確か)ファイルシステムのパフォーマンスが、たくさんの小さなファイルを扱うnode/rust開発には使えないくらい良くなかった。更新: 新しいのはcontainer machineサブコマンドだね。試してみようと思ったけど、コンテナが全く動かなかった: https://github.com/apple/container/issues/1681

OrbStack試したことある?やることはまだまだあるけど(テストワークロード大歓迎!)、小さいファイルや一般的な開発者のワークロードに最適化するために、OrbStackのカスタマイズされたファイルシステム共有プロトコルにかなりの努力を注いだよ(標準のvirtiofsじゃない)。

PodmanはmacOSでも使えるよ。既存のコンテナフレームワークを使ってマシンを動かしてる。ルート権限ありでもなしでも。

CodespacesやCoder、Gitlabみたいなサービスが、ホスティングされた/統合されたプラットフォームで実行することを許可したり、その同じコンテナを完全にローカルで立ち上げられたらいいのにね。時々、リモートの開発環境をオフラインにしたいけど、統合されたUXの恩恵を受けたいんだよね。

その操作をTerraformで表現できるなら、Coderはそれをやらせてくれるよ。最初に思いつく問題は、Coderのプロビジョナーからローカルマシンへの接続(Tailscale?ローカル?)と、実際にワークスペースを環境間で切り替えたい場合のディスクイメージの移行かな(ローカルプロビジョナーがこれをやることはできるけど、どちらにしても遅くてイマイチになるだろうね)。

これ、存在するよ。devcontainersって呼ばれてて、ローカルで管理するためのCLIもあるんだ。 https://github.com/devcontainers/ https://containers.dev/

もしかして理解できてないかもしれないけど、なんでGitLabのセルフホストのセットアップはうまくいかないの?

これをやるために気を使ってくれたことに驚いてるよ。やっぱりLinuxの方がいいけど、MacBookの価値はすごいね。

俺はいつもLinuxを使いたいけど、時々会社からMacBookをもらうこともあるんだ。だから、このツールを使うかもしれない。

AppleがLinuxコンテナを自慢してるのを見るたびに、敗北を認めてる以外の何物でもないと思っちゃう。まだDarwinのままだったら、簡単にできたのにね。

30年のインターネットの歴史を変えるってこと?

代わりは何? 彼らは10年前にサーバー市場を諦めて、それ以前もほとんどサポートしてなかったし。もしダーヴィンコンテナをサポートしたとして、何の意味があるの? 誰もそれに向けて開発しないし、Linuxが勝ったんだから。

Appleは、macOSをプロプライエタリコードにすることを決めた時点で、サーバーや開発者市場での敗北を自ら招いたんだよね。真剣な開発者がデバッグも修正もできないクローズドソースのコードを使う理由って何?真剣な開発者やハッカーがmacOSを使わないのもそのためだし、開発者の醍醐味って、どのレイヤーでもコードを掘り下げてデバッグしたり修正したりできることだからね。

macOSがWSL1スタイルのアプローチを試さない理由って何かあるの? Windowsでうまくいかなかったのは理解できるけど、macOSも別の*unixだから、Windowsで難しかったことがMacでは簡単にできる気がするんだよね。少しの新しいAPIを追加するだけで、ほとんどのLinuxアプリをネイティブで動かせるはずだし。実際、BSDはもうそれを実現してるし。

Appleが必要としているVMインフラに対して、Linuxカーネルよりもずっとシンプルで安定した「ABI」を持っているのに、何の利点があるの?

コンテナのボリュームを外付けドライブに変更することってできるのかな? 今はQEMUとqcow2イメージを使ってそれを実現してるけど、まあまあうまくいってるよ。

家にはWSLがあるよ。