Transcript
00:00:00今年のWWDCで発表されたApple Intelligenceの影で、
00:00:03Appleはひっそりと、Windows Subsystem for LinuxのApple版とも言える
00:00:06「Container Machines」をリリースしました。これはMac上で軽量かつ永続的な
00:00:10Linux環境を非常に簡単に利用できるもので、
00:00:14昨年公開されたDockerの代替プロジェクト「Apple Containers」をベースにしており、
00:00:18もちろんAppleシリコンに最適化されています。では、Container Machinesとは何か、
00:00:21どのように動作するのか、そして見逃した人のためにApple Containersの復習もしていきましょう。
00:00:29まずはContainer Machineのセットアップから始め、その仕組みについて少し解説します。
00:00:32私が使いたいのはUbuntu Linux環境です。単純にUbuntuイメージを使った
00:00:37Dockerファイルを用意し、その中に一般的なツールをインストールするための記述をいくつか加えました。
00:00:41これはOCI互換のあらゆるイメージで動作するため、Dockerで使えるイメージのほとんどが利用可能です。
00:00:46VMとして機能するために必要なのは、システム初期化プログラムを含めることだけです。
00:00:50VMに使いたいDockerファイルができたら、あとはAppleのコンテナツールを使って
00:00:54ビルドするだけです。ご覧の通り、これが私が使っているコマンドです。
00:00:58このフォルダーにDockerファイルがあるので、単純に「local-ubuntu-machine」
00:01:01というタグを付けてビルドを実行します。ちなみにこのコンテナツールは、
00:01:05macOS 26以降で動作します。GitHubのリポジトリにアクセスして、
00:01:09リリースから最新のパッケージをダウンロードすれば簡単にインストールできます。イメージのビルドが終わったようですが、
00:01:13Dockerと非常に似ていますね。OCIイメージをビルドしているだけです。
00:01:17これでContainer Machineに必要なものは全て揃いました。「container machine create」を実行し、
00:01:21Container Machineに使いたいイメージと、任意のフレンドリー名を指定します。
00:01:24また、これをデフォルトとして設定しておけば、以後コマンドを実行する際に
00:01:27名前を指定する必要がなくなり、このマシンが自動的に対象となります。これでエンターキーを押すと、
00:01:31文字通り数秒でセットアップが完了します。作成したContainer Machineの情報は
00:01:35「container machine list」で確認できます。先ほど作成したUbuntu環境が、
00:01:38IPアドレス、7つのCPU、18GBのメモリと共に表示されています。CPUとメモリは設定で変更可能ですが、
00:01:44デフォルトではMacのメモリの半分を使用します。実際にContainer Machineを使い始めるには、
00:01:48「container machine run」を実行するだけです。
00:01:51インタラクティブなターミナルに入りたい場合は空欄のままにするか、
00:01:54Linuxマシン上で実行したいコマンドを直接追加することもできます。ここではそのままエンターキーを押し、
00:01:58Linux環境のインタラクティブ・ターミナルに入りました。確認のために
00:02:02「uname -a」を実行してみると、Macで実行した時の「Darwin」ではなく、
00:02:06「Linux Ubuntu」であることが表示されます。Container Machineの素晴らしい点の一つは、
00:02:10ユーザーが自動的に共有されることです。Macのユーザー情報がLinux環境にコピーされており、
00:02:14ホームディレクトリも同様です。ホームディレクトリ全体が読み書き可能な状態でマウントされるため、
00:02:18このLinux環境からMac上のすべてのファイルにアクセスできます。ご覧の通り、「container run」
00:02:23を実行したフォルダーにそのまま直行しており、すでにファイルが存在しています。
00:02:27一方でこのマシン専用のボリュームもあるため、Ubuntuマシンの
00:02:31ホームディレクトリに移動すると、Mac側にはファイルがあってもこちらには何もないことが分かります。
00:02:35これはここがLinux環境であり、Linux専用のドットファイルを置く場所だからです。
00:02:39フォルダー共有のおかげで、使い慣れたツールを使ってMac上で開発を行い、
00:02:43あるいはmacOS専用ツールを使いながら、Linuxでテストが必要なときに即座に切り替えるといったことが非常に簡単になります。
00:02:48例えば、ここに非常にシンプルなBUNアプリケーションがあります。これを
00:02:52Linuxで動作する単一の実行ファイルにコンパイルしたいのですが、
00:02:56macOS上ではLinuxの動作テストができないため、実行しても成功したかどうかわかりません。しかしContainer Machineに切り替えれば、
00:03:01コマンドを直接実行できます。ファイル転送の手間は一切不要です。
00:03:04ファイルシステムが共有されているおかげです。ここで実行すると、うまく動作しました。
00:03:08このアプリケーションは非常にシンプルなWebサーバーで、
00:03:12現在何の上で動作しているかを表示するページがあります。現在Ubuntu 24で動作していることがわかります。
00:03:16購読ボタンも表示されていますね、ぜひ押してください。さて、Linux環境で
00:03:20BUN開発サーバーを動作させてテストしていましたが、問題なく動作しました。
00:03:23BUN devで実行中で、まだコンパイルはしていません。しかし、Mac側で
00:03:27ソースファイルを修正して、「subscribe」を「hello」に変えてみたのですが、
00:03:31ホットリロードが変更を検知できていないようです。変更を反映させるには
00:03:35BUN開発サーバーを再起動する必要があります。反映されましたね、「hello」になりました。
00:03:39ホットリロードはブレークポイントと同様で、macOS側のコードでは動作しませんが、
00:03:43エディタからSSH経由でContainer Machineに接続してファイルを編集すれば、
00:03:47ブレークポイントやホットリロードも正常に動作するはずです。ドキュメントにそのやり方のチュートリアルがあります。
00:03:52Container Machineの使い方は基本的にこれです。Ubuntu環境そのものですし、
00:03:55全体的な体験は非常にシームレスです。一台のマシンに限定されない点も重要です。
00:03:59Alpine、Ubuntu、Debianを並べて配置し、ターゲットごとにディストリビューションを
00:04:03変えることができ、クロスプラットフォーム作業をするなら非常に便利です。さらに、これらのマシンは
00:04:08SystemDを実際に実行できるため、Postgresをサービスとして動かし、
00:04:12アプリをその横で動かすといったスタックのテストも可能です。デプロイ先のLinuxサーバーと
00:04:17同じように振る舞います。シンプルさはAppleがContainer Machinesを開発する際に
00:04:22追求した核心的な設計原則の一つです。既存のワークフローに統合でき、
00:04:26必要に応じてすぐに起動でき、長期的に永続化して、
00:04:30必要なツールをすべて揃えた開発環境用VMとして使える、高速で軽量なVMを目指していました。
00:04:34WSLが実現しようとしていたことに似ています。ビルドの仕組みや、
00:04:39DockerやOrbStackとの比較について理解するために、まずは昨年リリースされたコンテナツールを見てみましょう。
00:04:42これはSwiftで書かれており、コンテナを実行するためのDocker代替ツールとして作られています。
00:04:47標準的なOCIイメージであれば、Docker Hubから取得したものでも動作します。
00:04:51Appleのアプローチがユニークなのは、Docker Desktopのように複数のコンテナが
00:04:55一つの巨大なLinux VMを共有するのではなく、独自の仮想化フレームワークを通じて、
00:04:59各コンテナに独自の軽量VMが割り当てられる点です。利点としては、セキュリティ面では
00:05:04各コンテナがフルVM相当の分離特性を持つことが挙げられます。プライバシー面でも、
00:05:08各VMに必要なデータだけをマウントするため優れています。共有VMの場合、
00:05:13データはすべて共有VMにマウントされてから、各コンテナに割り振られるからです。
00:05:17最後にパフォーマンス面ですが、Appleのコンテナツールで作られたコンテナは、
00:05:22フルVMよりも少ないメモリで動作し、起動時間もDockerや他のツールとほぼ同等です。
00:05:27RepoFlowがApple ContainersとOrbStack、Docker Desktopを比較したベンチマークによると、
00:05:31結果はそれほど悪くありません。Apple Containersは、
00:05:36シングルスレッドCPU性能で最も高い数値を記録しており、OrbStackもかなり肉薄しています。マルチスレッドでも
00:05:41同様で、どれも非常によく動作します。しかしAppleがわずかにリードしているのはメモリのスループットで、
00:05:46OrbStackが2位、Docker Desktopが最下位でした。小さなコンテナの起動時間については、
00:05:50Appleはまだ改善の余地があるようです。それでも1秒未満ではありますが、
00:05:55Docker DesktopやOrbStackは0.25秒以下で完了します。他にも多くのベンチマークがあるので、
00:06:00リンクを貼っておきます。基本的にOrbStackはファイルシステムと小さなファイルの処理性能が非常に優れており、
00:06:04Apple ContainersはDocker Desktopと同等か、それ以上の性能を見せています。
00:06:09ただし、利用前にいくつか注意すべき点があります。まずメモリについてです。
00:06:14先ほど言ったようにデフォルトでシステムRAMの半分を確保し、
00:06:17しかし、他の結果を見ればOrbStackがファイルシステムや小さなファイルの処理において並外れた性能を示すことは明らかです。
00:06:22また、Appleのコンテナ機能もDocker Desktopと同等、あるいはそれ以上の性能を見せています。
00:06:27ただ、利用する前に知っておくべき注意点がいくつかあります。
00:06:301つ目はメモリです。先ほど触れた通り、デフォルトでシステムRAMの半分を割り当てますが、
00:06:35このメモリは実際には解放されません。そのため、
00:06:39大規模なビルドなどでコンテナがメモリを大量消費すると、マシンを再起動するまでそのメモリは確保されたままになります。
00:06:43ここでOrbStackのユニークな利点が活きてきます。OrbStackには動的メモリ機能があり、
00:06:47未使用のメモリをmacOSに解放することで使用量を削減します。私の知る限り、これを実現しているのは他にありません。
00:06:532つ目は、GPUやUSBのパススルーに対応していないことです。GitHubには
00:06:57これらに関するIssueが上がっているので、将来的にサポートされるかもしれません。
00:07:023つ目は、GUIアプリを動かすのが少し複雑な点です。例えば、
00:07:06Linux版のVS Codeや、Linux専用アプリを動かしたい場合、スムーズとは言えません。他のツールを使ったほうがいいでしょう。
00:07:11最後に、セキュリティ上のトレードオフがあります。前述した通り、
00:07:15便利なホームディレクトリのマウント機能は、デフォルトで読み書き可能になっています。つまり、
00:07:20コンテナ内で動かしているプログラムが、あなたのSSH鍵やクラウドの認証情報など、
00:07:25Mac内のあらゆるデータにアクセスできてしまいます。マウントを読み取り専用にするか、
00:07:29完全にオフにする設定しかないようで、特定のフォルダだけをマウントする機能はないようです。
00:07:33総評として、Appleのコンテナ環境を試した結果、私はおそらくOrbStackを使い続けると思います。
00:07:37リソース管理や機能面で、現状では最も洗練されていると感じるからです。ただ、
00:07:40OrbStackはビジネスや商用利用で有料になるのを好まない方もいるでしょう。
00:07:45Docker Desktopの代わりにApple Containersを選ぶでしょう。また、他にも素晴らしい選択肢としてLimaがあります。
00:07:49素晴らしい選択肢もあります。皆さんは何を使っていますか？OrbStack、Docker Desktop、それともLima？
00:07:53コメントで教えてください。チャンネル登録もぜひ。それではまた。