Eclipse Vert.x ランタイムガイド
Eclipse Vert.x を使用して、OpenShift およびスタンドアロン RHEL で実行するリアクティブで非ブロッキングの非同期アプリケーションを開発
概要
前書き
本ガイドでは、概念と、開発者が Eclipse Vert.x ランタイムを使用するのに必要な実用的な詳細情報を説明します。
Red Hat ドキュメントへのフィードバック (英語のみ)
弊社のドキュメントに関するご意見やご感想をお寄せください。フィードバックをお寄せいただくには、ドキュメントのテキストを強調表示し、コメントを追加できます。
本セクションでは、フィードバックの送信方法を説明します。
前提条件
- Red Hat カスタマーポータルにログインしている。
- Red Hat カスタマーポータルで、マルチページ HTML 形式でドキュメントを表示します。
手順
フィードバックを提供するには、以下の手順を実施します。
ドキュメントの右上隅にある フィードバック ボタンをクリックして、既存のフィードバックを確認します。
注記フィードバック機能は、マルチページ HTML 形式でのみ有効です。
- フィードバックを提供するドキュメントのセクションを強調表示します。
ハイライトされたテキスト近くに表示される Add Feedback ポップアップをクリックします。
ページの右側のフィードバックセクションにテキストボックスが表示されます。
テキストボックスにフィードバックを入力し、Submit をクリックします。
ドキュメントに関する問題が作成されます。
- 問題を表示するには、フィードバックビューで問題トラッカーリンクをクリックします。
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。
第1章 Eclipse Vert.x を使用したアプリケーション開発の概要
本セクションでは、Red Hat ランタイムでのアプリケーション開発の基本概念を説明します。また、Eclipse Vert.x ランタイムの概要も説明します。
1.1. Red Hat Runtimes でのアプリケーション開発の概要
Red Hat OpenShift は、クラウドネイティブランタイムのコレクションを提供するコンテナーアプリケーションプラットフォームです。ランタイムを使用して、OpenShift で Java または JavaScript アプリケーションを開発、ビルド、およびデプロイできます。
Red Hat Runtimes for OpenShift を使用したアプリケーション開発には、以下が含まれます。
- OpenShift で実行するように設計された Eclipse Vert.x、Thorntail、Spring Boot などのランタイムのコレクション。
- OpenShift でのクラウドネイティブ開発への規定的なアプローチ。
OpenShift は、アプリケーションのデプロイメントおよびモニタリングの管理、保護、自動化に役立ちます。ビジネス上の問題を小規模なマイクロサービスに分割し、OpenShift を使用してマイクロサービスをデプロイし、監視し、維持することができます。サーキットブレーカー、ヘルスチェック、サービス検出などのパターンをアプリケーションに実装できます。
クラウドネイティブな開発は、クラウドコンピューティングを最大限に活用します。
以下でアプリケーションをビルドし、デプロイし、管理できます。
- OpenShift Container Platform
- Red Hat のプライベートオンプレミスクラウド。
- Red Hat CodeReady Studio
- アプリケーションの開発、テスト、およびデプロイを行う統合開発環境 (IDE)。
本ガイドでは、Eclipse Vert.x ランタイムに関する詳細情報を提供します。その他のランタイムの詳細は、関連する ランタイムドキュメント を参照してください。
1.2. Eclipse Vert.x の概要
Eclipse Vert.x は、Java 仮想マシン(JVM)で実行されるリアクティブで非ブロッキングの非同期アプリケーションを作成するために使用されるツールキットです。
Eclipse Vert.x はクラウドネイティブとなるように設計されています。これにより、アプリケーションは非常に少ないスレッドを使用できます。これにより、新規スレッドの作成時に生じるオーバーヘッドを回避します。これにより、Eclipse Vert.x アプリケーションとサービスは、クラウド環境でメモリーと CPU クォータを効果的に使用できます。
OpenShift で Eclipse Vert.x ランタイムを使用すると、リアクティブシステムのビルドが簡単になります。ローリングアップデート、サービス検出、カナリアデプロイメントなどの OpenShift プラットフォーム機能も利用できます。OpenShift では、外部化設定、ヘルスチェック、サーキットブレーカー、フェイルオーバーなどのマイクロサービスパターンをアプリケーションに実装できます。
1.2.1. Eclipse Vert.x の主な概念
本セクションでは、Eclipse Vert.x ランタイムに関連する主要な概念を説明します。また、リアクティブなシステムの概要も説明します。
クラウドネイティブおよびコンテナーネイティブアプリケーション
クラウドネイティブアプリケーションは、通常マイクロサービスを使用してビルドされます。分離コンポーネントの分散システムを形成するように設計されています。これらのコンポーネントは、通常、多数のノードを含むクラスターでコンテナー内で実行されます。これらのアプリケーションは、個々のコンポーネントの障害に対して耐性があり、サービスのダウンタイムなしに更新される可能性があります。クラウドネイティブアプリケーションをベースとするシステムは、基礎となるクラウドプラットフォーム(OpenShift など)によって提供される自動デプロイメント、スケーリング、管理タスク、メンテナンスタスクに依存します。管理および管理タスクは、個々のマシンレベルではなく、既成の管理およびオーケストレーションツールを使用してクラスターレベルで実行されます。
リアクティブシステム
Reactive manifesto に定義されているリアクティブなシステムは、以下の特徴を持つ分散システムです。
- Elastic
- システムはさまざまなワークロードで応答し続け、必要に応じて個々のコンポーネントをスケーリングし、負荷分散して、ワークロードの違いに対応します。Elastic アプリケーションは、同時に受け取る要求の数に関係なく、同じ品質のサービスを提供します。
- Resilient
- システムは、個々のコンポーネントのいずれかが失敗しても応答し続けます。システムでは、コンポーネントは相互に分離されます。これにより、個々のコンポーネントに障害が発生した場合に迅速に復元するのに役立ちます。単一コンポーネントの障害は、他のコンポーネントの機能に影響を与えることはありません。これにより、分離されたコンポーネントの障害により他のコンポーネントがブロックされ、徐々に障害が発生するというカスケード障害が回避されます。
- 応答の応答
- 応答システムは、一貫した QoS(Quality of Service)を確実に確保するために、妥当な時間内に要求に常に応答するように設計されています。応答を維持するには、アプリケーション間の通信チャネルをブロックすることはできません。
- メッセージ駆動型
- アプリケーションの個々のコンポーネントは、非同期のメッセージパスを使用して相互に通信します。マウスクリックやサービスの検索クエリーなど、イベントが発生した場合、サービスは共通のチャネル(イベントバス)にメッセージを送信します。メッセージはそれぞれのコンポーネントによってキャッチされ、処理されます。
リアクティブシステムは分散システムです。これらは、アプリケーション開発に非同期プロパティーを使用できるように設計されています。
リアクティブプログラミング
リアクティブシステムの概念は、分散システムのアーキテクチャーを記述しますが、リアクティブプログラミングは、アプリケーションをコードレベルでリアクティブにする手法を指します。リアクティブプログラミングは、非同期およびイベント駆動型のアプリケーションを記述する開発モデルです。リアクティブアプリケーションでは、コードはイベントまたはメッセージに反応します。
リアクティブプログラミングにはいくつかの実装があります。たとえば、コールバックを使用した簡単な実装、Reactive Extensions(Rx)を使用した複雑な実装、およびコルーチンを使用した複雑な実装などです。
Reactive Extensions(Rx)は、Java におけるリアクティブプログラミングの最も成熟した形式の 1 つです。RxJava ライブラリーを使用します。
1.2.2. Eclipse Vert.x でサポートされているアーキテクチャー
Eclipse Vert.x は、以下のアーキテクチャーをサポートします。
- x86_64 (AMD64)
- OpenShift 環境の IBM Z (s390x)
- OpenShift 環境の IBM Power System (ppc64le)
イメージ名の詳細は、「 Eclipse Vert.x でサポートされる Java イメージ」 のセクションを参照してください。
1.2.3. FIPS(Federal Information Processing Standard)のサポート
FIPS (Federal Information Processing Standards) は、コンピューターシステムやネットワーク間のセキュリティーおよび相互運用性を強化するためのガイドラインと要件を提供します。FIPS 140-2 および 140-3 シリーズは、ハードウェアおよびソフトウェアの両レベルで暗号化モジュールに適用されます。
連邦情報処理標準 (FIPS) 140-2 は、U.S により開発されたコンピューターセキュリティー標準です。暗号化モジュールの品質を検証する政府および業界の作業グループ。NIST Computer Security Resource Center で公式の FIPS 公開を参照してください。
Red Hat Enterprise Linux(RHEL)は、FIPS 140-2 準拠をシステム全体で有効にする統合フレームワークを提供します。FIPS モードで動作している場合、暗号化ライブラリーを使用するソフトウェアパッケージはグローバルポリシーに従って自己設定されます。
コンプライアンスの要件については、「Red Hat Government Standards」ページを参照してください。
Red Hat ビルドの Eclipse Vert.x は FIPS が有効な RHEL システムで実行され、RHEL が提供する FIPS 認定ライブラリーを使用します。
1.2.3.1. 関連情報
- FIPS モードが有効な RHEL をインストールする方法は、「FIPS モードが有効な RHEL 8 システムのインストール」を参照してください。
- RHEL をインストールした後に FIPS モードを有効にする方法は、「FIPS モードへのシステムの切り替え」を参照してください。
第2章 アプリケーションの設定
本セクションでは、Eclipse Vert.x ランタイムと連携するようにアプリケーションを設定する方法を説明します。
2.1. Eclipse Vert.x を使用するためのアプリケーションの設定
Eclipse Vert.x を使用するようにアプリケーションを設定する場合は、アプリケーションのルートディレクトリーにある pom.xml ファイルの Eclipse Vert.
x BOM(Bill of Materials)アーティファクトを参照する必要があります。BOM は、アーティファクトの正しいバージョンを設定するために使用されます。
要件
- Maven ベースのアプリケーション
手順
Pom
.xml
ファイルを開き、io.vertx:vertx-dependencies
アーティファクトを<dependencyManagement>
セクションに追加します。Type をpom
として指定し、
scope
をimport
として指定します。<project> ... <dependencyManagement> <dependencies> <dependency> <groupId>io.vertx</groupId> <artifactId>vertx-dependencies</artifactId> <version>${vertx.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> ... </project>
以下のプロパティーを追加して、使用している Eclipse Vert.x および Eclipse Vert.x Maven Plugin のバージョンを追跡します。
プロパティーを使用して、リリースごとに変更する値を設定できます。たとえば、product または plugins のバージョンなどです。
<project> ... <properties> <vertx.version>${vertx.version}</vertx.version> <vertx-maven-plugin.version>${vertx-maven-plugin.version}</vertx-maven-plugin.version> </properties> ... </project>
アプリケーションのパッケージ化に使用されるプラグインとして
vertx-maven-plugin
を指定します。<project> ... <build> <plugins> ... <plugin> <groupId>io.reactiverse</groupId> <artifactId>vertx-maven-plugin</artifactId> <version>${vertx-maven-plugin.version}</version> <executions> <execution> <id>vmp</id> <goals> <goal>initialize</goal> <goal>package</goal> </goals> </execution> </executions> <configuration> <redeploy>true</redeploy> </configuration> </plugin> ... </plugins> </build> ... </project>
Repositories
およびpluginRepositories
を追加して、アプリケーションのビルド用のアーティファクトおよびプラグインが含まれるリポジトリーを指定します。<project> ... <repositories> <repository> <id>redhat-ga</id> <name>Red Hat GA Repository</name> <url>https://maven.repository.redhat.com/ga/</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>redhat-ga</id> <name>Red Hat GA Repository</name> <url>https://maven.repository.redhat.com/ga/</url> </pluginRepository> </pluginRepositories> ... </project>
関連情報
- Eclipse Vert.x アプリケーションのパッケージ化に関する詳細は、Vert.x Maven Plugin のドキュメントを参照してください。
第3章 Eclipse Vert.x ランタイムアプリケーションの開発およびデプロイ
新しい Eclipse Vert.x アプリケーションを作成して、OpenShift またはスタンドアロンの Red Hat Enterprise Linux にデプロイできます。
3.1. Eclipse Vert.x アプリケーションの開発
基本的な Eclipse Vert.x アプリケーションには、以下を作成する必要があります。
- Eclipse Vert.x メソッドを含む Java クラス。
-
アプリケーションをビルドするために Maven が必要とする情報が含まれる
pom.xml
ファイル。
以下の手順では、応答として
「Greetings!」を返す単純な Greeting アプリケーションを作成します。
アプリケーションをビルドおよび OpenShift にデプロイする場合、Eclipse Vert.x 4.1 は OpenJDK 8 および OpenJDK 11 をベースとしたビルダーイメージのみをサポートします。Oracle JDK および OpenJDK 9 のビルダーイメージはサポートされていません。
要件
- OpenJDK 8 または OpenJDK 11 がインストールされている。
- Maven がインストールされている。
手順
新しいディレクトリー
myApp
を作成し、そのディレクトリーに移動します。$ mkdir myApp $ cd myApp
これは、アプリケーションのルートディレクトリーです。
ルートディレクトリーにディレクトリー構造
src/main/java/com/example/
を作成し、これに移動します。$ mkdir -p src/main/java/com/example/ $ cd src/main/java/com/example/
アプリケーションコードを含む Java クラスファイル
MyApp.java
を作成します。package com.example; import io.vertx.core.AbstractVerticle; import io.vertx.core.Promise; public class MyApp extends AbstractVerticle { @Override public void start(Promise<Void> promise) { vertx .createHttpServer() .requestHandler(r -> r.response().end("Greetings!")) .listen(8080, result -> { if (result.succeeded()) { promise.complete(); } else { promise.fail(result.cause()); } }); } }
以下の内容を含むアプリケーションルートディレクトリー
myApp
にpom.xml
ファイルを作成します。<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>my-app</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>jar</packaging> <name>My Application</name> <description>Example application using Vert.x</description> <properties> <vertx.version>4.1.8.redhat-00003</vertx.version> <vertx-maven-plugin.version>1.0.24</vertx-maven-plugin.version> <vertx.verticle>com.example.MyApp</vertx.verticle> <!-- Specify the JDK builder image used to build your application. --> <jkube.generator.from>registry.access.redhat.com/ubi8/openjdk-11</jkube.generator.from> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> </properties> <!-- Import dependencies from the Vert.x BOM. --> <dependencyManagement> <dependencies> <dependency> <groupId>io.vertx</groupId> <artifactId>vertx-dependencies</artifactId> <version>${vertx.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <!-- Specify the Vert.x artifacts that your application depends on. --> <dependencies> <dependency> <groupId>io.vertx</groupId> <artifactId>vertx-core</artifactId> </dependency> <dependency> <groupId>io.vertx</groupId> <artifactId>vertx-web</artifactId> </dependency> </dependencies> <!-- Specify the repositories containing Vert.x artifacts. --> <repositories> <repository> <id>redhat-ga</id> <name>Red Hat GA Repository</name> <url>https://maven.repository.redhat.com/ga/</url> </repository> </repositories> <!-- Specify the repositories containing the plugins used to execute the build of your application. --> <pluginRepositories> <pluginRepository> <id>redhat-ga</id> <name>Red Hat GA Repository</name> <url>https://maven.repository.redhat.com/ga/</url> </pluginRepository> </pluginRepositories> <!-- Configure your application to be packaged using the Vert.x Maven Plugin. --> <build> <plugins> <plugin> <groupId>io.reactiverse</groupId> <artifactId>vertx-maven-plugin</artifactId> <version>${vertx-maven-plugin.version}</version> <executions> <execution> <id>vmp</id> <goals> <goal>initialize</goal> <goal>package</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project>
アプリケーションのルートディレクトリーから Maven を使用してアプリケーションをビルドします。
$ mvn vertx:run
アプリケーションが実行していることを確認します。
curl
またはブラウザーを使用して、アプリケーションがhttp://localhost:8080
で稼働していることを確認します。$ curl http://localhost:8080 Greetings!
関連情報
- 推奨されるプラクティスとして、liveness プローブおよび readiness プローブを設定し、OpenShift で実行する際にアプリケーションのヘルスモニタリングを有効にできます。
3.2. Eclipse Vert.x アプリケーションの OpenShift へのデプロイ
Eclipse Vert.x アプリケーションを OpenShift にデプロイするには、アプリケーションで pom.xml
ファイルを設定し、OpenShift Maven プラグインを使用します。
Fabric8 Maven プラグインはサポート対象外になりました。OpenShift Maven プラグインを使用して、OpenShift に Eclipse Vert.x アプリケーションをデプロイします。詳細は「 Fabric8 Maven Plugin から Eclipse JKube への移行 」を参照してください。
Pom. xml
ファイルの jkube.generator.from
URL を置き換えて、Java イメージを指定できます。イメージは Red Hat Ecosystem Catalog で利用できます。
<jkube.generator.from>IMAGE_NAME</jkube.generator.from>
たとえば、OpenJDK 8 を使用する RHEL 7 の Java イメージは、以下のように指定します。
<jkube.generator.from>registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift:latest</jkube.generator.from>
3.2.1. Eclipse Vert.x でサポートされる Java イメージ
Eclipse Vert.x は、さまざまなオペレーティングシステムで利用可能なさまざまな Java イメージで認定およびテストされています。たとえば、Java イメージは、OpenJDK 8 または OpenJDK 11 の RHEL 7 で利用できます。
Eclipse Vert.x は、RHEL 8 上の Red Hat OpenJDK 8 および Red Hat OpenJDK 11 用の OCI 準拠の ユニバーサルベースイメージ を使用して、Eclipse Vert.x アプリケーションをビルドして OpenShift にデプロイするためのサポートを導入します。
Red Hat Ecosystem Catalog で RHEL 8 イメージにアクセスするには、Docker または podman 認証が必要です。
以下の表は、異なるアーキテクチャーの Eclipse Vert.x によってサポートされるコンテナーイメージを示しています。これらのコンテナーイメージは、Red Hat Ecosystem Catalog で利用できます。カタログでは、以下の表に記載されているイメージを検索およびダウンロードできます。イメージページには、イメージへのアクセスに必要な認証手順が含まれます。
表3.1 OpenJDK イメージおよびアーキテクチャー
JDK(OS) | サポートされるアーキテクチャー | Red Hat Ecosystem Catalog で利用可能なイメージ |
---|---|---|
OpenJDK8 (RHEL 7) | x86_64 | redhat-openjdk-18/openjdk18-openshift |
OpenJDK11 (RHEL 7) | x86_64 | openjdk/openjdk-11-rhel7 |
OpenJDK8 (RHEL 8) | x86_64 | ubi8/openjdk-8-runtime |
OpenJDK11 (RHEL 8) | x86_64、IBM Z、および IBM Power Systems | ubi8/openjdk-11 |
RHEL 7 ホストでの RHEL 8 ベースのコンテナーの使用 (OpenShift 3 または OpenShift 4 など) は、サポートが限定されています。詳細は、「Red Hat Enterprise Linux Container Compatibility Matrix」を参照してください。
3.2.2. OpenShift デプロイメント用の Eclipse Vert.x アプリケーションの準備
Eclipse Vert.x アプリケーションを OpenShift にデプロイするには、以下を含める必要があります。
-
アプリケーションの
pom.xml
ファイルにあるランチャープロファイル情報。
以下の手順では、OpenShift Maven プラグインを使用するプロファイルは、アプリケーションの OpenShift へのビルドおよびデプロイに使用されます。
要件
- Maven がインストールされている。
- Red Hat Ecosystem Catalog での Docker または Podman 認証による RHEL 8 イメージへのアクセスができる。
手順
以下の内容を、アプリケーションルートディレクトリーの
pom.xml
ファイルに追加します。<!-- Specify the JDK builder image used to build your application. --> <properties> <jkube.generator.from>registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift:latest</jkube.generator.from> </properties> ... <profiles> <profile> <id>openshift</id> <build> <plugins> <plugin> <groupId>org.eclipse.jkube</groupId> <artifactId>openshift-maven-plugin</artifactId> <version>1.1.1</version> <executions> <execution> <goals> <goal>resource</goal> <goal>build</goal> <goal>apply</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles>
Pom
.xml ファイルの
プロパティーを置き換え、使用する OpenJDK イメージを指定します。jkube.generator.
fromx86_64 アーキテクチャー
OpenJDK 8 を使用した RHEL 7
<jkube.generator.from>registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift:latest</jkube.generator.from>
OpenJDK 11 を使用した RHEL 7
<jkube.generator.from>registry.access.redhat.com/openjdk/openjdk-11-rhel7:latest</jkube.generator.from>
OpenJDK 8 を使用した RHEL 8
<jkube.generator.from>registry.access.redhat.com/ubi8/openjdk-8:latest</jkube.generator.from>
x86_64、s390x(IBM Z)、および ppc64le(IBM Power Systems)アーキテクチャー
OpenJDK 11 を使用した RHEL 8
<jkube.generator.from>registry.access.redhat.com/ubi8/openjdk-11:latest</jkube.generator.from>
3.2.3. OpenShift Maven プラグインを使用した Eclipse Vert.x アプリケーションの OpenShift へのデプロイ
Eclipse Vert.x アプリケーションを OpenShift にデプロイするには、以下を実行する必要があります。
- OpenShift インスタンスにログインします。
- アプリケーションを OpenShift インスタンスにデプロイします。
要件
-
CLI クライアント
oc
がインストールされている。 - Maven がインストールされている。
手順
oc
クライアントを使用して OpenShift インスタンスにログインします。$ oc login ...
OpenShift インスタンスで新規プロジェクトを作成します。
$ oc new-project MY_PROJECT_NAME
アプリケーションのルートディレクトリーから Maven を使用してアプリケーションを OpenShift にデプロイします。アプリケーションのルートディレクトリーには
pom.xml
ファイルが含まれます。$ mvn clean oc:deploy -Popenshift
このコマンドは、OpenShift Maven プラグインを使用して OpenShift で S2I プロセス を起動し、Pod を起動します。
デプロイメントを確認します。
アプリケーションのステータスを確認し、Pod が実行していることを確認します。
$ oc get pods -w NAME READY STATUS RESTARTS AGE MY_APP_NAME-1-aaaaa 1/1 Running 0 58s MY_APP_NAME-s2i-1-build 0/1 Completed 0 2m
MY_APP_NAME-1-aaaaa
Pod は、完全にデプロイされて起動すると、ステータスがRunning
である必要があります。特定の Pod 名が異なります。
Pod のルートを判別します。
ルート情報の例
$ oc get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION MY_APP_NAME MY_APP_NAME-MY_PROJECT_NAME.OPENSHIFT_HOSTNAME MY_APP_NAME 8080
Pod のルート情報は、アクセスに使用するベース URL を提供します。
この例では、
http://MY_APP_NAME-MY_PROJECT_NAME.OPENSHIFT_HOSTNAME
がアプリケーションにアクセスするためのベース URL です。アプリケーションが OpenShift で実行していることを確認します。
$ curl http://MY_APP_NAME-MY_PROJECT_NAME.OPENSHIFT_HOSTNAME Greetings!
3.3. スタンドアロンの Red Hat Enterprise Linux への Eclipse Vert.x アプリケーションのデプロイ
Eclipse Vert.x アプリケーションをスタンドアロンの Red Hat Enterprise Linux にデプロイするには、アプリケーションで pom.xml
ファイルを設定し、Maven を使用してパッケージ化し、java -jar
コマンドを使用してデプロイします。
要件
- RHEL 7 または RHEL 8 がインストールされている。
3.3.1. スタンドアロン Red Hat Enterprise Linux デプロイメント用の Eclipse Vert.x アプリケーションの準備
Eclipse Vert.x アプリケーションをスタンドアロンの Red Hat Enterprise Linux にデプロイするには、最初に Maven を使用してアプリケーションをパッケージ化する必要があります。
要件
- Maven がインストールされている。
手順
以下の内容をアプリケーションの root ディレクトリーの
pom.xml
ファイルに追加します。... <build> <plugins> <plugin> <groupId>io.reactiverse</groupId> <artifactId>vertx-maven-plugin</artifactId> <version>1.0.24</version> <executions> <execution> <id>vmp</id> <goals> <goal>initialize</goal> <goal>package</goal> </goals> </execution> </executions> </plugin> </plugins> </build> ...
Maven を使用してアプリケーションをパッケージ化します。
$ mvn clean package
作成される JAR ファイルは
target
ディレクトリーに置かれます。
3.3.2. Jar を使用したスタンドアロンの Red Hat Enterprise Linux への Eclipse Vert.x アプリケーションのデプロイ
Eclipse Vert.x アプリケーションをスタンドアロンの Red Hat Enterprise Linux にデプロイするには、java -jar
コマンドを使用します。
要件
- RHEL 7 または RHEL 8 がインストールされている。
- OpenJDK 8 または OpenJDK 11 がインストールされている。
- アプリケーションが含まれる JAR ファイル。
手順
アプリケーションで JAR ファイルをデプロイします。
$ java -jar my-app-fat.jar
デプロイメントを確認します。
curl
またはブラウザーを使用して、アプリケーションがhttp://localhost:8080
で稼働していることを確認します。$ curl http://localhost:8080
第4章 Eclipse Vert.x ベースのアプリケーションのデバッグ
本セクションでは、ローカルデプロイメントとリモートデプロイメントの両方で、Eclipse Vert.x ベースのアプリケーションのデバッグを説明します。
4.1. リモートのデバッグ
アプリケーションをリモートでデバッグするには、まずデバッグモードで開始するように設定してから、デバッガーを割り当てる必要があります。
4.1.1. デバッグモードでのアプリケーションのローカルでの開始
Maven ベースのプロジェクトのデバッグ方法の 1 つは、デバッグポートを指定している間にアプリケーションを手動で起動し、その後にリモートデバッガーをそのポートに接続することです。この方法は、少なくとも以下のアプリケーションのデプロイメントに適用できます。
-
Mvn
vertx:debug ゴールを使用して
アプリケーションを手動で起動する場合。これにより、デバッグが有効な状態でアプリケーションが起動します。
要件
- Maven ベースのアプリケーション
手順
- コンソールで、アプリケーションでディレクトリーに移動します。
アプリケーションを起動し、-
Ddebug.port
引数を使用してデバッグポートを指定します。$ mvn vertx:debug -Ddebug.port=$PORT_NUMBER
ここで
、$PORT_NUMBER
は未使用のポート番号です。リモートデバッガー設定のこの番号を覚えておいてください。-Ddebug.suspend=true
引数を使用して、デバッガーが起動するまでアプリケーションを待機します。
4.1.2. デバッグモードでの OpenShift でのアプリケーションの起動
OpenShift で Eclipse Vert.x ベースのアプリケーションをリモートでデバッグするには、コンテナー内で JAVA_DEBUG
環境変数を true
に設定し、リモートデバッガーからアプリケーションに接続できるようにポート転送を設定する必要があります。
前提条件
- アプリケーションが OpenShift で実行している。
-
oc
バイナリーがインストールされている。 -
ターゲット OpenShift 環境で
oc port-forward
コマンドを実行する機能。
手順
oc
コマンドを使用して、利用可能なデプロイメント設定を一覧表示します。$ oc get dc
アプリケーションのデプロイメント設定の
JAVA_DEBUG
環境変数をtrue
に設定します。これにより、JVM がデバッグ用にポート番号5005
を開くように設定されます。例:$ oc set env dc/MY_APP_NAME JAVA_DEBUG=true
設定変更時に自動的に再デプロイするように設定されていない場合は、アプリケーションを再デプロイします。例:
$ oc rollout latest dc/MY_APP_NAME
ローカルマシンからアプリケーション Pod へのポート転送を設定します。
現在実行中の Pod を一覧表示し、アプリケーションが含まれる Pod を検索します。
$ oc get pod NAME READY STATUS RESTARTS AGE MY_APP_NAME-3-1xrsp 0/1 Running 0 6s ...
ポート転送を設定します。
$ oc port-forward MY_APP_NAME-3-1xrsp $LOCAL_PORT_NUMBER:5005
ここで、
$LOCAL_PORT_NUMBER
はローカルマシンで選択した未使用のポート番号になります。リモートデバッガー設定のこの番号を覚えておいてください。
デバッグが完了したら、アプリケーション Pod の
JAVA_DEBUG
環境変数の設定を解除します。例:$ oc set env dc/MY_APP_NAME JAVA_DEBUG-
関連情報
デバッグポートをデフォルト 5005
から変更する場合は、JAVA_DEBUG_PORT
環境変数を設定することもできます。
4.1.3. アプリケーションへのリモートデバッガーの割り当て
デバッグ用にアプリケーションが設定されている場合は、選択したリモートデバッガーを割り当てます。本ガイドでは、Red Hat CodeReady Studio について説明していますが、他のプログラムを使用する場合も手順は同じようになります。
前提条件
- ローカルまたは OpenShift 上で実行し、デバッグ用に設定されたアプリケーション。
- アプリケーションがデバッグをリッスンしているポート番号。
- Red Hat CodeReady Studio がマシンにインストールされている。Red Hat CodeReady Studio ダウンロードページ からダウンロードできます。
手順
- Red Hat CodeReady Studio を起動します。
アプリケーションの新規デバッグ設定を作成します。
- Run→Debug Configurations をクリックします。
- 設定のリストで、Remote Java アプリケーション をダブルクリックします。これにより、新しいリモートデバッグ設定が作成されます。
- Name フィールドに、設定に適した名前を入力します。
- アプリケーションが含まれるディレクトリーへのパスを Project フィールドに入力します。便宜上、Browse… ボタンを使用できます。
- Connection Type フィールドを Standard (Socket Attach) に設定していない場合は、これを設定します。
- Port フィールドを、アプリケーションがデバッグをリッスンしているポート番号に設定します。
- Apply をクリックします。
Debug Configurations ウィンドウの Debug ボタンをクリックしてデバッグを開始します。
初めてデバッグ設定を迅速に起動するには、Run→Debug History をクリックし、一覧から設定を選択します。
関連情報
Red Hat ナレッジベースの「Debug an OpenShift Java Application with JBoss Developer Studio」
Red Hat CodeReady Studio はこれまで JBoss Developer Studio と呼ばれていました。
- OpenShift ブログの記事 「Debugging Java Applications On OpenShift and Kubernetes」
4.2. デバッグロギング
Eclipse Vert.x は組み込みロギング API を提供します。Eclipse Vert.x のデフォルトのロギング実装は、Java JDK で提供される java.util.logging
ライブラリーを使用します。Eclipse Vert.x を使用すると、Log4J(Eclipse Vert.x は Log4J v1 および v2)や SLF4J などの異なるロギングフレームワークを使用できます。
4.2.1. Java. util.logging を使用した Eclipse Vert.
x アプリケーションのロギング設定
Java. util.logging を使用して Eclipse Vert.x アプリケーションのデバッグロギングを設定するには、以下を実行します。
-
Application
システムプロパティーを設定します。この変数の値は、java.properties ファイルに java.util.logging.config.
file.util.logging
設定ファイルの名前 に対応する必要があります。これにより、アプリケーションの起動時にLogManager
がjava.util.logging
を初期化するようになります。 -
または、vertx
-default-jul-
設定ファイルを Maven プロジェクトのクラスパスに追加します。Eclipse Vert.x はこのファイルを使用して、アプリケーションの起動時にlogging.properties 名を持つ java.util
.loggingjava.util.logging
を設定します。
Eclipse Vert.x では、Log4J ライブラリー、Log4J2 ライブラリー、および
を使用してカスタムロギングバックエンドを指定できます。デフォルトで Java に含まれる SLF
ライブラリーに事前実装を提供する 4J
Log
DelegateFactoryjava.util.logging
とは異なり、他のバックエンドでは各ライブラリーをアプリケーションの依存関係として指定する必要があります。
4.2.2. Eclipse Vert.x アプリケーションにログ出力を追加します。
ロギングをアプリケーションに追加するには、io
.vertx.core.logging.Logger
を作成します。Logger logger = LoggerFactory.getLogger(className); logger.info("something happened"); logger.error("oops!", exception); logger.debug("debug message"); logger.warn("warning");
注意ロギングバックエンドは異なる形式を使用して、パラメーター化されたメッセージで置き換え可能なトークンを表します。パラメーター化されたロギングメソッドに依存すると、コードを変更せずにロギングバックエンドを切り替えることができません。
4.2.3. アプリケーションのカスタムロギングフレームワークの指定
Eclipse Vert.x が java.util.logging を使用しない場合は、io.
vertx.core.logging.Logger
を設定して、別のロギングフレームワークを使用するように設定します(例: Log4J
または SLF4J
)。
Vertx
.logger-delegate-factory-class-name
システムプロパティーの値をLogDelegateFactory
インターフェースを実装するクラスの名前に設定します。Eclipse Vert.x は、以下のライブラリーに事前ビルドされた実装を提供し、以下のように対応する事前定義されたクラス名を提供します。ライブラリー クラス名 Log4J
v1io.vertx.core.logging.Log4jLogDelegateFactory
Log4J
v2io.vertx.core.logging.Log4j2LogDelegateFactory
SLF4J
io.vertx.core.logging.SLF4JLogDelegateFactory
カスタムライブラリーを使用してロギングを実装する場合は、関連する
Log4J
jar またはSLF4J
jar がアプリケーションの依存関係に含まれていることを確認してください。注意Eclipse Vert.x で提供される Log4J v1 委譲は、パラメーター化されたメッセージをサポートしません。Log4J v2 および SLF4J の委譲 はどちらも
{}
構文を使用します。Java.util.logging
委譲は、{n}
構文を使用するjava.text.MessageFormat
に依存します。
4.2.4. Eclipse Vert.x アプリケーション用の Netty ロギングの設定
Netty は、アプリケーションで非同期ネットワーク通信を管理するために VertX によって使用されるライブラリーです。
Netty:
- プロトコルサーバーやクライアントなどのネットワークアプリケーションを迅速かつ簡単に開発できます。
- TCP や UDP ソケットサーバー開発などのネットワークプログラミングを簡素化し、効率化します。
- ブロックおよび非ブロッキング接続を管理するための統合 API を提供します。
Netty は、システムプロパティーを使用して外部ロギング設定に依存しません。代わりに、プロジェクトの Netty クラスに表示されるロギングライブラリーに基づいてロギング設定を実装します。Netty は、以下の順序でライブラリーの使用を試みます。
-
SLF4J
-
Log4J
-
フォールバックオプションとしての
java.util.logging
アプリケーションのメイン
メソッドの先頭に以下のコードを追加すると、io .netty.util.internal.logging.InternalLoggerFactory
を直接特定のロガーに直接設定できます。
// Force logging to Log4j InternalLoggerFactory.setDefaultFactory(Log4JLoggerFactory.INSTANCE);
4.2.5. OpenShift でのデバッグログへのアクセス
アプリケーションを起動し、これと対話して OpenShift のデバッグステートメントを確認します。
前提条件
-
CLI クライアント
oc
がインストールされ、認証されている。 - デバッグロギングが有効になっている Maven ベースのアプリケーション。
手順
アプリケーションを OpenShift にデプロイします。
$ mvn clean oc:deploy -Popenshift
ログを表示します。
アプリケーションと共に Pod の名前を取得します。
$ oc get pods
ログ出力の監視を開始します。
$ oc logs -f pod/MY_APP_NAME-2-aaaaa
ログ出力を確認できるように、ターミナルウィンドウにログ出力が表示されます。
アプリケーションと対話します。
たとえば、以下のコマンドは、
/api/greeting
メソッドでmessage
変数をログに記録するようにデバッグロギングが設定された REST API レベル 0 アプリケーションのサンプルに基づいています。アプリケーションのルートを取得します。
$ oc get routes
アプリケーションの
/api/greeting
エンドポイントで HTTP 要求を作成します。$ curl $APPLICATION_ROUTE/api/greeting?name=Sarah
Pod ログのあるウィンドウに戻り、ログでデバッグロギングメッセージを検査します。
... Feb 11, 2017 10:23:42 AM io.openshift.MY_APP_NAME INFO: Greeting: Hello, Sarah ...
-
デバッグロギングを無効にするには、ロギング設定ファイル(例:
src/main/resources/vertx-default-jul-logging.properties
)を更新し、クラスのロギング設定を削除し、アプリケーションを再デプロイします。
第5章 アプリケーションのモニタリング
このセクションでは、OpenShift で実行する Eclipse Vert.x ベースのアプリケーションのモニタリングについて説明します。
5.1. OpenShift でのアプリケーションの JVM メトリクスへのアクセス
5.1.1. OpenShift で Jolokia を使用した JVM メトリクスへのアクセス
Jolokia は、OpenShift 上の HTTP (Java Management Extension) メトリクスにアクセスするための組み込みの軽量ソリューションです。Jolokia を使用すると、HTTP ブリッジ上で JMX によって収集される CPU、ストレージ、およびメモリー使用量データにアクセスできます。Jolokia は、REST インターフェースおよび JSON 形式のメッセージペイロードを使用します。これは、非常に高速でリソース要件が低いため、クラウドアプリケーションのモニタリングに適しています。
Java ベースのアプリケーションの場合、OpenShift Web コンソールは、アプリケーションを実行している JVM によって関連するすべてのメトリクス出力を収集し、表示する統合 hawt.io コンソール を提供します。
前提条件
-
認証された
oc
クライアント。 - OpenShift のプロジェクトで実行している Java ベースのアプリケーションコンテナー
- 最新の JDK 1.8.0 イメージ
手順
プロジェクト内の Pod のデプロイメント構成をリストし、アプリケーションに対応するものを選択します。
oc get dc
NAME REVISION DESIRED CURRENT TRIGGERED BY MY_APP_NAME 2 1 1 config,image(my-app:6) ...
アプリケーションを実行している Pod の YAML デプロイメントテンプレートを開いて編集します。
oc edit dc/MY_APP_NAME
以下のエントリーをテンプレートの
ports
セクションに追加し、変更を保存します。... spec: ... ports: - containerPort: 8778 name: jolokia protocol: TCP ... ...
アプリケーションを実行する Pod を再デプロイします。
oc rollout latest dc/MY_APP_NAME
Pod は更新されたデプロイメント設定で再デプロイされ、ポート
8778
を公開します。- OpenShift Web コンソールにログインします。
- サイドバーで、Applications > Pods に移動し、アプリケーションを実行する Pod の名前をクリックします。
- Pod の詳細画面で Open Java Console をクリックし、hawt.io コンソールにアクセスします。
関連情報
5.2. Eclipse Vert.x での Prometheus を使用したアプリケーションメトリクスの公開
Prometheus は監視されたアプリケーションに接続してデータを収集します。アプリケーションはメトリクスをサーバーに送信しません。
要件
- Prometheus サーバーがクラスターで実行している。
手順
アプリケーションの
pom.xml
ファイルにvertx-micrometer 依存関係
依存関係を含めます。および
vertx-webpom.xml
<dependency> <groupId>io.vertx</groupId> <artifactId>vertx-micrometer-metrics</artifactId> </dependency> <dependency> <groupId>io.vertx</groupId> <artifactId>vertx-web</artifactId> </dependency>
バージョン 3.5.4 以降、Prometheus のメトリクスを公開するには、カスタム
Launcher
クラスで Eclipse Vert.x オプションを設定する必要があります。カスタム
Launcher
クラスのbeforeStartingVertx メソッドおよび
メソッドを上書きして、メトリクスエンジンを設定します。以下に例を示します。afterStarting
VertxCustomLauncher.java ファイルの例
package org.acme; import io.micrometer.core.instrument.Meter; import io.micrometer.core.instrument.config.MeterFilter; import io.micrometer.core.instrument.distribution.DistributionStatisticConfig; import io.micrometer.prometheus.PrometheusMeterRegistry; import io.vertx.core.Vertx; import io.vertx.core.VertxOptions; import io.vertx.core.http.HttpServerOptions; import io.vertx.micrometer.MicrometerMetricsOptions; import io.vertx.micrometer.VertxPrometheusOptions; import io.vertx.micrometer.backends.BackendRegistries; public class CustomLauncher extends Launcher { @Override public void beforeStartingVertx(VertxOptions options) { options.setMetricsOptions(new MicrometerMetricsOptions() .setPrometheusOptions(new VertxPrometheusOptions().setEnabled(true) .setStartEmbeddedServer(true) .setEmbeddedServerOptions(new HttpServerOptions().setPort(8081)) .setEmbeddedServerEndpoint("/metrics")) .setEnabled(true)); } @Override public void afterStartingVertx(Vertx vertx) { PrometheusMeterRegistry registry = (PrometheusMeterRegistry) BackendRegistries.getDefaultNow(); registry.config().meterFilter( new MeterFilter() { @Override public DistributionStatisticConfig configure(Meter.Id id, DistributionStatisticConfig config) { return DistributionStatisticConfig.builder() .percentilesHistogram(true) .build() .merge(config); } }); }
カスタムの
Verticle クラスを作成し
、メトリクスを収集するためにstart
メソッドを上書きします。たとえば、Timer
クラスを使用して実行時間を測定します。Example CustomVertxApp.java file
package org.acme; import io.micrometer.core.instrument.MeterRegistry; import io.micrometer.core.instrument.Timer; import io.vertx.core.AbstractVerticle; import io.vertx.core.Vertx; import io.vertx.core.VertxOptions; import io.vertx.core.http.HttpServerOptions; import io.vertx.micrometer.backends.BackendRegistries; public class CustomVertxApp extends AbstractVerticle { @Override public void start() { MeterRegistry registry = BackendRegistries.getDefaultNow(); Timer timer = Timer .builder("my.timer") .description("a description of what this timer does") .register(registry); vertx.setPeriodic(1000, l -> { timer.record(() -> { // Do something }); }); } }
アプリケーションの
pom
プロパティーを設定して、カスタムクラスを参照します。.xml ファイルの
launcher><vertx
.verticle> プロパティーおよび <vertx.<properties> ... <vertx.verticle>org.acme.CustomVertxApp</vertx.verticle> <vertx.launcher>org.acme.CustomLauncher</vertx.launcher> ... </properties>
アプリケーションを起動します。
$ mvn vertx:run
トレースされたエンドポイントを複数回呼び出します。
$ curl http://localhost:8080/ Hello
コレクションが発生するまで 15 秒以上待機し、Prometheus UI でメトリクスを確認します。
-
http://localhost:9090/ で Prometheus UI を開き、Expression ボックスに
hello
と入力します。 -
提案から、たとえば
application:hello_count
を選択し、Execute をクリックします。 - 表示される表で、リソースメソッドが呼び出された回数を確認できます。
-
Application:hello_time_mean_seconds
を選択して、すべての呼び出しの平均時間を確認します。
作成したすべてのメトリクスの前に
application: があることに注意してください
。Eclipse MicroProfile Metrics 仕様に必要なため、Eclipse Vert.x によって自動的に公開される他のメトリクスがあります。これらのメトリクスにはbase:
およびvendor:
というプレフィックスが付けられ、アプリケーションが実行される JVM に関する情報を公開します。-
http://localhost:9090/ で Prometheus UI を開き、Expression ボックスに
関連情報
- Eclipse Vert.x で Micrometer メトリクスを使用する方法は、「Eclipse Vert.x} Micrometer Metrics 」を参照してください。
付録A Source-to-Image (S2I) ビルドプロセス
Source-to-Image (S2I) は、アプリケーションソースのあるオンライン SCM リポジトリーから再現可能な Docker 形式のコンテナーイメージを生成するビルドツールです。S2I ビルドを使用すると、ビルド時間を短縮し、リソースおよびネットワークの使用量を減らし、セキュリティーを改善し、その他の多くの利点を使用して、アプリケーションの最新バージョンを実稼働に簡単に配信できます。OpenShift は、複数の ビルドストラテジーおよび入力ソース をサポートします。
詳細は、OpenShift Container Platform ドキュメントの「Source-to-Image (S2I) ビルド」の章を参照してください。
最終的なコンテナーイメージをアセンブルするには、S2I プロセスに 3 つの要素を指定する必要があります。
- GitHub などのオンライン SCM リポジトリーでホストされるアプリケーションソース。
- S2I Builder イメージ。アセンブルされたイメージの基盤となり、アプリケーションを実行しているエコシステムを提供します。
- 必要に応じて、S2I スクリプト によって使用される環境変数およびパラメーターを指定することもできます。
このプロセスは、S2I スクリプトで指定された指示に従ってアプリケーションソースおよび依存関係を Builder イメージに挿入し、アセンブルされたアプリケーションを実行する Docker 形式のコンテナーイメージを生成します。詳細は、OpenShift Container Platform ドキュメントの 「S2I build requirements」、「build options」および 「how builds work」を参照してください。
付録B サンプルアプリケーションのデプロイメント設定の更新
サンプルアプリケーションのデプロイメント設定には、ルート情報や readiness プローブの場所などの OpenShift でのアプリケーションのデプロイおよび実行に関連する情報が含まれます。サンプルアプリケーションのデプロイメント設定は YAML ファイルのセットに保存されます。たとえば、OpenShift Maven プラグインを使用する例では、YAML ファイルは src/main/jkube/
ディレクトリーにあります。Nodeshift を使用する例として、YAML ファイルは .nodeshift
ディレクトリーにあります。
OpenShift Maven プラグインおよび Nodeshift が使用するデプロイメント設定ファイルは完全な OpenShift リソース定義である必要はありません。OpenShift Maven プラグインと Nodeshift はどちらもデプロイメント設定ファイルを取り、不足している情報を追加して完全な OpenShift リソース定義を作成できます。OpenShift Maven プラグインによって生成されたリソース定義は target/classes/META-INF/jkube/
ディレクトリーにあります。Nodeshift によって生成されるリソース定義は tmp/nodeshift/resource/
ディレクトリーにあります。
前提条件
- 既存のサンプルプロジェクト。
-
CLI クライアント
oc
がインストールされている。
手順
既存の YAML ファイルを編集するか、または設定を更新して追加の YAML ファイルを作成します。
たとえば、サンプルに
readinessProbe
が設定された YAML ファイルがすでにある場合は、path
の値を別の利用可能なパスに変更し、readiness の有無を確認することができます。spec: template: spec: containers: readinessProbe: httpGet: path: /path/to/probe port: 8080 scheme: HTTP ...
-
readinessProbe
が既存の YAML ファイルで設定されていない場合は、readinessProbe
設定を使用して新規 YAML ファイルを同じディレクトリーに作成することもできます。
- Maven または npm を使用して、サンプルの更新バージョンをデプロイします。
設定更新が、デプロイ済みのサンプルに表示されることを確認します。
$ oc export all --as-template='my-template' apiVersion: template.openshift.io/v1 kind: Template metadata: creationTimestamp: null name: my-template objects: - apiVersion: template.openshift.io/v1 kind: DeploymentConfig ... spec: ... template: ... spec: containers: ... livenessProbe: failureThreshold: 3 httpGet: path: /path/to/different/probe port: 8080 scheme: HTTP initialDelaySeconds: 60 periodSeconds: 30 successThreshold: 1 timeoutSeconds: 1 ...
関連情報
Web ベースのコンソールまたは CLI クライアント oc
を使用してアプリケーションの設定を直接更新している場合は、これらの変更を YAML ファイルへエクスポートして追加します。oc export all
コマンドを使用して、デプロイされたアプリケーションの設定を表示します。
付録C OpenShift Maven プラグインでアプリケーションをデプロイする Jenkins フリースタイルプロジェクトの設定
ローカルホストの Maven および OpenShift Maven プラグインを使用してアプリケーションをデプロイするのと同様に、Jenkins を設定して Maven および OpenShift Maven プラグインを使用してアプリケーションをデプロイすることができます。
前提条件
- OpenShift クラスターへのアクセス
- 同じ OpenShift クラスターで実行している Jenkins コンテナーイメージ。
- Jenkins サーバーに JDK および Maven がインストールされ、設定されている。
Maven(
pom.xml
の OpenShift Maven プラグイン)を使用し、RHEL ベースイメージを使用してビルドするように設定されたアプリケーション。注記アプリケーションをビルドおよび OpenShift にデプロイする場合、Eclipse Vert.x 4.1 は OpenJDK 8 および OpenJDK 11 をベースとしたビルダーイメージのみをサポートします。Oracle JDK および OpenJDK 9 のビルダーイメージはサポートされていません。
pom.xml
の例<properties> ... <jkube.generator.from>registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift:latest</jkube.generator.from> </properties>
- GitHub で利用可能なアプリケーションのソース。
手順
アプリケーションの新規 OpenShift プロジェクトを作成します。
- OpenShift Web コンソールを開き、ログインします。
- Create Project をクリックして、新しい OpenShift プロジェクトを作成します。
- プロジェクト情報を入力し、Create をクリックします。
Jenkins がそのプロジェクトにアクセスできるようにします。
たとえば、Jenkins のサービスアカウントを設定している場合は、アカウントに、アプリケーションのプロジェクトへの
edit
アクセスがあることを確認してください。Jenkins サーバーで新しい フリースタイルの Jenkins プロジェクト を作成します。
- New Item をクリックします。
- 名前を入力し、Freestyle プロジェクト を選択して OK をクリックします。
- Source Code Management で Git を選択し、アプリケーションの GitHub URL を追加します。
-
Build で Add build step を選択し、
Invoke top-level Maven targets
を選択します。 以下を Goals に追加します。
clean oc:deploy -Popenshift -Djkube.namespace=MY_PROJECT
MY_PROJECT
をアプリケーションの OpenShift プロジェクトの名前に置き換えます。- Save をクリックします。
Jenkins プロジェクトのメインページから Build Now をクリックし、アプリケーションの OpenShift プロジェクトにアプリケーションのビルドおよびデプロイを確認します。
アプリケーションの OpenShift プロジェクトでルートを開いて、アプリケーションがデプロイされていることを確認することもできます。
次のステップ
-
GITSCM ポーリング を追加すること、または the
Poll SCM
ビルドトリガー を使用することを検討してください。これらのオプションにより、新規コミットが GitHub リポジトリーにプッシュされるたびにビルドを実行できます。 - デプロイ前にテストを実行するビルドステップを追加することを検討してください。
付録D 追加の Eclipse Vert.x リソース
- リアクティブマニフェスト
- Eclipse Vert.x プロジェクト
- 動作中の Vert.x
- Eclipse Vert.x for Reactive Programming
- Building Reactive Microservices in Java
- Eclipse Vert.x Cheat Sheet for Developers
- Vert.x - From zero to(micro)-hero
- Red Hat Summit 2017 Talk - Reactive Programming with Eclipse Vert.x
- Red Hat Summit 2017 Breakout Session - Reactive Systems with Eclipse Vert.x and Red Hat OpenShift
- Eclipse Vert.x および OpenShift でのライブコーディングリアクティブシステム
付録E アプリケーション開発リソース
OpenShift でのアプリケーション開発に関する詳細は、以下を参照してください。
ネットワークの負荷を減らし、アプリケーションのビルド時間を短縮するには、OpenShift Container Platform で Maven の Nexus ミラーを設定します。