Linuxでの新しいRails展開のベストプラクティスですか？
https://stackoverflow.com/questions/280155
-
07-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私はまっすぐなMongrelを使用し、Apacheの背後でMongrelクラスターを使用し、Thinを見て、Passengerに非常に興味を持ち始めています。私もNginxを見ました。 MRI、Ruby Enterprise Edition、Rubinius、およびJRubyを見てきました。多くのオプションがあり、それぞれが新しい聖杯であると主張しています。
まったく新しい最新の展開に最適なオプションは何ですか？唯一の前提はこれです：
- アプリはRails 2.2ベースです。 （2.2はまだ完全にはリリースされていませんが、この展開もそうではありません。）
- サーバーはLinuxベースです。おそらくUbuntu Hardyですが、実際には、この場合に最適なものは何でも。
- レールは完全に機能する必要があり、おそらくMySQLデータベースと通信する必要があります。
- その他はすべて交渉可能です。
これらの特に広範な制約がある場合、同時実行性と低いオーバーヘッドの観点から、どのソフトウェアの組み合わせが最良の結果をもたらすでしょうか？
「ワーカー」でApacheに傾倒していますmpmおよびPassenger + Ruby Enterprise Edition。セットアップとメンテナンスの即時の安定性とシンプルさを提供するからです。
別のオプションを使用した方が特に良いでしょうか？
解決
2週間前にMongrel ClusterからPassengerに切り替えました（Debian Linux Server）。私は一瞬振り返りませんでした。 Passengerは、おそらく新しいサーバーを稼働させる最も簡単な方法です。パフォーマンスと信頼性も合理的です。
個人的には、デプロイメントの問題を扱うのではなく、エキサイティングな新しいRailsプロジェクトに時間を費やすのが好きです-Passengerを使えば、まさにそれを行うことができます。ただし、なんらかの特別な要件がある場合は、Mongrelまたは他の何かが依然として望ましい場合があります（ほとんどの製品には適用されません）。
他のヒント
今朝、DHHは彼自身のブログでこのトピックについて語っています：
しかし、どういうわけかPassengerのメッセージは沈み込むのが少し遅かった。すでにそこにはたくさんの大きなサイトが走っている。 Shopify、MTV、Geni、Yammerを含め、すぐに最初のTa-daリストに移動し、その後すぐに37signalsスイートの残りの部分を移動する予定です。
したがって、手動で構成されたピースの独自のカスタム多層セットアップを実行する理由はまだありますが、特定の理由でmod_phpから遠ざかる人がいるように、最終的にデフォルトの答えに落ち着いたと思います。 Railsアプリケーションの最初のデプロイについて本当に考える必要のない何か。そのまま使用できるもの。そのボックスが共有ホストであっても！
http：//www.loudthinking .com / posts / 30-myth-1-rails-is-hard-to-deploy
Tobias L＆＃252; Shopify（1日あたり100万リクエスト）をPassengerに切り替えるトピックについて：
これは、Shopifyが通常の操作中に使用するメモリの合計量が平均9GBから平均5GBになったことを意味します。節約をより多くのShopifyプロセスとより多くのmemcachedスペースに均等に配分し、平均レスポンスタイムを210ミリ秒から130ミリ秒に移動させましたが、トラフィックはここ数か月で30％増加しました。
結論：現時点では、別の展開戦略を選択する理由はありません。シンプル、完全、高速、そして十分に文書化されています。
古い標準のnginxを使用してきました-＆gt;過去18か月間、Mongrelスタックを使用しました。初めてセットアップするのは簡単ではありませんでしたが、柔軟性が実証されており、非常にトラフィックの多いサイトに対処しました。特にNginxは非常に堅牢で高速であり、アプリのページキャッシュを取得できれば、多くのリクエストに対処できます。
立ち往生しているモングレルは問題であるため、monitを使用して、誤動作したときにそれらを殺します。繰り返しになりますが、設定するのはまったく簡単なことではありませんでしたが、この時点で多くの多くのサイトで同じプロセスを使用しました。
私たちはまだ乗客と遊んでいないので、おそらくそれはより簡単で安定しています、その上で他のレスポンダーに先送りします。 nginxとmongrelでスタックします。
NginX + MongrelをPassengerに切り替えました。
NginXとMongrelのクラスターが非常に優秀な人々に支持されているにもかかわらず、旅客は鉄道の新しい標準になると確信しています。乗客の最近の進歩は、それを本当に前進させました。
現在の設定は次のようなものです：
Webサーバー
- Ubuntu 8.04 LTS
- Apache2のPhusion Passenger
- MRI Ruby 1.8.6およびフレンド（フォームapt）
- Ruby Gems 1.3.0（ソースからインストール）
データベースサーバー
- Centos 5
- MySQL Cluster（これに切り替えたばかりですが、有望です）
正確なLinuxディストリビューションで標準化されているため、展開を支援するためにCapitranoレシピを記述できました（構成のわずかなバリエーションが多くのサービス停止の原因でした）。
Litespeed をご覧ください。 1 cpuで実行される無料バージョンを入手するか、マルチCPUを入手するために料金を支払うことができます。それは少し高価ですが、堅実でレールをきちんと処理します（つまり、使用するメモリが少なく、監視とセットアップのオーバーヘッドが少なくなります）。膨大な量のアプリを実行していますが、見逃すことはありません。
また、Mongrelからmod_passengerに切り替えたところ、セットアップとメンテナンスに必要なこの作業により、安定性が大幅に向上することがわかりました。良い選択。
もう1つの金：
Josh Peekの Slicehost gem には、Deprecよりもはるかにシンプルで整理されたCapistranoレシピが満載です。 。特にSlicehost固有のものもありません。
Ubuntu HardyでApache2とPassengerを使用して新しいアプリをホストしています。ほとんどのシナリオで最も簡単で最適なオプションのようです。そのためにSlicehost.comに参加しました。彼らは良い評価を得ており、ファーストクラスのホストの中で最も競争力のある価格を持っているようです。
私は新しいクライアントであるため、まだ実際に支持することはできませんが、ガイドのセットとサポートオプションの範囲は印象的です。
言及していないのは、アプリの大きさと人気です。この基準は、決定プロセスに影響を与える可能性があります。
Capistrano + Ubuntuでスタックを実際に設定し、展開を物理的に管理することを非難します。
サーバーアーキテクチャ用のMongrelクルーダーへのNginxプロキシ。これは最新の最先端技術ではありませんが、うまく機能し、十分に文書化されており、小さなVPSで作業している場合でも非常に高いパフォーマンスを発揮します。アプリケーションを中断していないと仮定すると、128 MBのSlicehost VPSをSlashdotすることができ、それがさらに戻ってきます。
そのことを言った：Nginxが実際にどのように機能するかを理解するまで、最初にいくつかの落とし穴がありました。その後、驚くべきことです-少しロシア語のアクセントを持つ小さなアパッチレットのように。
