NEC Mark
WebOTX Manual V11.1 (第6版)

目次を表示

3. テスト手法

本節では、作成したコンテナイメージを下記環境でテスト、デバッグを行う方法について説明します。

3.1. テストの手段

3.1.1. 手段

アプリケーションをテストする手段について説明します。目的にあわせて選択してください。

3.1.1.1. Webブラウザ

WebUIが提供されている場合に、目視での確認を行います。

3.1.1.2. REST API発行ツール

任意のREST APIを発行するツールで、提供サービスの確認を行います。

3.1.1.3. 自製テストプログラム

REST APIの発行や結果確認などを自由にプログラミングできます。

3.1.1.4. OpenAPI連携ツール

REST APIの仕様を定義したOpenAPIドキュメント(YAML/JSON)が提供されている場合に、それを利用してテストの手段とするもので、次のようなものがあります。

詳細については、 [ アプリケーション開発 > その他のアプリケーション > OpenAPIを利用した開発モデル ] を参照してください。

3.1.1.5. テストフレームワーク

テストに関するフレームワークとして、次のようなものがあります。

3.1.1.6. その他

その他にも、テストに関連して、次のようなものを利用できます。

3.1.2. テストフェーズでの利用

各テストフェーズにおいて、目的に応じて次のようなツールを利用できます。

3.1.2.1. 共通

テストフェーズによらず、開発環境、ビルド環境において、CI/CDを実現する次のようなツールが有用です。

3.1.2.2. 単体テスト (UT)

開発環境、ビルド環境で実施するUTでは、次のようなツールが有用です。

3.1.2.3. 機能テスト (FT)

開発環境、ビルド環境、評価環境(スタンドアロン、コンテナ)で実施するFTでは、次のようなツールが有用です。

3.1.2.4. 結合テスト (IT)

評価環境(スタンドアロン、コンテナ)、ステージング環境で実施するITでは、次のようなツールが有用です。

3.1.2.5. 総合テスト (ST)

ステージング環境／本番環境で実施するSTでは、次のようなツールが有用です。

3.1.3. Eclipse MicroProfileのテスト

Eclipse MicroProfile仕様の各機能を評価する際に、利用できるツール等について説明します。

詳細については、以下を参照してください。

3.1.3.1. MicroProfile Config

Java のシステムプロパティ、環境変数、プロパティファイル(META-INF/microprofile-config.properties)に設定された値を、優先度に従ってアプリケーションで取得できることを確認します。
このために利用するツールは特にはありません。

詳細については、以下を参照してください。

3.1.3.2. MicroProfile Fault Tolerance

サービスの耐障害性と回復性のための各機能を評価する際に、次のようなツールを利用できます。

詳細については、以下を参照してください。

3.1.3.3. MicroProfile Health Check

サービスのヘルス状態をエンドポイント(/health)で取得できることを評価する際に、次のようなツールを利用できます。

詳細については、以下を参照してください。

3.1.3.4. MicroProfile JWT Authentication

OpenID Providerから返却されたトークンの復号化等の変換を行う機能を評価する際に、次のようなツールを利用できます。

詳細については、以下を参照してください。

3.1.3.5. MicroProfile Metrics

メトリクスを公開するエンドポイント(/health)を評価する際に、次のようなツールを利用できます。

詳細については、以下を参照してください。

3.1.3.6. MicroProfile OpenAPI

OpenAPIドキュメントを公開するエンドポイント(/openapi)を評価する際に、次のようなツールを利用できます。

詳細については、以下を参照してください。

3.1.3.7. MicroProfile OpenTracing

サービスの依存関係や各サービスのレイテンシなどのトレーシングを評価する際に、次のようなツールを利用できます。

詳細については、以下を参照してください。

3.1.3.8. MicroProfile Rest Client

HTTPを介してRESTfulサービスを呼び出すためのタイプセーフなアプローチを評価する際に、後段の実サービスの代替として、次のようなツールを利用できます。

詳細については、以下を参照してください。


3.2. Application Serverコンテナの起動

テストを実行するために、テスト対象となるアプリケーション(Application Serverコンテナ)を起動します。

コンテナ環境とコンテナオーケストレーションツール環境における、Application Serverコンテナの操作について説明します。

3.2.1. コンテナ環境

