先日、X でこの様な投稿を見かけました。

引用元の煽り投稿に合わせてやや過剰な表現を使っている点は置いといて、以前私も macOS の環境において何回か Docker Desktop から Podman Desktop に移行しようとして断念した事を思い出しました。

そこでまた重い腰を上げて再挑戦したところ、案外すんなり行ってしまい、しばらく使った結果今のところ困ってないので Docker Desktop をメインで使うのをやめ Podman Desktop メインでいく事に決めました。

本投稿では、改めて移行の際にやった事などをいくつかまとめたいと思います。なお、macOS のバージョンは 26.3.1 です。

そもそも Podman (Desktop) とは？

Podman は Red Hat が開発を主導しているコンテナエンジン（と周辺のエコシステム）のプロジェクトです。Docker と互換性があり（というより OCI と言う標準があり、どちらもこれに準拠している）、ほとんど Docker の様に使うことができます。細かい話をすると、Podman はコンテナを管理するために常時稼働する Daemon が不要で、かつデフォルトでは rootless と言う特徴が Docker とは異なる主な点かと思います（macOS はネイティブで Linux kernel をサポートしていないのでどちらも VM を立てる必要がある点は同じですが）。Podman Desktop はそれのデスクトップアプリです。

2021年に Docker Desktop のライセンスが変わり、ある程度の規模の企業では無料で使えなくなった事で、無料で引き続き使える Podman Desktop へ一部ユーザーが流れたと言うことがありました。私も確かその時と、その数年後に Podman Desktop が GA になった時の合わせて2度ほど試したんですが、その時はなぜかすんなり行かなかず、私の環境では無料版 Docker Desktop で十分だったので特に調べもせず諦めた記憶があります。

改めてインストール＋セットアップ

公式サイトからダウンロード＆インストールできます。Podman Desktop の初回起動時は、さっき少し触れた VM (Podman machine) のセットアップが必要です。Docker Desktop の Resources の様に、CPU, Disk size, Memory を割り当てる必要があります。

Daemon less ではあるものの、macOS ではこの machine (実態は
Fedora CoreOS ベースの VM) が起動している（≒Podman Desktop のアプリが起動している）必要があるので、その辺の便利さはあまり享受できないですね。また Docker Desktop と同様 Disk size が十分でないとすぐ no space left on device になるので注意が必要です。

さて、machine ができたらコンテナを起動することができます。Docker との互換性があるので、単に docker コマンドの部分を podman にするだけで主要なコマンドは大体そのまま動きます。試しに nginx を起動してみましょう:

podman run -it --rm -p 9989:80 nginx

これだけで起動できます。簡単ですね。

$ curl -I http://localhost:9989
HTTP/1.1 200 OK
...

1024 未満のポートに bind する

さっきの例で nginx をホストの 9989 に bind しましたが、デフォルトの 80 に bind してるプロジェクトもよくあるかと思います。しかし、 Podman ではそのままだとうまくいきません。

$ podman run -it --rm -p 80:80 nginx
Error: preparing container 3cd38109c3a2dedf277c94a8fee71fa2a1d80cc5d83a33c4f9509d54344a22e0 for attach: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024), or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied

デフォルトの設定では 1024 未満の port に bind できない様になっています。machine に入って設定を変更する必要があります。以下のコマンドで machine に ssh します:

podman machine ssh

machine の中で、以下のコマンドで 80 以上を許可します:

sysctl -w net.ipv4.ip_unprivileged_port_start=80

さて、これでコンテナは無事起動できる様になりましたが、実際に関わっているプロジェクトはすべて Docker 前提になっているので、その他にも色々やることがあります。

podman-compose

大抵のプロジェクトは compose.yaml (docker-compose.yml) で複数コンテナを管理しているかと思います。これについても、コミュニティが podman-compose と言う Python のラッパーを提供していて、これを使って今のところ問題なく運用できています。

私は Homebrew でインストールしました。

brew install podman-compose

Compose Spec 準拠なので、基本は Docker Compose と大体同じように動きます。

podman-compose up -d

networks の挙動に一部違いがあった

Docker Compose と一部 networks の挙動が異なる部分がありました。次の様な設定があります:

services:
  app:
    image: busybox:1.36
    command: ["sh", "-c", "sleep 3600"]
    networks:
      default:
      app_net:
networks:
  app_net: {}

app_net と言う network を明示的に作り、default と app_net の2本挿しです。Docker Compose v5.0 だとうまくいきますが、podman-compose version 1.5.0 だと Python のレイヤーでエラーが発生します。default と言う名前の network が networks に定義されていないからです。Docker Compose ではこの場合でも default と言うネットワークを作るので問題ないのですが、podman-compose ではそうではない様です。networks に default も明示してあげるか、そもそも networks がない場合は作られるので問題ありません。 Compose Spec 的にはどっちが正しいのかは分かりませんがこの点は注意です（瑣末な問題ではありますが）。

AWS CDK で使える様にする

AWS CDK で、Lambda などに使う DockerImageAsset を使う場合、cdk deploy 時にデプロイを実行したマシンでイメージのビルドが行われます。この時、 docker build が前提になっているので Docker Desktop が起動していないとビルドができず、デプロイが進みません。ですが、公式ドキュメントにもある通り、 CDK_DOCKER に podman コマンドのパス (私の場合は /opt/homebrew/bin/podman を指定するとうまくいきます:

CDK_DOCKER=/opt/homebrew/bin/podman npx cdk deploy AppStack

私は今のところないですが、他に docker コマンドに依存してるシステム等がある場合、podman コマンドへの symlink を Docker Desktop が提供する docker コマンドである /usr/local/bin/docker よりも優先的に解決される PATH に docker と言う名前で配置しておくのも良いかもしれません。

Docker Desktop について

タイトルでは完全撤退とは書いたものの、何かしらで使う可能性があるので削除自体はしておらず、VM のサイズをかなり縮小した上で自動起動の設定をオフにしています。何かあったらいつでも使える用。

まとめ

以上、macOS でコンテナ環境を Docker Desktop から Podman に移行した話でした。もしかしたら GA になった2023年の時点からそうだったのかもしれませんが、互換性の面で今のところ困っている事がないのでこのまま楽しい Podman ライフを送ろうと思います。