OpenShiftの再現環境作成のコツ - 第2回 こんにちは、Red Hat Partner Technical Account Managerのイアンです。 シリーズの前回 では、 JBoss EAP Quickstarts を使ってOpenShiftへのサンプルアプリのデプロイと修正方法を説明しました。 また、 JBoss EAP OpenShift Templates も使って、アプリに必要なリソースをすぐ作成できました。 当記事では、テンプレートを使わずにローカルのソースコードのOpenShiftへのデプロイ方法を紹介します。 当シリーズ OpenShiftの再現環境作成のコツ - 第1回 Quickstarts紹介 OpenShiftの再現環境作成のコツ - 第2回 一からビルド OpenShiftの再現環境作成のコツ - 第3回 ランタイムイメージの利用 目次 当シリーズ 目次 事前準備 サンプルアプリ OpenShiftの準備 アプリに必要なリソース デプロイの流れ ImageStreamの作成 BuildConfigの作成 ビルド開始 DeploymentConfig作成 デプロイの確認 Pod上の稼働確認 アプリの公開 Serviceの作成 Routeの作成 稼働確認 再デプロイ まとめと次回の予告 事前準備 サンプルアプリ 事前準備として、JBoss EAP Quickstartsをローカルへクローンします。 $ git clone https://github.com/jboss-developer/jboss-eap-quickstarts.git 今回も helloworld-rs を利用しますが、 pom.xml を修正し、jboss-eap-quickstartsから切り抜きます 1 。 helloworld-rs/pom.xml に対して、以下の変更を行ってください。 変更は、quickstart-parentの依存関係を無くし、JBoss EAPのBOMとリポジトリの定義を追加し、ビルド時のプラグインを定義します。 <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/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> - <parent> - <groupId>org.jboss.eap.quickstarts</groupId> - <artifactId>quickstart-parent</artifactId> - <!-- - Maintain separation between the artifact id and the version to help prevent - merge conflicts between commits changing the GA and those changing the V. - --> - <version>7.4.0.GA</version> - <relativePath>../pom.xml</relativePath> - </parent> + <groupId>org.jboss.eap.quickstarts</groupId> <artifactId>helloworld-rs</artifactId> + <version>1.0.0-SNAPSHOT</version> <packaging>war</packaging> <name>Quickstart: helloworld-rs</name> <description>A simple Hello World project that uses JAX-RS</description> + <properties> + <maven.compiler.source>11</maven.compiler.source> + <maven.compiler.target>11</maven.compiler.target> + <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> + </properties> + + <dependencyManagement> + <dependencies> + <dependency> + <groupId>org.jboss.bom</groupId> + <artifactId>jboss-eap-jakartaee8-with-tools</artifactId> + <version>7.4.0.GA</version> + <type>pom</type> + <scope>import</scope> + </dependency> + </dependencies> + </dependencyManagement> + + <repositories> + <repository> + <releases> + <enabled>true</enabled> + <updatePolicy>never</updatePolicy> + </releases> + <snapshots> + <enabled>true</enabled> + <updatePolicy>never</updatePolicy> + </snapshots> + <id>jboss-public-repository-group</id> + <name>JBoss Public Repository Group</name> + <url>https://repository.jboss.org/nexus/content/groups/public/</url> + <layout>default</layout> + </repository> + <repository> + <releases> + <enabled>true</enabled> + <updatePolicy>never</updatePolicy> + </releases> + <snapshots> + <enabled>true</enabled> + <updatePolicy>never</updatePolicy> + </snapshots> + <id>jboss-enterprise-maven-repository</id> + <name>JBoss Enterprise Maven Repository</name> + <url>https://maven.repository.redhat.com/ga/</url> + <layout>default</layout> + </repository> + </repositories> + + <pluginRepositories> + <pluginRepository> + <releases> + <enabled>true</enabled> + </releases> + <snapshots> + <enabled>true</enabled> + </snapshots> + <id>jboss-public-repository-group</id> + <name>JBoss Public Repository Group</name> + <url>https://repository.jboss.org/nexus/content/groups/public/</url> + </pluginRepository> + <pluginRepository> + <releases> + <enabled>true</enabled> + </releases> + <snapshots> + <enabled>true</enabled> + </snapshots> + <id>jboss-enterprise-maven-repository</id> + <name>JBoss Enterprise Maven Repository</name> + <url>https://maven.repository.redhat.com/ga/</url> + </pluginRepository> + </pluginRepositories> + <licenses> <license> <name>Apache License, Version 2.0</name> @@ -65,6 +115,34 @@ </dependency> </dependencies> - - + <build> + <plugins> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-war-plugin</artifactId> + <version>3.2.3</version> + <configuration> + <failOnMissingWebXml>false</failOnMissingWebXml> + </configuration> + </plugin> + </plugins> + </build> + + <profiles> + <profile> + <id>openshift</id> + <build> + <plugins> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-war-plugin</artifactId> + <version>3.2.3</version> + <configuration> + <warName>ROOT</warName> + </configuration> + </plugin> + </plugins> + </build> + </profile> + </profiles> </project> OpenShiftの準備 リソースを作る前に、新しいプロジェクトを作ります。 今回は、 sandbox という名前を利用します。 $ oc new-project sandbox 次のコマンドで最新版のJBoss EAPのImageStreamをsandboxにインポートします。 oc create -f \ https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap74/eap74-openjdk11-image-stream.json アプリに必要なリソース OpenShiftでアプリをビルドとデプロイするために、以下のリソースがよく使われています： BuildConfig ( bc ): アプリのビルドとイメージ作成を管理する ImageStream ( is ): アプリのイメージを管理する DeploymentConfig ( dc ): ビルドしたアプリのデプロイ定義 3つが揃えば、アプリをビルドし、デプロイすることは可能ですが、OpenShiftの外からはアクセスできません。 アプリにアクセスするためには、更に次のリソースも必要です： Service ( svc ): アプリをアクセスするためのサービス定義 Route ( route ): 外部からアプリをアクセスするためのルーティング定義 デプロイの流れ 大まかな流れは次です： ImageStreamとBuildConfigを作成する ビルドを行う DeploymentConfigを作成する ServiceとRouteを作成し、アプリを公開する それぞれの手順を見てみましょう。 ImageStreamの作成 oc create imagestream eap-app コマンドを用いてアプリ用の ImageStream を作成します。 必須ではありませんが、全てのリソースに分かりやすいラベルを付けると、表示や削除するときが楽になります。 $ oc label is/eap-app application=eap-app BuildConfigの作成 アプリのビルドを管理する BuildConfig を作成します。 次のYAML定義を buildconfig.yaml に保存し、 oc create -f buildconfig.yaml コマンドで BuildConfig を作成します。 kind : BuildConfig apiVersion : build.openshift.io/v1 metadata : name : eap-app labels : application : eap-app spec : runPolicy : Serial source : type : Binary strategy : sourceStrategy : env : - name : GALLEON_PROVISION_LAYERS value : jaxrs-server from : kind : ImageStreamTag name : jboss-eap74-openjdk11-openshift:latest namespace : sandbox type : Source output : to : kind : ImageStreamTag name : eap-app:latest BuildConfig は、 jboss-eap74-openjdk11-openshift:latest のイメージを使って、アプリのソースをビルドします。 ビルドしたイメージを eap-app:latest の ImageStream に保存します。 ビルド時には、 $GALLEON_PROVISION_LAYERS の環境変数を定義しています。 利用可能なレイヤーの詳細は 5.2. 利用可能な JBoss EAP レイヤー をご参照ください。 もし、YAMLが苦手な場合は、 oc コマンドで必要なリソースを作成することも可能ですが、リソースによってYAMLほど定義できる項目が限られています。 当記事では、YAMLの定義を利用します。 oc コマンドで BuildConfig の定義は次です： $ oc new-build --name eap-app \ --binary \ --strategy source \ --image-stream jboss-eap74-openjdk11-openshift:latest \ -l application=eap-app \ -e GALLEON_PROVISION_LAYERS=jaxrs-server ビルド開始 BuildConfig と ImageStream ができたら、ビルドを開始できます。 helloworld-rs ディレクトリに入り、以下の oc start-build コマンドを実行します。 $ oc start-build eap-app --from-dir=. -F Uploading directory "." as binary input for the build ... Uploading finished build.build.openshift.io/eap-app-1 started Receiving source from STDIN as archive ... ... Writing manifest to image destination Storing signatures Successfully pushed image-registry.openshift-image-registry.svc:5000/sandbox/eap-app@sha256:c2886f188bf30e9909ad7b2055640050f0e7ed42aa44a467fcdec9435131de51 Push successful ローカルディレクトリのソースコードを圧縮し、OpenShiftへ転送してから、ビルドを開始します。 ビルドが成功したら、出来上がったイメージを ImageStream にプッシュします。 oc get is/eap-app コマンドで ImageStream の状態を確認できます。 $ oc get is/eap-app NAME IMAGE REPOSITORY TAGS UPDATED eap-app default-route-openshift-image-registry.apps-crc.testing/sandbox/eap-app latest 6 seconds ago DeploymentConfig作成 ビルドが完了したら、コンテナイメージが出来上がりますが、デプロイされていません。 イメージをデプロイするためには、 Deployment 、もしくは DeploymentConfig を用意する必要があります 2 。 当記事では、 triggers が使える DeploymentConfig を利用します。 次のYAMLを dc.yaml に保存し、 oc create -f dc.yaml コマンドで DeploymentConfig を作成します。 kind : DeploymentConfig apiVersion : apps.openshift.io/v1 metadata : name : eap-app labels : application : eap-app spec : replicas : 1 selector : deploymentconfig : eap-app template : metadata : labels : application : eap-app deploymentconfig : eap-app spec : containers : - env : - name : ENABLE_ACCESS_LOG value : "true" image : sandbox/eap-app imagePullPolicy : Always name : eap-app ports : - containerPort : 8080 protocol : TCP resources : {} restartPolicy : Always securityContext : {} terminationGracePeriodSeconds : 30 triggers : - type : ConfigChange - imageChangeParams : automatic : true containerNames : - eap-app from : kind : ImageStreamTag name : eap-app:latest type : ImageChange デプロイの確認 DeploymentConfig が作成されたら、すぐアプリのデプロイが開始され、Podが起動されます。 $ oc get pods -l deploymentconfig=eap-app NAME READY STATUS RESTARTS AGE eap-app-1-5dktn 1/1 Running 0 54s よくできました！ 無事にアプリをビルドし、デプロイできました。 Pod上の稼働確認 EAPアプリのPodが動いていますが、まだ公開していない状態です。 この状態でも、アプリの動作を確認できます。 oc rsh <pod name> コマンドを使って、対象のPodに対してシェルを起動します。 次は、 curl を使って、Podの中のEAPにアクセスします。 $ oc rsh eap-app-1-5dktn sh-4.4$ curl -w "\n" http://localhost:8080/rest/json {"result":"Hello World!"} sh-4.4$ exit $ アプリの公開 Serviceの作成 コンテナ内のJBoss EAPは8080ポートを利用しますので、そのポートを使っている Service を定義します。 次のYAMLを service.yaml に保存し、 oc create -f service.yaml コマンドで Service を作成します。 kind : Service apiVersion : v1 metadata : name : eap-app labels : app : eap-app spec : ports : - name : http port : 8080 protocol : TCP targetPort : 8080 selector : deploymentconfig : eap-app type : ClusterIP サービス対象は、 deploymentconfig: eap-app のラベルが付いているPodになります。 上の DeploymentConfig で定義しました。 Routeの作成 外からアクセスするためには、先に作成した Service を expose する必要があります。 $ oc expose service/eap-app route.route.openshift.io/eap-app exposed 稼働確認 アプリを公開しましたので、稼働確認を行います。 oc get route/eap-app -o jsonpath='{.spec.host}' コマンドでアプリのホスト名を取得します。 curl を使って、httpでアプリにアクセスします。 $ curl -w '\n' http://<host>/rest/json {"result":"Hello World!"} 再デプロイ アプリを再デプロイしたい場合は、 start-build をします。 DeploymentConfig にイメージ変更時の Trigger を設定したため、ビルド完了したら、自動的に再デプロイが走ります。 まとめと次回の予告 テンプレートを使わずにローカルのソースコードをすぐOpenShiftへデプロイする方法を紹介しました。 でも、終わりではありません。 今回紹介したやり方だと、 JBoss EAP Builder Image をそのまま利用しています。 ビルダーイメージには、ビルドツール（Maven, s2i）などが含まれていて、最終イメージのサイズが大きいです。 作った eap-app イメージのサイズは 680MB ほどになります 3 。 サンプルアプリのテストのためですので、そんなに重要な問題ではありませんが、よりお客様の環境に近づきたい場合は、 JBoss EAP Runtime Image を利用する必要があるかと思います。 ランタイムイメージを利用することによって、最終イメージのサイズが 440MB ほどになります。 次回は、ランタイムイメージの使い方を説明します。 各Quickstartは親の pom.xml を参照しているため、 helloworld-rs だけをOpenShiftへ転送したら、親のPOMが見つからず、エラーになります。対応としては、 helloworld-rs のPOMを修正し、親の依存を無くし、スタンドアローンにすることです。 ↩ Deployment と DeploymentConfig の違いについては、 Understanding Deployments and DeploymentConfigs を参照ください。 ↩ oc と skopeo コマンドを使って、作ったイメージのサイズを確認できます。 OpenShift Local (CRC)の場合は、 oc registry login --insecure=true を実行し、コンテナレジストリの認証情報を取得します。 skopeo と jq コマンドを組み合わせて、イメージの中の各レイヤーのサイズを合計します。 $ skopeo inspect --tls-verify=false docker://default-route-openshift-image-registry.apps-crc.testing/sandbox/eap-app | jq '[.LayersData[]|.Size]|add' 683122420 ↩

こんにちは、Red Hat Partner Technical Account Managerのイアンです。 サポートケース対応の中では、お客様が遭遇している事象を再現するためのサンプルアプリを自前で作ることが多いです。 ミドルウェア単体の問題であれば、 Red Hat Customer Portal から対象製品をダウンロードし、すぐアプリをデプロイできます。 でも、お客様は OpenShift の環境を使っているときはどうしましょうか？ 当シリーズでは、ローカルPC下のサンプルアプリをそのまま使って、OpenShiftに手軽にデプロイする方法を紹介します。 当シリーズ OpenShiftの再現環境作成のコツ - 第1回 Quickstarts紹介 OpenShiftの再現環境作成のコツ - 第2回 一からビルド OpenShiftの再現環境作成のコツ - 第3回 ランタイムイメージの利用 目次 当シリーズ 目次 OpenShiftが本当に必要？ OpenShiftの検証環境の入手 OpenShift Localの性能向上 Quickstarts OpenShiftでのデプロイ プロジェクト作成 ImageStreamのインポート Templateのインポート アプリの作成 ビルドとデプロイ 稼働確認 次のステップ Quickstartアプリのコード修正 まとめと次回の予告 OpenShiftが本当に必要？ まずは、OpenShift環境が本当に必要かどうかを切り分けましょう。 OpenShift特有の機能を使っていなければ、ミドルウェア単体で再現することは可能かもしれません。 また、OpenShiftで利用しているコンテナイメージは Red Hat Container Registry からダウンロード可能であり、ローカルで Podman や Docker でそのまま使えます。 そのやり方については、以前投稿した ローカルでのSource-To-Image (s2i)の検証 をご参照ください。 残念ながら、BuildConfig、Deployment/DeploymentConfigの挙動確認、コンテナの ライフサイクルフック の動作確認などの場合は、OpenShift環境が必要になります。 でも、割と手軽にOpenShift環境を入手できます！ OpenShiftの検証環境の入手 OpenShiftの検証環境を入手する方法はいくつか存在しています。 身近な環境（社内、校内、ご自宅など）をそのまま利用する AWS, Azure, GCP上のOpenShift環境 大手クラウドサービスで手軽にOpenShift環境を起動できますが、有償になります。 Red Hat提供の Developer Sandbox for Red Hat OpenShift Red Hat Developer のアカウントをお持ちであれば、30日間無償でご利用できる環境を使えます。詳細は上記のリンクをご覧ください。 OpenShift Local (旧名: CodeReady Containers (CRC)) ローカルPCにOpenShift環境を起動する方法です。 簡単に導入できますが、最低限の必要スペックは高いです： 4 CPUコア以上 9 GBメモリ以上 35 GBディスク以上 当記事では、OpenShift Localを利用しますが、他の環境でも使えるはずです。 環境の用意ができたら、サンプルアプリのデプロイの仕方を見てみましょう。 OpenShift Localの性能向上 ローカルPCで起動するときは、私は以下のコマンドを事前に実行し、性能を向上させます。 もちろん、自分の環境に合わせて設定を変更してください。 8コアまで利用する crc config set cpus 8 14GBメモリまで利用する crc config set memory 14336 Quickstarts サンプルアプリを作りたい場合は、一から作るのが大変でしょう。 EJBのアノテーションは何でしたっけ？ どうやってデータベース接続を用意すればいいの？ RESTのWebサービスをどう定義すればいいでしょうか？ ご安心ください！一から作成する必要が全くありません！ Red Hatは、Quickstartと呼ばれる高度な機能をすぐ使えるためのサンプルアプリを提供しています。 EAPの場合は、80個弱のQuickstartがあり、EJB、MDB、JPA、CXF、Resteasy などの技術を使っているサンプルもあります。 kitchensink (流し台)のQuickstartは複数機能を用いて、一般的なWebアプリに近いサンプルですが、再現アプリのベースとしては若干複雑です。 単純なアプリを作りたい場合は helloworld-* のQuickstartをベースにすることがお勧めです。 Quickstart の詳細は以下のリンクをご覧ください。 Red Hatカスタマーポータル上の JBoss EAP quickstart examples GitHub上の jboss-developer/jboss-eap-quickstarts OpenShiftでのデプロイ QuickstartのサンプルアプリをOpenShiftにデプロイする時の手順は以下の感じです。 OpenShift上のプロジェクトを作成する 必要なリソースをインポートする テンプレートを用いてEAP 7.4のアプリを作成する この手順の詳細は 第2章 JBoss EAP for OpenShift イメージでの Java アプリケーションのビルドおよび実行 に記載されています。 プロジェクト作成 oc new-project quickstart コマンドで新しいOpenShiftプロジェクトを作成する。 当記事では quickstart という名前を使っていますが、任意に決めていいです。別の名前を使った場合は、これからのコマンド例に quickstart を置き換えてください。 $ oc new-project quickstart Now using project "quickstart" on server "https://api.crc.testing:6443". You can add applications to this project with the 'new-app' command. For example, try: oc new-app rails-postgresql-example to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application: kubectl create deployment hello-node --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 -- /agnhost serve-hostname ImageStreamのインポート 最新版のJBoss EAP 7のImageStreamを quickstart プロジェクトにインポートします。 この例には、JDK 11用のイメージを利用します。 $ oc create -f \ https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap74/eap74-openjdk11-image-stream.json Templateのインポート EAPアプリを簡単にデプロイするためのテンプレートが用意されています。 テンプレート情報を quickstart プロジェクトにインポートします。 NOTE: テンプレートを使わない方法は後で紹介します。 for resource in \ eap74-amq-persistent-s2i.json \ eap74-amq-s2i.json \ eap74-basic-s2i.json \ eap74-https-s2i.json \ eap74-sso-s2i.json do oc create -f \ https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap74/templates/${resource} done NOTE: コマンドを貼り付ける場合は、 $\{resource\} にならないようにご注意ください。 アプリの作成 先程のテンプレートを使って、Quickstartのアプリをデプロイします。 $ oc new-app --template=eap74-basic-s2i \ -p IMAGE_STREAM_NAMESPACE=quickstart \ -p EAP_IMAGE_NAME=jboss-eap74-openjdk11-openshift:7.4.0 \ -p EAP_RUNTIME_IMAGE_NAME=jboss-eap74-openjdk11-runtime-openshift:7.4.0 \ -p SOURCE_REPOSITORY_URL=https://github.com/jboss-developer/jboss-eap-quickstarts \ -p SOURCE_REPOSITORY_REF=7.4.x \ -p CONTEXT_DIR=helloworld-rs \ -p GALLEON_PROVISION_LAYERS=jaxrs-server \ -e ENABLE_ACCESS_LOG=true NOTE: quickstart 以外のプロジェクト名を使った場合は、 IMAGE_STREAM_NAMESPACE の値をプロジェクト名に変更してください。 なお、各環境変数の詳細は 2.5. JBoss EAP S2I (Source-to-Image) アプリケーションの OpenShift へのデプロイ までご参照ください。 ビルドとデプロイ ここまでできたら、OpenShift上に指定したQuickstartのアプリがビルドとデプロイされます。 全体の状況を oc status コマンドで確認できます。 ビルドが完了したら、アプリの動作を確認しましょう。 稼働確認 以下のコマンドでアプリのホスト名を取得します。 oc get route/eap-app -o jsonpath='{.spec.host}' curl を使って、httpsでアプリにアクセスします。 $ curl -k -w '\n' https://<host>/rest/json {"result":"Hello World!"} できました！ 次のステップ Quickstartのサンプルアプリを簡単にOpenShiftにデプロイできました！ でも、ここで一つ疑問がありませんか？ どうやってアプリのコードを編集しますか？ QuickstartをGitHubからデプロイしましたが、GitHubのレポジトリをフォークし、ローカルにクローンし、修正し、またプッシュするのはかなり手間がかかります。 ローカルのソースコードからビルドする方法を説明します。 Quickstartアプリのコード修正 コードを修正するためには、ローカルにコードを用意する必要があります。 jboss-eap-quickstarts をローカルにクローンする。 jboss-eap-quickstarts ディレクトリに移動する。 7.4.x ブランチに切り替える。 準備ができたら、コードを編集します。 先に helloworld-rs を利用したため、 helloworld-rs の中の HelloService.java を以下のように変更します。 RESTサービスの応答の Hello を Hi に切り替えます。 変更前 public class HelloService { String createHelloMessage(String name) { return "Hello " + name + "!" ; } } 変更後 public class HelloService { String createHelloMessage(String name) { return "Hi " + name + "!" ; } } 編集できたら、アプリをOpenShiftにデプロイしましょう！ jboss-eap-quickstarts ディレクトリに戻る ビルドを開始する oc start-build eap-app-build-artifacts --from-dir=. oc start-build の --from-dir オプションを使って、ローカルディレクトリ内のファイルを圧縮し、OpenShiftへ転送することが可能です。 ビルドとデプロイが完了したら、サイトをアクセスする $ curl -k -w '\n' https://<host>/rest/json {"result":"Hi World!"} start-build に --from-dir オプションを使えば、ローカルのソースコードをそのままOpenShiftに転送し、ビルドできます。 ただし、アプリを作成したときは、 CONTEXT_DIR=helloworld-rs を指定しましたので、 helloworld-rs のディレクトリがソースコードにないと、ビルドがエラーになります。 あまり柔軟性がありませんね。 また、このやり方では、ビルド時には jboss-eap-quickstarts を全部まとめてOpenShiftに転送する必要があります。 これも少し無駄が多いです。 色々できましたが、まだ少し物足りません。 まとめと次回の予告 弊社が提供しているQuickstartをベースにしたサンプルアプリをOpenShiftに簡単にデプロイする方法を紹介しました。 また、そのアプリを修正し、再デプロイする方法も説明しました。 次回は、テンプレートとGitHubを使わずに、既にローカルにあるソースコードのデプロイ方法を勉強します。

