CoreOS＆Docker環境においてOracle Database 11g Release 2をインストールするためのポイント

運用・管理

技術解説

連載 :

進化を続けるDockerの今を知る

2016年3月23日(水)

世古雅也

データベースの定番であるOracle Databse 11g Release 2を、コンテナ環境に導入する手順を紹介します。

はじめに

筆者はCoreOS＆Docker上に、Oracle Database 11g Release 2 Standard Edition（以下、Oracle11gR2と表記）をインストールする検証を行った。その際、Oracle11gR2のインストールを成功させるためにはポイントが存在することが分かった。本稿では、このOracle11gR2をインストールするためのポイントについて解説する。なお本稿の想定読者は、CentOSにOracle11gR2をインストールした経験がある人とする。

本論に入る前に、本検証を行うことになった背景について軽く説明させていただきたい。弊社にはNablarch Application Frameworkという名称のJava用フレームワークが存在する。本フレームワークは多くのミドルウェアに対応しているため、様々なミドルウェアの組み合わせによるテストを行う必要がある。

機材の都合で、1台のホストに複数のミドルウェアをインストールする必要があるのだが、以下の問題に遭遇しているため、Dockerを検証することとした。

テストの際に生じた課題

遭遇した問題	Dockerに期待すること
当初は複数バージョンで検証する予定がなかったミドルウェアについて、後から複数バージョンでの検証が必要になった際、ミドルウェアごとに環境変数やポートを切り替える方法がアドホックになりがちである。その結果、時間が経つにつれ、クリーンな環境を保つのが難しくなる	環境変数などをコンテナに閉じ込められるため、クリーンな環境の維持が容易になる
上記の対策として、Xen等の仮想環境の使用も検討したが、将来的にIaaSに移行したいため、仮想環境の採用は足かせになる可能性がある。また、テストの際に起動と停止を頻繁に行うことが想定されるため、OSから起動しているとテストの実行時間が長くなってしまう恐れがある	様々なIaaSで使用できるため、将来のIaaSへの移行が容易と思われる。また、起動が速いため、コンテナの起動と停止のせいでテストが遅れることがない
環境変数等の切り替えの都合により、通常とは異なる方法でのインストールを行いがちであるため、ミドルウェアのアンインストールが困難であり、不要になっても放置しがちになる	コンテナとimageを破棄するだけで良いため、アンインストールが簡単になる
環境変数等の切り替えの都合により、通常とは異なる方法でのインストールを行いがちであるため、再インストールが必要になった際に、インストール方法が思い出せず多大な時間が掛かる	DockerFileにインストール手順が記録されるため、再インストールが必要になった際に楽である

以下に、計画したテスト環境の構成図を示す。

最終的に構築したいテスト環境

※Dockerコンテナは一部のみ記載※各コンテナは、使用するときのみ起動する

環境構築に先立ち、いくつかのミドルウェアをコンテナ上で動作させる検証を行い、その対象の一つにOracle11gR2が存在した。Docker Hubを探したところ、Oracle Database Express Edition 11g Release 2をインストールするためのイメージやDockerfileは見つかったものの、Oracle Database 11g Release 2 Standard EditionをインストールするためのDockerfileは見つからなかったため、インストールの段階から検証することとしたのが、今回のテストの背景である。

検証を実施した環境

検証は以下の環境で行った。

さくらのクラウド
ホスト側のOS：CoreOS 766.5.0（さくらのクラウドで提供されている367.1.0からアップデート）
Docker：1.7.1
コンテナ側のOS：CentOS 6.6

作業の手順

作業は以下の手順で行った。

