機械翻訳について

メタデータ・モデル

目次

概要

メタデータ・モデル(略してモデル)は、WebLogic Serverドメイン構成のバージョンに依存しない記述形式です。 ツール群はスパース・モデルをサポートするように設計されており、モデルは他のアーティファクトを説明する必要がなく、特定の操作に必要なものだけを説明すればよいようになっています。 たとえば、JDBCデータ・ソースに依存するアプリケーションを、他のアプリケーションまたはデータ・ソースを含む可能性がある既存のドメインにデプロイするには、モデルで該当するアプリケーションとデータ・ソースのみを記述する必要があります。 データ・ソースが以前に作成された場合、deployAppsツールはそれを再作成しようとしませんが、モデル説明が既存の値と異なる場合は、そのデータ・ソースの構成の一部を更新できます。 アプリケーションが以前にデプロイされている場合、deployAppsツールはバイナリを比較して、アプリケーションを再デプロイする必要があるかどうかを判断します。

モデル構造とそのフォルダ名および属性名は、WLSTの12.2.1.3オフライン構造および冗長フォルダが削除された名前に基づいて、モデルを単純に保つことができます。 たとえば、JDBCデータ・ソースのURLへのWLSTパスは/JDBCSystemResource/<data-source-name>/JdbcResource/<data-source-name>/JDBCDriverParams/NO_NAME_0/URLです。 モデルでは、resources:/JDBCSystemResource/<data-source-name>/JdbcResource/JDBCDriverParams/URLです(resourcesは、すべてのWebLogic Serverリソース/サービスが記述されている最上位のモデル・セクションです)。

モデルはYAML(またはオプションでJSON)で記述されます。 スネークYAMLに基づくYAMLパーサーは、仕様に関して厳密であり、完全にYAML 1.1準拠です。 たとえば、YAMLではインデント文字としてタブがサポートされていないため、インデントの目的で使用される先行タブがモデル・ファイルに含まれている場合、パーサーは解析エラーを生成します。 一般に、名前と値は引用符なしで指定できます。ただし、YAMLパーサーがテキストではなくマークアップ文字とみなす制限文字のいずれかがコンテンツに含まれる場合を除きます。 たとえば、キーには引用符を使用せずに埋め込まれたハイフンが含まれている場合がありますが、キーがハイフンで始まる場合、パーサーはそれをYAMLリスト要素の開始とみなすことができます。 詳細は、「YAML 1.1の指定」を参照してください。

トップレベルのモデル・セクション

ツールには、5つのトップレベル・モデル・セクションがあります:

  • domainInfo - WLSTで表現されない特別な情報が指定されたロケーション(たとえば、$DOMAIN_HOME/libにあるライブラリ)。
  • topology - サーバー、クラスタ、マシン、サーバー・テンプレートおよびその他のドメイン・レベル構成が指定されているロケーション。
  • resources - リソースおよびサービスが指定されるロケーション(データ・ソース、JMS、WLDFなど)。
  • appDeployments - 共有ライブラリおよびアプリケーションが指定されているロケーション。
  • kubernetes - WebLogic Kubernetes Operatorドメイン構成が指定されているロケーション。
  • verrazzano - Verrazzano WebLogicワークロード・コンポーネントおよびアプリケーション構成が指定されているロケーション。 ノート: Verrazzanoサポートは、WDT 4.0.0で非推奨になりました。

単純な例

アプリケーションとそのデータ・ソースをデプロイするモデルの簡単な例を次に示します:

resources:
    JDBCSystemResource:
        MyDataSource:
            Target: '@@PROP:myjcs.cluster1.name@@'
            JdbcResource:
                JDBCDataSourceParams:
                    JNDIName: jdbc/generic1
                JDBCDriverParams:
                    DriverName: oracle.jdbc.OracleDriver
                    URL: jdbc:oracle:thin:@//@@PROP:dbcs1.url@@
                    PasswordEncrypted: '@@PROP:dbcs1.password@@'
                    Properties:
                        user:
                            Value: '@@PROP:dbcs1.user@@'
                        oracle.net.CONNECT_TIMEOUT:
                            Value: 5000
                JDBCConnectionPoolParams:
                    MaxCapacity: 50