OpenShift AppDev SSAの瀬戸です。 Migration Toolkit for Applications(以下MTA)という製品をご存知でしょうか？Red Hatが出している静的解析ツールで、古いバージョンのJBoss EAPやOpenJDKなどのミドルウェアで動いているアプリケーションを最新のミドルウェア上で動作させるために必要な修正を洗い出してくれます。 実は、それだけではなく、組織のアプリケーションのモダナイゼーションのサポートもしてくれます。この記事では何回かにわけて、どういった機能があるのかと実際の使い方をご紹介したいと思います。 ちなみに、MTAは無償でお使いいただくことが可能です。 前回はMTAをインストールしてログインできるところまで説明をしました。今回は実際に使っていきたいと思います。 アプリケーションをMTAに登録して、モダナイゼーションをするべきかどうかアセスメント(評価)をしたいと思います。 MTAってなんだ？って人は以下の記事を参照してください。 rheb.hatenablog.com MTAをインストールしたことがない人は以下の記事を参照してください。 rheb.hatenablog.com ログイン直後だと以下のような画面が表示されているはずです。 ログイン直後 初期設定 アプリケーションを登録する前にいくつかの設定が必要になります。 左上のプルダウンからAdministrationを選択することでMTA自体の設定を変更することが可能です。 権限のプルダウン Assessment questionariesに登録されているLegacy PathfinderのRequiredをYesに設定します。これはMTAに登録されているデフォルトの質問集です。Red Hatのコンサルタントが何を気にしてクラウドに移行するかを検討するかをまとめたものになります。今回はアセスメントの内容のカスタマイズまでは行わずに、この質問集をそのまま使います。 Assessment questionaries その他にもGitのセキュリティの設定や、Proxyの設定等が行えます。必要に応じて他のものも設定を変更します。 アセスメント前の情報の登録 MTA自体の設定が終わったら、次はアセスメントに必要な情報を登録していきます。 左上の権限を選択してAdministrationからMigrationの方に戻ってきます。 まずは、ステークホルダー(関係者)の情報を登録します。 ステークホルダーの情報を登録するのは非常に重要です。 組織内のアプリケーションを横断的に変更しようとした場合に、アプリケーションの管理者が見つからないからといって、勝手にアプリケーションを変更したりはしません。あらためて責任者を立てる等、何かしらの対応を行います。責任者がわからないまま何かしらの対応をしようとした場合に、あとから責任者が出てきて、「俺何も聞いてないんだけど？」の一言でブロッカーとなってしまう可能性があります。 そのため、MTAでは最初にステークホルダーを登録する必要があり、誰がやったのか等の履歴をきちんととる必要があります。 ステークホルダーの登録はControlsから行うことができます。 ControlsからStakeholdersを選択して、Create newを押してください。 ステークホルダーの新規登録 ステークホルダーの情報を登録します。 ステークホルダーの情報入力 Saveを押せば一覧画面に表示されます。 ステークホルダーの登録後 これでステークホルダーの情報を登録できました。 アプリケーションの登録 ステークホルダーを登録したらアセスメントを行うアプリケーションの登録を行います。 Application InventoryからCreate newを選択します。 アプリケーションの登録 アプリケーションの情報を入力していきます。 必須なのはNameだけですが、Ownerとアプリケーションのソースコードの情報も入力しています。 なお、サンプルとして載せているgitのリポジトリは次の通りです。この後の静的解析で使用しますので、特にこだわりがない場合は以下の値を入力してください。 git リポジトリ - https://github.com/ssetoredhat/mtr-example-eap7.4to8.0 Branch - main Root Path - eap7.4/coolstore アプリケーションの情報入力1 アプリケーションの情報入力2 Saveを押すとアプリケーションの登録が終わります。 アプリケーションの一覧 アセスメントの実施 ここから実際にアセスメントを行います。アセスメントでは担当者が把握しているアプリケーションの管理状態を入力し、アプリケーションのクラウドへの移行に対してどれくらいの問題を内在しているのかの基礎情報を入力します。 アプリケーションの右側の縦になっている…をクリックし、Assessを選びます。 評価開始 Legacy Pathfinderを選択します。 使用するアセスメント ステークホルダーを登録します。これはこのアセスメントの回答者です。今回は既に登録した情報を使用します。実際にMTAで移行のアセスメントをする場合は自分自身の情報をステークホルダーとして登録するのを忘れないようにしてください。 ステークホルダーの指定 アセスメントが始まりますので、回答していきます。 このアセスメントに使用されている質問集はRed Hatのコンサルタントがアプリケーションの移行時にどういった考慮が必要かを考えた質問です。 Red Hatのコンサルタントがどういうことを気にしながらアプリケーションのモダナイゼーションを行っているのかが気になる人は、質問の内容を一通り確認するとよいでしょう。実際に移行をしなくても、現在のアプリケーションの運用でどれくらいの課題が内在しているかを把握するための一助となるかもしれません。 質問の内容をyamlとしてダンプしたものを以下のgistに保存してあります。必要に応じて参照してみてください。 Legacy Pathfinder.yaml · GitHub 質問 最後まで選択するとSaveとSave and reviewというボタンが表示されるので、今回はSaveを押します。reviewは後程別途行います。 アセスメントの終了 これでアセスメントは終了です。 静的解析 引き続き、静的解析を行います。静的解析では、事前に登録してあるルールに基づいてソースコードやバイナリを解析し、アプリケーションのコンテナ化、ミドルウェアの最新化にどういった修正が必要なのかを機械的に洗い出してくれます。先ほどアセスメントを行いましたが、どうしても担当者の思い込みや間違いが発生する可能性があります。静的解析ではそういったのを防ぎ、移行するのにどれくらいの修正が必要なのかを確認することができます。ただ、これで発見できるものがすべての修正ではありません。ただ、他のアプリケーションと比較することでどちらの方の移行が難しそうかといったことを判断することができます。 MTAはモダナイゼーションのために使用できるという説明をしましたが、静的解析ではもうちょっと具体的に、最新版のEAP 8への移行、やSpringからQuarkusへの移行、アプリケーションのコンテナ化をするために必要なタスクなどを洗い出すために使用する事ができます。 アプリケーションのチェックボックスを選択してから、Analyzeを押します。 静的解析開始 次に静的解析を行うアプリケーションのソースコード、バイナリの場所を指定します。アプリケーションの登録時にgitリポジトリの情報を登録してあるため、Source Codeを指定します。 ソースコードの指定 移行先を指定します。今回のサンプルアプリケーションはEAP 7.XからEAP 8.0への検証用に作成したアプリケーションなので、JBoss EAP 8を指定しています。これ以外にも最新のOpenJDKやコンテナへの移行等を検証することが可能です。 移行先の指定 その後、nextを押していき、最後にRunを押すことで、静的解析が実行されます。細かい挙動のカスタマイズをすることもできますが、今回は省略しています。 実行終了までには数分程度かかります。 静的解析中 終わると、アプリケーションにどういうテクノロジーが含まれているかを参照できるようになります。 アプリケーションに含まれているテクノロジー また、どういった修正が必要なのかについてはissuesから参照する事ができます。こちらでアセスメントの結果だと簡単に移行できると思っていたが、修正があまりにも多い場合等はアセスメントの結果を見直す必要が出てきます。 イシューの一覧 レビューを行う ここまででアプリケーションを取り巻く環境のアセスメント及びに、静的解析による難易度の測定が行えました。実際にその結果を見ながらレビューを行います。 アプリケーションの左の縦になった…をクリックしてreviewを選択します。 レビュー開始 さて、この先では実際にアプリケーションをどうやっていきたいのかを今まで解析した結果を基に入力していきます。 右側にはアセスメントで入力した結果が表示されています。 レビュー画面 Proposed Actionには6Rからどれを行うのかを選びます。 6Rってなんだっけ？と思った人は概要編を参照してください。 Effort estimateは作業の大変さを見積もった結果を入れます。Business criticalityやWork priorityについても今までのアンケートを基に入力していきます。ただし、これらに関しては何を入れるのかの指針についてはありません。それぞれの企業で自分たちの状態を勘案し適切に選択する必要があります。 ここは企業の状況によって適切に選択する必要があり、非常に難しいところです。今回は一つのアプリケーションだけの入力になっていますが本来は他のアプリケーションと見比べながら優先順位をつけていきます。Red Hatではお客様と一緒に移行の順番を考えられるようにコンサルティングサービスを提供しています。困ったらお問い合わせください。 ここで入力が終わればMTAを使うレクチャーは終わりです。これを企業内でアプリケーションがあるだけ繰り返して入力をしていきます。 アプリケーションのグルーピングを行うためのタグ打ちの機能や、どのビジネスサービスからどのアプリケーションが使われているのかを管理する機能等もあります。実際に使われる際にはそちらもぜひお試しください。 まとめ MTAの実際の入力方法を説明しました。システムのモダナイゼーションをしたいとだけ言われても途方に暮れてしまいますが、MTAを使う事でそのとっつきにくさを軽減することができます。ぜひご活用ください。

OpenShift AppDev SSAの瀬戸です。 Migration Toolkit for Applications(以下MTA)という製品をご存知でしょうか？Red Hatが出している静的解析ツールで、古いバージョンのJBoss EAPやOpenJDKなどのミドルウェアで動いているアプリケーションを最新のミドルウェア上で動作させるために必要な修正を洗い出してくれます。 実は、それだけではなく、組織のアプリケーションのモダナイゼーションのサポートもしてくれます。この記事では3回にわけて、どういった機能があるのかから実際の使い方をご紹介したいと思います。 ちなみに、MTAは無償でお使いいただくことが可能です。 前回はMTAの概要を説明しました。今回は使うまでの準備(インストール)をしたいと思います。 前回の記事はこちら。 rheb.hatenablog.com この記事では OpenShift 4.15/MTA 7.0.1を使用しています。バージョンによって多少挙動が違う可能性がありますので必要に応じて使用されるバージョンのマニュアルをご参照ください。 MTAの全機能を使うためにはOpenShiftが必要です。また、デフォルトで4vCPUと8Gバイト以上(20Gバイト以上推奨)のメモリ割り当て、150 Gバイト以上の永続ストレージの割り当て *1 と、インストール時に cluster-admin 権限が必要になります。詳細についてはドキュメントを参照してください。 access.redhat.com OpenShiftのサブスクリプションが足りていない場合は、OpenShift Localにインストールすることも可能です。OpenShift LocalはHyper-V上にインストールできるOpenShiftの簡易的なお試し環境です。 ただ、Windows上のOpenShift Local 4.14.2で試したところ、デフォルトのメモリ割り当てが小さするのと、デフォルトで作成される仮想ディスクファイル(vhdx)が小さすぎて拡張が行えない問題が発生しました。手動でメモリ割り当て *2 や、vhdxのファイルサイズ *3 を増やしてあげる必要がありました。ご注意ください。 メモリ割り当ての増やし方は特殊な方法が必要になるので以下のドキュメントを参照してください。vhdxの容量についてはHyper-Vの管理コンソールから増やすことが可能です。 access.redhat.com docs.redhat.com OpenShift Localについては以下のページからダウンロードが可能です。 console.redhat.com MTAのインストール MTAはOpenShift上のOperatorHubからインストールすることができます。 cluster-admin 権限を持ったユーザーでログインし、右のメニューからOperator→OperatorHubを選択し、Migration Toolkit for Applicationsで検索をしてください。 OperatorHub 選択するとインストール画面が表示されるので、そのままインストールを押します。 インストール画面 次の画面でもそのままインストールボタンを押します。 インストール設定 そのままインストールがはじまります。 インストール中 そのうち、Tackleの作成ボタンが表示されます。必要な依存リソースなのでTackleの作成ボタンを押します。 Tackleのインストール Tackleの作成画面が開くので、そのまま作成ボタンを押します。 Tackleの作成 10分ぐらい待つと 環境が完成します。Developerパースペクティブからトポロジーを開いて、openshift-mtaプロジェクトを選択します。 トポロジーの選択 インストールが完了している場合は以下のように表示されます。すべてのpodが青くなっている 事を確認したうえで、mta-uiのURLを開くを選択します。 MTAのURLを開く(mta-uiと名前の付いたpodの右上のボタン) ※いつまで待っても青くならない場合はリソースが不足していることが考えられます。メモリや永続化ボリュームの割り当て量が問題ないことを確認してください。 クリックするとログイン画面が表示されます。 Admin / Passw0rd! でログインすることができます。 ログイン 初回はパスワードの変更画面が表示されますので、好きなパスワードを入力してください。 パスワード変更画面 そうすることで、ログインすることができました。 ログイン後初期画面 まとめ これでMTAを使用し始める準備が整いました。次回は実際にMTAを操作していきます。 続きはこちらから。 rheb.hatenablog.com *1 : 設定を見直すことで最低40Gバイト以上の永続ストレージで動作させることが可能ですが、設定変更方法については割愛します。 *2 : 余裕をもって20Gまで増やしました。 *3 : 余裕をもって200Gまで増やしました。

OpenShift AppDev SSAの瀬戸です。 Migration Toolkit for Applications (以下MTA)という製品をご存知でしょうか？Red Hatが出している静的解析ツールで、古いバージョンのJBoss EAPやOpenJDKなどのミドルウェアで動いているアプリケーションを最新のミドルウェア上で動作させるために必要な修正を洗い出してくれます。 実は、それだけではなく、組織のアプリケーションのモダナイゼーションのサポートもしてくれます。この記事では3回にわけて、どういった機能があるのかから実際の使い方をご紹介したいと思います。 ちなみに、MTAは無償でお使いいただくことが可能です。 Red Hatの6R Red Hatはモダナイゼーションの移行戦略として6Rを提唱しています。次のようなものです。 Red Hatの6R モダナイゼーションの移行戦略といったときに単一のシステムの移行を想像されるでしょうか？ このツールは単一のシステムを移行させるのに必要な情報を提供するだけではなく、企業内の複数のシステムを移行する際にどのシステムから移行するべきかを検討する判断材料を提供してくれます。 現在の企業システムは複雑に絡み合っています。新しく作るシステムをクラウド上にデプロイすることは簡単ですが、古くから動作しているシステムをクラウドに移行しようとする場合は、システムの状態や依存関係を把握したうえで、優先順位をつけて順序良くクラウドに移行する必要が出てきます。 まれにすべての基盤システムを一度に更改し、数年かけて基盤入れ替えを行ってしまうような企業もありますが、多くの企業にとっては現実的ではありません。 また、移行を検討する中では、実は移行をする必要がないシステム(数年後には不要になるシステム等)が見つかることもあります。少なくとも、何も考えずに全部のシステムをクラウドに移行するべきというわけではありません。移行するための費用の無駄となります。 MTAの機能 MTAの全機能を使うためにはOpenShift上で動作させる必要があります。 。 OpenShift上で動作させるMTAには次の機能が含まれます。 移行対象の管理 - 組織がクラウドに移行しようとしているアプリケーションを一覧化し、どのアプリケーションの移行が必要なのかを管理できます。 移行対象の優先順位付け - アプリケーションの利用状況や開発、運用の情報をまとめ、状況に基づいた意思決定を行えるようにし、移行と最新化の優先順位をつけます。 アプリケーションの静的解析 - 複数のオープンソースツールに込められた知見を活用し、事前にどのような修正が必要なのか一覧を作成し、移行方法を解析します。 このうちアプリケーションの静的解析に関しては以前から持っている機能となり、以前もJBoss EAPの最新化の記事でご紹介をさせていただいたことがあります。 移行対象の管理 企業は複数のアプリケーションを保持しています。単一のアプリケーションしか持っていない企業はごく少数でしょう。どのようなアプリケーションがあるのかを一覧として管理することができます。それぞれのアプリケーションには依存関係があるはずです、依存関係や、そのアプリケーションが持っている特性をメタデータとして管理することができます。どのビジネスサービスからどのアプリケーションを使用しているのかをリンクすることもできます。 移行対象の管理 移行対象の優先順位付け アプリケーションの状態をアンケートとして入力することにより、アプリケーションを取り巻く環境がクラウド化に適しているのかを評価します。 アプリケーションの使用状況や、クラウド上でベストプラクティスとされている手法が運用上すでに行われているのかを評価し、クラウドへの移行優先度、移行難易度を推定します。 その中で、移行が簡単だと思われるものや、ビジネス価値が高いものについては移行の優先順位が高くなりますし、どれだけビジネス価値が高かろうとも、移行難易度が極限まで高ければ移行しないという判断を行うことができます。 移行対象の優先順位付け このアンケートは組み込みのものを使う事もできますし、お客様でカスタマイズすることも可能です。お客様固有の事情がある場合、例えば、レガシーな社内フレームワークを使っており、リプレイスが必要となっている場合、などはアンケートに項目を追加する事で社内システムの評価項目に加えることもできます。その他、どのような質問が必要なのかについては弊社コンサルタントがお手伝いすることもできますので、必要に応じてお問い合わせください。 アプリケーションの静的解析 第三者目線によるアプリケーションの解析を行い、アプリケーションにどういった修正が必要なのかを洗い出してくれます。すべてを洗い出してくれるわけではありませんが、主だった修正を簡単に潰しこむことが出来るようになります。アンケートはどうしても担当者の思い込みが入り込みますが、この機能の場合は思い込みが入り込むことはありません。移行が簡単だと思ってたけれども実は大変だったといったことを防ぐことができます。 また、クラウドに移行したいけれども、移行順序の評価までは必要がないが、具体的にどういう修正が必要なのかがわからないという方はこちらを動作させるだけでも助けになります。 ただし、現時点ではJava言語のみサポートされております。他言語についても逐次対応予定なので、少々お待ちください。 *1 静的解析 この機能のみコマンドライン版で動作させることができます。実際にクラウドへの移行のためのアプリケーションの修正を始めた後はOpenShift上から動作させるのに比べてコマンドラインから動作させる方が簡単なので、そちらから使用する事が推奨です。 まとめ ここまででMTAが持っている機能を一通り紹介しました。 次回は、MTAをインストールして実際に使える状態にします。 次回の記事はこちらから。 rheb.hatenablog.com *1 : Go言語がtech preview中、.NET、TypeScript、Pythonのサポートがマイナーアップデートで提供予定

皆さんこんにちは、Red Hat の岡野です。 前回 Event-Driven Ansible のお試し方法についてご紹介させていただきましたが、今回は一歩踏み込んで、サードパーティ製のアプリケーションと連携した動作についてご紹介します。 Event-Driven Ansible (EDA) は以下のような様々なイベントソースと連携し動作します。 ・Zabbix ・IBM Instana, Turbonomic ・Dynatrace ・CrowdStrike ・AWS Cloudtrail, SQS ・Azure Service Bus など 今回この中から、IBM 社の Turbonomic および Instana との連係動作についてご紹介したいと思います。 IBM Turbonomic と Instana IBM Instanaは、WebSpere や DB2、Oracle など従来型アプリケーションから最新のクラウドネイティブアプリケーションにも対応したアプリケーション・パフォーマンスの管理ソリューションです。分散トレーシングによりサービスの依存関係を自動的に可視化。アプリケーションを構成する各マイクロサービスのアクセスレイテンシレベルまで可視化されます。 この可視化された情報を元に AI を活用してサービスレベルの監視を行い、アプリケーションの日時や季節性も考慮した、 『普段と異なるアプリケーションの状態』 を即座に検知。必要に応じ、動的なアラートを発砲することが可能となっています。 www.ibm.com 一方、Turbonomic はリソースの利用状況の把握と最適化を行うことが出来ます。オンプレやパブリッククラウド含めたアプリケーションが稼働するインフラの把握と、リソースの利用状況を自動的に検知しグラフィカルに可視化。 『リソースの過不足をリアルタイムかつ継続的に監視』することにより、アプリケーションに影響を与え得るリソース上の制約、将来の予測分析などをAIを用いて把握した上で、必要があればインスタンスの『スケールイン/スケールアウト』、『スケールアップ/ダウン』を行う機能を提供します。 www.ibm.com IT 運用の現場では様々な監視ツールが利用されていますが、何か問題が起こってアラームが通知されたとき、『原因』や『修正方法』、『修正作業中のサービスへの影響範囲』などを把握すること、さらに、それらを理解した上で修正実行の要否や時期を判断。また、修正実施後にはサービスの正常稼働を確認する必要があることなどから、問題解決までには多くの時間と労力を要します。 その手間と時間を大幅に削減してくれる魅力ある機能を提供するのが Event-Driven Ansible です。Instana や Turbonomic から得られる様々な情報を元に、問題が発生した場合は Event-Driven Ansible で自動的に修正を行います。修正アクションは完全自動実行も可能ですし、Ansible Automation Controller のワークフロー内に承認フローを入れたり、Servicenow などのチケット管理システムなどを挟んで、最終実行は『人』が判断することも可能です。 今回はEvent-Driven Ansible のイベントソースとして、『Instana を使ったアプリケーション障害復旧の自動化』と、『Turbonomic を使ったインフラリソースの自動最適化』に関するデモ動画を作成してみました。是非ご覧ください。 ※デモ動画は音声付きですのでリンクをクリックする際はご注意ください。 Instana + Event-Driven Ansible によるアプリケーション障害復旧の自動化（デモ動画は こちら ） コンテナアプリケーション（Quote of the Day）に障害が発生 Instana がアプリケーションの障害を検知しアラームを発砲 Webhook 経由でアラームが Event-Driven Ansible へ通知される Event-Driven Ansible 内で Rulebook を元に Action 実行が必要と判断 Action を実行し、Ansible Automation Controller 内のジョブテンプレートを実行 アプリケーションが正常に稼働 Turbonomic + Event-Driven Ansible による IT リソースの自動最適（デモ動画は こちら ） AWS 上のインスタンスのリソース利用状況を監視 リソース状況に応じた推奨（インスタンスタイプの変更）を提示 Webhook 経由でインスタンスタイプの変更を Event-Driven Ansible へ通知 Event-Driven Ansible が Rulebook を元に、AWS のタグ情報を含め、インスタンスタイプ変更の可否を判断 インスタンスタイプの変更を実施し、アプリケーションの稼働を確認 まとめ 今回は、IT 運用監視系のツールである、IBM 社の Instana 及び Turbonomic と Red Hat Event-Driven Ansible の連携よる IT 運用自動化のお話でした。如何でしたでしょうか？先述の通り、IT 運用においては様々な監視ツールからアラームが上がってきます。その際、そもそも対応が必要なのかどうか？という判断から始まり、障害内容の把握、対処法の確認、実施の判断、作業員の確保と実施、実施後の正常動作の確認...など、多くの時間と労力が必要となります。 このような運用に対し、 『あらかじめ課題解決のルール』 を定義しておき、問題が起こった時にはそのルールに従うことで手間なく自動的に修正ができる、というのが今回のブログの趣旨となります。 勿論、あらかじめ準備されたものに関しては、導入当初は『抜け・漏れ』や『修正できない』などの問題が数多く発生することが予想されますが、運用上発生したそういった問題を都度システム側にフィードバックしていくことで Instana / Turbonomic 及び、Event-Driven Ansible、Ansible Automation Controller 内に IT 運用のナレッジがたまっていきます。 つまり、運用すればするほど賢くなっていきます。そして、いずれ『人依存』からの脱却が可能となるのではと思います。 こちらのソリューションにご興味ある方は是非 Red Hat 担当までご連絡ください。