さくらのクラウドでインスタンスを起動する
CoreOS上で、「sudo update_engine_client -update」を実行し、CoreOSをアップデートする
オラクル社のサイトからLinux x86-64用のOracle11gR2のインストーラをダウンロードする。Dokcer上で動作するイメージの多くは64bitOS用であるため、64bit用のインストーラを使用する。ダウンロードしたZIPファイルは、CoreOS上で展開しておく
Oracle11gR2のレスポンスファイルとoraInst.locファイルを用意する。GUIのインストーラを使うためにはXの導入が必要になるため、今回はCLIでインストールする
ホスト側の環境設定を行う。Dockerはカーネルをホストと共有するため、ホスト側でもカーネルのパラメータの設定を行っておく
Dockerfileを用意する。Dockerfileには、Oracle11gR2のインストーラを起動するまでを記述する。Dockerfileにインストーラの起動を記述しないのは、以下の理由による。
・インストーラ実行中、「別のシェルを起動して、rootでスクリプトを実行する」ように求められる箇所があるが、この部分をDockerfileで実現するのは困難であるため
・Oracle11gR2のインストーラの実行条件を整える際に、特権モード（--privilegedオプション）が必要な箇所があるが、docker build実行時は特権モードを指定できないため
docker buildを実行する。実行時には、Dockerfile、Oracle11gR2のインストーラ、レスポンスファイル、oraInst.locを同一ディレクトリに配置しておく
docker runを実行する。この際、Oracle11gR2のインストーラ起動のために、必要な引数をつける必要がある
コンテナ内で環境設定を行う。Oracle11gR2のインストーラ起動に必要である
Oracle11gR2のインストーラを実行する
コンテナの起動と同時に、Oracle11gR2を起動するための設定を行う
コンテナを停止し、コンテナをdocker commitする
作成したimageを使用してOracle11gR2を起動と停止の確認を行う

本稿では、主に手順1、手順5から手順13について解説する。

さくらのクラウドでインスタンス起動

さくらのクラウドで起動するサーバは、以下のスペックを推奨する。

起動するサーバの推奨スペック

項目	値	説明
CPU	1コア以上	仮想化によるオーバーヘッドはそれほど多くないため、1コアでもOracle11gR2は起動できる。必要に応じてコア数を決定すること
メモリ	1GB以上	CoreOSがデフォルトで/tmpに割り当てるサイズは、メモリの半分程度である。後述するが、Oracle11gR2の自動メモリ管理で使用するためにコンテナの/dev/shmに、ホストの/tmpを割り当てる。そのため、必要に応じて本サイズを決めること
ディスク	40GB以上	Oracle11gR2のDockerのImageは、10GB以上になることがある。Imageとコンテナで使用するディスク容量を踏まえると、40GB以上のディスクを使用した方が良い

ホスト側の環境設定

ホスト側では、以下の項目を設定する。

カーネルのパラメータ

Oracle11gR2のインストール要件を満たすために設定が必要である。カーネルのパラメータに対してチューニングを行う際、ホスト側とコンテナ側のどちらにカーネルのパラメータを設定する必要があるのか、Dockerのドキュメントから記述をみつけることができなかった。そのため、本稿ではホストとコンテナの双方に設定することとする。

スワップ領域

Oracle11gR2のイストーラー起動時の環境チェックに合格するために必要。検証の結果、ホストに設定したスワップ領域をコンテナが使用することが分かっているため、ホストにスワップ領域を割り当てる（CoreOSは、デフォルトではスワップ領域を割り当てない）。

CoreOSを使用したホストにカーネルのパラメータを設定する方法を、以下に示す。

/usr/share/oem/cloud-config.ymlを編集する

追記する内容の例は、以下の通りだ。

リスト1：

01coreos:
02  units:
03    - name: systemd-modules-load.service
04      command: restart
05    - name: systemd-sysctl.service
06      command: restart
07 
08write_files:
09  - path: /etc/modules-load.d/nf.conf
10    content: |
11      nf_conntrack
12  - path: /etc/sysctl.d/nf.conf
13    content: |
14        kernel.shmall = 1073741824
15        kernel.shmmax = 536870912
16        kernel.shmmni = 4096
17        kernel.sem = 250 32000 100 128
18        fs.file-max = 6815744
19        fs.aio-max-nr = 1048576
20        net.ipv4.ip_local_port_range = 9000 65500
21        net.core.rmem_default = 262144
22        net.core.rmem_max = 4194304
23        net.core.wmem_default = 262144
24        net.core.wmem_max = 1048576

ホストを再起動する

設定値の確認

/proc/sys/以下の値を表示して、設定値が有効になっていることを確認する。例えば、kernel.shmallの値を確認する際は以下のようになる。

リスト2：

`1`	`$ cat /proc/sys/kernel/shmall`

`2`	`1073741824`

CoreOSを使用したホストにスワップ領域を割り当てる方法を以下に示す。今回はディスク容量の都合で512MBを割り当てることとした。

