Liferayポータルのステージングのベストプラクティス

ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

この記事では、サイトでのステージング使用準備時、または既存のステージングインフラを管理する際に、管理者が留意すべき推奨事項をいくつか説明します。

ローカルステージングとリモートステージング

Stagingの使用を計画するとき、最初に決定しなければならないことの1つは、 Local Live と Remote Live Stagingのどちらを有効にするかということです。

この決断をするために、以下の情報を検討してください。

ローカルステージング。

• ステージングサイトとライブサイトの両方が同じサーバーにホストされています。 有効にすると、Liferayプラットフォームは、ページと選択されたポートレットデータを公開することで、ポータル内に同一のHidden Siteを作成します。 クローンしたサイトはステージング環境となり、元のサイトはライブ環境となります。
• ローカルライブステージングでは、ネットワークトラフィックが発生しないため、サイトの変更をより迅速に公開することができます。 ただし、ステージングされたコンテンツは本番のコンテンツと同じデータベースに保存されるため、サーバーにはより多くのリソースが必要になります。
• Local Statingを有効にしたときに、サイトがすでに多くのデータを持っている場合、そのクローンを作成するのに時間がかかり、リソースを消費する操作になる可能性があります。 また、データのバックアップもリモートライブステージングに比べると十分ではありません。

リモートステージング。

• あなたのLive Siteは、全く別のLiferayインスタンス/サーバーに位置しています。 有効にすると、Liferayプラットフォームは、ネットワーク上で2つのSite間の接続を確立します。 リモートサーバー上のサイトがLive環境となり、現在のサイトがStaging環境となります。
• リモートライブステージングでは、データがより分離されているため、資産の区別や管理がしやすくなっています。 また、新しいバージョンのアプリやコンテンツは、別のサーバーに配置されるため、Live環境との干渉を心配することなく、Staging環境にデプロイすることができます。 ただし、リモートライブでは、ネットワーク経由でデータを転送する必要があるため、ローカルライブに比べて発行が遅くなる。
• もちろん、ステージングサーバーを別に稼働させるためには、より多くのハードウェアも必要です。

カスタムテーマの公開

• カスタムテーマを持つページを公開する場合、Theme Settingsチェックボックスをチェックするか、LiveページがデフォルトのLiferayテーマを持つことが重要です。
• というのもあります。 エクスポート時に選択すると、サイトに選択されたテーマとカラースキームが、結果のLARファイルに含まれます。 インポート時に選択すると、テーマと配色の設定がインポートされ、すべてのページがそれらを使用するように設定されます。
• それ以外の場合は、 THEMEID と COLORSCHEMEID が削除されたことが表示される。 THEMEID と COLORSCHEMEID が後続のパブリケーションで削除される既知の問題である。 詳細は、 LPS-92943 を参照してください。

ハードウェアの最適化

Stagingを使い始める前に、ハードウェアについて考えておく必要があります。

ネットワーク速度。

• リモートステージング環境では、ネットワークが考慮すべき重要な要素になります。 膨大な量のデータ、たくさんの画像、大きな動画を公開しようとする場合、ネットワークを介してプッシュする必要があることを認識する必要があります。 このため、リモートサーバーをサブネットワークの外に置くと、公開速度に悪影響が出る場合があります。

原稿読み取り/書き込み速度。

• 例えば、画像をたくさん使う場合、Liferayが非常に高速に読み書きができることを確認する必要があります。 これはローカルのファイルシステムにも言えることですが、特にリモートでドキュメントにアクセスする外部リポジトリには当てはまります。

CPUのスピード

• 膨大な量のウェブコンテンツを公開する場合、ディスクやネットワークに負荷をかける操作ではありませんが、この使用例では記事の実際の文字列データがその場で処理され更新されるため、CPUがそのタスクに対応していることを確認する必要があります。 例えば、すべてのリンクとその埋め込みデータへの参照は、Live環境上の位置に応じて変更する必要があります。

お客様のニーズに最も適したハードウェアとステージング構成を考えるには、様々なシナリオで多くのテストを行うことを強くお勧めします。

ステージングをオンにする前に、ステージングするポートレットを決定する

ステージングを有効にする場合、ステージングするコンテンツの種類を選択する必要があります。

• 個々のポートレットデータに対してステージングをオン・オフすると、ステージング・サイトとライブ・サイトの間でデータの不整合が発生する可能性があるため、これは重要な決定事項であることに注意してください。
• このため、最近のLiferayのバージョンでは、Stagingを有効にすると、個々のポートレットの設定を変更することができなくなりました。 後で調整が必要な場合は、Stagingを完全にオフにして、新しい設定で再度有効にする必要があります。

出版は早く、出版は頻繁に、出版は小さく

