いんふら屋の仕事なのかと問われると実は相当に怪しい話なのだが。
沙耶です。
お仕事で閉塞ローカルな環境でRoRでの構築用インフラを作ってくれと。
アプリ屋さんのほうからは特に何も言ってこないので、ぶっちゃけRails環境なんか自前で作れよばーかばーか。とか思ったりするのですが、要件にPassengerでの起動が含まれていまして。
アプリサーバって立ち位置が微妙すぎて正直嫌いなんだけどな。
まあいいや。Passengerまでは入れておいてやろう。とか思ったわけです。
まーね。RoRなんてろくろく触ってないしね。よく知らないけどあれだろ。bundler入れてbundle installすればいいんだろ？
くらいの感覚。とりあえず閉塞なので、手元環境でガスガスとpassenger環境を構成。bundle installでごっそり持ってこさせて、まとめてgemfile作って、bundle packageでvender/cacheを生成。
よーしOK。あとはこれを送りこんでしまえばOKだ。
ココまでは大変順調に進んだ。まあひとしきりめんどくさかったといえばめんどくさかったのだが。
話を聞けばとりあえずbundle install –path vender/cacheでいい。っていうからそのとおりにしてみる。Gemfile作り忘れてた。
まあ一回入れちゃえばあとはどうとでもなる。
さて、Railsの動作確認しねーとなー。passengerは動いてるからこのまま放置でもいいけど、Hello Worldくらい出したいじゃん。まさか動作確認のためにRedmine入れるとかやりたくないしｗ 絶対依存関係でえらい目にあいそうだし。
おもむろにrails newして見る。
config …
config …
config …
bundle install
は？ お前ちょっと待てこら。何おっぱじめてんだてめぇ。
結局その後あれも足りないこれも足りないとか言われる。足りない理由がrails server起動のためのWEBrickのためのもので、まったく使わないとかいう現実。
でも動作確認はしたいので送り込んでインストール。
あのさぁ。これどうするのが正解なの？ Rubistに聞きたいんだけど。
ローカルにGemのRepository全部syncしてそこを参照しておくのが正解だったりすんの？もしかして。せめて最小限必要なパッケージくらいまとめたrpmなりdebなり作っておこう、って気は無いの？
ただでさえいい印象が無いのに、Rubyは一体どこへ向かっているの。
同じことはphpのpearやpythonのpip、perlのCPANにも本来はいえることなのだけど、perlのCPANなんてrpmへの変換がそのまま行えるのでrpmのリポジトリにその主要なものはほぼ結合してしまっている。
pythonもその伝統をある程度受け継いでいるので、少しずつだけどpythonモジュールもrpmツリーのなかにいる。もちろん、rpmのパッケージツリーをsyncしてるわけじゃないけど、yumdownloderで一気にシステムの依存関係とあわせて解消して目的のサーバに持ち込める（そしてインストールもyumで済む）。
phpもrpmリポジトリの中にあるよね。
無いのはruby、君だけなのよ。なんのポリシーなのか知らないけどさ。どうして同じことができないの？ しようとしないの？
これはrubyの問題なの？ それとも僕らインフラがrpm作らないからだろ？って主張なの？
よくわかんないんだけどさ。僕らインフラはRubyなんて使わないのよ。正直、Passengerすらなんで俺が？って思ってるよ？こんなのアプリが入れろよ。だって定義すべき要素はすべてアプリのパスだぜ。
サーバデザインとなんの関係も無い環境変数だぜ？ アプリのホーム以下をどう使いたいか、なんてアプリの設計だろう？
なんで俺らがそのためのパッケージを定型化して作れると思うの？ rpmなりdebなりってそのデフォルトパスまで定義しなきゃいけないのに、それはアプリが好き勝手決めたいって要素じゃん。え、/var/wwwとかにアプリホーム作っていいの？ ftpもつながんないけどいいの？
だったらこれの作成はアプリ作る連中が便利と思うか思わないか、って話なんだよね。
つまり、別に不便だと思ってねぇってわけだ。てことは、逆に言えばインフラはそこに手を出さなくていいんじゃないかな。アプリの連中は不便だと思ってないんだから。
だから僕らが一生懸命gemを入れてあげる必要は無いんだ、きっと。
じゃあpassengerが動くこと。ってのはインフラ要件じゃないよこれは。だってgemで入れるものなんだもの。
「アプリ」が「インフラの用意したapacheの上に」Passengerを構築する。んだ。たぶん。
それがたぶん正しい。インフラにとってPassengerはアプリケーションとして認識すべきものだ。
入れるのにLoadModule書かなきゃいけないけど、それでも。それがたぶんRubyの正しさ、なんだと思う。
ならばpassengerはインストール時に「自分で」「ちゃんと」「Apacheなりnginxなりを」構成しなさいよ。sudoくらい吐けばいいじゃない。loadmoduleするだけでしょうが。
パスは.htaccessにでも書けよ。それをしない、のはどうして？
結局今のままじゃapacheの正しさ、とかお作法、とかとコンフリクトするんだけど、どっちかが折れなきゃどうにもならんじゃん。インフラが心配してあげるってのはアプリを甘やかしすぎなんじゃないかな、って最近思うよ。
ましてrubyのモジュールなんてさ。インフラがRuby使うわけ無いだろ。使うと思ってんの？
perlとpythonあれば事足りちゃうんだよ。まあ、Chefで使うしvagrantでも使うだろって言うけどさ。
vagrantは表からruby見えないようになってるよ。Chefだってテンプレート書くのに要るだけだし、Chefを入れるサーバが閉塞ネットワークに入ったりするわけ無いだろ？ それは構築支援環境であって実行環境じゃないんだよ。だいたいPythonのpuppetもあるしさぁ。
実行環境を作るための要素があやふやなんだよ。よくわからない。何がしたいのか。実行環境と開発環境なんかの支援がごたまぜ過ぎるんだよ。Javaみたいにそれならそれで切り分けろよ。JRE入れとけばいいです。で済ませろよ。どうしてできないのだろう。設計思想の問題？
そう思っていろいろ調べてたら、閉塞ネットワークでRoR使うなとか書いてある。理由：めんどくさいから。
酷い話ｗｗｗｗｗｗｗ
正直に言えば、Rubyはそもそもその成立理念から設計理念までをそんなに詳しく知らないんだ。なぜそうなっているのか、にはきっと理由があるんだけど、その理由はきっとインフラ屋さんとは関係ない、アプリ製作の独りよがりで作られたような気がしているんだよね。
それならそれでかまわないんだけど、ならインフラの領域に土足で入るようなマネはするべきじゃないんじゃないのかなぁ。それがお作法なんじゃないのかなぁ。まあこんなのSystemdのdebug議論と同じで水掛け論なのかもしれないけど。
そもそもインフラとアプリ、って考えてる僕が古臭い、といわれればそれまでだよ。
動作確認のためのWebrickだと思うけど、だとしたらそれはデフォルトで入るべきものなのだろうか？
RoRの実行環境としてインフラがPassengerを用意するとしたら、そこにデプロイするアプリにWebrickが必要か？ 僕はそうは思わない。それは依存関係じゃない。
Ruby流儀ってのがあるのは理解できる。
でもそれを他の流儀との迎合は真っ平ごめん、俺は俺の正しさをもって日和りはしない！って主義ならそれはそれで結構。
でもだとしたら、その流儀はあらゆる環境をサポートできるような流儀でなくてはならないよ。
オフラインに展開するのに、どうして一発で必要なものがそろわないんだ？
Passengerが動作する＝Railsの動作環境、ではないのかな。
どうしてPassengerが稼動できる状態において、railsのスケルトン作成が失敗するのか、それは異質だとは思わないんかなぁ。僕は少なくともそれはすごくおかしなことだと思うのだけど。
ぐだぐだ書いてるけど結局今も正解ってもんはわからない。アプリケーションサーバってそういう立ち位置のものだと思っているから。
それでも、うだうだしながらもVMのようなサンドボックスを見てると、Rubyは異質に感じてしまう。結局インフラとアプリの間に線を引きたいのか引きたくないのかよくわからんのだ。
引きたいなら引きたいでかまわない。それならその閉じた世界を作って欲しい。
引きたくないなら引きたくないで、インフラのお作法に「も」迎合して欲しい。
別に自分たちの流儀を否定はしないよ。それはそれで作ればいい。でもインフラの流儀にも沿ったものを別途用意してくんないかな？ え、それはてめえがやれ？ だからそれはさっき言ったじゃん。君らの作ってるものはインフラで決定できないことの塊だよ。
どっちもいやだ俺は俺の道を逝く。ってやられたらそりゃあ不満も出るよ。一体これはどこへ向かってるんだよ…。誰のための、何なんだよ、お前。開発者のための、開発者による、開発者たちだけのRubyとRailsだっていうなら。インフラなんて存在しないんだっていうなら。
Webrickで全部やるべきだ。apacheやらに甘えるな。必要ならwebrickにプロキシ張るから、それでいいだろ。パフォーマンスが！とか言うなよ。それならWebrickをチューンしろ。nginxにも甘えるのも微妙。本来は、それがたぶん目指すべき正しさだと思うぞ俺は。
