mkbrechtel
(Markus Katharina Brechtel)
1
こんにちは！
Discourse OCI イメージを作成するために、RPS Discourse Image Builder というリポジトリを作成しました。これは、ここにいる多くの人にとって役立つかもしれません。主に、時間がかかる Discourse のデプロイを待つ必要がなくなり、Discourse のバージョンを確実に固定できるようになるためです。
discourse_docker リポジトリ を使用して、可能な限り汎用的な方法で安定バージョンでイメージをビルドするスクリプトを作成しました。
また、ビルドに必要なデータベースと、テスト用の Discourse イメージを起動し、ローカル開発用に実行する Docker Compose ファイルもあります。これは shell エグゼキュータを持つ GitLab Runner で実行できますが、プロファイルをサポートする docker-compose バージョンを持つシステムが必要です。
アプローチ
ビルドスクリプトは、CI/CD パイプライン内で実行されるべきです。これにより、バージョンを簡単に更新でき、さらに調整が必要な場合は、このリポジトリが作成したイメージに基づいた Dockerfile を持つ別のリポジトリで行われます。
背景
Discourse は非常に優れたソフトウェアですが、デプロイやバージョン固定はそれほど簡単ではありません。このリポジトリは、Discourse のデプロイに使用できる Docker イメージを作成するために使用されます。
問題は、Discourse が Docker イメージのビルド方法において非常にユニークな方法を採用していることです。Discourse の開発者は、彼らの discourse_docker リポジトリを使用して、ターゲットマシン上でイメージをビルドすることを期待しています。
この件についてはフォーラムで長い議論がありましたが、要するに、Discourse の主要開発者は、Discourse のデプロイに使用できる公開 Docker イメージのサポートを拒否しています。彼らは、Discourse をデプロイする唯一の公式な方法として discourse_docker リポジトリを維持したいと考えています。
このアプローチの主な欠点は次のとおりです。
- 私たちの経験では、Discourse のバージョンを確実に固定することはできません。
- イメージのビルドに時間がかかり、イメージがビルドされてもサービスは利用できません。また、Discourse は、サポートしているすべてのサービスの中で最も長い DevOps イテレーションサイクルを持っています。
- データベースは、通常の Docker ベースのプロジェクトとは異なる方法で管理されます。
- 公式の Discourse デプロイ方法は、Kubernetes や Docker-Compose のような OCI ベースの開発ワークフローやデプロイメントと互換性がありません。
- discourse_docker ランチャーは、実行されている環境について多くの仮定を立てています。たとえば、ルートレス Podman では、引数や環境変数でバイパスできない、ストレージボリュームが見つからないというエラーで実行を拒否します。
「いいね！」 2
Falco
(Falco)
4
app.ymlファイルには、実行したいバージョンを設定できるversionパラメータがあります。
公式のインストールを使用してください。これはスタンドアロンコンテナからWebコンテナとデータコンテナを分離するで処理されます。
はい、私たちは「FileZillaをFTP経由でドラッグアンドドロップしてこのzipファイルを解凍する」というWebマスターフレンドリーな方法を目指しながら、誰もがスタック内のすべてのソフトウェア（データベースを含む）の最新でサポートされているパッチ適用済みのバージョンを実行できるようにしています。
より知識のあるDiscourse管理者向けには、Discourseを個別のPostgreSQLサーバーで使用するように構成するに従って、環境変数で外部で管理されているデータベースを指定できます。
はい、ランチャーベースのフローは、そのままではコンテナオーケストレーションと互換性がありません。ただし、./launcher bootstrap appを実行し、結果のイメージをコンテナレジストリにプッシュしてから、オーケストレーション経由でそのイメージを実行することで互換性を持たせることができます。
これは一般的に役立つと思われるため、可能にするためのプルリクエストを歓迎します。pr-welcome
「いいね！」 5
mkbrechtel
(Markus Katharina Brechtel)
5
2.8 からデプロイを作成しようとしましたが、間違った Discourse バージョンについて不平を言って失敗しました。CI/CD で再現できるようになったので、ここでエラーを確認できます: docker-build (#4121616927) · Jobs · idcohorts / RPS / Discourse Image Builder · GitLab
基本的にそれをやっています。
ありがとうございます。取り掛かります。
「いいね！」 1
Falco
(Falco)
6
Discourse 2.8は現在サポートされていないため、最新のRubyをバックポートしておらず、すでにEOL（サポート終了）のRubyバージョンで実行されているためです。誰も本番環境で実行すべきではありません。
「いいね！」 1
mkbrechtel
(Markus Katharina Brechtel)
7
「いいね！」 2
mkbrechtel
(Markus Katharina Brechtel)
8
それでも、バージョンパラメータを変更するだけで技術的に不可能であり、古い環境を再現できなくなりました。
古いベースイメージを使用するだけで、それが可能です。
mkbrechtel
(Markus Katharina Brechtel)
10
どうすればできますか？検索しましたが、解決策が見つかりませんでした…
ターゲットとしているリリース頃に作成された古いベースイメージを文字通り参照しています（当然、それ以降でなければなりません）。
何ページにもわたってあります。
https://hub.docker.com/r/discourse/base/tags
「いいね！」 1
pfaffman
(Jay Pfaffman)
12
しかし、古すぎるバージョンに固定しようとすると、Discourse のベースイメージの更新されたバージョンで動作しない可能性があります。具体的な例は覚えていませんが、古いバージョンの Discourse は Ruby 3.2 では動作しないため、古いバージョンの Discourse に固定する場合は discourse_docker も固定する必要がある場合があります。
最も安全で、ほとんどの場合最も無駄のない解決策は、イメージをビルドしてリポジトリにプッシュすることであり、デプロイごとに新しいイメージをビルドするのではなく、それを行うことです。プラグインがある場合は、それらもそれぞれ固定する必要があるでしょう。
私はこれを、ECS および GCP と AWS 上の k8s の複数のクライアントに対して行いました。
前述したように、discourse_docker も古いバージョンに固定すれば再現できると確信しています。プラグインの場合は、それらも古いバージョンに固定する必要があるため、より複雑になります。古いバージョンを本当に維持したい場合は、それらを正確に一度ビルドしてリポジトリにプッシュするのが最善の方法です。私はクライアントと協力して、現在の本番環境から最新バージョンへのアップグレードパスをテストするためにこれを行っており、スムーズに動作しています。
「いいね！」 1