Railsアプリケーションをデプロイする前に、どんな小さなことをする必要があるかという質問では、「小さなこと」よりも大きな答えがたくさんあります。したがって、この質問は少し異なります。
Rails アプリケーションをデプロイする前に、どのような主要な手順を実行する必要がありますか。この場合、5 分以上かかるので、スケジュールする必要があることを意味します。小さなワンライン構成の変更については、ささいなことの質問を使用してください。
Railsアプリケーションをデプロイする前に、どんな小さなことをする必要があるかという質問では、「小さなこと」よりも大きな答えがたくさんあります。したがって、この質問は少し異なります。
Rails アプリケーションをデプロイする前に、どのような主要な手順を実行する必要がありますか。この場合、5 分以上かかるので、スケジュールする必要があることを意味します。小さなワンライン構成の変更については、ささいなことの質問を使用してください。
Capistrano をセットアップしてデプロイする まだ知らない場合は capistrano を学び、自動化された方法でコードをデプロイするために使用します。これには、共有ディレクトリと、database.yml などの共有リソースの設定が含まれます。
C ベースの MySQL gem をインストールする 必要なすべてのライブラリがない場合、これには少し時間がかかりますが、20 分未満です。
セッション固定化、セッション ハイジャック、クロスサイト スクリプティング、SQL インジェクションなどの一般的な Web アプリケーション攻撃に対して脆弱ではないことを確認してください(おそらく、SQL インジェクションについてあまり心配する必要はありません)。ビュー画面でユーザーが入力したデータを出力するときは、必ず h() を使用してください。これについては、オンラインで多くの優れた資料があります。
サーバー アーキテクチャを選択してください Nginx、Mongrel、FastCGI、CGI、Apache、Passenger から選択できます。アプリがどのように使用されるかを考え、最適なアーキテクチャを決定してから、セットアップします。
Exception Notifier または Exception Logger を設定する アプリが壊れたときに警告を表示する必要があります。これらのツールのいずれかを設定して、生産例外を追跡します。注: 例外通知機能は、ルーティング エラーが発生した場合に警告します (例: ファット フィンガー URL やスクリプト キディが攻撃した場合)。そのため、エラーが発生したときにフレームワークに何をさせたいかを考え、それに応じて調整してください。
すべてのパスワードがソース管理外にあることを確認してくださいdatabase.yml、mail.yml (yaml_mail_config を使用している場合)、またはその他の機密ファイルがソース管理にある場合は、それらをそこから取り出して、database.yml.example に置き換えます。それらをサーバーの shared/ フォルダーに配置します。
DB がロックダウンされていることを確認します。多くの人は、新しい実稼働用 Rails ボックスをセットアップするときに、MySQL を保護することを忘れています。彼らのようにならないでください。
すべての小さな Web ファイルが配置されていることを確認します。Google にリストされる予定がある場合は、sitemap.xmlファイルを生成します。を使用する予定がある場合は、. 何かのhtaccessファイルがある場合は、そこにあることを確認してください。サイトの特定の領域がインデックスに登録されないようにするためにrobots.txtファイルが必要な場合は、作成してください。見栄えの良い404 Pageが必要な場合は、正しく設定されていることを確認してください。デプロイ時に「すぐに戻る」ページを表示したい場合は、Capistrano メンテナンス ファイルが指定されていることと、Nginx または Apache がそのファイルにリダイレクトする方法とタイミングを認識していることを確認してください。
SSL 証明書を用意する SSL を使用する場合は、本番ドメインで有効な証明書を取得して設定してください。
プロセス (多くの場合雑種) が停止したり、その他の悪いことがプロセスに発生したりすることがあります。たとえば、メモリ リークにより、メモリ消費量が無期限に増加したり、プロセスがすべての CPU を使用し始めたりする可能性があります。
monitとgodはどちらも、この運命からあなたを救うための良い選択です。サイトの URL にアクセスして 200 レスポンス コードをチェックするように設定することもできます。
このスペースでのいくつかの提案: fiveruns、newrelic、scout
これらのツールは、サーバー上の詳細なメトリックを記録し、何か問題が発生して実際に何が起こったのかを確認する必要がある場合に非常に役立ちます. また、サーバーの負荷に関するリアルタイムの情報も提供します。
クラスタがある場合、この種のレポートはさらに重要です。
データベースと、ユーザーがアップロードできるその他のアセットを定期的にバックアップするスクリプトを作成します。これには S3 が適しているかもしれません。
私の好みのサーバーはnginxですが、一般的なパターンはapache + mod_proxy_httpから始めることです。