Red Hat のソリューションアーキテクトの瀬戸です。 この記事はRed Hat Developerのブログ記事、 What's new in JBoss Enterprise Application Platform 8.0 | Red Hat Developer を、許可をうけて翻訳したものです。 Red Hat は最近、 Jakarta EE 準拠プラットフォームの最新リリースであるJBoss EAP 8.0 を発表しました。このリリースにより、企業は最新のJakarta EE APIを活用し、エンタープライズ Java アプリケーションのライフサイクルを大幅に延長できるようになります。 JBoss EAP 8.0 では、管理コンソールと CLI、セキュリティ、クラスタリング、データソース、EJB サブシステムなど、プラットフォームの多くの領域にわたって改善が加えられています。新しい機能と拡張機能、および削除された機能と非推奨になった機能の詳細なリストについては、 JBoss EAP 8.0 リリースノート を参照してください。 この記事では、JBoss EAP 8.0 の新しい機能と、顧客が古いバージョンの JBoss EAP から移行できるように Red Hat が提供するツールについて説明します。 Jakarta EE アプリケーションの長期サポート サポートライフサイクルページ に示されているように、JBoss EAP 8.0 は長期ライフサイクルサポートポリシーを採用しています。 Jakarta EE 10 の互換性 Jakarta EE 8をサポートするJBoss EAP 7.4とは異なり、JBoss EAP 8.0 は Jakarta EE 10 API の実装を提供します。Jakarta EE 10 には、Jakarta EE に対する多くの変更が加えられています。 JBoss EAP アプリケーションを Jakarta EE 8 から Jakarta EE 10 に移行する方法 について詳しく学習してください 。 Jakarta EE 10 への移行での最も重要な変更の 1 つは、ネームスペース(パッケージ)が javax から jakarta に変更されたことです。これはJava EE がEclipse Foundation へ移管され Jakarta EEの確立されたことに続くものです。 Red Hat は、この移行に必要なアプリケーションコードの変更についてお客様を支援するためのルールを備えた Migration Toolkit for Applications (MTA) を更新しました。 Jakarta EE 10 Core Profile Jakarta EE 10 Core Profileが JBoss EAP 8.0 で利用できるようになりました。Jakarta EE Core Profile は Jakarta EE 10 で導入され、クラウドネイティブ開発とマイクロサービスをサポートする最小限の API セットに重点を置いた最新のクラウド アプリケーションの開発者を対象としています。Jakarta EE 10 Core Profileは、Galleon プロビジョニング レイヤー、ee-core-profile-server として利用できます。 最新のプロビジョニング システム JBoss EAP 8.0 は、すべてのデプロイメントターゲット (ベアメタルやVM、クラウド) 全体で一貫性を高め、テスト/ステージング環境と実稼働環境の間の差異を削減する新しいプロビジョニングシステムを導入します。 ターゲット環境に応じて、適切なツールがプロビジョニングを実行します (例: クラウド用の Maven プラグイン、またはベアメタル/VM 用の jboss-eap-installation-manager CLI)。これらのツールの中核には、機能パック、レイヤー、チャネルという同じ 3 つの概念があります。チャネルは、特定の製品バージョン (8.0、8.1 など) をプロビジョニングするために必要なコンポーネントの下位互換性リリースのコレクションです。クラウド展開の場合、プロビジョニング システムは、アプリケーションの依存関係をサポートするために必要なレイヤーのみを展開するように設計されており、その結果、イメージサイズと取り組み対象領域が縮小されます。 運用チームは、同じデータソースレイヤーを使用して VM とクラウドにデータベース用のドライバーを展開するなど、展開対象や環境に関係なく、一貫した構成とこれらの概念の利用から恩恵を受けます。 新しいプロビジョニング システムは、オンラインとオフラインの両方の展開をサポートします。オンライン デプロイメントの依存関係は、Red Hat Maven リポジトリから取得されます。オフライン デプロイメントは、Red Hat のダウンロード サーバーからダウンロードできる Maven リポジトリのローカル アーカイブを使用することで利用できます。 改善されたクラウド ワークフロー ツール JBoss EAP 8.0 では、 Red Hat OpenShift Container Platform 上で実行するための JBoss EAP 8.0 アプリケーションイメージのプロビジョニングを支援する更新されたツールが導入されています。これらのツールを使用する事で、開発者は、Red Hat OpenShift などの Kubernetes プラットフォーム上での Jakarta EE アプリケーションのデプロイメントを管理および最適化できます。JBoss EAP 8.0 を使用する事で、開発者は OpenShift 上で JBoss EAP をデプロイおよび設定する方法をより詳細に制御できるようになり、生産性が向上し、より合理化された安全な OpenShift イメージが実現します。 主な改善点の 1 つは JBoss EAP Maven プラグイン の導入です。これにより、OpenShift での JBoss EAP の設定がより簡単かつ柔軟になる大幅な改善が行われます。 詳細については、記事: JBoss EAP 8 の OpenShift へのデプロイメントを簡単にする方法 を参照してください。 セキュリティの強化 JBoss EAP 8.0 によって導入されたセキュリティ強化には、OpenID Connect のネイティブサポートを提供する新しい elytron-oidc-client サブシステムが含まれています。JBoss EAP では、RH SSO OIDC アダプターが提供されなくなった代わりに、OIDC を使用して JBoss EAP 8.0 にデプロイされたアプリを保護できるようになりました。 JBoss EAP 8.0 でレガシーセキュリティフレームワーク (picketlink および picketbox) が削除されました。これらは JBoss EAP 7.1 から非推奨になっていました。JBoss EAP 8.0 のセキュリティー強化の詳細についてはリリースノートのセキュリティーセクションを参照してください。 JDKのサポート JBoss EAP 7.4 から JDK 11 のサポートは非推奨になっており、Red Hat は JDK 17 の使用を推奨します。JBoss EAP 8.0 でもJDK 11 は引き続きサポートされていますが、非推奨です。 Java SE 21 のサポートは、JBoss EAP 8 の将来のリリースで計画されています。 移行ツール Red Hat は、お客様が以前のバージョンの JBoss EAP から JBoss EAP 8.0 に、また Java 8 から Java 11 / 17 に移行できるように、更新された Migration Toolkit for Applications (MTA) を提供しています。 MTA のアップデートに加えて、Red Hat はサーバー移行ツールも更新してリリースしています。JBoss EAP 7.x から JBoss EAP 8.0 へのアップグレードに必要なサーバー設定の変更を自動化します。 データソース機能パックのサポート eap-datasources-galleon-pack Galleon 機能パックには、Oracle、Microsoft SQL Server、PostgreSQL のデータベースに必要なドライバーとモジュールを提供するレイヤーが含まれています。 最新のプロビジョニング システムを使用する事で、これらのドライバーを任意の対象環境 (ベアメタルやVM、クラウドなど) に展開して構成できます。 JBoss EAP XP (expansion pack) 5.0 JBoss EAP 8.0 GA リリース後、互換性のある拡張パックとして JBoss EAP XP 5.0 GA と、Jakarta EE 10 に準拠した Eclipse MicroProfile バージョンをリリースする計画があります。 拡張パックを JBoss EAP に追加する事で、開発者はメトリクス、ヘルスエンドポイント、リアクティブメッセージングサポートの追加など、クラウドネイティブ機能を既存の Jakarta EE アプリケーションに追加できるようになります。 JBoss EAP XP 5.0 では暫定的に以下のサポートを追加する予定です。 MP OpenTracing を置き換える MP OpenTelemetry OpenShift / Kubernetes クラウドネイティブのさらなる機能強化: EAP XP テンプレート機能の Helm チャート Micrometer Metrics version 1.9 MicroProfile LRA (長時間実行アクション) - Tech Preview MP Reactive Messagingを使用した AMQ Broker への AMQP Connector のサポート 正確な機能セットについては、JBoss EAP 拡張パック 5.0 のリリース後に リリースノートを参照してください。 まとめ JBoss EAP 8.0 のリリースにより、Red Hat は Jakarta EE アプリケーションのサポートを提供し、更新された Jakarta EE API の使用を可能にし、ターゲット環境に依存しない一貫したデプロイメントアプローチを提供することに継続的に取り組んでいることを示しています。JBoss EAP 8.0 は、レガシーセキュリティフレームワークの削除とネイティブ OpenID コネクトのサポートの導入により、アプリケーションのセキュリティを強化します。 Red Hat は、Jakarta EE アプリケーションを最新化し、クラウドネイティブ環境に移行したいお客様に、Jakarta EE Core Profileのサポートと改善されたクラウド ワークフロー ツールを提供します。

皆さんこんにちは、Red Hat の岡野です。 前回の『Ansible Lightspeed の始め方』に引き続き、AAP 2.4 のもう 1 つの注目の新機能、Event-Driven Ansible (EDA) のお試し方法についてご紹介したいと思います。EDA を利用することにより、IT 運用において発生する様々なイベントを自動的に処理することが可能となります。EDA の概要は、 こちら をご確認ください。 1. EDA と環境概要 Event-Driven Ansible （以下 EDA）は、Ansible Automation Platform 2.4 (AAP 2.4) から新たに追加された GUI サービスを提供するコンポーネントです。AAP 2.3 までは、Ansible Automation Controller (AAC) と Private Automation Hub (PAH) の 2つが GUI サービスを持つコンポーネントとして提供されてていましたが、3 つめのコンポーネントとして、EDA Controller が追加されました。 今回はイベントソースに webhook を利用し、EDA Controller と AAC を連携させた動作を確認してみます。 構成 ・EDA Controller ・Ansible Automation Controller (AAC) ・PostgreSQL (for EDA Controller & AAC) イベントソース ・webhook 2. EDA のインストール方法 EDA のインストールは簡単です。AAC や PAH と同様、Inventory ファイルに EDA の情報を記載するだけで OK です。詳細は以下のドキュメントをご確認ください。 access.redhat.com マニュアルにも構成例とその際の Inventory ファイルが記載されていますが、AAC と EDA Controller を 外部 DB 共有の形でインストールする場合、Inventory ファイルを以下のように記載すればインストールできると思います。 [automationcontroller] aap.example.com [automationedacontroller] eda.example.com [database] db.example.com [all:vars] admin_password='<your_password>' pg_host='db.example.com' pg_port=5432 pg_database='awx' pg_username='awx' pg_password='<your_password>' pg_sslmode='prefer' # set to 'verify-full' for client-side enforced SSL registry_url='registry.redhat.io' registry_username='<registry username>' registry_password='<registry password>' receptor_listener_port=27199 automationedacontroller_admin_password='<your_password>' automationedacontroller_pg_host='db.example.com' automationedacontroller_pg_port=5432 automationedacontroller_pg_database='automationedacontroller' automationedacontroller_pg_username='automationedacontroller' automationedacontroller_pg_password='<your_password>' 3. EDA の使い方 では、実際に EDA Controller と AAC の設定を行い連携動作させてみましょう。これには以下のような作業が必要となります。 3-1. Rulebook の作成と Github 上への配置 今回、Rulebook は以下を使います。すべてのホストからの webhook を5000番ポートで待ち受け、webhook のイベントを受け取ったら、 その中のメッセージを確認し、Ansible is super cool という文字列と一致した場合に、 AAC 内にあらかじめ作成された Demo Job Template というジョブテンプレートを実行するというものです。 --- - name: Listen for events on a webhook hosts: all sources: - name: Wait for Webhook Message ansible.eda.webhook: host: 0.0.0.0 port: 5000 rules: - name: Say Hello condition: event.payload.message == "Ansible is super cool" action: run_job_template: name: Demo Job Template organization: Default Rulebook は、Git 上に配置する必要があります。AAC ではローカルホルダーもサポートされていますが、EDA Controller は現時点では、ローカルパスはサポートされていません。また、Git上での配置場所ですが、各リポジトリの extensions/eda/rulebooks 配下に置く必要があります。今回は、 こちら を利用します。勿論、ご自身の Github 上において利用いただいてもかまいませんが、Rulebook を配置するパスに注意ください。 3-2. EDA → AAC の認証情報の設定 今回、EDA Controller から AAC に接続しジョブテンプレートを稼働させる必要があります。このため何かしらの認証の仕組みが必要になるのですが、EDA Controller と AAC 間の認証にはトークンを使います。作業は簡単です。まずは、 AAC 側 で、『ユーザー』→『admin』→『トークン』と進み、『範囲』で『書き込み』を選択、保存します。保存をクリックするとトークンが表示されますので、クリップボードにコピーします。 次は、コピーした AAC トークンの EDA Controller へのペースト作業です。 EDA Controller で『ユーザー』→『admin』→『コントローラートークン』と進み、『コントローラートークンの作成』をクリック。『トークン』に先ほどAACからコピーしたトークンをペーストして、『コントローラートークンの作成』をクリックします。これで EDA Controller と AAC の認証設定は終了です。 3-3. Rulebook のアクティベーション ここまで準備ができれば、Rulebook のアクティベーションが可能です。まずはプロジェクトで Rulebook が存在する Git の URL を定義します。SCM のURLは、 https://github.com/hiro52/eda_demo/ です。 いよいよルールのアクティベーションです。左ペインで『ルールブックのアクティベーション』を選択し、適当に名前を入力、先ほど作成したプロジェクトを選択し、『ルールブック』で、 eda_test.yml を選択します。決定環境は、Default Decision Environment を選択。 『ルールブックのアクティベーションの作成』をクリックすると、以下のように、ルールブックのアクティベーションステータスが『実行中』となります。 3-4. 動作確認 では、実際に webhook で文字列を投げて動作を確認してみましょう。Firewall などのポートの制限がなく、EDA に接続可能な適当なホスト上（EDA 上でも勿論OK）で以下のコマンドを実行して、EDA Controller に webhook を介してメッセージ Ansible is super cool を送ってみます。 $ curl -H 'Content-Type: application/json' -d "{\"message\": \"Ansible is super cool\"}" <EDA FQDN>:5000 設定に間違いがなければ、AAC 上で、Demo Job Template が起動します。ご確認ください。 5. まとめ いかがでしたでしょうか。Event-Driven Ansible は IT 運用で発生する様々なイベントを自動的に処理することが出来ます。今回は、ソースとして Webhook を直接コマンドでたたくという簡易的動作確認を行いましたが、次回は、実際のアプリケーションをソースとした連携についてデモ動画を交えてご説明したいと思います。

こんにちは、Red Hatでソリューションアーキテクトをしている北村です。 2024/1/17に" Red Hat Developer Hub: 一貫した開発への入り口 "という記事がエントリーされました。こちらの記事に記載がある通り、Red Hatは2024/1/16に Red Hat Developer Hub (以下、RHDH)をGAリリースしました。 rheb.hatenablog.com Red Hat Developer Hubとは RHDHはBackstageをベースとしたInternal Developer Portalであり、Backstageの基本機能に加え、サンプルのGolden Pathや、他のRed Hat製品との連携を強化するプラグイン、ならびにエンタープライズレベルのサポートを提供します。 このRHDHは大きく2つの価値を開発者に提供します。 Golden Path - 開発のベストプラクティスを実際に動作する環境と共に提供 開発者がOpenShift上で開発する上で必要となる様々な情報を一元化 特にGolden PathはRHDHの根幹となる仕組みであり、Platform Engineering TeamはこのGolden Pathをいかに効率よく開発チームに提供できるのかが重要になります。 Golden Path 昨今話題となっているPlatform EngineeringとRHDH(Backstage)の関係性についてはCNDT2023でお話させていただいたので、こちらも是非見ていただければと思います。 これからのPlatform Engineeringを支えるコンテナ×Backstageの真価 Red Hat Developer HubでGolden Pathを作るには？ RHDHはその特性上、開発者の体験にフォーカスした特徴やメリットが前面に出されます。そして、そういった利用者（ここでは開発者）の視点のみで製品を捉え導入しても、残念ながら導入価値を最大化することは困難です。製品導入においては、 開発者に価値を提供するために必要なRHDHの運用方法 を理解しておくことが重要です。 そこで、今回は現時点でのリリースバージョンにおけるRHDHの具体的な設定方法、特に Golden Pathの作成と実行 にフォーカスしたQiita記事をエントリーしました。 これからこういったInternal Developer Portalの導入を検討される方や、今OpenShiftをお使いの方で、少し興味がある方は是非触ってみていただければと思います。 コンテンツ 記事は全部で6つに分かれており、現在5つの記事まで公開しています。こちらは順番に実施するWorkshop形式で記載しています。 qiita.com qiita.com qiita.com qiita.com qiita.com さいごに RHDHはOpenShift Container Platformとは別サブスクリプションとなるため、残念ながら気軽に利用することが難しいですが、RHDHのアップストリームである Janus Project でもRHDHと近しい体験を得ることができます。Qiitaの中ではJanusのインストール方法も記載していますので、まずはこちらで気軽に試してみるところから始めてみてもいいかと思います。 2024年はRed Hat Developer Hubでさらに快適なCloud Native開発を目指してみてはいかがでしょうか？

