原文はこちら。
https://blogs.oracle.com/weblogicserver/docker-volumes-in-weblogic

---

Background Information

Dockerの世界では、コンテナは一時的（ephemeral）なものです。コンテナは破棄され、交換できます。コンテナ破棄後、コンテナに加えられたすべての変更はなくなります。コンテナのライフサイクルとは独立してデータを保持したい場合は、ボリュームを使用する必要があります。ボリュームは、コンテナファイルシステムの外部に存在するディレクトリです。

Docker Data Volume Introduction

このエントリでは、Dockerデータボリュームの概要を紹介します。なお、WebLogic Server 12.2.1.3イメージに基づいて記載しています。githubにあるスクリプトを使用してイメージを構築できます。

Oracle WebLogic Server on Docker
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/dockerfiles/12.2.1.3

このエントリでは、この基本イメージをデータボリュームの使用方法を説明するためにのみ使用し、WebLogic Serverインスタンスは実際には実行しません。その代わりに、'sleep 3600'でコンテナは6分間稼働させた後に停止します。

Local Data Volumes

Anonymous Data Volumes

匿名データボリューム（anonymous data volume）は、（名前がないとはいえ）一意の名前が内部で自動生成されています。
以下の2方法で匿名データボリュームを作成できます。

• '-v /container/fs/path'

  オプションを付けて

  docker create

  もしくは

  docker run

  でコンテナを作成もしくは開始する。
• Dockerfile内でVOLUME命令を使う
  VOLUME ["/container/fs/path"]

$ docker run --name c1 -v /mydata -d weblogic-12.2.1.3-developer 'sleep 3600'
$ docker inspect c1 | grep Mounts -A 10