appDeployments:
    Application:
        simpleear :
            SourcePath: wlsdeploy/applications/simpleear.ear
            Target: '@@PROP:myjcs.cluster1.name@@'
            ModuleType: ear
     Library:
        'jsf#2.0':
            SourcePath: '@@WL_HOME@@/common/deployable-libraries/jsf-2.0.war'
            Target: '@@PROP:myjcs.cluster1.name@@'
            ModuleType: war

前述の例は、フレームワークの2つの重要な機能を示しています。 最初に、URL, PasswordEncrypted, userプロパティValueおよびすべてのTargetフィールドに、@@PROP:<name>@@パターンを持つ値が含まれていることに注意してください。 これは、変数ファイルを使用して実行時に値が指定される変数プレースホルダーを示します。 このトークン・タイプとその他のトークン・タイプの詳細は、「モデル・トークン」を参照してください。

次に、jsf#2.0共有ライブラリのSourcePath属性値が@@WL_HOME@@で始まることに注意してください。 これは、ターゲット環境のWebLogic Serverホーム・ディレクトリのロケーションを相対的に指定するために使用できるパス・トークンです。 詳細および使用可能なパス・トークンのリストについては、「モデル・トークン」を参照してください。

上の例は、値がwlsdeploy/applications/simpleear.earのsimpleearアプリケーションの属性SourcePathを示しています。 プレフィクスwlsdeploy/は、リソースが指定のロケーションのアーカイブ・ファイルにあり、ドメイン内のそのディレクトリ(この例では<domain-home>/wlsdeploy/applications/simpleear.ear)にデプロイされることを示します。 アーカイブ・ファイルの使用の詳細は、「アーカイブ・ファイル」を参照してください。

ユーザーは、上記のロケーションの下にさらにディレクトリ構造を作成して、ファイルやディレクトリが適切に表示されるように整理できます。 ターゲット・システムにすでに存在するバイナリは、モデルでターゲット・システムで正しいロケーションが指定されている場合、アーカイブに含める必要はありません。

最後に、フレームワークは、他のツールで使用するためにモデルを拡張できるような方法で記述されています。 他のトップレベル・セクションをモデルに追加することはサポートされており、既存のツールおよびフレームワークでは、それらが無視されます(存在する場合)。 たとえば、SOAコンポジット・アプリケーションが記述されているモデルにsoaCompositesセクションを追加し、それらのバイナリを格納できるアーカイブ・ファイル内のロケーションを追加することで、SOAコンポジットを理解し、デプロイする方法が同じモデルおよびアーカイブ・ファイルに対して実行できるようになります。

モデル名

WebLogic Deploy Toolingは、非常に規定された方法でWebLogic Server構成アーティファクトの名前を処理します。 名前の処理方法を理解するには、最初にWLSTオフライン・ネーミングの基本を理解する必要があります。 WLSTオフラインでは、構成アーティファクトの一般的なカテゴリが2つあります:

  • 別の構成アーティファクト・タイプへのゼロ個以上の参照を保持できるアーティファクト。
  • ゼロまたは別の構成アーティファクトへの参照を保持できるアーティファクト。

たとえば、ドメインにはゼロ以上のJDBCSystemResourceまたはAppDeploymentインスタンスを含めることができますが、単一のSecurityConfigurationアーティファクトのみを含めることができます。 JDBCSystemResourceなどの構成アーティファクトを操作する場合、名前は常にJDBCSystemResource要素のサブ要素としてモデリングされます(次を参照)。 

resources:
    JDBCSystemResource:
        MyDataSource:
            Target: mycluster
            ...
        YourDataSource:
            Target: yourcluster
            ...

上の例では、モデルにJDBCSystemResourceの2つのインスタンスがあります: MyDataSourceおよびYourDataSourceという名前の1つ。 WLSTに精通しているユーザーは、MyDataSource構成へのWLSTオフライン・パスが常に/JDBCSystemResource/MyDataSourceで始まるため、これは多少理解しているように見えます。 このWLSTフォルダには、MyDataSourceにも設定されているName属性があることがよくわかっていない場合があります。 WebLogic Deploy Toolingでは、例に示すように、モデラーがフォルダ・セマンティクスを使用してJDBCSystemRTesource名を設定する必要があります。 フォルダ内のName属性を使用して名前を設定することはできず、このように試行しても機能しません。この場合、Name属性は冗長です。これは、名前がフォルダ名としてすでに指定されているためです。