Red Hat のソリューションアーキテクトの瀬戸です。 この記事はRed Hat Developerのブログ記事、 Red Hat Developer Hub: Your gateway to seamless development | Red Hat Developer を、許可をうけて翻訳したものです。 Red Hat Developer Hub がGAになり一般提供が開始されました。 この記事では、Developer Hub の紹介と共に、Developer Hub が開発プロセスをどのように合理化するかについて説明します。 また、Red Hat Developer Hub を介してプロジェクトで Backstage の機能を活用するための基本的な概念についても詳しく説明します。 Backstage とは何ですか？ ソフトウェア開発の活動的な世界ではチームワークと効率が不可欠です。Backstage プロジェクトは開発チームの負担を軽減し、シンプルにすることを約束します。 Backstage はもともと Spotify によって作成され、オープンソース プロジェクトとして Cloud Native Computing Foundation (CNCF) と共有されました。開発チームの中心のハブとして機能し、ソフトウェア開発ライフサイクルをより管理しやすくし、新しいメンバーのオンボーディングを加速し、リソースを一元化したいプロジェクトで使用されます。Backstageは、利害関係者ができる限り少ない労力で関連情報やリソースにアクセスできる中央リポジトリとして機能することで、膨大な数の開発ツールの管理を支援します。 Backstage が有益である重要な要素には、プラグインによる拡張や、プロジェクト コンポーネントの動的なカタログ、プロジェクト間で共有できるテンプレートを作成する機能などがあります。Backstage は単なるポータルではなく、開発チームがタスクに優先順位を付けて完了する方法を変革するツールです。 Backstage と Red Hat Developer Hub はどのような関係ですか? Backstage は、Spotify が必要なこと、まさに Spotify が望んでいることを実現するために Spotify によって作成されたオープンソース プロジェクトです。サポートや延長されたライフサイクル、認定、テスト、古いバージョンのバグ修正などのエンタープライズ向け機能はありません。 Backstage は社内開発者ポータルを作成するための「フレームワーク」であるにもかかわらず、顧客はポータルをカスタマイズし、開発者がアクセスするツールのさまざまなプラグインを統合する必要があります。そこで Red Hat Developer Hub の出番です。Backstage をRed Hat テクノロジーと統合するためにサポートされているプラ​​グインを備えたエンタープライズグレードの内部開発者ポータルに変換します。 また、私たちはコミュニティに還元し、私たちが面倒なタスクに集中している間、コミュニティがイノベーションに集中できるようにします。 Red Hat Developer Hub (図 1) は、Backstage オープンソース プロジェクトのエンタープライズ グレードのバージョンを提供するための Red Hat がサポートするビルドです。 図 1: The Developer Hub UI Red Hat Developer Hub を理解する: 開発者の天国 ソフトウェア開発の分野では、Red Hat Developer Hub は集中制御装置として機能し、拡張可能なプラグイン アーキテクチャを利用して多様なツールをシームレスに統合します。図 2 に示すように、各プラグインは依存関係の管理から自動ビルドに至るまで開発プロセス内のそれぞれの機能に対応しています。このモジュール式のアプローチによりソフトウェアの開発環境が合理化されます。Developer Hub にはコンテナーイメージに組み込まれたサポートされているプラ​​グインが含まれています。ユーザーは、サードパーティから提供された/自分で構築した独自のプラグインを持ち込んでさらにカスタマイズすることもできます。 図 2: Developer Hub のプラグイン アーキテクチャ この優れた記事 でプラグインについてさらに詳しく調べてください。この記事では、より多くのコンテキストが提供されています。 Red Hat Developer Hub の機能の基礎となっているのは動的なコンポーネントカタログです。このカタログは集中リポジトリとして機能し、プロジェクトのコンポーネントやサービス、依存関係を体系的に整理します。プロジェクトの要素の統合ビューを提供することで、開発者向けのナビゲーション ツールとしても機能します。Red Hat Developer Hub は、体系化されたサマリーを提供することで曖昧さを軽減し、チームの協力を促進します。基本的に、組織化された共有スペースとして機能し、開発者から見ると、プロジェクトで使用している機能へのアクセシビリティと明確性が向上します。 Red Hat Developer Hub の価値提案は、従来のプロジェクト管理の制約を超越する能力に基づいています。Red Hat Developer Hub は、共有可能なツールの統合を通じてコラボレーション環境を促進します。開発チームは、特定の要件に合わせて調整されたツールを自ら組み込んで適用し、プロジェクト全体で共有して、一貫性と効率性を促進できます。Red Hat Developer Hub はプラットフォームとして、単なる促進装置ではありません。プロジェクトの複雑さを解消し、アプリケーション開発への集中的なアプローチを可能にする実用的なソリューションです。 開発チームの効率を促進するツール Red Hat Developer Hub の 2 つの重要なツールにより、すべてのチームメンバーのソフトウェア開発体験がとても良くなります。 ソフトウェアテンプレート コンポーネントカタログ ソフトウェアテンプレート ソフトウェア テンプレートは、簡単に言えば、プロジェクトを構築するための既製の計画です。「整備された道路」と呼ばれることもあります。ソフトウェア テンプレートにはプロジェクトを開始するために必要なすべての設定と構成が含まれています。Red Hat Developer Hub を使用してチームの開発作業を開始するときにはサンプルのテンプレートを使用できます。サンプルのテンプレートは、開発を最適化する構成が最初からセットアップされているため、初期セットアップに費やす時間が短縮されます。プロジェクトのスケジュールが短縮され、新しいプロジェクトに対応する労力が軽減されます。 技術リーダーはソフトウェア テンプレートを使用して、新しいプロジェクトやソフトウェア コンポーネント向けにカスタマイズされた標準構成を開発者に提供できます。これらのテンプレートには、コードのエラーチェック、セキュリティ検証の検証、安全なサプライ チェーンの信頼できるパイプラインの構築のための組織の推奨ツールが含まれる場合があります。 コンポーネントカタログ コンポーネント カタログは、プロジェクト内のすべてのもののマスターリストであり、基本的には、必要なパーツ、サービス、その他の必要なコンポーネントを追跡できる、よく整理された検索可能なインベントリです。開発チームにとって、このカタログは、プロジェクトの依存関係を管理し、相互に依存しているさまざまな要素間の全体的なリスクを軽減するのに特に役立ちます。コンポーネントカタログを使用することで、すべての関係者がこれらの構成要素を表示、整理、管理できるため、スムーズで秩序ある開発プロセスが保証されます。 ここで説明したようなツールは、単純な整備にとどまらず、拡張され、その使用を通じて具体的な利点が組み込まれています。これらはチームワークとコラボレーションに貢献し、誰もが簡単に会社のガイドラインに従って同じ方法でプロジェクトを開始できるようにします。Red Hat Developer Hub をさらに深く知っていくと、これらの機能が重要な味方となり、より効率的に作業し、一貫性を維持し、プロジェクトの全行程を通じてシームレスに共同作業するのに役立つことに気が付くでしょう。---これらすべてが組織の競争上の優位性に貢献します。 Red Hat Developer Hub の使用を開始する方法 Red Hat Developer Hub 1.0 のリリースについて、私たちと同じように皆さんも興奮していただけると嬉しいです。さらに読み進めたり、実践したりする準備ができている場合は、いくつかの方法から始めることができます。 社内向けの開発者ポータルを構築する予定なら、 プラットフォームエンジニア向けの新しい学習パス に従って、Developer Sandbox for Red Hat OpenShift で独自のバージョンを無料で立ち上げ、実行することができます。 Joshua Wood、Hans-Peter Grahsl、Ryan Jarvinen 著の近日発売予定の電子書籍『 Developer Portals: Prepare to Perform with Red Hat Developer Hub 』から 3 つのプレビュー チャプターをダウンロードしてください。 進んで自分自身でデプロイする準備ができていますか？ access.redhat.com から評価版を入手し、独自のクラスターで起動します。コンテキストと詳細情報については、必ず ドキュメント を確認してください。 Red Hat Developer Hub と共に飛び込んで探索し、あなたのプロジェクトの潜在的な可能性を解き放ちましょう。

皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。2024 年が始まりましたね。今年もたくさんの Ansible Automation Platform 関連の情報をお届けできればと考えています。是非お付き合いください。 さて、昨年末 こちら で予告させていただいた通り、まずは、Ansible Lightspeed のお試し方法についてご紹介したいと思います。実は昨年の12月にパートナー様向けに Ansible Automation Platform 最新情報に関するセミナーを開催したのですが、その際も Ansible Lightspeed は大変引き合いが強く、 『すぐに試したいのでやり方教えてください！！』 という声をたくさんいただきましたので、その声にお応えすべく。 ただし、一点、初めにお断りしておきます。 こちら に記載の通り、評価環境構築に関してはよりスマートな方法が2024年初頭（ということなのでもうすぐ）提供されるとのことです。お急ぎでない場合はそちらをお待ちいただくのも良いかもしれません。 ただ、私のところにも社内外から構築方法について多くの問い合わせをいただいているのと、また、そもそもIBM クラウド独特の言葉の意味がわからず、私自身結構苦労しましたので急ぎ確認したい方が同じ轍を踏まないために。（＾＾） では早速。 Ansible Lightspeed の環境構築方法 評価版の利用 製品版の Ansible Lightspeed を利用する場合、以下2つを購入する必要があります。このそれぞれに評価版（無償枠）が提供されていますのでこちらを利用します。 Ansible Automation Platform (AAP) 以下から評価版のサブスクリプションを入手します。 www.redhat.com IBM watsonx Code Assistant for Red Hat Ansible Lightspeed IBM クラウドに登録し、無償利用枠＄200を利用します cloud.ibm.com ※ IBM クラウドの無償利用枠は $200までです。Lightspeed の場合 1か月分となりますので、テスト利用が終了したらデータの削除等対応ください。放置すると請求が発生します。また、アカウントの削除は AWS などと異なり、ケースによる対応が必要で結構手間がかかります。アカウント新規作成の際は、その点ご了承の上ご利用ください。 もちろん、既にAAPのサブスクリプションを所有している方、IBM クラウドの既存ユーザーの方はそちらを利用することも可能です。今回は入手した評価版/無償枠を利用して環境構築を行っていきます。 1. IBM クラウドでの作業 1-1. サービス ID と watsonx Code Assistant (WCA) キーの作成 まずは、Ansible Lightspeed が WCA にアクセスするための ID とアクセスキーを作成します。 こちら （IBM Cloud内）から、名前（ここでは "watsonx Code Assistant user"）を入力してサービス ID を作成します。 次に、作成した ID 内のタブ『API キー』を開き、APIキーの名前を入力し作成をクリックすると、APIキーのコピーとダウンロードを促す画面が表示されます。この画面は閉じると2度とキーの取得ができませんので、クリップボードへのコピー、およびダウンロードしておきます。コピーした APIキーは手順 2-1 の登録の際に利用します。 1-2. watsonx Code Assistant for Ansible Lightspeed モデルのデプロイメント 　Ansible Lightspeed で利用する AI モデルをデプロイします。 こちら から、『watsonx Code Assistant』を検索し、『IBM watsonx Code Assistant』をクリックします。以下のスクリーンキャプチャーを参考に、『IBM watsonx Code Assistant for Red Hat Ansible Lightspeed Essentials』を選択し、同意にチェックの上作成をクリック。遷移した画面で『10 user』となっていることを確認し 『Launch watson Code Assistant』 をクリックします。 しばらくすると以下のような画面が表示されます。こちらを順に実行していきます。右にある矢印は各設定を行うためのリンクです。一番上の手順は既に先の手順で設定が完了しているサービスID及び API キーの作成です。構築済みですので一度矢印をクリックし、何もせずこちらの画面に戻ります。 次にデプロイメント・スペースの作成の矢印をクリックします。デプロイメントスペース作成画面で『名前』を入力し、『コードアシスタントサービス』をプルダウンで選択した上で、『作成』をクリック。完了画面が出て作成が完了します。 デプロイメント・スペースの作成が完了すると、ベース・モデル ID が割り振られます。このベース・モデルIDは、手順2で利用します。以下赤枠の中に値が入力されていることを確認の上、『サービスIDをスペースコラボレーターとして追加する』手順に進みます。矢印をクリックします。 『watsonx Code Assistant user』 にチェックを入れます。 これで IBM クラウド側の設定は完了です。以下参考に、矢印をクリックして手順 2 Ansible Lightspeed 管理ポータルでの設定に進みます。 2. Ansible Lightspeed 管理ポータルでの作業 2-1. WCA キーとベース・モデルの ID の登録 Ansible Lightspeed 管理ポータルが表示されていると思います。もし表示されてない場合は、 こちら をクリックください。IBM Cloud API Key と Model ID を入力する画面となりますので、手順 1-1、1-2でそれぞれ作成した WCA キーとベース・モデルID をそれぞれコピー＆ペーストします。 2-2. VSCode Extension のインストール ※Ansible Lightspeed は VS Code の拡張機能として動作します。まだ VS Code をインストールしていない場合はインストールの上、以下実施ください。逆に、既に VS Code や Extension をインストールしている場合は、バージョンに注意してください。Ansible Lightspeed でサポートされるバージョンは以下の通りです。 ・VS Code version 1.70.1 or later ・Ansible extension for VS Code version 2.8 or later VS Code の Ansible Exension をインストールします。 さらに、以下参考に、拡張機能で、Lightspeed に関する設定（2か所）にチェックを入れて Lightspeed を有効化。さらに Ansible アイコンをクリックしてConnect をクリックします。 この後、4つほど確認画面が表示されますが、『Allow』→『Open』→『Authorize』→『Open』など、クリックして進めてください。 ブラウザが立ち上がって、『Red Hat Ansible Lightspeed with IBM watsonx Code Assistant』の画面が表示されればこの手順は完了です。 3.Hybrid Cloud Console での作業 Ansible Lightspeed を利用するには、AAP のサブスクリプションが必要になります。この作業は AAP のサブスクリプションを持つユーザーに対して Ansible Lightspeed を利用する権限（シートライセンス）を与える設定です。 こちら から Hybrid Cloud Console 上で、Assign users をクリックの上、必要なユーザーを登録します。 再度 こちら をクリックしてみてください。ログイン後に『licensed user』と表記されていればこの設定が完了しています。 Ansible Lightspeed で Playbook を作成！ 早速簡単なPlaybook を作成してみましょう。VS Code 上で、新しいファイルを拡張子 『yaml』 で作成・保存します。実は拡張子は何でも良いのですが、関連付けもできるので後々便利です。下の『yaml』をクリック、さらに、言語モードとして『Ansible』を選択します（今後のため関連付けを行っておくと便利です）。 Extension に関するエラーが出るかもしれませんが、下に 『Lightspeed (licenced)』 と出ていれば気にしなくても大丈夫です。エラーが気になるようであれば、Ansible-lint 関連や、Ansible › Validation: Enabled のチェックを外すとエラーは出なくなると思います。 では Lightspeed に Task を作成してもらいましょう。試しに以下のように書いて、『・・・即座に開く』の後ろで改行してみてください。複数にまたがる推奨のタスクが出てくれば成功です。確定は『Tab』キー、拒否は『Esc』キーです。 『#』と『&』が意味を持ちますので重要です。 --- - name: my first lightsppd yml hosts: all tasks: # 最新バージョンの httpd をインストール & httpd サービスの有効化と開始 & 80/443 ポートをFireall で恒久的に即座に開く 推奨がどこから出てきたのか、その出所は、右上のパネルの切り替えをクリックし、出てきたウィンドウで 『ANSIBLE』をクリックすることで確認することが出来ます。 まとめ いかがでしたでしょうか？ 生成 AI の利用については色々と議論が始まったばかりですが、その課題の一つが、 『得られたデータがどこから来たのか？』 ということだと思います。先日も New York Times が OpenAI に対し著作権侵害...などという記事が出ていて、個人的に、ありがちな事だなぁと感じていました。 この点、Ansible Lightspeed で利用される『watsonx Code Assistant for Ansible Lightspeed』は、 Ansible Galaxy コンテンツとその他のオープン・データ・ソースおよび、Red HatとIBMの自動化に関する専門知識が注入された、Ansible固有の「トレーニング」データ・セットとなっているため、生成されたコードの質が高く、さらに、上記の通り、生成されたコードがどこから来たのか、そのソースを確認することもできることから、コードの脆弱性や不意のライセンス違反などを気にすることなく、安心して利用することが可能となっています。 Ansible Lightspeed は今後も機能拡張を続けていきます。今回の機能提供はその第一弾、『ほんのさわりの部分』と考えていただいても良いと思います。Ansible Lightspeed に関するさらに詳細なご説明をご希望の方、また、機能拡張のロードマップを教えてほしいなどございましたら弊社担当までお問い合わせください。 関連ドキュメントのリンク access.redhat.com cloud.ibm.com access.redhat.com

Podmanイン・アクション Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。今回は私も執筆に参加した書籍「Podmanイン・アクション」について紹介いたします。 （2024年1月16日、更新）インフラエンジニアBooksのアーカイブURLと資料のリンクを追記しました。 Podmanイン・アクション 2023年9月に翻訳本である「Podmanイン・アクション」が発売されました。Podmanイン・アクションの原著は以前に紹介した「Podman in Action」です。 rheb.hatenablog.com Podmanイン・アクションはレッドハット株式会社の有志メンバーが集まって翻訳を行い、またそのチームメンバーもソリューションアーキテクト、コンサルタント、サポート、テクニカルトランスレーターと、さまざまな構成となっています。出版社の担当者を始め多くの方の協力を得ることで、原著のリリースから比較的短期間で翻訳本のリリースを行うことができました。書籍は B5変形版・376ページの技術書で、Part1からPart4までの4部10章+Appendixからなる構成です。実際に読んでみるとルートレスやセキュリティに関する部分は高密度で書かれており、かなり読み応えのある内容となっています。現時点でのPodmanに関する決定版書籍として十分にご活用いただけます。 （出版社）秀和システムのサイト： www.shuwasystem.co.jp 次世代コンテナエンジンの基礎からセキュリティまで徹底解説 本のサブタイトルにもあるように「次世代コンテナエンジン」というキーワードがこの本の大きな特徴になっています。Linuxコンテナ（以下、コンテナ）についてはすでに多くのDockerに関する書籍が出版されています。そのようなある意味「情報過多」になっている状況でこの本が存在する意義とは、Dockerに対する新しいコンテナツール（コンテナエンジン）としてのPodmanの優位性があるからに他なりません。広く使われるDockerに対するPodmanの新しさとは何か、Podmanが生まれることになった背景やその思想とは何かといったことを知ることができ、単なるコンテナを実行するコマンドや技術解説に留まららない内容となっています。 コンテナ技術そのものを深く掘り下げていくとLinux（Linuxカーネル）のセキュリティ機能を利用していることを知ることになります。コンテナを使っていると、時にはそのセキュリティ機能が働きそれを回避するために --privileged オプションを付けて実行したくなることもあるでしょう。その時に重要なのはなぜコンテナの仕組みがそのようになっているのだろうか？と考え、思考を止めないことです。多くのDockerの解説本ではこのようなコンテナセキュリティの根本の部分に関して明確に書かれておらず、曖昧な知識のままになっている人も多いのではないでしょうか。Podmanの新しさとはこうしたDockerでは当たり前のDockerデーモンのアーキテクチャーやデフォルトではルート権限でDockerデーモンが実行されるといったセキュリティ面への課題解決を目指したところからアーキテクチャーが構築されているという点にもあります。その他にも、Dockerで実行するコンテナはDockerデーモンの子プロセスとして実行されるというアーキテクチャーとの違いや、コンテナイメージの短縮名がdocker.ioにハードコードされている問題などにもPodmanでは対処する機能や仕組みがあります。 つまり、DockerユーザーにとってPodmanについて学ぶことはコンテナへの理解をより一歩深く前進させることに他なりません。Dockerユーザーの方もこれからコンテナを始める初心者の方も是非一度、本書を手に取って内容をお確かめください。 （宣伝）インフラエンジニアBooks 30分でわかる「Podmanイン・アクション」 来週1月15日に株式会社エーピーコミュニケーションズ様主催のオンラインイベント「 インフラエンジニアBooks 」に登壇して本書「Podmanイン・アクション」の解説を行います。本記事では紹介しきれなかった実際の中身の見どころなどを紹介いたします。参加者の中から抽選で書籍プレゼントもありますので、ぜひ奮ってイベントにご参加ください！ 登録は下記connpassのページからお願いいたします。 infra-eng-books.connpass.com アーカイブ： https://youtu.be/ufTrB576A1U 資料： https://speakerdeck.com/tnk4on/infra-engineer-books-podman-in-action

