ハクソク

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

コンテナ化は、macOS上でLinuxコンテナを実行するためのSwiftパッケージです。

350日前原文(github.com)

概要

Containerization はApple silicon向けのLinuxコンテナ管理パッケージ。 Swift製 で、Virtualization.frameworkを活用。 OCIイメージ管理や仮想マシン生成など多機能。 最適化Linuxカーネル で高速起動と軽量動作を実現。 macOS 15以降、Apple silicon必須。

Containerizationパッケージ概要

  • Linuxコンテナ をApple silicon上で動作させるためのSwift製パッケージ
  • Virtualization.framework を利用し、各コンテナを独立した軽量仮想マシンで実行
  • OCIイメージ管理、リモートレジストリ連携、ext4ファイルシステム生成
  • Netlinkソケット ファミリーとの連携機能
  • 最適化Linuxカーネル によるサブセカンド起動
  • 仮想マシン生成・管理機能、ランタイム環境制御
  • Rosetta 2 を活用し、Apple silicon上でx86_64プロセス実行対応

設計と特徴

  • 各Linuxコンテナは 独立した軽量仮想マシン 内で動作
  • 各コンテナに 専用IPアドレス割当 可能、個別ポートフォワーディング不要
  • 最小限のrootファイルシステム と軽量initシステム（vminitd）による高速起動
  • vminitdは gRPC API をvsock経由で提供し、プロセス起動やI/O管理を実現
  • プロセス実行時のI/Oやシグナル、イベント の伝達機能

動作要件

  • Apple silicon搭載Mac 必須
  • ビルド要件
    • macOS 15以降 & Xcode 26 Beta
    • macOS 26 Beta 1以降
  • アプリケーション実行は macOS 15以上
    • macOS 15では非分離型ネットワーク不可 （同一vmnet内のコンテナ間通信不可）

使い方例・ツール

  • cctlコマンド によるAPI機能の試用
    • OCIイメージ操作
    • コンテナレジストリへのログイン
    • ルートファイルシステムブロック生成
    • シンプルなLinuxコンテナ実行

Linuxカーネルについて

  • 仮想マシン起動にはLinuxカーネル必須
  • kernelディレクトリ に最適化カーネル設定とビルド環境を同梱
  • 最小限の機能セット で高速・軽量動作を実現
  • API経由でカーネル構成やバージョンを個別指定可能
    • ワークロードごとに異なるカーネルバージョン検証に対応
  • Kata Containers プロジェクトが推奨する最適化済みカーネル（vmlinux.container）も利用可能

ビルド・セットアップ手順

  • Swiftly, Swift, Static Linux SDK のインストール
    • make cross-prepコマンド実行
    • .swiftly/env.shの反映確認
    • which swiftでパス確認
    • 古いSDKの削除（必要に応じて）
  • ビルド: make all
  • テスト: make test integration
    • カーネル未所持の場合はmake fetch-default-kernelで取得
    • make all test integrationで一括実行

Protobuf・ドキュメント生成

  • grpc-swift・swift-protobufのバージョン依存
  • make protosでRPCインターフェース再生成
  • make docs, make serve-docsでAPIドキュメント生成・プレビュー
    • open http://localhost:8000/documentation/ で閲覧

コントリビューション・プロジェクト状況

  • 貢献歓迎、詳細はCONTRIBUTING.md参照
  • バージョン0.1.0 が初の公式リリース
  • ソース安定性保証はマイナーバージョン間のみ
    • 例：0.1.1と0.1.2間
  • .upToNextMinorVersion(from: "0.1.0") 指定で破壊的変更回避
  • 今後のマイナーバージョンでルール変更の可能性あり

Hackerたちの意見

何が起きてるのかよくわからないけど、すごく遅い気がする。ビルドに時間がかかりすぎてる。-c と -m でCPUとメモリを増やしてビルダーを動かしてみたけど。

└

どのセットアップと比べてるの？昔のシリコンMacと、例えばRancher Desktopを使ってた時は、x86イメージを作るふりをしてくれてたけど、実際のx86ハードウェアではほとんど動かなかったんだよね。

Dockerはこれについてどう思ってるんだろう。MacにDocker for Desktopが結構入ってると思うけど…。

└

これでDocker Desktopの開発がめっちゃ楽になるよね。自分たちでLinux VMを立ち上げる必要がなくなるから。ソフトウェアが「粘着性」があるから、みんなDocker Desktopの使い慣れたCLIやUX、Docker Compose、他のコンテナランタイムに移行するのがほぼ不可能なDocker特有の quirks を好むと思う。

└

おそらくpodmanに対しても同じような感じだろうね。

└

Docker Desktopはクローズドソースのプロプライエタリソフトウェアだけど、これはフリーソフトウェアだから、こっちの勝ちだね（少なくとも私たちにとっては）。

かっこいいね！短いデモの中で「数百ミリ秒以内」とVMの起動時間について言ってたけど（そうだよね？）。どれだけ調整が必要だったのか気になるな。Virtualization.frameworkを使ってるみたいだけど、これって前からあってDocker DesktopやColima、UTMでも使われてるオプションだし。特に複数のコンテナを動かすときのメモリオーバーヘッドが気になるな。複数のVMを立ち上げることになるから。[0]: https://developer.apple.com/videos/play/wwdc2025/346 10:10以降

└

ここにカーネルの設定が含まれてるよ。

コンテナは最適化されたLinuxカーネルの設定と、軽量なinitシステムを持つ最小限のルートファイルシステムを使って、サブ秒の起動時間を実現してるんだ。

私の意見では、これはAppleのクラウドホスティングへの一歩だと思う。Xcode Cloudもあるし、Amazonとの40億ドルの契約が終わるし、すごく利益が出てる。コンテナを作って、Appleにデプロイする、もしかしたら彼らのCPUにもアクセスできるかも。

└

AppleがmacOS向けにコンテナサポートを発表したからって、「AWSと競争するつもりだ」ってのはちょっと飛躍しすぎじゃない？ 特にApple自身のサーバーワークロードやデータストレージはほとんどGCPにあるし。

プレスリリースやWWDCセッションのCLIはここにあるよ。 https://github.com/apple/container これ、私みたいな人には興味深いと思う。最新のXcode Betaにこれが含まれることを期待してたけど、どうやらそうじゃないみたい。今はプリビルドパッケージがないけど、作業中らしいよ。 https://github.com/apple/container/issues/54

└

君のコメントのちょうど1分後にプリビルドパッケージがリリースされたみたいだよ。 https://github.com/apple/container/releases/tag/0.1.0

└

ここで議論されてるよ: https://news.ycombinator.com/item?id=44229239

これについての動画はここにあるよ。 https://developer.apple.com/videos/play/wwdc2025/346/ 各コンテナがそれぞれ軽量なLinux VMを持つみたい。ここからコンテナツールをダウンロードして試してみてね。 https://github.com/apple/container/releases （macOS 26が必要）

└

macOS 15でも動くけど、いくつかのネットワーキング機能は制限されるって言ってたよ。

└

提出物は https://github.com/apple/containerization のことだよ。 https://github.com/apple/container の方じゃない。前者はコンテナサイドカーと一緒にアプリを出荷するためのもので（個人的にはこっちの方が面白いニュースだね）、後者は「私は開発者で、docker run ...をしたい」って感じ。あ、コンテナに関してはここに提出物があるよ: https://news.ycombinator.com/item?id=44229239

これについてもう少し調べる必要があるけど、LinuxコンテナをmacOSアプリにバンドルするのに使えるか誰か教えてくれない？ いくつかの場面で役立ちそうな気がする。例えば、GPTにLinux環境へのアクセスを与えて、root CLIコマンドを実行する権限を与えないとか。

└

そうだね、もしアプリがmacOS 26でしか動かないのが大丈夫なら。そうじゃなければ、Virtualization.frameworkを直接使えば、やりたいことはもう実現できるけど、ちょっと手間がかかるよ。

└

そう、それがまさにその目的だよ。

これで他の2つの大手デスクトップOSも、Linuxネイティブアプリをホストするための公式なLinux VMを実行するメカニズムを持つことになったね。これをもってLinuxが勝ったって言えるかもしれない。確かに、LinuxのシステムコールAPIは今や最も普及しているアプリケーションAPIかもしれないね。

└

「macOSでのLinux。」

└

ゲームをプレイしているのが自分だけなら、それは勝ちなの？ 普通のWindowsやMacユーザーに自慢しても、「え？」とか「Linuxって何？」って言われるだけだよ。

└

Linuxは勝った。 一般の人がLinuxシステム用にプログラムをまともに開発するために、最も有名な非Linuxオペレーティングシステムが2つ必要だと考えると、それは特に勝利とは言えないよね。何年経ってもLinuxデスクトップのひどい状態を浮き彫りにしてるだけだし。普通の人にとっては、どの面でもまだまだひどいし、問題が頻発するから、今でも勧めるのが難しいよ。毎年、比較的新しいPCやノートパソコンに最新のFedora/Ubuntu（初心者向けのおすすめって言われてるやつ）をインストールしてるけど、一度も「お、これ結構使えるし安定してるな」って思ったことはないよ。

└

まあ、他の2つのプラットフォームが、そこから離れずにLinuxを使える方法を見つけているとも言えるね。それがデスクトップでのLinuxの市場シェアを遅らせているんだ。

└

グラフィックス、オーディオ、GUIに関しては、良い解決策が存在しないね。

これについてもう少し考えてみると、採用に関してすぐに気になるのは、各コンテナを独自のVMで立ち上げて完全に隔離し、それぞれにIPを与えるというアイデアが、LinuxやWindowsにはあまり合わないってことだね。つまり、開発者チームの中に一人でもMacを持っていない人がいると、ローカルの開発環境がすでに崩れちゃう。だから、DockerやComposeを簡単に置き換える方法が見えないな。

これは単にwslと比較するためのチェックボックス機能だと思う。そうじゃなきゃ、Appleが関わることはなかったはず（エンジニアじゃなくて、こういうことを許可した経営陣がね）。