SecurityConfigurationやJMXなどのアーティファクトを操作する場合、これらのアーティファクトのインスタンスが構成コンテナのみであり、名前には一般的に意味がないため、ドメイン内に複数のインスタンスが存在することはありません。 そのため、次に示すように、WebLogic Deploy Toolingはモデルでこれらの名前を公開しません: 

topology:
    SecurityConfiguration:
        NodeManagerUsername: weblogic
        NodeManagerPasswordEncrypted: welcome1

前述の例に示すように、SecurityConfiguration要素には名前付きサブ要素がないため、JDBCSystemResourceがあります。ただし、SecurityConfiguration属性へのWLSTパスは/SecurityConfiguration/<domain-name>です。 WebLogic Deploy Toolingには組込みルールとナレッジ・ベースがあり、これらの名前の処理方法を制御してこれらのアーティファクトの構成を完了できます。 前のクラスの構成アーティファクトと同様に、フォルダにはほとんどの場合、WLSTで名前を変更するために使用できる Name属性が含まれます。 以前のクラスのアーティファクトと同様に、WebLogic Deploy ToolingではこれらのフォルダでのName属性の使用はサポートされず、Name属性を設定しようとすると適用されません。 通常、Name属性を使用するモデルのロケーションは最上位トポロジ・セクションのみです。これは、WLSTがドメイン名を格納するロケーションにマップするためです。

モデル・トークン

モデルでは、モデルの処理時にテキスト値に置き換えられるトークンを使用できます。 このセクションでは、いくつかのタイプのトークンについて説明します。

「変数トークン」は、構文@@PROP:<variable>@@で宣言されます。 このタイプのトークンは、標準Javaプロパティ・ファイル形式の変数ファイルを使用して実行時に解決される値を表します。 変数は、任意の値および名前に使用できます。 たとえば、Oracle Java Cloud Service内の1つ以上のアプリケーションを含む環境の確立を自動化するために、サービス・プロビジョニングでは、プロビジョニング・スクリプトでサーバー名を指定できません。 たとえば、プロビジョニング後にデプロイされるアプリケーションがJavaシステム・プロパティを指定するためにServer Start引数を微調整する必要がある場合、モデルはサーバー名の代わりに変数プレースホルダーを使用し、プロビジョニングとアプリケーション・デプロイメント間で動的にプロビジョニングされたサーバー名を変数ファイルに移入できます。

「ファイル・トークン」は、構文@@FILE:<filename>@@で宣言されます。 このタイプのトークンは変数トークンに似ていますが、指定されたファイルから読み取られる単一の値を参照します。 たとえば、モデルでは次のようにパスワード属性を参照できます: 

PasswordEncrypted: '@@FILE:/home/me/dbcs1.txt@@'

ファイル/home/me/dbcs1.txtには、次の単一行が含まれます:

password#123

モデルが処理されると、PasswordEncryptedの値はpassword#123に解決されます。 また、ファイル・プレースホルダーを他のタイプのトークンと組み合せて、次のようなファイルの名前とロケーションでのバリエーションを許可することもできます: 

PasswordEncrypted: '@@FILE:/dir/@@PROP:name@@.txt@@'

PasswordEncrypted: '@@FILE:@@ORACLE_HOME@@/dir/name.txt@@'

「環境トークン」は、構文@@ENV:<name>@@で宣言されます。 このタイプのトークンは、システム環境変数<name>を検索し、その値をトークンに置き換えることで解決されます。

シークレット・トークンは、構文@@SECRET:<name>:<key>@@で宣言されます。 このタイプのトークンは、Kubernetesシークレット・ファイルのロケーションを決定し、そのファイルから最初の行を読み取ることによって解決されます。 その行はトークンに置き換えられます。

