JSS導入のベストプラクティスとセキュリティ
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
JSSアプリケーションのデプロイ手順は 、開発ワークフローによって異なります。
本番環境では、ほとんどのアプリがSitecoreファーストワークフローを使用しています。
Sitecoreファーストのワークフローでは、以下のSitecore DevOpsのベストプラクティスが適用されます。
- 繰り返し可能で完全自動化された展開プロセスを持つこと。
- UnicornやTDSのようなアイテムシリアライゼーションツールを使って、開発者所有のSitecoreアイテム(テンプレート、レンダリングなど)をソース管理し、JSSサイトのものも含めてデプロイしてください。
特にJSSに関しては、以下のことも推奨しています:
- SitecoreのバックエンドコードとJSSサイトコードを同じソース管理リポジトリに保存することで、フロントエンドとバックエンド間の変更同期の問題を避け、開発者が簡単にコミット、テスト、変更を差し戻せるようにしましょう。これにより、CIビルド時にJSSサイトの成果物をSitecoreにビルド・デプロイしやすくなります。
- SitecoreのアップデートとJSSのサイトアップデートをヘッドレスモードで単一のビルドプロセスに自動化し、フロントエンドとバックエンドの異なるバージョンをデプロイすることで生じる欠陥を防ぎます。
- JSS接続情報や展開情報をデプロイ変数に格納できるようにするには、jss setupコマンドでいくつかのオプションを使用できます。
!ヒントグローバルnpmパッケージをインストールできない環境でjss CLIコマンドを実行する場合、代わりにnpm run jss commandを使うと、CLIコマンドがnpmにアリアス化されます。
実行するコマンドの引数の前に -- を使npm。例えば、npm run jss deploy app -- --skipBuild
輸入サービス
インポートサービスは、コード優先のSitecoreアイテムアーティファクトをSitecoreにデプロイし、またSitecore優先の開発者スキャフォールディングにも使われます。このサービスはSitecoreヘッドレスサービスをインストールすると自動的にインストールされます。
- 展開サービスは認証に共有秘密を使用します。これらは環境ごとに一意で、 ランダム生成 (パスフレーズなし)、かつ少なくとも32文字でなければなりません。共有秘密はHMACを使用し、パッケージが展開される要素として利用されるため、パッケージが改ざんされていないことを示す署名検証があり、共有秘密が有線経由で送信されることは決してありません。
- シグネチャ検証があっても、インポートサービスを含むすべてのSitecore HTTPサービスはTLSで保護されたチャネル上で実行することを強く推奨します。
- インポートサービスは、Sitecoreサーバーの役割がローカル開発や本番環境でContentManagementされないStandalone、自動的に無効化されます。公開サーバーではJSSアプリのインポートは自動的に許可されていません。
- インポートサービスにIPホワイトリストを展開したい場合は、ネットワークレベルで行うことができます。
ファイル展開
JSSデプロイメントサービスは、攻撃対象をできるだけ最小限に抑えるため、意図的にデプロイされるファイルを受け入れていません。JSSビルドアーティファクトのファイルは、アップデートパッケージ、ダイレクトファイルコピー、Microsoft Web Deployなど、他のSitecoreデプロイに適した手法を用いてデプロイしなければなりません。ファイル展開に関してJSS特有の考慮事項はありません。