tea-e7n.dev

apple/containerを試してみた

そういえばapple/containerみたいなのあったなーと思い出して、Dockerと何が違うんだろとちょっと気になったので動かしてみます。

環境

  • Mac Mini (M4)
  • macOS 26.6.2

インストール

公式手順に則って作業します。

自分の場合はここからバージョン1.2.2をインストールしました。

動かしてみる

Dockerとほぼ同じノリで動くようで、なおかつDockerfileも使えるらしいので、Dockerを使ったことある人なら扱いは何も難しくなさそうです。

適当にDockerfileを書いたので、これを元にコンテナを作って動かします。

FROM docker.io/library/golang:1.26-alpine AS builder

WORKDIR /src
COPY go.mod ./
COPY *.go ./
RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /hello .

FROM scratch
COPY --from=builder /hello /hello
ENTRYPOINT ["/hello"]

image build、コンテナ起動は次のように実行します。 Dockerとほぼ同じ要領で動きます。

# build
> container build --tag apple-container-go:latest --file Dockerfile .

# run
> container run --rm apple-container-go:latest
Hello, World!

で、まあ普通に使えましたねってことで終わりっちゃ終わりです。

で、Dockerとなにが違うの?

Dockerとapple/containerとの違いは、主にVMの持ち方にあるみたいです。

例えばmacOSでDocker Desktopを利用すると、ホストとDockerとの間に1つの共有VMが立ち上がって、そいつの上で色んなコンテナが動きます。まあ要は、複数コンテナがあってもVMは共有用の1つっていうイメージです。

一方で、apple/containerについてはそこが違って、コンテナごとに別々のVMを起動します。

それの何がいいのっていう話ですが、主にセキュリティ面で嬉しいことがあるというふうに公式に記載されています。 例えばDocker Desktopのようなコンテナ間共有VM方式の場合、脆弱性などを突いてコンテナ境界や共有VMが侵害されると、それを経由して他のコンテナまで影響が広がる可能性があります。 一方でapple/containerの場合はVMをコンテナごとに分離しているので、もしもあるコンテナが汚染されても、他に影響が波及しづらいという特性があります。

例えばAI Agentにタスクを任せるとき、AIが何かしらのソフトウェアをインストールして実行するというシチュエーションがありますが、そうした場合にapple/container上で動かすことで、万が一悪意のあるものであっても影響範囲を限定することができるというのが具体的なメリットとしてあります。

他にも細かい差は色々あるようですが、大きな差はこのくらいっぽいです。

まとめ

apple/containerをさくっと使ってみました。 とは言っても、別に大したことをする必要はなく、ほぼDockerと同じ感触で使うことができました。

また、Dockerとapple/containerとの違いについても簡単に確認しました。 AI時代との相性が良さそうな点がGoodだと思いました。

普段使いとして今すぐにDockerからapple/containerに移行するというほどではないかなーと言うのが現時点での所感ですが、まあDockerとほぼ同じ感触で使えるので、思い出したら積極的に使おうかなと思います。

今後も継続的にwatchしていきます。