Podmanに興味はありますか？

開発
20

私はこれに約 30 分ほど挑戦してみました。Podman はコマンド互換性がありますが、出力互換性はないため、launcher が出力を解析しようとした際に混乱します（見分けは容易で、docker --version は podman version 1.0.5 と返すため、これは重大な障壁ではありません）。

docker0 ネットワークデバイスが存在しません。Podman のデフォルトの overlay ストレージドライバは基本的に overlay2 実装であり、それに対してエイリアスされていますが、出力には overlay2 とは表示されず、docker info コマンドの出力もわずかに異なります。チェックを回避するために --skip-prereqs を使用しました。共有ディレクトリは自動的に作成されませんでしたが、その理由については調査しませんでした。進めるために mkdir -p /var/discourse/shared/standalone/log/var-log を実行しました。次に、SELinux が強制モードで /var/discourse に対して設定されていないことに起因する権限の問題が発生しました。

ディレクトリをコンテナにボリュームマウントし、:z または :Z を追加すると、コンテナエンジンがボリューム内のコンテンツを container_file_t に再ラベル付けします。

podman build のドキュメントには以下のように記載されています：

z オプションは、2 つのコンテナがボリュームコンテンツを共有することを Podman に伝えます。その結果、Podman はコンテンツを共有コンテンツラベルでラベル付けします。共有ボリュームラベルにより、すべてのコンテナがコンテンツの読み書きを可能にします。Z オプションは、Podman にコンテンツをプライベートな非共有ラベルでラベル付けするように指示します。プライベートボリュームを使用できるのは現在のコンテナのみです。

私は一時的にこの使い捨てインストールで setenforce 0 を実行し、後で対応することにしました。 代わりに、volumes を小文字の :z を使用するように変更しました：

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared:z
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log:z

これらの小さな修正により、Discourse のブートストラップに成功しました。Redis はカーネルで透過的 Huge Pages がサポートされていることに不満を持っており、その無効化とメモリオーバーコミット設定の変更を提案しています。おそらく、メガバイト単位のログ出力の中に、私が見逃した他の有用なデバッグメッセージも多数あったでしょう！

./launcher start app
...
--restart オプションはサポートされていません。
コンテナの再起動には systemd ユニットファイルを使用してください

スクリプトを --restart を使用しないように修正し、start モードでも --skip-prereqs が必要であることを発見しました。これにより最終的に docker run を試す段階に至りましたが、そこで以下のエラーが発生しました：

./launcher start app --skip-prereqs
...
+ /usr/bin/docker run ... -e DOCKER_HOST_IP= --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared:z -v /var/discourse/shared/standalone/log/var-log:/var/log:z --mac-address 02:9c:01:9b:0e:17 local_discourse/app /sbin/boot
--mac-address オプションは現在サポートされていません

したがって、これはすぐに動作するものではなく、launcher を Docker または Podman で動作するように修正するのにどれほどの労力がかかるのかもわかりません。プリリク処理に対処することは「そのまま動作する」可能性が高く、Podman の事前チェックを行えばそれほど難しくないでしょう。しかし、ネットワーク設定に関する仮定がスタック下の設定にどの程度深く入り込んでいるかはわかりませんし、このネットワークモードは Podman によって単純にサポートされていないように見えます。

この懸念に基づき、launcher を Podman 下で機能させるための作業は行わない予定です。これは単に初期の簡易実験の結果を報告するものです。

とはいえ、スタックに精通した人であれば、それほど難しい作業ではないでしょう。今年の春に私が行った開発作業は、Fedora 29 上での手動開発インストールで行ったもので、apt-get の代わりに dnf を使用する、いくつかのパッケージ名の微調整を行うなど、Docker や Podman を一切使用しない、些細な調整で済みました。Podman と Discourse 技術スタック全体の通常の管理に精通した人であれば、それは比較的容易な作業の中等度の量であると考えるでしょう。もし必要な作業の全体像がわかっていれば、それが「陳腐化」して継続的なメンテナンスが必要になる可能性のある作業かどうかをよりよく判断できたでしょう。しかし…私は知りません。:roll_eyes: