入門書の次に読むRailsデプロイ

とあるきっかけから、監訳者の一人の橋本さんを通してオライリーさんからRailsデプロイRailsデプロイ[rakuten]をいただいた。Railsプログラミングがひと通りできるようになった、常用しているマシンの上で動作させてきた、自分以外の人々に向けたサービスをこれから始める。本書はそんな人々を助けてくれるだろう。

プライベートに運用するアプリケーションを除くと、普段は自分がログインすることがほとんどないようなマシンがアプリケーションを動かすための場になる。そのようなマシンは一つだけではなく、用途ごとに複数のマシンを並べて動作させることが多い。このようなマシン環境下でアプリケーション群を正常動作させ続けるには、いつも使っているマシンでアプリケーションを運用するのとは異なった視点・手法・作業が求められる。

たとえば、アプリケーションを動かすのに必要なハードウェア環境…… はともかくとしても、ソフトウェア環境を整えなければならない。それはRubyのインストールから始まるかもしれないし、もしかするとRubyをインストールするための環境作りから始まるかもしれない。また、HTTPサーバを設定しなければならないだろうし、複数あるマシンがうまく連携できるようにもするだろう。アプリケーションのリリースは複数のマシンが対象となる。マシンの用途が違えば作業も違う。そして、マシンを増やすことがあればそのたびにそれらすべてを行う必要がある。いきなりなにもかもやろうとすると大変だ。

本書を読むと、手元で動かす→他のある程度整備されたホストで動かしす→VPSを借りて動かす→専用ハードを借りて……、といった具合にじょじょに規模を拡大していく工程をひと通りながめることができる。その内容は単に「Railsアプリケーションをリリースする」というだけではなく、複数のマシンでサービスを運用するための機能分散の方法や負荷分散をするためのリバースプロキシの設定など広い範囲をカバーしている。

そのうえ、複数のデータベースを運用するためのMySQLの設定とアプリケーション側での対処、チューニングのためのベンチマークやプロファイルの取り方、キャッシュの使い方とキャッシュ乱用への注意など、アプリケーションをサービスとして運用するのに必要な領域についても実践的に解説する。そのような点から、アプリケーションを作れるようになり、さあこれからデプロイしようといったストーリーの入口で本書は活躍するだろう。

少々残念なのは、今この時期にPassengerが扱われていない点。もちろん出版時期などからいたしかたないところではあるのだが、カバーしている範囲の広さからすると実におしい。また、Railsからはやや離れたところでの説明や表現にはいくつかひっかかる点もあった。一つあげると125ページの「Linux上でRailsアプリケーションを動作させるためには……最低限でもCやC++のコンパイラ……が必要」といった記述で、これはRMagickなどをRubyGemsで運用することなどを前提にしているのであるが、できるならコンパイラは避けたいところと考える人も少なくないはずだ。(他のものも含めて出版社の方に伝えておいた。)

一方、本筋とやや離れたところでちょっと感心したのは、Apache HTTPサーバの設定作業の中で、a2enmodやa2dismodなどに触れている点だった(本書ではUbuntuを主な環境としている)。この種の特定のOS環境(この場合はDebian/Ubuntu)に独特な手順というのはともすれば流されてしまいがちである。もちろん明確な方針があって別のやり方で運用するのは構わない。だが、マシンはいつか自分の手を離れるものであるとすると、理由がなければできるだけその環境の流儀に従っておいたほうがよいと思う。考えてみればRailsだってそうなのだから、環境整備でも同じようにしたってよいだろう。

追記(2009-07-24)

