{"componentChunkName":"component---src-templates-post-template-js","path":"/posts/why-puma-daemonization-removed","result":{"data":{"markdownRemark":{"id":"e850900e-60da-537b-bd28-7f651564d80d","html":"

Puma は Ruby のアプリケーションサーバの一種であり、Ruby on Rails がデフォルトで使用していることでも有名です。

\n

そんな Puma をサーバにデプロイする方法を調べていると、一昔前まではデーモン化 (Daemonization) する設定があったそうですが、現在はその設定が廃止されていました。

\n

そこで

\n\n

を調べたところいろいろ勉強になったので、記事としてまとめます。

\n

前提

\n

Puma とは？という方には、Ruby における Web サーバとアプリケーションサーバについて説明している以下の翻訳記事が分かりやすくてオススメです。

\n\n

Puma をデーモン化する設定はなぜ廃止されたのか

\n

Puma の GitHub リポジトリの History.md によると、

\n
\n

5.0.0 / 2020-09-17

\n

:

\n\n
\n

ということで、デーモン化の設定はバージョン 5.0.0 で削除されています。

\n

その理由などは、#2170 のプルリクエストに対応する issue (#1983) で議論されています。

\n

この議論の中では、デーモン化機能の削除の理由として Don’t Daemonize your Daemons! | Mike Perham という記事がリンクされています。

\n

この記事から重要な点をいくつか引用させていただくと、

\n
\n

Your application code should not be dealing with PID files, log redirection or other low-level concerns.

\n
\n
\n

Let your operating system handle daemons, respawning and logging while you focus on your application features and users.

\n
\n

とのことで、要するに、「PID ファイルの管理やログのリダイレクトといった低レベルの関心事はアプリケーションで扱うべきではなく、デーモン化やリスポーン・ロギングといった機能は OS に任せて、アプリケーションの開発者は機能やユーザに注視するべき」ということです。

\n

この記事に書かれている通り、自前のコードでデーモン化を実現しようとすると、ログローテーションなど多くの考慮事項ができてしまいます。

\n

systemd などの提供する方法でデーモン化すれば、そういった考慮事項が減るので、systemd などを使ってデーモン化するべきということです。

\n

systemd を使うことで、例えばログは単に標準出力に出せばよくなり、The Twelve-Factor App にもある移植性の高いアプリケーションの設計プラクティスを満たすこともできます。

\n

なお、Puma を systemd で管理する際の設定については、docs/systemd.md に書かれています。

\n

代替手段の puma-daemon によるデーモン化はどのように実現されているのか

\n

さて、このような理由で Puma のデーモン化設定は廃止されたわけですが、代替手段として puma-daemon という gem が作られました。

\n

この gem を使ってデーモン化する方法が systemd でのデーモン化とどう違うのか、コードを追いかけてみます。

\n

※ CRuby、glibc とコードを見ていきます。この辺りのコードは読み慣れていないので、もし間違いなどあれば Twitter などでご指摘いただけますと幸いです

\n

puma-daemon の該当箇所

\n

puma-daemon のコードをなんとなく探ってみると、どうやら ここ で

\n
\n

Process.daemon(true)

\n
\n

と、Ruby の組み込みライブラリの関数 Process.daemon が呼ばれており、この処理でデーモン化しているようです。

\n

Ruby の Process.daemon の該当箇所

\n

もう少し詳しく知りたいので、Ruby (CRuby) の実装を追いかけてみようと思います。

\n

GitHub の ミラーリポジトリ を見てみると…

\n

process.c の この箇所 で

\n
\n

err = daemon(nochdir, noclose);

\n
\n

のように、daemon という関数が呼ばれています。

\n

※ daemon という関数が呼ばれるのは #ifdef HAVE_DAEMON が満たされた場合のみです。そうでない場合については別の方法でデーモン化されているようです

\n

glibc の該当箇所

\n

Man page of DAEMON によると、daemon は、C 言語の標準ライブラリの関数のようです。

\n

そこで標準ライブラリの代表的な 1 つである glibc のコードを見てみようと思います。

\n

GitHub の ミラーリポジトリ を見てみると、daemon.c に以下のように実装されているようです。

\n
int\ndaemon (int nochdir, int noclose)\n{\n    int fd;\n\n    switch (__fork()) {\n    case -1:\n        return (-1);\n    case 0:\n        break;\n    default:\n        _exit(0);\n    }\n\n    if (__setsid() == -1)\n        return (-1);\n\n    if (!nochdir)\n        (void)__chdir(\"/\");\n\n    if (!noclose) {\n        :\n        :\n        :\n    }\n    return (0);\n}
\n

このコードの一番重要な処理は以下の箇所です。

\n
    switch (__fork()) {\n    case -1:\n        return (-1);\n    case 0:\n        break;\n    default:\n        _exit(0);\n    }
\n

glibc のコードの読み方に確信が持てないですが、おそらく __fork() は fork というシステムコール を読んでいるのではないかと思います。

\n

fork システムコールはその戻り値によって親プロセスと子プロセスで処理を分岐することが多いのですが、上記の switch 文はまさにその典型です。

\n

子プロセスは case 0 に進み、以後の処理を継続し、アプリケーションサーバとして動きます。

\n

一方、親プロセスは戻り値として子プロセスの PID を受け取るため、default に進み、exit します。

\n

『詳解 Linuxカーネル 第3版』p32 によると、

\n

\"\"

\n
\n

プロセスが終了する際、カーネルは終了するプロセスの子プロセスすべてに関して、init の子になるように適切なプロセスディスクリプタのポインタを変更します。

\n
\n

とのことで、親プロセスがいなくなったことで子プロセス (アプリケーションサーバのプロセス) は init の子プロセスになり、デーモン化が完了したわけです。

\n

※ Linux 以外でも同様の挙動になるかは調べていません

\n

結局 puma-daemon でのデーモン化と systemd でのデーモン化はどう違うのか

\n

話がだいぶ込み入ってしまいましたが、ここまで読んできたコードからすると、

\n\n

ということです。

\n

結局どうするのがオススメか

\n

最後に、では結局どうするのがオススメかをまとめようと思います。

\n

そもそもデーモン化を気にする必要があるか

\n

そもそも論として、最近のクラウド環境を踏まえると、サーバに直接 Puma をデプロイすることはオススメしません。

\n

Heroku などの PaaS や、Fargate などのコンテナ環境を使うのが第一候補になります。

\n

これらのプラットフォームを使う場合は、デーモン化について気にする必要はありません。

\n

サーバにデプロイする場合

\n

デーモン化を気にする必要があるのは、PaaS やコンテナを使わず、サーバに直接デプロイする場合です。

\n

その場合、この記事の内容を踏まえると、systemd などを使ってデーモン化する方が望ましいと言えます。

\n

puma-daemon によるデーモン化は、あくまで簡易的な代替手段と考えるのが良さそうです。

","fields":{"slug":"/posts/why-puma-daemonization-removed","tagSlugs":["/tag/ruby/","/tag/rails/"],"autoRecommendPosts":["ruby-and-rails-books","what-is-installation","487311313X","4839975868"]},"frontmatter":{"date":"2021-07-04T11:16:36.214Z","description":"「Puma をデーモン化する設定はなぜ廃止されたのか」、「代替手段の puma-daemon によるデーモン化はどのように実現されているのか」を調べたところいろいろ勉強になったので、記事としてまとめます。","tags":["ruby","rails"],"title":"Puma の Daemonization が廃止された理由と、デーモン化したいときはどうするべきか","socialImage":null,"recommendPosts":["https://www.kanzennirikaisita.com/posts/ruby-and-rails-books","https://www.kanzennirikaisita.com/posts/software-developer-books-index"]}}},"pageContext":{"slug":"/posts/why-puma-daemonization-removed"}},"staticQueryHashes":["251939775","3942705351","401334301"]}