デプロイ
デプロイの前に
ウェブアプリケーションを公開する前に、いくつかの質問を検討する必要があります。
- 予想されるトラフィックはどの程度ですか？
- サービスレベルアグリーメント（SLA）など、アップタイム保証を契約上満たす必要がありますか？
- どのようなユーザーエージェントがインフラストラクチャにアクセスしますか？これらには、以下が含まれる可能性があります。
- デスクトップウェブブラウザ
- モバイルウェブブラウザ（フォームファクタは？タブレット？携帯電話？両方？)
- スマートテレビやゲーム機からの組み込みブラウザ
- Android/iOS/Windows Phoneアプリ
- PhoneGap/Electronアプリ
- 開発者（cURL、Postman、AJAXリクエスト、WebSocketフロントエンドアプリ)
- その他のデバイス（テレビ、時計、トースターなど…)
- どのようなものをリクエストしますか（例：HTML、JSON、XML）？
- Socket.ioを使用したリアルタイム機能（例：チャット、リアルタイム分析、アプリ内通知/メッセージ）を活用しますか？
- クラッシュとエラーはどのように追跡していますか？ホスト型サービス（Papertrailなど）と組み合わせて
sails.log()を使用していますか？ NODE_ENV環境変数を「production」に設定して、ローカルで起動してみましたか？（これを簡単にテストするには、NODE_ENV=production node app（またはショートカットとしてsails lift --prod）を実行します）。
本番環境向けアプリの設定
本番環境でのみ適用される設定をいくつかの方法で提供できます。ほとんどのアプリでは、環境変数とconfig/env/production.jsを組み合わせて使用しています。どちらの方法を使用する場合でも、このセクションとドキュメントのスケーリングセクションでは、本番環境に移行する前に確認する必要がある設定について説明しています。
単一サーバーへのデプロイ
Node.jsは非常に高速です。多くのアプリでは、少なくとも最初は、1台のサーバーで予想されるトラフィックを処理できます。
このセクションでは、単一サーバーでのSailsデプロイに焦点を当てています。この種のデプロイは、スケールにおいて本質的に制限されています。ロードバランサーの背後にSails/Nodeアプリをデプロイする方法については、スケーリングを参照してください。
多くのチームは、ロードバランサーまたはプロキシ（HerokuやNowなどのPaaS、またはnginxサーバーの背後）の背後に本番アプリをデプロイすることを決定します。これは、スケーラビリティのニーズが変化し、サーバーを追加する必要がある場合にアプリの将来性を確保するのに役立つため、多くの場合適切なアプローチです。ロードバランサーまたはプロキシを使用している場合は、以下のリストにあるいくつかの項目を無視できます。
- SailsがSSL証明書を使用するように設定する必要はありません。SSLはほとんどの場合、ロードバランサー/プロキシサーバーまたはPaaSプロバイダーで解決されます。
- （プロキシ（nginxなど）の背後でない場合）ポート80でアプリを実行するように設定する必要はないでしょう。ほとんどのPaaSプロバイダーは、ポートを自動的に判断します。プロキシサーバーを使用している場合は、そのドキュメントを参照してください（Sailsアプリのポートを設定する必要があるかどうかは、設定方法によって異なり、ニーズに基づいて大きく異なる可能性があります）。
アプリがソケットを使用しており、nginxを使用している場合は、nginxがサーバーにWebsocketメッセージを中継するように設定してください。WebSocketsのプロキシに関するガイダンスは、nginxの該当するドキュメントで見つけることができます。
NODE_ENV環境変数を'production'に設定します。
アプリの環境設定を'production'に設定すると、Sailsは本番環境で実行されていることを認識します。これは間違いなく最も重要なステップです。Sailsアプリをデプロイする前に1つの設定のみ変更できる時間しかない場合、これがその設定であるべきです！
アプリが本番環境で実行されている場合
- Sailsに組み込まれているミドルウェアやその他の依存関係は、より効率的なコードを使用するように切り替わります。
- すべてのモデルの移行設定が
migrate: 'safe'に強制されます。これは、デプロイ中に本番データを誤って破損するのを防ぐための安全策です。 - アセットパイプラインは本番モードで実行されます（該当する場合）。すぐに使用できる状態では、Sailsアプリはすべてのスタイルシート、クライアント側のスクリプト、プリコンパイルされたJSTテンプレートを、ミニファイされた
.cssおよび.jsファイルにコンパイルして、ページの読み込み時間を短縮し、帯域幅の消費量を削減します。 res.serverError()からのエラーメッセージとスタックトレースはログに記録されますが、レスポンスには送信されません（これは、攻撃者が暗号化されたパスワードやSailsアプリがサーバーのファイルシステム上のどこに配置されているかなどの機密情報にアクセスするのを防ぐためです）。
注：
sails.config.environmentを別の方法で'production'に設定しても問題ありません。SailsはNODE_ENV環境変数を自動的に'production'に設定するか、警告をログに記録しますので、コンソールを確認してください。この環境変数が非常に重要である理由は、使用しているフレームワークに関係なく、Node.jsの普遍的な慣例であるためです。Sailsの組み込みミドルウェアと依存関係は、本番環境でNODE_ENVが設定されていることを期待しており、そうでない場合は、開発でのみ使用するために設計された、効率の低いコードパスを使用します。
sails.config.sockets.onlyAllowOrigins値を設定します。
アプリでソケットを有効にしている場合（つまり、sails-hook-socketsモジュールがインストールされている場合）、セキュリティ上の理由から、sails.config.sockets.onlyAllowOriginsを、Websocketを介してアプリへの接続を許可するオリジンの配列に設定する必要があります。これは、アプリのconfig/env/production.jsファイルで設定するのが一般的です。onlyAllowOriginsの詳細については、ソケット設定のドキュメントを参照してください。
アプリがポート80で実行されるように設定します。
sails_port環境変数を使用するか、--portコマンドラインオプションを設定するか、本番環境の設定ファイルを変更するかに関係なく、Sails設定の最上位レベルに次の行を追加します。
port: 80
前述のように、アプリがロードバランサーまたはプロキシの背後で実行される場合は、このステップを無視してください。
モデル用の本番データベースを設定します。
アプリのすべてのモデルがデフォルトのデータストアを使用している場合、本番データベースの設定は、config/env/production.jsファイルでsails.config.datastores.defaultを正しい設定で設定するほど簡単です。
アプリが複数のデータベースを使用している場合、プロセスは同様です。アプリで使用されるすべてのデータストアについて、config/env/production.jsのsails.config.datastores辞書に項目を追加します。
バージョン管理（たとえばgit）を使用している場合、アプリの設定ファイルに機密情報（データベースパスワードなど）を含めると、リポジトリにチェックインされます。この問題に対する一般的な解決策は、特定の機密設定を環境変数として提供することです。詳細については、設定を参照してください。
MySQLなどのリレーショナルデータベースを使用している場合は、追加のステップがあります。本番環境で実行されている場合、Sailsがすべてのモデルをmigrate:safeに設定する方法を覚えていますか？つまり、アプリの起動時に自動移行は実行されません...つまり、デフォルトではテーブルが存在しません。Sailsアプリのリレーショナルデータベースの初回設定時にこれに対処する一般的なアプローチを以下に示します。
- 本番データベースサーバー（例：
frenchfryparty）にデータベースを作成します。 - この本番データベースを使用するようにローカルアプリを設定しますが、環境を
'production'に設定せず、モデルの設定をmigrate: 'alter'のままにします。ここでsails liftを一度実行し、ローカルサーバーの起動が完了したら終了します。- 注意！これは、本番データベースにデータがない場合にのみ実行してください。
これが不安な場合、または本番データベースにリモートで接続できない場合は、上記のステップをスキップできます。代わりに、ローカルスキーマをダンプして、本番データベースにインポートします。
CSRF保護を有効にします。
CSRFからの保護は、Sailsアプリにとって重要なセキュリティ対策です。すでにCSRF保護を有効にして開発を行っていない場合は（sails.config.security.csrfを参照）、本番環境に移行する前にCSRF保護を有効にするようにしてください。
SSLを有効にします。
APIまたはWebサイトで認証を必要とする操作を実行する場合は、本番環境でSSLを使用する必要があります。SailsアプリでSSL証明書を使用するように設定するには、sails.config.sslを使用します。
前述のように、アプリがロードバランサーまたはプロキシの背後で実行される場合は、このステップを無視してください。
アプリを起動します。
デプロイの最後のステップは、実際にサーバーを起動することです。たとえば
NODE_ENV=production node app.js
または、コマンドラインオプションの方が使いやすい場合は、--prodを使用できます。
node app.js --prod
# (Sails will set `NODE_ENV` automatically)
ご覧のとおり、本番環境ではsails liftではなく、node app.jsを使用してSailsアプリを起動する必要があります。これにより、sailsコマンドラインツールにアクセスできる必要がなくなり、アプリはSailsアプリにバンドルされているapp.jsファイル（同じことを行う）を実行するようになります。
…そして起動したままにします。
HerokuなどのPaaSにデプロイしない限り、pm2またはforeverなどのツールを使用して、アプリサーバーがクラッシュした場合に再起動できるようにする必要があります。選択したデーモンに関係なく、上記のようにサーバーを起動するようにする必要があります。
次のステップ
sailsjs.comでより良いエクスペリエンスを得るには、ブラウザを更新してください。
概念
愛情を込めて作成
Sailsフレームワークは、貢献者たちの助けを借りて、テキサス州オースティンにあるウェブ＆モバイルショップによって作成されました。私たちは2012年にNode.jsプロジェクトを支援するためにSailsを作成し、オープンソースにしました。皆さんの生活を少しでも楽にできれば幸いです！
© 2012-2024 The Sails Company。
SailsフレームワークはMITライセンスに基づいて無料でオープンソースです。
イラストはEdamameによるものです。