1.5. コンテナの起動・停止

コンテナエンジンに Dokcer を使用する場合のコンテナ起動・停止方法について説明します。 コンテナエンジンに Podman を使用する場合は、docker コマンドを podman コマンドに読み替えてください。 詳細については、使用するコンテナエンジン、コンテナオーケストレーションツールのドキュメントを参照してください。

1.5.1. コンテナの起動

以下のコマンドでコンテナイメージからコンテナを起動します。

# docker run -d <コンテナイメージ名 または コンテナイメージID>

コンテナ内のポートを外部に公開するには、docker run コマンドに -p <ホストのポート番号>:<コンテナ内のポート番号> オプションを指定してください。

1.5.2. コンテナの停止

以下のコマンドでコンテナを停止します。

# docker stop <コンテナ名 または コンテナID>

停止したコンテナは以下のコマンドで削除できます。

# docker rm <コンテナ名 または コンテナID>

不要になったコンテナイメージは以下のコマンドで削除できます。 ただし、コンテナで使用中のイメージは削除できません。あらかじめコンテナを停止してから削除してください。

# docker rmi <コンテナイメージ名 または コンテナイメージID>

1.6. 公開イメージの利用

WebOTXでは、Linux環境のWebOTX Application Server Express (フルプロファイル)およびWebOTX Application Server StandardのコンテナイメージをDocker Hub <https://hub.docker.com/u/webotx> で公開しています。 Docker Hubに公開されたWebOTX Application Serverのコンテナイメージを利用する手順を説明します。

1.6.1. コンテナイメージ一覧

コンテナイメージ一覧
コンテナイメージ(*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 の場合 ] の手順に従い、ライセンスを登録します。

1.6.2. コンテナイメージの取得

コンテナイメージの取得について説明します。
(Podmanを使用する場合は、dockerコマンドをpodmanコマンドに読み替えてください)

  1. ホストOSにログイン名 root でログインします。
    $ login: root
    
  2. コンテナイメージを取得します。以下のコマンドを実行します。
    # docker pull <コンテナイメージ名:タグ>
    
  3. コンテナイメージが取得されていることを確認します。 以下のコマンドを実行します。
    # docker images
    REPOSITORY TAG IMAGE ID CREATED
    <コンテナイメージ名> <タグ> ************ ** **** ago
    

    (*) *** 部分の表記は環境または取得日によって異なります。

    取得したコンテナイメージが表示されれば、取得完了です。

1.6.3. ライセンスの入れ替え

コンテナ起動時のライセンスの入れ替えについて説明します。
(Podmanを使用する場合は、dockerコマンドをpodmanコマンドに読み替えてください)

Caution
ご利用にはライセンスの購入が必要です。購入後、以下の手順を行ってください。

1.6.3.1. WebOTX Application Server Express の場合

WebOTX Application Server Express にはあらかじめ、お試し版ライセンスが入っています。 正式ライセンスへの入れ替えについて説明します。

  1. ホストOSにログイン名 root でログインします。
    $ login: root
    
  2. コンテナ起動時にお試し版ライセンスを削除し、正式ライセンスに入れ替えます。以下のコマンドを実行します。
    # docker run --env WEBOTX_DOCKER_PREPROCESS='/opt/share.nec/bin/OTXLDel 002;/opt/share.nec/bin/OTXLAdd <ライセンス>' -it -d <コンテナイメージ名:タグ>
    
  3. 以下のコマンドを実行して、コンテナが起動していることを確認します。
    # docker ps
    CONTAINER ID IMAGE COMMAND CREATED
    537d3c548628 <コンテナイメージ名:タグ> "/opt/WebOTX/bin/doc***" 2 minutes ago
    

    コンテナの実行が確認できれば、正しく動作しています。

1.6.3.2. WebOTX Application Server Standard の場合

WebOTX Application Server Standard にはライセンスが登録されていません。 正式ライセンスの登録について説明します。

  1. ホストOSにログイン名 root でログインします。
    $ login: root
    
  2. コンテナ起動時に正式ライセンスを登録します。以下のコマンドを実行します。
    # docker run --env WEBOTX_DOCKER_PREPROCESS='/opt/share.nec/bin/OTXLAdd <ライセンス>' -it -d <コンテナイメージ名:タグ>
    
  3. 以下のコマンドを実行して、コンテナが起動していることを確認します。
    # docker ps
    CONTAINER ID IMAGE COMMAND CREATED
    537d3c548628 <コンテナイメージ名:タグ> "/opt/WebOTX/bin/doc***" 2 minutes ago
    

    コンテナの実行が確認できれば、正しく動作しています。

1.6.4. 証明書の入れ替え

コンテナ起動時の証明書の入れ替えについて説明します。
(Podmanを使用する場合は、dockerコマンドをpodmanコマンドに読み替えてください)

1.6.4.1. WebOTX Application Server Express (WebOTX内蔵型) の場合

WebOTX内蔵型の場合の証明書の入れ替えについて説明します。

  1. ホストOSにログイン名 root でログインします。
    $ login: root
    
  2. キーストア(keystore.jks)とトラストストア(cacerts.jks)をホストの任意のディレクトリに格納します。

    Caution
    事前に証明書がインポートされているキーストア(keystore.jks)とトラストストア(cacerts.jks)が必要です。

  3. ホストの任意のディレクトリ、および、格納されたファイルに権限を付与します。以下のコマンドを実行します。
    # chmod -R o+r <ホストの任意のディレクトリ>
    
  4. SELinuxが有効な場合は、SELinuxコンテキストのタイプをread-onlyにします。以下のコマンドを実行します。
    # chcon -R -t container_share_t <ホストの任意のディレクトリ>
    

    Memo
    SELinuxの確認は、以下のコマンドを実行します。
    「Enforcing」の場合は、SELinuxが有効です。

    # getenforce
    Enforcing
    
  5. コンテナ起動時にキーストアとトラストストアを入れ替えます。以下のコマンドを実行します。
    # docker run -v <ホストの任意のディレクトリ>/cacerts.jks:/opt/WebOTX/domains/domain1/config/cacerts.jks -v <ホストの任意のディレクトリ>/keystore.jks:/opt/WebOTX/domains/domain1/config/keystore.jks -it -d <コンテナイメージ名:タグ>
    
  6. 以下のコマンドを実行して、コンテナが起動していることを確認します。
    # docker ps
    CONTAINER ID IMAGE COMMAND CREATED
    537d3c548628 <コンテナイメージ名:タグ> "/opt/WebOTX/bin/doc***" 2 minutes ago
    

    コンテナの実行が確認できれば、正しく動作しています。

1.6.4.2. WebOTX Application Server Standard (Webサーバ) の場合

Webサーバの場合の証明書の入れ替えについて説明します。

  1. ホストOSにログイン名 root でログインします。
    $ login: root
    
  2. サーバ証明書と秘密鍵をホストの任意のディレクトリに格納します。

    Caution
    事前にサーバ証明書と秘密鍵が必要です。
    ここではサーバ証明書ファイルを「server.crt」、秘密鍵ファイルを「server.key」とします。

  3. ホストの任意のディレクトリ、および、格納されたファイルに権限を付与します。以下のコマンドを実行します。
    # chmod -R o+r <ホストの任意のディレクトリ>
    
  4. SELinuxが有効な場合は、SELinuxコンテキストのタイプをread-onlyにします。以下のコマンドを実行します。
    # chcon -R -t container_share_t <ホストの任意のディレクトリ>
    

    Memo
    SELinuxの確認は、以下のコマンドを実行します。
    「Enforcing」の場合は、SELinuxが有効です。

    # getenforce
    Enforcing
    
  5. コンテナ起動時にサーバ証明書と秘密鍵を入れ替えます。以下のコマンドを実行します。
    # 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 <コンテナイメージ名:タグ>
    
  6. 以下のコマンドを実行して、コンテナが起動していることを確認します。
    # docker ps
    CONTAINER ID IMAGE COMMAND CREATED
    537d3c548628 <コンテナイメージ名:タグ> "/opt/WebOTX/bin/doc***" 2 minutes ago
    

    コンテナの実行が確認できれば、正しく動作しています。

1.6.5. 公開イメージに対する追加構成

公開イメージに対する追加構成は [ コンテナイメージの生成(フルプロファイル, Linux) > 生成済みのWebOTX Application Serverのコンテナイメージに対する追加構成 ] を参照してください。

ただし、公開イメージに対して追加構成を実施するには、まずライセンスを正式ライセンスに入れ替える必要があります。 ライセンスを入れ替えたイメージを生成するには、追加構成用のDockerfileでOTXLDelコマンド(Expressのみ必要)およびOTXLAddコマンドを実行します。 ライセンスの入れ替えは、ドメイン起動前に行う必要があるため、追加構成用のDockerfileの初めの方で実施します。

Caution
OTXLAddコマンドおよびOTXLDelコマンドは成功すると終了コードが非0の値になります。そのため、実行コマンドに「!」を付けて、終了コードを反転させる必要があります。
また、公開イメージではOTXLAddコマンドおよびOTXLDelコマンドをrootユーザだけでなくrootグループに対しても実行可能としています。そのため、公開イメージのWebOTX運用管理ユーザに設定されているユーザでもこれらのコマンドを実行できます。
コマンドの詳細は以下のコマンドリファレンスを参照してください。
[ リファレンス > コマンドリファレンス > ライセンス管理コマンド > OTXLAdd, OTXLDel ]

