legacy-knowledge-base
公開されました Jul. 2, 2025

Liferay PortalとDXPのリモートステージングセットアップ

投稿者

Ira Chui

knowledge-article-header-disclaimer-how-to

knowledge-article-header-disclaimer

legacy-article

learn-legacy-article-disclaimer-text

この記事では、Liferay PortalとDXPで基本的なリモートステージングを設定する方法を説明します。

記事末尾のトラブルシューティングガイドは、Liferay Portal 6.2に関連するものです。 Portal 6.2にアップグレードされたユーザーには、以前のバージョンから多くの変更点、機能性が見られます。 以下の情報の一部は、Portal 6.2のユーザーに直接関係するものですが、その他の部分は一般的に適用されます。

解像度

1. Liferayのインスタンスを2つセットアップします。

ステージングに関する問題を避けるため、使用するすべてのサーバーに同じパッチが適用されていることを確認してください。 これについては、 サーバー間のステージングまたはエクスポート/インポートに関するよくあるエラーをご覧ください。

これは、VM、または別のポートで動作するLiferayの2番目のインスタンスを介して設定することができます(conf/server.xmlを介して変更することができます)。 どちらも選択できない場合は、同じインスタンス上の別のサイトを使用することができます。 これらのオプションは、あくまでテスト用であることを念頭に置いてください。 以下の指示はVM用となりますが、お客様のニーズに合わせて調整可能です。

2. Liferay の両方のインスタンスを設定する。

サイトの変更をリモートサイトに公開できるようにするには、リモートサーバーをステージングサーバーの許可サーバーリストに追加する必要があり、その逆も同様です。 Liferay 6.2の場合、ステージングサーバーとリモートサーバーで共有する認証キーを指定し、各Liferayサーバーのトンネリングサーブレットの認証検証を有効にする必要があります。

そのためには、両方のLiferayインスタンスでportal-ext.propertiesを設定する必要があります。

Staging Server Liferay 6.1 の例です:

tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP,172.16.10.120
axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP,172.16.10.120

リモートサーバーLiferay6.1の例:

tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP,172.16.10.46
axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP,172.16.10.46

Staging Server Liferay 6.2 の例です:

tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP,172.16.10.120
axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP,172.16.10.120
tunneling.servlet.shared.secret=1234567890123456
auth.verifier.TunnelingServletAuthVerifier.hosts.allowed=

リモートサーバーLiferay6.2の例:

tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP,172.16.10.46
axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP,172.16.10.46
tunneling.servlet.shared.secret=1234567890123456
auth.verifier.TunnelingServletAuthVerifier.hosts.allowed=

3. Liferayの両インスタンスに同じ認証情報を持つ管理者ユーザーを設定します。

ユーザーがStaging ServerからRemote Serverへ変更を公開しようとすると、ポータルはユーザーの電子メールアドレス、スクリーンネーム、またはユーザーIDをRemote Serverに渡し、権限チェックを実行します。 パブリッシング操作を成功させるためには、Staging環境とRemote環境の両方で同一の資格と権限を持つユーザーによって操作が行われる必要があります。 Liferay 6.1では、2つのサーバー間で事前共有鍵がないため、ユーザーのパスワードも同じである必要があります。

4. ステージングサーバーの場合

1. コントロールパネルに移動します。
2. Test Staging」という名前の新しいブランクサイトを作成します。 このサイトは、リモートサーバー(「ソース」サイト)に公開するためのコンテンツを作成するサイトとなります。
3. テストステージング」サイトにページを作成し、ページ内にウェブコンテンツの記事を追加します。

5. リモートサーバーの場合

4. コントロールパネルに移動します。
5. Test Remote」という名前の新しいブランクサイトを作成します。 これは、あなたが公開したいサイト、あなたの「ターゲット」サイトとなります。
6. 作成後のサイトID(例:"10401")を控えておいてください。 もし、何らかの理由でここから離れてしまった場合は、サイトのサイト設定パネルに移動して、いつでも確認することができます。

6. ステージングサーバーの場合

