これをみながら、Podman + Podman-composeを試してみました。 以下のバージョンを想定しています。
- Podman 2.2.1以降
- podman-compose 0.1.5（執筆日時点で最新）
必要なソフトウェアのセットアップ
Podmanおよびpodman-composeをインストールします。
CentOSなどの場合
以下で導入できますが、pipコマンドについてはroot権限で実行すると怒られてしまいます。
# yum install podman python3-pip -y # pip3 install podman-compose WARNING: Running pip install with root privileges is generally not a good idea. Try `pip3 install --user` instead.
podman-composeを使ったコンテナアプリケーションのデプロイ
基本的には、Docker + docker-composeを使う時とお作法は同様でした。 以下に従って、ディレクトリー、app.py、requirements.txt、Dockerfile、docker-compose.ymlを作成します。
アプリケーションアクセスに必要なので、ポート5000(tcp)を解放します。
# firewall-cmd --add-port=5000/tcp # firewall-cmd --permanent --add-port=5000/tcp # firewall-cmd --reload
プロジェクトディスクトリー内でpodman-compuse upでアプリケーションを起動します。
# podman-compose up
ブラウザーなどでアクセスすると、コンテナアプリケーションにアクセスできます。docker-composeと一緒ですね。
docker-composeを使う事もできる？
ちなみに、互換APIを使って、docker-composeコマンドを使ってPodmanコンテナでアプリケーションをデプロイすることができるようです。
早速試してみたのですが、file not found の嵐で動く気配がありませんでした。
# export DOCKER_HOST=unix:///run/podman/podman.sock # docker-compose up
おそらくPodmanのバージョンやdocker-composeのバージョン、Pythonのバージョンなどいくつか乗り越えないといけない壁があるのだと思われます。ただ、以前触った時と比べるとpodman-composeがうまく動いてくれたので、無理にPodmanでdocker-composeを使わないでもいいだろうとは思いますね。
そもそもdocker-composeを使うなら、最初からDockerを使った方が良い気もしないでもないです。
ディストリビューションによってはPodmanとDocker Engineの共存は難しいらしい
あと、どうでもいいことかもしれませんが、PodmanとDocker Engine（旧称Docker CE）の共存をしようとすると大変なんですね。 Docker Engineはcontainerd.ioというパッケージでruncが提供されるのでコンフィリクトを起こすんですね。 「--nobest」をつけて回避できる様ですが、以降yumコマンドを実行する時に「--nobest」オプションが必要になります。
外部リポジトリーに依存するとこういうことが起きるよなあ。
# yum install docker-ce docker-ce-cli メタデータの期限切れの最終確認: 0:01:14 時間前の 2021年03月31日 17時16分02秒 に実施しました。 エラー: 問題: package docker-ce-3:20.10.5-3.el8.x86_64 requires containerd.io >= 1.4.1, but none of the providers can be installed - package containerd.io-1.4.3-3.1.el8.x86_64 conflicts with runc provided by runc-1.0.0-70.rc92.module_el8.3.0+699+d61d9c41.x86_64 - package containerd.io-1.4.3-3.1.el8.x86_64 obsoletes runc provided by runc-1.0.0-70.rc92.module_el8.3.0+699+d61d9c41.x86_64 - package containerd.io-1.4.3-3.2.el8.x86_64 conflicts with runc provided by runc-1.0.0-70.rc92.module_el8.3.0+699+d61d9c41.x86_64 - package containerd.io-1.4.3-3.2.el8.x86_64 obsoletes runc provided by runc-1.0.0-70.rc92.module_el8.3.0+699+d61d9c41.x86_64 - package containerd.io-1.4.4-3.1.el8.x86_64 conflicts with runc provided by runc-1.0.0-70.rc92.module_el8.3.0+699+d61d9c41.x86_64 - package containerd.io-1.4.4-3.1.el8.x86_64 obsoletes runc provided by runc-1.0.0-70.rc92.module_el8.3.0+699+d61d9c41.x86_64 - problem with installed package podman-2.2.1-7.module_el8.3.0+699+d61d9c41.x86_64 - package podman-2.2.1-7.module_el8.3.0+699+d61d9c41.x86_64 requires runc >= 1.0.0-57, but none of the providers can be installed - cannot install the best candidate for the job - package runc-1.0.0-64.rc10.module_el8.3.0+479+69e2ae26.x86_64 is filtered out by modular filtering (競合するパッケージを置き換えるには、コマンドラインに '--allowerasing' を追加してみてください または、'--skip-broken' を追加して、インストール不可のパッケージをスキップしてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)
ちなみに、Ubuntuを使えばUbuntuにはDockerもcontainerdもpodmanも含まれる（注: PodmanはUbuntu 20.10から）ので、こういう悩ましい問題は起きません。Docker Engineのリポジトリーのパッケージを使った場合は、同じ問題が起きるかもしれません。
4/1/2021 追記
Fedoraにも moby-engine というパッケージが用意されていて、このパッケージを入れるとDockerを使えます（執筆日時点では19.03ベース）。これを使うには、以下にあるようにcgroups v1の切り替えが必要です（Fedora 33のrunCがcgroups v2をサポートしていない。Docker Engine版は20.10で修正済み）。Fedora 33のpodmanとmoby-engineは共存可能です（Podmanはcgroups v1でもcgroups v2環境でも動くため）
4/7/2021 追記
現在はFedora 33のpodmanとDockerコミュニティ版Dcoker Engineは問題なく共存できます（依存関係の問題が起きなくなった）。
