WebLogic Server アプリケーションのデプロイメント

     前  次    新しいウィンドウで目次を開く     
ここから内容の開始

デプロイメント プランのリファレンスおよびスキーマ

この付録では、WebLogic Server デプロイメント プランに関する追加情報を提供します。内容は以下のとおりです。

 


デプロイメント プランのしくみ

WebLogic Server デプロイメント プランは、アプリケーションを WebLogic Server へのデプロイ用にコンフィグレーションする任意の XML ファイルです。デプロイメント プランでは、WebLogic Server デプロイメント記述子で通常定義するようなプロパティ値を設定したり、WebLogic Server デプロイメント記述子ですでに定義されているプロパティ値をオーバーライドしたりします。アプリケーションをエクスポートするときに、デプロイメント プランは通常、開発中に作成した WebLogic Server デプロイメント記述子内の選択されたプロパティをオーバーライドするよう機能します。

デプロイメント プランを使用すると、管理者はパッケージ化されている WebLogic Server デプロイメント記述子ファイルを変更することなく、アプリケーションの WebLogic Server コンフィグレーションを簡単に変更して、複数のさまざまな WebLogic Server 環境にデプロイできます。コンフィグレーションの変更は、変更する WebLogic Server 記述子プロパティの場所と、それらのプロパティに割り当てる値の双方を定義する、デプロイメント プラン内の変数を追加または変更することによって適用されます。アプリケーションをデプロイしている管理者は、デプロイメント プランを変更するだけで済みます。元のデプロイメント ファイルとデプロイメント記述子は、変更されないままです。

図 D-1 WebLogic Server デプロイメント プラン

WebLogic Server デプロイメント プラン

 


デプロイメント プラン スキーマ

この節では、デプロイメント プラン スキーマを示します。

コード リスト 7-1 デプロイメント プラン スキーマ
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
     targetNamespace="http://www.bea.com/ns/weblogic/90"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns:wls="http://www.bea.com/ns/weblogic/90"
     xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified"
     version="1.0">
  <xsd:import namespace="http://java.sun.com/xml/ns/j2ee"
             schemaLocation="http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd" />
  
<xsd:element name="deployment-plan" type="wls:deployment-planType"/>
<xsd:complexType name="deployment-planType">
    <xsd:sequence>
      <xsd:element name="description"
                   type="xsd:string"
                   minOccurs="0"
                   nillable="true"/>
      <xsd:element name="application-name"
                   type="xsd:string"/>
      <xsd:element name="version"
                   type="xsd:string"
                   minOccurs="0"/>
      <xsd:element name="variable-definition"
                   type="wls:variable-definitionType"
                   minOccurs="0" />
      <xsd:element name="module-override"
                   type="wls:module-overrideType"
                   minOccurs="0"
                   maxOccurs="unbounded"/>
      <xsd:element name="config-root"
                   type="xsd:string"
                   nillable="true"
                   minOccurs="0"/>
    </xsd:sequence>
    <xsd:attribute name="global-variables"
                   type="xsd:boolean"
                   use="optional"
                   default="false"/>
</xsd:complexType>
<xsd:complexType name="variable-definitionType">
  <xsd:sequence>
     <xsd:element name="variable"
                  type="wls:variableType"
                  minOccurs="0"
                  maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
<!--
単一の変数定義
-->
<xsd:complexType name="variableType">
  <xsd:sequence>
    <xsd:element name="name"
                 type="xsd:string"/>
    <xsd:element name="value"
                 type="xsd:string"
                 minOccurs="0"
		 nillable="true"/>
    <xsd:element name="description"
                 type="xsd:string"
                 minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>
<!--
各変数の割り当てには、以下の要素がある
name: 変数を識別する
xpath : uri によって識別される記述子への有効な xpath。xpath は、複数の要素に解決される
description : 任意の説明
-->
<xsd:complexType name="variable-assignmentType">
  <xsd:sequence>
     <xsd:element name="description"
                  type="xsd:string"
                  minOccurs="0"/>
     <xsd:element name="name"
                  type="xsd:string"/>
     <xsd:element name="xpath"
                  type="j2ee:pathType"/>
     <xsd:element name="operation" default="add" minOccurs="0">
        <xsd:simpleType>
          <xsd:restriction base="xsd:string">
            <xsd:enumeration value="add"/>
            <xsd:enumeration value="remove"/>
            <xsd:enumeration value="replace"/>
          </xsd:restriction>
        </xsd:simpleType>
     </xsd:element>
  </xsd:sequence>
