この記事では、Red Hat JBoss Enterprise Application Platform (EAP) アプリケーションを Azure Red Hat OpenShift クラスターにデプロイする方法について説明します。 このサンプルは、SQL データベースを基盤とする Java アプリケーションです。 このアプリは、 JBoss EAP Helm チャート を使用してデプロイされます。
このガイドでは、次の方法について説明します。
- OpenShift 用に JBoss EAP アプリケーションを準備します。
- Azure SQL Database の単一データベース インスタンスを作成します。
- Azure Workload Identity はまだ Azure OpenShift でサポートされていないため、この記事では、パスワードなしのデータベース接続を使用する代わりに、データベース認証にユーザー名とパスワードを引き続き使用します。
- JBoss Helm Charts と OpenShift Web コンソールを使用して Azure Red Hat OpenShift クラスターにアプリケーションをデプロイする
サンプル アプリケーションは、HTTP セッションに情報を格納するステートフル アプリケーションです。 これは、JBoss EAP クラスタリング機能を利用し、Jakarta EE と MicroProfile の以下のテクノロジを使用します。
- Jakarta サーバーの顔
- ジャカルタ・エンタープライズ・ビーンズ
- ジャカルタ パーシステンス
- MicroProfile の正常性
この記事は、Azure Red Hat OpenShift クラスターで JBoss EAP アプリを実行するためのステップバイステップの手動ガイダンスです。 Azure Red Hat OpenShift クラスターへの取り組みを加速させるより自動化されたソリューションについては、「 Quickstart: Azure portal を使用して Azure Red Hat OpenShift に JBoss EAP をデプロイする」を参照してください。
JBoss EAP on Azure ソリューションを開発しているエンジニアリング チームとフィードバックを提供したり、移行シナリオに密接に取り組んだりすることに関心がある場合は、JBoss EAP 移行に関するこの短い survey に記入し 連絡先情報を含めてください。 プログラム マネージャー、アーキテクト、エンジニアのチームからすぐに連絡があり、緊密なコラボレーションが開始されます。
重要
この記事では、JBoss EAP Helm Chart を使用してアプリケーションをデプロイします。 執筆時点では、この機能は引き続きテクノロジ プレビューとして提供されています。 JBoss EAP Helm Chart を使用してアプリケーションを運用環境にデプロイすることを選択する前に、お使いの JBoss EAP/XP 製品バージョンでこの機能がサポートされていることを確認してください。
重要
Red Hat と Microsoft Azure は、統合されたサポート エクスペリエンスを提供するために Azure Red Hat OpenShift を共同で設計、運用、サポートしていますが、この記事で説明する Azure Red Hat OpenShift 上で実行するソフトウェアには、独自のサポートとライセンス条項が適用されます。 Azure Red Hat OpenShift のサポートの詳細については、「Azure Red Hat OpenShift 4 のサポート ライフサイクル」を参照してください。 この記事で説明されているソフトウェアのサポートの詳細については、この記事に記載されているソフトウェアのメイン ページを参照してください。
前提条件
注
OpenShift クラスターを作成して実行するには、Azure Red Hat OpenShift に少なくとも 40 コアが必要です。 新しい Azure サブスクリプションの既定の Azure リソース クォータは、この要件を満たしていません。 リソースの制限の引き上げを依頼するには、「標準クォータ:VM シリーズでの制限の引き上げ」を参照してください。 無料試用版サブスクリプションはクォータの引き上げの対象になりません。クォータの引き上げを要求する前に、You-Go 従量課金制サブスクリプションにアップグレード
インストールされているさまざまな製品 (Ubuntu、macOS、または Windows Subsystem for Linux など) でサポートされている Unix のようなオペレーティング システムを搭載したローカル コンピューターを準備します。
Java Standard Edition (SE) 実装をインストールします。 この記事のローカル開発手順は、OpenJDK の Microsoft ビルドの Java Development Kit (JDK) 17 でテストされました。
Maven 3.8.6 以上をインストールします。
Azure CLI 2.40 以降をインストールします。
このデモ アプリケーション (todo-list) のコードを、お使いのローカル システムにクローンします。 デモ アプリケーションは GitHub にあります。
Azure Red Hat OpenShift 4 クラスターの作成に関するページの手順に従います。
"Red Hat プル シークレットの取得" 手順は省略可能としてラベル付けされていますが、この記事では必須です。 プル シークレットを使用すると、Azure Red Hat OpenShift クラスターで、JBoss EAP アプリケーション イメージを見つけることができます。
クラスターでメモリを集中的に使用するアプリケーションを実行する予定の場合は、
--worker-vm-size
パラメーターを使用して、ワーカー ノードにとって適切な仮想マシン サイズを指定します。 詳細については、以下を参照してください:Azure Red Hat OpenShift 4 クラスターへの接続に関するページの手順に従って、クラスターに接続します。
- 「OpenShift CLI をインストールする」の手順に従います
- ユーザー
kubeadmin
として、OpenShift CLI を使用して Azure Red Hat OpenShift クラスターに接続します
次のコマンドを実行して、このデモ アプリケーションのための OpenShift プロジェクトを作成します。
oc new-project eap-demo
次のコマンドを実行して、既定のサービス アカウントに view ロールを追加します。 このロールが必要なのは、アプリケーションで他のポッドを検出し、それらを備えたクラスターをセットアップできるようにするためです。
oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default -n $(oc project -q)
アプリケーションを準備する
次のコマンドを使用して、サンプル アプリケーションを複製します。
git clone https://github.com/Azure-Samples/jboss-on-aro-jakartaee
Todo-list デモ アプリケーションを複製し、ローカル リポジトリが メイン ブランチにあります。 デモ アプリケーションは、Azure SQL でレコードを作成、読み取り、更新、削除する単純な Java アプリです。 ローカル マシンにインストールされている JBoss EAP サーバーに、このアプリケーションをそのままでデプロイできます。 必要なのは、必要なデータベース ドライバーとデータ ソースを使用してサーバーを構成することだけです。 ローカル環境からアクセスできるデータベース サーバーも必要です。
ただし、OpenShift をターゲットにしている場合は、JBoss EAP サーバーの機能をトリミングすることをお勧めします。 たとえば、プロビジョニングされたサーバーのセキュリティの露出を減らし、全体的なフットプリントを減らすことができます。 また、OpenShift 環境での実行により適したアプリケーションとするため、いくつかの MicroProfile 仕様を含めることもできます。 JBoss EAP を使用する場合、このタスクを実行する 1 つの方法は、アプリケーションとサーバーを Bootable JAR と呼ばれる単一のデプロイメント ユニットにパッケージ化することです。 デモ アプリケーションに必要な変更を追加して、これを行いましょう。
デモ アプリケーションのローカル リポジトリに移動し、ブランチを bootable-jar
## cd jboss-on-aro-jakartaee
git checkout bootable-jar
このブランチで変更した内容を簡単に確認してみましょう。
-
wildfly-jar-maven
プラグインを追加して、サーバーとアプリケーションを 1 つの実行可能な JAR ファイルにプロビジョニングしました。 OpenShift のデプロイ単位は、アプリケーションがあるサーバーです。 - Maven プラグインに対して、一連の Galleon レイヤーを指定しました。 この構成により、サーバーの機能を削って必要な機能だけにすることができます。 Galleon に関する完全なドキュメントについては、WildFly のドキュメントを参照してください。
- このアプリケーションは Ajax リクエストで Jakarta Faces を使用しているため、HTTP セッションに情報が格納されます。 このような情報を、ポッドが削除された場合に失いたくはありません。 この情報をクライアントに保存すれば、要求ごとに送り返すことができます。 ただし、特定の情報をクライアントに配布しない場合があります。 このデモでは、すべてのポッド レプリカにわたってセッションをレプリケートすることを選択しました。 これを行うには、
<distributable />
に を追加しました。 これにより、サーバーのクラスタリング機能とともに、HTTP セッションがすべてのポッドに配布可能になります。 - 2 つの MicroProfile 正常性チェックを追加しました。これらのチェックにより、アプリケーションがいつライブになっていて要求の受信準備ができているかを識別できます。
ローカルでアプリケーションを実行する
アプリケーションを OpenShift にデプロイする前に、ローカルで実行して動作を確認します。 次の手順では、Azure SQL Server が実行されていて、ローカル環境から使用できることを前提としています。
データベースを作成するには、「クイック スタート: Azure SQL Database の単一データベースを作成する」の手順に従いますが、次の置換を使用します。
- [リソース グループ] には、前に作成したリソース グループを使用します。
-
[データベース名] には
todos_db
を使用します。 -
[サーバー管理者ログイン] には
azureuser
を使用します。 -
[パスワード] には
Passw0rd!
を使用します。 - [ファイアウォール規則] セクションで、[Azure サービスおよびリソースにこのサーバーへのアクセスを許可する] を [はい] に切り替えます。
その他の設定はすべて、リンクされた記事から安全に使用できます。
[追加設定] ページで、データベースにサンプル データを事前に設定するオプションを選択する必要はありませんが、そうしても害はありません。
データベースを作成したら、概要ページからサーバー名の値を取得します。
[サーバー名] フィールドの値の上にマウス ポインターを置き、値の横に表示されるコピー アイコンを選択します。 後で使用するために、この値を保存します。(この値に MSSQLSERVER_HOST
という名前の変数を設定します)。
注
金銭的コストを低く抑えるために、クイックスタートにより、サーバーレス コンピューティング レベルを選択するようにリーダーが指示されます。 アクティビティがない場合、このレベルは 0 にスケーリングされます。 この場合、データベースはすぐに応答しません。 この記事の手順を実行するときにデータベースの問題が発生した場合は、自動一時停止を無効にすることを検討してください。 方法については、「Azure SQL Database サーバーレス」で自動一時停止を検索します。 執筆時点で、次の Azure CLI コマンドは、この記事で構成されているデータベースの自動一時停止を無効にします。az sql db update --resource-group $RESOURCEGROUP --server <Server name, without the .database.windows.net part> --name todos_db --auto-pause-delay -1
以下の手順に従って、ローカルでアプリケーションをビルドして実行します。
起動可能な JAR をビルドします。 MS SQL Server データベースで
eap-datasources-galleon-pack
を使用しているため、この特定の環境変数で使用するデータベース ドライバーのバージョンを指定する必要があります。eap-datasources-galleon-pack
および MS SQL Server の詳細については、Red Hat の「」ドキュメントを参照してくださいexport MSSQLSERVER_DRIVER_VERSION=7.4.1.jre11 mvn clean package
以下のコマンドを使用して、起動可能な JAR を起動します。
Azure SQL データベースで、このサーバーが実行されているホストからのネットワーク トラフィックが許可されていることを確認する必要があります。 「クイック スタート: Azure SQL Database の単一データベースを作成する」の手順を実行するときに [現在のクライアント IP アドレスを追加する] を選択したため、サーバーが実行されているホストが、Azure portal へのブラウザーの接続元と同じホストである場合は、ネットワーク トラフィックを許可する必要があります。 サーバーが実行されているホストが他のホストである場合は、「Azure portal を使用してサーバー レベルの IP ファイアウォール規則を管理する」を参照する必要があります。
アプリケーションを起動するときは、データソースを構成するために必要な環境変数を渡す必要があります。
export MSSQLSERVER_USER=azureuser export MSSQLSERVER_PASSWORD='Passw0rd!' export MSSQLSERVER_JNDI=java:/comp/env/jdbc/mssqlds export MSSQLSERVER_DATABASE=todos_db export MSSQLSERVER_HOST=<server name saved aside earlier> export MSSQLSERVER_PORT=1433 mvn wildfly-jar:run
注
Microsoft では、使用可能な最も安全な認証フローを使用することをお勧めします。 この手順で説明する認証フロー (データベース、キャッシュ、メッセージング、AI サービスなど) には、アプリケーションに対する非常に高い信頼が必要であり、他のフローには存在しないリスクが伴います。 このフローは、パスワードレス接続やキーレス接続のマネージド ID など、より安全なオプションが有効でない場合にのみ使用します。 ローカル コンピューターの操作では、パスワードレス接続またはキーレス接続にユーザー ID を使用します。
このデモで使用される基になるランタイムの詳細については、データソースを統合するための Galleon Feature Pack のドキュメントに記載された、使用可能な環境変数の完全な一覧を参照してください。 Feature Pack の概念の詳細については、WildFly のドキュメントを参照してください。
次の例のようなテキストのエラーが表示された場合:
Cannot open server '<your prefix>mysqlserver' requested by the login. Client with IP address 'XXX.XXX.XXX.XXX' is not allowed to access the server.
このメッセージは、ネットワーク トラフィックが許可されていることを確認する手順が機能しなかったことを示します。 エラー メッセージの IP アドレスがファイアウォール規則に含まれていることを確認します。
次の例のようなテキストのメッセージが表示された場合:
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: There is already an object named 'TODOS' in the database.
このメッセージは、サンプル データが既にデータベースに存在することを示します。 このメッセージは無視してかまいません。
(省略可能) クラスタリング機能を検証する場合は、起動可能な JAR に
jboss.node.name
引数を渡して同じアプリケーションのインスタンスをより多く起動し、jboss.socket.binding.port-offset
を使用してポート番号を移動することでポート番号の競合を回避することもできます。 たとえば、OpenShift で新しいポッドを表す 2 番目のインスタンスを起動するには、新しいターミナル ウィンドウで次のコマンドを実行します。export MSSQLSERVER_USER=azureuser export MSSQLSERVER_PASSWORD='Passw0rd!' export MSSQLSERVER_JNDI=java:/comp/env/jdbc/mssqlds export MSSQLSERVER_DATABASE=todos_db export MSSQLSERVER_HOST=<server name saved aside earlier> export MSSQLSERVER_PORT=1433 mvn wildfly-jar:run -Dwildfly.bootable.arguments="-Djboss.node.name=node2 -Djboss.socket.binding.port-offset=1000"
注
Microsoft では、使用可能な最も安全な認証フローを使用することをお勧めします。 この手順で説明する認証フロー (データベース、キャッシュ、メッセージング、AI サービスなど) には、アプリケーションに対する非常に高い信頼が必要であり、他のフローには存在しないリスクが伴います。 このフローは、パスワードレス接続やキーレス接続のマネージド ID など、より安全なオプションが有効でない場合にのみ使用します。 ローカル コンピューターの操作では、パスワードレス接続またはキーレス接続にユーザー ID を使用します。
クラスターが動作している場合は、サーバー コンソール ログに次のようなトレースが表示されます。
INFO [org.infinispan.CLUSTER] (thread-6,ejb,node) ISPN000094: Received new cluster view for channel ejb
注
既定では、起動可能な JAR により、JGroups サブシステムは UDP プロトコルを使用して、他のクラスター メンバーを検出するメッセージを 230.0.0.4 マルチキャスト アドレスに送信するように構成されます。 ローカル マシンのクラスタリング機能を適切に検証するには、お使いのオペレーティング システムでマルチキャスト データグラムの送受信が可能で、それらをイーサネット インターフェイス経由で 230.0.0.4 IP にルーティングする必要があります。 サーバー ログにクラスター関連の警告が示される場合は、ネットワーク構成を調査し、そのアドレスのマルチキャストがサポートされていることを確認してください。
ブラウザーで http://localhost:8080/ を開き、アプリケーションのホームページにアクセスします。 さらにインスタンスを作成した場合は、ポート番号をシフトしてアクセスできます (例: http://localhost:9080/. アプリケーションは、次の画像のようになります。
アプリケーションの liveness probe と readiness probe を確認します。 OpenShift はこれらのエンドポイントを使用して、ポッドがいつライブになり、ユーザー リクエストを受信する準備ができているかを確認します。
liveness の状態を確認するには、次のコマンドを実行します。
curl http://localhost:9990/health/live
次のように出力されます。
{"status":"UP","checks":[{"name":"SuccessfulCheck","status":"UP"}]}
準備状況を確認するには、次のコマンドを実行します。
curl http://localhost:9990/health/ready
次のように出力されます。
{"status":"UP","checks":[{"name":"deployments-status","status":"UP","data":{"todo-list.war":"OK"}},{"name":"server-state","status":"UP","data":{"value":"running"}},{"name":"boot-errors","status":"UP"},{"name":"DBConnectionHealthCheck","status":"UP"}]}
Ctrl
C 押して、アプリケーションを停止します。
OpenShift にデプロイする
アプリケーションをデプロイするには、Azure Red Hat OpenShift で既に利用可能な JBoss EAP Helm Charts を使用します。 また、必要な構成を指定する必要があります。たとえば、データベース ユーザー、データベース パスワード、使用するドライバーのバージョン、データ ソースによって使用される接続情報などです。 次の手順では、OpenShift クラスターから実行中かつアクセス可能な Azure SQL データベース サーバーがあり、 という名前の mssqlserver-secret
にデータベース ユーザー名、パスワード、ホスト名、ポート、およびデータベース名が格納されていることを前提としています。
デモアプリケーションのローカルリポジトリに移動し、現在のブランチを bootable-jar-openshiftに変更します。
git checkout bootable-jar-openshift
このブランチで変更した内容を簡単に確認してみましょう。
- クラウドでサーバーを実行するための特定の構成で起動可能な JAR を準備する、
bootable-jar-openshift
という名前の新しい Maven プロファイルを追加しました。 これにより、たとえば、JGroups サブシステムでネットワーク要求を使用し、KUBE_PING プロトコルによって他のポッドを検出できます。 - jboss-on-aro-jakartaee/deployment ディレクトリに、構成ファイルのセットを追加しました。 このディレクトリには、アプリケーションをデプロイするための構成ファイルがあります。
OpenShift にアプリケーションをデプロイする
次の手順では、OpenShift Web コンソールを使用して Helm Chart でアプリケーションをデプロイする方法について説明します。 "シークレット" と呼ばれる機能を使用して、Helm チャートに機密値をハード コーディングしないようにします。 シークレットは単に名前と値のペアのコレクションであり、値は必要となる前に既知の場所で指定されます。 この場合、Helm チャートでは 2 つのシークレットが使用され、それぞれに次の名前と値のペアがあります。
mssqlserver-secret
-
db-host
はMSSQLSERVER_HOST
の値を示します。 -
db-name
はMSSQLSERVER_DATABASE
の値を示します。 -
db-password
はMSSQLSERVER_PASSWORD
の値を示します。 -
db-port
はMSSQLSERVER_PORT
の値を示します。 -
db-user
はMSSQLSERVER_USER
の値を示します。
-
todo-list-secret
-
app-cluster-password
は、クラスター ノードをより安全に形成できるように、ユーザーが指定した任意のパスワードを示します。 -
app-driver-version
はMSSQLSERVER_DRIVER_VERSION
の値を示します。 -
app-ds-jndi
はMSSQLSERVER_JNDI
の値を示します。
-
mssqlserver-secret
を作成します。oc create secret generic mssqlserver-secret \ --from-literal db-host=${MSSQLSERVER_HOST} \ --from-literal db-name=${MSSQLSERVER_DATABASE} \ --from-literal db-password=${MSSQLSERVER_PASSWORD} \ --from-literal db-port=${MSSQLSERVER_PORT} \ --from-literal db-user=${MSSQLSERVER_USER}
todo-list-secret
を作成します。export MSSQLSERVER_DRIVER_VERSION=7.4.1.jre11 oc create secret generic todo-list-secret \ --from-literal app-cluster-password=mut2UTG6gDwNDcVW \ --from-literal app-driver-version=${MSSQLSERVER_DRIVER_VERSION} \ --from-literal app-ds-jndi=${MSSQLSERVER_JNDI}
注
Microsoft では、使用可能な最も安全な認証フローを使用することをお勧めします。 この手順で説明する認証フロー (データベース、キャッシュ、メッセージング、AI サービスなど) には、アプリケーションに対する非常に高い信頼が必要であり、他のフローには存在しないリスクが伴います。 このフローは、パスワードレス接続やキーレス接続のマネージド ID など、より安全なオプションが有効でない場合にのみ使用します。 ローカル コンピューターの操作では、パスワードレス接続またはキーレス接続にユーザー ID を使用します。
OpenShift コンソールを開き、開発者ビューに移動します。 このコマンドを実行すると、OpenShift クラスターのコンソール URL を検出できます。 前の手順で取得した
kubeadmin
ユーザー ID とパスワードを使用してサインインします。az aro show \ --name $CLUSTER \ --resource-group $RESOURCEGROUP \ --query "consoleProfile.url" \ --output tsv
ナビゲーション ウィンドウの上部にあるドロップダウン メニューで、<[/> Developer] パースペクティブを選択します。
<[/> Developer] パースペクティブで、[プロジェクト] ドロップダウン メニューから [eap-demo] プロジェクトを選択します。
[+追加] を選択します。 [Developer Catalog] セクションで、[Helm Chart] を選択します。 Azure Red Hat OpenShift クラスターで利用可能な Helm チャート カタログにアクセスします。 [Filter by keyword] ボックスに、「eap」と入力します。 次に示すように、いくつかのオプションが表示されます。
このアプリケーションでは MicroProfile 機能を使用しているため、EAP XP の Helm チャートを選択します。 「Xp」は拡張パックの略です。 JBoss Enterprise Application Platform 拡張パックを使用すると、開発者は、Eclipse MicroProfile アプリケーション プログラミング インターフェイス (API) を使用して、マイクロサービス ベースのアプリケーションをビルドおよびデプロイできます。
JBoss EAP XP 4 Helm チャートを選択し、[Helm チャートのインストール] を選択します。
この時点で、アプリケーションをビルドしてデプロイするために Helm を構成する必要があります。
リリースの名前を eap-todo-list-demo に変更します。
Form View または YAML View のいずれかを使用して Helm Chart を構成できます。 [Configure via] というラベルのセクションで、[YAML View] を選択します。
Helm Chart を構成するために、既存の内容の代わりに deployment/application/todo-list-helm-chart.yaml で入手できる Helm Chart ファイルの内容をコピーして貼り付けることで、YAML の内容を変更します。
このコンテンツは、前に設定したシークレットを参照します。
最後に、[Install] を選択してアプリケーションのデプロイを開始します。 このアクションにより、Helm リリース (eap-todo-list-demo という名前) とそれに関連付けられているリソースのグラフィカル表現を含む [トポロジ] ビューが開きます。
Helm リリース (略記で HR) には eap-todo-list-demo という名前が付いています。 それには、デプロイ リリース (略記で D) が含まれていて、こちらの名前も eap-todo-list-demo です。
[D] ボックスの左下にある円円で囲まれた 2 つの矢印が付いたアイコンを選択すると、[ログ] ペインが表示されます。 ここでは、ビルドの進行状況を確認できます。 トポロジ ビューに戻るには、左側のナビゲーション ウィンドウで [Topology] を選択します。
ビルドが完了すると、左下のアイコンに緑色のチェック が表示されます。
デプロイが完了すると、円の輪郭は濃い青色になります。 濃い青色の上にマウスを置くと、「
3 Running
」のようなメッセージが表示されます。 そのメッセージが表示されたら、デプロイに関連付けられているルートから (右上のアイコンを使用して) URL をアプリケーションに移動できます。アプリケーションが次の画像のようにブラウザーで開かれて、使用する準備が整います。
アプリケーションには、情報を提供するポッドの名前が表示されます。 クラスタリング機能を確認するために、いくつかの Todo 項目を追加できます。 次に、アプリケーションに表示される [サーバー ホスト名] フィールドに示された名前のポッドを、
oc delete pod <pod-name>
を使用して削除します。 ポッドを削除した後、同じアプリケーション ウィンドウに新しい Todo を作成します。 Ajax 要求を介して新しい Todo が追加され、[サーバー ホスト名] フィールドに別の名前が表示されるようになったことがわかります。 バックグラウンドでは、OpenShift ロード バランサーが新しいリクエストをディスパッチし、使用可能なポッドに配信しました。 Jakarta Faces ビューは、要求を処理しているポッドに格納されている HTTP セッションのコピーから復元されます。 実際、[セッション ID] フィールドは変更されなかったことがわかります。 セッションがポッド間でレプリケートされていない場合、Jakarta FacesViewExpiredException
が表示され、アプリケーションは期待どおりに動作しません。
リソースをクリーンアップする
アプリケーションを削除する
アプリケーションを削除するだけの場合は、OpenShift コンソールを開き、開発者ビューで [Helm] メニュー オプションに移動することができます。 このメニューには、クラスターにインストールされているすべての Helm チャート リリースが表示されます。
eap-todo-list-demo という Helm Chart を特定します。 行の末尾で、ツリーの垂直ドットを選択して、アクションのコンテキスト メニュー エントリを開きます。
[Uninstall Helm Release] を選択してアプリケーションを削除します。 アプリケーション構成を提供するために使用されるシークレット オブジェクトは、グラフの一部ではないことに注意してください。 不要になった場合は、それを個別に削除する必要があります。
アプリケーション構成を保持しているシークレットを削除する場合は、次のコマンドを実行します。
$ oc delete secrets/todo-list-secret
# secret "todo-list-secret" deleted
OpenShift プロジェクトを削除する
このデモ用に作成されたすべての構成の削除は、eap-demo
プロジェクトを削除することでも行えます。 そのためには、次のコマンドを実行します。
$ oc delete project eap-demo
# project.project.openshift.io "eap-demo" deleted
Azure Red Hat OpenShift クラスターを削除する
「チュートリアル: Azure Red Hat OpenShift 4 クラスターを削除する」の手順に従って、Azure Red Hat OpenShift クラスターを削除します。
リソース グループを削除します
前の手順で作成したすべてのリソースを削除する場合は、Azure Red Hat OpenShift クラスター用に作成したリソース グループを削除します。
次のステップ
このガイドで使用された以下の参考資料から、より多くのことを学習できます。
- Red Hat JBoss Enterprise アプリケーション プラットフォーム
- OpenShift コンテナー プラットフォームでの JBoss EAP の使用
- Azure Red Hat OpenShift
- JBoss EAP の Helm Chart
- JBoss EAP の起動可能な JAR
Azure 上で JBoss EAP を実行するためのオプションについて引き続き調べます。