ファイルの作成

スワップ領域として使用するためのファイルを作成する。

リスト3：

1$ sudo fallocate -l 512m /512MiB.swap
2$ sudo chmod 600 /512MiB.swap
3$ sudo chattr +C /512MiB.swap
4$ sudo mkswap /512MiB.swap

設定ファイルの作成

ホストOS起動時にスワップ領域をマウントするため、systemdの設定ファイルを作成する。設定ファイルは/etc/systemd/system/swap.serviceというファイル名で作成した。

リスト4：

01[Unit]
02Description=Turn on swap
03 
04[Service]
05Type=oneshot
06Environment="SWAPFILE=/512MiB.swap"
07RemainAfterExit=true
08ExecStartPre=/usr/sbin/losetup -f ${SWAPFILE}
09ExecStart=/usr/bin/sh -c "/sbin/swapon $(/usr/sbin/losetup -j ${SWAPFILE} | /usr/bin/cut -d : -f 1)"
10ExecStop=/usr/bin/sh -c "/sbin/swapoff $(/usr/sbin/losetup -j ${SWAPFILE} | /usr/bin/cut -d : -f 1)"
11ExecStopPost=/usr/bin/sh -c "/usr/sbin/losetup -d $(/usr/sbin/losetup -j ${SWAPFILE} | /usr/bin/cut -d : -f 1)"
12 
13[Install]
14WantedBy=multi-user.target

設定ファイルの有効化

作成した設定ファイルを有効化するために、以下のコマンドを実行する。

リスト5：

`1`	`$ sudo systemctl enable swap.service`

再起動

ホストを再起動する。

確認

再起動後、cat /proc/meminfoを実行してスワップ領域が割り当てられていることを確認する。SwapTotalの項に、割り当てたスワップファイルの容量が表示される。

リスト6：

1$ cat /proc/meminfo
2（中略）
3SwapTotal:        524284 kB
4SwapFree:         520796 kB

Dockerfileの準備

Dockerfileでは以下の処理を行う。1. ベースとなるイメージの指定。今回は、CentOS 6.6のオフィシャルイメージを使用することとした2. Oracle11gR2のインストールに必要なパッケージのインストール3. Oracle11gR2のインストールに必要なOSのユーザとグループの作成4. Oralce11gR2のインストール先ディレクトリの作成と権限付与5. インストーラ等のコンテナへのコピー

Oracle11gR2のインストールに必要となるパッケージは、「Oracle Databaseインストレーション・ガイド」の「Linux x86-64のOracle Databaseパッケージ要件」の項を参考に調査した。パッケージのインストール部分を、Dockerfileから抜粋する。

リスト7：

01RUN \
02yum -y install \
03binutils \
04compat-libcap1 \
05compat-libstdc++ \
06compat-libstdc++-33 \
07compat-libstdc++-33.i686 \
08gcc \
09gcc-c++ \
10glibc \
11glibc-devel \
12glibc.i686 \
13ksh \
14libgcc \
15libstdc++ \
16'libstdc++.so.5' \
17libstdc++-devel \
18libaio \
19libaio-devel \
20make \
21sysstat

「Oracle11gR2のインストールに必要なOSのユーザとグループの作成」については、ちょっとしたテクニックが存在する。通常、対話なしにパスワードを設定したユーザを作成するには、暗号化済みのパスワードを作成しておいてそれをuseraddの引数に設定する。セキュリティ的に平文で保存しても構わない場合は、ユーザ作成後chpasswdでパスワードを設定することで、パスワードを平文で記述することが出来る。以下に、ユーザ作成とパスワード設定の例を示す。以下の例では、Oracleのホームディレクトリにインストールを行うため、所有者とパーミッションの設定も併せて行っている。

リスト8：

1RUN \
2groupadd oinstall && \
3groupadd dba && \
4groupadd oper && \
5useradd -g oinstall -G dba,oper -d /opt/oracle -s /bin/bash oracle && \
6echo 'oracle:oracle' | chpasswd && \
7chown -R oracle:oinstall /opt/oracle && \
8chmod -R 755 /opt/oracle

