|
|
アプリケーションのデプロイメントとは、WebLogic Server ドメインでクライアント リクエストの処理にアプリケーションやモジュールを利用できるようにすることです。この章では、WebLogic Portal アプリケーションおよび共有ライブラリをサーバにデプロイする場合の推奨手順とベスト プラクティスについて説明します。
| ヒント : | この手順を進める前に、WebLogic Server ドキュメントの「WebLogic Server ドメインについて」の内容を確認しておくことをお勧めします。 |
WebLogic Portal アプリケーションをデプロイする前に、送り先ドメインをコンフィグレーションする必要があります。ドメインのコンフィグレーションの詳細については、「クラスタ ドメインの作成」を参照してください。
WebLogic Portal 8.1 以前のバージョンでは、WebLogic Portal コンポーネント (キャッシュ、キャンペーン、行動追跡、コンテンツ管理など) のコンフィグレーションに META-INF/application-config.xml という名前のアプリケーション コンフィグレーション ファイルが使用されていました。
WebLogic Portal 9.2 では、このコンフィグレーション ファイルが削除されており、コンフィグレーションの内容はスキーマ準拠の新しい記述子のコレクションに移行されています。これらの新しい記述子は、単一サービスまたは関連するサービス グループに特化されています。WebLogic Workshop のアプリケーションで使用する一連の記述子ファイルを確認する場合は、マージ済みプロジェクト ビューを選択します。
これらのファイルは、WebLogic Server ですべての J2EE 記述子 (application.xml または web.xml など) の処理に使用されるのと同じインフラストラクチャを使って処理されます。これらの記述子は、J2EE 共有ライブラリからのマージをサポートしています。また、デプロイメント計画もサポートしています (マージの詳細については、「記述子のマージ」を参照)。WebLogic Portal 記述子はデフォルト設定を使用してインストールされます。このデフォルト設定は、アプリケーションにコピーして編集することによってオーバーライドできます。このコンフィグレーションの大きな利点は、プロジェクトの EAR ファイルの内容が WebLogic Portal 製品コードではなく、プロジェクトに限定されることです。
サーバはデプロイメント記述子を処理する際に、これらの記述子をマージします。アプリケーションで参照されるアプリケーションおよび共有ライブラリのすべての記述子がマージされます。個々のデプロイメント記述子に対して、マージされた「仮想」記述子が作成されます。仮想記述子は、アプリケーションをデプロイする際にサーバで使用できます。記述子のマージを規定するルールについては、「優先に関する共有ライブラリ ルール」を参照してください。参照ライブラリからインポートされる設定は、参照元アプリケーションとそのデプロイメント計画によって常にオーバーライドされます。
アプリケーションをデプロイせずにマージ結果を確認する場合は、weblogic.appmerge という WebLogic Server ユーティリティを使用します。このユーティリティは共有ライブラリを参照するアプリケーションを取得して、マージされたコンテンツやマージされた記述子を含む J2EE アプリケーションを作成します。このユーティリティはデバッグに有効です。詳細については、WebLogic Server ドキュメントの「Using weblogic.appmerge to Merge Libraries」を参照してください。
Workshop for WebLogic では、共有ライブラリ (ライブラリ モジュールとも呼ばれる) に関する情報が利用できます。Workshop for WebLogic を使用すると、共有ライブラリのファイルをアプリケーションにコピーできます。この場合、コピーされたファイルは後から変更できます。それ以降は、ローカル コピーがライブラリ モジュールのコピーよりも優先されます。[パッケージ・エクスプローラー] ビューを使用すると、共有ライブラリの内容を表示および参照できます。
WebLogic Portal のインストールには、ddbrowser という別のユーティリティも含まれています。このユーティリティはアプリケーションを検査して、「マージ可能」なすべての記述子を表示します。アプリケーション内の各記述子については、マージされた記述子だけでなく、各ライブラリの関与も確認できます。
ddbrowser を使用するには、WL_HOME 環境変数で weblogic ホーム ディレクトリを参照するように設定してから、以下のコマンドを入力します。
java -jar $WL_HOME/common/p13n/lib/ddbrowser.jar
ポータル Web アプリケーションには、複数のデプロイメント記述子が含まれています。デフォルトで、これらの記述子は Web プロジェクトの WebContent/WEB-INF ディレクトリにあります。表 4-1 にデプロイメント記述子を示します。
| ヒント : | WebLogic Server ベースのアプリケーションに関連するデプロイメント記述子の完全なリストと詳細については、WebLogic Server ドキュメントの「WebLogic Server アプリケーション開発の概要」を参照してください。 |
J2EE 仕様では、J2EE モジュールおよびアプリケーションに対応する、移植可能で標準的なデプロイメント記述子が定義されています。BEA では、WebLogic Server 環境でモジュールやアプリケーションをデプロイするための WebLogic 固有のその他のデプロイメント記述子が定義されています。WebLogic Portal のエンタープライズ アプリケーション (EAR プロジェクトとも呼ばれる) には、表 4-2 に記載されたデプロイメント記述子が含まれています。デフォルトで、これらのファイルは EAR プロジェクトの EarContent/META-INF ディレクトリにあります。
| ヒント : | WebLogic Server ベースのアプリケーションに関連するデプロイメント記述子の完全なリストと詳細については、WebLogic Server ドキュメントの「WebLogic Server アプリケーション開発の概要」を参照してください。 |
表 4-3 は、Web アプリケーションのコンフィグレーション ファイルを示しています。これらのファイルは記述子ファイルではありません (これらのファイルはデプロイメント計画で使用できず、マージされることもありません)。
WEB-INF/wsrp-producer-registry.xml で <enable-local-proxy> を true に設定することによって、ローカル プロキシ サポートを有効にできる。WSRP アプリケーションの詳細については、『連合ポータル ガイド』を参照。
|
|
デプロイメント計画を使用すると、アプリケーション EAR ファイルの記述子を実際に変更することなく、アプリケーションのデプロイメント記述子をデプロイメントごとに容易にチューニングできます。たとえば、ステージング環境向けに記述子を調整する場合やプロダクション環境向けに調整する場合に、それぞれ個別のデプロイメント計画を使用できます。通常、開発者は記述子の初期基準値を設定します。
| ヒント : | 「アプリケーション チューニングのヒント」も参照してください。 |
デプロイメント記述子は、デプロイメント時におけるアプリケーションやモジュールの J2EE 動作や WebLogic Server コンフィグレーションを定義する XML ドキュメントです。デプロイメント計画は、アプリケーションのアーカイブ ファイルの外部にある XML ドキュメントで、アプリケーションの既存の WebLogic Server デプロイメント記述子に格納されているデプロイメント プロパティに変更を加えることができます。
デプロイメント計画の詳細については、WebLogic Server ドキュメントの「プロダクション デプロイメントのためのアプリケーションのコンフィグレーション」を参照してください。このドキュメントには、デプロイメント計画の詳細、デプロイメント計画の XML スキーマ、およびデプロイメント計画の作成、編集、および使用手順に関する説明が記載されています。
| 注意 : | WebLogic Portal Administration Console では、デプロイメント計画を使用してデプロイメント記述子の値に対する実行時の変更を保存します。 |
アプリケーション スコープ JDBC を使用すると、WebLogic Portal ドメインで複数のデータベースを使用できます。これにより、ドメインにデプロイされた各アプリケーションで独自のデータベースを利用することが可能になります。JDBC プールのスコープをアプリケーション レベルに設定できるようにすると、WebLogic Server でこの機能が利用できるようになります。
| ヒント : | アプリケーション スコープで指定する JDBC プールをドメインで WebLogic portal アプリケーションと共に使用することをベスト プラクティスとして推奨します。 |
エンタープライズ アプリケーションをパッケージ化する場合、JDBC モジュールを EAR にパッケージ化し、該当するすべての記述子ファイルに JDBC モジュールへの参照を追加すると、JDBC リソースをアプリケーションに組み込むことができます。アプリケーションをデプロイする際には、JDBC リソースもデプロイされます。アプリケーションでデプロイされる JDBC データ ソースは、JDBC モジュールのコンフィグレーション方法に基づいて、コンテナ アプリケーションによる利用に限定されるか (アプリケーション スコープ モジュール)、またはすべてのアプリケーションとクライアントで利用できるようになります (グローバル スコープ モジュール)。
デフォルトで、JDBC プールのスコープはドメイン レベルです。JDBC プールのスコープをアプリケーション レベルに設定する場合は、コンフィグレーションが必要になります。アプリケーション スコープ JDBC のコンフィグレーションの詳細については、WebLogic Server ドキュメントの「JDBC アプリケーション モジュールのデプロイメントのコンフィグレーション」を参照してください。
この節では、Workshop for WebLogic またはコマンドラインを使用してポータル アプリケーションをビルドする手順および EAR ファイルを作成する手順について説明します。この節では、EAR ファイルと非圧縮 EAR の両方を使用した作成手順について説明します。
ポータル アプリケーションをプロダクション環境にデプロイするには、まず Workshop for WebLogic でそのアプリケーションをビルドして、ポータル アプリケーション内の必要なクラスをコンパイルし、デプロイ可能な EAR ファイルを作成する必要があります。EAR は、圧縮 (EAR ファイル) または非圧縮 (非圧縮 EAR ディレクトリ) のいずれでも使用できます。
Workshop for WebLogic でのアプリケーションのビルドの詳細については、Workshop for WebLogic のドキュメント「ビルド プロセスについて」を参照してください。
非圧縮 EAR ディレクトリを作成するには、最初に EAR ファイルをビルドし、次に Java の jar xf コマンドを使用してファイルを非圧縮にします。
| ヒント : | 非圧縮 EAR の作成後、アプリケーション ディレクトリの名前に .ear 拡張子を付けて変更することができます。たとえば、アプリケーション ディレクトリの名前が myPortalApp である場合は、ディレクトリ名を myPortalApp.ear に変更します。.ear を追加すると、圧縮および非圧縮デプロイメント用のコンフィグレーションを共通化できますが、必須ではありません。 |
Workshop for WebLogic を使用すると、プロジェクトの Ant ビルド ファイルをエクスポートできます。詳細については、WebLogic Workshop のドキュメント「アプリケーションのカスタム Ant ビルド ファイルの作成」を参照してください。
この節では、ポータル アプリケーションのデプロイメントの手順について説明します。
| 注意 : | WebLogic Portal バージョン 9.2 より前のバージョンでは、WebLogic Portal アプリケーションの管理サーバへのデプロイが必須でしたが、バージョン 9.2 では必須ではなくなったため、ここでは特に説明しません。 |
| ヒント : | WebLogic Server ドキュメントには、デプロイメント手順と複数のデプロイメント例の詳細な説明が記載されています。この手順を進める前に、WebLogic Server ドキュメントの『WebLogic Server アプリケーションのデプロイメント』の内容を確認しておくことをお勧めします。WLST による自動デプロイメント タスクについては、WebLogic Server ドキュメントの『WebLogic Scripting Tool ガイド』を参照してください。 |
一般的な開発環境では、開発者は Workshop for WebLogic を使用してポータル コンポーネントの開発を行います。通常、開発者は開発モードでコンフィグレーションされたローカル サーバ ドメインに対してデプロイおよび実行します。管理対象サーバは使用されません。Workshop for WebLogic を使用してアプリケーションのデプロイ (公開) とテストを行うのがベスト プラクティスです。
ドメインが 1 つの管理サーバと 1 つの管理対象サーバまたはクラスタ構成の複数の管理対象サーバで構成される場合には、ポータル EAR ファイルを管理対象サーバまたはクラスタにデプロイすることを強くお勧めします。管理サーバにはデプロイしないでください。このように管理サーバを管理機能用に確保しておくと、管理サーバのヒープを小さくすることができます。また、管理サーバ上で管理機能をファイアウォール保護することもできます。
ステージング サーバおよびプロダクション サーバは、開発モードではなくプロダクション モードでコンフィグレーションするのがベスト プラクティスです。
アプリケーションを直接管理対象サーバにデプロイできる WebLogic Server の機能は、管理対象サーバ独立 (MSI) モードといいます。MSI の情報といくつかの制限については、『WebLogic Server ドキュメント』の「管理対象サーバ独立モードについて」を参照してください。管理サーバがダウンしていると、セキュリティ プロバイダのデータを変更できないことがもっとも大きな制限の 1 つです。管理サーバがダウンしている場合、永続性を得るためにデプロイメント計画に書き込む必要がある WebLogic Portal コンフィグレーションがすべて機能しなくなることが、もう 1 つの制限です。
再デプロイとは、既存/稼働中/デプロイ済みのアプリケーションの新バージョンをデプロイすることを意味します。ポータル アプリケーションをステージングまたはプロダクション環境に再デプロイする場合には、前の節で説明したデプロイ手順と同じ手順を使用します。ただし、再デプロイする際には、伝播ツールを使用して個別の操作として、datasync やその他の WebLogic Portal 資産を目的のデータベースに伝播する必要があります。再デプロイの詳細については、「一般的な伝播のシナリオ」を参照してください。
展開された EAR ファイルを管理対象サーバにデプロイする場合、追加のコンフィグレーションが必要です。新しい datasync.properies ファイルを META-INF ディレクトリにあるエンド ユーザ のアプリケーションに配置する必要があります。この datasync.properties ファイルに、以下のプロパティを追加します。
PERSISTENT_STORE=DATABASE_STORE
展開された EAR ファイルをデプロイする場合のみ、この変更が必要になります。
J2EE 共有ライブラリを参照すると、WebLogic Portal の製品コードがアプリケーションに組み込まれます。これらのライブラリは、WebLogic Portal のインストールの一部になります。また、アプリケーション コードを含む独自の共有ライブラリを開発することもできます。J2EE 共有ライブラリを使用すると、アプリケーションのさまざまな部分の開発ライフサイクルを分離できます。これらのライブラリのバージョン管理やデプロイは個別に行うことができます。このため、単一の大きな EAR ファイルではなく、各ライブラリを個別に開発して配布することが可能です。
| ヒント : | J2EE 共有ライブラリの詳細については、WebLogic Server ドキュメントの「共有 J2EE ライブラリおよびオプション パッケージの作成」を参照してください。また、「チーム環境での J2EE 共有ライブラリの使用」および WebLogic のポータル開発ガイドも参照してください。 |
この節では、共有ライブラリに関する次の内容について説明します。
コード リスト 4-1 は、エンタープライズ アプリケーションのサンプル (myApp.ear) を示しています。記述子 weblogic-application.xml には、p13n-app-lib というライブラリに対する参照 (太字で表記) が含まれています。p13n-app-lib という名前以外に、ライブラリに関する情報は記載されていません。
エンタープライズ アプリケーションはこのライブラリを検索します。これは、<library-ref> 要素によって、サーバが同じ名前を持つデプロイ済みのライブラリを実行時に検索するためです。<library-ref> 要素ではバージョン情報が指定されていないため、サーバは利用可能な最新の (最も大きな) バージョン番号を検索します。共有ライブラリの名前とバージョン番号は、ライブラリそのもの (META-INF/MANIFEST.MF ファイル) に含まれています。次に例を示します。
META-INF/MANIFEST.MF
Extension-Name: p13n-app-lib
Specification-Version: 10.0.0
Implementation-Version: 10.0.0
詳細については、「ライブラリ バージョン」を参照してください。ポータル Web アプリケーションの WEB-INF/weblogic.xml ファイルには同じパターンが適用されます。
サーバで検索するには、共有ライブラリをライブラリとしてデプロイする必要があります。このデプロイメントは、実行可能なアプリケーションのデプロイメントとは異なります。ライブラリをライブラリとしてデプロイすると、ライブラリ ファイルがサーバに登録されて、参照元アプリケーションで利用できるようになります。
ライブラリをデプロイするには、WebLogic Server Console、weblogic.Deployer コマンド、wldeploy Ant タスク、または WLST スクリプトを使用します。これらのメソッドについては、WebLogic Server ドキュメントの「WebLogic Server Administration Console」、「weblogic.Deployer コマンドライン リファレンス」、「wldeploy Ant タスクのリファレンス」、および「WLST コマンドおよび変数リファレンス」を参照してください。
たとえば、WebLogic Server Console を使用すると、アプリケーションのデプロイとまったく同じ方法で共有ライブラリをデプロイできます (共有ライブラリと実行可能なアプリケーションを区別するチェックボックスが利用できる点を除く)。
コード リスト 4-2 は、コード リスト 4-1 のアプリケーションで参照される共有ライブラリに対応した、サーバ ドメインの config/config.xml ファイルのエントリを示しています。
<library>
<name>p13n-app-lib#10.0.0@10.0.0</name>
<target>myServer</target>
<module-type>ear</module-type>
<source-path>/bea/weblogic100/deployable-libraries/p13n-app-lib.ear
</source-path>
<security-dd-model>DDOnly</security-dd-model>
</library>
ライブラリ名が同じで異なるバージョン番号を持つ複数のライブラリをデプロイできます。アプリケーションで使用されるバージョン番号は、アプリケーションのコンフィグレーション ファイル META-INF/weblogic-application.xml または Web アプリケーションの weblogic.xml で指定されます。コード リスト 4-3 のようにバージョン番号が指定されない場合には、サーバで最も大きなバージョン番号を持つ p13n-app-lib という名前のデプロイ済みライブラリが選択されます。
<library-ref>
<library-name>p13n-app-lib</library-name>
</library-ref>
これに対して、アプリケーションで p13n-app-lib のバージョン 10.0.0 が使用できず、バージョン 10.0.1 以降が必要な場合には、コード リスト 4-4 のようにライブラリを参照できます。
<library-ref>
<library-name>p13n-app-lib</library-name>
<specification-version>10.0.1</specification-version>
</library-ref>
特定のバージョンのみを使用する必要がある場合には、コード リスト 4-5 のように <exact-match> 要素を指定できます。
<library-ref>
<library-name>p13n-app-lib</library-name>
<specification-version>10.0.0</specification-version>
<exact-match>true</exact-match>
</library-ref>
コンテンツ リポジトリを使用している場合には、送り先サーバ上に 1 つまたは複数のリポジトリを作成する必要があります。これを行うには、WebLogic Portal Administration Console を使用します (『コンテンツ管理ガイド』の説明を参照)。これは、ルート リポジトリのみを作成し、コンテンツの項目やタイプは作成しないことを意味します。環境の間で項目やタイプを移動するには、WebLogic Portal の伝播ツールを使用します。伝播ツールの詳細については、「伝播方針の開発」を参照してください。
また、コンフィグレーション ファイル META-INF/content-config.xml で、エンタープライズ アプリケーションのデフォルト コンテンツ リポジトリを指定することもできます。詳細については、「エンタープライズ アプリケーションのデプロイメント記述子」を参照してください。
単一クラスタ ドメインで複数のエンタープライズ アプリケーションを作成および実行できます。図 4-1 に示すように、単一のドメインで複数のエンタープライズ アプリケーション (EAR) をホストできます。各 EAR デプロイメントで複数の Web アプリケーションをホストでき、Web アプリケーションに応じて任意の数のデスクトップを作成できます。1 つのエンタープライズ アプリケーション (EAR) に関連付けられている Web アプリケーションおよびデスクトップは、別のエンタープライズ アプリケーションにある (切り離されている) Web アプリケーションおよびデスクトップに依存しません。
単一ドメインに複数のエンタープライズ アプリケーションをコンフィグレーションする場合、次の制限が適用されます。
| 注意 : | 各エンタープライズ アプリケーションは、それぞれの WebLogic Portal Administration Console を通じて管理する必要があります。ユーザ、グループなどの一部のドメインレベルのリソースは、エンタープライズ アプリケーションに関係なく、単一の WebLogic Portal Administration Console から表示および管理できますが、アプリケーションのデータはキャッシュされていることがあり、そのデータに対して別のアプリケーションの WebLogic Portal Administration Console から行われた更新は即時に表示されない場合があることに注意してください。 |
| 注意 : | 各エンタープライズ アプリケーションのコンテンツは、それぞれの WebLogic Portal Administration Console と仮想コンテンツ リポジトリを通じて管理されます。仮想コンテンツ リポジトリ (および WebLogic Portal Administration Console) は、各アプリケーションに対してユニークであり、共有できません。 |
ペスト プラクティスは、アプリケーションをデプロイする前にデプロイメント計画を使用して記述子の値を変更しておくことです。「デプロイメント計画の使用」を参照してください。また、WebLogic Server ドキュメントの『WebLogic Server パフォーマンス チューニング ガイド』に関する説明も参照してください。
WebLogic Portal には、JSR-168 WAR ファイルにパッケージされた JSR 168 ポートレットを自動的にデプロイするユーティリティが用意されています。このユーティリティでは、JSR-168 ポートレットを格納した JSR-168 WAR をインポートして、WSRP プロデューサでポートレットを公開できます。
| 注意 : | WebLogic Portal 10.0 では、ポートレット |
この節では、インポート ユーティリティの使い方を説明します。次のトピックが含まれています。
http://servername:port/earProjectNameAdmin
ここで、servername は管理サーバの IP 名、port はポート番号、earProject はサーバにデプロイされたポータル エンタープライズ アプリケーションの名前です。次に例を示します。
http://localhost:7001/myEarProjectAdmin
http://servername:port/earProjectAdmin/jsr168/jsr168import.jsp
ここで、servername は管理サーバの IP 名、port はポート番号、earProject はサーバにデプロイされたポータル エンタープライズ アプリケーションの名前です。次に例を示します。
http://localhost:7001/myEarProjectAdmin/jsr168/jsr168import.jsp
図 4-1 にユーティリティを示します。
この節では、インポート ユーティリティを使用して JSR-168 WAR ファイルをエンタープライズ アプリケーションにインポートする方法について説明します。
| ヒント : | [参照] ボタンを使用して WAR ファイルを見つけるか、[Add JSR-168 compliant .war] テキスト フィールドに直接パスを入力します。テキスト フィールドにパスを入力する場合は、〔Tab〕を押してパスを受け入れます。 |
startWebLogic.cmd または startWebLogic.sh を実行したディレクトリ) に配置されます。単一のサーバ環境の場合は、サーバの起動ディレクトリはドメイン ディレクトリです。管理対象サーバの場合は、サーバの起動ディレクトリは管理対象サーバのディレクトリです。
新しい EAR ファイルがデプロイされたら、インポートした WAR ファイルに格納されたポートレットをアプリケーションに追加できます。これを行うには、Web アプリケーションを WSRP プロデューサとして追加する必要があります。Web アプリケーションがプロデューサとして追加されたら、WebLogic Portal Administration Console を使用して WSRP プロデューサで行ったように、アプリケーションのポートレットを組み込むことができます。詳細については、『連合ポータル ガイド』を参照してください。
| ヒント : | プロデューサ アプリケーションとコンシューマ アプリケーションが同じサーバを共有している場合は、ローカル プロキシ モードを有効にすることをお勧めします。ローカル プロキシ サポートにより、プロデューサ Web アプリケーションとコンシューマ Web アプリケーションが同じ場所にある場合は、ネットワーク I/O および「HTTP 上での SOAP」のオーバーヘッドを回避できます。『連合ポータル ガイド』の「ローカル プロキシ モードの使用」を参照してください。 |
この節では、プロダクションの再デプロイメント技術を使用して、プロダクション環境に WebLogic Portal アプリケーションを再デプロイする方法について説明します。
| 注意 : | プロダクションの再デプロイメントは、限られた数の使用例でしか機能しません。最も信頼性があり、一般的な使用例は、web-tier （ファイル ベース） リソースを追加、削除、または更新することです。.たとえば、プロダクションの再デプロイメントの一般的な使用では、JSP コードの更新、または画像ファイルの更新が含まれています。 |
| 注意 : | 変更にポータル データベースや他のデータ ソースへの変更を伴う場合は、一般的にプロダクションの再デプロイメントはお勧めしません。プロダクションの再デプロイメントを他のより複雑な方法で使用することもできますが、それらの使用法はこの節で説明する他の要因の数に左右されます。 |
プロダクションの再デプロイメントを行うと、デプロイされたアプリケーションを停止したり、クライエントのアプリケーションの使用を中断したりせずに、プロダクション環境でポータル管理者にアプリケーションの新しいバージョンを再デプロイすることができます。プロダクションの再デプロイメントは、同じアプリケーションの古いバージョンをデプロイすると同時に、更新されたアプリケーションの新バージョンをデプロイすることで機能します。新バージョンには新しいクライアントのリクエストのみ送信するように、WebLogic サーバで自動的にクライアント接続を管理します。再デプロイメント中にアプリケーションにすでに接続されたクライアントは、作業が完了するまでアプリケーションの古い、廃棄されるバージョンを使用し続けます。
| ヒント : | WebLogic Portal アプリケーションでプロダクションの再デプロイメントを使用する場合、ポータルの特定部分の維持および更新に連合ポータル技術 (WSRP) の使用を考慮することをお勧めします。そのような戦略は、指定されたデプロイメントの全体的なスコープを減らすことによって、再デプロイメント戦略を増やす可能性があります。連合ポータルの詳細については、『連合ポータル ガイド』を参照してください。 |
WebLogic Portal におけるプロダクションの再デプロイメント サポートは、WebLogic サーバからのサポートに基づきます。この手順進める前に、以下の WebLogic Server ドキュメントを確認することをお勧めします。
図 4-2 は、WebLogic Portal アプリケーションの一般的なプロダクションの再デプロイメント シナリオを示します。図が示すように、新しいポータル バージョン、App V2 は最初のバージョンである App V1 と並列してデプロイされています。プロダクションの再デプロイメント中、既存のユーザは App V1 と対話し続け、新しいユーザは App V2 と対話します。App V1 に接続されたすべてのユーザ セッションが終了するか、タイム アウトになった場合、App V1 はアンデプロイされます。
ポータル アプリケーションに対してプロダクションの再デプロイメントがどのように機能するかを理解する鍵は、プロダクションの再デプロイメント中、新旧の両方のアプリケーションが同じデータベース、セキュリテイ リポジトリ、およびコンテンツ リポジトリを共有する点に留意することです。
両方のアプリケーションは、同じバック エンド システムを共有しているので、プロダクションの再デプロイメント中に悪影響が発生する可能性があります。これを説明するには、以下のシナリオを考慮します。開発者が、App V2 ポータルのホーム ページに新しいポートレットを追加しました。新しいポータルのデプロイ時に、そのポートレットと新しいポートレットを含む更新されたページ定義がプロダクション データベースに配置されました。現在は、これまでと新規の両方のアプリケーションが同じデータ ベースを共有するので、App V1 は新しいポートレットを表示しようとする可能性があります。残念なことに、ポートレットの基盤となるサポート対象のファイル ベース コード は、App V1 デプロイメントに存在しません。
この単純な例を使ったシナリオでは、共有データ ベースにはアプリケーションに固有のリファレンスが含まれるため、プロダクションの再デプロイメント中によく発生する悪影響について説明しています。「並列」アプリケーションの基盤となるデプロイメント間に差分があるため、エラーが発生する可能性があります。データベースで参照されるアプリケーション リソースのような、アプリケーションへのすべての外部タッチ ポイントは、2 つのアプリケーション間で一貫性を持っている必要があります。たとえば、ポートレット バッキング ファイルのクラス名は、ポートレットの定義と共にデータ ベースに格納されます。バッキング ファイルの名前を変更したり削除したりすると、元のアプリケーションにアクセスしている既存のユーザがエラーに直面する可能性があります。同様に、プロダクションの再デプロイメント中に新しいポートレットを含む新しいページをポータルに追加すると、このページとポートレット定義がデータベースに追加され、間違って元のアプリケーションに表示されるかもしれません。この場合、元のアプリケーションのユーザがエラーを経験する可能性があります。
| ヒント : | これまでと新規のアプリケーション間にある差分が、データベースに参照されないファイルとアプリケーション コードの集積の中にある場合、プロダクションの再デプロイメントに成功する可能性が高くなります。 |
これらのシナリオでは、WebLogic Portal アプリケーションのプロダクションの再デプロイメント中に発生する可能性がある悪影響を説明します。後の節では、プロダクションの再デプロイメントの推奨使用例と共に、付加的に起こりうる悪影響についても説明します。
| 注意 : | 実際のプロダクション環境で再デプロイする前に、まずステージング環境でプロダクションの再デプロイメントに必要なすべての手順を実行することをお勧めします。 |
図 4-3 では、WebLogic Portal のインストールと共にプロダクションの再デプロイメントの基本的な手順を説明します。
| 注意 : | WebLogic ポータル サイトで訪問者にカスタマイズや管理者アクティビティを許可している場合、プロダクションの再デプロイメント中にこのようなアクティビティを制限または排除するために、メンテナンス モードか別の戦略を使用することをお勧めします。メンテナンス モードは、管理者が WebLogic Portal Administration Console を使ってポータルに変更を加えるのを防止します。[コンフィグレーション｜サービス管理] を選択することで、WebLogic Portal Administration Console でメンテナンス モードを有効化できます。詳細については、Administration Console のオンライン ヘルプを参照してください。 |
| ヒント : | WebLogic Server ドキュメント「プロダクション再デプロイメントを使用したアプリケーションの更新」では、WebLogic Server 上でデプロイされた、ポータル アプリケーションも含むすべてのアプリケーションに適用されるプロダクションの再デプロイメントの手順について、詳しく説明します。 |
| 注意 : | 最初は管理モードで新しいアプリケーション バージョンをデプロイすることをお勧めします。管理モードは、コンフィグレーションされた管理チャネルを通じてのみ、アプリケーションを利用可能にします。外部のクライアントは、管理モードで配布され、デプロイされたアプリケーションにはアクセスできません。詳細については、WebLogic Server ドキュメントの「管理モードで配布されたアプリケーションの起動」を参照してください。 |
| ヒント : | 使用例など、伝播に関する背景情報については、「伝播方針の開発」を参照してください。 |
次の節では、プロダクションの再デプロイメントで可能なシナリオ、および各シナリオの既知の制限を説明します。
この節では、WebLogic Portal と共にアプリケーションの再デプロイメントを使用するシナリオを説明します。
| 注意 : | データベースに変更が行われていると、プロダクションの再デプロイメントを使用してもロールバックしたりアプリケーションを元の状態に戻したりすることはできません。データベースには、実行時にポータルにより使用されるポータル フレームワークと datasync 要素の表現が含まれています。たとえば、ユーザ カスタマイズおよび資格などの機能の値は、データ ベースに格納されます。 |
この節では、次の再デプロイメント シナリオについて説明します。
非ポータル資産の追加、削除、または更新は、データベースへの変更が必要ではない資産の追加、または削除を参照しています。このシナリオでは、ゼロ ダウンタイムの再デプロイメントを達成するために、プロダクションの再デプロイメントは安全で推奨できる技術です。
| 注意 : | データベース変更、またはバックエンド データ ソースに変更が必要な場合は、どのような場合でもプロダクションの再デプロイメントはお勧めしません。プロダクションの再デプロイメントの使用を決めた場合は、細心の注意を払ってください。まずステージング環境で再デプロイメントを十分にテストします。詳細については、「プロダクションの再デプロイメントによる悪影響」を参照してください。 |
このシナリオでは、データベースの変更が必要な資産は、ポータルの新しいバージョンから追加、または削除します。デプロイメント時に、既存のブックに新しいページを追加するなどしてポータルの構造を変更する場合、変更は自動的にデータベースに適用されます。
このシナリオでは、WebLogic Portal ではプロダクションの再デプロイメントを完全にはサポートしません。これは、アプリケーション データベースのロールバックがサポートされないためです。一度変更を適用すると、WebLogic Portal ではデータベースの変更を元に戻すことができません。
| 注意 : | 伝播ツールを使用してポータル資産を伝播する場合は、常にアプリケーション ロールバックはサポートされません。詳細については、「インポート プロセスのロールバック」を参照してください。 |
このシナリオでは、新しくデプロイされたアプリケーションでは、ポータル資産を伝播する必要がありあす。伝播はポータルのデータベースを変更するため、この場合はアプリケーション ロールバックはサポートされません。伝播の概要については、「伝播方針の開発」を参照してください。
| 注意 : | データベース変更、またはバックエンド データ ソースに変更が必要な場合は、どのような場合でもプロダクションの再デプロイメントはお勧めしません。プロダクションの再デプロイメントの使用を決めた場合は、細心の注意を払ってください。まずステージング環境で再デプロイメントを十分にテストします。詳細については、「プロダクションの再デプロイメントによる悪影響」を参照してください。 |
| 注意 : | 伝播ツールを使用してポータル資産を伝播する場合は、常にアプリケーション ロールバックはサポートされません。詳細については、「インポート プロセスのロールバック」を参照してください。 |
この節では、WebLogic Portal アプリケーションのプロダクションの再デプロイメントに関連するいくつかの問題と制限を説明します。WebLogic Portal アプリケーションでアプリケーションの再デプロイメントを行なう前に、この節を読み返してください。
プロダクションの再デプロイメント プロセスをリバーシングまたは「ロールバック」すると、アクティブな、および廃棄されるアプリケーションの状態を切り替え、それに応じて新しいクライアントの接続リクエストが再送信されます。新たにデプロイされたアプリケーションのバージョンで問題が検出された場合、およびクライアントのアクセスを停止したい場合は、プロダクションの再デプロイメント プロセスを元に戻すことが必要になる可能性があります。アプリケーション ロールバックは、WebLogic Server ドキュメント「プロダクション再デプロイメント プロセスのロールバック」で説明します。
一般に、プロダクションの再デプロイメントでWebLogic Portal データベース エントリに変更を加えた場合は常に、WebLogic Portal プロダクションを再デプロイメントするためにアプリケーション ロールバックがサポートされることはありません。また、新旧のアプリケーションが同じデータベースを共有するため、再デプロイメント中にデータベースが変更されると、これらの変更をロールバックすることはできません。元のアプリケーションのユーザに悪影響を及ぼす恐れがあるからです。
データベース変更が発生するシナリオの詳細および例については、「アプリケーションの再デプロイメントのシナリオ」を参照してください。
プロダクションの再デプロイメント機能では、同時に WebLogic Portal アプリケーションの 2 つのバージョン全体を実装するため、メモリおよび CPU の要件を考慮する必要があります。プロダクションの再デプロイメントに必要なメモリおよび CPU の量を正確に指定するのは不可能ですが、経験からいえば、サーバ上で現在実行中のロードの 2 倍となります。たとえば、アプリケーションで 1 ギガバイトのメモリを消費し、現在の CPU の 40 パーセントを使用している場合、2 つめのバージョンでも同量のメモリと CPU が必用と仮定する必要があります。このため、WebLogic Portal サーバ インスタンス上でのユーザ アクティビティとロードが少ない場合は、プロダクションの再デプロイメント 計画を検討する必要があります。
WebLogic Portal 伝播ツールでは、データベースのロールバックをサポートしません。このため、デプロイメント シナリオで伝播の使用が必要な場合、アプリケーション ロールバックを実行できません。
詳細については、「インポート プロセスのロールバック」を参照してください。
WebLogic Portal アプリケーションのバージョン間では、同一のデータ ストアを使用することをお勧めします。
プロダクションの再デプロイメントを使用する場合、WebLogic Portal ではデータベース スキーマへの変更をサポートしません。
WebLogic Portal のキャッシュ フレームワークは、現在のアプリケーションへのキャッシュ エントリのみを無効にします。 プロダクションの再デプロイメント中に実行されるアプリケーションでは、キャッシュは無効化されません。このため、異なるバージョンのアプリケーション間で古いキャッシュ エントリが表示されることがあります。
プロダクションの再デプロイメントでは、ファイルに基づくコンテンツ リポジトリはサポートされません。
プロダクションの再デプロイメントは、条件式に基づくロール方針を使用するアプリケーションではサポートされません。条件式に基づく定義ロールの詳細については、『WebLogic Portal のセキュリティ ガイド』を参照してください。
| 注意 : | GroupSpace アプリケーションは条件式に基づくロール方針を使用するので、WebLogic Portal は GroupSpace アプリケーションのプロダクションの再デプロイメントをサポートしません。 |
プロダクションの再デプロイメントを使用する場合、WebLogic Portal アプリケーションを依存対象とする外部システムに影響が出る可能性があります。プロダクションの再デプロイメントでは、ユーザが接続されたアプリケーションのバージョン管理に HTTP セッション管理のみを使用するため、以下の非 HTTP フレームワークでは常にアプリケーションの新しい方のバージョンを参照します。
この節では、WebLogic Portal アプリケーションでプロダクションの再デプロイメントを使用した場合の既知の悪影響を示します。この節では、次のトピックについて説明します。
デスクトップへのカスタマイズは、ポータル アプリケーションの新旧バージョンのどちらでもすぐには表示されません。たとえば、管理者がアプリケーションの新しいバージョンでユーザのデスクトップを変更する場合、その変更はすぐに表示されないことがあります。カスタマイズした内容がアプリケーションの古いバージョンのユーザのためにキャッシュされるので、キャッシュがタイム アウトしないかぎり、ユーザには新しいカスタマイズが表示されません。
アプリケーションの新しいバージョンをデプロイする場合、WebLogic Portal はポータルデータベースを変更します。たとえば、古いアプリケーションには存在しないポートレットを新しく追加する場合、データベースは新しいアプリケーションに合わせて更新されます。このため、アプリケーションの古いバージョンを使用中のユーザは、ファイル システム資産が古いバージョンに存在しないので、ポートレットを見ることができてもレンダリング（画像化）することはできません。
資格には LDAP と RDBMS の両方のアーティファクトがあるため、同じデータベースを使用する新旧バージョンのアプリケーションの間で共有されています。これに伴う悪影響の 1 つは、古いアプリケーションでの WebLogic Portal Administration Console 管理者がバージョンの新しいアプリケーションの資格に影響を与える恐れがあることです (その逆の場合も同様です)。
WSRP コンジュｰマでは、ユーザの代わりにプロデューサでセッション状態を維持します。そのため、WSRP ポートレットを使用する外部アプリケーションは、セッションのタイム アウト後、新しいアプリケーション バージョンへ移行します。
システム クラスパスに変更を加えた場合は、常にサーバを再起動する必要があります。
  
|