Kubernetesシークレット・ファイルのロケーションを導出するメソッドは2つあります。 最初のメソッドでは、1つ以上の構成済ルート・ディレクトリを使用し、パス<root-directory>/<name>/<key>のシークレット・ファイルを検索します。

ルート・ディレクトリは、環境変数WDT_MODEL_SECRETS_DIRSを使用して、ディレクトリのカンマ区切りリストとして構成されます。 たとえば、WDT_MODEL_SECRETS_DIRSが/etc/my-secrets,/etc/your-secretsに設定されている場合、トークン@@SECRET:secrets:the-secret@@は次のロケーションを検索します: 

/etc/my-secrets/secrets/the-secret
/etc/your-secrets/secrets/the-secret

これらのファイルのいずれかが見つかると、シークレットはそのファイルから読み取られ、モデルで置き換えられます。

Kubernetesシークレット・ファイルを検索する2番目のメソッドは、環境変数WDT_MODEL_SECRETS_NAME_DIR_PAIRSを使用して、<name>値を特定のディレクトリのロケーションにマップすることです。 たとえば、WDT_MODEL_SECRETS_NAME_DIR_PAIRSがmy-root=/etc/my-secrets,your-root=/etc/your-secretsに設定されている場合、トークン@@SECRET:your-root:the-secret@@は、次のシークレット・ファイルを検索します: 

/etc/your-secrets/the-secret

<name>値に対応するマップされたディレクトリがWDT_MODEL_SECRETS_NAME_DIR_PAIRSにある場合、そのディレクトリはWDT_MODEL_SECRETS_DIRSで指定されたルートより優先されます。

シークレット・ディレクトリにはシークレット・ファイルのみを含めることが重要です。これらのファイルは、使用可能な名前/キーのペアのリストを作成するために調査されるためです。

「パス・トークン」は既知の値を参照するトークンであり、モデルをより移植可能にするために使用できます。 たとえば、モデルは次のようなWebLogicライブラリ・ソース・パスを参照できます: 

SourcePath: '@@WL_HOME@@/common/deployable-libraries/jsf-2.0.war'

パス・トークン@@WL_HOME@@を使用すると、WebLogicインストール・ディレクトリが異なる場合でも、複数の環境でモデルを使用できます。 パス・トークンは、ファイルまたはディレクトリのロケーションを指定するモデル内の任意のロケーションで使用できます。 サポートされているトークンは次のとおりです:

  • @@ORACLE_HOME@@ - WebLogic Serverおよび他のFMW製品がインストールされているロケーション(古いバージョンでは、これはMW_HOMEと呼ばれていました)。
  • @@WL_HOME@@ - WebLogic ServerがインストールされているOracle Home内のロケーション(たとえば、12.1.2+の$ORACLE_HOME/wlserverディレクトリ)。
  • @@DOMAIN_HOME@@ - ツールが動作しているドメイン・ホーム・ディレクトリのロケーション。
  • @@PWD@@ - ツールが起動された現在の作業ディレクトリ。
  • @@TMP@@ - java.io.tmpdirシステム・プロパティによって制御される一時ディレクトリのロケーション。

モデル・セマンティクス

複数の値を持つことができる構成属性をモデリングする場合、WebLogic Deploy Toolingはこれをできるだけたやすいものにしようとします。 たとえば、リソースのTarget属性には、0個以上のクラスタまたはサーバー(あるいはその両方)を指定できます。 このようなリスト属性の値を指定する場合、ユーザーはリストまたはカンマ区切り文字列として自由に指定できます(カンマ区切りはリストに対して唯一認識されます)。 値にカンマを法的に含めることができる属性の場合、アイテムをリストとして指定する必要があります。 それぞれの例を次に示します。 

resources:
    JDBCSystemResource:
        MyStringDataSource:
            Target: AdminServer,mycluster
            JdbcResource:
                JDBCDataSourceParams:
                    JNDIName: jdbc/generic1, jdbc/special1
                ...
        MyListDataSource:
            Target: [ AdminServer, mycluster ]
            JdbcResource:
                JDBCDataSourceParams:
                    JNDIName: [ jdbc/generic2, jdbc/special2 ]
                ...
    WLDFSystemResource:
        MyWldfModule:
            Target: mycluster
            WLDFResource:
                Harvester:
                    HarvestedType:
                        weblogic.management.runtime.ServerRuntimeMBean:
                            Enabled: true
                            HarvestedInstance: [
                                'com.bea:Name=AdminServer,Type=ServerRuntime',
                                'com.bea:Name=m1,Type=ServerRuntime'
                            ]
                ...