インストーラ等のコンテナへのコピーについては、いったんコンテナ内の作業用ディレクトリにコピーしたのちに、必要なものについてはさらに別の場所にコピーしている。いったん作業用ディレクトリにコピーする必然性はないが、その方がDockerfileの構造についてわかりやすく感じるため、そのようにした。

リスト9：

1ADD database /data/database/
2ADD db_install.rsp /data/
3RUN chmod 777 -R /data/
4 
5RUN \
6cp /data/oraInst.loc /etc && \
7chown oracle:oinstall /etc/oraInst.loc && \
8chmod 664 /etc/oraInst.loc

docker buildの実行

Dockerfile、Oracle11gR2のインストーラ、レスポンスファイル、oraInst.locを一つのディレクトリに揃えたのち、docker buldを実行する。以下にコマンドの例を示す。

リスト10：

1$ ls
2Dockerfile  database  db_install.rsp  oraInst.loc
3$ docker build -t oracle11g .

docker runの実行

イメージの作成が終わったら、docker runでコンテナを起動する。起動時に、以下の環境設定を行う。

Dockerの特権モードを指定

コンテナ内でのmountコマンドの実行および、カーネルのパラメータを書き換える際に必要となる。

プロセス数のリミットの設定

Oralceの推奨設定を満たすために設定する必要がある。docker run時にrootユーザ用の設定を行う。Docker 1.6からは、--ulimitオプションで設定可能になった。

/dev/shmの割り当て

Oracleの自動メモリ管理を使用する際に必要な設定である。

「/dev/shmの割り当て」について補足する。コンテナの/dev/shmにはデフォルトで64MBが割り当てられているが、これではOracle11gR2の自動メモリ管理を使用するためには小さすぎる。

コンテナの/dev/shmを増やすためには、ファイルシステムが「tmpfs」となっているホストのディスク領域を割り当てる。ファイルシステムの確認のために、ホストでdfコマンドを実行した結果を以下に示す。

リスト11：

01$ df -hT
02Filesystem     Type      Size  Used Avail Use% Mounted on
03rootfs         rootfs     38G   17M   38G   1% /
04devtmpfs       devtmpfs  489M     0  489M   0% /dev
05tmpfs          tmpfs     500M     0  500M   0% /dev/shm
06tmpfs          tmpfs     500M  224K  499M   1% /run
07tmpfs          tmpfs     500M     0  500M   0% /sys/fs/cgroup
08/dev/vda9      btrfs      38G   17M   38G   1% /
09/dev/vda3      ext4     1008M  288M  670M  31% /usr
10tmpfs          tmpfs     500M     0  500M   0% /tmp
11tmpfs          tmpfs     500M     0  500M   0% /media
12/dev/vda6      ext4      108M   56K   99M   1% /usr/share/oem

/tmpがtmpfsなので、コンテナの/dev/shmをそこに割り当てることとする。

環境設定を行った状態でのdocker runのコマンド例は以下の通りである。

リスト12：

`1`	`$ docker run --privileged --ulimit nproc=2047:16384 --name oracle11g -v /tmp:/dev/shm -it oracle11g sh`

コンテナ内の環境設定

docker runでコンテナを起動後、コンテナ内で以下の設定を行う。

カーネルパラメータの設定
インストールに使用するユーザ（oracleユーザ）に対する、プロセス数のソフトリミットの設定

カーネルパラメータは、通常は/proc以下に値を書き込めないため設定できない。/proc以下に値を書き込むには二つ方法が存在する。

/procを読み書き可能として再マウントする
ホストの適当なディレクトリを/procとしてマウントする

今回は、項番1の方法でカーネルパラメータの設定を行った。以下にカーネルパラメータの設定のためのコマンドを示す。

リスト13：

1# mount -o remount,rw -t proc /proc /proc
2# echo 250 32000 100 128 > /proc/sys/kernel/sem
3# echo 128 > /proc/sys/kernel/shmmni
4# echo 536870912 > /proc/sys/kernel/shmmax
5# echo 2097152 > /proc/sys/kernel/shmall
6# echo 9000 65500 > /proc/sys/net/ipv4/ip_local_port_range

docker run時の--ulimit引数で設定したプロセス数のソフトリミットは、コンテナに入った後、suで切り替えたユーザには値が引き継がれない。インストール前にoracleユーザに切り替えるため、再設定が必要となる。以下にoracleユーザに切り替えた後、ソフトリミットを設定するためのコマンドを示す。