</xsd:complexType>
<xsd:complexType name="module-overrideType">
  <xsd:sequence>
    <xsd:element name="module-name"
                 type="xsd:string"/>
    <xsd:element name="module-type"
                 type="xsd:string"/>
    <xsd:element name="module-descriptor"
                 type="wls:module-descriptorType"
                 minOccurs="0"
                 maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
<xsd:complexType name="module-descriptorType">
  <xsd:sequence>
    <xsd:element name="root-element"
                 type="xsd:string"/>
    <xsd:element name="uri"
                 type="j2ee:pathType"/>
    <xsd:element name="variable-assignment"
                 type="wls:variable-assignmentType"
                 minOccurs="0"
                 maxOccurs="unbounded"/>
    <xsd:element name="hash-code"
                 type="xsd:string"
                 minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="external"
                 type="xsd:boolean"
                 use="optional"
                 default="false"/>
</xsd:complexType>
</xsd:schema>

 


デプロイメント コンフィグレーション プロセスについて

アプリケーションのデプロイメント コンフィグレーションは、アプリケーションのライフサイクルにおいて、いくつかの時点で行われる可能性があります。デプロイメント コンフィグレーションの各フェーズでは一般に、さまざまなデプロイメント ファイルの作成と処理が行われます。

  1. デプロイメント コンフィグレーション - 開発中、プログラマはアプリケーションまたはモジュールの J2EE デプロイメント記述子を作成します。プログラマはまた、WebLogic Server デプロイメント記述子も作成して、アプリケーションを WebLogic Server 開発環境にデプロイするためにコンフィグレーションします。
  2. 注意 : WebLogic Server 開発環境の外部で開発されたアプリケーション (たとえばサンプル アプリケーション、または PetStore などサードパーティの J2EE アプリケーション) には、J2EE 記述子しか含まれていない場合があります。
  3. エクスポート コンフィグレーション - アプリケーションを開発からリリースする前に、プログラマまたは設計者は必要に応じて、アプリケーションのデプロイメント コンフィグレーションを WebLogic Server デプロイメント プランにエクスポートできます。コンフィグレーションのエクスポートにより、アプリケーションの WebLogic Server 記述子ファイルで定義済みのデプロイメント プロパティの全部または一部のためのデプロイメント プラン変数が作成されます。
  4. アプリケーションのエクスポートにより、組織における別分野のデプロイヤ (QA チームの技術者、プロダクション管理者など) が、プログラマの開発環境とは異なる環境へ、アプリケーションを簡単にデプロイできるようになります。理想的なデプロイメント プランでは、新しい環境でアプリケーションをデプロイする前にデプロイヤによる変更が必要になる可能性が高いプロパティの完全なリストが提供されます。

  5. デプロイメント時コンフィグレーション - 管理者またはデプロイヤは、対象環境にアプリケーションをデプロイする前に、アプリケーションのコンフィグレーションを行います。デプロイメント時コンフィグレーションでは、組織のデプロイメント コンフィグレーション ワークフローに応じて、開発中に作成された WebLogic Server デプロイメント コンフィグレーション ファイルと同じもの、デプロイメント コンフィグレーション ファイルの修正バージョン、または開発者が以前にこの環境のために作成したカスタム コンフィグレーション ファイルを使用できます。
  6. デプロイメント後コンフィグレーション - アプリケーションが対象環境にデプロイされた後は、管理者またはデプロイヤは新しいデプロイメント プランでの再デプロイによって、または Administration Console を使用した既存のデプロイメント プランの更新および再デプロイによって、アプリケーションを再コンフィグレーションできるようになります。

デプロイメント コンフィグレーションは、アプリケーションのライフサイクルにおけるさまざまな時点で、さまざまな人間によって行われるため、管理者と開発者は互いに協力して、繰り返し実行できるコンフィグレーション ワークフローを組織のために作成する必要があります。詳細については、「一般的なデプロイメント コンフィグレーションのワークフロー」を参照してください。

管理者およびデプロイヤは通常、デプロイメント時またはアプリケーションのデプロイメント後にのみ、デプロイメント コンフィグレーションを実行します。これらの段階において、アプリケーションについて必要とされる追加のコンフィグレーションは、使用可能なコンフィグレーション ファイルによって異なります。「アプリケーションのデプロイメント コンフィグレーションの更新」を参照してください。

 