1.6.5.1. WebOTX Application Server Express の場合
FROM <公開されているWebOTX Application Server Expressのコンテナイメージ名:タグ>

RUN ! /opt/share.nec/bin/OTXLDel 2 && ! /opt/share.nec/bin/OTXLAdd <ライセンス>

Caution
追加でライセンスを登録する場合は、「&& ! /opt/share.nec/bin/OTXLAdd <ライセンス>」を追加します。

1.6.5.2. WebOTX Application Server Standard の場合
FROM <公開されているWebOTX Application Server Standardのコンテナイメージ名:タグ>

RUN ! /opt/share.nec/bin/OTXLAdd <ライセンス>

1.7. OpenShift を使った運用

OpenShift 環境での WebOTX Application Server の運用方法について説明します。

1.7.1. OpenShift を使ったコンテナイメージ生成

OpenShift では、あらかじめ生成したコンテナイメージを使用するだけでなく、OpenShift 上でコンテナイメージを生成することができます。 ここでは、OpenShift 上で WebOTX Application Server のコンテナイメージを生成する方法を説明します。 oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。

  1. コンテナイメージ生成用のファイルを準備

    [ コンテナイメージの生成(フルプロファイル, Linux) ] の手順に従い、コンテナイメージ生成に必要なファイルを準備します。
    [ コンテナイメージの生成(フルプロファイル, Linux) > ファイルの準備とコンテナイメージの生成 ] の手順(13) コンテナイメージ生成用ファイルの準備開始確認で「y」を入力してファイル準備を実行した後、手順(16) コンテナイメージ生成開始確認で「q」を入力してコンテナイメージ生成をキャンセルします。

    公開イメージをベースに追加構成を行う場合は、[ 公開イメージの利用 > 公開イメージに対する追加構成 ] の手順に従い、コンテナイメージ生成に必要なファイルを準備します。

  2. BuildConfig の作成

    以下のコマンドで、バイナリソースによる Docker ビルドストラテジーの BuildConfig を作成します。

    $ oc new-build --strategy docker --binary --name <BuildConfig名(任意の名前)>
    

    プロキシ環境下では、必要に応じて --build-arg オプションで環境変数 http_proxy, https_proxy, no_proxy を指定してください。

  3. ビルドの開始

    以下のコマンドで、コンテナイメージ生成用ファイルを準備したディレクトリを入力として指定し、ビルドを開始します。

    $ oc start-build <BuildConfig名> --from-dir <ファイルを準備したディレクトリ>
    

    実行結果はOpenShiftの管理コンソールか oc get is コマンドで確認できます。 また、oc start-build コマンドに --follow オプションを追加すると、コンテナイメージ生成の実行状況が表示されます。

1.7.2. OpenShift を使ったコンテナ(Pod)の起動

ここでは、OpenShift 上で WebOTX Application Server のコンテナイメージからコンテナ(Pod)を起動する方法を説明します。 oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。

  1. SCC (Security Context Constraints) の設定 (WebOTX運用管理ユーザがrootの場合のみ)

    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権限

  2. コンテナイメージのデプロイ

    以下のコマンドで、生成したコンテナイメージをデプロイします。

    $ oc new-app -l app=<appラベル名(任意の名前)> <ImageStream名>
    

    ImageStream名はコンテナイメージ生成時に指定した BuildConfig名と同じ名前を指定します。

  3. サービスの作成

    コンテナ(Pod)に外部からアクセスする場合は、以下のコマンドでClusterIPサービスを作成します。

    $ oc create service clusterip <サービス名> --tcp=<コンテナ(Pod)内のポート番号>
    

    サービス名はコンテナイメージのデプロイ時に指定した appラベル名と同じ名前を指定します。 --tcp オプションは複数指定可能です。

  4. サービスの公開

    作成したサービスは、以下のコマンドで公開します。

    $ oc expose svc/<サービス名> --port <コンテナ(Pod)内のポート番号>
    

    複数のポートを公開する場合は、以下のように --name オプションで異なる名前を指定します。 --name オプションを指定しない場合、サービス名と同じ名前の Route が作成されます。

    $ oc expose svc/<サービス名> --name <Route名(任意の名前)> --port <コンテナ(Pod)内のポート番号>
    

    oc get routes コマンドや oc status コマンドで公開したポートにアクセスするためのホスト名、URL を確認できます。