ビルドしたコンテナイメージは、デフォルトでは当該コンテナ環境下でキャッシュされた状態で、ローカルでのみ利用できます。

コンテナイメージを共有する場合は、Docker Hub、クラウドのレジストリサービス、もしくはプライベートに用意したDockerレジストリのリポジトリでバージョン管理します。リポジトリに登録(push)して公開、リポジトリから取得(pull)して利用します。

詳細については、 [ 構築・運用 > コンテナ型仮想化 > WebOTX Application Server のコンテナイメージ > コンテナの起動・停止 ] を参照してください。

3.2.1.1. コンテナの起動

コンテナの起動は、docker runコマンドでイメージ名を指定して起動します。

Dockerレジストリに登録されたコンテナイメージを起動するコマンドイメージは以下です。
ここでは、httpポートを異なるポートで公開し、バックグラウンドで起動しています。

# docker run -it -d -p 18080:8080 -e OTX_LOG_TO_STDIO=true registry.server:5000/webotx-micro
オプション 説明
-it 疑似 TTY（pseudo-TTY）をコンテナの標準入力にアタッチ
-d コンテナをバックグラウンドで実行し、コンテナ ID を表示
-p コンテナのポートをホスト側に公開
例) -p 18080:8080
Webサーバのhttpポート8080をホスト側で18080で公開
-e 環境変数を指定
例) -e OTX_LOG_TO_STDIO=true
マイクロサービスプロファイル版で有効な環境変数で、ログファイルの内容を標準出力に表示

コンテナが起動されたかの確認は、docker psコマンドで確認します。

# docker ps
    STATUS              PORTS                                                                NAMES
fe3441a8b1a8        registry.server:5000/webotx/webot-…"   "java -jar sample-ap…"   About a minute ago   Up About a minute   0.0.0.0:18080->8080/tcp                                              eloquent_swanson

コンテナをバックグラウンドで実行した場合、コンテナが出力するメッセージは、コンテナIDを指定してdocker logsコマンドで確認します。

# docker logs -t <コンテナID>

マイクロサービスプロファイル版の場合、下記メッセージが出力されていれば、ドメインは起動完了しています。
起動時に、環境変数の指定(-e OTX_LOG_TO_STDIO=true)が必要です。

2021-04-28T02:23:45.927039570Z Unpacked base directory is /opt
2021-04-28T02:23:46.467722223Z com.nec.webotx.logging.WebOTXLoggerFactory
・・・・・
2021-04-28T02:23:58.135277686Z 2021-04-28 02:23:58,133 INFO Loading application [sample-app-1.0-SNAPSHOT] at [/sample-app-1.0-SNAPSHOT] [main]
2021-04-28T02:23:58.333828203Z 2021-04-28 02:23:58,329 INFO Configuration saved at /opt/WebOTX/domains/domain1/config/domain.xml [pool-19-thread-1]
2021-04-28T02:23:58.333847798Z 2021-04-28 02:23:58,333 INFO     DEPLOY   - sample-app-1.0-SNAPSHOT was successfully deployed in 3,821 milliseconds. [main]
2021-04-28T02:23:58.333850769Z 2021-04-28 02:23:58,333 INFO     DEPLOY   - OTX03010088: deployment completed [main]
2021-04-28T02:23:58.338441952Z 2021-04-28 02:23:58,335 INFO     DEPLOY   - Elapsed time: 3,826 ms [main]
2021-04-28T02:23:58.338459938Z 2021-04-28 02:23:58,337 INFO     MICROPROFILE - Version 10.40.00.00 (build 20210423) ready in 12,008 (ms) [main]
2021-04-28T02:23:58.338469215Z 2021-04-28 02:23:58,338 INFO Version 10.40.00.00 (build 20210423) ready in 12,008 (ms) [main]

フルプロファイル版の場合、下記メッセージが出力されていれば、ドメインは起動完了しています。

