アプリケーションサーバPassengerを3から6まで更新した際に感じた違いまとめ

はじめに

アプリケーションサーバPassenger(Phusion Passenger)を3から6に更新する機会があったのですが、インストール方法やデプロイできるアプリケーションの種類の選択肢が増えていたのでまとめました。
また、今更Passengerを3->6に上げたり、Passengerを導入を視野に入れることは珍しいことかもしれませんが、Passenger関係の記事を調べると古い情報のものも多いため、ここの情報をもとに新しい情報を見つける助けにでもなれば幸いです。

なお、ここではPassengerやアプリケーションサーバについての詳しい説明は行いません。
Passengerについては公式ページ、Railsでのアプリケーションサーバの役割などは以下の記事が個人的に参考になったのでよろしければ参考にしてください。

3から6に上げた時の差分や動作の違いの参考としては公式のChangelogやGetting Startを見ています。

概要

導入面での話

• Passengerのgemインストール->ApacheやNginxのモジュールとして組み込む方法以外に、OSのパッケージとしてインストールする方法が増えた
• Ruby on Rails製のアプリ以外にPythonやNode.js製のアプリもデプロイできるようになった

運用面での話

• 再起動するコマンドなどが増えた
• Passengerがテレメトリーレポートを収集するようになった

導入面での話

Passegner3->6に上げるにしたがって、新規に環境構築などを行う必要があったためその時に感じた違いです。

インストール方法の選択肢が増えた

みなさん、Passengerを知っている人がいればこう思うかもしれません
「Passenger? アプリケーションサーバのことでしょ? なんかApacheだとまだ導入しやすいみたいだけど、NginxだとNginxビルドしなきゃいけないやつ..」
そうです。PassengerはApacheやNginxのモジュールとして動作するのですが、Nginxを使用する際はPassengerをモジュールとしてNginxをビルドする必要がありました。

Nginxをビルドするって言葉だけですごく心理的障壁が高くなりますよね...
こういったこともあり、Nginx+Passengerの組み合わせを回避するようなこともあったかもしれません。

しかし、Passenger(6.0.17)ではインストール方法の1つとして、OSのパッケージとしてインストール方法が増えていました。(ChangelogをさかのぼってみるとPassenger4系からこのようなインストール方法が増えていたみたいです。)
OSのパッケージとしてPassegner(正しくはPassengerのNginxモジュール)をインストールするとNginxと一緒にインストールされるようになっており、自らNginxをビルドする必要はなくなっていました。

例えばUbuntu22.04だと以下のコマンドでインストールは完了します参考

• パッケージインストール

  # Install our PGP key and add HTTPS support for APT
  $ sudo apt-get install -y dirmngr gnupg apt-transport-https ca-certificates curl
  
  $ curl https://oss-binaries.phusionpassenger.com/auto-software-signing-gpg-key.txt | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/phusion.gpg >/dev/null
  
  # Add our APT repository
  $ sudo sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger jammy main > /etc/apt/sources.list.d/passenger.list'
  $ sudo apt-get update
  
  # Install Passenger + Nginx module
  $ sudo apt-get install -y libnginx-mod-http-passenger
  

• NginxのPassengerモジュールの有効(とNginxの再起動)

  $if [ ! -f /etc/nginx/modules-enabled/50-mod-http-passenger.conf ]; then sudo ln -s /usr/share/nginx/modules-available/mod-http-passenger.load /etc/nginx/modules-enabled/50-mod-http-passenger.conf ; fi
  $sudo ls /etc/nginx/conf.d/mod-http-passenger.conf
  $ sudo service nginx restart
  

なお、自分が試した&確認したのはNginxの例だけですが、Apacheのほうも同じようにできそうでした。
ソースコードをビルドしていた時と比べだいぶインストールしやすいですね！

Ruby on Rails製のアプリ以外のアプリもデプロイできるようになった

PassengerはRuby on Railsのアプリ用のイメージを持っていたのですが、
最近はPythonやNode.js, Meteorを使ったアプリケーションにも使用できそうです。

調べたところこれらのアプリはつい最近追加されたわけではなく、早くてPassenger4系のbetaくらい(2013年ころ?)からサポートされていたみたいです。

最近はPassengerを使用するケースはあまりないかもしれませんが、機会があれば使ってみるのもいいかもしれませんね。

運用面での話

Passegner3で運用しているときと変わって考慮する必要が出てきた違いです。Changelogを見ているとこれ以外にも運用面に関することはあったとは思いますが、ここでは私個人に関係する範囲で記載しました。

再起動するコマンドなどが増えた

Passenger4系以降を触っている人にとっては何を言っているかわからないかもしれませんが、Passengerは3系(正確には4.0.31?) まで、restart.txtといったファイルを監視して、restart.txtのタイムスタンプが更新された際に再起動を行うような動作になっていました。(restart.txt動作の参考)
方法としては再起動したいタイミングで

$ touch restart.txt

とするものでしょうか、自分は初めて見た時にはこんな再起動方法があるんだと感動をおぼえておりました。

このような、再起動方法だったものが4系以降では

$ passenger-config restart-app

といったコマンドが増えてこちらを使用した再起動が推奨されています。
例としてRailsのアプリに対して再起動を行う場合以下のようになります。

$ passenger-config restart-app ${your-app-dir-path}

なお、一応現在でもrestart.txtを使用した再起動はできるみたいですが、passenger-config restartはコマンドが実行されたタイミングで再起動されるのに対し、restart.txtはファイルのタイムスタンプ更新後のリクエストが来たタイミングで再起動されるので注意が必要です。

Passengerがテレメトリーレポートを収集するようになった

テレメトリーレポートとは匿名の利用状況データのことです。WindowsでいうとMicrosoftに送信する診断データのようなものでしょうか。これがPassenger6.0.0よりデフォルトの設定で収集されるようになりました。

こちらについては、自分で使う分には「へぇ、そうなんだ」程度だと思うのですが、アプリの運用状況では少し不安になる更新内容です。
こちらに書いているようにもちろんセキュリティなどは考慮されているらしいのですが、やっぱり不安は残ると思います。

そこで、設定しておくといいのがNginxの場合passenger_disable_anonymous_telemetry(ApacheだとPassengerDisableAnonymousTelemetry)です。(詳細)
以上の設定をconfファイルなどで設定しておくとテレメトリーレポートの収集を無効化できるようです。

# 匿名のテレメトリーの無効化をonにする。何も書かないとデフォルトはoff(テレメトリー収集が有効)
passenger_disable_anonymous_telemetry on;

アプリ運用状況によっては結構重要な設定ですね。

おわりに

ここまで、個人的に大きな変更だと思ったものをまとめました。
3->6といった結構大きな差分だったので、確認するのは大変でしたが、運用方法などに影響するものもあってしっかり読んでいてよかったなと思いました。
最後にもし、間違いや指摘などありましたら教えていただけると幸いです。