読んでいてひっかかった点は編集さんに送ったが、そのうち正誤表に載っていないものや載らなそうなものを以下に挙げておく。

  • 56ページ15行目「コマンドラインに関する知識と何でもGoogleで検索してみる」
    • 「知識を何でも」?
  • 67ページ下から10行目「インストール中にどのような種類の設定を行うか聞かれたら"Internet site: ... "(メールはSMTPを使って直接送受信される)という選択肢を選んでください」
    • 他のところでメール関連のことを扱っているのかなとも思ったのだけど特別に前提条件はなさそうなので、本文の記述に従うと外部からアクセス可能なSMTPサーバをたてるということになりそう
    • となると、一般的な選択という点ではローカルホストのみで動作させるくらいにして、必要に応じてそのような設定をしよう、というような書き方のほうがよいのでは
  • 106ページ囲み
    • ファイルを/etc/init.dにコピーするだけでよいように読めるが一般にそのようなことはないはず
    • Debian系であればupdate-rc.d、Red Hat Linux系であればchkconfigでの操作が必要になる
  • 107ページ囲み「flexとbisonそしてbyaccをインストールしましょう」
    • flex、bison、byaccのうちのいずれか、ではないのかな
  • 110ページ15行目「Linuxシステムでは、initは/etc/init.dに置かれるすべてのスクリプトの実行を担当しています」
    • initはすべてのプロセスの祖先ですから間違いとはいえないが、 ここでいおうとしているinitの用法と /etc/init.d(より正しくは/etc/rc*.d)以下のファイルの運用はまた別だといっても差し支えないと思いう
    • /etc/init.d(略)以下のファイルにより起動したサービスは /etc/inittabで管理されるプロセスとは違ってinitにより再起動されることは通常ない
  • 110ページ訳注「sudo update-rc.d monit remove」
    • /etc/init.d/monitが残っている場合、update-rc.d -f monit removeとする必要がある
    • そうでなければrm /etc/init.d/monitした上でupdate-rc.d monit removeとする
  • 110ページ下から4行目「Monitを使ってMongrelを管理するようになったら…mongrel_cluster/recipesを使う必要はなくなりました」
    • mongrel_cluster/recipesが唐突に出てきている…… ような気がする
    • 読み落としてしまっただけかも(検索可能な何かがあればなあ)
  • 111ページ下から4行目「FastCGIのゾンビプロセス」
    • 「なぜか居残り続けてしまう、仕事をしないfastcgi管理下のプロセス」にすぎず、UNIX一般にはこのようなプロセスをゾンビとは呼ばないように思う
    • 実際、reaperはfastcgiプロセスに対してシグナルを送っているわけだけど、本来の意味でのゾンビプロセスはそもそもシグナルを受け取れる状態にない
    • 参考: プロセス - 終了状態
  • 117ページ15行目「ハートビート」
    • 外部から動いていることを確認すること自体をハートビートとはあまり呼ばないような気が
    • 一般的には生存証明を自らするようなものをそう呼んだり、あるいは、HAクラスタなどでサービスが動作していることを待機系とで情報交換するような仕組み全体を指すことはあると思う
    • いずれにしても本文で説明されているのはNagiosなどがするような監視であって、死活監視などと呼ぶほうが一般的ではないだろうか
  • 127ページ下から二行目「CNAMEレコードはAレコードのエイリアス(別名)のようなものです。対象のAレコードは自分のものでも他人のものでもかまいません」
    • DNSの「リソースレコード」と「名前」が混同されているように思える
    • CNAMEレコードでは名前に対応する正しい名前を定義する
    • CNAMEレコード全体をもってエイリアスと表現するのは間違いとまではいえないが、CNAMEレコードの対象がAレコードというのは表現としておかしいのではないか
    • 実際、CNAMEレコードを持つ「名前」に他のリソースレコードを付けてはならないことになっているはずで
  • 129ページ10行目「大きな値(例えば7日)を指定すると、ブラウザなどのクライアントソフトウェアがDNSに問い合わせを行う回数を削減でき」
    • 「クライアントソフトウェアがDNSに問い合わせを行う」というのはリゾルバの動作で、リゾルバの動作にはTTLはリゾルバの動作に影響を与えない…… のではないかしら
    • MS-Windowsなど、ある種の環境ではDNS問い合わせについてのキャッシュ機構があるようだが、それらを考えにいれたとしても実装依存というのがやっとだと思う(MS-Windowsの機構はキャッシュサーバの一種なのではないかしら?)