[        "Mounts": [
            {
"Name": "625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421",
"Source": "/scratch/docker/volumes/625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421/_data",
"Destination": "/mydata",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
            }
        ],
# ここでボリュームにランダムに生成された名前が付いていることがわかります。
625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421

$ docker volume inspect 625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421

[
    {
"Name": "625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421",
"Driver": "local",
"Mountpoint": "/scratch/docker/volumes/625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421/_data",
"Labels": null,
"Scope": "local"
    }
]     

Named Data Volumes

名前付きデータボリューム（Named data volumes）はDocker 1.9.0以後で利用できます。
名前付きデータボリュームは以下の2方法で作成できます。

• docker volume create --name volume_name

  を使う

• -v volume_name:/container/fs/path

  を付けて、

  docker create

  もしくは

  docker run

  でコンテナを生成もしくは実行する

$ docker volume create --name testv1
$ docker volume inspect testv1

[
    {
"Name": "testv1",
"Driver": "local",
"Mountpoint": "/scratch/docker/volumes/testv1/_data",
"Labels": {},
"Scope": "local"
    }
]

Mount Host Directory or File

既存のホストディレクトリをコンテナに直接マウントできます。
コンテナ稼働中にホストを直接マウントするには

• docker create もしくは docker runで

  -v /host/path:/container/path

  を付けてコンテナを作成もしくは実行する

同様の方法でホストのファイルをマウントできます。

• docker create もしくは docker runで

  -v /host/file:/container/file

  を付けてコンテナを作成もしくは実行する

マウントされたホストディレクトリやファイルはDockerが管理している実際のデータボリュームではないため、docker volume lsを実行しても表示されないこと、また、Dockerfileでホストディレクトリやファイルをマウント出来ないことにご注意ください。

$ docker run --name c2 -v /home/data:/mydata -d weblogic-12.2.1.3-developer 'sleep 3600'
$ docker inspect c2 | grep Mounts -A 8

"Mounts": [
            {
"Source": "/home/data",
"Destination": "/mydata",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
            }
        ],

Data Volume Containers

データボリュームコンテナはデータ専用コンテナです。データボリュームコンテナが作成後、そのコンテナを起動する必要はありません。他のコンテナは--volumes-fromを使用して共有データにアクセスできます。

# step 1: create a data volume container 'vdata' with two anonymous volumes
$ docker create -v /vv/v1 -v /vv/v2 --name vdata weblogic-12.2.1.3-developer 

# step 2: run two containers c3 and c4 with reference to the data volume container vdata
$ docker run --name c3 --volumes-from vdata -d weblogic-12.2.1.3-developer 'sleep 3600'
$ docker run --name c4 --volumes-from vdata -d weblogic-12.2.1.3-developer 'sleep 3600'

Data Volume Plugins

Docker 1.8以降では、ボリュームプラグインをサポートしています。これにより、新しいボリュームドライバでDockerを拡張できます。例えばボリュームプラグインを使用して、iSCSI、NFS、FCなどの共有ストレージサーバーにリモートフォルダを直接マウントできます。別のホストで動作している別のコンテナから同じストレージに同じ方法でアクセスできます。 異なるホストのコンテナが同じデータを共有できます。
さまざまなストレージタイプに対応したプラグインがあります。ボリュームプラグインについては、以下のDockerのドキュメントを参照してください。

Volume plugins
https://docs.docker.com/engine/extend/legacy_plugins/#volume-plugins

WebLogic Persistence in Volumes

WebLogic ServerをDockerで実行する場合、データボリュームの利用にあたって基本的に2つのユースケースがあります。

1. WebLogic Serverのライフサイクルからデータを分離するため、WebLogic Serverコンテナが破棄され、後で再起動または移動された後でもデータを再利用可能
2. 異なるWebLogic Serverインスタンス間でデータを共有するため、（サービス移行時に）必要に応じて相互のデータを復元可能

以下のWebLogic Serverのアーティファクトでデータボリュームの利用が考えられます。

• ドメインホーム・ディレクトリ
• サーバーログ
• JMSやJTAなどの永続ファイルストア
• アプリケーション・デプロイメント

下表にWebLogic Serverのサブシステムが格納するデータを纏めました。

Subsystem or Service	格納されているもの	詳細情報
Diagnostic Service	ログレコード データイベント 収集されたメトリック	Understanding WLDF Configuration （Configuring and Using the Diagnostics Framework for Oracle WebLogic Server）
JMS Messages	永続メッセージと恒久サブスクライバ	Understanding the Messaging Models （Developing JMS Applications for Oracle WebLogic Server）
JMS Paging Store	JMSサーバごとに1個 永続メッセージと非永続メッセージをページング	Main Steps for Configuring Basic JMS System Resources （Administering JMS Resources for Oracle WebLogic Server）
JTA Transaction Log (TLOG)	完了していない可能性がある、サーバーがコーディネートしたコミット済みトランザクションに関する情報 TLOGはデフォルトの永続ストアまたはJDBC TLOGストアに格納可能	Managing Transactions （Developing JTA Applications for Oracle WebLogic Server） Using a JDBC TLog Store （Developing JTA Applications for Oracle WebLogic Server）
Path Service	メッセージ・リソースへのメッセージ・グループのマッピング	Using the WebLogic Path Service （Administering JMS Resources for Oracle WebLogic Server）
Store-and-Forward (SAF) Service Agents	受信SAFエージェントへの再送信のための送信SAFエージェントからのメッセージ	Understanding the Store-and-Forward Service （Administering the Store-and-Forward Service for Oracle WebLogic Server）
Web Services	信頼性のあるWebLogic Web Serviceの呼び出しによるリクエストおよびレスポンスSOAPメッセージ	Using Reliable SOAP Messaging （Programming Advanced Features of JAX-RPC Web Services for Oracle WebLogic Server）
EJB Timer Services	EJBタイマーオブジェクト	Understanding Enterprise JavaBeans （Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server）

WebLogic Serverの各インスタンスをそれぞれのコンテナで実行し、データボリューム内のドメイン構成を共有することをお勧めします。これは、WebLogic Serverでのデータボリュームの基本的な使用例です。ドメインホームが外部ボリュームにある場合、サーバーログもまた既定で外部ボリュームにあります。ただ、サーバーログにはドメインホーム内の他のファイルよりも機密性の高いデータが含まれており、アクセス管理を必要とするため、サーバーログを別のボリュームに配置するよう明示的に構成可能です。
JMSやJTAなどのファイルストアは、外部ボリュームに配置し、共有ディレクトリを使用する必要があります。これは、サービス移行を機能させるためです。インスタンス毎に自動的にファイル名を一意に装飾するため、同一ドメイン内のすべてのデフォルトストアとカスタムストアで同じ共有ディレクトリを使用できます。しかし異なるドメインの場合、ファイル名が衝突する可能性があるため、同じディレクトリの場所を共有できません。同様に、2つの実行中の重複ドメインは、同じディレクトリの場所を共有できません。ファイルが衝突すると、通常はファイルロックエラーが発生し、その結果データが破損する可能性があります。
ファイルストアは、さまざまな目的のために多数のファイルを作成します。 キャッシュファイルとページングファイルは、コンテナファイルシステムにローカルに格納できます。種々のファイルと場所の詳細については、次の表を参照してください。

ストアのタイプ	ディレクトリ構成	未構成のストア・パス	相対ストア・パス	絶対ストア・パス	ファイル名
default	WebLogic Serverデフォルトストア上に構成されたディレクトリ（Using the Default Persistent Storeを参照）	<domainRoot>/servers/<serverName>/data/store/default	<domainRoot>/<relPath>	<absPath>	_WLS_<serverName>NNNNNN.DAT
custom file	カスタムファイルストア上に構成されたディレクトリ（Using Custom File Storesを参照）	<domainRoot>/servers/<serverName>/data/store/<storeName>	<domainRoot>/<relPath>	<absPath>	<storeName>NNNNNN.DAT
cache	DirectWriteWithCache同期書き込みポリシーを持つデフォルトもしくはカスタムファイルストア上に構成されたキャッシュディレクトリ（Tuning Performance of Oracle WebLogic Serverの Tuning the WebLogic Persistent Store を参照）	${java.io.tmpdir}/WLStoreCache/${domainName}/<storeUuid>	<domainRoot>/<relPath>	<absPath>	<storeName>NNNNNN.CACHE
paging	The paging directory configured on a SAFエージェントもしくはJMSサーバ上に構成されたページング・ディレクトリ（Tuning Performance of Oracle WebLogic Serverの Paging Out Messages To Free Up Memory を参照）	<domainRoot>/servers/<serverName>/tmp	<domainRoot>/<relPath>	<absPath>	<jmsServerName>NNNNNN.TMP <safAgentName>NNNNNN.TMP

外部ボリューム内のデータを適切に保護するためには、管理者の責任でこれらのディレクトリに対して適切な権限を設定する必要があります。WebLogic Serverプロセスがボリューム内のデータにアクセスできるようにするには、コンテナを実行しているユーザがボリュームフォルダへの適切なアクセス権を持っている必要があります。

Summary

• ローカルボリュームの利用
  • Docker 1.8.x以前では、（匿名データボリュームを持つ）データボリューム・コンテナの利用を推奨
  • Docker 1.9.0以後では、名前付きデータボリュームの利用を推奨
  • 複数のボリュームを持つ場合、複数コンテナ間で共有するためには、名前付きデータボリュームを持つデータボリュームコンテナの利用を推奨
• 異なるホスト間でデータを共有するためには、まず共有ストレージサーバのフォルダをマウントし、その後一つのボリュームプラグインを選択して、Dockerにマウントする

WebLogic Serverドメインホームをデータボリュームに外出しすることをお勧めします。外出ししたドメインホームは、それぞれが独自のコンテナで実行されている管理サーバーと管理対象サーバーによって共有されている必要があります。高可用性を実現するには、すべての管理対象サーバーが共有データボリューム内のストアを読み書きする必要があります。選択されるデータボリュームの種類は、ストア、ログ、および診断ファイルの永続性を考慮して選択する必要があります。