前述の例では、Target属性は、カンマ区切り文字列として、リストとして、単一の文字列として、単一のターゲットのみが存在する場合に指定されています。 JNDIName属性は、カンマ区切り文字列およびリストとして指定されます(単一の文字列も機能します)。 一方、各要素にはカンマが含まれているため、HarvestedInstances属性をリストとして指定する必要がありました。

WebLogic Deploy Toolingの主な目標の1つは、ユーザーが特定の状況に必要な構成のみを指定できるスパース・モデルをサポートすることです。 これはツール間で多少異なりますが、一般的にはツールが加算モデルを使用していることを意味します。 つまり、既存のドメインまたはドメイン・テンプレートにすでにあるもの(新しいドメインを作成するときに)は、指定されたモデルにドメインを正確に一致させるのではなく、ツールによって追加されます。 意味のある場合は、複数値属性の値を設定するときに、同様の追加アプローチが使用されます。 たとえば、モデルでアーティファクトのターゲットとしてクラスタmyclusterを指定した場合、ツールによってアーティファクトの既存のターゲット・リストにmyclusterが追加されます。 開発チームは、ナレッジ・ベースでそれに応じてマージする意味のない属性をマークしようとしましたが、ナレッジ・ベース・データ・ファイルに追加の注釈を追加することで、属性ごとにこの動作を無効にできます。 開発チームは、非加算的、コンバージ・トゥ・ザ・モデル・アプローチを必要とする状況を処理する方法と、そのサポート方法についてすでに考えていますが、これはまだウィッシュ・リスト・アイテムです。 これらの要件を持つユーザーは、このサポートについて問題を提起する必要があります。

削除する"名前付きMbean"の宣言

WebLogic Deploy Toolingでは、Create Domain、Update DomainおよびDeploy Applications Toolを使用して、削除するモデル内の名前付きアイテムを指定できます。 名前付きアイテムは、管理対象サーバー、データ・ソース、セキュリティ・レルムなど、ユーザーが指定した名前で区別される複数のインスタンスを持つアイテムです。 削除するアイテムの先頭には、モデル内の感嘆符(!)が付きます。 ノート: Deploy Applications Toolは、WDT 4.0.0で非推奨になりました。

この例では、管理対象サーバーobsoleteServerが削除され、newServerが作成されます:

感嘆符は、名前とともに引用符で囲む必要があります:

    Server:
        '!obsoleteServer':
        newServer:
            ListenAddress: 127.0.0.1
            ListenPort: 9005

この機能は、WebLogic Serverテンプレートで作成されたアイテムを削除することもできます。 たとえば、ベース・テンプレートでは、myrealmというデフォルトのセキュリティ・レルムが作成されます。 ユーザーがカスタム・レルムを宣言することを選択した場合、myrealmは不要です。 この例では、myrealmが削除され、カスタム・レルムnewrealmが作成され、デフォルト・レルムとして宣言されます: 

    SecurityConfiguration:
        DefaultRealm: newrealm
        Realm:
            '!myrealm':
            newrealm:
                AuthenticationProvider:
                ...

この機能は、レルム内の名前付きセキュリティ・プロバイダには適用されません。 これらのアイテムは、オーダーの保守に必要な特別なルールのセットに従います。 詳細は、「セキュリティ・プロバイダのモデリング」を参照してください。

この機能は、アプリケーションのアンデプロイやライブラリの削除に使用できます。

削除するリスト・アイテムの宣言

名前付きmbeanの削除に加えて、リストからアイテムを削除できます。 ほとんどの場合、これはターゲット・リストに含まれます。 

  JMSSystemResource:
      BPMJMSModule:
          Target: soa_cluster,'!AdminServer'

この例では、BPMJMSModuleのAdminServerターゲットがターゲット・リストから削除されます。

複数のモデルの使用