7. テストステージング」に戻る。
8. サイトのサイト設定パネルに移動し、右側にあるステージングオプションをクリックします。
9. リモートライブを選択し、構成設定セクションに気づく。
10. 最初のリモートホスト/IPフィールドに、「Test Remote」サイトがあるリモート/ターゲットサーバーのIPアドレスを入力します。 同じインスタンスを使用している場合は、: localhostと入力します。
11. ポートには、リモート/ターゲットサーバーのポート(デフォルトでは8080)を指定します。
12. リモートサイトIDは、手順6で述べた「Test Remote」サイトのIDになります。
13. その他の設定はすべてデフォルトのままにしてください。 保存をクリックします。
14. コントロールパネルを出て、「Test Staging」サイトに移動します。
15. 上部の「ステージング」ボタンをクリックし、「リモートライブに公開する」を選択
16. 公開したいページと、リモートライブの接続設定が正しいことを確認する。
17. パブリッシュ]をクリックします。 Liferay 6.2ではプログレスバーが表示され、"Successful "の状態で終了するはずです。 Liferay 6.1では、"Your Request Completed Successfully "と書かれた緑のバーが表示されるはずです。 ポップアップを閉じる。
18. ここで、「リモートライブへ」ボタントップをクリックします。
19. これで、「Test Remote」サイト(リモート/ターゲットサイト)への公開が完了しました。 テストステージング」サイトから表示されるようになったウェブコンテンツの記事に注目してください。

トラブルシューティング

Liferayのリモートステージングは、以下の7つのうち、1つ以上の領域で障害が発生する可能性があります:

  1. 接続:ステージングサーバーは、設定を確認するために、リモートサーバーとの接続を確立します。
  2. エクスポート:ステージングサーバーは、目的のサイトとそのコンテンツをアーカイブ(.lar)としてローカルストレージ(temp)上にエクスポートします。
  3. データ転送:ステージングサーバーがアーカイブをリモートサーバーに転送する。
  4. チェックサム:リモートサーバーがアーカイブの完全性を検証する。
  5. バリデーション:リモートサーバーは、参照の欠落や無効なコンテンツがないかチェックする
  6. インポート:リモートサーバーは、コンテンツのインポートを進めます。 失敗した場合、インポート全体がロールバックされます。
  7. クリーンアップ:両サーバーとも、一時ファイルをクリーンアップします。