リスト14：

`1`	`# su - oracle`

`2`	`$ ulimit -S -u 2048`

Oracle11gR2のインストーラの実行

Oracle11gR2のインストーラを起動する前に、database/stage/cvu/cvu_prereq.xmlのRUNLEVELの設定を編集する。これは、Oracle11gR2のインストーラがランレベルを厳格にチェックし過ぎるためである。インストーラが存在するディレクトリに移動して、以下のコマンドを実行する。

リスト15：

`1`	`$ sed -i -e 's/<RUNLEVEL>/<RUNLEVEL SEVERITY="IGNORABLE">/g' stage/cvu/cvu_prereq.xml`

Oracle11gR2のインストーラは、以下の例のようにレスポンスファイルのパスを指定して起動する。

リスト16：

`1`	`$ ./runInstaller -silent -responseFile /data/db_install.rsp`

インストーラ実行中、以下のメッセージが表示される。その際には、別のコンソールからdocker execコマンドでコンテナに入って、メッセージ中で指定されているスクリプト（/opt/oracle/product/11.2/root.sh）を実行しよう。

リスト17：

01The following configuration scripts need to be executed as the "root" user.
02 #!/bin/sh
03 #Root scripts to run
04 
05/opt/oracle/product/11.2/root.sh
06To execute the configuration scripts:
07         1. Open a terminal window
08         2. Log in as "root"
09         3. Run the scripts
10         4. Return to this window and hit "Enter" key to continue

インストーラの実行終了までには、筆者の環境で30分前後掛かった。インストール中に問題があった場合には、「<インベントリのディレクトリ>/logs/」に存在するログを確認すると良い。インベントリのディレクトリは、レスポンスファイル内でINVENTORY_LOCATIONというキーで指定しているはずである。

Oracle11gR2起動の設定

起動の設定として以下を行う。

/etc/oratabと/etc/rc.d/init.d/dboraの準備
docker run 時に実行するシェルスクリプトの実装

自動起動を有効にするために、/etc/oratabを編集する。以下のように最終行の末尾の「N」を「Y」にする。

リスト18：

01#
02 
03# This file is used by ORACLE utilities.  It is created by root.sh
04# and updated by the Database Configuration Assistant when creating
05# a database.
06 
07# A colon, ':', is used as the field terminator.  A new line terminates
08# the entry.  Lines beginning with a pound sign, '#', are comments.
09#
10# Entries are of the form:
11#   $ORACLE_SID:$ORACLE_HOME:<N|Y>:
12#
13# The first and second fields are the system identifier and home
14# directory of the database respectively.  The third filed indicates
15# to the dbstart utility that the database should , "Y", or should not,
16# "N", be brought up at system boot time.
17#
18# Multiple entries with the same $ORACLE_SID are not allowed.
19#
20#
21xe:/opt/oracle/product/11.2:Y

/etc/rc.d/init.d/dboraは、Oracle Database管理者リファレンスを参考に、以下のように実装した。ポイントは、dbstart実行前に、プロセス数のソフトリミットを設定することである（ハードリミットはコンテナ起動時に毎回設定するか、dockerデーモン起動時に設定しておく）。

リスト19：

01#! /bin/sh  -x
02#
03# Change the value of ORACLE_HOME to specify the correct Oracle home
04# directory for your installation.
05 
06ORACLE_HOME=/opt/oracle/product/11.2
07#
08# Change the value of ORACLE to the login name of the
09# oracle owner at your site.
10#
11ORACLE=oracle
12 
13#
14case $1 in
15'start')
16        su - $ORACLE -c "ulimit -S -u 2048 && ${ORACLE_HOME}/bin/dbstart ${ORACLE_HOME}"
17        ;;
18'stop')
19        su - $ORACLE -c "${ORACLE_HOME}/bin/dbshut ${ORACLE_HOME}"
20        ;;
21*)
22        echo "usage: $0 {start|stop}"
23        exit
24        ;;
25esac
26#
27exit

実装後は、rootユーザで実行できるように権限を付与する。以下に例を示す。

リスト20：

`1`	`# chmod u+x /etc/rc.d/init.d/dbora`

docker run時に実行するシェルスクリプトでは、以下の処理を行う。

