People,
I know Discourse has standardised on Docker for distribution and support but it seems to me there are some reasonable arguments for also making Discourse available as a Podman container? I would be happy to have a go at producing something if at least one clued-up dev was prepared to help me . .
Regards,
Phil.
It is unlikely we can spend any time on it, but if you want to give it a go, go for it.
Thanks for the fast reply Jeff!
I will see if I can get some enthusiam going from the appropriate Fedora group . .
@codinghorror , Can you point me to a HOWTO for a completely manual install somewhere? - I have some familiarity with Rails etc . .
Here are the instructions: Install Discourse on Ubuntu or Debian for Development.
If you look at the install script in the Install Discourse Dependencies section of the guide, you’ll find the manual instructions there.
Thanks!
I will check it out . .
RHEL 8 では Docker は Podman に置き換えられています。
RHEL（および CentOS）の顧客を失わないためにも、Podman のインストールサポートを開始するのは自然な流れでしょう。
Podman の公式サイト によると、
簡単に言えば：‘alias docker=podman’
とあり、Docker との高い相互運用性が示されています。
ROI は良さそうですか？
推奨されるインストール方法では、リポジトリが提供する Docker パッケージを使用しないため、どちらにせよこれは考慮事項ではないかもしれません。
Docker 自体が特定のディストリビューションのサポートを廃止するまで、問題ありません。
Podman のサポートにどれほどの労力が必要かは正確にはわかりませんが、エンタープライズ顧客は「おそらく問題ない」というサポートレベルを好まないと思います。
RHEL (CentOS) 8 以上を実行している場合、外部リポジトリから Docker をインストールする必要があります。これは Podman と並行してインストールされる可能性があり、そのような使用ケースは RedHat によってサポートされません。あるいは、Docker イメージをインストールするために Podman を使用することもできますが、これは Discourse によってサポートされていません。
公式にサポートされるようになることを願っています。
CentOS 8 がリリースされるにつれて、この話題がより注目されるようになるでしょう。
CentOS 8 およびその派生である RHEL 8 では、Docker はすでにサポートされています。両者を並行して実行するシナリオがあるとは聞いたことがありませんが、何か見落としているでしょうか？
Docker が Podman に完全に置き換わったと言うのは正確ではなく、Podman がデフォルトでバンドルされるようになったというだけのことです。そもそも、ディストリビューションにバンドルされたバージョンの Docker を使う人はいませんよね？
サポートの責任は常に Red Hat ではなく Docker 側にあります。前述の通り、推奨されているのはディストリビューションにバンドルされたパッケージではなく、Docker 公式のパッケージを使用することです。
実際は逆ですが、リンク先の Red Hat ページには次のように記載されています。
Red Hat Enterprise Linux (RHEL) 8 向けに
dockerパッケージは Red Hat から提供またはサポートされていません。
podmanコンテナエンジンが、Red Hat Enterprise Linux 8 システムにおける優先され、保守・サポートされるコンテナランタイムとしてdockerに取って代わりました。
私はこれを、Red Hat による Docker の「サポート」とは読み取れません。
もしこれが RHEL ユーザーへのサポート中止を意味するなら、それは Discourse の判断です。
Docker のリポジトリを確認してください。RHEL パッケージは提供されておらず、CentOS のみです。
Podman は Docker と 100% 互換性があることを意図しているため、実際には何らかの対応を行う必要はないかもしれません。
おそらく、インストールドキュメントを少し編集して、Podmanのインストールへの言及を追加することをお勧めします（おそらく冒頭で「対応しており、dockerコマンドをpodmanに置き換える必要がある」という旨を記載する程度でよいでしょう）。これにより、ユーザーが対応の有無について疑問を抱くのを防げるかもしれません。
この機能をテストするまで、明確な立場を取るつもりはありません
私の知る限り、人類の歴史において Podman を使用して Discourse をインストールしようとした例はこれまでありません
ここに多少の混乱があると思います。私たちは Podman の存在を知っており、チームの何人かは、それが成功することが FOSS エコシステム全体にとって良いことになると考えて応援しています。しかし：
サポートされていません。
当社のホスティングは Ubuntu / Debian を使用しています。そのため、現時点では RHEL を実行している顧客はいません。
たとえそのまま動作が確認されたとしても、サポートに関する考え方には非常に警戒すべきです。
Docker が CentOS/RHEL を放棄しない限り、それは不要です。仮にそれが起こったとしても、Discourse/Docker がディストリビューションレベルで要件を課す最初のアプリケーションになるわけではありません。
ここで最もイライラするのは、行われた作業の量に対する憶測の量です。
もしこれが最初の投稿であれば、私の反応は違ったでしょう。
過去 30 日間、公式の Discourse Docker インストールを podman で使用してきました。私が感じた些細な点と、このセットアップで気に入った点をまとめました！
ここでの根本的な問題は、「私たちのために作業してください。私は実験も作業もしたくない。これはあなたとコミュニティにとって大きな問題になるでしょう」という姿勢です。
私はこれを非常に嫌います。
それが私の回答を非常に明確に表していますね。ここでは予測可能な技術と取り組んでいるので、終末的な宣言をする必要も余地もありません。
私もやり取りの応酬はあまり好きではなく、関与するよりも黙っていればよかったと後悔しています。
この発言では、動作させるために何らかの作業が必要だと想定していましたが、100% 互換性があり、コマンドを置き換えるだけで済むのであれば、それは素晴らしいことです。
Podman を使用して行き詰まったユーザーを導くことを提案しました。
開発モデルは正確には存じ上げませんが、コミュニティ主導であり、ユーザーがまず作業を行うことを想定しているものと推察します。
私はこれに約 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 技術スタック全体の通常の管理に精通した人であれば、それは比較的容易な作業の中等度の量であると考えるでしょう。もし必要な作業の全体像がわかっていれば、それが「陳腐化」して継続的なメンテナンスが必要になる可能性のある作業かどうかをよりよく判断できたでしょう。しかし…私は知りません。