ハクソク

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

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

2025年6月10日原文(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

Hacker Newsで議論の続きを見る