カーネルのパラメータの設定

カーネルのパラメータは、dockerのimageに記録されないため、コンテナ起動時に毎回設定する。

listener.oraに含まれるホスト名の置換

コンテナ起動時にホスト名が決まるため、listener.oraに記載されているホスト名に置換する。

Oracle11gR2の起動処理

docker stop時にOracle11gR2を停止する設定

docker stop時、dockerはフォアグラウンドのプロセスにしかシグナルを送らない。そのため、フォアグラウンドのプロセスがシグナルを受信したらOracle11gR2を停止するように実装を行う。この設定をしない場合は、コンテナ停止前に手動でOracle11gR2を停止する必要がある

以下に実装例を示す。

リスト21：

01#!/bin/sh
02mount -o remount,rw -t proc /proc /proc
03echo 250 32000 100 128 > /proc/sys/kernel/sem
04echo 4096 > /proc/sys/kernel/shmmni
05echo 536870912 > /proc/sys/kernel/shmmax
06echo 2097152 > /proc/sys/kernel/shmall
07echo 9000 65500 > /proc/sys/net/ipv4/ip_local_port_range
08 
09sed -i -E "s/HOST = [^)]+/HOST = $HOSTNAME/g" /opt/oracle/product/11.2/network/admin/listener.ora
10chown oracle:oinstall /opt/oracle/product/11.2/network/admin/listener.ora
11/etc/rc.d/init.d/dbora start
12trap "/etc/rc.d/init.d/dbora stop && exit" SIGTERM
13while true
14do
15    sleep 10
16done

実装後は、rootユーザで実行できるように権限を付与する。以下に例を示す。

リスト22：

`1`	`# chmod u+x /root/start.sh`

また、oracleユーザの.bash_profileについても編集しておく。以下に例を示す。

リスト23：

01# .bash_profile
02 
03# Get the aliases and functions
04if [ -f ~/.bashrc ]; then
05        . ~/.bashrc
06fi
07 
08# User specific environment and startup programs
09 
10PATH=$PATH:$HOME/bin
11 
12export ORACLE_BASE=/opt/oracle
13export ORACLE_HOME=$ORACLE_BASE/product/11.2
14export ORACLE_SID=xe
15export PATH=$PATH:$ORACLE_HOME/bin
16export LD_LIBRARY_PATH=$ORACLE_HOME/lib

コンテナの停止とdocker commit

コンテナ内で各種設定が終わったら、インストール時に自動的に起動したOracle11gR2を停止したのちに、コンテナを停止する。以下にOracle11gR2の停止とコンテナの停止を行うコマンドの例を示す。

リスト24：

01$ export ORACLE_BASE=/opt/oracle
02$ export ORACLE_HOME=$ORACLE_BASE/product/11.2
03$ export ORACLE_SID=xe
04$ export PATH=$PATH:$ORACLE_HOME/bin
05$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib
06$ sqlplus / as sysdba
07 
08SQL*Plus: Release 11.2.0.1.0 Production on Sat Nov 21 13:13:49 2015
09 
10Copyright (c) 1982, 2009, Oracle.  All rights reserved.
11 
12 
13Connected to:
14Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
15 
16SQL> SHUTDOWN IMMEDIATE
17Database closed.
18Database dismounted.
19ORACLE instance shut down.
20SQL> exit
21$ exit　← oracleユーザでのexit
22# exit　← rootユーザでのexit

コンテナ起動時にshを指定しているはずなので、rootユーザでexitを実行した際に、シェルと同時にコンテナが終了するはずである。

コンテナを停止したらimageをコミットする。コミットする際には、コンテナ開始時に起動するスクリプトも併せて指定する。以下にコマンドの例を示す。

リスト25：

`1`	`$ docker commit --change 'CMD ["/root/start.sh"]' oracle11g oracle11g`

コミットをしたら、imageが保存されていることを確認するために「docker images」を実行する。

リスト26：

1$ docker images
2REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
3oracle11g           latest              f5dd49b35162        24 hours ago        11.1 GB
4centos              6.6                 12c9d795d85a        5 weeks ago         202.6 MB

作成したimageを使用してのOracle11gR2の起動と停止

コミットしたimageを使用してコンテナを起動する際はdocker runを使用する。oracle11gR2の起動と、プロセスの起動を確認した際の例を示す。

