ネットワーク隔離環境での Discourse HA セットアップ

よろしくお願いします。
本番環境で高可用性を持つ Discourse のセットアップを計画しています。以下に設計計画といくつかの環境条件を示します。

  1. アプリケーションサーバー 3 台と Postgres DB サーバー 2 台でセットアップします。常に 1 台の PG サーバーが書き込みモードで、もう 1 台が読み取り専用モードになります。

  2. これら 3 台のアプリケーションサーバーは、同じ DB サーバーを指します。

  3. 各 DB インスタンスは、それぞれ読み取りおよび書き込み専用の操作を提供する必要があります。

  4. 本番サーバーにはインターネット接続がありませんが、dockerHub イメージをプルすることはできます。

  5. 独自の GitLab サーバーがあります。

  6. Docker イメージをブートストラップし、そのイメージを複数のサーバーにデプロイすることは可能ですか?

どなたか、このセットアップを行うのを手伝っていただけませんか?リンクや提案があれば、プライベートメッセージで送ってください。

「いいね!」 2

./launcher bootstrap appどこか で実行した後、結果のコンテナイメージを保存し(通常はレジストリにプッシュします)、それを3つのアプリケーションサーバーにダウンロードして実行する必要があります。

中央のRedisサーバー(およびそのレプリカ)も必要になります。また、それらの異なるアプリケーションサーバーへのリクエストをルーティングするためのロードバランサーも不足しています。

「いいね!」 3

Falcoさん、返信ありがとうございます。

HAProxyロードバランサーとNexusリポジトリをアーティファクトの保存に使用しています。

「いいね!」 1

@Falco様
本番環境ではインターネットにアクセスできないため、インターネットにアクセスできるマシンでブートストラップを実行し、そのブートストラップイメージを本番サーバーに持ち込むことを計画しています。本番VMでこれを行うと、Unicornサーバーが親プロセスIDを探しているため、コンテナが起動せず実行されません。

ここで助けていただけますでしょうか。ブートストラップを実行した /var/discourse ディレクトリを本番サーバーにコピーする必要がありますか?

「これ」とは何ですか?ブートストラップですか、それとも以前にブートストラップされたコンテナイメージを実行することですか?

「いいね!」 1

以前ブートストラップされたコンテナイメージを実行しているとき

画像をどのように保存し、本番サーバーにエクスポートしましたか?

具体的に、保存した画像を本番環境でどのように実行しようとしていますか?

「いいね!」 1

以前にブートストラップされたイメージをNexusリポジトリにプッシュし、Nexusリポジトリから本番サーバーにプルします。

./launcher start-cmd app から生成された docker run コマンドを本番サーバーで実行します。

「いいね!」 1

本番環境で起動した際の、エラーログを共有してもらえますか?

run-parts: /etc/runit/1.d/00-ensure-links を実行中
run-parts: /etc/runit/1.d/00-fix-var-logs を実行中
run-parts: /etc/runit/1.d/01-cleanup-web-pids を実行中
run-parts: /etc/runit/1.d/anacron を実行中
run-parts: /etc/runit/1.d/cleanup-pids を実行中
古いPIDファイルをクリーニング中
run-parts: /etc/runit/1.d/copy-env を実行中
runsvdir を起動しました。PIDは42です
chgrp: 無効なグループです: ‘syslog’
ok: run: redis: (pid 51) 0s
ok: run: postgres: (pid 56) 0s
supervisor pid: 53 unicorn pid: 75
config/unicorn_launcher: 行 71: kill: (75) - No such process
config/unicorn_launcher: 行 15: kill: (75) - No such process
(53) 終了します
ok: run: redis: (pid 51) 7s
ok: run: postgres: (pid 101) 0s
supervisor pid: 96 unicorn pid: 103
config/unicorn_launcher: 行 71: kill: (103) - No such process
config/unicorn_launcher: 行 15: kill: (103) - No such process
(96) 終了します
ok: run: redis: (pid 51) 14s
ok: run: postgres: (pid 127) 0s
supervisor pid: 120 unicorn pid: 129
config/unicorn_launcher: 行 71: kill: (129) - No such process
config/unicorn_launcher: 行 15: kill: (129) - No such process
(120) 終了します
ok: run: redis: (pid 51) 22s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 51) 30s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 51) 37s
ok: run: postgres: (pid 174) 0s
supervisor pid: 165 unicorn pid: 176
config/unicorn_launcher: 行 71: kill: (176) - No such process
config/unicorn_launcher: 行 15: kill: (176) - No such process
(165) 終了します
ok: run: redis: (pid 51) 48s
ok: run: postgres: (pid 196) 1s
supervisor pid: 191 unicorn pid: 198
config/unicorn_launcher: 行 71: kill: (198) - No such process
config/unicorn_launcher: 行 15: kill: (198) - No such process
(191) 終了します
ok: run: redis: (pid 51) 54s
timeout: down: postgres: 1s, normally up, want up

外部の PostgreSQL、Redis、およびオブジェクトストレージを使用していますか?HA を行う場合はそれが期待されることであり、本番サーバーとビルドサーバーの両方がそれらの外部サービスにアクセスできる必要があります。

ブートストラップを1台のサーバーで実行し、ブートストラップされたコンテナイメージを別のサーバーでスタンドアロンセットアップで実行するシナリオをテストしています。

それは絶対にうまくいかない方法です。

オブジェクトストレージについて言及する理由は何ですか。サーバーの内部ストレージを使用することはできませんか?

HA セットアップでは、ブートストラップを実行した discourse ディレクトリをすべてのアプリサーバーにコピーする必要がありますか?

複数のアプリサーバーとユーザーのアップロードをどのように処理しますか?すべてのサーバー間で共有ネットワークドライブを使用しますか?それは機能するかもしれませんが、それに対する公式のソリューションはS3 APIを使用したオブジェクトストレージです。

その必要はありません。

はい、外部のPostgresサーバーとredisクラスターを使用しています。

アプリケーションと共にRedisクラスターに使用する3つのアプリサーバー。

したがって、discourseビルドディレクトリには共有ディレクトリ/ストレージを使用する必要があります。@Falco、おかげで明確になりました。

ご迷惑をおかけして申し訳ありません、@Falcoさん、最後の質問があります。

再構築ステップを実行する際に、既存のPostgres DBのデータに影響はありますか?もし影響がある場合、どのように対処すればよいですか?

はい、再構築中に実行されるマイグレーションがあり、データと構造の両方が変更されます。

HA 環境では、こちらのガイダンスに従う必要があります: Introducing Post Deployment Migration

「いいね!」 1

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.