リモートステージングに失敗した場合、まずエラーログを確認することで、上記のエラーのうち、どのエラーが発生したかを知ることができます。 パブリッシングプロセスでは、どのステップで失敗したかは記載されませんが、管理者が調べてエラーを見つけることができる場所が存在するのです。 エラーが特定された後、管理者は以下のいくつかの手順で問題を解決することができます。

  1. コネクションエラー
    • 2台のサーバーは正しく接続されていますか? tunneling.servlet.shared.secret= および axis.servlet.hosts.allowed= の値は portal-ext.properties で宣言されています(上記参照)。
    • Webプロキシサーバー:Webプロキシサーバーがある場合、サーバーがプロキシリクエストでオリジンホストを保持することを確認してください。さもないと、リクエストは無効なIPアドレスのためにリモートサーバーによって拒否されます。
    • 警告:このステップは安全ではありません。 プロキシサーバーを設定できない場合、管理者はリモートサーバーの axis.servlet.hosts.allowed= をプロキシサーバーのIPアドレスと一致するように変更することをお勧めする場合があります。 リスクとしては、LiferayのリモートAPIに誰でもアクセスできるようになることです。
  2. データ転送
    このフェーズでよくある問題は、以下の通りです:
    • タイムアウト. この処理が失敗した場合、プロキシ、サーバー、スイッチ、アプリケーションサーバー、アンチウイルスの他のルールが影響している可能性があります。
    • サイズ. デフォルトでは、ファイルが10MBを超える場合、プロセスは.larファイルを複数個に分割して送信します。 この値は、 staging.remote.transfer.buffer.size= プロパティで変更することができます。 上記のように、"よく輸出し、小さく輸出する "ことです。
  3. Export
    Exportが失敗することはほとんどありません。 もしそうなら、
    • ディスクドライブに十分な空き容量があることを確認してください。
    • コントロールパネルからサイトを.larとしてエクスポートします。
    • 最新のパッチをインストールする。
  4. Checksum
    このステップは、技術的には決して失敗しないはずです。 もしそうなら:
    • もう一度出版してみてください。 送信したファイルが転送中に破損したのかもしれません。
    • クラスタ環境がある場合:送信ファイル(アーカイブ > 10MBの場合)がクラスタ化されているかどうかを確認します。 このようなことは起こらないはずですが、もし起こった場合、Liferayは50%のファイルを一方のサーバーに、50%をもう一方のサーバーに置くことになります(2ノードクラスタを想定しています)。 その場合、チェックサムは常に失敗することになります。
    • アーカイブのサイズを確認する。 (データ転送#2参照)
  5. バリデーション
    バリデーション中のエラーは、「リモートパブリッシング」のインターフェース(履歴)で詳細な情報を提供します:
    • 欠落している参照を特定し、システムがこの参照が欠落していると考える理由を理解するようにします。
    • サイトにグローバル参照(構造、テンプレート、カテゴリなど)がある場合は、必ず最初に Global サイトを公開してください。 グローバルサイトは、コントロールパネル > サイトから公開することができます。
    • 外部参照を持たないサイトの場合、コンテンツ全体を公開してみてください。 リモートパブリッシング」のオプションで、「すべてのコンテンツ」を選択します。
  6. インポート
    インポート処理に失敗する可能性がある箇所は数多く考えられます。 考えられる解決策は
    • 重複コンテンツに関するエラーがある場合は、サイト全体を再度公開します。
    • 公開サイズを小さくするために「バージョン履歴」を無効にして、違いがあるかどうか確認してください。
    • より詳細な情報は、リモートサーバーのログを確認してください:
      • OutOfMemoryExceptionの場合は、サーバーアプリケーション(-Xmx)で使用できるメモリを増やしてください。
      • GenericJDBCExceptionの場合、JDBC接続プールを確認してください。 すべてのコネクションが使用され、1つも解放されていない可能性があります。 アプリケーションサーバーを再起動すると解放されます。 お客様のニーズに合わせてJDBCの設定を確認してください。
    • インポート処理が非常に遅い場合は、CPUやIOアクセスなどのインフラを監視し、仮想マシンやサーバーに多くのリソースを割り当ててください。 インポート処理に時間がかかりすぎると(通常30分以上)、ステージングサーバーがタイムアウトし、インポートはまだ続いていて完了しても、正しくクリーンアップされません(次のポイントを参照ください)。
  7. Cleanup
    Cleanupは失敗しないが、 remote staging は失敗する可能性がある。 この時点で、Liferayでは以下のようなことが起こります:
    1. ステージングサーバー は、リモートサーバーがインポートを終了するのを待ち続けます。 しばらくすると、ステージングサーバーはタイムアウトを起こし、接続がリセットされます。
    2. このような場合、ステージングサーバー側でクリーンアップを行い、プロセスのステータスを「失敗」に設定します。
    3. しかし、相手側(リモートサーバー)ではインポート処理が継続され、成功する可能性があります。 リモートサーバー の表示状態がおかしく、「最終発行日」が正しく設定されていない。
    技術的には成功したが、タイムアウトにより失敗と報告された場合、別のパブリケーションを開始し、日付範囲を「過去12時間」に設定します。 この小さな出版物は、より速く実行され、成功し、「最終出版日」を正しく更新するはずです。

まだ出版しないの?

それでもリモートパブリッシングに失敗する場合は、以下のいずれかを試してみることを検討してください:

  • クラスター環境の場合は、1つのノード以外を無効にしてみてください。
  • アプリケーションサーバーの前にプロキシサーバーが設置されている場合は、ファイアウォールを開放して、アプリケーションサーバーに直接パブリッシュしてみてください。
  • リモートパブリッシング処理にSSL接続を使用している場合は、SSL接続なしでお試しください。 一部の証明書は有効期限が切れているため、ステージングサーバーとリモートサーバーの間で正しい「ハンドシェイク」ができない可能性があります。
  • リモートサーバーを同じネットワーク上に移動してみてください。
  • 同じマシン上でリモートサーバーを動かしてみてください。

追加情報

did-this-article-resolve-your-issue

legacy-knowledge-base