リスト27：

01$ docker run --privileged --name oracle11g -d -p 1521:1521 -v /tmp:/dev/shm -it oracle11g
02a08af9dde97c54478a59ce0966b9186e46591bc1f3c1587b409fc0d9093dde92
03$ docker ps
04CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                              NAMES
05a08af9dde97c        oracle11g           "/root/start.sh"    4 seconds ago       Up 3 seconds        0.0.0.0:1521->1521/tcp             oracle11g
06$ ps aux | grep ora.*xe.*
07core     14762  0.0  4.6 612512 47464 ?        Ss   15:15   0:00 ora_pmon_xe
08core     14764  0.0  3.8 610268 39808 ?        Ss   15:15   0:00 ora_vktm_xe
09core     14768  0.0  3.8 610268 39732 ?        Ss   15:15   0:00 ora_gen0_xe
10core     14770  0.0  3.8 610268 39776 ?        Ss   15:15   0:00 ora_diag_xe
11core     14772  0.0  6.1 610268 62340 ?        Ss   15:15   0:00 ora_dbrm_xe
12core     14774  0.0  4.0 610268 41492 ?        Ss   15:15   0:00 ora_psp0_xe
13core     14776  0.0  4.4 610780 45084 ?        Ss   15:15   0:00 ora_dia0_xe
14core     14778  0.0  4.4 610268 45772 ?        Ss   15:15   0:00 ora_mman_xe
15core     14780  0.0  4.6 616148 47616 ?        Ss   15:15   0:00 ora_dbw0_xe
16core     14782  0.0  4.6 625820 47360 ?        Ss   15:15   0:00 ora_lgwr_xe
17core     14784  0.0  4.4 610780 45592 ?        Ss   15:15   0:00 ora_ckpt_xe
18core     14786  0.0  6.7 610784 69048 ?        Ss   15:15   0:00 ora_smon_xe
19core     14788  0.0  6.2 610780 63720 ?        Ss   15:15   0:00 ora_reco_xe
20core     14790  0.2 11.0 616060 112480 ?       Ss   15:15   0:00 ora_mmon_xe
21core     14792  0.0  4.6 610268 47976 ?        Ss   15:15   0:00 ora_mmnl_xe
22core     14794  0.0  3.8 616392 39504 ?        Ss   15:15   0:00 ora_d000_xe
23core     14796  0.0  3.6 611332 36908 ?        Ss   15:15   0:00 ora_s000_xe
24core     14826  0.0  4.2 610268 43432 ?        Ss   15:16   0:00 ora_qmnc_xe
25core     14907  0.1  9.8 614876 100744 ?       Ss   15:16   0:00 ora_cjq0_xe
26core     14936  0.0  6.7 610776 69272 ?        Ss   15:16   0:00 ora_q000_xe
27core     14938  0.0  4.7 610264 49004 ?        Ss   15:16   0:00 ora_q001_xe
28core     14964  0.0  0.0   4404   776 pts/0    S+   15:17   0:00 grep --colour=auto ora.*xe.*

上記の手順で起動しない場合は、以下の点を確認しよう。

/tmp内の確認

ホストの/tmpに、「ora」から始まる名前のファイルが大量に存在していないか確認する。Oracle11gR2が異常終了した際、/tmpにゴミが残るため/tmpの空きが不足して起動に失敗することがある。

エラーメッセージの確認

docker run時にshを指定して起動し、コンテナに入ってからスタートアップスクリプトを実行して、何かエラーメッセージが表示されていないか確認する。以下に実行例を示す。

リスト28：

`1`	`$ docker run --privileged --name oracle11g -p 1521:1521 -v /tmp:/dev/shm -it oracle11g sh`

`2`	`# /root/start.sh`

停止はホスト上でdocker stopを実行する。この際に-tオプションを指定してタイムアウト時間を長めに指定する必要がある。デフォルトでは10秒で強制終了してしまうためである。以下にタイムアウトを120秒にする例を示す。

リスト29：

`1`	`$ docker stop -t 120 oracle11g`

満たせていないインストール要件について

今回のテストでは、Oracle11gR2のインストール要件のうち、以下のカーネルパラメータについては設定できていない。

