Pleasanter を複数ポートで運用するための構成整理(Ubuntu+nginx+UFW)

Pleasanter を Linux(Ubuntu)上で運用していると、

「本番環境とは別に検証環境を作りたい」
「DB を分けた複数の Pleasanter を並列で動かしたい」

というニーズが出てくる。

自分だけかもしれないけど。

メモリに余裕があるといくつか並列に走らせることができるので思い付くわけですね。

ちなみに、DS1621+はRAM32GBで、かなり遊びがあるので、3本くらいは余裕で走るわけです。

アクセスは個人なので、たかが知れてるもので。

Windows 版の IIS と違い、Linux 版 Pleasanter は Kestrel(dotnet)+nginx リバースプロキシという構成になるため、複数インスタンスを動かすには nginx と UFW の理解が必須になる。

今回の作業で、複数ポート運用のポイントが完全に整理できたので、その手順と背景をまとめておきます。


■ なぜ Pleasanter は “リバースプロキシ必須” なのか

Linux 版 Pleasanter は内部で Kestrel(dotnet)を使って動いている。
Kestrel は外部公開を前提にしていないため、以下のような制約がある。

  • Host ヘッダの整合性チェックが厳しい
  • X-Forwarded-Host が無いと BadRequest を返す
  • HTTPS 終端は nginx 側で行う前提
  • BaseUrl が設定されている場合は URL が一致しないと拒否される

つまり、Kestrel に直接アクセスしても正常に動かない。
必ず nginx を経由させる必要がある。


■ nginx 側の設定(複数インスタンス対応)

複数の Pleasanter を動かす場合、
nginx の listen(公開ポート)を変えるだけで並列運用が可能になる。

例:8811 で動かす場合

● server_name は _ が最も安全

複数環境を作る場合、
server_name 192.168.0.163; のように IP を固定すると
ポート付きの Host と一致せず、nginx が設定を選ばないことがある。

server_name _; にしておけば、
どんな Host でもこの設定が使われるためトラブルが起きない。

● X-Forwarded-Host は必須

Pleasanter はこのヘッダが無いと BadRequest を返す。
Linux 版 Pleasanter の “落とし穴” のひとつ。


■ nginx の設定テストと再起動


■ UFW(ファイアウォール)の落とし穴

今回もっとも重要だったポイントがここ。

Ubuntu の UFW が有効な場合、
nginx が LISTEN していても、UFW が許可していないポートは外部からアクセスできない。

実際、8888 は開いていたが、
新しく追加した 8811 は許可されていなかったため、
nginx が動いているのにアクセスできない状態になっていた。

● 現在の状態確認

● 新しいポートを許可

これで外部からアクセスできるようになる。


■ 動作確認

ブラウザで:

例:

Pleasanter のログイン画面が表示されれば成功。


■ 複数インスタンスを増やす場合

  • nginx の listen を 8812 / 8813 … と増やす
  • dotnet 側の内部ポートを 5003 / 5004 … と変える
  • DB 名を変える(別インスタンス用)
  • UFW でポートを開放する

これだけで完全に独立した Pleasanter が複数動く。


■ 今回のポイントまとめ

  • Pleasanter はリバースプロキシ必須
  • nginx の設定は
    • listen
    • server_name
    • X-Forwarded-Host
      が重要
  • nginx が LISTEN していても、UFW が許可していないと外部からアクセスできない
  • 複数インスタンスはポートを変えるだけで量産可能
  • BaseUrl が未設定ならポート変更に影響しない

今回の 8811 の件は、
nginx も dotnet も正しく動いていたのに、UFW が止めていたという典型的なパターンだった。