本ブログ記事は、OpenShift Advent Calendar 2023のエントリーです。(年を越してしまいましたが...) OpenShift v4.14のリリースノートに、「 Open Virtual Network (OVN) 最適化によるスケーリングと安定性の向上 」という項目があり、下記のような記述になっています。 OpenShift Container Platform 4.14 では、Open Virtual Network Kubernetes (OVN-K) の最適化が導入されており、内部アーキテクチャーが変更されて運用遅延が短縮され、ネットワーキングコントロールプレーンのスケールとパフォーマンスに対する障壁が取り除かれています。ネットワークフローデータは、コントロールプレーンに情報を集中させるのではなく、クラスターノードにローカライズされるようになりました。これにより、操作遅延が短縮され、ワーカーノードとコントロールノード間のクラスター全体のトラフィックが削減されます。その結果、ノードが追加されるたびにネットワーク容量が追加され、大規模なクラスターが最適化されるため、クラスターネットワークのノード数は線形にスケールします。ネットワークフローはすべてのノードでローカライズされるため、コントロールプレーンノードの RAFT リーダー選出は必要なくなり、不安定性の主な原因が除去されました。ローカライズされたネットワークフローデータのさらなる利点は、ネットワーク上のノード損失の影響が障害が発生したノードに限定され、クラスターの残りのネットワークには影響を及ぼさないため、クラスターの障害シナリオに対する回復力が高まることです。詳細は、OVN-Kubernetes アーキテクチャー を参照してください。 この中身について簡単にご紹介します。 ...とその前に。本題に入る前に書いておきたいことがありまして、それはOpenShift/Kubernetes (もしくはCNIプラグイン) の観点からは、OVNK LegacyもOVNK Interconnectも同じように見える、という点です。したがいまして、OpenShift v4.13 (OVNK Legacy) からv4.14 (OVNK Interconnect) にアップグレードした場合でも、利用者(Pod/Service/Network Policy等のk8s API)の観点からは全く同じ使い方ができます。 OVN-Kubernetes、OVN、OVN Interconnect、OVN-Kubernetes with OVN Interconnect まずはじめにOVN周りの用語を整理したいと思います。 OVN (Open Virtual Network) : Software Defined Networkingを実現するOSSのひとつ。主にOpen vSwitchコミュニティのメンバーで開発されています。さまざまなCMS (Cloud Management System、仮想基盤やコンテナ基盤のコントローラと思ってください) と連携することを想定しています。具体的には、OpenStack、oVirt、Docker、Kubernetes等から使用することができます。 OVN Interconnect : OVNのクラスター間をGeneveトンネルで結ぶことで、複数のOVNクラスターを接続するOVNの機能。OVN-ICと略すこともあります OVN-Kubernetes : Kubernetes上でOVNを使ってPod/Serviceの通信を行うためのCNIプラグイン。OpenShiftでは、OVN-Kubernetesはv4.2からTech Previewとして導入され、v4.6から正式サポートのCNIプラグインとなりました。v4.12以降はOVN-KubernetesがデフォルトのCNIプラグインです。OVNK、OVN-Kなどと略すこともあります OVN-Kubernetes with OVN Interconnect: OVN-Kubernetesの中でOVN Interconnectを使う構成のこと。OVNK-ICと略すこともあります 冒頭のOpenShift v4.14のリリースノートの文言は、OpenShiftでOVN-Kubernetesを使う際の構成が、従来のOVN-KubernetesからOVN-Kubernetes with OVN Interconnectに変わった、ということを意味しているのでした。 従来のOVN-Kubernetesの構成 OVNを構成するコンポーネントは、図1のようになっています。 図1: OVNの構成要素 従来のOVN-Kubernetes (OVNK Legacy) では図2のように、OVNを構成するコンポーネントのうち、コントロールプレーンを構成するNorthboud DB (nbdb)、northd、Southbound DB (sbdb) がcontrol planeノードで ovnkube-master というPodとして稼働し、データプレーンとなるovn-controllerおよびovs-vswitchd、ovsdb-serverが全ノードで稼働します。 図2: OVN-Kubernetes Legacyのコンポーネント OVN-Kubernetesのおおまかな動きとしては、OVNのオーバーレイ論理ネットワークに変化が起きた場合 (例えばPodを新たにデプロイした場合)、ovnkube-masterがk8sのAPIリソースの更新を検知してNorthbound DB (nbdb) にオーバーレイ論理ネットワークの更新を書き込みます。その後northdがそれを検知して論理フローに変換してSouthbound DB (sbdb) に書き込み、ovn-controllerがそれを検知して自ノードのOVSブリッジに必要なOpenFlowのフローを投入します。何らかのイベントによってノードのポート状態が変化した場合 (例えばPodが死んだ場合) は逆に、該当Podが稼働するノードのovn-controllerがそれを検知してSouthbound DBに書き込み、northdがそれを検知してNorthbound DBを更新し、最後にovnkube-masterがk8sのAPIサーバ経由でetcdにその情報を記録します。 nbdb, sbdbは各control planeノードで稼働するOVSDBで、OVNK Legacyではそれぞれが冗長化のためにcontrol planeノード間でRAFTクラスターを構成します。また各ノードのovn-controllerはcontrol planeノードのsbdbにOVSDB Management Protocolで接続します。このためOVNK Legacyには、ノード数が増えるとその分sbdbに対する接続数が増え、またPodやServiceが増えるとその分「control planeノードのsbdb」↔「各ノードのovn-controller」の通信が増える、という課題がありました。 OVN-Kubernetes with OVN Interconnectionの構成 OVN Interconnectは元々、Kubernetesとは関係なく、複数のOVNクラスターを接続するために考案されたアーキテクチャです。これをOVN-Kubernetesに応用したものが、OVNK Interconnectです。OVNK Interconnectの構成は図3のようになります。 図3: OVN-Kubernetes Legacyのコンポーネント OVNK Legacyでは、OpenShift/Kubernetesクラスター1つに対してOVNクラスターを1つデプロイしていましたが、OVNK Interconnectでは、各ノードごとに1つのOVNスタックを配置します。具体的には、OVNのコントロールプレーンとなるnbdb, sbdb, northdといったコンテナが、control planeノードではなく、全ノード上の ovnkube-node Pod内で稼働します。OVNK Legacyでは、nbdbおよびsbdbはcontrol planeノード上で稼働し、OpenShift/Kubernetesクラスター全体のオーバーレイ論理ネットワークの情報を格納していましたが、OVNK Interconnectでは各ノードに分散し、自ノードの論理ネットワークの情報だけを持ちます。また、OVNK Legacyのnbdb, sbdbは3台のcontrol planeノード間でRAFTクラスターを構成して冗長化しましたが、OVNK Interconnectではシングル構成で冗長化はしません。結果としてOVNK Interconnectでは、OVSDB Management Protocolによる通信は完全にノード内に閉じる形になります。 control planeで稼働するPod ( ovnkube-cluster-manager ) はクラスター全体の情報 (ノードごとのサブネット、Egress IP等) を管理し、nbdbやsbdbにはアクセスしません (情報は主にノードのannotationに記録します)。 OVNK Interconnectにすることで期待できること OVN-KubernetesをOVN Interconnect化し、各ノードで独立したOVNスタックを持つことで、下記のようなメリットを享受することができます。 OVN的な処理のレイテンシーの改善 (Legacyでは論理ネットワーク全体のDB更新が必要だったのに対して、ICでは各ノードが自ノード上の論理ネットワークのみを処理するため) スケーラビリティの改善 (Legacyではnbdb, sbdb, northdがボトルネックになっていたが、ICではこれらを各ノードに分散したため) control planeノードの負荷の軽減 (OVNのコントロールプレーンコンポーネントであるnbdb, sbdb, northdの負荷が各ノードに分散するため) ノード間通信のシンプル化 (ICではOVSDB Management Protocolによるノード間通信が必要ないため) TLS証明書管理の軽減 (Legacyではノード間のOVSDB Management Protocolで使用するTLS証明書を管理する必要があったのに対して、ICではUNIXドメイン通信で済むため) OVSDBのシングル構成化による運用負荷の軽減 (ICではRAFTによるクラスター化を行わないため) このメリットは、特にHosted Control Planeで効いてきます。Hosted Control Planeとは ひとつのManagement cluster: 各Hosted clusterのcontrol planeの機能をPodとして収容するOpenShiftクラスター 複数のHosted cluster: workerノードのみのOpenShiftクラスター という形で複数クラスターを管理する方式です。OVNK Interconnectにすることで、control planeのコンポーネントが小さくなり、より多くのHosted clusterをManagement clusterでホストできるようになります。 AWSでのマネージドサービスであるRed Hat OpenShift Service on AWS (ROSA)では、Hosted clusterとしてOpenShiftクラスターをデプロイすることが可能になっています(現時点ではリージョンによってはまだ使用できませんが)。ROSAのHosted Control Planeでは、Management clusterはRed Hat SREが管理するので、control planeのコンポーネントがスリム化するのはとてもうれしいのでした。 ROSA with HCPについては、こちらの記事をご参照ください。 rheb.hatenablog.com 一方で、OVNK Interconnectのデメリットとして下記が考えられます。 ログの増加 (各ノードでOVNスタックを持つため) 各ノードのCPU/メモリ負荷の増加 (各ノードでnbdb, sbdb, northdを動かすため) 論理ネットワークのパケットトレースの複雑化 (ovnkube-trace等のツールを改良中) とはいえ、workerノードのリソースがかつかつな場合以外は、基本的にはそれほど大きな影響はないかと思います。 論理ネットワーク OVNで作る仮想的な論理ネットワークの構成も、OVNK LegacyとOVNK Interconnectで少し異なります。OVNK Legacyの場合は 図4 のようなトポロジーです。ノード間を接続する論理ルーター ovn_cluster_router と論理スイッチ join が各ノードに分散します。 図4: OVN-Kubernetesのロジカルネットワーク(v4.13) 一方、OVNK Interconnectの場合は 図5 のようになります。 ovn_cluster_router および join スイッチは分散せずに各ノード内に配置します。その代わりに、ノード間を接続する transit_switch がノードに分散する形で作られます。 図5: OVN-Kubernetesのロジカルネットワーク(v4.14) 最後に 冒頭にも書きましたが、細かい内部の話は、ユーザーの立場からはぶっちゃけあんまり気にしなくても大丈夫です。今までと同じようにご利用いただければと思います。 参考文献 ovscon2019: Multi-tenant Inter-DC tunneling with OVN (Han Zhou, eBay) ( slides , video ) (OVN Interconnectについての最初の講演です。OVN-Kubernetesの話はありません) ovscon2022: Using OVN Interconnect for scaling (OVN) Kubernetes deployments ( slides , video ) (OVNK-ICについての講演です。開発中の話なので、Podの構成等が今と若干異なる部分があります) blog: How the new OVN Kubernetes architecture helps with scaling OpenShift (OVNK-ICについての最新ブログ記事) doc: 25.2.7. OVN-Kubernetes の論理アーキテクチャー (公式ドキュメント) OpenShift.Run 2023: OVN-Kubernetes Deep Dive - OCP v4.12 (OVNK Legacyについての日本語講演資料) 余談 通常OVN Interconnectを構成するには、複数のOVNデプロイメントを管理し、クラスター間の接続情報を管理するための「ovn-ic (OVN Interconnection controller)」というデーモン(OVN-ICと紛らわしいですが、だいたい文脈でわかります)およびIC_NB/IC_SBというデータベースが必要です。しかし、OVN-Kubernetes with OVN Interconnectの場合は、全体の構成はKubernetesのetcdに情報があり、ovnkube-cluster-managerがovn-ic的な役割を果たすため、ovn-icおよびIC_NB/IC_SBは存在しません。

みなさんメリークリスマス! Red Hatのさいとう( @saito_hideki )です。 この記事は､ Ansible Advent Calendar / Red Hat Advent Calendar の2023年最終日の記事です。 ここ数年、Ansible Advent Calendar/Red Hat Adivent Calendarでは、最終日に翌年のAnsibleプロジェクトに関連する動向を予想したお話を書いてきました。今回は、Event Driven Ansibleのダッシュボードを含めたコントロールプレーンを提供するためのアップストリームプロジェクトである EDA Server を取り上げてます。 具体的には、2024年のEDA Serverを体験するために、現在の開発版のインストールと起動方法についてご紹介しようと思います。今年も文字多めです。 2023年に公開された新技術 2023年のトピックは、 @akira6592 さんが、Ansible Advent Calendar 2023 12月24日の記事( [Ansible] 2023年の Ansible 関連リリースや動向まとめ )としてまとめてくれています(感謝!) そこで言及されている通り、2023年には新たに以下の２つのプロダクトがリリースされました。 Event-Driven-Ansible -> 以降EDA Ansible Lightspeed -> 以降 Lightspeed これらについては、ダウンストリームのRed Hat Ansible Automation Platform 2.4の新機能として、 Ansible Automation Platform 2.4 注目の新機能紹介 でまとめられていますので、興味のある方はご一読ください。 EDAとLightspeedは、これまでにない新しい試みでした。2024年は、これらのプロジェクトの機能追加とバグフィックスを中心として「改修と改善」がメイントピックになりそうで、現時点での予想として来年はびっくりするような飛び道具は、おそらくなしです。 EDA Serverの2024年を覗く 今回の開発環境は以下のスペックのFedora39のVirtualMachineです。 OS: Fedora39(x86_64) CPU: 2 Memory: 4096 HDD: 20GB 以降の手順は、基本的には公式ドキュメント Development environment setup に従ってFedora39にEDA Serverをインストールすることを想定して書いています。 poetry.log でガッチリとPythonライブラリのバージョンが固定されているので、開発環境のディストリビューションやバージョンを外すとちょっと厄介です。注意しましょう。 EDA Serverのビルドに必要となるパッケージ群をインストールします。今回は、プラットフォームにFedora39を利用し、コンテナエンジンとしてPodmanを利用します。 $ sudo dnf install libffi-devel libxml2-devel xmlsec1-devel xmlsec1-openssl-devel libtool-ltdl-devel openldap-devel python3.11 python3.11-devel podman podman.socketサービスをrootlessで起動します。サービスのステータスとAPIアクセスを念のため確認しておきましょう。 $ systemctl --user enable --now podman.socket Created symlink /home/hsaito/.config/systemd/user/sockets.target.wants/podman.socket → /usr/lib/systemd/user/podman.socket. $ systemctl --user status podman.socket ● podman.socket - Podman API Socket Loaded: loaded (/usr/lib/systemd/user/podman.socket; enabled; preset: disabled) Active: active (listening) since Sun 2023-12-24 21:45:10 JST; 22s ago Triggers: ● podman.service Docs: man:podman-system-service(1) Listen: /run/user/1000/podman/podman.sock (Stream) CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/podman.socket $ curl -s --unix-socket /run/user/1000/podman/podman.sock http://d/v3.0.0/libpod/info | jq .version { "APIVersion": "4.8.1", "Version": "4.8.1", "GoVersion": "go1.21.4", "GitCommit": "", "BuiltTime": "Tue Dec 5 21:00:50 2023", "Built": 1701777650, "OsArch": "linux/amd64", "Os": "linux" } docker-composeをインストールします。Ansibleのさまざまなプロジェクト(Ansible Core/AWX/Galaxy NG/EDA Server等々)の開発環境の構築手法は、プロジェクト毎にバラバラでまったく統一されていませんが、「コンテナをビルドしてdocker-composeでサービスとして起動する」という方法が主流です。 $ mkdir ~/.local/bin $ curl -L https://github.com/docker/compose/releases/download/v2.23.3/docker-compose-linux-x86_64 > ~/.local/bin/docker-compose $ chmod +x ~/.local/bin/docker $ docker-compose --version Docker Compose version v2.23.3 EDA Serverの開発環境用にvirtualenvを作成します。Fedora39のデフォルトPythonインタプリタは3.12ですが、EDA Serverの開発環境は、現時点(2023年12月25日)では、 Python3.9から3.11までを想定している ため、ここでは事前にインストールしておいたPython.3.11を利用しています。 $ python3.11 -m venv ~/work/venv $ source ~/work/venv/bin/activate (venv) pip install -U pip EDA Serverは、Djangoのアプリケーションです。起動に必要とするPythonライブラリ群はpoetryとre-commitを利用してインストールします。そのまえに、これらのツールをpipでインストールしておきましょう。 (venv)$ pip install pre-commit (venv)$ pip install poetry docker-composeや、EDA Serverの管理コマンドのラッパーとして振る舞ってくれるTaskfile(taskコマンド)をインストールします。taskコマンドがラップしてくれる機能は こちら から確認できます。 Taskfileやpoetryは、他のプロジェクトの開発環境構築では、これまで使われてこなかった仕組みなので、ちょっと新鮮です。 (venv)$ sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d -b ~/.local/bin (venv)$ task --version Task version: v3.33.1 (h1:JJSRANHH7RQrr5Z2CTvSnTH7iWlfBlKV2W2O0JiZoLk=) ソースコードをチェックアウトし､taskコマンドでビルドに必要となるモジュール群をインストールします。 (venv)$ git clone https://github.com/ansible/eda-server.git/ (venv)$ cd eda-server (venv)$ task dev:init task: [dev:init] poetry install -E dev Installing dependencies from lock file Package operations: 109 installs, 11 updates, 0 removals • Downgrading certifi (2023.11.17 -> 2023.7.22): Pending... • Downgrading cffi (1.16.0 -> 1.15.1): Pending... • Downgrading charset-normalizer (3.3.2 -> 3.1.0): Pending... • Downgrading idna (3.6 -> 3.4): Pending... • Installing pyasn1 (0.5.0): Pending... • Downgrading urllib3 (2.1.0 -> 1.26.15): Pending... [...] Installing the current project: aap-eda (0.1.0) task: [dev:init] pre-commit install pre-commit installed at .git/hooks/pre-commit 続いて、taskコマンドからdockerコンテナをビルドします。ここではdocker-composeを利用するので、環境変数DOCKER_HOSTに、podman.serviceのsocketファイルを指定してから実行します。DOCKER_HOSTの設定は、必要に応じて.bashrcなどのrcファイルに追加しておいてください。 (venv)$ podman info -f '{{.Host.RemoteSocket.Path}}' /run/user/1000/podman/podman.sock (venv)$ export DOCKER_HOST="unix://`podman info -f '{{.Host.RemoteSocket.Path}}'`" (venv)$ echo $DOCKER_HOST DOCKER_HOST=unix:///run/user/1000/podman/podman.sock (venv)$ docker-compose ls NAME STATUS CONFIG FILES (venv)$ task docker:build task: [docker] docker-compose -p eda -f tools/docker/docker-compose-dev.yaml build [+] Building 5.1s (0/1) docker-container:default => [eda-api internal] booting buildkit 5.1s => => pulling image moby/buildkit:buildx-stable-1 5.1s [...] => => exporting layers 14.3s => => exporting manifest sha256:4051e5517b307516aa49095b0b1aa70647fa0395ca993e15b4a36bafdff52d78 0.1s => => exporting config sha256:c91c61d366dc2b91c0b0e6aa7d9814c0e9ac37e53ae7d242c1fbf5aaa7c1d863 0.1s => => sending tarball 14.1s => [eda-api] importing to docker (venv)$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/aap-eda latest c91c61d366dc 2 minutes ago 1 GB docker.io/moby/buildkit buildx-stable-1 be698b50dea4 3 weeks ago 173 MB 環境変数EDA_CONTROLLERにAutomation controllerやAWXのURLを指定し、taskコマンドでEDA Serverを起動します。 task docker:up は docker-compose up -d を実行します (venv)$ export EDA_CONTROLLER_URL=https://<IPADDRESS> (venv)$ task docker:up [...] [+] Running 14/14 ✔ Network eda_default Created 0.0s ✔ Volume "eda_podman_data" Created 0.1s ✔ Volume "eda_postgres_data" Created 0.1s ✔ Container eda-redis-1 Healthy 1.0s ✔ Container eda-podman-pre-setup-1 Started 1.0s ✔ Container eda-postgres-1 Healthy 1.5s ✔ Container eda-podman-1 Started 0.6s ✔ Container eda-eda-scheduler-1 Started 0.7s ✔ Container eda-eda-api-1 Healthy 0.4s ✔ Container eda-eda-activation-worker-2 Started 0.4s ✔ Container eda-eda-ui-1 Started 0.8s ✔ Container eda-eda-ws-1 Started 0.8s ✔ Container eda-eda-default-worker-1 Started 0.7s ✔ Container eda-eda-activation-worker-1 Started 0.4s 最後に、taskコマンドから管理ユーザアカウント(admin)のパスワードを設定しましょう。実際には aap-eda-manage changepassword を実行しています。 (venv)$ $ task manage -- changepassword admin Changing password for user 'admin' Password: changeme2024 Password (again): changeme2024 Password changed successfully for user 'admin' EDA Serverのフロントエンドは、Port:8443でListenします。firewalldでPort:8443を許可しておきましょう。 (venv)$ sudo firewall-cmd --zone=public --permanent --add-port=8443/tcp success (venv)$ sudo firewall-cmd --reload success ダッシュボードにアクセスし、adminアカウントでログインしてみましょう。 /eda/ を忘れずに。 https://EDA_SERVER_URL:8443/eda/ ログイン画面が表示され、これで eda-serverリポジトリ のmainブランチからビルドしたEDA Serverにログインできます。 起動したコンテナの確認 taskコマンドで起動したコンテナには、ビルド元になったソースコードのパスがマウントされています。必要に応じて自身でソースコードを改変し、taskコマンドでdown->upすれば、改修内容もチェックできますね。 (venv)$ podman inspect eda-eda-api-1 [...] "Mounts": [ { "Type": "bind", "Source": "/home/hsaito/work/eda-server", "Destination": "/app/src", "Driver": "", "Mode": "", "Options": [ "rbind" ], "RW": true, "Propagation": "rprivate" } ], [...] サービスの停止と起動方法は以下の通りです。 (venv)$ task docker:down (venv)$ task docker:up まとめ この記事では、EDA Serverをmainブランチからビルドすることで、コントロールプレーンの最新のダッシュボードを含めた機能を体験する方法をご紹介しました。2024年は「改修と改善」の年になるでしょう。個人的には2023年は何だか忙しく、アップストリームに貢献することがほとんできない年でした。今回の記事に書いた開発版の構築手法を活用しながら、2024年はもう少しアップストリームに貢献したいなと考えてます。みなさんも是非 ;) それではみなさん、2024年もHappy Automation! 参考情報 [Ansible] 2023年の Ansible 関連リリースや動向まとめ Ansible Automation Platform 2.4 注目の新機能紹介 【Podman v3】ルートレスモードでdocker-composeを実行する Development environment setup

