|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
Linux環境でWebOTX Application Server Express (フルプロファイル)またはWebOTX Application Server Standardのコンテナイメージを生成する手順を説明します。
コンテナイメージを作成するには、事前にコンテナエンジン (Docker または Podman)のインストールが必要です。インストール方法および環境設定方法はOSおよびコンテナエンジンのドキュメントを参照してください。
また、移行機能で作成したファイルを展開するためにunzipコマンドを使用します。移行機能を使用してコンテナイメージを生成する場合、事前にunzipコマンドをインストールしておく必要があります。
コンテナイメージの生成に必要なファイルを準備するには、WebOTXのインストールメディアに格納されているコンテナイメージ生成用ファイル準備スクリプトを使用します。 このスクリプトでは、ファイルの準備だけでなくコンテナイメージの生成まで行うことができます。
手順を以下で説明します。
login: root
root> cd / root> mount -t iso9660 /dev/cdrom /media/cdrom
root> /media/cdrom/OTXCNT/LINUX/prepare-to-build-image.sh
移行機能を利用してコンテナイメージを生成する場合は、移行機能で作成されたzipファイルをスクリプトの引数に指定してください。
移行機能で作成されたzipファイルがネストしている場合は、先にunzipコマンドで展開して、内部のzipファイルを引数に指定してください。
root> /media/cdrom/OTXCNT/LINUX/prepare-to-build-image.sh <zipファイル>
引数に移行機能で作成されたzipファイルを指定した場合は、はじめにzipファイルを解析して取得した移行先環境情報が表示されます。
Parsing <zipファイル> ... Product Name : WebOTX Application Server <エディション> for Container User Domain Name : <ドメイン名> Web Server : <Webサーバの種類> Domain Administration User Name : <ドメインの運用管理ユーザ名> Domain Administration Port : <ドメインの運用管理ポート番号>
新規に作成するため、存在しないディレクトリを指定してください。
Please enter a directory path to use as an output directory. (Please enter a non-existing path. It will be created after.)
使用するベースイメージを番号で選択してください。その他のイメージを使用する場合は「6」を選択してください。
なお、Red Hat Enterprise Linux 7のイメージは配布に制限があります。また、Red Hat Universal Base Imageを使用する場合も、Red Hat Enterprise Linuxのyumリポジトリを使用すると、配布が制限される場合があります。
Please select a base image. (Default: 1)
1. Red Hat Universal Base Image 7
(registry.access.redhat.com/ubi7/ubi)
2. Red Hat Universal Base Image 7 (Minimal)
(registry.access.redhat.com/ubi7/ubi-minimal)
3. Red Hat Enterprise Linux 7 Image
(registry.access.redhat.com/rhel7)
4. Red Hat Universal Base Image 8
(registry.access.redhat.com/ubi8/ubi)
5. Red Hat Universal Base Image 8 (Minimal)
(registry.access.redhat.com/ubi8/ubi-minimal)
6. Other image
「6」を選択した場合、ベースイメージ名を入力します。
Please enter a base image name.
続いて、パッケージマネージャのコマンドを入力します。指定したベースイメージで使用可能なコマンドを入力してください。既定値は指定したベースイメージ名に合わせて変わります。
Please enter a package manager name. (Default: yum)
さらに、パッケージマネージャのコマンドオプションを入力します。指定したパッケージマネージャで使用可能なコマンドオプションを入力してください。既定値は指定したベースイメージ名に合わせて変わります。既定値が「<none>」でない場合、「<none>」と入力することでコマンドオプションなしになります。
Please enter package management command options. (Default: --disableplugin=subscription-manager --disablerepo=* --enablerepo=ubi-7 --enablerepo=ubi-7-server-extras-rpms --enablerepo=ubi-7-server-optional-rpms) If you enter "<none>", it means no options.
使用するJDKを番号で選択してください。その他のJDKを使用する場合は「3」を選択してください。
移行機能を利用してコンテナイメージを生成する場合、既定値は指定したzipファイル内の移行先環境情報に合わせて変わります。
Please select a JDK. (Default: 1) 1. Red Hat OpenJDK 8 2. Red Hat OpenJDK 11 3. Other JDK
「3」を選択した場合、JDKのインストーラ(tar.gz)ファイルを入力します。既定値はメディアに含まれるインストーラです。
Please enter a JDK installer file (*.tar.gz) path. (Default: /media/cdrom/JDK/LINUX/jdk-8uX-linux-x64.tar.gz)
WebOTX Application Server Express for Containerの場合は「1」を、WebOTX Application Server Standard for Containerの場合は「2」を選択してください。
移行機能を利用してコンテナイメージを生成する場合は、指定したzipファイル内の移行先環境情報でエディションが決まるため、この選択肢はスキップされます。
Please select one of the following WebOTX products. 1. WebOTX Application Server Express for Container 2. WebOTX Application Server Standard for Container
ライセンスキーは製品に添付される「ソフトウェア使用認定証」の「製品番号」に記載されている19桁の番号です。
Please enter a license key of WebOTX Application Server <エディション> for Container.
Caution
入力する「ライセンスキー」は1つですが、コンテナに割り当てるコア数に応じた数の WebOTX Application Server <エディション> Processor License for Container を購入していただく必要があります。
WebOTX Webサーバを(Apache HTTP Server 2.4.xxベース)を使用する場合は「1」を、WebOTX内蔵型のJavaベースのWebサーバを使用する場合は「2」を選択してください。既定値はWebOTX Application Server Express for Containerの場合は「2」、WebOTX Application Server Standard for Containerの場合は「1」です。
移行機能を利用してコンテナイメージを生成する場合は、指定したzipファイル内の移行先環境情報でWebサーバが決まるため、この選択肢はスキップされます。
Please select one of the following Web Server. (Default: 1) 1. WebOTX Web Server 2.4 2. Internal Java based Web Server
コンテナイメージ生成時にWebOTX Application Serverのパッチを適用する場合は「y」を、パッチを適用しない場合は「n」を選択してください。
Would you like to apply a patch of WebOTX Application Server <エディション> during installation? [y,n] (Default: n)
「y」を選択した場合、事前に対象マシンにダウンロードしたWebOTX Application Serverのパッチへのパスを入力してください。
Please enter a patch file (*.tar.gz) path of WebOTX Application Server <エディション>.
Caution
パッチの入手にはWebOTXの保守契約が必要です。
Caution
パッチは指定したエディションに適用可能なものを選択してください。
WebOTX運用管理ユーザをroot以外に設定する場合は「y」を、rootに設定する場合は「n」を選択してください。
Would you like to configure a non-root user as WebOTX Operation User? [y,n] (Default: y)
「y」を選択した場合、WebOTX運用管理ユーザはユーザ名asadm (ユーザID 10001)、グループはroot (グループID 0)になります。
また、運用管理ユーザがroot以外の場合、OSの制約上ポート番号として1024未満の番号を利用できません。移行機能を利用しないでコンテナイメージを生成する場合は、HTTPのポート番号として8080が、HTTPSのポート番号として8443が使用されます。移行機能を利用する場合、ポート番号に1024未満を使用していないことを確認してください。
ユーザドメイン名は半角英数字と、ハイフン(-)、アンダーバー(_)を32文字以内で入力してください。また、「admin」は予約語であるため、ユーザドメイン名として指定することができません。
移行機能を利用してコンテナイメージを生成する場合は、指定したzipファイル内の移行先環境情報でドメイン名が決まるため、この入力はスキップされます。
Please enter a name of a user domain. (Default: domain1)
コンテナイメージ生成用ファイルの準備を開始するには「y」を入力してください。キャンセルするには「q」を入力してください。キャンセルした場合、コンテナイメージ生成用ファイル準備スクリプトは終了します。再実行する場合は手順(3)のコンテナイメージ生成用ファイル準備スクリプトの実行からやり直してください。
A build context will be created in the specified output directory
with the following settings.
Output Directory : ./build
Base Image : Red Hat Universal Base Image 7
(registry.access.redhat.com/ubi7/ubi)
package manager : yum (--disableplugin=subscription-manager --disablerepo=* --enablerepo=ubi-7 --enablerepo=ubi-7-server-extras-rpms --enablerepo=ubi-7-server-optional-rpms)
JDK : Red Hat OpenJDK 8
Product Name : WebOTX Application Server Express for Container
License Key : 1234567890ABCDEF
Web Server : Internal Java based Web Server
Apply Patch File : none
WebOTX Operation User : non-root
User Domain Name : domain1
************************************************************************
* Preparation to build image in the output directory. *
* To continue, enter y. *
* Enter q to exit the preparation. [y, q] (Default: y) *
************************************************************************
移行機能を利用してコンテナイメージを生成する場合は、引数に指定したファイル、ドメインの運用管理ユーザ名、運用管理ポートの情報も表示されます。
A build context will be created in the specified output directory
with the following settings.
Output Directory : ./build
Migration Config : ./webotx_migration_configs_19010100.zip
Base Image : Red Hat Universal Base Image 7
(registry.access.redhat.com/ubi7/ubi)
package manager : yum (--disableplugin=subscription-manager --disablerepo=* --enablerepo=ubi-7 --enablerepo=ubi-7-server-extras-rpms --enablerepo=ubi-7-server-optional-rpms)
JDK : Red Hat OpenJDK 8
Product Name : WebOTX Application Server Express for Container
License Key : 1234567890ABCDEF
Web Server : Internal Java based Web Server
Apply Patch File : none
WebOTX Operation User : non-root
User Domain Name : domain1
Domain Administration User Name : admin
Domain Administration Port : 6212
************************************************************************
* Preparation to build image in the output directory. *
* To continue, enter y. *
* Enter q to exit the preparation. [y, q] (Default: y) *
************************************************************************
以下のメッセージが表示されたら準備完了です。
Preparation of image build context is successful.
複数ページにわたって表示されるため、ページを進めるにはスペースキーを押下してください。
コンテナイメージの生成を開始するには「y」を入力してください。キャンセルするには「q」を入力してください。キャンセルした場合、コンテナイメージ生成用ファイル準備スクリプトは終了します。
************************************************************************ * Building an image using the output directory as build context. * * To continue, enter y. * * Enter q to exit the image building. [y, q] (Default: y) * ************************************************************************
キャンセル後にコンテナイメージを生成する方法は [ スクリプトで作成されたファイルを利用したコンテナイメージの生成 ] を参照してください。
追加構成や追加のライセンス登録を行う場合は、「q」を入力してコンテナイメージの生成をキャンセルし、手順(4)で指定したディレクトリに生成されたファイルを編集してから、[ スクリプトで作成されたファイルを利用したコンテナイメージの生成 ] に記載の方法でコンテナイメージを生成してください。
追加構成および追加のライセンス登録の方法は [ 追加構成 ] および [ 追加ライセンス登録 ] を参照してください。
Validating environment for building image...
イメージ生成環境の確認を別途実施するには、以下のスクリプトを実行してください。
root> /media/cdrom/OTXCNT/LINUX/validate-image-build-environment.sh
イメージ生成環境が正しく準備できている場合は、以下のメッセージが表示されます。
Validation is successful.
イメージ生成環境が正しく準備できていない場合は、以下のメッセージが表示されスクリプトが終了します。一緒に表示されるエラーメッセージの内容を確認して、コンテナエンジン等のイメージ生成環境を構築した後に [ スクリプトで作成されたファイルを利用したコンテナイメージの生成 ] に記載の方法でコンテナイメージを生成してください。
Validation failed.
Please enter a name of the build image. (Default: no name)
Dockerデーモンと同じプロキシ設定を使用する場合は「y」を、プロキシ設定を使用しない場合は「n」を選択してください。Dockerデーモンにプロキシ設定をしていない場合は、この選択肢はスキップされます。
「y」を入力した場合、プロキシ設定はdocker buildコマンドの--build-argオプションを使用して指定されます。
Would you like to use the same proxy configuration as the Docker daemon when building the image? [y/n] (Default: y) Http Proxy: <httpプロキシ> Https Proxy: <httpsプロキシ> No Proxy: <プロキシ除外設定>
上記の「<httpプロキシ>」「<httpsプロキシ>」「<プロキシ除外設定>」はDockerデーモンに設定したプロキシ設定が表示されます。設定されていない項目は「<none>」と表示されます。
Caution
RHEL 7 で提供される Docker 1.13 では--build-argオプションで指定したプロキシ設定の情報が中間イメージに残る点に注意してください。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > イメージ生成時のプロキシ設定が中間イメージに残る ]
Podmanの場合は、スクリプトを実行した環境の環境変数http_proxy, https_proxy, no_proxyが引き継がれるため、この選択肢はスキップされます。
以下のメッセージが表示されたら生成完了です。コンテナイメージ生成用ファイル準備スクリプトはここで終了します。
Building an image is successful.
以下のコマンドを実行します。
(Podmanを使用する場合は、dockerコマンドをpodmanコマンドに読み替えてください)
root> docker images REPOSITORY TAG IMAGE ID CREATED <イメージ名> <タグ> ************ ** **** ago registry.access.redhat.com/ubi7/ubi latest ************ ** **** ago
(*) *** 部分の表記は環境によって異なります。
生成時に指定した名前のイメージが表示されれば、生成完了です。
WebOTX Application Serverのコンテナイメージを生成する際に追加の構成を行う方法を説明します。
追加の構成を行うには、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)で指定したディレクトリに作成されたadditional-configディレクトリの以下のスクリプトを編集してください。
| スクリプトファイル名 | 実行タイミング |
|---|---|
| pre-start-domain.sh | コンテナイメージ生成中のドメイン起動前 |
| post-start-domain.sh | コンテナイメージ生成中のドメイン起動後 |
| post-stop-domain.sh | コンテナイメージ生成中のドメイン停止後 |
スクリプト内では、以下の環境変数が利用可能です。
| 環境変数名 | 説明 |
|---|---|
| AS_INSTALL | WebOTX Application Serverインストールディレクトリ 「/opt/WebOTX」固定 |
| AS_JAVA | JDKのホームディレクトリ |
| INSTANCE_ROOT | ユーザドメインのディレクトリ 「/opt/WebOTX/domains/<ドメイン名>」 |
| DOMAIN_NAME | ユーザドメイン名 |
| ADDITIONAL_CONFIG | additional-configディレクトリのコンテナ内でのパス このディレクトリはイメージ生成の中で削除されます |
スクリプトから使用するファイルは、additional-configディレクトリに配置して、ADDITIONAL_CONFIG環境変数を使用してアクセスしてください。 additional-configディレクトリ内のファイル ($ADDITIONAL_CONFIG ディレクトリにコピーされたファイル) はスクリプト実行後に削除されます。最終イメージでも使用するファイルはスクリプト内で別のディレクトリにコピーする必要があります。
Caution
各スクリプトの内容およびadditional-configディレクトリの内容が中間イメージに残る点に注意してください。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > 追加構成に使用したファイルが中間イメージに残る ]
Caution
追加の構成を行う際、自身のホスト名を指定する場合は「localhost」を使用することで、コンテナ起動時にコンテナのホスト名に自動的に置き換わります。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > 自身のホスト名を指定する場合は「localhost」を使用する必要がある ]
追加構成を行うためのスクリプトの例を記載します。この例では、以下の構成を行います。
additional-config/pre-start-domain.sh に以下の内容を追記します。
# copy library
cp "$ADDITIONAL_CONFIG/derbyclient.jar" "$INSTANCE_ROOT/lib/"
# add permission in server.policy
cat << 'EOF' >> "$INSTANCE_ROOT/config/server.policy"
// for jdbc driver
grant codeBase "file:${com.nec.webotx.instanceRoot}/lib/derbyclient.jar" {
permission java.security.AllPermission;
};
additional-config/post-start-domain.sh に以下の内容を追記します。
# set value "$AS_INSTALL/bin/otxadmin" set --user admin --password adminadmin server.microprofile.microprofile-health.enabled=true "$AS_INSTALL/bin/otxadmin" set --user admin --password adminadmin server.microprofile.microprofile-metrics.enabled=true # create resource "$AS_INSTALL/bin/otxadmin" create-jdbc-datasource --user admin --password adminadmin --dataSourceType JDBCEX_Derby --jdbcMajorVersion 4 --jdbcUserName APP --jdbcPassword APP --serverName hostname --portNumber 1527 --dataSourceName sample-db jdbc/sample # deploy application "$AS_INSTALL/bin/otxadmin" deploy --user admin --password adminadmin "$ADDITIONAL_CONFIG/hello.war"
スクリプト内で使用するファイル derbyclient.jar と hello.war はadditional-configディレクトリに配置します。
addtional-configディレクトリ内のスクリプトの変更およびファイルの配置後に、[ スクリプトで作成されたファイルを利用したコンテナイメージの生成 ] に記載の方法でコンテナイメージを生成することで、追加構成を実施したコンテナイメージが生成されます。
コンテナイメージ生成時ではなくコンテナ起動時に毎回実行する処理は、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)で指定したディレクトリに作成されたscripts/preprocess.dディレクトリに実行可能ファイルを配置してください。ここに配置した実行可能ファイルはコンテナ内でのドメイン起動前に実行されます。この実行可能ファイルでは、以下の環境変数が利用可能です。
| 環境変数名 | 説明 |
|---|---|
| AS_INSTALL | WebOTX Application Serverインストールディレクトリ 「/opt/WebOTX」固定 |
| AS_JAVA | JDKのホームディレクトリ |
| INSTANCE_ROOT | ユーザドメインのディレクトリ 「/opt/WebOTX/domains/<ドメイン名>」 |
| DOMAIN_NAME | ユーザドメイン名 |
WebOTX Application Serverのコンテナイメージを生成する際に追加のライセンス登録を行う方法を説明します。
追加のライセンスを登録するには、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)で指定したディレクトリに作成されたテキストファイルadditional-license.txtにライセンスキーを記入してください。ライセンスキーは1行に1つずつ記入してください。
additional-license.txt記入後に、[ スクリプトで作成されたファイルを利用したコンテナイメージの生成 ] に記載の方法でコンテナイメージを生成することで、追加構成を実施したコンテナイメージが生成されます。
コンテナイメージ生成用ファイル準備スクリプト (prepare-to-build-image.sh)で作成されたファイルを利用して、コンテナイメージを生成する方法を説明します。
追加構成や追加ライセンス登録のために [ ファイルの準備とコンテナイメージの生成 ] の手順(16)で「q」を入力してコンテナイメージの生成をキャンセルした場合や、コンテナイメージを再生成する場合、Docker, Podmanをインストールしていない環境でコンテナイメージ生成用ファイル準備スクリプトを実行してファイルを準備し、Docker, Podmanをインストールした環境に持って行ってコンテナイメージを生成する場合に実施します。 スクリプトの延長でコンテナイメージを生成する場合は、[ ファイルの準備とコンテナイメージの生成 ] の手順(16)で「y」を入力してください。
コンテナイメージを生成するには以下のコマンドを実行してください。イメージ名を指定する場合はコンテナイメージ名の規約に従ってください。 Dockerfileがあるディレクトリとは、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)で指定したディレクトリです。
root> docker build -t <イメージ名> <Dockerfileがあるディレクトリ>
プロキシ環境下で実行する場合は、buildコマンドの--build-argオプションでhttp_proxy、https_proxy、no_proxyにコンテナイメージ生成時に使用するプロキシサーバの情報を指定してください。
Caution
RHEL 7 で提供される Docker 1.13 では--build-argオプションで指定したプロキシ設定の情報が中間イメージに残る点に注意してください。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > イメージ生成時のプロキシ設定が中間イメージに残る ]
root> podman build -t <イメージ名> <Dockerfileがあるディレクトリ>
プロキシ環境下で実行する場合は、環境変数http_proxy、https_proxy、no_proxyにコンテナイメージ生成時に使用するプロキシサーバの情報を指定してpodman buildコマンドを実行してください。
WebOTX Application Serverのコンテナイメージを生成した後、そのコンテナイメージに対して追加の構成を行う方法を説明します。
生成済みのコンテナイメージに対して追加の構成を行うには、任意の新規ディレクトリにDockerfileを作成して、FROM命令で指定するベースイメージに生成済みのWebOTX Application Serverのコンテナイメージ名を指定します。
さらに、DockerfileでADD, COPY, RUN等の命令を用いて追加構成を行います。
コンテナイメージ生成時の追加構成と異なり、WebOTXのインストールディレクトリなどを指す環境変数は利用できません。
Caution
Dockerfileの内容およびCOPYまたはADDでコピーしたファイルが中間イメージに残る点に注意してください。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > 追加構成に使用したファイルが中間イメージに残る ]
Caution
追加の構成を行う際、自身のホスト名を指定する場合は「localhost」を使用することで、コンテナ起動時にコンテナのホスト名に自動的に置き換わります。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > 自身のホスト名を指定する場合は「localhost」を使用する必要がある ]
生成済みのWebOTX Application Serverのコンテナイメージに対して追加構成を行う例を記載します。
この例でベースイメージとして使用するWebOTX Application Serverのコンテナイメージは以下のように構成されています。
この例では、以下の構成を行います。
以下の内容の Dockerfile を作成します。
FROM <生成済みのWebOTX Application Serverのコンテナイメージ名>
USER 0
# Configuration
COPY derbyclient.jar /opt/WebOTX/domains/domain1/lib/
COPY hello.war /tmp/
RUN chown 10001:0 /opt/WebOTX/domains/domain1/lib/derbyclient.jar /tmp/hello.war
USER 10001
RUN echo '// for jdbc driver' >> /opt/WebOTX/domains/domain1/config/server.policy && \
echo 'grant codeBase "file:${com.nec.webotx.instanceRoot}/lib/derbyclient.jar" {' >> /opt/WebOTX/domains/domain1/config/server.policy && \
echo ' permission java.security.AllPermission;' >> /opt/WebOTX/domains/domain1/config/server.policy && \
echo '};' >> /opt/WebOTX/domains/domain1/config/server.policy && \
/opt/WebOTX/bin/docker/start-domain-for-config.sh && \
sleep 20 && \
/opt/WebOTX/bin/otxadmin set --user admin --password adminadmin server.microprofile.microprofile-health.enabled=true && \
/opt/WebOTX/bin/otxadmin set --user admin --password adminadmin server.microprofile.microprofile-metrics.enabled=true && \
/opt/WebOTX/bin/otxadmin create-jdbc-datasource --user admin --password adminadmin --dataSourceType JDBCEX_Derby --jdbcMajorVersion 4 --jdbcUserName APP --jdbcPassword APP --serverName hostname --portNumber 1527 --dataSourceName sample-db jdbc/sample && \
/opt/WebOTX/bin/otxadmin deploy --user admin --password adminadmin /tmp/hello.war && \
/opt/WebOTX/bin/docker/stop-domain-for-config.sh && \
rm -rf /opt/WebOTX/domains/domain1/backup && \
rm -rf /opt/WebOTX/domains/domain1/osgi-cache && \
rm -f /opt/WebOTX/domains/domain1/config/ObjectBroker/namesv.ndf && \
rm -f /tmp/hello.war
Dockerfile内で使用するファイル derbyclient.jar と hello.war はDockerfileと同じディレクトリに配置します。
DockerfileおよびDockerfile内で使用するファイルの準備後に、[ スクリプトで作成されたファイルを利用したコンテナイメージの生成 ] に記載の方法でコンテナイメージを生成することで、追加構成を実施したコンテナイメージが生成されます。
その際、docker build/podman buildコマンドに指定するDockerfileがあるディレクトリとは、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)で指定したディレクトリではなく、追加構成のために新規に作成したDockerfileがあるディレクトリを指定します。
生成済みのWebOTX Application Serverのコンテナイメージに対してパッチを適用する例を記載します。
Caution
パッチ適用は生成済みのWebOTX Application Serverのコンテナイメージに対してではなく、WebOTX Application Serverのコンテナイメージを生成する際に実施することを推奨します。
WebOTX Application Serverのコンテナイメージを生成する際にパッチを適用するには、[ ファイルの準備とコンテナイメージの生成 ] の手順(10)で「y」を入力し、続いてパッチファイルのパスを入力します。
この例でベースイメージとして使用するWebOTX Application Serverのコンテナイメージは以下のように構成されています。
この例では、以下の処理を行います。
以下の内容の Dockerfile を作成します。
FROM <生成済みのWebOTX Application Serverのコンテナイメージ名>
USER 0
# Install util-linux for su command used during applying patch
# (Uncomment this RUN instruction only if using ubi8-minimal)
#RUN microdnf -y install util-linux && \
# microdnf clean all && \
# rm -rf /var/cache/yum/*
# Apply Patch
ADD ["<パッチファイル(.tar.gz)名>", "/tmp/build-tmp/patch"]
RUN usermod -s /bin/bash asadm && \
echo -e 'y\nasadm\nroot\ny' | /tmp/build-tmp/patch/bin/wo_patch_as.sh && \
rm -rf /tmp/build-tmp && \
usermod -s /sbin/nologin asadm
USER 10001
Dockerfile内で使用するWebOTX Application ServerのパッチファイルはDockerfileと同じディレクトリに配置します。
パッチのreadmeで適用後の作業指示がある場合は、指示された内容をDockerfileのRUN命令で実行します。
DockerfileおよびWebOTX Application Serverのパッチファイルの準備後に、[ スクリプトで作成されたファイルを利用したコンテナイメージの生成 ] に記載の方法でコンテナイメージを生成することで、パッチ適用されたコンテナイメージが生成されます。
その際、docker build/podman buildコマンドに指定するDockerfileがあるディレクトリとは、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)で指定したディレクトリではなく、パッチ適用のために新規に作成したDockerfileがあるディレクトリを指定します。
Linux環境でWebOTX Application Server Express (マイクロサービスプロファイル)のコンテナイメージを生成する手順を説明します。
マイクロサービスパッケージを作成する方法は [ アプリケーション開発 > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 ] を参照してください。
コンテナエンジンに Docker を使用する場合のコンテナイメージの作成ついて説明します。 コンテナエンジンに Podman を使用する場合は、docker コマンドを podman コマンドに読み替えてください。 詳細については、使用するコンテナエンジン、コンテナオーケストレーションツールのドキュメントを参照してください。
コンテナイメージの作成は次のとおりの手順で行ないます。
$ login: root
# cd <任意のフォルダ>/webotx-ms-package
# docker build -t <イメージ名> .
# docker images REPOSITORY TAG IMAGE ID CREATED <イメージ名> <タグ> ************ ** **** ago registry.access.redhat.com/rhel latest ************ ** **** ago(*) *** 部分の表記は環境によって異なります。
動作確認は次のとおりの手順で行ないます。
$ login: root
# docker run -it -d -e OTX_LICENSE=<ライセンスキー> -p 8080:8080 <イメージ名>
Caution
指定する「ライセンスキー」は事前に購入していただく必要があります。
Caution
「8080番ポート」はホスト上で使用していないポート番号を指定してください。
ポート番号が競合していないことを確認するには、以下のコマンドで確認できます。
# ss -ant | grep 8080
# docker ps CONTAINER ID IMAGE COMMAND CREATED 537d3c548628 <イメージ名> "java -jar ・・・" 2 minutes ago
http://[ホストOSのIPアドレス]:8080/{artifactId}-{version}/parameter/query?param=query
Webブラウザ上に「query」の表示が確認できれば、正常に動作しています。
Windows環境でWebOTX Application Server Express (フルプロファイル)のコンテナイメージを生成する手順を説明します。
Caution
Windows環境ではWebOTX Application Server Express (マイクロサービスプロファイル)とWebOTX Application Server Standardのコンテナイメージ生成をサポートしていません。
コンテナイメージを生成するには、WebOTXのインストールメディアに格納されているDockerfile、WebOTXインストーラ、JDKインストーラ、起動スクリプトファイルを作業フォルダに準備し、docker image buildコマンドを実行します。
手順を以下で説明します。
WebOTXメディアのDVD-ROM媒体を DVD-ROM ドライブに挿入してください。インストーラのランチャー画面が表示された場合は、[OK]ボタンを押して閉じてください。
以下に示すファイルおよびフォルダを任意のフォルダにコピーしてください。
<ドライブ>は、DVD-ROM ドライブのドライブ文字です。
コピー先のフォルダを<作業フォルダ>として、以下の構成となるようにコピーしてください。
[Windows Server 2019 の場合]
テキストファイル<作業フォルダ>\Dockerfile の初めにある以下の行の「ltsc2016」を「ltsc2019」に変更してください。
FROM mcr.microsoft.com/windows/servercore:ltsc2016
[メディアにバンドルしていない Oracle の JDK を使用する場合]
メディアにバンドルしていないOracleのJDKを使用する場合は、JDKのインストーラ(exe)ファイルを用意し、<作業フォルダ>にコピーします。
さらに、テキストファイル<作業フォルダ>\Dockerfile の「# install JDK」の次の行にある COPY の「jdk-*.exe」を用意した JDK のインストーラ(exe)ファイル名にマッチするように編集します。
[AdoptOpenJDK を使用する場合]
AdoptOpenJDK を使用する場合は、AdoptOpenJDK のインストーラ(msi)ファイルを用意し、<作業フォルダ>にコピーします。AdoptOpenJDK のインストーラ(msi)ファイルは、メディアの以下の場所にバンドルしています。メディアにバンドルしていない AdoptOpenJDK のインストーラ(msi)ファイルを使用しても構いません。
さらに、テキストファイル<作業フォルダ>\Dockerfile の「# install JDK」の次にある 2 行(COPY と RUN の行)を削除し、そこに以下の 2 行を挿入します。
COPY OpenJDK*.msi C:/temp/OpenJDK.msi RUN start /wait msiexec /i C:\temp\OpenJDK.msi ADDLOCAL="FeatureMain,FeatureOracleJavaSoft" /quiet
※ 用意したAdoptOpenJDKのインストーラ(msi)ファイル名がCOPYの「OpenJDK*.msi」にマッチしない場合は、マッチするように編集します。
[その他のOpenJDK を使用する場合]
その他のOpenJDKを使用する場合は、OpenJDKのインストーラ(zip)ファイルを用意し、<作業フォルダ>にコピーします。
さらに、テキストファイル<作業フォルダ>\Dockerfile の「# install JDK」の次にある 2 行(COPY と RUN の行)を削除し、そこに以下の 2 行を挿入します。
COPY <OpenJDK のインストーラ(zip)ファイル名> C:/temp/openjdk.zip RUN powershell.exe -Command Expand-Archive -Path C:\temp\openjdk.zip -DestinationPath 'C:\Program Files\Java'
※ <OpenJDKのインストーラ(zip)ファイル名>には、用意したOpenJDKのインストーラ(zip)ファイルの名前を記載します。
次に、テキストファイル<作業フォルダ>\Dockerfile の「# install WebOTX AS Express」にある「$jdkRegistryPath = 〜 ; \」の行から「$javaHome = 〜 ; \」の行までの 4 行を削除し、そこに以下の 1 行を挿入します。
$javaHome = Get-ChildItem 'C:\Program Files\Java' ^| Select-Object -First 1 ^| % { $_.FullName } ; \
製品に添付されている 「ソフトウェア使用認定証」の「製品番号」に記載されている19桁の番号をテキストファイル<作業フォルダ>\license.txtに記入します。コンテナに割り当てられるコア数の総計が3コア以上であっても、ここで登録するライセンス数は 1 つです。
Caution
license.txt に記載する「ライセンスキー」は 1 つですが、コンテナに割り当てるコア数に応じた数の WebOTX Application Server Express Processor License for Container を購入していただく必要があります。
コンテナイメージを生成します。PowerShell で以下のコマンドを実行します。指定するイメージ名はコンテナイメージ名の規約に従ってください。
PS> docker image build -t <イメージ名> <作業フォルダ>
コンテナイメージが生成されていることを確認します。PowerShell で以下のコマンドを実行します。
PS> docker image ls REPOSITORY TAG IMAGE ID CREATED <イメージ名> <タグ> ************ ** **** ago mcr.microsoft.com/windows/servercore ltsc2016 ************ ** **** ago
生成時に指定した名前のイメージが表示されれば、作成完了です。
WebOTX Application Serverのコンテナイメージを生成する際に追加の構成を行う方法を説明します。
追加の構成を行うには、[ ファイルの準備とコンテナイメージの生成 ] の手順(2)で用意したテキストファイル<作業フォルダ>\Dockerfile を編集してください。
Dockerfile内で使用するファイルは、<作業フォルダ>に配置します。
Caution
Dockerfileの内容およびCOPYまたはADDでコピーしたファイルが中間イメージに残る点に注意してください。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > 追加構成に使用したファイルが中間イメージに残る ]
Caution
追加の構成を行う際、自身のホスト名を指定する場合は「localhost」を使用することで、コンテナ起動時にコンテナのホスト名に自動的に置き換わります。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > 自身のホスト名を指定する場合は「localhost」を使用する必要がある ]
追加構成を行うためのDockerfileの例を記載します。この例では、以下の構成を行います。
Dockerfile を以下のように変更します。
「# configure domain1」の行の次(RUN の前)に COPY 命令を追加して追加構成で使用するファイルをコンテナ内にコピーします。
COPY derbyclient.jar C:/WebOTX/domains/domain1/lib/ext/ COPY app.war C:/temp/
「# configure domain1」の RUN 命令の中の「C:\WebOTX\bin\otxadmin.bat stop-domain domain1 ; \」の行の前後に設定変更やファイルの削除の処理を追加します。
C:\WebOTX\bin\otxadmin.bat set --user admin --password adminadmin server.microprofile.microprofile-health.enabled=true ; \
C:\WebOTX\bin\otxadmin.bat set --user admin --password adminadmin server.microprofile.microprofile-metrics.enabled=true ; \
C:\WebOTX\bin\otxadmin.bat create-jdbc-datasource --user admin --password adminadmin --dataSourceType JDBCEX_Derby --jdbcMajorVersion 4 --jdbcUserName APP --jdbcPassword APP --serverName hostname --portNumber 1527 --dataSourceName sample-db jdbc/sample ; \
C:\WebOTX\bin\otxadmin.bat deploy --user admin --password adminadmin C:\temp\app.war ; \
C:\WebOTX\bin\otxadmin.bat stop-domain domain1 ; \
Remove-Item C:\temp -Recurse -Force ; \
Dockerfile内で使用するファイル derbyclient.jar と hello.war は<作業フォルダ>に配置します。
Dockerfileの変更およびファイルの配置後に、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)に記載の方法でコンテナイメージを生成することで、追加構成を実施したコンテナイメージが生成されます。
WebOTX Application Serverのパッチ適用を行うためのDockerfileの例を記載します。
Dockerfile を以下のように変更します。
「# install WebOTX AS Express」の RUN の前の行に COPY 命令を追加してWebOTX Application Serverのパッチファイルをコンテナ内にコピーします。
COPY <パッチファイル(.zip)名> C:/temp/webotx_as_patch_win.zip
「# install WebOTX AS Express」の RUN 命令の中の「Start-Process C:\temp\EXP\setup.exe 〜 -Wait ; \」の後の行に以下の内容を挿入します。
ここでは、パッチの展開、パッチ適用スクリプトを非対話実行可能に変更、パッチ適用スクリプトを実行という処理を行います。
Expand-Archive -Path C:\temp\webotx_as_patch_win.zip -DestinationPath C:\temp\patch ; \
$newContent = Get-Content C:\temp\patch\bin\wo_patch_edition.bat ; \
$newContent = $newContent ^| ForEach-Object { if ($_.Trim().StartsWith('set BACKUPFILE=')) { 'set BACKUPFILE=webotx_as_%BACKUPFILEVERSION%_backup.zip' } else { $_ } } ; \
$newContent = $newContent ^| ForEach-Object { if ($_.Trim().StartsWith('set LOGFILE=')) { 'set LOGFILE=webotx_as_patch.log' } else { $_ } } ; \
$newContent = $newContent.Replace('for /f \"tokens=4\" %%L in (''\"%INSTALLDIR%bin\otxadmin.bat\" version'') do (', 'for /f \"tokens=3,4\" %%K in (''\"%INSTALLDIR%bin\otxadmin.bat\" version'') do if \"%%K\" == \"Version\" (') ; \
$newContent = $newContent ^| ForEach-Object { if ($_.Trim().StartsWith('set /p APPLYPATCH=')) { 'set APPLYPATCH=y' } else { $_ } } ; \
$newContent = $newContent.Replace('pause', '') ; \
$newContent ^| Out-String ^| % { [Text.Encoding]::UTF8.GetBytes($_) } ^| Set-Content -Path C:\temp\patch\bin\wo_patch_edition.bat -Encoding Byte ; \
C:\temp\patch\bin\wo_patch_edition.bat ; \
Dockerfile内で使用するWebOTX Application Serverのパッチファイルは<作業フォルダ>に配置します。
Dockerfileの変更およびWebOTX Application Serverのパッチファイルの配置後に、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)に記載の方法でコンテナイメージを生成することで、パッチ適用されたコンテナイメージが生成されます。
WebOTX Application Serverのコンテナイメージを生成する際に追加のライセンス登録を行う方法を説明します。
追加のライセンスを登録するには、[ ファイルの準備とコンテナイメージの生成 ] の手順(2)で用意したテキストファイル<作業フォルダ>\Dockerfile を編集して、「# bootstrap script」の前の行に以下の行を挿入してください。
RUN C:\WebOTX\share\bin\OTXLAdd.exe <ライセンスキー> && exit 1 || exit 0
WebOTX Application Serverのコンテナイメージを生成した後、そのコンテナイメージに対して追加の構成を行う方法を説明します。
生成済みのコンテナイメージに対して追加の構成を行うには、任意の新規フォルダにDockerfileを作成して、FROM命令で指定するベースイメージに生成済みのWebOTX Application Serverのコンテナイメージ名を指定します。
さらに、DockerfileでADD, COPY, RUN等の命令を用いて追加構成を行います。
Caution
Dockerfileの内容およびCOPYまたはADDでコピーしたファイルが中間イメージに残る点に注意してください。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > 追加構成に使用したファイルが中間イメージに残る ]
Caution
追加の構成を行う際、自身のホスト名を指定する場合は「localhost」を使用することで、コンテナ起動時にコンテナのホスト名に自動的に置き換わります。
[ 注意制限事項 > 機能ごとの注意制限事項 > Docker > 注意事項 > 自身のホスト名を指定する場合は「localhost」を使用する必要がある ]
生成済みのWebOTX Application Serverのコンテナイメージに対して追加構成を行う例を記載します。
この例では、以下の構成を行います。
以下の内容の Dockerfile を作成します。
FROM <生成済みのWebOTX Application Serverのコンテナイメージ名>
# Configuration
COPY derbyclient.jar C:/WebOTX/domains/domain1/lib/ext/
COPY app.war C:/temp/
RUN powershell.exe -Command \
$ErrorActionPreference = 'Stop' ; \
C:\WebOTX\bin\otxadmin.bat start-domain domain1 ; \
Start-Sleep 20 ; \
C:\WebOTX\bin\otxadmin.bat set --user admin --password adminadmin server.microprofile.microprofile-health.enabled=true ; \
C:\WebOTX\bin\otxadmin.bat set --user admin --password adminadmin server.microprofile.microprofile-metrics.enabled=true ; \
C:\WebOTX\bin\otxadmin.bat create-jdbc-datasource --user admin --password adminadmin --dataSourceType JDBCEX_Derby --jdbcMajorVersion 4 --jdbcUserName APP --jdbcPassword APP --serverName hostname --portNumber 1527 --dataSourceName sample-db jdbc/sample ; \
C:\WebOTX\bin\otxadmin.bat deploy --user admin --password adminadmin C:\temp\app.war ; \
C:\WebOTX\bin\otxadmin.bat stop-domain domain1 ; \
Remove-Item C:\temp -Recurse -Force ; \
Remove-Item C:\WebOTX\domains\domain1\backup -Recurse -Force ; \
Remove-Item C:\WebOTX\domains\domain1\osgi-cache -Recurse -Force ; \
Remove-Item C:\WebOTX\domains\domain1\config\ObjectBroker\namesv.ndf -Force
Dockerfile内で使用するファイル derbyclient.jar と hello.war はDockerfileと同じフォルダに配置します。
DockerfileおよびDockerfile内で使用するファイルの準備後に、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)に記載の方法でコンテナイメージを生成することで、追加構成を実施したコンテナイメージが生成されます。
その際、docker image buildコマンドに指定する作業フォルダとは、[ ファイルの準備とコンテナイメージの生成 ] の手順(2)で準備したフォルダではなく、追加構成のために新規に作成したDockerfileがあるフォルダを指定します。
生成済みのWebOTX Application Serverのコンテナイメージに対してパッチを適用する例を記載します。
以下の内容の Dockerfile を作成します。
FROM <生成済みのWebOTX Application Serverのコンテナイメージ名>
# Apply patch
COPY <パッチファイル(.zip)名> C:/temp/webotx_as_patch_win.zip
RUN powershell.exe -Command \
$ErrorActionPreference = 'Stop' ; \
Expand-Archive -Path C:\temp\webotx_as_patch_win.zip -DestinationPath C:\temp\patch ; \
$newContent = Get-Content C:\temp\patch\bin\wo_patch_edition.bat ; \
$newContent = $newContent ^| ForEach-Object { if ($_.Trim().StartsWith('set BACKUPFILE=')) { 'set BACKUPFILE=webotx_as_%BACKUPFILEVERSION%_backup.zip' } else { $_ } } ; \
$newContent = $newContent ^| ForEach-Object { if ($_.Trim().StartsWith('set LOGFILE=')) { 'set LOGFILE=webotx_as_patch.log' } else { $_ } } ; \
$newContent = $newContent.Replace('for /f \"tokens=4\" %%L in (''\"%INSTALLDIR%bin\otxadmin.bat\" version'') do (', 'for /f \"tokens=3,4\" %%K in (''\"%INSTALLDIR%bin\otxadmin.bat\" version'') do if \"%%K\" == \"Version\" (') ; \
$newContent = $newContent ^| ForEach-Object { if ($_.Trim().StartsWith('set /p APPLYPATCH=')) { 'set APPLYPATCH=y' } else { $_ } } ; \
$newContent = $newContent.Replace('pause', '') ; \
$newContent ^| Out-String ^| % { [Text.Encoding]::UTF8.GetBytes($_) } ^| Set-Content -Path C:\temp\patch\bin\wo_patch_edition.bat -Encoding Byte ; \
C:\temp\patch\bin\wo_patch_edition.bat ; \
Remove-Item C:\temp -Recurse -Force
Dockerfile内で使用するWebOTX Application ServerのパッチファイルはDockerfileと同じディレクトリに配置します。
パッチのreadmeで適用後の作業指示がある場合は、指示された内容をDockerfileのRUN命令で実行します。
DockerfileおよびWebOTX Application Serverのパッチファイルの準備後に、[ ファイルの準備とコンテナイメージの生成 ] の手順(4)に記載の方法でコンテナイメージを生成することで、パッチ適用されたコンテナイメージが生成されます。
その際、docker image buildコマンドに指定する作業フォルダとは、[ ファイルの準備とコンテナイメージの生成 ] の手順(2)で準備したフォルダではなく、パッチ適用のために新規に作成したDockerfileがあるフォルダを指定します。
コンテナエンジンに Dokcer を使用する場合のコンテナ起動・停止方法について説明します。 コンテナエンジンに Podman を使用する場合は、docker コマンドを podman コマンドに読み替えてください。 詳細については、使用するコンテナエンジン、コンテナオーケストレーションツールのドキュメントを参照してください。
以下のコマンドでコンテナイメージからコンテナを起動します。
# docker run -d <コンテナイメージ名 または コンテナイメージID>
コンテナ内のポートを外部に公開するには、docker run コマンドに -p <ホストのポート番号>:<コンテナ内のポート番号> オプションを指定してください。
以下のコマンドでコンテナを停止します。
# docker stop <コンテナ名 または コンテナID>
停止したコンテナは以下のコマンドで削除できます。
# docker rm <コンテナ名 または コンテナID>
不要になったコンテナイメージは以下のコマンドで削除できます。 ただし、コンテナで使用中のイメージは削除できません。あらかじめコンテナを停止してから削除してください。
# docker rmi <コンテナイメージ名 または コンテナイメージID>
WebOTXでは、Linux環境のWebOTX Application Server Express (フルプロファイル)およびWebOTX Application Server StandardのコンテナイメージをDocker Hub <https://hub.docker.com/u/webotx> で公開しています。 Docker Hubに公開されたWebOTX Application Serverのコンテナイメージを利用する手順を説明します。
| コンテナイメージ <コンテナイメージ名:タグ> |
製品名 | ベースイメージ | JDK | ライセンス | Webサーバ | WebOTX 運用管理ユーザ |
|---|---|---|---|---|---|---|
| webotx/webotx-express-ubi7:10.40.00.00 | WebOTX Application Server Express V10.4 Processor License for Container (Linux 版) | registry.access.redhat.com/ubi7/ubi | OpenJDK 8 | お試し版 (*1) | WebOTX内蔵型(JavaベースのWebサーバ) | 非root |
| webotx/webotx-express-ubi8:10.40.00.00 | WebOTX Application Server Express V10.4 Processor License for Container (Linux 版) | registry.access.redhat.com/ubi8/ub | OpenJDK 8 | お試し版 (*1) | WebOTX内蔵型(JavaベースのWebサーバ) | 非root |
| webotx/webotx-standard-ubi7:10.40.00.00 | WebOTX Application Server Standard V10.4 Processor License for Container (Linux 版) | registry.access.redhat.com/ubi7/ubi | OpenJDK 8 | なし (*2) | WebOTX Webサーバ(Apache HTTP Server 2.4.xxベース) | 非root |
| webotx/webotx-standard-ubi8:10.40.00.00 | WebOTX Application Server Standard V10.4 Processor License for Container (Linux 版) | registry.access.redhat.com/ubi8/ubi | OpenJDK 8 | なし (*2) | WebOTX Webサーバ(Apache HTTP Server 2.4.xxベース) | 非root |
(*1) お試し版として、公開日より 365 日間使用できます。引き続き利用する場合は、
[ ライセンスの入れ替え > WebOTX Application Server Express の場合 ] の手順に従い、ライセンスを入れ替えます。
(*2) ご利用に際して、
[ ライセンスの入れ替え > WebOTX Application Server Standard の場合 ] の手順に従い、ライセンスを登録します。
コンテナイメージの取得について説明します。
(Podmanを使用する場合は、dockerコマンドをpodmanコマンドに読み替えてください)
$ login: root
# docker pull <コンテナイメージ名:タグ>
# docker images REPOSITORY TAG IMAGE ID CREATED <コンテナイメージ名> <タグ> ************ ** **** ago
(*) *** 部分の表記は環境または取得日によって異なります。
取得したコンテナイメージが表示されれば、取得完了です。
コンテナ起動時のライセンスの入れ替えについて説明します。
(Podmanを使用する場合は、dockerコマンドをpodmanコマンドに読み替えてください)
Caution
ご利用にはライセンスの購入が必要です。購入後、以下の手順を行ってください。
WebOTX Application Server Expres にはあらかじめ、お試し版ライセンスが入っています。 正式ライセンスへの入れ替えについて説明します。
$ login: root
# docker run --env WEBOTX_DOCKER_PREPROCESS='/opt/share.nec/bin/OTXLDel 002;/opt/share.nec/bin/OTXLAdd <ライセンス>' -it -d <コンテナイメージ名:タグ>
# docker ps CONTAINER ID IMAGE COMMAND CREATED 537d3c548628 <コンテナイメージ名:タグ> "/opt/WebOTX/bin/doc***" 2 minutes ago
コンテナの実行が確認できれば、正しく動作しています。
WebOTX Application Server Standard にはライセンスが登録されていません。 正式ライセンスの登録について説明します。
$ login: root
# docker run --env WEBOTX_DOCKER_PREPROCESS='/opt/share.nec/bin/OTXLAdd <ライセンス>' -it -d <コンテナイメージ名:タグ>
# docker ps CONTAINER ID IMAGE COMMAND CREATED 537d3c548628 <コンテナイメージ名:タグ> "/opt/WebOTX/bin/doc***" 2 minutes ago
コンテナの実行が確認できれば、正しく動作しています。
コンテナ起動時の証明書の入れ替えについて説明します。
(Podmanを使用する場合は、dockerコマンドをpodmanコマンドに読み替えてください)
WebOTX内蔵型の場合の証明書の入れ替えについて説明します。
$ login: root
Caution
事前に証明書がインポートされているキーストア(keystore.jks)とトラストストア(cacerts.jks)が必要です。
# chmod -R o+r <ホストの任意のディレクトリ>
# chcon -R -t container_share_t <ホストの任意のディレクトリ>
Memo
SELinuxの確認は、以下のコマンドを実行します。
「Enforcing」の場合は、SELinuxが有効です。
# getenforce Enforcing
# docker run -v <ホストの任意のディレクトリ>/cacerts.jks:/opt/WebOTX/domains/domain1/config/cacerts.jks -v <ホストの任意のディレクトリ>/keystore.jks:/opt/WebOTX/domains/domain1/config/keystore.jks -it -d <コンテナイメージ名:タグ>
# docker ps CONTAINER ID IMAGE COMMAND CREATED 537d3c548628 <コンテナイメージ名:タグ> "/opt/WebOTX/bin/doc***" 2 minutes ago
コンテナの実行が確認できれば、正しく動作しています。
Webサーバの場合の証明書の入れ替えについて説明します。
$ login: root
Caution
事前にサーバ証明書と秘密鍵が必要です。
ここではサーバ証明書ファイルを「server.crt」、秘密鍵ファイルを「server.key」とします。
# chmod -R o+r <ホストの任意のディレクトリ>
# chcon -R -t container_share_t <ホストの任意のディレクトリ>
Memo
SELinuxの確認は、以下のコマンドを実行します。
「Enforcing」の場合は、SELinuxが有効です。
# getenforce Enforcing
# docker run --env WEBOTX_DOCKER_PREPROCESS='/opt/share.nec/bin/OTXLAdd <ライセンス>;sed -i -e "/^SSLCertificateFile/c SSLCertificateFile <任意のコンテナ内ディレクトリ>/server.crt" -e "/^SSLCertificateKeyFile/c SSLCertificateKeyFile <任意のコンテナ内ディレクトリ>/server.key" /opt/WebOTX/domains/domain1/config/WebServer/ssl.conf' -v <ホストの任意のディレクトリ>:<任意のコンテナ内ディレクトリ> -it -d <コンテナイメージ名:タグ>
# docker ps CONTAINER ID IMAGE COMMAND CREATED 537d3c548628 <コンテナイメージ名:タグ> "/opt/WebOTX/bin/doc***" 2 minutes ago
コンテナの実行が確認できれば、正しく動作しています。
公開イメージに対する追加構成は [ コンテナイメージの生成(フルプロファイル, Linux) > 生成済みのWebOTX Application Serverのコンテナイメージに対する追加構成 ] を参照してください。
ただし、公開イメージに対して追加構成を実施するには、まずライセンスを正式ライセンスに入れ替える必要があります。 ライセンスを入れ替えたイメージを生成するには、追加構成用のDockerfileでOTXLDelコマンド(Expressのみ必要)およびOTXLAddコマンドを実行します。 ライセンスの入れ替えは、ドメイン起動前に行う必要があるため、追加構成用のDockerfileの初めの方で実施します。
Caution
OTXLAddコマンドおよびOTXLDelコマンドは成功すると終了コードが非0の値になります。そのため、実行コマンドに「!」を付けて、終了コードを反転させる必要があります。
また、公開イメージではOTXLAddコマンドおよびOTXLDelコマンドをrootユーザだけでなくrootグループに対しても実行可能としています。そのため、公開イメージのWebOTX運用管理ユーザに設定されているユーザでもこれらのコマンドを実行できます。
コマンドの詳細は以下のコマンドリファレンスを参照してください。
[ リファレンス > コマンドリファレンス > ライセンス管理コマンド > OTXLAdd, OTXLDel ]
FROM <公開されているWebOTX Application Server Expressのコンテナイメージ名:タグ> RUN ! /opt/share.nec/bin/OTXLDel 2 && ! /opt/share.nec/bin/OTXLAdd <ライセンス>
Caution
追加でライセンスを登録する場合は、「&& ! /opt/share.nec/bin/OTXLAdd <ライセンス>」を追加します。
FROM <公開されているWebOTX Application Server Standardのコンテナイメージ名:タグ> RUN ! /opt/share.nec/bin/OTXLAdd <ライセンス>
OpenShift 環境での WebOTX Application Server の運用方法について説明します。
OpenShift では、あらかじめ生成したコンテナイメージを使用するだけでなく、OpenShift 上でコンテナイメージを生成することができます。 ここでは、OpenShift 上で WebOTX Application Server のコンテナイメージを生成する方法を説明します。 oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
[ コンテナイメージの生成(フルプロファイル, Linux) ] の手順に従い、コンテナイメージ生成に必要なファイルを準備します。
[ コンテナイメージの生成(フルプロファイル, Linux) > ファイルの準備とコンテナイメージの生成 ] の手順(13) コンテナイメージ生成用ファイルの準備開始確認で「y」を入力してファイル準備を実行した後、手順(16) コンテナイメージ生成開始確認で「q」を入力してコンテナイメージ生成をキャンセルします。
公開イメージをベースに追加構成を行う場合は、[ 公開イメージの利用 > 公開イメージに対する追加構成 ] の手順に従い、コンテナイメージ生成に必要なファイルを準備します。
以下のコマンドで、バイナリソースによる Docker ビルドストラテジーの BuildConfig を作成します。
$ oc new-build --strategy docker --binary --name <BuildConfig名(任意の名前)>
プロキシ環境下では、必要に応じて --build-arg オプションで環境変数 http_proxy, https_proxy, no_proxy を指定してください。
以下のコマンドで、コンテナイメージ生成用ファイルを準備したディレクトリを入力として指定し、ビルドを開始します。
$ oc start-build <BuildConfig名> --from-dir <ファイルを準備したディレクトリ>
実行結果はOpenShiftの管理コンソールか oc get is コマンドで確認できます。 また、oc start-build コマンドに --follow オプションを追加すると、コンテナイメージ生成の実行状況が表示されます。
ここでは、OpenShift 上で WebOTX Application Server のコンテナイメージからコンテナ(Pod)を起動する方法を説明します。 oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
WebOTX運用管理ユーザをroot以外で構成した WebOTX Application Server を OpenShift 上で動作させるには、restricted の SCC で十分です。
restricted は既定で適用される SCC であるため、WebOTX運用管理ユーザをroot以外で構成した場合は、SCC の設定は不要です。
WebOTX運用管理ユーザをrootで構成した WebOTX Application Server を OpenShift 上で動作させるには、anyuid の SCC が必要です。
以下のコマンドで、対象のサービスアカウントに anyuid の SCC を付与します。
この設定は各プロジェクトで 1 回実行すれば十分です。
$ oc adm policy add-scc-to-user anyuid -z <サービスアカウント名>
デフォルトのサービスアカウントに SCC を付与する場合は、サービスアカウント名に「default」を指定します。
Memo
OpenShift に標準で定義された SCC を使用せずに独自に SCC を定義する場合は、SCC の RunAsUser に次の権限を指定します。
WebOTX運用管理ユーザが root 以外の場合：RunAsAny, MustRunAsRange, MustRunAsNonRoot権限のいずれか
WebOTX運用管理ユーザが root の場合：RunAsAny権限
以下のコマンドで、生成したコンテナイメージをデプロイします。
$ oc new-app -l app=<appラベル名(任意の名前)> <ImageStream名>
ImageStream名はコンテナイメージ生成時に指定した BuildConfig名と同じ名前を指定します。
コンテナ(Pod)に外部からアクセスする場合は、以下のコマンドでClusterIPサービスを作成します。
$ oc create service clusterip <サービス名> --tcp=<コンテナ(Pod)内のポート番号>
サービス名はコンテナイメージのデプロイ時に指定した appラベル名と同じ名前を指定します。 --tcp オプションは複数指定可能です。
作成したサービスは、以下のコマンドで公開します。
$ oc expose svc/<サービス名> --port <コンテナ(Pod)内のポート番号>
複数のポートを公開する場合は、以下のように --name オプションで異なる名前を指定します。 --name オプションを指定しない場合、サービス名と同じ名前の Route が作成されます。
$ oc expose svc/<サービス名> --name <Route名(任意の名前)> --port <コンテナ(Pod)内のポート番号>
oc get routes コマンドや oc status コマンドで公開したポートにアクセスするためのホスト名、URL を確認できます。