内容は次のとおりです。
Oracle WebLogicインストール・イメージを構築するには、まず、Oracle LinuxおよびOracle JDKイメージがすでに実行されている必要があります。Docker HubからOracle Linux 6または7イメージを取得します。Oracle JDKイメージを作成するには、GitHub/Oracle JDKからDockerfileをダウンロードします。このDockerファイルは、Oracle Linuxイメージを拡張し、JDKをインストールします。JDKを/OracleJDK/java-x
ディレクトリにダウンロードします。
$ sudo docker build –t oracle/jdk:8
開始する前に、「DockerでのWebLogic Serverイメージについて」の説明に従い、使用するインストールのタイプとしてGenericインストーラまたはDeveloperインストーラのいずれかを選択します。次の手順を実行します。
注意:
出力されるイメージでは、ドメインはあらかじめ構成されていません。Oracle WebLogic Serverインストール・イメージを拡張してOracle WebLogic Serverドメイン・イメージを作成するためのDockerfileとサポート・スクリプトが別途提供されています。
Oracle WebLogic Serverインストール・イメージを拡張するカスタムのDockerfileからドメインを作成する方法の理解を助けるために、DeveloperディストリビューションとGenericディストリビューションについて、Oracle WebLogic Server 12c (12.2.1)向けのサンプルがいくつか提供されています。サンプルは、samples/1221-domain
ディレクトリにあります。
このDockerfileは、oracle/weblogic:12.2.1-dev
(Developerディストリビューション)を拡張してイメージを作成します。これは、次の設定でbase_domain
を構成します。
ドメイン名: base_domain
管理ポート: 8001
管理者のユーザー名: weblogic
管理者のパスワード: welcome1
Oracle Linuxのユーザー名: oracle
Oracle Linuxのパスワード: welcome1
クラスタ名: DockerCluster
管理対象サーバー・ポート: 7001
NodeManagerポート: 5556
JVMメモリー設定: -Xms236m –Xmx512m –XXLMacPermSize=2048m
独自のドメインを作成する、またはドメインを拡張する最善の方法は、WLSTの使用です。Dockerfileコンテナ内でのドメインの作成で使用するWLSTスクリプトは、create-wls-domain.py
です。このスクリプトは、デフォルトでJMSリソースおよびいくつかのその他の設定を追加します。
このスクリプトを独自の設定に調整して、データソースおよび接続プール、セキュリティ・レルム、アーチファクトのデプロイなどを作成できます。また、WLSTを使用して、イメージを拡張して既存のドメインを上書きしたり、新しいドメインを作成することもできます。
WLSTの使用方法の詳細は、「WebLogic Scripting Toolの理解」を参照してください。
WebLogic Serverドメイン・イメージを使用してコンテナを起動すると、デフォルトでコンテナ内の管理サーバーが稼働を開始します。デフォルトの管理サーバー名はAdminServer
、デフォルトのポート構成は8001
、およびデフォルトの管理サーバーのコンテナ名はwlsadmin
です。単一の同じホスト内で複数のドメインを実行する場合は、管理サーバー名、ポート番号およびコンテナ名を変更する必要があります。
管理サーバーを起動するには、次の手順を実行します。
注意:
複数の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 5556:5556 -name="wlsnm0" -e NM_HOST="xx.xxx.xx.xxx" -e NM_PORT="5556" samplewls:12.2.1 createMachine.sh
$ 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
から管理サーバー・コンソールにアクセスします。もう1つの可能なトポロジは、リモート・ホスト上で稼働中のOracle WebLogic Serverと通信する、単一の管理サーバー・コンテナの実行です。ローカルのコンテナIPアドレスのかわりに実行されているホストのIPアドレスをコンテナで推定するよう、-add-host
を使用します。
$ sudo docker run -d -p 8001:8001 -net=host -add-host=hostname: <host ip address where container is running> -name wlsadmin samplewls:12.2.1
このトポロジを機能させるには、次の構成が必要となります。
Dockerコンテナ内の管理サーバーのリスニング・アドレスを構成する必要があります。
リモート・ホスト上の管理サーバーのリスニング・アドレスを構成する必要があります。
クライアントで、ホストIPアドレスを使用して、JNDIルックアップの初期コンテキストを取得する必要があります。
oracle/weblogic:12.2.1-dev
)を拡張して、MedRecアプリケーションがデプロイされるWebLogic Serverドメイン・イメージを作成できます。補助クイック・インストーラは/samples/1221-medrec
にあります。MedRecサンプル・ドメインを作成するには、次の手順を実行します。
Docker 1.9では、複数のマルチホスト・オペレーティング・システムまたは仮想マシンで実行されている複数のコンテナを一緒にネットワーク化する機能が導入されました。Oracle WebLogic Server 12cドメインは、様々な物理ホストまたは仮想マシンに分散されたDockerコンテナで実行されているサーバー上で動作保証されています。このDocker環境では、クラスタ内で実行されているWebLogicサーバーには、WebLogic Serverクラスタのすべての高可用性特性があります(たとえば、セッション複製およびシングルトン・サービス移行)。
Dockerには、そのようなマルチホスト環境を作成してそれらを一緒にネットワーク化することが非常に容易になる、次のような開発されたツールがあります。
Docker Machine: Docker Machineは、仮想ホストにDocker Engineをインストールし、docker-machineコマンドを使用してホストを管理できるツールです。
Docker Swarm: Docker Swarmは、Dockerのためのネイティブ・クラスタリングです。Dockerホストのプールを単一の仮想Dockerホストに変えます。Docker Swarmは標準のDocker APIの役割を果たすため、Dockerデーモンとすでに通信しているツールでは、Swarmを使用して複数のホストを透過的にスケーリングできます。
Docker Overlay Network: Dockers Overlayネットワーク・ドライバでは、より優れたコンテナ分離がまだ提供されている一方で、追加設定なしのマルチホスト・ネットワーキングがネイティブでサポートされています。
Docker Compose: Composeは、マルチコンテナDockerアプリケーションを定義および実行するためのツールです。Composeでは、Composeファイルを使用してアプリケーション・サービスを構成します。その後、単一のコマンドを使用して、構成からすべてのサービスを作成および開始します。
Docker Registry: Registryは、Dockerイメージを格納および配布できる、ステートレスで非常にスケーラブルなサーバー側アプリケーションです。
Consul: Consulを使用すると、サービスの自己登録、およびDNSまたはHTTPインタフェースを介した他のサービスの検出が単純になります。
注意:
Docker 1.10以上を実行するには、UEK4が必要です。
Docker環境で実行されているWebLogic Serverドメインでは、WebLogic Server Domainイメージを拡張してアプリケーション・イメージを作成することで、アプリケーションをデプロイします。サンプルは、/samples/1221-appdeploy
のGitHubで提供されています。サンプル・アプリケーションをデプロイして1221-appdeploy
イメージを作成するために使用されるWLSTスクリプトは、/samples/1221-appdeploy/container-scripts/app-deploy.py
です。デフォルトでは、このスクリプトは、サンプル・アプリケーションをドメイン内のすべてのサーバーにデプロイします。WLSTスクリプトを変更することで独自のアプリケーションをデプロイするか、WLSTを使用して新しいものを作成できます。
アプリケーション・イメージを構築するには、次の手順を実行します。
$ cd ~/docker-images/OracleWebLogic/samples/1221-appdeploy $ sudo docker build -t 1221-appdeploy
Apacheプラグインでは、WebLogicクラスタ内のWebLogic Managedサーバーへのトラフィックを負荷分散できます。各管理対象サーバーはそれ固有のDockerコンテナ内で実行されており、ApacheプラグインWeb層もそれ固有のDockerコンテナ内で実行されています。マルチホスト環境では、トラフィックを、Docker Swarmクラスタ内で実行されている管理対象サーバー・コンテナにルーティングし、Docker Overlay Networkによって一緒にネットワーク化できます。
ApacheプラグインWeb層イメージをカスタムDockerfileから作成する方法のサンプルは、/samples/1221-webtier-apache
にあります。独自のイメージを作成するのに最もよい方法は、環境に合うようDockerfileおよびweblogic.conf
ファイルを編集することです。
Dockerfileは、httpd:2.4イメージを拡張してApacheプラグインをインストールします。WebLogic Web層イメージを構築するには、次の手順を実行します。
$ cd ~/docker-images/OracleWebLogic/samples/1221-webtier-apache $ sudo docker build -t webtier
次のイメージは、複数のホストまたは仮想マシンにわたりOracle WebLogic分散ドメインおよびクラスタを作成する必要があります。
Oracle Linux
Oracle JDKイメージ
WebLogicインストール・イメージ
WebLogicドメイン・イメージ
WebLogicアプリケーション・イメージ
Web層イメージ
WebLogicドメインおよびクラスタを分散するには、コンテナの実行を計画している各ホストにDocker Engineをインストールする必要があります。イメージを実行し、それらのイメージからコンテナを起動します。これらのコンテナを一緒にネットワーク化するために必要なのは、Docker Overlayネットワークのみです。このオーバーレイ・ネットワークには、有効なキー値格納サービスが必要となります。現在、DockerではConsul、EtcdおよびZooKeeper (分散ストア)がサポートされています。それを有効にする手順は、Dockerネットワーキングを参照してください。
別の方法としては、前に説明したDockerツールを使用してWebLogic分散ドメインおよびクラスタを作成できます。Docker MachineはVirtual Boxを起動し、Docker Engineが内部で実行されます。必要な数だけ環境内でDocker Machineを使用できます。マシンを起動するには、次の手順を実行します。
$ docker-machine create
各Docker Machineは、Docker Swarmクラスタに参加し、Docker Overlayネットワークを使用してネットワーク化されます。Docker Registryでは、イメージをレジストリにプッシュしてから、スクリプトを使用して仮想マシンの外部のこれらのイメージからコンテナを実行できます。Docker Swarmの一部である各仮想マシンは、Docker Overlayネットワークを使用して一緒にネットワーク化されます。仮想マシン内で実行されている各コンテナは、Docker Swarm内の別の仮想マシンで実行されている他のコンテナと通信できます。これにより、多数の異なる仮想マシン内のWebLogicサーバーを実行して、複数の仮想マシンにわたりWebLogic Serverドメインまたはクラスタを分散できます。Dockerネットワークを調べるには、次のコマンドを実行します。
$ sudo docker network ls
$ sudo docker network inspect <overlay network name>
前に説明したツールを使用してマルチホスト環境でWebLogic Serverドメインを作成するスクリプトは、/samples/1221-multihost
にあります。bootstrap.sh
スクリプトは、weblogic-orchestrator
とweblogic-master
という2つのDocker Machineを起動します。weblogic-orchestrator
には、コンテナの実行に必要なイメージを登録するDocker Registry、およびサービスの開始に役立つConsulが含まれています。weblogic-master
には、Docker Swarm、Overlay Network、および仮想マシンで実行されるWebLogic管理サーバー・コンテナが含まれています。それら2つのDockerマシンの実行後、appdeploy
イメージが、weblogic-orchestrator
マシン内で実行されているレジストリにプッシュされます。最後に、ブートストラップ・スクリプトによって、ブートストラップ後スクリプトが呼び出されます。このスクリプトでは、レジストリにプッシュされたapp-deploy
イメージから、weblogic-master
マシン内の管理サーバーDockerコンテナが実行されます。
管理対象サーバーを実行する新しいDockerマシンを起動するには、/samples/1221-multihost/create-machine.sh
を呼び出します。新しいDocker MachineはDocker Swarmの一部であり、この仮想マシン内で実行されている管理対象サーバー・コンテナは、Swarm内の他のコンテナとともに、Overlayネットワークを使用してネットワーク化できます。create-machine.sh
スクリプトの実行後は、次のコマンドを呼び出すことで、環境内で実行されているDocker Machineを表示できます。
$ sudo docker-machine ls
app-deploy
イメージから管理対象サーバー・コンテナを起動するには、/samples/1221-multihost/create-container.sh
を呼び出します。管理対象サーバー・コンテナを特定のDockerマシン内で起動する場合は、マシン名をパラメータ(./create-container.sh <machine name>
)として指定します。コンテナは、Swarm内のどのDocker Machineででも起動できます。
Oracle WebLogic Cluster内の管理対象サーバーへの要求を負荷分散するには、ApacheプラグインWeb層を実行するDockerコンテナを作成します。このコンテナは、Docker Swarm内のDocker Machineのいずれかで実行され、Swarm内の他のすべてのコンテナとネットワーク化されます。/samples/1221-multihost/start-webtier.sh
スクリプトは、Swarm内で実行されているすべての管理対象サーバーを検出し、WEBLOGIC_CLUSTER
という文字列を作成し、Web層イメージをレジストリにプッシュし、weblogic-master
マシン上でWeb層コンテナを起動します。WEBLOGIC_CLUSTER
文字列は、Apache Web層コンテナの起動時に環境パラメータとして設定され、weblogic.conf
ファイル内で設定されます。また、Apache Web層コンテナは、weblogic-master
マシンのポート80にバインドされます。
Apache Web層を使用してサンプル・アプリケーションを呼び出します。ブラウザで、weblogic-masterマシンのIPアドレスとポート80を使用します。
http://xxx.xxx.xxx:80/sample
weblogic-master
マシンのIPアドレスを取得するには、次のコマンドを実行します。
$ sudo docker-machine ls
さらにDocker Machine、およびマシン内で実行される管理対象サーバーを作成するには、前の手順を繰り返します。
この項では、Dockerコンテナで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トランザクションに関する項を参照してください。
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クラスタ・プロトコルとしてユニキャストを使用することをお薦めします。