2021-03-15T04:06:05.458089355Z WEBOTX_DOCKER_DOMAIN_NAME=domain1
2021-03-15T04:06:05.458143485Z WEBOTX_DOCKER_VERBOSE=1
・・・・・
2021-03-15T04:06:36.525157224Z Domain [domain1] is running [Version 10.40.00.00 (build 20210305)].
2021-03-15T04:06:36.525190830Z
2021-03-15T04:06:36.525261708Z     * Standard JMX Clients (like JConsole) can connect to JMXServiceURL:
2021-03-15T04:06:36.525268589Z         [service:jmx:rmi:///jndi/rmi://7201fbd74af5:6212/jmxrmi] for domain management purposes.
2021-03-15T04:06:36.525316141Z
2021-03-15T04:06:36.525365480Z     * Domain listens on at least following ports for connections:
2021-03-15T04:06:36.525405248Z         [80 443 5858 6212 6712].
2021-03-15T04:06:36.525439426Z
2021-03-15T04:06:36.525780424Z Command start-domain executed successfully.

ドメインの起動完了確認は、ヘルスチェックエンドポイント(/health)の結果でも判断できます。
例えば、curlコマンドで次のように確認します。

# curl http://localhost:18080/health
{"outcome":"UP", "checks":[]}

アプリケーションにMicroProfile Health Checkを実装すると、例えばアプリケーションが後段のサービスの完了を待ち合わせる必要がある場合など、アプリケーションレベルの起動完了を確認することができます。

テストにおいては、当該エンドポイントに対して、スクリプトでのcurlコマンド発行や、jax-rsクライアントプログラムでのhttpリクエスト発行により、テストの開始契機を待ち合わせます。

3.2.1.2. コンテナの停止

コンテナの停止は、docker stopコマンドでコンテナIDを指定して起動します。

# docker stop <コンテナID>

停止時にコンテナが出力するメッセージは、docker logsコマンドでコンテナIDを指定して確認します。

# docker logs -t <コンテナID>

マイクロサービスプロファイル版の場合、以下のメッセージが出力されます。

2021-04-28T04:07:41.448574154Z 2021-04-28 04:07:41,442 Shutdown process will start [GlassFish Shutdown Hook]

フルプロファイル版の場合、以下のメッセージが出力されます。

2021-03-15T04:21:57.377975656Z Domain domain1 stopped.
2021-03-15T04:21:57.396333598Z Command stop-domain executed successfully.
コンテナの削除

停止したコンテナの削除は、docker rmコマンドでコンテナIDを指定して行います。

# docker rm <コンテナID>

3.2.2. コンテナオーケストレーションツール環境

コンテナオーケストレーションツール環境では、事前に配備したWebOTX Operatorを介してApplication Serverを制御します。
また、当該環境では、Application Serverコンテナは、logstashコンテナとともにPodという実行単位で扱われます。

以降、カスタムリソースの準備と、Podの起動停止についてAmazon EKSなどのKubernetes環境とOpenShift環境での操作について説明します。

3.2.2.1. カスタムリソースの準備

WebOTX Operatorが提供するWebOTX Application Server用のカスタムリソース(webotx_cr.yaml)に、作成したApplication Serverコンテナのコンテナイメージ名を設定します。

# Vendor: NEC Corporation.
# Product: WebOTX Operator for Kubernetes
# Version: 10.40.00.00
#
apiVersion: webotx.nec.com/v2
kind: ApplicationServer
metadata:
  # Replace this with the ApplicationServer Object name
  name: REPLACE_APPLICATIONSERVER_NAME
・・・・・

REPLACE_APPLICATIONSERVER_NAMEの部分を、次のようにDockerレジストリに登録されているコンテナイメージ名で置換します。

  name: resistry.server:5000/webotx-micro

カスタムリソースには、このほかに、ポート番号などApplication Serverの各種設定を定義できます。

詳細は、マニュアル「」を参照してください。

3.2.2.2. Kubernetes環境での操作

ここでは、Podの起動停止における操作の流れについて説明します。

Kubernetes環境でのApplication Serverの展開については、 [ 構築・運用 > コンテナ型仮想化 > WebOTX Application Server の展開・更新・削除 ] を参照してください。

Podの起動

準備したカスタムリソースをkubectl applyコマンドで適用すると、Application ServerのPodが起動します。

$ kubectl apply -f webotx_cr.yaml -n <Namespace名>

適用したリソースは、以下のコマンドで確認できます。

$ kubectl get ApplicationServer -n <Namespace名>
NAME                 AGE
webotx-micro         1d

Podが起動状態は、以下のコマンドで確認します。OperatorのPodとともに状態が表示されます。

$ kubectl get pod -n <Namespace名>
NAME                                  READY   STATUS    RESTARTS   AGE
webotx-micro-84d88f6d7c-kx2qf         2/2     Running   1          1h
webotx-operator-754c75f9dc-kdv7m      1/1     Running   1          1d

Application Serverコンテナが出力するメッセージは、以下のコマンドで確認します。
Pod名とApplication Serverのコンテナ名(固定)を指定します。

$ kubectl logs <Pod名> -c webotx-as -n <Namespace名>

メッセージの内容や、ヘルスチェックによる起動確認の方法については、コンテナ環境と同じです。

Podの停止

カスタムリソースをkubectl deleteコマンドで削除すると、Application ServerのPodが停止します。

kubectl delete -f webotx_cr.yaml -n <Namespace名>
3.2.2.3. OpenShift環境での操作

ここでは、Podの起動停止における操作の流れについて説明します。

OpenShift環境でのApplication Serverの展開については、 [ 構築・運用 > コンテナ型仮想化 > OpenShift への WebOTX Application Server の展開 ] を参照してください。

Podの起動

準備したカスタムリソースをoc applyコマンドで適用すると、Application ServerのPodが起動します。

$ oc apply -f manifest/webotx_cr.yaml

適用したリソースは、以下のコマンドで確認できます。

$ oc get ApplicationServer
NAME                 AGE
webotx-micro         1d

Podの起動状態は、以下のコマンドで確認します。OperatorのPodとともに状態を確認できます。

$ oc get pod
NAME                                  READY   STATUS    RESTARTS   AGE
webotx-micro-84d88f6d7c-kx2qf         2/2     Running   1          1h
webotx-operator-754c75f9dc-kdv7m      1/1     Running   1          1d

Application Serverコンテナが出力するメッセージは、以下のコマンドで確認します。
Pod名とApplication Serverのコンテナ名(固定)を指定します。

$ oc logs <Pod名> -c webotx-as

メッセージの内容や、ヘルスチェックによる起動確認の方法については、コンテナ環境と同じです。

Podの停止

カスタムリソースをoc deleteコマンドで削除すると、Application ServerのPodが停止します。

$ oc delete -f webotx_cr.yaml
Route定義

Application Serverコンテナに外部からアクセスする場合、Routeを作成するために、以下のコマンドを実行します。複数のポートを公開する場合は、公開するポート番号毎に異なる Route 名を指定します。

oc expose svc/<カスタムリソース名> --name <Route名> --port <公開するポート番号>

Routeの確認には、以下のコマンドを実行します。

oc get route

以下のような情報が出力されます。

NAME              HOST/PORT                                           PATH   SERVICES              PORT   TERMINATION   WILDCARD
webotx-as-http    webotx-as-http-example.apps.otx4k.smileninja.net           webotx-as-container   8080                 None
webotx-as-https   webotx-as-https-example.apps.otx4k.smileninja.net          webotx-as-container   8443                 None

Routeの削除は、以下のコマンドを実行します。

oc delete route <Route名>

3.3. テストの方法

コンテナで起動したApplication Serverに対して、前述した目的に応じて「テストの手段」を選択してテストを実行します。

3.3.1. 手動でのテスト

特に説明することはありません。

3.3.2. Mavenでのテスト

Mavenでのテストは、次のような場面が考えられます。

WebOTX Uber JARのpom.xmlの修正については、 [ 構築・運用 > コンテナ環境の開発から運用まで > アプリケーション開発手法 > Mavenでの実行 ] を参照してください。

3.3.3. CIツールでのテスト

代表的なCIツールであるJenkins上でビルドを行う場合、Jenkinsのパイプラインでビルドに連動して実行するテスト処理を定義します。 次のような場面で考えられます。

Jenkinsのパイプライン定義については、 [ 構築・運用 > コンテナ環境の開発から運用まで > ビルド・デプロイ方法 > パイプラインでの実装方法 ] を参照してください。

3.4. デバッグの方法

テストの結果、httpステータスコードがエラーであったり、レスポンスデータが不正である場合に、アプリケーションの不具合を調査するために、ソースコードのデバッグをコンテナ環境下で行う方法について説明します。

3.4.1. デバッグオプション

コンテナをデバッグモードで起動するには、Application Serverのjava実行環境に対して、デバッグオプションをjavaオプションとして指定します。

オプションについては、 [ 構築・運用 > コンテナ環境の開発から運用まで > アプリケーション開発手法 > デバッグ > デバッグモードでの起動 ] を参照してください。

3.4.2. デバッグ版アプリケーションの構築

デバッグ対象となるアプリケーションは、デバッグ情報をjavacコンパイル時に指定しておく必要があります。

設定については、 [ 構築・運用 > コンテナ環境の開発から運用まで > アプリケーション開発手法 > デバッグ > デバッグモードのコンパイル ] を参照してください。

3.4.3. WebOTX Developerの設定

WebOTX Developer側では、コンテナ環境で起動したApplication Serverのjavaプロセスで開いたデバッグ用ポートに対してアタッチする形でデバッグを行います。

コンテナ環境の場合、実ポートではなく、コンテナ環境外に公開したポート番号を指定します。

設定については、 [ 構築・運用 > コンテナ環境の開発から運用まで > アプリケーション開発手法 > デバッグ > WebOTX Uber JARプロセスへのアタッチ ] を参照してください。

3.4.4. Application Serverの設定

3.4.4.1. コンテナ環境
マイクロサービスプロファイル版

コンテナ起動時に、環境変数 JAVA_TOOL_OPTIONS に上記デバッグオプションを指定します。
また、サービス用のポート番号に加えて、デバッグ用のポート番号もコンテナ外に公開する指定も行います。
指定例は、以下のとおりです。

# docker run -it -p 18080:8080 -p 14004:4004 -e OTX_LOG_TO_STDIO=true -e JAVA_TOOL_OPTIONS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4004" webotx/webotx-uberjar
フルプロファイル版

Application Serverには、属性として、デバッグオプションとその有効化フラグ(デフォルトは無効)が定義されています。

server.java-config.debug-enabled = false
server.java-config.debug-options = -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4004

これらの属性は、Application Serverの設定ファイル /opt/WebOTX/domains/domain1/config/domain.xml に定義されているため、このフラグをコンテナ起動時にtrueに更新することでデバッグオプションを有効化します。

      <java-config classpath-suffix="" debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4004" debug-enabled="true" system-classpath="">

コンテナ起動時に、環境変数 WEBOTX_DOCKER_PREPROCESS に、有効化フラグをtrueに書き換えるコマンド実行イメージを指定します。
また、サービス用のポート番号に加えて、デバッグ用のポート番号もコンテナ外に公開する指定も行います。
指定例は、以下のとおりです。

# docker run -it -p 18080:8080 -p 14004:4004 -e WEBOTX_DOCKER_PREPROCESS='sed -i -e "s/<java-config \(.*\)>/<java-config \1 debug-enabled=\"true\">/g" /opt/WebOTX/domains/domain1/config/domain.xml'
3.4.4.2. コンテナオーケストレーションツール環境
マイクロサービスプロファイル版

環境変数 JAVA_TOOL_OPTIONS に上記デバッグオプションを指定します。

Operatorで提供されるConfigMapのリソースファイル(configmap.yaml)に、以下の定義を追加するか、新規作成して適用します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-env
data:
    JAVA_TOOL_OPTIONS: "-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4004"

Operatorで提供されるApplicationServerのカスタムリソースファイル(webotx_cr.yaml)に、上記ConfigMapから環境変数を設定する、以下の定義を追加して適用します。

apiVersion: webotx.nec.com/v2
kind: ApplicationServer
metadata:
  # Replace this with the ApplicationServer Object name
  name: webotx-micro
spec:
  # WebOTX related settings
  webotx:
    # ConfigMap
    envFrom:
      configMaps:
        - user-env

ポート番号を外部に公開するには、serviceの定義に以下を追加します。
nodePortは、kubernetes の制限により30000〜32767の範囲で設定します。

  # Service manifest definition settings
  service:
    # Configure NodePort service.
    type: NodePort
    ports:
    - name: debug
      protocol: TCP
      targetPort: 4004
      port: 4004
      nodePort: 30004

カスタムリソースの設定については、 [ リファレンス > 設定 > WebOTX Operator for Kubernetes > カスタムリソース設定項目 ] を参照してください。

フルプロファイル版

フルプロファイル版では、環境変数 WEBOTX_DOCKER_PREPROCESS を定義します。
有効化する方法については、マイクロサービスプロファイル版と同様です。

Copyright (C) 1998 - 2023 NEC Corporation. All rights reserved.