|
|
WebOTX Manual V11.1 (第6版) 目次を表示 |
|
|
|
WebOTX Manual V11.1 (第6版) 目次を表示 |
本節では、次のケースでのアプリケーション開発について説明します。
コンテナ化とは、アプリケーションをWebOTX Application Serverの実行基盤とともにコンテナ環境で動作可能な形態(コンテナイメージ)にすること、その際にアプリケーションをコンテナ環境の特性に適合させること、を意味します。
WebOTXでは、コンテナ化のために、コンテナイメージを作成するための機能だけでなく、アプリケーションのコンテナ環境への適合性を検証する支援機能を提供しています。
マイクロサービス化とは、アプリケーションをマイクロサービスアーキテクチャ(従来のモノリシックな構造に対して、変更容易性・スケーラビリティ・耐障害性に優れるサービスを細分化した構造)に基づいた実装とすること、サービスをEclipse MicroProfile仕様が提供する機能を利用した実装とすること、を意味します。
WebOTXでは、マイクロサービス化のために、軽量化したWebOTX Application Serverの実行基盤や、Eclipse MicroProfile仕様に準拠した実装を提供しています。
WebOTXが対応するEclipse MicroProfileの各機能について簡単に説明します。
詳細については、以下を参照してください。
Java のシステムプロパティ、環境変数、プロパティファイル(META-INF/microprofile-config.properties)に設定された値を、優先度に従ってアプリケーションで取得するためのAPIを提供します。
これにより、アプリケーションでは、どこで設定が行われているかを意識することなく、同じAPIにより値を取得できます。
詳細については、以下を参照してください。
サービスの耐障害性と回復性を実現するための次のような機能を提供します。
| 機能 | 概要 |
|---|---|
| Timeout | 実行時間を制限します。 |
| Retry | エラー発生時にリトライします。 |
| Fallback | エラー発生時の後処理を実行します。 |
| Bulkhead | 同時実行数を制限します。 |
| CircuitBreaker | エラー頻発時の要求受付を抑止します。 |
| Asynchronous | 実行を非同期にします。 |
これにより、アプリケーションでは、アノテーションなど簡易な実装だけで、サービス異常時の多種多様な制御を実現できます。
詳細については、以下を参照してください。
サービスのヘルス状態をエンドポイント(/health)で公開する機能を提供します。
これにより、アプリケーションでは、アノテーションなど簡易な実装だけで、アプリケーション単位の各種状態をWebOTX全体の状態に統合して公開できます。
詳細については、以下を参照してください。
OpenID Providerから返却されたトークンの復号化等の変換を行う機能を提供します。
これにより、アプリケーションでは、アノテーションなど簡易な実装だけで、認証機能を実現できます。
詳細については、以下を参照してください。
マイクロサービスのさまざまなデータを定量化し、定量化したデータを管理しやすいように加工して、メトリクスとしてエンドポイント(/metrics)で公開する機能を提供します。base(共通)、vender(ベンダー固有)、application(アプリケーション固有)の3種類のメトリクスがあり、acceptヘッダーに応じてPrometheus形式かJSON形式のデータとして返却します。
これにより、アプリケーションでは、アノテーションなど簡易な実装だけで、アプリケーション固有のメトリクスを公開できます。
詳細については、以下を参照してください。
JAX-RSアプリケーションから、OpenAPI v3 specification準拠のAPIドキュメントを自動生成し、それをエンドポイント(/openapi)で公開する機能を提供します。
これにより、次のようなことが実現できます。
詳細については、以下を参照してください。
サービスの依存関係や各サービスのレイテンシなどのトレーシングなどができる機能を提供します。分散トレーシングのコンテキストをリクエストヘッダでサービス間で伝達し、その情報をJaegerなどのトレーサーにストアして依存関係やレイテンシなどを可視化・分析で利用します。
これにより、アプリケーションでは、アノテーションなど簡易な実装だけで、分散トレーシングに必要な処理を実装できます。
詳細については、以下を参照してください。
HTTPを介してRESTfulサービスを呼び出すためのタイプセーフなアプローチを提供します。JAX-RSリソースが定義されたinterfaceを元にそのクライアントを作成し、そのinterfaceのメソッドを呼び出す形となります。
これにより、アプリケーションでは、アノテーションなど簡易な実装だけで、サービスの呼出しを実装できます。
詳細については、以下を参照してください。
オンプレ環境から移行するコンテナ環境の実行基盤として提供するApplication Server製品について説明します。
コンテナ環境下でマイクロサービス化したアプリケーションに最適なマイクロサービスプロファイル版のExpress実行環境を提供します。
他の製品と異なり、javaコマンドで単体起動可能なWebOTX Uber JARという形態の軽量化された実行基盤となっており、モノリシックではない、変更容易性・スケーラビリティ・耐障害性にすぐれたマイクロサービスアーキテクチャに沿うアプリケーションの実行に適しています。
既存のアプリケーションを使用する場合には、WebOTX Developerの [ コンテナ向けアプリケーション検証機能 ] を利用して適合性を確認できます。
マイクロサービスプロファイル版のビルドは、次のような流れとなります。
ビルド手順については、 [ インストールガイド > Linux] のコンテナ向け製品 WebOTX Application Server Express for Container を参照してください。
コンテナ環境下でJava EEの機能を提供するフルプロファイル版のExpress実行環境を提供します。
オンプレからコンテナ環境に移行する場合の受け皿となり、WebOTX Developerを使用して「マイグレーションアシスタント」で変換した設定と「コンテナ向けアプリケーション検証」を利用してコンテナ化したアプリケーションをエクスポートし、それを入力としてスクリプト実行してコンテナイメージを構築します。
新規にコンテナイメージを構築する場合、V10.3と同様の方法(入力なしでスクリプトを実行)に加えて、V10.4からはDocker Hubで公開されるExpress版のベースイメージを利用する方法も可能です。
移行の場合、次の流れとなります。
公開イメージを利用する場合、次の流れとなります。
ビルド手順については、 [ インストールガイド > Linux] のコンテナ向け製品 WebOTX Application Server Express for Container を参照してください。
製品の特徴、ビルドの流れについては、Express版と同じです。
ビルド手順については、 [ インストールガイド > Linux] のコンテナ向け製品 WebOTX Application Server Standard for Container を参照してください。
WebOTX Developerで提供するコンテナ向け開発ツールについて説明します。
マイグレーションアシスタントは、旧バージョンのWebOTXからの移行作業を短時間で容易に行うための機能です。
本ツールは、コンテナ環境への移行もサポートしており、次のような流れで移行します。
オンプレミス環境への移行との主な差異は、★部分となります。
詳細については、 [ 移行 > 移行機能リファレンス > マイグレーションアシスタント ] を参照してください。
コンテナ向けアプリケーション検証は、Javaアプリケーションのコンテナ向けマイグレーション作業をサポートする機能で、インポートされたプロジェクトソースディレクトリやアプリケーションアーカイブなどを検証し、変更が必要な場所などをHTMLレポートとして出力する機能です。
詳細については、 [ アプリケーション開発 > その他のアプリケーション > コンテナ向けアプリケーション検証 ] を参照してください。
本ツールを利用することで、既存アプリケーションのコンテナ化において、客観的に課題やその対処を把握することができ、最低限の改修で動作できるフルプロファイル版のコンテナ環境を利用するか、さらにマイクロサービスアーキテクチャに則った実装に改修してマイクロサービスプロファイル版のコンテナ環境を利用するかなど、の判断の一歩とできます。
以降に、利用方法やレポート内容について簡単に説明します。
2通りの実行方法を提供します。
amt-cli.sh / amt-cli.bat)を実行WebOTX Developerでの方法は [ アプリケーションアーカイブの検証手順 ] を、コマンドでの方法は [ コマンドを使用したコンテナ向けアプリケーション検証 ] を参照してください。
実行時に、以下を検証対象として指定できます。
Memo
アーカイブファイルを検証するには、事前にプロパティファイルの設定変更が必要です。
詳細については、[ プロパティファイルの設定変更 ] を参照してください。
実行時に、WebOTX Application Serverのどのプロファイルに向けた検証とするかを選択します。
マイグレーションの場合、基本的にはJava EEアプリケーションがターゲットとなるため、「フルプロファイル向けの検証」を選択します。さらに、「マイクロプロファイル向けの検証」も行うことにより、マイクロサービス化の可能性も確認できます。
新規作成の場合、Webサービス以外も含むJava EEアプリケーションの開発であれば「フルプロファイル向けの検証」を、Webサービスのみのマイクロサービスの開発であれば「マイクロプロファイル向けの検証」を選択します。
検証の結果、マイクロサービス化に適合する場合は、マイクロサービスに適したSpring BootやEclipse Microprofileといったフレームワークも利用できます。後者は、従来から利用されているJavaEEの資産や技術を利用できるため、段階的なモダナイズには適しています。
選択したプロファイルに応じて、次のような検証ルールでチェックします。
HTMLで提供されるレポートでは、アプリケーションごとに、次のような情報を確認できます。
詳細については、 [ コンテナ向けアプリケーション検証レポート ] を参照してください。
特に、「Issues (移行課題)」で指摘された課題、対処、ストーリポイントが、コンテナ化、マイクロサービス化に必要な作業内容、作業量を検討するために有用な情報となります。
例えば、Java RMIの利用したプログラムにおいて、次のような指摘がレポートされます。
Webアプリケーション、Webサービスアプリケーションのプロジェクトにおいて、前述したEclipse MicroProfile仕様に準拠したライブラリを利用し、各機能をアプリケーションで実装できます。
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスアプリケーションの開発 ] を参照してください。
WebOTX Uber JAR生成ツールは、WebOTXマイクロサービスMavenプラグインとして提供します。
ビルドに必要な以下のものは、Maven Central Repositoryで提供しています。製品媒体にも含まれており、Mavenローカルリポジトリに直接配置することもできます。
WebOTX Uber JARを作成する作業の流れは、以下となります。
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 ] を参照してください。
ここでは、以下の開発手順について説明します。
ここでは主に、オンプレミス環境からコンテナ環境に既存アプリケーションを移行する際に行う、WebOTX Developerのコンテナ向けアプリケーション検証の作業について説明します。
例として、[ アプリケーション開発 > EJBアプリケーション > サンプル集 ] の [ EJBのステートフルセッションBean ] で提供されているサンプルプロジェクトのアーカイブファイルを使用します。
WebOTX Developerのメニューで［ファイル］−［インポート］−［既存プロジェクトをワークスペースへ］を選択し、［プロジェクトのインポート］画面で上記アーカイブファイルを選択してインポートし、[ EJBのステートフルセッションBean ]を参照してアプリケーションをビルドしてください。
既存アプリケーションのアーカイブファイル(ear)に対して検証を行います。
WebOTX Developerにおいて、アーカイブファイル(ear)の右クリックメニューで、［コンテナ向けアプリケーション検証］をクリックし、以下の検証種別を選択して「検証開始」を実行します。
検証が終わると、画面にレポート出力先フォルダのパスが表示されます。
Memo
検証種別によるレポートの違いを確認する場合は、レポート出力後にフォルダ名をリネームしてください。
詳細については、 [ コンテナ向けアプリケーション検証機能 > アプリケーションアーカイブの検証手順 ] を参照してください。
レポート出力先フォルダ直下のindex.htmlをブラウザで開いて検証レポートを確認します。
本サンプルの場合、検証種別によって、次のようなレポートを確認できます。
Issues(移行課題)で、Cloud Mandatoryが1件検出されています。画面上でクリックすると、以下の内容を確認できます。
本サンプルの特性(同じマシン内でのWebJSPからのEJB呼び出しであり、リモート呼び出しでの懸念はない)を踏まえると、フルプロファイル版のコンテナ環境であれば改修なしで移行可能と判断できます。
Issues(移行課題)で、Cloud Mandatoryが7件検出されています。画面上でクリックすると、すべて同じで、以下の内容を確認できます。
マイクロサービスプロファイル版に移行するためには、EJBアプリケーションをWebサービス化する改修が必須と判断できます。
ここでは、改造が不要なフルプロファイル版への移行を選択したものとします。
フルプロファイル版のコンテナ環境の場合も、Eclipse MicroProfileの機能を利用することができます。
必要に応じて実装してください。
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスアプリケーションの開発 ] を参照してください。
コンテナ化された既存アプリケーションは、マイグレーションアシスタントの作業のなかで、変換された設定とともにアーカイブファイル(zip)としてエクスポートされます。
コンテナ環境への移行とは、コンテナイメージを生成することを意味します。マイクロサービスプロファイル版のコンテナ製品が対応するLinux環境において、アーカイブファイル(zip)を入力として、次のような手順でビルドします。
追加構成のために中断した場合、出力先に生成されたファイルに対して追加構成を定義した後で、手動でコマンド(docker/podman)を実行してコンテナイメージを生成します。
次のような追加構成ができます。
詳細については、 [ インストールガイド > Linux] の以下を参照してください。
動作確認のため、コマンド(docker/podman)を実行してコンテナイメージを起動します。
詳細については、 [ 構築・運用 > コンテナ環境の開発から運用まで > テスト手法 > Application Serverコンテナの起動 > コンテナ環境 > コンテナの起動 ] を参照してください。
WebOTX Developerにおいて、WebOTXマイクロサービスMavenアーキタイプで作成したMavenプロジェクトをベースに、新規アプリケーションを開発する一連の作業手順について説明します。
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 > WebOTX Debeloperを利用して新規に作成 ] を参照してください。
WebOTX Developerのメニューで［ファイル］−［新規］−［その他］−［Maven］−［Maven Project］を選択し、 WebOTXマイクロサービスMavenアーキタイプ(ms-uberjar-archetype)を指定してMavenプロジェクトを生成します。
初回は、「Add Archetype...」ボタンを押下し、以下を指定してMaven Central repositoryから上記Mavenアーキタイプを追加してください。
| 項目 | 値 |
|---|---|
| Archetype Group Id | com.nec.webotx |
| Archetype Artifact Id | ms-uberjar-archetype |
| Archetype Version | 11.1 |
| Repository URL | − |
アーキタイプのパラメータ入力画面では、空欄の［Artifact Id］に任意プロジェクト名を入力します。
ここでは、次の値とします。
| 項目 | 値 | 備考 |
|---|---|---|
| Group Id | com.sample | 既定値のまま |
| Artifact Id | sample-app | プロジェクト名を指定 |
| Version | 1.0-SNAPSHOT | 既定値から変更 |
| Package | com.sample.sample_app | 自動設定値のまま |
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 > WebOTX Developerを利用して新規に作成 > Mavenプロジェクトの作成 ] を参照してください。
プロジェクトには、デフォルトで用意されているサンプルアプリケーションが展開されます。
これをベースにプロジェクト内でアプリケーションを開発するか、別プロジェクトで開発したアプリケーションアーカイブファイル(war)を統合します。
ここでは、前者の例として、Eclipse Microprofileの機能をいくつか実装したサンプルアプリケーションのソースファイルをプロジェクトに統合します。
下記アーカイブファイルは、ここで構築するWebOTX Uber JARのMavenプロジェクトの最終的なものです。
これを解凍し、下記フォルダを、作成したマイクロサービス用プロジェクトのものと、まるごと置換します。
デフォルトのものとソースフォルダが異なるため、当該プロジェクトの右クリックメニューの［ビルド・パス］−［ビルド・パスの構成］−［ソース］を開き、以下の設定変更を行います。
アプリケーションが参照するライブラリを、pom.xmlのdependency定義に追加します。
以下では、OpenTracingとJUnitのライブラリを追加しています。
<dependencies>
<dependency>
<groupId>io.opentracing</groupId>
<artifactId>opentracing-api</artifactId>
<version>0.33.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.7.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.7.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 > WebOTX Developerを利用して新規に作成 > pom.xmlの編集 ] を参照してください。
必要に応じて、アプリケーションにEclipse MicroProfileの機能を実装します。
統合したサンプルアプリケーションでは、以下の機能を使用しています。
他サービスのURLを設定として入力します。
サービスの呼び出し回数をメトリクスとして公開します。
サービスのOpenAPIドキュメントを公開します。
サービス連携の分散トレースを採取します。
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスアプリケーションの開発 ] を参照してください。
Mavenによるビルドを実行し、アプリケーションを統合したWebOTX Uber JARと、コンテナイメージ生成に必要なDockerfileをマイクロサービスパッケージとして出力します。
アプリケーションやApplication Server実行基盤に対する設定は、mavenプラグインのconfigurationに指定します。
次のような設定があります。
そのほか、コンテナイメージの基となるDockerfileに関する設定もあります。
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 > pom.xmlの設定 > 設定一覧 ] を参照してください。
ビルドは、mavenコマンドmvn packageで行います。
当該プロジェクトの右クリックメニューの［実行］−［実行の構成］−［Maven Build］で、下記設定の新規構成を作成して実行します。
| タブ | 設定項目 | 値 |
|---|---|---|
| Main | Goals | package |
ビルド結果は、WebOTX Developerのコンソールで確認します。
ビルド生成物は、${project}/target/webotx-ms-package配下に以下のものが出力されます。
| 生成物 | ファイル名 |
|---|---|
| WebOTX Uber JAR | (アプリケーション名)-(バージョン )-micro.jar 例：sample-app-1.0-SNAPSHOT-micro.jar |
| Dockerfile | Dockerfile |
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 > WebOTX Developerを利用して新規に作成 > ビルド実行 ] を参照してください。
ビルドしたWebOTX Uber JARは、javaコマンドで単体起動できます。
コマンドプロンプトで起動してCtl+Cで停止する、手動操作が基本的な実行方法となります。
ここでは、WebOTX Developerで実行する2つの方法について説明します。
WebOTX Uber JARは、自身やコンテナイメージの再作成をせずに設定を変更できるように、起動時の引数および環境変数での設定ができます。
例えば、開発マシンで一時的に同じポート番号が使用されているような場合、ビルド時ではなく、実行時の引数で変更できます。
| 引数 | 説明 | 既定値 |
|---|---|---|
| --http-port | HTTPポート番号 | 8080 |
| --https-port | HTTPSポート番号 | 8443 |
詳細については、 [ リファレンス > 設定 > マイクロサービスプロファイル ] の以下を参照してください。
WebOTX Developerから手動でWebOTX Uber JARを単体起動する場合、外部ツールとして実行する方法があります。
起動は、メニューの［実行］−［外部ツール］−［外部ツールの構成］−［プログラム］で、下記設定の新規構成を作成して実行します。
| タブ | 設定項目 | 値 |
|---|---|---|
| メイン | ロケーション | javaコマンドのパス |
| 作業ディレクトリ | プロジェクトフォルダ ${workspace_loc:/project-name} |
|
| 引数 | プログラムの引数 | -jar target/(WebOTX Uber JARのjarファイル名) 例) -jar target/sample-app-1.0-SNAPSHOT-micro.jar |
| 共通 | エンコード | MS932 |
起動すると、WebOTX Developerのコンソールビューに、WebOTX Uber JARからの標準出力と標準エラー出力が表示されます。
停止は、コンソールビューの「停止」ボタンを押下します。
この場合、WebOTX Uber JARは強制停止となるため、残存するファイルを手動で削除する必要があります。
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 > WebOTX Developerを利用して新規に作成 > Uber JARの実行確認 > WebOTX Developerで実行 ] を参照してください。
CIツールでの自動ビルド時にWebOTX Uber JARの動作確認をするような場合に、mavenで実行するためには、Mavenプラグイン(exec-maven-plugin)を利用します。
実行は、同期(デフォルト)／非同期が選択できますが、同期ではmavenに制御が戻らないため、非同期で実行します。
また、そのままmavenが停止すると、非同期に実行したWebOTX Uber JARが残存するため、maven停止に連動してjavaプロセスが停止される設定にします。
pom.xmlに追加するプラグイン定義は以下のとおりです。
| 定義 | 値 | 意味 |
|---|---|---|
| async | true | javaを非同期で実行します。 |
| asyncDestroyOnShutdown | true | maven停止に連動します。 |
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>exec-uberjar</id>
<phase>package</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>java</executable>
<arguments>
<argument>-jar</argument>
<argument>${project.build.directory}/${artifactId}-${version}-micro.jar</argument>
<argument>--basedir</argument>
<argument>${project.basedir}/workdir</argument>
</arguments>
<skip>false</skip>
<async>true</async>
<asyncDestroyOnShutdown>true</asyncDestroyOnShutdown>
</configuration>
</execution>
</executions>
</plugin>
非同期実行の場合、次のような留意点があります。
そのため、WebOTX Uber JARの実行に続けて、起動完了を待ち合わせて動作確認をするテストプログラムを連続して実行するような場合に有用です。
その場合、テストプログラムを同期実行するプラグイン(exec-maven-plugin)定義を追加します。
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>exec-tp</id>
<phase>package</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>${project.basedir}test.bat</executable>
<arguments>
</arguments>
<skip>false</skip>
</configuration>
</execution>
</executions>
</plugin>
定義例では、簡易なテスト手段としてバッチファイル(test.bat)を指定します。
例えば、次のような処理を実装します。
以下では、固定で60秒間待ち合わせた後に、サービスを呼び出しています。
@echo off REM ============================== REM Wait for starting WebOTX AS REM ============================== powershell sleep 60 REM ============================== REM Access Application Service REM ============================== curl -f http://localhost:8080/sample-app-1.0-SNAPSHOT/sample_service_a/service_a?route=A if %errorlevel% neq 0 ( exit /b 1 ) exit /b 0
起動すると、Developerのコンソールビューに、mavenの出力とともに、WebOTX Uber JARからの標準出力と標準エラー出力が表示されます。
停止は、mavenの停止に連動して強制的に行われます。
この場合、WebOTX Uber JARは強制停止となるため、残存するファイルを手動で削除する必要があります。
WebOTX Uber JARのコンソール出力について説明します。
起動開始時に、WebOTX Uber JARの展開先ディレクトリのパスが出力されます。
展開先ディレクトリ C:\Users\USERNAME\AppData\Local\Temp\webotx-micro-4352678962912490878
手動評価などで、実行中のログファイルを確認する場合は、このディレクトリ配下を確認してください。
また、実行後に残存している場合はこのディレクトリを削除してください。
自動評価で固定化したい場合には、WebOTX Uber JARの起動時引数(-basedir)でディレクトリを指定できます。
デフォルトでは、起動完了を示すメッセージはコンソールに出力されません。
ログファイル(<展開先ディレクトリ>\WebOTX\domains\domain1\logs\server.log)に出力されるメッセージで確認してください。
起動完了時に、バージョン情報と"ready"のメッセージが出力されます。
ログファイルの内容を標準出力に表示してコンソールで確認する方法もあります。
--log-to-stdio)を指定OTX_LOG_TO_STDIO=true)を指定そのほか、Eclipse MicroProfile Health Checkが提供されるヘルスチェック用エンドポイント(/health)の結果で判断できます。 curlコマンドでアクセスし、”UP"と表示されることを確認してください。
> curl http://localhost:8080/health
{"outcome":"UP", "checks":[]}
WebOTX Uber JARは、当該動作固有の一時的なディレクトリを作成して、jarファイルに含まれている実行環境を展開して動作しています。 当該ディレクトリが停止後も残存している場合、特にディレクトリを固定化していない場合は、ゴミファイルとして残り続けるため、削除する必要があります。
WebOTX Uber JARに統合したアプリケーションは、以下のURLでサービスを公開しています。
curlコマンドでアクセスし、HTTPステータスコードが200となることを確認してください。
> curl http://localhost:8080/sample-app-1.0-SNAPSHOT/sample_service_a/service_a?route=A service_a called! result : 200
確認方法としては、次のようなものが考えられます。 必要に応じて、これを手動もしくはMavenプラグインで自動実行します。
サンプルアプリケーションでは、OpenAPIドキュメントを公開用のエンドポイント(/openapi)から取得できます。curlコマンドでアクセスし、ドキュメントを取得できることを確認してください。
> curl http://localhost:8080/openapi
---
openapi: 3.0.1
info:
title: Generated API
version: "1.0"
servers:
- url: http://localhost:8080/sample-app-1.0-SNAPSHOT
description: Default Server.
paths:
/sample_service_a/service_a:
get:
summary: Service A
description: "Service A calls Service B. The route parameter specifies the target\
\ service ID (A/B/C) to cause a delay. However, A does not cause a delay."
parameters:
- name: route
in: query
required: true
schema:
type: string
responses:
"200":
description: OK
content:
text/plain:
schema:
type: string
・・・・・
サンプルアプリケーションでは、メトリクスを公開用のエンドポイント(/metrics)から取得できます。
アプリケーションのサービスに複数回アクセスした後、curlコマンドでアクセスし、メトリクスを取得できることを確認してください。デフォルトではhttpsプロトコルで公開されています。
以下はPrometheus形式で取得した場合です。
> curl https://localhost:8443/metrics/application --insecure # HELP application:hello Metrics to show how many times SampleServiceA.serviceA() was called. # TYPE application:hello counter application:hello 12.0
以下は、JSON形式で取得した場合です。
> curl https://localhost:8443/metrics/application --insecure -H "Accept: application/json"
{
"hello" : 12
}
WebOTX Uber JARに統合されたアプリケーションのソースコードをデバッグする場合、次の手順で行います。
詳細については、 [ アプリケーション開発 > その他のアプリケーション > マイクロサービスプロファイルを使用したWebOTX Uber JARの作成 > WebOTX Developerを利用して新規に作成 > Uber JARのデバッグ ] を参照してください。
コンパイル時にデバッグ情報を含めるために、pom.xmlに以下の定義を追加します。
<properties>
<maven.compiler.debug>true</maven.compiler.debug>
<maven.compiler.debuglevel>lines,vars,source</maven.compiler.debuglevel>
</properties>
リモートデバッグを可能にするために、WebOTX Uber JAR起動時のjavaオプションに以下を追加します。ポート番号は任意です。
[JDK8] -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4004 [JDK11] -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:4004
起動すると、WebOTX Developerのコンソールに以下のメッセージが最初に表示されます。
Listening for transport dt_socket at address: 4004
このポート番号を、デバッグ時にアタッチ先として指定します。
そのほかは、実行時と同じです。
デバッグは、プロジェクトの右クリックメニューの［デバッグ］−［デバッグの構成］−［リモートJavaアプリケーション］で、下記設定の新規構成を作成して実行します。
| タブ | 設定項目 | 値 | |
|---|---|---|---|
| 接続 | 接続タイプ | 接続 (ソケット接続) | |
| 接続プロパティ | ホスト | localhost | |
| ポート | 4004 | ||
ソースコード上にブレークポイントを設定し、アプリケーションにアクセスすると、デバッグ用のパースペクティブが開かれ、デバッグが可能となります。
停止は、切断ボタンを押下します。