net.core.rmem_default
net.core.rmem_max
net.core.wmem_default
net.core.wmem_max

おそらくDockerのネットワーク機能の都合で設定できないと思われるのだが、詳細は不明である。

まとめ

CoreOS＆Docker環境へのOracle11gR2のインストールは可能であった。このことから、フレームワークの動作確認を行うという目的は達成と言える。

一方、問題解決については、うまく出来たことと、出来なかったことがあった。以下に振り返りを記載する。

振り返り

Dockerに期待すること	達成状況	説明
環境変数などをコンテナに閉じ込めることができるため、クリーンな環境の維持が容易になる	△	環境変数、ディレクトリ、ポートはコンテナに閉じ込めることが出来たため、ほぼ実現できた。しかし、カーネルパラメータについてはホストへの設定要否について謎が残った。ただし、カーネルパラメータについては、使用するDBの最小公倍数的な設定を行い、「DBはDB専用のホストで起動する」と割り切ってしまえば大きな問題はないと思われる
様々なIaaSで使用できるため、将来のIaaSへの移行が容易と思われる。また、起動が速いため、コンテナの起動と停止のせいでテストが遅れることがない	○	今回さくらのクラウド上でCoreOS＆Dockerを使用したが、特に問題は感じなかった。また、Dockerコンテナ起動も高速であり期待通りであった。
直接Dockerとは関係ない気付きであるが、ホスト側OSに採用したCoreOSの起動は大変高速で、ホスト側の再起動が必要になった際も快適であった
コンテナとimageを破棄するだけで良いため、アンインストールが簡単になる	○	ミドルウェアのアンインストールについては、「docker rm」と「docker rmi」を実行すれば終わるため、期待通り簡単に行える。一方、操作ミスでうっかり消してしまわないように、大事なimageはバックアップを取得するか、Dockerプライベートリポジトリにコミットする等の工夫を行ったほうが良い。
DockerFileにインストール手順が記録されるため、再インストールが必要になった際に楽である	△	DockerFileで全てを表現できないこともあるため、インストール手順を全てDockerFileに記録しておくことは出来なかった。一般的な対話式コマンドについてはexpectの使用で対応できるが、今回のように対応できないパターンのこともある。またdocker build時は特権モードを使用できないため、mountの実行が出来ないなど、いくつか制約が存在する
最初に期待していたメリットではないが、実は環境構築を何度もやり直すことになったため、途中までであってもDockerfileに手順を記録しておけるのは大変便利であった

その他、以下の注意点が存在することに気付いた。

ディスク容量

イメージサイズが大きくなりがちであるため、ディスク容量に注意が必要である。docker imagesで確認したところVIRTUAL SIZEの項が10GB前後であった。

インストール要件

前述したとおり、ネットワーク関連でパラメータについて、満たせていないインストール要件が存在するため、性能に悪影響が生じる可能性を否定できない。そのため、性能にシビアさが求められる本番環境で使用する際には、要件を満たせるか検証が必要である。また、連載「より深くDockerを知る」の「Dockerコンテナのパフォーマンス劣化とチューニング」であったように、ネットワークの速度とディスクの速度のチューニングにも気を付けた方が良いと思われる。

また、本稿を読んでOracle11gR2のインストールを行われる方は、オラクル社のライセンスポリシーを確認した上で行うように注意していただきたい。

今後の課題

本稿に関連して、今後の検証が必要と思われる課題は以下の通りだ。

docker pouse/unpouseへの対応

シグナルのtrapを追加することで対応できると思われるが、未検証である。

データファイル等をホスト側ディレクトリへ格納する設定

実現のためには、Oracle11gR2のOptimal Flexible Architectureを理解したうえで、ディレクトリ構成を設計する必要がある。

著者

世古雅也

この著者の記事一覧この著者の
記事一覧

TIS株式会社

生産革新本部アプリケーション開発センター所属。
システムエンジニアとして、数多くのシステム開発と、複数のJavaフレームワーク開発の案件を担当。
現在は、Javaアプリケーション開発/実行基盤「Nablarch」の開発を担当しており、製品の改善と利用の拡大に向けての技術情報の提供や利用者支援の活動に従事している。
「雑談でも技術ネタが出てくる」ような技術者集団の中で、楽しく業務を行っている。
> TIS株式会社