ステージングを使い始めるときによくある間違いは、最初にすべてのコンテンツを作成し、最後のステップとしてステージングをオンにすることです。 しかし、使用するステージングの種類にかかわらず、データが追加される前、または比較的早い段階で、サイト上でステージングを有効にすることが最善です。

• サイト作成プロセスの非常に早い段階でステージングをオンにすると、より小規模なパブリッシュが可能になり、増分データをパブリッシュできます。パブリッシュが終了するのを長時間待つ必要がなく、可能性のある問題を早い段階で発見できます。
• データセットを制限することで、より少量のデータを公開することができます。 コンテンツの種類と日付の範囲に基づいて行うことができます。 例えば、最近作成した Web コンテンツ記事 のみを、そのバージョン履歴（最新版のみ必要な場合）や参照されたコンテンツ（それらを既に個別に公開している場合、再度公開する必要はない）を せずに公開することが可能です。

出版オプションの詳細については、 Staging Publication Form Options の記事を参照してください。

ステージングの効率的な活用

Stagingが適切に使用されていない場合に起こりうるいくつかの問題を回避するために、Stagingの最も一般的な使用例に関するベストプラクティスのリストを作成しました。 これについては、 Getting Started with Staging の記事をご確認ください。

ステージングをデバッグする方法

Stagingの問題の大半は、データ検証中に発生します。これは、このプロセスで見つかる不整合に起因します。 このため、トラブルシューティングの最も重要なステップは、問題のあるエントリーを見つけることです。 そのためには、一般的な方法があります。

• 出版物を構成要素に分解する。

• ウェブコンテンツの記事のみを掲載するようにしてください。 次にドキュメントとメディアのみ、など。 問題の切り分けができるまで

• スタックトレースからより多くの情報を得るために、複数のStaging関連クラスのログレベルをDEBUGに増やします。 こうすることで、問題が起こる前にどのエントリーが処理されたかを確認することができます。

  • コントロールパネル > サーバー管理 > ログレベル にアクセスし、以下のカテゴリーを DEBUG に設定します。

    com.liferay.portal.lar

    com.liferay.portal.kernel.lar

    com.liferay.portal.staging

    com.liferay.portlet.documentlibrary.lar

    com.liferay.portlet.journal.lar

• Liferay プラットフォームは、Staging 公開が成功または失敗した後、生成された LAR ファイルを Live 環境のアプリケーションサーバーの temp フォルダーに保存するように設定できます。 これは、どのデータがLiferayプラットフォームによって処理されたかを正確に分析したい場合に非常に便利です。 そのためには、 portal-ext.properties ファイルで、以下のプロパティを設定します。

    #

    # Set this property to false to avoid deleting the temporary LAR during a

    # a failed staging publication process.

    #

    staging.delete.temp.lar.on.failure=false

    
    #

    # Set this property to false to avoid deleting the temporary LAR during a

    # a successful staging publication process.

    #

    staging.delete.temp.lar.on.success=false

詳しくは、 LAR/Staging Ticket を開く前に をご確認ください。

演出の正しい消し方

ローカルまたはリモートのどちらのライブステージングを使用しているかによりますが、最終的にあなたのサイトでステージングを無効にすることを計画している場合、いくつかのことを認識する必要があります。

Local Stagingの場合。

• Stagingを有効にすると、すべてのStagingコンテンツを保持するために、複製サイトが作成されます。 つまり、本来の「本物」のサイトはLiveサイトであり、Stagingから公開する場合にのみ、作成されたデータが含まれることになります。 このため、Stagingを無効にすると、 公開されていないすべてのコンテンツが失われます。.

Remote Stagingの場合。

• リモートライブサイトを有効にすると、特別な制限事項が適用されます。

• Liveサイトでは、管理者はStagedコンテンツに対して新しいエントリーを作成したり、既存のエントリーを編集したりすることはできません。 このため、Stagingを無効にした場合、Stagingサーバーはネットワークを通じてLiveサーバーと通信し、これらの制限を解除する必要があります。 Liveサーバーにアクセスできない場合（削除された、またはアドレスが異なる）、 あなたのサイトでStagingを無効にすることはできません。

ワークアラウンド

• Liveサーバーに再度アクセスできるようにする。 すでにLive Siteを削除している場合でも、Stagingを無効にすることができるようになります。
• エクスポート/インポート機能を使用して、データを別のサイトに移動し、元のステージングサイトを削除します。
• Liferay サポートに連絡し、あなたのシナリオを正確に説明した上で、追加のソリューションについて問い合わせてください。

追加情報

• Liferay 6.2におけるステージング使用のベストプラクティス（Liferay Symposiumビデオ）
• Liferay 6.2におけるステージング使用のベストプラクティス（プレゼンテーションスライド）