Apple Container Machineによる環境構築
先日(2026.6.9)、Apple Containerのv1.0.0がリリースされていた。
apple container は現在でも macOS 上で開発/テスト用にDBサーバーを複数動作させたりするのに重宝している。
今までは、バージョンアップの度にCLIの仕様が変わったりしていたので、 これで正式リリースになってCLIの仕様も固定されるだけなのかと思ったら container machine という機能がリリースされていた。
少し使ってみたが開発環境の構築にはなかなか良さそうだったので、ここに感想をまとめておく。
コンテナと何がちがうのか？
新しくリリースされた container machine が既存のコンテナ機能と何が違うのか最初見たときわかりづらかった。
公式のチュートリアルによると以下のように説明されている。
Containers are typically modeled after an application. A container machine is modeled after a Linux environment.
通常のコンテナがアプリケーションを単位とするのに対し、コンテナマシンはLinux環境全体を模している。
container は雑に言えば Docker とある程度互換性がある Apple 版コンテナ。
コマンドが違ったりファイルに直接ボリュームマウントできなかったりと細かい違いはあるが、Dockerfile やコンテナイメージは Docker と同じものを使うことができる。
Docker/Apple コンテナの場合は、1コンテナ1プロセスの原則に従い、コンテナという隔離環境内で何らかのアプリケーションを動作させる(例: PostgreSQLのコンテナイメージならPostgreSQLを動かすといったように)。 上の "Containers are typically modeled after an application" はこのあたりのことを意味しているのだろう。
このように Container は特定のアプリケーションを動作させるのに使われるので、Linux 仮想マシン全体を扱うのとは使い勝手が異なり、開発環境を構築するにあたっては、このあたりが手間だと感じることがあった。
もちろん Docker コンテナに supervisord 等の process manager をインストールして複数プロセスを管理することもできるようになるが、Dockerfile の記述とかがそれなりに面倒くさい。
一方、container machine では Linux の仮想マシンっぽいものを簡単に起動できる。 machine も container と同じくコンテナイメージから作成されるが、 container では PID 1 のプロセスは ENTRYPOINT や CMD で指定したコマンド/プロセスになる。対して、container machine では /sbin/init が実行されることになる(*1)。/sbin/init として systemd を実行することもサポートされている。
作成した container machine では Linux の仮想マシンが起動したような使い勝手になる。 これが、 "A container machine is modeled after a Linux environment." の意味するところなのだろう。
container と machine の違いはざっくりと言えば、最初に起動するプロセスが ENTRYPOINT や CMD で指定したものなのか、/sbin/init かの違いと言ってしまえばよいようだ。
結果として、特定のアプリケーションを実行するのか(container)、複数プロセスを管理できる Linux 環境を実行するのか(container machine)という違いになる。
container machine では他にもコンテナ内のユーザアカウントを自動作成してくれたり、 macOS のユーザディレクトリを自動でマウントして container machine と共有してくれるので、machine を作成した時点で作業しやすい環境が構築済みの状態となっている。
container machine の起動
実際に container machine を起動してみよう。 チュートリアルにもあるように Alpine のコンテナイメージなどはそのまま machine として起動できる。
container machine の作成と起動
% container machine create -n alpine-machine alpine
container machine に接続
% container machine run -n alpine-machine
/Users/tomita $ ps aux
PID USER TIME COMMAND
1 root 0:00 /sbin/init
7 root 0:00 /sbin/getty 38400 tty1
8 root 0:00 /sbin/getty 38400 tty2
9 root 0:00 /sbin/getty 38400 tty3
10 root 0:00 /sbin/getty 38400 tty4
11 root 0:00 /sbin/getty 38400 tty5
12 root 0:00 /sbin/getty 38400 tty6
26 tomita 0:00 /bin/sh
32 tomita 0:00 ps aux
PID 1に /sbin/init が起動しているのがわかる。 Alpine のイメージでは /sbin/init は OpenRC が使われているようだ。 systemd が使いたい場合は、systemd をインストールする例も先に挙げた公式チュートリアルに載っている。
AmazonLinux2023 の container machine を起動
個人的に AmazonLinux2023 のコンテナを使うことが多いので AmazonLinux2023 でも同じことをやってみよう。
AmazonLinux2023のコンテナを起動してみると以下のようなエラーになる。
% container machine create -n al2023-machine public.ecr.aws/amazonlinux/amazonlinux:2023 Error: failed to start process 61f332f8-17b8-41fe-b779-bf88390af4ed in container al2023-machine-ab3995 (cause: "internalError: "failed to start process (cause: "internalError: "startProcess: failed to start process: internalError: "vmexec error: internalError: " Error Domain=NSPOSIXErrorDomain Code=3 "No such process""" (cause: "internalError: "no PID data from sync pipe"")"")"")
ログを確認してみると、、、
% container machine logs al2023-machine /sbin.machine/init: line 74: /sbin/init: No such file or directory
これは AmazonLinux2023 のコンテナイメージに /sbin/init がインストールされていないためだ。
そこで Dockerfile を作成して systemd をインストールしたイメージを作成する。
Dockerfile
FROM public.ecr.aws/amazonlinux/amazonlinux:2023 RUN dnf install -y \ systemd \ sudo \ procps-ng \ httpd
作成した Dockerfile からコンテナイメージをビルドする。これは、通常のコンテナイメージのビルドと同じ手順だ。
% container build -t al2023-systemd .
これで container machine として AmazonLinux2023 を起動できるようになる(/sbin/init は systemd へのシンボリックリンクになる)。
% container machine create -n al2023-machine al2023-systemd al2023-machine
AmazonLinux2023 の container machine に接続
% container machine run -n al2023-machine [tomita@al2023-machine al2023]$ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 22480 10860 ? Ss 13:11 0:00 /sbin/init root 28 0.0 0.0 35132 11032 ? Ss 13:11 0:00 /usr/lib/systemd/systemd-journald systemd+ 34 0.0 0.0 19972 8260 ? Ss 13:11 0:00 /usr/lib/systemd/systemd-networkd systemd+ 40 0.0 0.0 23120 12112 ? Ss 13:11 0:00 /usr/lib/systemd/systemd-resolved root 43 0.0 0.0 18656 7136 ? Ss 13:11 0:00 /usr/lib/systemd/systemd-logind dbus 45 0.0 0.0 9408 3460 ? Ss 13:11 0:00 /usr/bin/dbus-broker-launch --scope system --audit root 46 0.0 0.0 2784 1548 pts/0 Ss+ 13:11 0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud - 115200,38400,9600 xterm root 47 0.0 0.0 2740 1440 tty1 Ss+ 13:11 0:00 /sbin/agetty -o -p -- \u --noclear - linux dbus 48 0.0 0.0 5412 2460 ? S 13:11 0:00 dbus-broker --log 4 --controller 9 --machine-id 3684e559957143689147994e tomita 53 0.0 0.0 4672 3628 pts/1 Ss 13:11 0:00 /bin/bash tomita 74 0.0 0.0 5740 2448 pts/1 R+ 13:12 0:00 ps aux
systemdが起動しているのがわかる。 これで、systemctlでプロセスの起動設定を変えることができる。
試しにhttpdを起動してみる。
$ sudo systemctl status httpd
○ httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; preset: disabled)
Active: inactive (dead)
Docs: man:httpd.service(8)
[tomita@al2023-machine al2023]$ sudo systemctl enable httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
[tomita@al2023-machine al2023]$ sudo systemctl start httpd
[tomita@al2023-machine al2023]$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (
/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
Active: active (running) since Sun 2026-06-14 12:12:30 UTC; 6s ago
Docs: man:httpd.service(8)
Main PID: 106 (httpd)
Status: "Started, listening on: port 80"
Tasks: 177 (limit: 77217)
Memory: 31.9M
CPU: 38ms
CGroup: /system.slice/httpd.service
├─106 /usr/sbin/httpd -DFOREGROUND
├─107 /usr/sbin/httpd -DFOREGROUND
├─108 /usr/sbin/httpd -DFOREGROUND
├─110 /usr/sbin/httpd -DFOREGROUND
└─151 /usr/sbin/httpd -DFOREGROUND
Jun 14 12:12:30 al2023-machine systemd[1]: Starting httpd.service - The Apache HTTP Server...
Jun 14 12:12:30 al2023-machine httpd[106]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.64.13. Set the '
[tomita@al2023-machine al2023]$
Linux 仮想マシンと同じように操作できるのがわかる。
まとめ
container machine で簡単に Linux 環境を構築できるのがわかった。
ただし、これは仮想マシンではなく、あくまで Linux の仮想マシン上に構築されたコンテナ環境だ。 Kernel はホスト(containarization framework の VM の Kernel)のものを使うことになるし、完全仮想化環境に比べると制約もある。 コンテナ型仮想化である OpenVZ と同じようなものと考えるといいかもしれない。
実際使ってみた感想としては、container machine は 仮想マシンと Container の中間というかいいところどりした使い勝手という印象だ。
- VMWare などのような仮想化ソフトよりも素早く Linux 環境を構築できる
- そして構築した仮想環境は仮想マシンと同じような使い勝手で使える
container machine は開発環境を構築するにはよさそうだ。 私は開発環境は VMWare や Parallels に Linux を入れて構築することが多いが、container machine による環境構築も有効な選択肢になりそうだ。
一点、データベースなどは今までどおり container で作っておいた方がよいだろう。 container machine は container より lifetime が長いとはいえ、container machine の 設定(CPU数とか)を変更したい場合やイメージの再ビルド時には machine の再作成が必要になる。 container machine のシステム領域にすべて突っ込んでおくと、これらは machine の再作成で消えてしまう。 仮想マシンのように扱えるとはいえ、どこに何を置いているかを気をつけて構成する必要がある。
(*1) イメージで指定された ENTRYPOINT や CMD は参照されないようだ。
投稿日:2026/06/15 22:39