一般的なデプロイメント コンフィグレーションのワークフロー

デプロイメント プランを使用すると、複数の WebLogic Server 環境にデプロイするためのアプリケーションのコンフィグレーションの、便利かつ繰り返し可能なワークフローを定義できます。プロダクション アプリケーションのためのコンフィグレーション ワークフローには、デプロイ可能なアプリケーションを作成およびパッケージ化する開発および設計チームと、各対象 WebLogic Server 環境の管理者またはデプロイヤとの間で協力が必要です。

組織のための理想的なコンフィグレーション ワークフローは、次の要素によって決まります。

以下の節では、デプロイメント プランの管理、および複数の WebLogic Server ドメインへのアプリケーションのデプロイのための一般的なデプロイメント コンフィグレーション ワークフローについて説明します。

単一のデプロイメント プランを使用するアプリケーション

さまざまなデプロイメント環境の正確なコンフィグレーションを理解している組織では、単一の精密に定義されたデプロイメント プランを使用して、アプリケーションを複数の WebLogic Server ドメインにデプロイできます。単一デプロイメント プランのコンフィグレーション ワークフローは、次のように機能します。

  1. 開発チームは、管理者およびデプロイヤと協力して、すべての対象環境で使用するためのマスター デプロイメント プランを作成します。対象環境の数は、組織の構成によって異なります。共通のデプロイメント環境には、1 つまたは複数の品質保証 (QA) またはテスト ドメイン、ステージング ドメイン、およびプロダクション ドメインが含まれます。
  2. このフェーズでチームが作成するデプロイメント プランは、対象環境ごとに異なると分かっているすべてのコンフィグレーション プロパティの変数を定義します。たとえばこのプランで、環境間で異なっており、アプリケーションがデプロイ可能になる前にコンフィグレーションが必要なリソース名のための空の変数を定義する場合があります。またこのプランでは、デプロイヤが環境において変更するかもしれない共通のチューニング パラメータのデフォルト値を定義することもあります。

    開発中におけるデプロイメント プランの作成の詳細については、「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。

  3. あるバージョンのアプリケーションのリリース準備が整うと、開発チームはそのアプリケーションのデプロイメント ファイルをパッケージ化し、デプロイメント ファイルとマスター デプロイメント ファイルの双方を、各対象環境のデプロイヤに配信します。
  4. 各デプロイヤは、Administration Console を使用してアプリケーションをインストールし、コンフィグレーションに使用するデプロイメント プランを識別します。Administration Console は、対象ドメインで使用可能なリソースに基づき、デプロイメント コンフィグレーション全体を検証します。その後、プランで定義されているコンフィグレーション可能なプロパティ (および、すべての無効なプロパティ) のリストを、編集のためにデプロイヤに提示します。
  5. 図 D-2 単一デプロイメント プランのワークフロー


    単一デプロイメント プランのワークフロー

  6. デプロイヤは、Administration Console を使用して、デプロイメント プランで定義されたプロパティを対話形式でコンフィグレーションします。null 値、または対象 WebLogic Server インスタンスまたはクラスタについて無効な値を持つデプロイメント プラン変数をコンフィグレーションしないと、アプリケーションがデプロイ可能になりません。すでに有効な値を持つデプロイメント プラン変数は、デプロイメント前に変更する必要はありません。
  7. 各環境におけるデプロイヤは、コンフィグレーションを変更できるのはデプロイメント プランで定義されたプロパティのみと制限することに同意しています。それ以上のコンフィグレーション変更が必要な場合、デプロイヤはマスター デプロイメント プランを変更する開発または設計チームに、それらの要求を伝える必要があります。

単一デプロイメント プランのワークフローを使用する利点は、次のとおりです。

全般に、単一デプロイメント プランのワークフローを使用するのは、組織における対象環境が少数かつ詳しく理解されており、各環境で標準化されたデプロイメント コンフィグレーションを簡単にレプリケートする必要がある場合です。

単一デプロイメント プランの所有権および制限事項

単一のデプロイメント プランのワークフローでは、開発または設計チームが、デプロイメント プランの所有権を保持しており、デプロイヤがプランに対して行える変更は、プラン内で定義される変数に限定されていることを前提としています。デプロイヤが、デプロイメント プランで定義されているプロパティのみを変更する場合、それらの変更は変数の更新として、同じデプロイメント プランに書き戻されます。