こんにちは。Red Hat にて Ansible Automation Platform のテクニカルサポートをしている呉です。 ※暖房が効かなくなってしまい、極寒の家で毛布被って体育座りしながら書いてますので、以下、暖い心で読んでいただけましたら幸いです。;) 今回は、Ansible モジュールの小ネタの一つとして cisco.iosxr.iosxr_config モジュール( https://docs.ansible.com/ansible/latest/collections/cisco/iosxr/iosxr_config_module.html )の match に与える事のできる以下のオプションのそれぞれの違いについて紹介したいと思います。 line (default) strict exact none 手始めに、以下はドキュメントに記載されている match の説明文を ChatGPT に翻訳してもらったものになります。 このモジュールに、一連のコマンドを現在のデバイス設定に対してどのように照合するかを指示します。matchがlineに設定されている場合、コマンドは行ごとに照合されます。matchがstrictに設定されている場合、コマンド行は位置に応じて照合されます。matchがexactに設定されている場合、コマンド行は完全に一致していなければなりません。最後に、matchがnoneに設定されている場合、モジュールはソース設定をリモートデバイス上の実行中の設定と比較しようとはしません。 私は正直、こちらを読んでもよく理解できませんでしたので、検証してみました :) 以下にその結果を記載します。 1. line (default) について こちらは、 cisco.iosxr.iosxr_config モジュールの lines に与えられたコンフィグが running-config に存在しているかどうかを確認します。ただし、投入されているコンフィグの順番は考慮しません。あくまで、コンフィグが存在しているかどうかのみを確認します。 ※例: running-config ipv4 access-list IPv4-ACL 10 deny tcp any 1.1.1.1 0.0.0.255 20 permit tcp any 2.2.2.2 0.0.0.255 30 permit tcp any 3.3.3.3 0.0.0.255 40 permit tcp any any 例えば、上記のコンフィグに対し以下のプレイブックが渡されても、既にコンフィグが存在するので、iosxr_config モジュールは何もしません。 - name : iosxr_config "line" test cisco.iosxr.iosxr_config : lines : - 20 permit tcp any 2.2.2.2 0.0.0.255 #<--- 順番が入れ替わっている箇所 - 10 deny tcp any 1.1.1.1 0.0.0.255 #<--- 順番が入れ替わっている箇所 - 30 permit tcp any 3.3.3.3 0.0.0.255 - 40 permit tcp any any parents : ipv4 access-list IPv4-ACL match : line 2. strict について こちらは、 cisco.iosxr.iosxr_config モジュールの lines に与えられたコンフィグが running-config に存在しているかどうかだけでなく、 lines に与えられた順番通りに存在しているかどうかまでを確認します。コンフィグが存在していても、設定されているコンフィグの順番に差分がある場合には、 lines に与えられた順番通りになるよう変更を試みます。 ※例: running-config ipv4 access-list IPv4-ACL 10 deny tcp any 1.1.1.1 0.0.0.255 20 permit tcp any 2.2.2.2 0.0.0.255 30 permit tcp any 3.3.3.3 0.0.0.255 40 permit tcp any any 例えば、上記のコンフィグに対し以下のプレイブックが実行された場合、順番に差分がありますので、 iosxr_config モジュールは設定変更を試みます。 - name : iosxr_config "strict" test cisco.iosxr.iosxr_config : lines : - 20 permit tcp any 2.2.2.2 0.0.0.255 - 10 deny tcp any 1.1.1.1 0.0.0.255 - 30 permit tcp any 3.3.3.3 0.0.0.255 - 40 permit tcp any any parents : ipv4 access-list IPv4-ACL match : strict 3. exact について exact は strict と非常によく似た機能なのですが、 strict との相違点としては、 cisco.iosxr.iosxr_config モジュールの lines に与えられたコンフィグと running-config との比較だけでなく、 parents に指定されたブロック全体の「行数」まで比較を行う点にあります。 ※例: running-config interface GigabitEthernet0/0/0/1 description ansible test hogehoge shutdown 例えば、上記のコンフィグを持つインターフェイス(GigabitEthernet0/0/0/1)に以下のプレイブックを実行した場合、何度実行しても"TEST EXACT"タスクの lines に指定した設定が常に適用され、status は changed となります。理由としましては、 lines に与えられたコンフィグの合計の行数が 2 行(interface GigabitEthernet0/0/0/1 と description ansible test hogehoge) に対し、現在の running-config が 3 行となるので、差分があると判定し、変更を試みるためです。 サンプル Playbook 1 --- - hosts : example01.com gather_facts : false tasks : - name : TEST EXACT cisco.iosxr.iosxr_config : lines : - description ansible test hogehoge # - shutdown parents : interface GigabitEthernet0/0/0/1 match : exact 尚、 strict の場合は、 lines に指定した各行レベルでの比較のみを行います。 例えば以下のプレイブック(match: strict の箇所以外は サンプル Playbook 1と同じ)を実行しても、 lines に指定した description の設定が running-config と一致している場合は、設定の変更は試みられず、プレイブックの実行 status は常に ok となります。これは、ブロック内の行数については比較しないためです。 サンプル Playbook 2 --- - hosts : example01.com gather_facts : false tasks : - name : TEST STRICT cisco.iosxr.iosxr_config : lines : - description ansible test hogehoge # - shutdown parents : interface GigabitEthernet0/0/0/1 match : strict 4. none について こちらは、 lines に与えられたコンフィグと running-config の比較を行いません。したがって、 lines に与えられたコンフィグが running-config に存在しているかどうかにかかわらず、常に設定を試みます。 以上、ご参考になれば幸いです。 Happy holiday & Automation!

※この記事は Red Hat Advent Calendar 2023 の23日目です。 qiita.com こんにちは。Red Hat にてOpenStackのテクニカルサポートの担当をしている井川です。 日頃、サポートケースを通じて多くの問い合わせを頂いておりますが、認識の齟齬や状況・問題の把握に時間を要し、残念ながら解決までに時間のかかることもあるのが現状です。 今回、より早く解決させるためのコツ(tips)・ベストプラクティスについて、「 サポートサービス利用ガイド 」の中から「サポートサービスをうまく活用するコツ」をご紹介したいと思います。 サポートサービスをうまく活用するコツ 詳細を記載する 特にトラブルシュートや障害調査では、可能なかぎり詳細を記載することにより、サポートエンジニアが状況を把握しやすくなり、トラブル解決へのスピードが早くなることが期待されます。トラブル発生時にはバタバタしてしまい、なかなか冷静でいることは難しい状況です。 しかし、ここを省略してしまうと、サポートエンジニアとの情報のやりとりが増えることとなり、結果、トラブル解決にかかる時間が増大してしまう可能性が大きくなります。 記載すべき情報の例 現象発生日時 (日付・時刻) 発生頻度 (1度のみ発生、くりかえし発生、不定期に発生) タイミング(再起動時に発生、毎日 0:00 に発生、タイミング不明) 事象発生前に実施した作業やオペレーションの有無 パッケージやソフトウェアのアップデート 環境や設定の変更 ･ 環境の詳細 (ホスト名、カーネルバージョン、パッケージバージョン等) ログやデータなどの情報で事象を説明する 上記「詳細を記載する」にも関連しますが、以下のような具体的な情報をご提供いただくことで、事象把握の大きな助けとなります。 しばしば、「インターネットに繋がっていない環境なのでsosreportなどを送付できない」というケースも見受けられます。しかし、サポートエンジニアとしては、これらの具体的な情報が無いとシステムや事象の詳細がわからず解決に非常に時間がかかる結果となってしまいます。 このため、重要なシステムであればあるほど、トラブル発生時に下記の様な情報をどのように送付するのか？を予め計画・テストしておくことが大切となります。 記載・添付すべき情報の例 コマンド出力結果 sosreportやログ情報抜粋 画面ショット (スクリーンショット) トピック・問題ごとにサポートケースを分けて登録する １つのサポートケースで複数のトピックや問題が扱われると、どちら事象についての話なのかが分かりづらくなり、お客様もサポートエンジニアも混乱が発生する可能性があります。 このようなことを避ける為、トピック・問題ごとにサポートケースをご登録いただければと思います。 例 同じホストで以下 a と b の２つの事象が発生したとします。 １つのサポートケースで a,b 両方をお問い合わせ頂くより、別の (２つの)サポートケースでお問い合わせ頂いた方がスムーズに対応が進みます。 OS再起動時に時間がかかるので、短くする方法を教えて欲しい。 パッケージのアップデートを試みたらエラーで失敗した。対処方法を教えてほしい。 また、サポートケースのやり取りの中で新たな問題やトピックが出てくることもよくありますが、その場合には、サポートエンジニアより、新たなサポートケースの登録をお願いすることもありますので、ご了承いただければと思います。 適切な重大度を指定する 「 重大度の定義 」の通り、重大度 1や2は業務を提供している本番環境向けにおける深刻・重大な問題向けのものです。 あてはまらない環境・問題でも選択できてしまいますが、実際のシステム・業務の状況をお伺いしたり、状況に応じて重大度の調整をお願いさせて頂く場合があります。 access.redhat.com その他 Red Hat テクニカル・アカウント・マネジメント(TAM)を購入する 通常のテクニカルサポートでは、リアクティブな対応となり、また、システム構成や状況は把握していないため、ケース作成毎に毎回説明していただく必要があります。 一方、 TAM においては、お客様の単一連絡窓口のテクニカルアドバイザーとなり、定期的なリモート会議に参加し、予めシステム構成等を把握し、プロアクティブにサポートを行うことなどが可能となります。 このため、トラブルの発生を未然に防ぐことが可能となり、また、トラブル発生時にも担当TAMがすでに把握してる情報を再度やり取りすることがなく、通常のテクニカルサポートと比較し、迅速に解決に導ける可能性が高まります。 重要なシステムにおいては TAM のご購入を検討いただければ幸いです。 www.redhat.com サポート利用に関するリンク サポートサービスやカスタマーポータルについての日本語のガイドはありますか? 本記事を書くにあたり コピペ 参考にした資料 へのリンクです。リンク先の資料には、サポートサービス・カスタマーポータルの利用方法が丁寧に書かれています。 access.redhat.com Red Hat サポートを利用するためのリファレンスガイド 上記で述べた事も一部含まれていますが、各製品毎のログ収集方法へのリンク等あります。 access.redhat.com How to collect all required logs for Red Hat Support to investigate an OpenStack issue Red Hat OpenStack Platform において発生した事象を解析するためのログ収集方法について書かれたドキュメントです。英語が苦手な場合には、 機械翻訳 を参考としていただければと思います。 access.redhat.com おまけ ChatGPT 4に、問い合わせる際のコツを聞いてみました。 ChatGPT4への質問1 Red Hat のテクニカルサポートへ問い合わせる際、より効果的な回答を得るための方法やコツを挙げられるだけ挙げてください。 回答 Red Hatのテクニカルサポートに問い合わせる際、効果的な回答を得るためには以下の方法やコツが有効です： 明確な問題の説明 ：問題の詳細を具体的かつ明確に説明してください。何が起きているのか、どのような状況で問題が発生しているのか、影響を受けているシステムやソフトウェアのバージョンなどを含めます。 再現手順の提供 ：問題を再現するための具体的な手順を提供することで、サポートチームが問題をより迅速に理解し、解決策を見つけやすくなります。 エラーメッセージとログの共有 ：エラーメッセージやシステムログ、コンフィギュレーションファイルなどの詳細情報を提供することで、問題の原因を特定しやすくなります。 優先度の設定 ：問題の緊急度やビジネスへの影響度を伝えることで、サポートチームが対応の優先度を適切に設定できます。 既存のトラブルシューティングの結果の共有 ：既に試みた解決策やトラブルシューティングの手順を共有することで、サポートチームが同じ手順を繰り返さずに済みます。 具体的な質問や要望の提示 ：どのような解決策を求めているのか、具体的な質問や要望を明確にすることが大切です。 連絡先情報の確認 ：連絡が取れる電話番号やメールアドレスを確認し、必要に応じて連絡可能な時間帯も伝えておきます。 関連する環境情報の提供 ：問題が発生している環境（ハードウェア、OS、ネットワーク構成など）に関する情報も重要です。 継続的なコミュニケーション ：問い合わせ後も状況が変わった場合は、追加情報を提供するなどして継続的にコミュニケーションを取ります。 サポートポータルやコミュニティの利用 ：Red Hatのサポートポータルやコミュニティフォーラムで、似たような問題や解決策がないか探してみるのも一つの方法です。 これらのコツを実践することで、Red Hatのテクニカルサポートからより迅速で的確な回答を得ることができるでしょう。 筆者補足 「4. 優先度の設定 」 → Severity(重大度)にて設定できます。 「7. 連絡先情報の確認 」 → 通常、サポートケースを通じてのやりとりとなりますので、特段の注意は不要です。 「8. 関連する環境情報の提供 」：問題が発生している環境（ハードウェア、OS、ネットワーク構成など）に関する情報も重要です。 → sosreport が非常に有効ですが、お問い合わせの問題に関連すると思われる環境の情報があれば、付け加えていただくとより効果的です。 「10. サポートポータルやコミュニティの利用 」：Red Hatのサポートポータルやコミュニティフォーラムで、似たような問題や解決策がないか探してみるのも一つの方法です。 → 弊社 ドキュメント ・ ナレッジベース には非常に多くの情報が蓄積されております。お問い合わせの際に、一度ご確認いただくことにより、回答が素早く見つかる可能性もあります。 access.redhat.com access.redhat.com ChatGPT4への質問2 RHOSPに関する問い合わせの場合、特に注意すべき点やコツなどあれば教えてください。 回答 Red Hat OpenStack Platform（RHOSP）に関する問い合わせの際に特に注意すべき点やコツは以下の通りです： バージョン情報の提供 ：問題が発生しているRHOSPのバージョンを明確に伝えてください。異なるバージョンで異なる問題や解決策が存在する可能性があります。 デプロイメントの詳細 ：デプロイメントの設定や構成（ノードの数、使用しているストレージやネットワーキングの設定など）に関する詳細情報を提供します。 具体的な症状の説明 ：問題の症状を具体的に説明します。例えば、特定のサービスが応答しない、パフォーマンスが低下している、あるいは特定の操作が期待通りに動作しないなどです。 関連するログファイルの提供 ：OpenStackの各コンポーネントからのログファイルを集め、問題の解析に役立つ情報を提供します。 エラーメッセージの共有 ：発生しているエラーメッセージを可能な限り詳細に共有します。 変更履歴の記録 ：問題発生前に行われたシステムやネットワークの変更、アップデート、設定の変更などの履歴を提供します。 スケールや負荷の情報 ：問題が発生している環境のスケール（仮想マシンの数、使用中のリソース量など）や現在の負荷に関する情報も有効です。 環境固有の情報 ：自社の環境に特有の設定やカスタマイズがある場合は、それに関する情報も共有してください。 既に試みた解決策 ：問題解決のために既に行った試みや、実施したトラブルシューティング手順を共有します。 継続的なコミュニケーション ：問題解決に向けた継続的なコミュニケーションを保ち、新たな情報が得られたらそれを迅速に共有します。 Red Hat OpenStack Platformは複雑なシステムですので、これらの情報を詳細に提供することで、テクニカルサポートチームがより効果的に問題を理解し、解決策を提供しやすくなります。 筆者補足 いずれも重要な視点と感じます。特に最後の Red Hat OpenStack Platformは複雑なシステムですので は、とても染み入る言葉と感じます。 以上、効果的なテクニカルサポートへの問い合わせのヒントとなれば幸いです。

皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。 2023 年も残すところあと少しとなりました。さて、今回は、注目の新機能をサポートし、今年GAとなった Ansible Automation Platform 2.4 について、2023 年の締めくくりとして書いておきたいと思います。それぞれのお試し方法については、年明け、またこちらの Blog でご紹介予定です。 Ansible Automatio Platform 2.4 (以下 AAP2.4) の新機能、細かいところを上げるとたくさんあるのですが、なんといっても注目は、 ・Event-Driven Ansible ・Ansible Lightspeed の2つです。では、そのそれぞれについてご説明します。 Event-Driven Ansible AAP 2.4 では、IT の運用で発生する様々なイベントに対するオペレーションを自動化する、Event-driven Ansible (以下 EDA) が新たに追加されました。AAP 2.3 までは、GUI サービスを提供するコンポーネントとして、Ansible Automation Controller（以下 AAC）と Private Automation Hub (PAH) が提供されていましたが、AAP 2.4 では EDA Controller が GUI を提供する 3つ目のコンポーネントとして追加されています。従来の AAP では、IT システム運用の際の様々な作業を Playbook として定義し、さらにそれをサービス化することで作業工数の大幅な削減を実現しましたが、ここに EDA が追加されることにより、IT 運用の現場で日々発生する、様々なイベントを自動的に処理し、その結果として例えば、AAC と連携した Playbook の実行ができるようになります。イメージは以下の通りです。 EDA の動作は、AAC とよく似ています。AAC では yaml 形式で書かれた Playbook をジョブテンプレート経由で実行しますが、EDA では同じく yaml 形式で書かれた Rulebook を実行します。Playbook も Rulebook も同じ yaml 形式ですから、Playbook の作成・編集に慣れた方であればほとんどハードルなく Rulebook の作成ができるのではないかと思います。 Rulebook には以下の内容が記載されており、あらかじめ EDA Controller 上でアクティベーション（イベントを待ち受ける状態）されています。 ・sources（何が） 　イベントの提供元に関する情報 ・rules 　 condition（どうなったら） 　　実行条件 (not equal, equal, and / or, defined など柔軟に指定可能) 　 action（どうする） EDA の動作のトリガーとなるソースに関しては、サードパーティ製のソフトウェアと連携する形をとります。例えば、IBM社の Instana、Turbonomic、Zabbix、Dynatrace、Paloalto など EDA をサポートするソフトウェアから発砲されたイベントをソースとして利用することができます。EDA が source からイベントを受け取ると、Rulebook に記載された内容に基づき、 condition に記載された条件と一致するかどうかを判断し、一致した場合は、 action に記載された内容を実行します。 action には、ポストイベントの発砲など含めいくつかの種類がありますが、AAC 内にあらかじめ準備されたジョブテンプレートやワークフローテンプレートを呼び出して Playbook を実行することも可能です。 例えば、以下は簡単な Rulebook の一例ですが、このケースでは、すべてのホストからの webhook を5000番ポートで待ち受け、webhook のイベントを受け取ったら、 その中のメッセージを確認し、 Ansible is super cool という文字列と一致した場合に、 AAC 内にあらかじめ作成された say-what というジョブテンプレートを実行するという動作になります。 --- - name: Listen for events on a webhook hosts: all sources: - name: Wait for Webhook Message ansible.eda.webhook: host: 0.0.0.0 port: 5000 rules: - name: Say Hello condition: event.payload.message == "Ansible is super cool" action: run_job_template: name: say-what organization: Default AAC は実行環境で Playbook を実行しますが、EDA Controller も同じように、決定環境と呼ばれるコンテナ内部で Rulebook を実行します。 決定環境の中には ansible.eda というイベントソースプラグインがあらかじめパッケージ化されており、インストール直後から利用可能です。 ansible.readthedocs.io 詳細については以下をご確認ください。 github.com ansible.eda 以外のプラグインは Red Hat Hybrid Cloud Console から Collections として提供されています。このあたりの実装は、AAC と同じです。以下のリンクは、 Red Hat Hybrid Cloud Console を文字列 eda で検索した結果です。EDA ではこれらの Collections が利用可能です。 console.redhat.com EDA の具体的な動作テストの方法は年明けに、こちらのブログでご紹介したいと思います。 Ansible Lightspeed AAP 2.4 のもう一つの大きな目玉、Ansible Lightspeed についてご紹介します。 Ansible Lightspeed は、IBM Cloud 上でサービス提供される watsonx Code Assistant for Ansible Lightspeed を利用した生成 AI による Playbook 作成支援機能です。生成 AI というと ChatGPT を思い浮かべる方も多いかもしれませんが、Ansible Lightspeed で利用される watsonx Code Assistant for Ansible Lightspeed は Ansible Galaxyコンテンツとその他のオープン・データ・ソースおよび、Red HatとIBMの自動化に関する専門知識が注入された、Ansible固有の「トレーニング」データ・セットとなっているため、生成されたコードの質が高く、また、生成されたコードがどこから来たのか、そのソースを確認することもできることから、コードの脆弱性や不意のライセンス違反などを気にすることなく、安心して利用することが可能です。 Ansible Lightspeed は VSCode の拡張機能として利用することができます。現在サポートされている機能は以下の通りです。 タスクの作成 自然言語プロンプトからの Ansible Playbook または Roles のタスクの生成 マルチタスクの作成 YAML コメント (#) 行でアンパサンド (&) を使用して連鎖した自然言語タスク プロンプトの連続チェーンを提供することにより、Ansible タスク ファイルと Playbook に対する複数の Ansible タスク提案を生成する コンテンツソースマッチング 生成された各コードの推奨事項を、Ansible コンテンツ、コンテンツ作成者、コンテンツ ライセンスなど、最も近い潜在的なデータ トレーニング ソースの上位 3 つと照合する ポストプロセッシングルール 生成されたコードの推奨事項を拡張し、Ansible のベストプラクティスに確実に準拠するようにする 詳しくはこちらのデータシートをご確認ください。 www.redhat.com 一つの例として、Ansible Lightspeed を使って、Playbook 内に以下ようなタスクを作成してみました。 入力した自然言語 #最新バージョンの httpd をインストール & httpd サービスの有効化と開始 & 80/443 ポートをFireall で恒久的に即座に開く Ansible Lightspeed によるマルチタスク作成結果 tasks: # 最新バージョンの httpd をインストール & httpd サービスの有効化と開始 & 80/443 ポートをFireall で恒久的に即座に開く - name: 最新バージョンの httpd をインストール ansible.builtin.package: name: httpd state: latest - name: Httpd サービスの有効化と開始 ansible.builtin.service: name: httpd state: started enabled: true - name: 80/443 ポートをFireall で恒久的に即座に開く ansible.posix.firewalld: port: '{{ item }}/tcp' permanent: true state: enabled immediate: true loop: - 80 - 443 簡単なデモ動画も作成してみました。 youtu.be いかがでしたでしょうか？次回は年明け、EDA、Lightspeed の実際のお試し方法についてご紹介したいと思います。 なお、今回ご紹介した EDA は AAP のサブスクリプションに含まれておりますが、Ansible Lightspeed に関しては、IBM Cloud によるサービス提供となるため、別途追加費用が必要となります。具体的な価格に関しては弊社担当までお問い合わせください。

id:nekop です。この記事は OpenShift Advent Calendar 2023 のエントリです。 OpenShift Loggingでは長くEFK (Elasticsearch, Fluentd, Kibana)スタックが利用されていましたが、現在のリリースはLoki Vectorスタックを標準的に利用するようになっています。Elasticsearchは2022-07に非推奨、Fluentdは2023-01に非推奨となりました。 OpenShift Loggingでは Vectorによるログ収集と転送 がサポートされています。VectorはDatadog社により開発されたデータ転送処理ソフトウェアです。Sourceと呼ばれる入力、Transformerによる加工、Sinkと呼ばれる出力の3つのコンポーネントを利用してデータの転送処理を行います。 今回はこのVectorにフォーカスして遊んでみます。通常構成のログストアであるLokiは利用せず、クラスタ内に受信側となる別のVector podを用意してそちらにログ転送してファイル出力を行う設定で構成します。この構成における受信側Vectorはサポートされる構成ではなくユーザアプリ扱いなので、サポート対象外となります。 受信側Vectorは http_server source で8080ポート待ち受け、 file sink でファイル出力する設定です。/tmp配下のファイルとして保存します。 TARGET_PROJECT=tkimura-infra cat <<EOF > vector.toml expire_metrics_secs = 60 [api] enabled = true [sources.http_server_source] type = "http_server" address = "0.0.0.0:8080" decoding.codec = "json" [sinks.file_sink] type = "file" inputs = [ "http_server_source" ] path = "/tmp/vector-%Y-%m-%d.log" encoding.codec = "json" EOF oc -n $TARGET_PROJECT create configmap vector-http --from-file=vector.toml oc -n $TARGET_PROJECT create deployment vector-http --image=quay.io/openshift-logging/vector:5.8 --port=8080 oc -n $TARGET_PROJECT set volume deploy/vector-http --add --name=vector-http-config --configmap-name=vector-http --mount-path=/etc/vector oc -n $TARGET_PROJECT expose deploy/vector-http oc -n openshift-logging create -f - <<EOF apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: type: vector --- apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: ext-vector-http type: http url: 'http://vector-http.$TARGET_PROJECT.svc:8080' pipelines: - name: forward-to-ext-vector-http inputRefs: - application - infrastructure outputRefs: - ext-vector-http EOF デプロイすると、受信側Vectorで転送されたログを確認することができます。 $ oc -n tkimura-infra rsh deploy/vector-http ls -la /tmp total 131968 drwxrwxrwt. 1 root root 35 Dec 22 07:44 . dr-xr-xr-x. 1 root root 39 Dec 22 07:44 .. -rw-r--r--. 1 1000710000 root 101867631 Dec 22 08:22 vector-2023-12-22.log $ oc -n tkimura-infra rsh deploy/vector-http tail -n2 /tmp/vector-2023-12-22.log {"@timestamp":"2023-12-22T07:57:53.432429470Z","hostname":"ip-10-0-45-201.ap-northeast-1.compute.internal","kubernetes":{"annotations":{"openshift.io/scc":"hostaccess"},"container_id":"cri-o://465432752c76d4aff0419119d2365fbbf38cee44620ff746c974380df12cbeef","container_image":"quay.io/openshift-release-dev/ocp-release@sha256:e5128c3b0ab225e0abf9344dae504e08b82dda4885bbd047e2dbc13cc3d9879b","container_name":"cluster-version-operator","labels":{"k8s-app":"cluster-version-operator","pod-template-hash":"678d8bb44"},"namespace_id":"e0c35f25-5a1f-4682-bfa2-d69dab7418fc","namespace_labels":{"kubernetes_io_metadata_name":"openshift-cluster-version","name":"openshift-cluster-version","olm_operatorgroup_uid_32e3efbd-dac1-4364-bab3-cd37df669a1e":"","openshift_io_cluster-monitoring":"true","openshift_io_run-level":"","pod-security_kubernetes_io_audit":"privileged","pod-security_kubernetes_io_enforce":"privileged","pod-security_kubernetes_io_warn":"privileged"},"namespace_name":"openshift-cluster-version","pod_id":"4b2b3ab9-297a-4480-8857-d80244289da1","pod_ip":"10.0.45.201","pod_name":"cluster-version-operator-678d8bb44-s8c7x","pod_owner":"ReplicaSet/cluster-version-operator-678d8bb44"},"level":"info","log_type":"infrastructure","message":"I1222 07:57:53.432384 1 sync_worker.go:990] Done syncing for cloudcredential \"cluster\" (269 of 860)","openshift":{"cluster_id":"1e0f1eb9-9174-426b-8e2e-6b401fca7fbe","sequence":29292},"path":"/","source_type":"http_server","timestamp":"2023-12-22T07:57:53.454795108Z"} {"@timestamp":"2023-12-22T07:57:53.432429470Z","hostname":"ip-10-0-45-201.ap-northeast-1.compute.internal","kubernetes":{"annotations":{"openshift.io/scc":"hostaccess"},"container_id":"cri-o://465432752c76d4aff0419119d2365fbbf38cee44620ff746c974380df12cbeef","container_image":"quay.io/openshift-release-dev/ocp-release@sha256:e5128c3b0ab225e0abf9344dae504e08b82dda4885bbd047e2dbc13cc3d9879b","container_name":"cluster-version-operator","labels":{"k8s-app":"cluster-version-operator","pod-template-hash":"678d8bb44"},"namespace_id":"e0c35f25-5a1f-4682-bfa2-d69dab7418fc","namespace_labels":{"kubernetes_io_metadata_name":"openshift-cluster-version","name":"openshift-cluster-version","olm_operatorgroup_uid_32e3efbd-dac1-4364-bab3-cd37df669a1e":"","openshift_io_cluster-monitoring":"true","openshift_io_run-level":"","pod-security_kubernetes_io_audit":"privileged","pod-security_kubernetes_io_enforce":"privileged","pod-security_kubernetes_io_warn":"privileged"},"namespace_name":"openshift-cluster-version","pod_id":"4b2b3ab9-297a-4480-8857-d80244289da1","pod_ip":"10.0.45.201","pod_name":"cluster-version-operator-678d8bb44-s8c7x","pod_owner":"ReplicaSet/cluster-version-operator-678d8bb44"},"level":"info","log_type":"infrastructure","message":"I1222 07:57:53.432416 1 sync_worker.go:975] Running sync for rolebinding \"openshift-cloud-credential-operator/cloud-credential-operator\" (270 of 860)","openshift":{"cluster_id":"1e0f1eb9-9174-426b-8e2e-6b401fca7fbe","sequence":29293},"path":"/","source_type":"http_server","timestamp":"2023-12-22T07:57:53.454795108Z"} 設定ファイルを見てみましょう。vector.tomlは大まかに以下の設定になっています。 kubernetes_logs source journald source 基本的な加工 openshift, kube namespaceのログとjournaldをinfrastructureに分類、その他をapplicationに分類 受信側vectorへのhttp sink $ oc -n openshift-logging extract secret/collector-config vector.toml run-vector.sh $ cat vector.toml expire_metrics_secs = 60 [api] enabled = true # Logs from containers (including openshift containers) [sources.raw_container_logs] type = "kubernetes_logs" max_read_bytes = 3145728 glob_minimum_cooldown_ms = 15000 auto_partial_merge = true exclude_paths_glob_patterns = ["/var/log/pods/openshift-logging_logfilesmetricexporter-*/*/*.log", "/var/log/pods/openshift-logging_elasticsearch-*/*/*.log", "/var/log/pods/openshift-logging_*/loki*/*.log", "/var/log/pods/openshift-logging_kibana-*/*/*.log", "/var/log/pods/openshift-logging_*/gateway/*.log", "/var/log/pods/openshift-logging_*/opa/*.log", "/var/log/pods/*/*/*.gz", "/var/log/pods/*/*/*.tmp"] pod_annotation_fields.pod_labels = "kubernetes.labels" pod_annotation_fields.pod_namespace = "kubernetes.namespace_name" pod_annotation_fields.pod_annotations = "kubernetes.annotations" pod_annotation_fields.pod_uid = "kubernetes.pod_id" pod_annotation_fields.pod_node_name = "hostname" namespace_annotation_fields.namespace_uid = "kubernetes.namespace_id" rotate_wait_ms = 5000 [sources.raw_journal_logs] type = "journald" journal_directory = "/var/log/journal" [sources.internal_metrics] type = "internal_metrics" [transforms.container_logs] type = "remap" inputs = ["raw_container_logs"] source = ''' .openshift.cluster_id = "${OPENSHIFT_CLUSTER_ID:-}" if !exists(.level) { .level = "default" if match!(.message, r'Warning|WARN|^W[0-9]+|level=warn|Value:warn|"level":"warn"|<warn>') { .level = "warn" } else if match!(.message, r'Error|ERROR|^E[0-9]+|level=error|Value:error|"level":"error"|<error>') { .level = "error" } else if match!(.message, r'Critical|CRITICAL|^C[0-9]+|level=critical|Value:critical|"level":"critical"|<critical>') { .level = "critical" } else if match!(.message, r'Debug|DEBUG|^D[0-9]+|level=debug|Value:debug|"level":"debug"|<debug>') { .level = "debug" } else if match!(.message, r'Notice|NOTICE|^N[0-9]+|level=notice|Value:notice|"level":"notice"|<notice>') { .level = "notice" } else if match!(.message, r'Alert|ALERT|^A[0-9]+|level=alert|Value:alert|"level":"alert"|<alert>') { .level = "alert" } else if match!(.message, r'Emergency|EMERGENCY|^EM[0-9]+|level=emergency|Value:emergency|"level":"emergency"|<emergency>') { .level = "emergency" } else if match!(.message, r'(?i)\b(?:info)\b|^I[0-9]+|level=info|Value:info|"level":"info"|<info>') { .level = "info" } } pod_name = string!(.kubernetes.pod_name) if starts_with(pod_name, "eventrouter-") { parsed, err = parse_json(.message) if err != null { log("Unable to process EventRouter log: " + err, level: "info") } else { ., err = merge(.,parsed) if err == null && exists(.event) && is_object(.event) { if exists(.verb) { .event.verb = .verb del(.verb) } .kubernetes.event = del(.event) .message = del(.kubernetes.event.message) set!(., ["@timestamp"], .kubernetes.event.metadata.creationTimestamp) del(.kubernetes.event.metadata.creationTimestamp) . = compact(., nullish: true) } else { log("Unable to merge EventRouter log message into record: " + err, level: "info") } } } del(.source_type) del(.stream) del(.kubernetes.pod_ips) del(.kubernetes.node_labels) del(.timestamp_end) ts = del(.timestamp); if !exists(."@timestamp") {."@timestamp" = ts} ''' [transforms.drop_journal_logs] type = "filter" inputs = ["raw_journal_logs"] condition = ".PRIORITY != \"7\" && .PRIORITY != 7" [transforms.journal_logs] type = "remap" inputs = ["drop_journal_logs"] source = ''' .openshift.cluster_id = "${OPENSHIFT_CLUSTER_ID:-}" .tag = ".journal.system" del(.source_type) del(._CPU_USAGE_NSEC) del(.__REALTIME_TIMESTAMP) del(.__MONOTONIC_TIMESTAMP) del(._SOURCE_REALTIME_TIMESTAMP) del(.JOB_RESULT) del(.JOB_TYPE) del(.TIMESTAMP_BOOTTIME) del(.TIMESTAMP_MONOTONIC) if .PRIORITY == "8" || .PRIORITY == 8 { .level = "trace" } else { priority = to_int!(.PRIORITY) .level, err = to_syslog_level(priority) if err != null { log("Unable to determine level from PRIORITY: " + err, level: "error") log(., level: "error") .level = "unknown" } else { del(.PRIORITY) } } .hostname = del(.host) # systemd’s kernel-specific metadata. # .systemd.k = {} if exists(.KERNEL_DEVICE) { .systemd.k.KERNEL_DEVICE = del(.KERNEL_DEVICE) } if exists(.KERNEL_SUBSYSTEM) { .systemd.k.KERNEL_SUBSYSTEM = del(.KERNEL_SUBSYSTEM) } if exists(.UDEV_DEVLINK) { .systemd.k.UDEV_DEVLINK = del(.UDEV_DEVLINK) } if exists(.UDEV_DEVNODE) { .systemd.k.UDEV_DEVNODE = del(.UDEV_DEVNODE) } if exists(.UDEV_SYSNAME) { .systemd.k.UDEV_SYSNAME = del(.UDEV_SYSNAME) } # trusted journal fields, fields that are implicitly added by the journal and cannot be altered by client code. .systemd.t = {} if exists(._AUDIT_LOGINUID) { .systemd.t.AUDIT_LOGINUID = del(._AUDIT_LOGINUID) } if exists(._BOOT_ID) { .systemd.t.BOOT_ID = del(._BOOT_ID) } if exists(._AUDIT_SESSION) { .systemd.t.AUDIT_SESSION = del(._AUDIT_SESSION) } if exists(._CAP_EFFECTIVE) { .systemd.t.CAP_EFFECTIVE = del(._CAP_EFFECTIVE) } if exists(._CMDLINE) { .systemd.t.CMDLINE = del(._CMDLINE) } if exists(._COMM) { .systemd.t.COMM = del(._COMM) } if exists(._EXE) { .systemd.t.EXE = del(._EXE) } if exists(._GID) { .systemd.t.GID = del(._GID) } if exists(._HOSTNAME) { .systemd.t.HOSTNAME = .hostname } if exists(._LINE_BREAK) { .systemd.t.LINE_BREAK = del(._LINE_BREAK) } if exists(._MACHINE_ID) { .systemd.t.MACHINE_ID = del(._MACHINE_ID) } if exists(._PID) { .systemd.t.PID = del(._PID) } if exists(._SELINUX_CONTEXT) { .systemd.t.SELINUX_CONTEXT = del(._SELINUX_CONTEXT) } if exists(._SOURCE_REALTIME_TIMESTAMP) { .systemd.t.SOURCE_REALTIME_TIMESTAMP = del(._SOURCE_REALTIME_TIMESTAMP) } if exists(._STREAM_ID) { .systemd.t.STREAM_ID = ._STREAM_ID } if exists(._SYSTEMD_CGROUP) { .systemd.t.SYSTEMD_CGROUP = del(._SYSTEMD_CGROUP) } if exists(._SYSTEMD_INVOCATION_ID) {.systemd.t.SYSTEMD_INVOCATION_ID = ._SYSTEMD_INVOCATION_ID} if exists(._SYSTEMD_OWNER_UID) { .systemd.t.SYSTEMD_OWNER_UID = del(._SYSTEMD_OWNER_UID) } if exists(._SYSTEMD_SESSION) { .systemd.t.SYSTEMD_SESSION = del(._SYSTEMD_SESSION) } if exists(._SYSTEMD_SLICE) { .systemd.t.SYSTEMD_SLICE = del(._SYSTEMD_SLICE) } if exists(._SYSTEMD_UNIT) { .systemd.t.SYSTEMD_UNIT = del(._SYSTEMD_UNIT) } if exists(._SYSTEMD_USER_UNIT) { .systemd.t.SYSTEMD_USER_UNIT = del(._SYSTEMD_USER_UNIT) } if exists(._TRANSPORT) { .systemd.t.TRANSPORT = del(._TRANSPORT) } if exists(._UID) { .systemd.t.UID = del(._UID) } # fields that are directly passed from clients and stored in the journal. .systemd.u = {} if exists(.CODE_FILE) { .systemd.u.CODE_FILE = del(.CODE_FILE) } if exists(.CODE_FUNC) { .systemd.u.CODE_FUNCTION = del(.CODE_FUNC) } if exists(.CODE_LINE) { .systemd.u.CODE_LINE = del(.CODE_LINE) } if exists(.ERRNO) { .systemd.u.ERRNO = del(.ERRNO) } if exists(.MESSAGE_ID) { .systemd.u.MESSAGE_ID = del(.MESSAGE_ID) } if exists(.SYSLOG_FACILITY) { .systemd.u.SYSLOG_FACILITY = del(.SYSLOG_FACILITY) } if exists(.SYSLOG_IDENTIFIER) { .systemd.u.SYSLOG_IDENTIFIER = del(.SYSLOG_IDENTIFIER) } if exists(.SYSLOG_PID) { .systemd.u.SYSLOG_PID = del(.SYSLOG_PID) } if exists(.RESULT) { .systemd.u.RESULT = del(.RESULT) } if exists(.UNIT) { .systemd.u.UNIT = del(.UNIT) } .time = format_timestamp!(.timestamp, format: "%FT%T%:z") ts = del(.timestamp); if !exists(."@timestamp") {."@timestamp" = ts} ''' [transforms.route_container_logs] type = "route" inputs = ["container_logs"] route.app = '!((starts_with!(.kubernetes.namespace_name,"kube-")) || (starts_with!(.kubernetes.namespace_name,"openshift-")) || (.kubernetes.namespace_name == "default") || (.kubernetes.namespace_name == "openshift") || (.kubernetes.namespace_name == "kube"))' route.infra = '(starts_with!(.kubernetes.namespace_name,"kube-")) || (starts_with!(.kubernetes.namespace_name,"openshift-")) || (.kubernetes.namespace_name == "default") || (.kubernetes.namespace_name == "openshift") || (.kubernetes.namespace_name == "kube")' # Set log_type to "application" [transforms.application] type = "remap" inputs = ["route_container_logs.app"] source = ''' .log_type = "application" ''' # Set log_type to "infrastructure" [transforms.infrastructure] type = "remap" inputs = ["route_container_logs.infra","journal_logs"] source = ''' .log_type = "infrastructure" ''' [transforms.forward_to_ext_vector_http_user_defined] type = "remap" inputs = ["application","infrastructure"] source = ''' . ''' [transforms.ext_vector_http_normalize_http] type = "remap" inputs = ["forward_to_ext_vector_http_user_defined"] source = ''' del(.file) ''' [transforms.ext_vector_http_dedot] type = "lua" inputs = ["ext_vector_http_normalize_http"] version = "2" hooks.init = "init" hooks.process = "process" source = ''' function init() count = 0 end function process(event, emit) count = count + 1 event.log.openshift.sequence = count if event.log.kubernetes == nil then emit(event) return end if event.log.kubernetes.labels == nil then emit(event) return end dedot(event.log.kubernetes.namespace_labels) dedot(event.log.kubernetes.labels) emit(event) end function dedot(map) if map == nil then return end local new_map = {} local changed_keys = {} for k, v in pairs(map) do local dedotted = string.gsub(k, "[./]", "_") if dedotted ~= k then new_map[dedotted] = v changed_keys[k] = true end end for k in pairs(changed_keys) do map[k] = nil end for k, v in pairs(new_map) do map[k] = v end end ''' [sinks.ext_vector_http] type = "http" inputs = ["ext_vector_http_dedot"] uri = "http://vector-http.tkimura-infra.svc:8080" method = "post" [sinks.ext_vector_http.encoding] codec = "json" [sinks.ext_vector_http.buffer] when_full = "drop_newest" [sinks.ext_vector_http.request] retry_attempts = 17 timeout_secs = 10 # Bearer Auth Config [sinks.ext_vector_http.auth] strategy = "bearer" token = "eyJhbGciOiJSUzI1NiIsImtpZCI6Im03RElRbTF6ZXdvU01mQ3lRcGZUUTZWUXRlVVJ1WHJtdWlVaUo0Y0tmSUUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJvcGVuc2hpZnQtbG9nZ2luZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJsb2djb2xsZWN0b3ItdG9rZW4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoibG9nY29sbGVjdG9yIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMjk1N2NjNDAtZTRjNS00YzMzLWE2MGQtMGFiZDU5ZGRjMGJlIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Om9wZW5zaGlmdC1sb2dnaW5nOmxvZ2NvbGxlY3RvciJ9.OTVa3zjpdEUCPmQ2vru3UexUBsp63cb6wZWOLdM0cPKAYRj-clibbFa36WBV9OG__L0ujRVnPBBetkh1r9QwO4HpOPCi7owlcDWn_yOc3_tEVsWge5LZT28QEVm2vQh4n_sON1HRcwmnYKqJVMOStpD6WjIW9tIADai9RlW-d47iumC6j8eqXVF1zY-N09jkLAA3ZuBXqBpPmI4W24FZOlPmEAEGwE--H8dYxUjwheD12e1EntYBOjRpnUb9Sx86GqOnG1LIbfb3jv0MbndOFs7kIbus2Xc516OaHoFJfEoxl-SMxGdKcCOtm38S5ikpsfEC6LfcapTV0mg5JitpgOJI9QiUDwZ8ClOKk0z1JxNQQJcJPjg1zy0OjqZrSeIS4TqdzLsAUrA-tuu7HWpbKlwuNVNiLBqKw8N3JqTTEK3j0WeVvEYlBacZsyCBpfH8Vt8234r9ckbs67278tniUmQ5Y-4Y8ybEUjp6cIcs28T13DGfQmWOftlBgltTAmvpXAUCgBu6bTPXZLXCCmCs5VzTfK8W9NcVjOp-fmyIYVm2uBY1mSw5WXIP15I8FCsa22zzMXlGPU1IIDQuNQJCFvGQxeeWa0rZP5T_8wxjhi6tScJHh_XTKcx8sxKJHagYmIvYfF39oI0ZCo_pdCTI5EZ990JiFch5-dVv3zBzIyc" [transforms.add_nodename_to_metric] type = "remap" inputs = ["internal_metrics"] source = ''' .tags.hostname = get_env_var!("VECTOR_SELF_NODE_NAME") ''' [sinks.prometheus_output] type = "prometheus_exporter" inputs = ["add_nodename_to_metric"] address = "[::]:24231" default_namespace = "collector" [sinks.prometheus_output.tls] enabled = true key_file = "/etc/collector/metrics/tls.key" crt_file = "/etc/collector/metrics/tls.crt" min_tls_version = "VersionTLS12" ciphersuites = "TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-RSA-CHACHA20-POLY1305,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-GCM-SHA384" また、以前のFluentdではディスクバッファを利用する設定でしたが、Vectorではディスクを利用しないメモリバッファ設定となります。理由はいくつかあり、リソース消費が大きく遅い、遅いのでログが消失する、単に無駄、というものが大きな理由です。 ディスクバッファ設定では、ディスクバッファに一度書いてから転送してバッファ削除、という処理となります。入力がネットワーク受信したログなどであれば合理的な構成ですが、入力がディスク上のログなので、それを読み込んでもう一度ディスクに書き込むのは大きな無駄です。基本的には元となるコンテナログの保持サイズ、期間を伸ばせば済むところです。当然処理が多くなるので、パフォーマンスが低く、CPUやメモリの消費量が大きくなり、かつ転送処理が大幅に遅くなります。ログ出力レートが高いと転送が追いつかなくなり、バッファがフルになり入力がブロックされ(もしくはダイレクトにログ転送破棄が行われ)、その間にもログローテーションが発生すると転送されないログが発生してログ消失となります。ログ出力が多い、nodeあたりPod数が多い、などの条件で顕著にログ消失が発生してしまいます。言い換えると、Fluentd構成でログ消失をなるべく防ぎたい、という場合はノード一台あたりのログ出力レートを小さく保つ必要があるため、多数のコンテナが稼働する大きいサイズのノードを利用することができなくなります。 対してメモリバッファでは単純な強制終了で少量のログが転送されず消失するリスクがある、という点はありますが、上記の問題はすべて回避でき、また以前のFluentdの構成と比べて何十倍という単位で高速で動作するので、リスクとなる「転送処理中のログ」自体が非常に小さく保てます。Vectorにもdisk bufferオプションはありますが、500msインターバルでメモリを永続化する非同期のモデルとなっており、同期ではないので、ディスクバッファ設定を行ったとしても耐障害性ではメモリバッファとあまり大差はなさそうです。 たとえばもし強制終了が多く発生する、そのときにログ転送のログ消失は防止したい、といった特殊な前提条件があるのであれば、Vectorはその要件を満たすことはできなさそうですので、OpenShift LoggingのVectorではなく自前でログ収集エージェントを選定して設定したほうが良いでしょう。 検証していても、以前のFluentd設定では初期設定からログが収集されるまで小一時間待つ必要がありましたが、Vectorでは一瞬で全ログが転送されるのが便利です。

レッドハットでインテグレーションのためのミドルウェアのテクニカルサポートを担当している山下です。以前、SAGAやEventStormingについて記述すると宣言していたのですが、実際のところ私が書くよりもよっぽど良い日本語の書籍や記事がでていて、もう書く必要もないと思っていたのですが、今回機会をいただいたので約４年ぶりに”マイクロサービスとメッセージングのなぜ"の希望編を書くことになりました。今回の記事ではSAGAやEventStormingの詳細は書かないのですが、私がイベントやメッセージングが必要と考えるに至った危機感や希望を共有します。そうした意味ではむしろ原点ともいえる内容になっています。なお今回記事にはとりわけ個人的な経験や意見が多く含まれますので、事前に異論は認めることにします。 以前の記事はこちら： 「 マイクロサービスとメッセージングのなぜ [概要編] 」 「 マイクロサービスとメッセージングのなぜ [疑問編] 」 終わりのなく続く名詞集めとモノリシックなモデル リレーショナルデータベース中心アーキテクチャによってプロジェクトを進めてきた方は私を含め多くいらっしゃるのではないでしょうか。様々な方法がありますが、それは例えば、ユースケースから名詞を拾い集め、データ中心によるモデル、とりわけデータ構造を定義していく方法があります。 要件やビジネスプロセスを分析して、ユースケースの詳細を記述したユースケース記述では、システムがどのように使用されるかをユーザーや外部システムの視点から記述します。そこでは画面UIなどからシステムへのクエリやコマンドで利用される具体的な名詞（≒ データ）が記述されています。そしてそれらの名詞を洗い出してデータの正規化を行ない、そうしてできたデータ構造はER図やメソッドが省略されたクラス図に落とし込んでシステムの骨格を形づくっていきます。データ構造が決まれば、それらを利用する処理を配置するクラスは自ずと明らかになるので、プロラミングではデータ構造に肉付けするように開発を進めていくことができるようになるのです。 おそらくこれは現在でも最も実践的な方法の１つであり、適したプロジェクトも数多くあります。実際私もこうした方法を実践してきました。この方法に一概に問題があるというつもりは全くないのですが、しかし限界もあります。 変更コストは高い、事前に予期して完璧なモデルを作成する こうしたデータ構造のモデルは画面などと比べれば安定しているともいわれたりしますが、とはいえシステム要件が追加されることで変わっていくことはよくあり、実際のところ安定しているなどとはとてもいえないものです。また些細なように見える追加要件がドラスティックにデータ構造のモデルを変えて、そこから各種の設計書やUIに変更が波及し続ける開発を自分を含め多くの方が経験しているでしょう。データ構造の変更はそれに依存した多くの実装への修正を伴うために、大きな手戻りやコストを伴います。ですから、どれだけ要件を予め洗い出すことができるのか、また顧客のニーズを予期して、できるだけ事前にモデルに取り入れることに努めて、実装に進む前により完璧なモデルを追求することになります。 境界なくフラットに広がり続けるデータ構造のモデル より完璧なモデルを追求する中で、様々な要件や一見して想定しえないような例外的な要件であったとしてもモデルはそれを飲み込み続けなければなりません。なぜなら想定されなかった要件や事実をモデルは受け入れず、その事実自体がむしろ存在しなかったように否定されてしまうからです。”一度の注文でも発送は数回に分割することが時々ある”、“あとから当時の状況がわかるように履歴を作りたい”、”棚下しの中でで発送したはずの商品がバーコードで検出された”、どれも胃が痛くなってきます。こうして、様々なドメインを巻き込みながら、履歴/事実、状態、例外状態、あらゆるコマンドやクエリに対応して、境界なくフラットにデータ構造のモデルは広がり続けます。 ブロックされる開発 広がり続けるモデルの一方で、要件をできるだけヒアリングして網羅しモデルやデータ構造が十分に納得できるまで、開発が進められないといったことが起こります。後戻りのコストは高くつくために、モデルがより完璧でなければならないのです。とはいえどこかで区切りをつけて開発を開始しなければなりません。逆算してプロジェクトのデッドラインが許すまでの分析を続けることになります。そして開発が始まった後には、データ構造のモデルが変化するような要件が発覚しないよう、不安を抱えながら祈り続けるのです。 モノリシックなシステムに突き進む 名詞集めは十分に実践的ですが、様々な要件のクエリやコマンドから名詞を洗い出し、それらすべての整合性を保ったデータ構造を設計し続けなければなりません。新たな要件を満たすように少しづつ巨大化していくデータ構造のモデルは、フラットに広がり続けます。モデルは想定を超えて大きくなり、その大きな役割をますますリレーショナルデータベースに頼るようになります。実際のところ様々な要件を満たす完璧なモデルには近づくことさえ難しいことも多くの方はご存知でしょう、新しい要件の統合はより難しさ増していきます。しかし整理したり分割しようとしても、データベース中心アーキテクチャで確立されたモデルを分割することは、ソフトウェア開発における最も高価なリファクタリングの1つです。後戻りもできないままに、重箱の隅をつつくように名詞を集め続け、より完璧なモデルを追求しながらモノリシックなモデル、そしてモノリシックなシステムへと突き進み続けることになります。 イベントを集めるEventStorming 上記のような名詞を集める方法に対して、イベントを集めるEventStormingという方法があります。これはポストイットを使ったコラボレーションワークショップで、イベントを中心としたアプローチが特徴です。EventStormingの目的には、ドメインを理解するための学習やチームワーク、問題発見や解決策の創出、ビジネスプロセスの可視化や、境界づけられたコンテキストや集約の識別などがあり、それらの目的に応じて様々なテクニックや手法を調整して利用します。 出典: https://openpracticelibrary.com/practice/event-storming/ ここではEventStormingの詳細は説明しませんが、大まかには以下のような手順で進みます。 1. イベント（オレンジ色のポストイット）を洗い出す まずビジネスプロセスに関連するイベントを、大まかな時系列に沿って洗い出していきます。イベントは通常「～した」という過去形あるいは過去分詞形の形式で記述され、システムに関連した事実を表します。イベントは、ユーザーの操作、外部システム、時間、他のイベントなどから発生しますが、しかしとりわけこの時点では特定の発生元に囚われることなく当該のドメイン内で発生している事実を洗い出していきます。またイベント名に過去の時制の動詞を使用して、状態遷移に焦点を当てることで、その推論からドメイン全体の探索へ繋げていきます。 2. コマンド(青色のポストイット)の特定 各イベントをトリガーするコマンドを特定します。コマンドはアクターの判断の結果として行われるシステムへの指示で「～する」という形式で記述されます。なおアクターは黄色のポストイットで表します。 3. リードモデル(緑色のポストイット)の追加 アクターがコマンドを実施する際の判断に必要な情報をリードモデルとして追加します。リードモデルは、データの表示や分析に特化したモデルでクエリ操作のために利用されます。 4. ポリシー（ライラック色のポストイット）の追加 何らかのイベントが発生した時にコマンドを発行するルールとしてポリシーを追加します。これらは「〜(何らかのイベント) するときはいつでも」で始まることも多く、システムが自動的に行うことや、人が記憶しておくべきことなどを表します。 5. 集約（大きな薄黄色のポストイット）の識別 関連するイベントやコマンド群、ビジネスルールやトランザクションによるデータ整合性を維持するための集約を識別します。集約はドメインモデルの一部で、データと処理をカプセル化した責務を持つ単位です。集約は、イベントソーシングの文脈ではデータの書き込みに特化したライトモデルに対応し、コマンドに対して異なる応答をするので、小さなステートマシンのようにみえることもあります。 6. 境界づけられたコンテキストを定義する 言葉や意味の一貫性の程度が高いグループ、同時に変更される可能性が高い機能のまとまりから、境界づけられたコンテキストを定義します。モデルの一貫性は境界づけられたコンテキスト内のでのみ達成でき、そのモデルは限界を超えて大きくすることはできません。意味の一貫性の程度が高い複数の比較的小さなモデルを目指します。 集約の定義は意図的に延期されている EventStormingでははじめにイベントを集めていく一方で、集約の識別は手順の終わりの方になるまで意図的に延期されます。ビジネスプロセスやシステムの振る舞いを十分に理解した後に、コマンドやイベント、ポリシーなどを頼りにして、責務に基づいた精度の高い集約のモデリングが可能になります。私たちはモデルの内部構造について画面上で見たいものを重ね合わせ、名詞を集めてくる習慣によって、責務ではなく背後にあるデータの正規化から暗に集約を見つけようとしてしまうことがあります。しかしそうすると同じ識別子(ID)に紐づくデータとそれに関連するイベントやコマンドまでも引きづられて塊になり、集約が肥大化して分割が難しくなるので注意してください。 イベントを集めてもっと小さく柔軟で進化するモデルへ リードモデル、集約(ライトモデル)、イベント EventStormingではリードモデルと集約(ライトモデル)の２つの役割のモデルがあります。また事実や履歴についてはイベントに任せることができるでしょう。さらには境界づけられたコンテキストごとに必要な機能や責務によってもモデルを分割できる柔軟性があります。 これらは基礎としてイベントが存在していることによって実現されます。マイクロサービスのような小さく独立したサービス間での連携が行えるほか、データ転送によって統合された表示用のリードモデルを実現することができます。またシステムの状態変化をイベントとして蓄積（イベントソーシング）すれば、イベント自体が事実や履歴となり、またモデルの変更があっても過去のイベントの蓄積から再評価して新しいモデルへと柔軟に進化させることができます。さらには過度な要件をモデルに取り込まないという選択ができることもあります。例えば本来想定しえないような稀で例外的な要件は、イベントに保存しておき、集約(ライトモデル)には取り込まずに例外のレポートを出力させるに留めるといった方法もありえます。 境界づけられたコンテキストによる分割 また境界づけられたコンテキストにより、同じ識別子(ID)を共有するエンティディであったとしても、それぞれに特化したモデルに分割できることもあります。例えば一口に"ユーザ"という同じ識別子(ID)を共有するエンティティであったとしても、境界づけられたコンテキストが異なれば、受注では購入者、請求では請求先、出荷では配送先、CRMでは顧客、システム上ではログインユーザといった具合に独自のモデルによってデータや機能が異なることがありえます。 上記は単純な例ではありますが、これらは同じユーザIDを持ちながらも、境界づけられたコンテキストごとに異なるデータや振る舞いを持った集約として分割されました。ところで集約はトランザクションによるデータ整合性を維持する単位でもあるため、更新時の排他制御やロックも考慮することになります。一般的にはレコード単位を集約ルートのインスタンスして、そこにロックをかけてデータ整合性を確保することが多いでしょう。しかし例えばログインユーザの場合にはログインユーザ名やメールアドレスが全体の中でユニークでなければならないといった要件を実現するために縦にカラム一式を排他制御するするシングルトンの集約にすることも考えられるかもしれません。レコードによる主キーや正規化にばかりに気を取られずに、集約の振る舞いに注目すれば、もっと自由な視点でモデルを分割できる可能性が広がります。 イベントを導入することで、システム内のサービスは小さな独立したモデルに分割され、それぞれが特定イベントに反応して動作するようになります。そして各モデルが新しい要件に柔軟に対応でき、全体のシステムを複雑化することなく進化し続けることができます。 まとめ 今回は、ソフトウェア開発における名詞を集めてデータ構造を定義していくアプローチと、EventStormingによるイベント集めのアプローチについて説明しました。名詞を集めてデータ構造を定義していく方法は十分に実践的で、それが適したプロジェクトも数多くあります。しかしあらゆる要件を満たすように少しづつ巨大化して、柔軟性に欠けたモノリシックなシステムへと突き進み続けることになる可能性があります。 一方、EventStormingによるイベント集めのアプローチでは、イベント、コマンド、リードモデル、ポリシー、集約などを用いて、ビジネスプロセスを理解し、より柔軟で適応性の高いモデルを構築します。またリードモデルや集約（ライトモデル）、イベントなど異なる役割を持ったモデルに分割され、さらには境界づけられたコンテキストごとに必要な機能や責務によってもモデルを分割できる柔軟性があります。こうした分割により新しい要件に対して柔軟に対応でき、全体のシステムが過度に複雑化することなく個別に進化し続けることが可能になります。イベントやメッセージングはマイクロサービスには欠かすことができないものです。 私がイベントやメッセージングが必要と考えるに至った危機感がいくらかでも共有しできたでしょうか。名詞を集めてデータ構造を定義していく方法ははじめはパズルを解くような楽しさもありますが、選択肢が少なく、どこか予め決められた道を歩かされているような窮屈さがあります。それはレールが続いているのか崖になっているのかも分からないジェットコースターにチーム全体がのって進まされているような恐怖とでもいいましょうか。要件が複雑であったりシステムが進化していくことを前提とすると、こうした名詞集めによるモノリシックなモデルにはずっと限界を感じてきました。より完璧なデータ構造を求めて残業を続けたことも、大きな手戻りを恐れて名詞を集め続けながら開発フェーズに進めなかったことも、データ構造のモデルが変化するような要件が発覚しないよう不安を抱えて祈り続けたことも、これらは全て自分の苦い経験ではありますが、おそらく責任ある多くのエンジニアにも似た経験があるのではないかとも思います。イベントやメッセージングにも特有の難しさはあり、手放しで簡単だというつもりはありませんし、確実な未来もわかりません。しかしこの希望編から、もっとモデルに選択肢があるかもしれない、もっと柔軟にモデルを描いてもいいかもしれない、イベントやメッセージングを導入してもよいかもしれない、と少しでも考えるきっかけになれば幸いです。 参考文献 Introducing EventStorming Microservices Patterns Enterprise Integration Patterns Exploring CQRS and Event Sourcing [PR] オープンソースの Apache Kafka をベースとした製品として、Red Hatから AMQ Streams が提供されています。 AMQ Streams にはさらに、KubernetesやOpenShiftの上でApache Kafkaの運用の自動化を実現する、オープンソースの Strimzi をベースとした機能も含まれています。Red Hat製品に興味ない方もKubernetesを利用している方は Strimzi をぜひ使ってみてください。

OpenShift Advent Calendar 2023 / AWS Containers Advent Calendar 2023 の12/14の記事です。 Red Hatの小島です。 2023年12月に、Managed OpenShiftサービスの1つであるROSAを無料で試せる ROSA Hands-on Experience というサービスがリリースされました。本記事では、同時期に提供開始しましたROSA Hosted Control Plane (HCP)の特徴と共に、ROSA Hands-on Experienceの概要をご紹介します。 ROSA Hosted Control Plane (HCP) ROSA HCPの料金情報 ROSA Hands-on Experience ROSA HCPワークショップ日本語コンテンツ ROSA Hosted Control Plane (HCP) ROSA HCPは、OpenShift 4.14のベアメタルおよびOpenShift Virtualizationで正式にリリースされた Hosted Control Plane が取り入れられたROSAです。ROSA HCPでは、OpenShiftのコントロールプレーンがRed Hat SREチームのAWSアカウントに作成されるOpenShiftクラスターのPodとしてデプロイされるようになり、ユーザーのAWSアカウントにはワーカーノードのみデプロイされます。これによって、ユーザーにはコントロールプレーンが隠蔽されてワーカーノードしか見えなくなる、というシンプルな構成になりました。 ROSA HCPは、コントロールプレーン/インフラノード/ワーカーノードが全てユーザーのAWSアカウントに作成される従来のROSA(ROSA Classicと定義しています)に比べると使い勝手がかなり向上しており、次のような特徴を持つため、Kubernetesインフラ観点ではAmazon EKSなどのManaged Kubernetesサービスに近いものとなっています。 最小構成がワーカーノード2台構成 (SingleAZ/MultiAZ共通。デフォルトはm5.xlarge(4vCPU/RAM16GiB) x2) クラスターデプロイ時間の短縮 (ROSA Classic: 40分~。ROSA HCP: 25分~) ワーカーノードをAZ単位で1台から追加可能 (SingleAZ/MultiAZ共通) ワーカーノード追加時のバージョン選択が可能 コントロールプレーンの更新時間の短縮 (ROSA Classic: 90分ほど。ROSA HCP: 15分ほど) コントロールプレーンとワーカーノードの更新の分離 一部のワーカーノードのみを更新するという部分更新の対応 これらのインフラ的な特徴に加えて、 コンテナアプリケーションの開発/運用を支援するための様々な機能 アプリケーションのトポロジー/モニタリング/ロギングを利用するためのWebコンソール Visual Studio Code的なWeb IDE (AI搭載生産性向上ツールである Amazon CodeWhisperer プラグインも利用可能) 様々なフォーマットの入力に対応した、アプリケーションビルド/デプロイの自動化 Gitリポジトリのソースコード/Dockerfile, コンテナイメージ, JARファイルなど アプリケーションのベースOSとなるRHELのサポート Red Hatのパートナーエコシステムによる、様々なミドルウェアのサポート (Kubernetes Operator含む) 上記機能をマルチテナント的に利用するための、外部認証プロバイダーとの連携 エンタープライズシステムとして利用するための、Kubernetes基盤のセキュリティ強化 (コンテナアプリでのroot利用禁止など) といったOpenShiftならではの特徴も備えているため、エンタープライズ用途にパッケージングされたManaged KubernetesサービスをAWS上で利用したい場合に、ROSA HCPが適したサービスであると言えます。 ROSA HCPの料金情報 ROSA HCPを利用する場合、次の3つの合計金額がAWSからユーザーに請求されます。Red Hatからの請求料金はありません。 ROSA HCPのクラスター料金 (1クラスター辺りの料金。0.25USD/cluster/時間) ワーカーノードのサービス料金 (0.171USD/4vCPU/時間) AWSリソースの利用料金 (ワーカーノードのEC2インスタンス, EBS, S3, NAT Gatewayなど) デフォルトはm5.xlarge(4vCPU/RAM16GiB)インスタンスの2台構成となりますので、AWS料金情報に基づいて、オハイオリージョンでのSingleAZ2台構成の1時間辺りの利用料金を計算してみると、大体の目安は $1.3/時間~ となります。主なAWSサービスの料金内訳は次のようになります。計算の簡単化のために、料金内訳からはS3やデータ転送などの利用料金を除いています。 クラスター料金 $0.25 (0.25(USD/cluster) x 1(cluster)) ワーカーノードのサービス料金 $0.342 (0.171(USD/4vCPU) x 2(4vCPU)) ワーカーノードのEC2/EBS(300GiB x2)の利用料金 $0.467 (0.192(USD) x 2 + 0.1(USD/GB/month) x 300(GB) / 720(時間/month) x 2) NAT Gatewayの利用料金 (プライベートサブネット1つに付き1つ作成されます) $0.045 NLBの利用料金 $0.0225 コントロールプレーンとインフラノードも料金請求の対象であった従来のROSA Classicと比較すると、かなりスリム化した料金となっています。なお、ROSA HCPでは、インフラノードとしてみなされるワーカーノードはありません。ルーター/レジストリ/モニタリングなどのコンポーネントは全てワーカーノード上で稼働し、全てのワーカーノードの利用料金が請求されることになります。 ROSA Hands-on Experience 本題です。 ROSA Hands-on Experience は、Red Hatのデモプラットフォームを利用して、ユーザーが無料でROSA HCPクラスターにアクセスして、ハンズオンができるサービスです。Red Hatアカウントでログインして「Request experience」をクリックすると、大体数十秒でデモプラットフォーム上のROSA HCPクラスターにアクセスできるようになっています。このサービスを利用する場合、AWSアカウントをご用意いただく必要はありません。 また、この画面からROSAコミュニテイのSlackチャネル(英語)に参加できるだけでなく、ハンズオン中に質問がある場合、画面右下のRed Hatロゴをクリックすることで、Red Hatのカスタマーサクセスチームと英語チャットができるようになっています。 デモプラットフォームにアクセスすると、次のような画面が表示されます。ユーザーは画面左半分のコンテンツに表示されるコマンドを、画面右半分のTerminalにコピペして、ROSA HCPクラスターを操作していく流れとなります。また、ROSA HCPクラスターの管理者アカウントで、Webコンソールにログインして利用できるようにもなっています。これらのコンテンツは全て英語となっているため、必要に応じてWebブラウザの機械翻訳機能を使ってください。 2023年12月時点での、ROSA Hands-on Experienceのコンテンツは下記の16項目です。ROSA特有の項目だけ学習したい場合は、 1. Explore the ROSA environment から 6. Configure Red Hat SSO IDP for ROSA までだけを実行してもいいでしょう。 ・ROSA特有の内容を含むコンテンツ Explore the ROSA environment Upgrade your ROSA cluster Managing Worker Nodes Autoscale your ROSA Cluster Labeling your Worker Nodes Configure Red Hat SSO IDP for ROSA ・ROSAだけでなく、Self-Managed OpenShiftでも実行可能なコンテンツ Configure Red Hat OpenShift Logging with AWS Cloudwatch Deploy an Application with AWS Database Deploy an Application with Red Hat OpenShift GitOps Secure your applications with Network Policies Make your application resilient Service Mesh Introduction Install Service Mesh Operator Deploy Service Mesh Control Plane Deploy a Service Mesh example application Configure and observe Service Mesh traffic なお、ROSA Hands-on Experienceについては、 8時間/1回の利用を3回まで(延べ24時間) という制限があります。4回目以降の利用はできませんので、ご注意ください。 ROSA HCPワークショップ日本語コンテンツ 上記を翻訳したコンテンツではありませんが、主にROSA HCP特有の項目にフォーカスして、ROSA HCPクラスターでのアプリケーション開発/運用の基礎を体感していただくための日本語コンテンツ(下図の「ROSA Lab」と記載しているもの)も別途提供しています。この日本語コンテンツを参考にしながら、ROSA Hands-on Experienceで払い出されたROSA HCPクラスターでハンズオンを実施することもできます。ただし、その場合は次の制限がありますのでご注意ください。 この日本語コンテンツは、Red Hatのカスタマーサクセスチームの管理下にないため、チャットやSlackでの質問はできません。 ROSA HCPクラスターの作成手順は実行できません。 ROSA Hands-on ExperienceではAWS IAMユーザーを払い出さないため、この日本語コンテンツで紹介しているCloudWatchでのロギング設定/確認手順は実行できません。 ワーカーノードについては、既存のMachinepool(ROSAでワーカーノードを扱う単位)についてのみ編集(ワーカーノードの追加/削除/オートスケール化/更新など)できます。そのため、新規Machinepoolの追加や削除は実行できません。 最新版のROSA HCPクラスターが払い出されている場合、ROSA HCPクラスターの更新手順は実行できません。 ROSA HCPワークショップ日本語コンテンツは、下記のリンクからご参照ください。 rh-open.github.io このワークショップ日本語コンテンツについては、ご要望次第で個社向けにも開催しています。ご興味がありましたら、Red Hatの担当営業や下記の「購買専用のお問い合わせ」フォーム(「追加情報」記入欄に「赤帽ブログで見た個社向けROSA HCPワークショップについての詳細を希望」などをご記入ください)からお問い合わせください。 www.redhat.com