| Oracle® Fusion Middleware DockerでのOracle WebLogic Server 12.2.1の実行 12c (12.2.1) E72550-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware DockerでのOracle WebLogic Server 12.2.1の実行 12c (12.2.1) E72550-01 |
|
前 |
次 |
ここでは、オラクル社が提供しGitHubで入手可能なWebLogic Server 12.2.1 Dockerの独自のイメージをビルドするためのDockerfileおよびサポート・スクリプトの使用方法について説明します。
内容は次のとおりです。
開始する前に、「DockerでのWebLogic Serverイメージについて」の説明に従い、使用するインストールのタイプとしてGenericインストーラまたはDeveloperインストーラのいずれかを選択します。次の手順を実行します。
dockerfiles/12.2.1ディレクトリにある必要なWebLogic ServerインストーラおよびJDKをダウンロードします。
/dockerfilesディレクトリに移動し、buildDockerImage.shスクリプトをrootとして実行します。
$ sudo sh buildDockerImage.sh -h
使用方法: buildDockerImage.sh [-d]
この場合、d:は、Developerディストリビューション、または省略した場合はGenericディストリビューションに基づいてイメージを作成します。
|
注意: 出力されるイメージでは、ドメインはあらかじめ構成されていません。Oracle WebLogic Serverインストール・イメージを拡張してOracle WebLogic Serverドメイン・イメージを作成するためのDockerfileとサポート・スクリプトが別途提供されています。 |
Oracle WebLogic Serverインストール・イメージを拡張するカスタムのDockerfileからドメインを作成する方法の理解を助けるために、DeveloperディストリビューションとGenericディストリビューションについて、Oracle WebLogic Server 12c (12.2.1)向けのサンプルがいくつか提供されています。サンプルは、samples/12c-domainディレクトリにあります。
このDockerfileは、oracle/weblogic:12.2.1-dev (Developerディストリビューション)を拡張してイメージを作成します。これは、次の設定でbase_domainを構成します。
JPA 2.1の有効化
JAX-RS 2.0デプロイ済
管理者のユーザー名: weblogic
管理者のパスワード: welcome1
Oracle Linuxのユーザー名: oracle
Oracle Linuxのパスワード: welcome1
WebLogic Serverのドメイン名: base_domain
独自のドメインを作成する、またはドメインを拡張する最善の方法は、WLSTの使用です。Dockerfileコンテナ内でのドメインの作成で使用するWLSTスクリプトは、create-wls-domain.pyです。このスクリプトは、デフォルトでJMSリソースおよびいくつかのその他の設定を追加します。
このスクリプトを独自の設定に調整して、データソースおよび接続プール、セキュリティ・レルム、アーチファクトのデプロイなどを作成できます。また、WLSTを使用して、イメージを拡張して既存のドメインを上書きしたり、新しいドメインを作成することもできます。
WLSTの使用方法の詳細は、「WebLogic Scripting Toolの理解」を参照してください。
ドメインを構成したWebLogic Serverイメージのサンプルをビルドするには、次の手順を実行します。
「DockerでのWebLogic Serverイメージのビルド」で説明する手順に従い、oracle/weblogic:12.2.1-devイメージをビルドしておきます。まだビルドしていない場合、/dockerfilesディレクトリに移動し、buildDockerImage.shスクリプトをrootとして実行します。
$ sudo sh buildDockerImage.sh -d
/samples/12c-domainに移動し、docker buildコマンドを実行します。
$ sudo docker build -t samplewls:12.2.1
docker imagesコマンドを実行して、イメージが正しく作成されたことを確認します。
$ sudo docker images
WebLogic Serverドメイン・イメージを使用してコンテナを起動すると、デフォルトでコンテナ内の管理サーバーが稼働を開始します。デフォルトの管理サーバー名はAdminServer、デフォルトのポート構成は8001、およびデフォルトの管理サーバーのコンテナ名はwlsadminです。単一の同じホスト内で複数のドメインを実行する場合は、管理サーバー名、ポート番号およびコンテナ名を変更する必要があります。
管理サーバーを起動するには、次の手順を実行します。
docker runコマンドを実行します。
$ sudo docker run -d --name=wlsadmin samplewls:12.2.1
ここで、samplewls:12.2.1は、WebLogic Serverドメイン・イメージのタグです。サンプルのDockerfilesでは、startWebLogic.shがデフォルトのCMD (コマンド)として定義されています。
管理サーバー・コンテナのIPアドレスを取得するには、docker inspectコマンドを実行します。
$ sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' wlsadmin
管理サーバーのWebベース・コンソールを、http://xxx.xx.x.xx:8001/consoleから開きます。
|
注意: 複数のWebLogic Serverドメインが同一のホスト上で稼働中の場合(複数の管理サーバーなど)、-nameパラメータ(管理サーバー・コンテナの名前)および-pパラメータ(管理サーバーのポート)を変更します。 |
管理対象サーバー・コンテナには、ノード・マネージャおよびノード・マネージャ内で稼働している管理サーバーがあります。これらの管理対象サーバー・コンテナは、管理サーバーのコンテナ名を使用してリンクする(--linkコマンド)ことにより、管理サーバー・コンテナと通信します。管理サーバーのコンテナ名は、デフォルトでwlsadminです。
同一のホスト上で複数のドメインが稼働する場合、管理サーバーのコンテナ名を一意にする必要があり、管理サーバーのコンテナ名を-nameパラメータを使用して管理対象サーバーのコンテナ名を変更し、-linkコマンドで指定された名前と各管理対象サーバーのコンテナ名が合致するようにしてください。
管理対象サーバー・コンテナを起動するには、次の3つの方法があります。
ノード・マネージャを起動します(手動)。
$ sudo docker run -d --link wlsadmin:wlsadmin <image-name> startNodeManager.sh
ノード・マネージャを起動し、自動的にマシンを作成します。
$ sudo docker run -d --link wlsadmin:wlsadmin <image-name> createMachine.sh
ノード・マネージャを起動し、自動的にマシンを作成して管理対象サーバーを作成します。
$ sudo docker run -d --link wlsadmin:wlsadmin <image-name> createServer.sh
管理対象サーバー・コンテナのサンプルのdocker runコマンドおよび使用可能なパラメータのリストを次に示します。
$ sudo docker run -d -link wlsadmin:wlsadmin \
-p <NM Port>:5556 -p <MS Port>:<MS Port> \
-name=<Container name> \
-e MS_HOST=<Host address where Managed Server container runs> \
-e MS_PORT=<Managed Server port> \
-e NM_HOST=<Host address where Managed Server container runs> \
-e NM_PORT=<Node Manager Port (should match the port in the -p)> \
<image name> \
<createMachine.sh, startNodeManager.sh, createServer.sh>
サポートされているスクリプトには変数のリストが含まれ、表2-1の定義に従い正しく構成する必要があります。
表2-1 スクリプト変数と定義
| 変数 | 定義 |
|---|---|
|
|
管理サーバー デフォルト: |
|
|
デフォルト: Dockerfileのビルドで指定された値(サンプルでは |
|
|
管理サーバーのt3 URL。 デフォルト: |
|
|
作成するマシンの名前。 デフォルト: コンテナの |
|
|
ノード・マネージャにアクセス可能なIPアドレス。 デフォルト: コンテナのIPアドレス |
|
|
ノード・マネージャのポート。 デフォルト: |
|
|
管理対象サーバーにアクセス可能なIPアドレス。 デフォルト: コンテナのIPアドレス |
|
|
管理対象サーバーのポート番号。 デフォルト: |
次のコマンドを使用して、管理対象サーバー・コンテナを実行します。
$ sudo docker run -d -link wlsadmin:wlsadmin -p 5558:5556 --name="wlsnm0" -e NM_HOST="xx.xxx.xx.xxx" -e NM_PORT="5558" samplewls:10.3.6 createMachine.sh
単一ホスト構成をリモート・サーバー(たとえばDevOpsマシンなど)で実行する場合、管理対象サーバーのポートおよびアドレスを次に示すサンプルのように公開する必要があります。
$ sudo docker run -d --link wlsadmin:wlsadmin -p 7003:7003 -e MS_HOST=xx.xxx.xx.xxx -e MS_PORT=7003 samplewls:12.2.1 createServer.sh $ sudo docker run -d --link wlsadmin:wlsadmin -p 7002:7002 -e MS_HOST= xx.xxx.xx.xxx -e MS_PORT=7002 samplewls:12.2.1 createServer.sh
|
注意: 管理対象サーバーが稼働中のホスト・オペレーティング・システムに追加の管理対象サーバーを作成する場合、新しい一意のリスニング・ポートを割り当てる必要があります。これにより、同一のホスト・オペレーティング・システムで稼働する複数の管理対象サーバーが、同じリスニング・ポートでリスニングしないようになります。 |
createServer.shコマンドを使用する場合、次のようにします。
http://admin-container-ip:8001 /consoleから管理サーバー・コンソールにアクセスします。
「ドメイン構造」ツリーで、「環境」を開きます。
「マシン」を選択して「マシンのサマリー」ページを開き、マシンが登録されていることを確認します。
表の登録されたマシンをクリックし、「ノード・マネージャ」タブおよび「サーバー」タブを使用して、ノード・マネージャおよび管理対象サーバーが構成されていることも確認します。
「サーバー」ページを開いて「制御」タブを選択し、サーバーを起動します。
この項では、DockerコンテナでWebLogic Serverイメージを稼働する際の追加の考慮事項について説明します。
Dockerコンテナが再起動されるとIPアドレスが変更されるため、Dockerコンテナで稼働するWebLogic Serversのアドレスが新しくなります。コンテナの再起動前にサーバーと通信していたアプリケーションやその他のサーバーは、通信できなくなります。
これを解決するには、コンテナの再起動後に、DNSサーバーをDockerで構成し、DNS名を使用するようにWebLogic Serverドメインを構成します。
WebLogic Server構成ファイル、サーバー・ログ、ファイル・ストアなどはすべてコンテナ・ファイル・システム内に保存されます。Dockerコンテナが破損すると、ファイル・システム全体が失われます。ファイル・システムが失われないようにするには、次で説明し、図2-1で示すように、2つの方法があります。
データ専用コンテナを使用して、ドメインのファイル・システムを格納します。(図のContainer1およびDataCont-1。)
ホスト・ファイル・システムを使用して、コンテナのローカル・ファイル・システムを格納します(図のContainer2。)
|
注意: 図のContainer0は、ステートレスな単一WebLogic Serverを示します。これが持つ機能は、アプリケーションおよびリソースのデプロイのみで、そのファイル・システムを維持する必要がありません。これが破壊されても、イメージから新しいコンテナを開始することができます。 |
ファイル・システムへの依存を最小限にするために、次のようにすることをお薦めします。
TLogおよびJMSなどのストアをデータベースに保存します。
XAトランザクションを使用する場合、「TLog書込みを使用しないXAトランザクション」を使用すると、TLogへの書き込みを最小限にすることができます。『Oracle WebLogic Server JTAアプリケーションの開発』のトランザクションTLog書込みなしのXAトランザクションに関する項を参照してください。
クラスタ化されたOracle WebLogic Serverは、互いに通信し、また管理サーバーとの間で通信する必要があります。異なるホスト・マシン上で稼働するDockerコンテナには、他のコンテナと直接通信するために必要な可視性およびアクセス権がありません。そのため、複数のホスト・オペレーティング・システムにまたがるWebLogic Server構成の利用は、現時点でサポートされていません。
これを解決するためには、WebLogic Serverドメイン全体を単一ホストで稼働するように構成します。
WebLogic Server汎用インストール・イメージで作成したWebLogic Serverイメージへパッチを適用する、またはアップグレードするには、次の手順を実行します。
WebLogic ServerインストールDockerイメージを拡張し、アップグレードまたはパッチ適用を行います。
Docker cp (copy)コマンドを使用して、ホストまたはデータ専用コンテナの宛先ディレクトリにドメイン・ディレクトリをコピーします。
コンテナを削除します。
拡張されたイメージ(アップグレードまたはパッチ適用による)イメージから、新しいコンテナを実行します。
Docker cp (copy)コマンドを使用して、アップグレードされたコンテナにドメイン・ディレクトリをコピーしなおします。
DockerコンテナおよびLinuxコンテナに関して、次のセキュリティ上の重要な問題があります。
まず、個別のコンテナで実行中のコードを互いに独立して使用できるかどうかが懸念されます。そのような環境でのWebLogic Serverの稼働能力に影響を与える既知の問題は、現時点ではありません。
また、Dockerイメージの提供元に関するセキュリティ上の懸念があります。Dockerイメージは信頼できる提供元のみから入手し、更新の頻度に注意し、Docker Hubの管理の特質について理解する必要があります。
DockerおよびLinuxテクノロジーについて常に最新情報を入手し、そこで発生しているセキュリティ上の問題を認識する必要があります。
Dockerコンテナのデフォルトのネットワーク・モードである「ブリッジ・ネットワーク」では、マルチキャストはサポートされていません。Dockerコンテナのホスト・ネットワークではマルチキャストがサポートされていますが、ホスト・ネットワークのスタックを使用するため、独立性が低下します。Dockerコンテナで稼働する場合、WebLogic Serverクラスタ・プロトコルとしてユニキャストを使用することをお薦めします。
