|
|
WebOTX Manual V11.1 (第6版) 目次を表示 |
コンテナエンジンに 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のコンテナイメージを利用する手順を説明します。
| コンテナイメージ(*1) <コンテナイメージ名:タグ> |
製品名 | ベースイメージ | JDK | ライセンス | Webサーバ | WebOTX 運用管理ユーザ |
|---|---|---|---|---|---|---|
| webotx/webotx-express-ubi7:11.11.00.00 | WebOTX Application Server Express V11.1 Processor License for Container (Linux 版) | registry.access.redhat.com/ubi7/ubi | OpenJDK 8 | お試し版 (*2) | WebOTX内蔵型(JavaベースのWebサーバ) | 非root |
| webotx/webotx-express-ubi8:11.11.00.00 | WebOTX Application Server Express V11.1 Processor License for Container (Linux 版) | registry.access.redhat.com/ubi8/ub | OpenJDK 8 | お試し版 (*2) | WebOTX内蔵型(JavaベースのWebサーバ) | 非root |
| webotx/webotx-standard-ubi7:11.11.00.00 | WebOTX Application Server Standard V11.1 Processor License for Container (Linux 版) | registry.access.redhat.com/ubi7/ubi | OpenJDK 8 | なし (*3) | WebOTX Webサーバ(Apache HTTP Server 2.4.xxベース) | 非root |
| webotx/webotx-standard-ubi8:11.11.00.00 | WebOTX Application Server Standard V11.1 Processor License for Container (Linux 版) | registry.access.redhat.com/ubi8/ubi | OpenJDK 8 | なし (*3) | WebOTX Webサーバ(Apache HTTP Server 2.4.xxベース) | 非root |
(*1) 公開しているイメージの最新バージョン情報はdockerhubで確認してください。
(*2) お試し版として、公開日より 365 日間使用できます。引き続き利用する場合は、
[ ライセンスの入れ替え > WebOTX Application Server Express の場合 ] の手順に従い、ライセンスを入れ替えます。
(*3) ご利用に際して、
[ ライセンスの入れ替え > 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 Express にはあらかじめ、お試し版ライセンスが入っています。 正式ライセンスへの入れ替えについて説明します。
$ 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 を確認できます。