Create Domain、Update Domain、Deploy ApplicationsおよびValidate Model Toolでは、コマンドラインで複数のモデルを指定できます。 例えば: 

$ weblogic-deploy\bin\createDomain.cmd -model_file modelOne,modelTwo,modelThree ...

この場合、モデルは適用前に1つのモデルにマージされます。 各連続したモデルは、前のモデルに追加されます。 エンティティが両方のモデルに存在する場合、属性が結合され、連続するモデルの属性値が優先されます。 結果のモデルは適用前に検証されます。 たとえば、モデル1は次のようになります: 

topology:
    Server:
        m1:
            ListenPort: 7000
            Notes: Server 1
        m2:
            ListenPort: 9000

モデル2は次のようになります:

topology:
    Server:
        m1:
            ListenAddress: myhostname
            ListenPort: 8000
        m3:
            ListenPort: 10000

サーバーm1の属性はマージされ、サーバーm2は変更されないままになり、サーバーm3が追加されます。 結果のモデルは次のようになります: 

topology:
    Server:
        m1:
            ListenAddress: myhostname
            ListenPort: 8000
            Notes: Server 1
        m2:
            ListenPort: 9000
        m3:
            ListenPort: 10000

要素名(@@PROP:my-server@@など)で変数プロパティが使用されている場合、両方のモデルの名前が解決され、一致する要素がマージされます。

複数のモデルと表記の削除

「表記の削除」を使用する名前付き要素では、一致する名前を持つ要素が完全に削除され、前のモデルでは削除表記は行われません。 たとえば、モデル1は次のようになります: 

topology:
    Server:
        m1:
            ListenPort: 7000
            Notes: Server 1
        m2:
            ListenPort: 9000

モデル2は次のようになります:

topology:
    Server:
        '!m2':

結果のモデルは次のようになります:

topology:
    Server:
        m1:
            ListenPort: 7000
            Notes: Server 1

同様に、削除表記のない要素は、以前のモデルで削除表記を持つ一致する名前で要素を完全に置き換えます。 たとえば、モデル1は次のようになります: 

topology:
    Server:
        '!m1':

モデル2は次のようになります:

topology:
    Server:
        m1:
            ListenPort: 7000
            Notes: Server 1

結果のモデルは次のようになります:

topology:
    Server:
        m1:
            ListenPort: 7000
            Notes: Server 1

WDT 1.xから現在のWDTバージョンYAMLファイルへのアップグレード

2.0以降、WebLogic Deploy Toolingには、モデル・ファイルの読取りおよび書込み用のSnakeYAMLパーサーが組み込まれています。 正しく解析するために、既存のモデルに対するいくつかの変更が必要になる場合があります。

  • 「表記の削除」を使用するモデル要素は、一重引用符または二重引用符で囲む必要があります。
topology:
    Server:
        '!ms1':
        ms2:
  • 同じ親の下のモデル要素は、まったく同じレベルにインデントする必要があります。 前のYAMLパーサーはこの制限を適用しませんでしたが、YAMLの標準です。 この例では、各クラスタに4つのスペースがインデントされています。 
topology:
    Cluster:
        cluster1:
            ClientCertProxyEnabled: True
        cluster2:
            WeblogicPluginEnabled: true

  • モデルのkubernetesセクションのオブジェクト・リストは、生成されるドメイン・リソース・ファイルでの表示方法と同様に、ハイフン・リスト形式で指定する必要があります

  • WebLogic Kubernetes Operator

        clusters:
    - clusterName: 'cluster1'
      allowReplicasBelowMinDynClusterSize: true
    - clusterName: 'cluster2'
      allowReplicasBelowMinDynClusterSize: true
    • kubernetesセクションの古い名前付きオブジェクト・リスト形式のサポートは削除され、ハイフン付きリスト形式に変換されないとバリデーション・エラーが発生します。
        clusters:
      'cluster1':
        allowReplicasBelowMinDynClusterSize: true
      'cluster2':
        allowReplicasBelowMinDynClusterSize: true

  • 非推奨の引数-model_sampleは、Model Help Toolから削除されました。 Model Help Toolでは、リリース1.9.2以降、モデル・サンプル形式がデフォルトで使用されています。