しかし、WebLogic Server では、デプロイヤが Administration Console を使用して変更できるコンフィグレーション プロパティに関しては、制限を設けていません。デプロイヤが、元来はプラン内で定義されていなかったデプロイメント プロパティをコンフィグレーションする場合、Administration Console は変数エントリが追加された新しいデプロイメント プランを生成し、その新しいプランを、デプロイメントまたは再デプロイメント操作に使用します。これによりデプロイヤが、開発チーム所有のマスター デプロイメント プランとは大幅に異なるデプロイメント プランを使用するという状況が生じる可能性があります。

マスター デプロイメント プランに新しく変更を組み込むには、デプロイヤは Administration Console によって作成されカスタマイズされた、新しいデプロイメント プランを取得します。理想的には、これらの変更は、マスター デプロイメント プランに適用されます。

複数のデプロイメント プランを使用するアプリケーション

頻繁に変更される数多くのデプロイメント環境を有する組織では、複数のデプロイメント プランを備えるコンフィグレーション ワークフローを使用する必要があります。複数デプロイメント プランのワークフローでは、各デプロイメント プランは開発チームではなく、アプリケーションのデプロイヤが所有しています。複数デプロイメント プランのコンフィグレーション ワークフローは、次のように機能します。

  1. 開発チームは、あるバージョンのパッケージ化されたアプリケーション デプロイメント ファイル (J2EE および WebLogic Server 記述子を含む) をリリースします。リソース定義のためのエクスポートされた変数、または共通のチューニング可能なパラメータを備える基本のデプロイメント プランは、これに含めても含めなくてもかまいません。
  2. まずアプリケーションをデプロイする前に、各デプロイヤは、対象環境用にアプリケーションをコンフィグレーションするためのカスタム デプロイメント プランを生成します。
  3. カスタム デプロイメント プランの作成は、テンプレート デプロイメント プランから (またはデプロイメント プランなしで) 開始して、Administration Console を使用しアプリケーションのデプロイメント コンフィグレーションに対話形式による変更を加えることで行えます。Administration Console を使用して加えられた変更は、元のデプロイメント プランに書き戻されるか、またはアプリケーションの新しく生成されたデプロイメント プランに格納されます。

  4. 環境に合わせてデプロイメント コンフィグレーションを定義後、各デプロイヤはカスタム デプロイメント プランを取得して、それをアプリケーションの将来的なデプロイメントに備えて維持します。カスタム コンフィグレーション プランは、必要に応じて新しいバージョンを追跡したり元に戻したりできるように、ソース コントロール システムに格納することをお勧めします。
  5. 図 D-3 複数デプロイメント プランのワークフロー


    複数デプロイメント プランのワークフロー

  6. その後のリリースでは、各デプロイヤはカスタマイズされたデプロイメント プランを使用して、アプリケーションをデプロイメントのためにコンフィグレーションします。カスタマイズされたプランを使用すると、デプロイヤは weblogic.Deployer による会話形式によらないデプロイメント、または WLST による完全自動化されたデプロイメントを実行できます。

複数デプロイメント プランのワークフローを使用する利点は、次のとおりです。

全般に、複数デプロイメント プランのワークフローを使用するのは、組織におけるデプロイメント環境の数が多く、頻繁に変更されるために単一のマスター デプロイメント プランを維持することが困難または不可能である場合です。

複数デプロイメント プランの所有権および制限事項

複数デプロイメント プランのワークフローでは、デプロイヤまたは管理者 (プログラミングまたは設計チームではない) が、アプリケーションのデプロイメント コンフィグレーションを所有および維持することが前提となっています。また、アプリケーションの基本の J2EE コンフィグレーションは滅多に変更されないものと想定されています。これは、J2EE コンフィグレーションに、ある特定の変更が加えられるとデプロイヤのカスタム コンフィグレーション プランが無効になってしまうからです。たとえば、エンタープライズ アプリケーション内のモジュールが追加、削除、または変更された場合、そのモジュールを参照するカスタム デプロイメント プランは無効になります。この場合、各デプロイヤは Administration Console を使用してアプリケーションを対話形式によってコンフィグレーションすることで、カスタム プランを再作成する必要があります。


  ページの先頭       前  次