こんにちは。Red Hatでソリューションアーキテクトをしている杉本 拓です。 先日行われた Red Hat Summit 2022 では、Red Hatが注力しているマネージドサービスに関する ビジョンやロードマップ について発表がありました。また、 Open Hybrid Cloud Week 2022 の私のセッション[「アプリケーション開発を効率化する！Red Hatミドルウェア製品とマネージドサービスの最新情報」]でもRed Hatのマネージドサービスを紹介をしています。 今回の赤帽ブログでは、そのRed Hatのマネージドサービスとしてどのようなものがあるのか、そしてそのマネージドサービスの始め方について紹介したいと思います。 Red Hat Cloud Servicesとは Red Hat Cloud Services は以下の3つのカテゴリに分類されます。 Managed OpenShift (Platform Services) Application Services Data Services Managed OpenShiftはマネージドのコンテナ基盤としてパブリッククラウドベンダーからも既に提供が開始されており、利用されているお客様も多くいます。ただクラウドネイティブなアプリケーションを開発していくためにはコンテナ基盤があればいいという訳ではなく、そのコンテナ基盤上でマイクロサービスを効率的に開発したり、APIを管理したり、イベント駆動型のアーキテクチャでサービス間の連携を疎結合にしたり、リアルタイムなデータ連携を行ってデータの利活用を行っていくことができるようなアプリケーション開発のためのプラットフォームというものが必要になってきます。 Red HatのApplication ServicesとData Servicesは、Managed OpenShiftの上で動作し、そのようなアプリケーションプラットフォームを実現するためにRed Hatが提供するマネージドサービスで、以下のサービスが含まれています。 Application Services: Red Hat OpenShift API Management Red Hat OpenShift Streams for Apache Kafka Red Hat OpenShift Service Registry Red Hat OpenShift Connectors Data Services: Red Hat OpenShift Data Science Red Hat OpenShift Database Access 図1: Red Hat Cloud Servicesの全体像 Red Hat Application and Data Servicesのご紹介 ではそれぞれのサービスについて概要を紹介したいと思います。 Red Hat OpenShift API Management Red Hat OpenShift API Management はManaged OpenShift上で動作するRed HatマネージドのAPI管理サービスです。API管理の機能をOpenShift上ですぐに始められるので、APIファーストのアプローチとアプリケーションのマイクロサービス化を進めることができ、顧客により早くデジタルサービスの価値を提供し、それに関わる運用コストを削減することができるようなサービスです。 OpenShift API ManagementはRed HatのAPI管理製品である 3scale API Management をベースとしており、マネージドのOpenShift環境でOpenShiftのアドオンとしてインストールして、利用することができるようになっています。3scaleと同様に、API管理の設定を行うためのAPI Managerと実際にAPIのトラフィック制御が行われるAPI Gatewayの2つのコンポーネントに加えて、オープンソースのシングルサインプロジェクトである Keycloak をベースとした Red Hat Single Sign-on が含まれています。このAPI管理のインフラはRed HatのSREが運用管理を行いますので、利用者はAPI管理のインフラ運用から開放されてAPIで提供するビジネス的な価値にフォーカスすることができるようになります。 図2: Red Hat OpenShift API Management概要 Red Hat OpenShift Streams for Apache Kafka Red Hat OpenShift Streams for Apache Kafka は、ストリーム処理をするアプリケーションのためのフルマネージドな Kafka のサービスです。データをバッチで処理するのではなく、リアルタイムなストリーム処理をするためにApache Kafkaの採用が進んでいますが、Kafkaのクラスタ環境を構築し、運用するのは複雑で面倒な点が課題です。このOpenShift Streams for Apache Kafkaのサービスでは、Kafkaクラスタがマネージドサービスとして提供されており、Red HatのSREがグローバルでサポートし、99.95%のSLAで提供されているので、利用者は運用コストを削減し、運用の複雑さを軽減することができるようになります。 このマネージドのKafkaとRed Hatのミドルウェア製品や他のマネージドサービスを組み合わせることで、オンプレミスやハイブリッドクラウド環境にまたがって大量のデータをリアルタイムに処理したり、データ連携を行うための基盤を構築することがすぐに実現できます。 図3: Red Hat OpenShift Streams for Apache Kafka概要 Red Hat OpenShift Service Registry OpenShift Service Registry は、イベントのスキーマ情報やAPIの定義情報を一元管理することができるようにするためのマネージドサービスで、OpenShift API ManagementとOpenShift Streams for Apache Kafkaと組み合わせて利用することで、API管理やデータ連携を更に効果的に行うことができるようになります。 Service Registryを使うことのメリットとして、APIドキュメントとスキーマを一元的に管理できるので、サービスの再利用性を向上させ、アプリケーション開発のスピードを上げることができるという点があります。 もう一つのメリットは、スキーマエボリューション（スキーマの進化）への対応ができるという点で、アプリケーションの改修や機能追加に伴ってスキーマ定義を変更する必要性が出てくることがありますが、変更される前後でその互換性を考慮する必要が出てきます。このService Registryでは、Apache AvroやJSON Schemaなど主要な業界標準のフォーマットに対応してデータのバリデーションを行ったり、互換性のチェックを行って、スキーマエボリューションに対応することができるようになります。 Apache Kafkaをデータ連携のハブとして使用する場合、このスキーマエボリューションへの対応という点においてこのService Registryは非常に重要な役割を持っていますが、Red Hatではそれをマネージドサービスとして提供しており、OpenShift API ManagementあるいはOpenShift Streams for Apache Kafkaの付加サービスとして無料で利用可能になっています。 図4: Red Hat OpenShift Service Registry概要 Red Hat OpenShift Connectors Red Hat OpenShift Connectors はOpenShift Streams for Apache Kafkaと連携して動作する、事前に定義済みのコネクターのマネージドサービスで、ハイブリッドクラウド環境でデータ連携をする際の複雑さを軽減し、Time to Marketまでの時間の短縮を実現することが可能です。 このコネクターのサービスは、オープンソースのプロジェクトである CDC (チェンジデータキャプチャ) の Debezium とサーバーレスなインテグレーション機能を提供する Camel K をベースとしています。OpenShift Streams for Apache Kafkaと接続するためのSourceコネクタとSinkコネクタが50以上用意されており、このコネクターサービスを利用することで、開発者はコーディングすることなく、セルフサービスでデータ連携の設定や削除を行うことができるようになります。 なお、この記事執筆時点の2022年6月では、まだサービスプレビューとしての提供です。 図5: Red Hat OpenShift Connectors概要 Red Hat OpenShift Data Science Red Hat OpenShift Data Science はマネージドのOpenShift上で動作するマネージドのAI/MLのためのサービスです。オープンソースのAI/MLプロジェクト Open Data Hub をベースとし、データセンターからクラウド、エッジに至るまで、柔軟でスケーラブルなAI/MLの導入を進め、データサイエンスを行うための基盤となるマネージドサービスです。Jupyter NotebooksやTensorFlow、PyTorchのようなデータサイエンス関連のツールや機械学習のフレームワークが含まれているのですぐにデータサイエンスを始めることができますが、様々なISVパートナーのソフトウェアと組み合わせて、お客様のニーズに応じたAI/ML基盤を構築することが可能になっています。また、OpenShiftの機能を活用してインテリジェントなAIアプリケーションの開発プロセスを自動化することができ、AI/MLのライフサイクルのイテレーションを高速化することができるようになります。 また初期リリースでは対応していませんが、今後GPUアクセラレーションにも対応する予定です。 図6: Red Hat OpenShift Data Science概要 Red Hat OpenShift Database Access Red Hat OpenShift Databases Access は、マネージドのOpenShift上でISVパートナーが提供するデータベースサービス、Database as a Serviceを利用することができるようにするためのサービスです。このDatabase Accessのサービスを利用することで、開発者はセルフサービスで利用したいデータベースへの接続を設定でき、アプリケーションの開発とデプロイを効率化することができるようになります。 なお、この記事執筆時点の2022年6月では、まだサービスプレビューとしての提供です。 図7: Red Hat OpenShift Databases Access概要 Red Hat Application and Data Servicesの始め方 Red Hatでは、このようにマネージドサービスの提供を通じてクラウドネイティブなアプリケーション開発をサポートしており、これらのマネージドサービスはトライアルで無料ですぐに試すことができます。クイックスタートガイドやチュートリアルも用意されているので、これらのマネージドサービスを実際にどのように使ったらいいのかも体験することができるようになっています。 トライアルを始めるには、 Red Hat Hybrid Cloud Console にアクセスしてログインしてみましょう。Red Hatアカウントが必要になりますのでお持ちでなければ作成してからアクセスしてみてください。 Red Hat Hybrid Cloud Console にログインし、左のナビゲーションメニューで Application and Data Services > Overview を選択すると、利用可能なマネージドサービスの概要一覧が表示されます。各マネージドサービスのメニューを選択し、利用を始めることができるようになっており、各マネージドサービスにはチュートリアルも用意されているので、すぐに試すことができるようになっています。マネージドサービスにはManaged OpenShiftのアドオンとしてインストールされるものと専用のOpenShiftクラスタが作成されるものがあるため、サービスの種類によって利用方法が若干異なります。 図8: Red Hat Hybrid Cloud Console画面 Red Hatのマネージドサービスは、 Red Hat Hybrid Cloud Console で管理することができるようになっており、以下のサービスについてはこの管理コンソールからインスタンスを作成して、すぐに始めることができるようになっています。 Red Hat OpenShift Streams for Apache Kafka Red Hat OpenShift Service Registry Red Hat OpenShift Connectors なお、OpenShift ConnectorsはOpenShift Streams for Apache Kafkaに対するコネクターとして動作するため、以下の画面のようにOpenShift Streams for Apache KafkaのKafkaクラスタを作成する必要があります。 図9: Red Hat OpenShift Connectors設定画面 また、以下のマネージドサービスはOpenShiftのアドオンとしてインストールされるため、OpenShiftクラスタがまだ登録されていない場合には、Red Hat Hybrid Cloud Consoleの OpenShift管理画面 でOpenShiftクラスタを作成する必要があります。 Red Hat OpenShift API Management Red Hat OpenShift Data Science ただし、Red Hatが開発者向けに無償で提供する OpenShiftのDebeloper Sandbox環境 を使用すれば、自分でOpenShiftクラスタを作成しなくてもすぐにOpenShift API ManagementとOpenShift Data Scienceを始めることが可能です。 OpenShift API ManagementをDeveloper Sandbox環境で始めるには、 こちらのリンク にアクセスし、[Launch your Developer Sandbox for Red Hat OpenShift API Management]のボタンをクリックしてSandbox環境を作ることができます（Red Hatアカウントが必要になります）。 図10: Red Hat OpenShift API ManagementのDeveloper Sandbox作成画面 OpenShift Data ScienceをDeveloper Sandbox環境で始めるには、 こちらのリンク にアクセスし、[Launch your Developer Sandbox for Red Hat OpenShift Data Science]のボタンをクリックしてSandbox環境を作ることができます。 図11: Red Hat OpenShift Data ScienceのDeveloper Sandbox作成画面 Red Hat OpenShift Database Accessについては、左のナビゲーションメニューでOpenShiftを選択し、このOpenShift Database AccessサービスをインストールしたいOpenShiftクラスタを選択し、そのOpenShiftクラスタにアドオンとしてインストールを行います。詳細についてはこちらの オンラインマニュアル に記載がありますのでご参照ください。 図12: Red Hat OpenShift Database Accessの設定画面 OpenShiftのDeveloper Sandboxについて OpenShiftのDeveloper Sandboxでは、上記のマネージドサービスを試すことができるだけでなく、ブラウザベースのIDEである Red Hat OpenShift Dev Spaces (旧Red Hat CodeReady Workspaces) も利用できるようになっており、Kubernetes/OpenShift上でクラウドネイティブなアプリケーションを開発するためのチュートリアルやサンプルが多数用意されています。ぜひRed Hatアカウントを作成して、クラウドネイティブなアプリケーション開発を始めてみましょう！ 図13: Red Hat OpenShift Developer Sandboxの概要画面 以下の記事もぜひご参考にしてください。 rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Custom JFR event templates with Cryostat 2.0 | Red Hat Developer の翻訳記事です。 Cryostat 2.0の使い方をハンズオンで紹介するシリーズにようこそ。この記事では、JDK Flight Recorder (JFR) を使用して Java アプリケーションを監視するためのカスタムイベントテンプレートを事前に設定する方法を紹介します。まず、新しい Cryostat Operator と Red Hat OpenShift ConfigMap を使用してカスタムイベントテンプレートを作成し、Cryostat Operator に Cryostat のデプロイ時に ConfigMap を使用するよう指示します。OpenShift コンソールを使用して Cryostat と対話するか、Cryostat カスタムリソース用の YAML ファイルを編集することができます。今回はどちらの方法も実演します。 このシリーズの全記事を読む Part 1: Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ Part 2: Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ Part 3: CryostatによるカスタムターゲットのJavaモニタリング - 赤帽エンジニアブログ Part 4: Automating JDK Flight Recorder in containers - 赤帽エンジニアブログ Part 5: https://rheb.hatenablog.com/entry/custom-jfr-event-templates-cryostat-20 注意 ：CryostatはKubernetesまたはRed Hat OpenShiftのためのJDK Flight Recorderです。Cryostat 2.0 の Red Hat ビルドは、現在、技術プレビューで広く利用できます。Red Hat ビルドには、Red Hat OpenShift 上での Cryostat のデプロイを簡素化および自動化するための Cryostat Operator が含まれています。 カスタムテンプレートとConfigMapの作成 Cryostatでは、既存のテンプレートファイルをJava仮想マシン（JVM）から直接ダウンロードできます。テンプレートファイルをローカルマシンにダウンロードしたら、JDK Mission Control (JMC) テンプレートマネージャを使用して、目的に合ったテンプレートを簡単に編集できます。 テンプレートファイルをカスタマイズした後、そこから ConfigMap を作成するのはとても簡単です。この ConfigMap は、Cryostatが実行されるクラスタ内にテンプレートファイルを格納します。Cryostatをデプロイする名前空間では、 oc や kubectl を利用できます。前者を使う場合のソースはこちらです。 $ oc create configmap my-template --from-file=/path/to/custom.jfc このコマンドは、ローカルマシンの /path/to/custom.jfc にあるファイルから my-template という名前の ConfigMap を作成します。このファイルは、 ConfigMap 内の custom.jfc というファイル名で配置されます。 Cryostat OperatorにConfigMapを追加 ConfigMap を作成したら、Cryostat Operator に Cryostat のデプロイ時にそれを使用するように指示するだけです。これは、Cryostatのカスタムリソースを作成するとき、または既存のリソースを更新することで、行えます。OpenShift コンソールを使用して Cryostat をインストールしている場合、更新したい Cryostat カスタムリソースの下にある Event Templates を選択します。 Add Event Template を選択します。 Config Map Name ドロップダウン リストには、ローカル名前空間内のすべての ConfigMap が表示されます。作成したイベントテンプレートが含まれる ConfigMap を選択します。 Filename に、 ConfigMap 内の .jfc ファイルの名前を入力します。図 1 では、前のセクションで作成した custom.jfc を使用しています。 図1. JDKの.jfcイベントテンプレート定義ファイルを用いてConfigMapを作成 CryostatカスタムリソースのYAMLを直接操作できます。手順はコンソールでやったことと似ています。 spec セクションに eventTemplates プロパティがない場合は、追加してください。次に、 ConfigMap の名前を参照する configMapName と、 ConfigMap 内のファイル名を参照する filename を持つ配列エントリを追加します。以下の YAML は、図 1 の OpenShift コンソールの例で行ったことを反映したものです。 apiVersion : operator.cryostat.io/v1beta1 kind : Cryostat metadata : name : cryostat-sample spec : eventTemplates : - configMapName : custom-template filename : my-template.jfc Cryostatカスタムリソースに変更を保存すると、Cryostat Operatorはこのテンプレートがあらかじめ設定された状態でCryostatをデプロイします。CryostatのWebアプリケーションにアクセスすると、図2に示すように、テンプレートが存在し、新しいフライトレコーディングの作成に使用できることが表示されます。 図2. イベントテンプレートリストには、ConfigMapで作成されたテンプレートが表示 まとめ この記事では、OpenShift ConfigMaps を使用してカスタマイズされたイベントテンプレートで Cryostat を事前構成する方法を学びました。カスタマイズされたテンプレートを使用すると、フライトレコーディングであなたが必要とする特定のデータを収集できます。Cryostat.io にアクセスし、このシリーズの他の記事でさらに詳細をご覧ください。 ContainerJFR入門: コンテナのためのJDK Flight Recorder - 赤帽エンジニアブログ Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ CryostatによるカスタムターゲットのJavaモニタリング - 赤帽エンジニアブログ Automating JDK Flight Recorder in containers - 赤帽エンジニアブログ

みなさん、こんにちは。 Red HatでOpenShiftのソリューションアーキテクトをしている小野です。 主にエッジコンピューティングを推進しています。 今回は、エッジデバイスへOpenShiftをインストールする 「MicroShift」をご紹介します。 MicroShiftとは MicroShiftは、 エッジデバイスでOpenShiftを利用できる様にOpenShiftをRe-パッケージしたソフトウェア です。 Red HatのCTOオフィスのEdge Computingチームにより推進される実験プロジェクトとして、開発が進められています。 next.redhat.com next.redhat.com Red Hat Enterprise Linux (RHEL)がインストールされたエッジデバイスに、オプションでデプロイできるアプリケーションを目指しており、 MicroShiftのライフサイクルは、OSのライフサイクルから切り離されています。 MicroShiftは現状、実験プロジェクトということで、製品化されておらず、オープンソースとして公開されています。 5月に開催されたRed Hat Summit 2022にて、2022年末にリリース予定のOpenShift 4.12より、Early Access Program（※1）として利用可能とする計画が発表されました。 （※1） Red Hat Cloud Suite Early Access Support Policies - Red Hat Customer Portal github.com エッジデバイスとは エッジデバイスとは、フィールドに大量に展開されるデバイスを指します。 例えば、 POSやKIOSK端末 自動運転のAIを実行する車両内の小型デバイス 工場のラインに設置される産業用のPC 遠隔地の石油やガスプラントを監視し予知保全を実行するデバイス 衛星に搭載されるデバイス など、別の言い方で「組み込みシステム」とも呼ばれます。 フィールドに展開される、ということで、エッジデバイスは、通常、電力とネットワークが安定しているデータセンタとは全く異なる環境に設置されます。 MicroShiftは、特にネットワーク環境が貧弱、またはネットワーク未接続で、遠隔管理・制御が難しい場所に大量展開されるデバイスもスコープにしています。 衛星といえば、先日、IBM / Red Hatの衛星エッジコンピューティングのプロジェクトがプレスリリースされました。 www.universetoday.com 記事に記載されている取り組み内容をざっくり言うと、 IBM Cloudに開発ポータルを構築 開発ポータルにPythonコードをプッシュ 脆弱性スキャンの後、地上局経由で衛星上で稼働するコンピュータへコードを展開・実行 というもので、衛星の磁力計、太陽センサー、電圧、温度などのテレメトリデータの取得や、衛星のカメラを使用して地球の写真を撮る、といったユースケースを目指しています。 この「衛星上で稼働するコンピュータ」に、本稿でご紹介するMicroShiftが使われています。 どの辺が "Micro" なの？ MicroShitは、OpenShiftのコアコンポーネント（※2）をバイナリサイズ160MB程度までダウンサイジングし、シングルバイナリかつsystemdでライフサイクル管理する、モノリスなOpenShiftとして実装されています。 （※2）etcd、kube-apiserver、kube-controller-manager、kube-scheduler、openshift-apiserver、openshift-controller-manager これだけだと、オープンソースのKubernetesと変わりありませんので、OpenShiftのコンポーネントをいくつかアドオンの形で展開できるようになっています。 現状だと、 openshift-dns 、 openshift-ingress 、 service-ca 、 local-storage-provisioner がインストール時にデフォルトで展開されます。 OpenShiftのコアコンポーネントがシングルバイナリで提供されることによって、更新やロールバックなどの変更オペレーションを大幅に簡素化できるようになります。 そして、変更オペレーションに伴うコンポーネント間のオーケストレーションが不要となることで、OpenShiftクラスタを管理するCluster Operatorを削除でき、フットプリントの大幅な削減に成功しています。ただし、Cluster Operatorが使えないとなると、MicroShiftの想定するパラメーターの範囲外で設定が必要になった場合に、手動での構成が必要になるというデメリットも伴います。 エッジデバイスでKubernetesを使うことのメリット エッジデバイスとサーバのプロビジョニングフローの違い エッジデバイスは、多くの場合、以下のプロビジョニングフローで現場へ設置されます。 メーカーやエンドユーザの開発・運用拠点などで一元的にキッティング 現場へ出荷 現場の担当者が、デバイスを設置 現場の担当者が電源ケーブルとLANケーブル挿入、電源ON・ネットワーク設定 この辺のプロビジョニングフローは、FIDOアライアンスが策定したFIDO Device Onboarding (FDO) 仕様が参考になります。 fidoalliance.org 多くの場合、現場にIT技術者はいません。 データセンタへのサーバのプロビジョニングフローとは全く異なる、という点がポイントになります。 エッジのスケール時の課題 ところで最近、AIカメラなど、エッジデバイス上でAIを実行する「エッジAI」が流行しています。 このエッジAIを例にしても、エッジコンピューティングの事例として、 従来サーバサイドで実行されていたAIなどのアプリケーションをエッジデバイス上で実行する 、という動向が見受けられます。 プロビジョニングフローを踏まえると、エッジデバイスのスケールに対応する際、下記が課題となります。 大量のエッジデバイスのプロビジョニングの効率化 大量のエッジデバイスへサーバサイド・アプリケーションの実行環境の構築の効率化 サーバサイド・アプリケーションのプロビジョニングの効率化 現場へエッジデバイスを設置した後のサーバサイド・アプリケーションの変更や機能追加の効率化 「小さいクラウドの自動生産ライン」を作る必要があると言えると思います。 現場業務の簡素化とIT技術者によるエッジデバイスのプロビジョニング・運用効率化が、エッジのスケールに対応する上で重要な課題となります。 また、IoTの進展に伴い、センサーから生成されるデータをクラウドへ送る手前でエッジデバイスへ一次集約し、分析やAIの実行に活用するという事例が増えています。エッジデバイスは基本的にハードウェアとアプリケーションが密結合したパッケージとして現場へ配布されます。したがって、エッジデバイスのローカルディスクの容量が不足したり、エッジデバイスのハードウェアが故障すると、データの取りこぼしが起こり得ます。 PoCの段階では大きな問題にならなくても、データ・ドリブンでの意思決定の重要度が増す程、データ損失による業務破綻のリスクが高まってきます。 その様な背景から、エッジデバイスを複数台用意してスケーラビリティを向上させたい、ハードウェアを冗長化させたい、といった データ収集の可用性向上 に向けた課題も重要になってきます。 Kubernetesがエッジにもたらす価値 2021年にSlash Dataは、Cloud Native Computing Foundation（CNCF）の依頼を受け作成した「State of Cloud Native Development Report」というレポートを公開しました。 7000人のバックエンド開発者を対象に、Kubernetesとコンテナーに関する認識や利用形態の調査結果がまとめられています。 このレポートによると、 Kubernetesはエッジコンピューティングの開発者による利用傾向が最も高い 、というデータが出ています。 https://www.cncf.io/wp-content/uploads/2021/12/Q1-2021-State-of-Cloud-Native-development-FINAL.pdf Kubernetesは、ITインフラストラクチャやアプリケーションの管理において強力な自動化機能を有し、複数台のノードでクラスタを構成することで、インフラストラクチャの可用性と拡張性の柔軟性を向上できるプラットフォームとして活用されています。この「自動化」と「可用性・拡張性の柔軟性」という点で、エッジコンピューティングの課題との親和性が高く、期待値として表れていると考えます。 MicroShiftは、正にその様な期待に応えるために開発されたエッジコンピューティングに最適化されたOpenShiftです。 マルチノードなど、まだまだ機能改善が図られているソフトウェアですが、クラウドとエッジで同じ運用モデルを適用できる様になることで、End-to-Endの業務の自動化を推進できます。 例えばOpenShiftの様に、Red Hat Advanced Cluster Management（RHACM）を用いて、MicroShiftがインストールされたエッジデバイスをクラスタとして管理でき、RHACMを単一のコントロールプレーンとして、Zero Touch Provisioningによりクラスタやアプリケーションを自動生産、かつセキュリティポリシを一括適用するといった運用が可能になります。 例えば、以下の様に、Tektonを用いたエッジ環境のプロビジョニング自動化の事例が存在します。 github.com MicroShiftのインストール それでは、MicroShiftを試しにインストールして触ってみましょう。 MicroShiftは、ホスト上で直接実行するか、Podman上でコンテナとして展開できます。 ここでは、PC上にFedoraの仮想マシンを実行し、仮想マシン上でMicroShiftを実行してみたいと思います。 MicroShiftの動作環境 ハードウェア要件： CPU: x86/64 / AMD64 / ARM64 Red Hat Enterprise Linux 8.6以降 必要最低限のスペック： CPUコア数: 2 コア メモリ: 2GB DISK: 1GB rheb.hatenablog.com インストール お手持ちのPCへVagrantをインストールします。 Vagrantのインストール方法は公式ドキュメントを参考にしてください。 www.vagrantup.com 以下のVagrantfileを作成します。 Vagrant.configure("2") do |config| config.vm.box = "fedora/35-cloud-base" config.vm.provider "virtualbox" do |v| v.memory = 4096 # 4GB v.cpus = 2 # 2コア end # localhostからアクセスできる様にポートフォワードしておく config.vm.network :forwarded_port, guest: 6443, host: 6443, id: "console" config.vm.network :forwarded_port, guest: 443, host: 443, id: "console" config.vm.network :forwarded_port, guest: 80, host: 80, id: "console" config.vm.network :forwarded_port, guest: 22, host: 22, id: "ssh" # 任意のドメインを指定 config.vm.hostname = 'microshift.local.com' config.vm.provision "shell", inline: <<-SHELL dnf module list cri-o dnf -y module enable cri-o:1.22 dnf -y install cri-o curl https://copr.fedorainfracloud.org/coprs/g/redhat-et/microshift-nightly/repo/fedora-34/group_redhat-et-microshift-nightly-fedora-34.repo -o /etc/yum.repos.d/microshift-nightly-fedora34.repo 2>/dev/null cat << EOF > /etc/cni/net.d/100-crio-bridge.conf { "cniVersion": "0.4.0", "name": "crio", "type": "bridge", "bridge": "cni0", "isGateway": true, "ipMasq": true, "hairpinMode": true, "ipam": { "type": "host-local", "routes": [ { "dst": "0.0.0.0/0" } ], "ranges": [ [{ "subnet": "10.42.0.0/24" }] ] } } EOF dnf install -y microshift hostnamectl set-hostname microshift.local.com dnf -y install firewalld wget systemctl enable firewalld --now firewall-cmd --zone=public --permanent --add-port=6443/tcp firewall-cmd --zone=public --permanent --add-port=30000-32767/tcp firewall-cmd --zone=public --permanent --add-port=2379-2380/tcp firewall-cmd --zone=public --add-masquerade --permanent firewall-cmd --zone=public --add-port=80/tcp --permanent firewall-cmd --zone=public --add-port=443/tcp --permanent firewall-cmd --zone=public --add-port=10250/tcp --permanent firewall-cmd --zone=public --add-port=10251/tcp --permanent firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 firewall-cmd --reload firewall-cmd --permanent --change-zone=eth0 --zone=public systemctl enable crio systemctl start crio systemctl enable microshift systemctl start microshift ARCH=x86_64 wget -q https://mirror.openshift.com/pub/openshift-v4/$ARCH/clients/ocp/candidate/openshift-client-linux.tar.gz mkdir tmp;cd tmp tar -zxvf ../openshift-client-linux.tar.gz mv -f oc /usr/local/bin cd ..;rm -rf tmp rm -f openshift-client-linux.tar.gz echo "export KUBECONFIG=/var/lib/microshift/resources/kubeadmin/kubeconfig" >> /root/.bash_profile SHELL end vagrantコマンドで仮想マシンを起動すると、自動でMicroShiftもインストールされます。 $ vagrant status Current machine states: default not created (virtualbox) $ vagrant up $ vagrant status Current machine states: default running (virtualbox) MicroShiftの動作確認 KubeconfigをローカルPCにコピーし、ocコマンドでAPIを実行してみます。 $ ssh vagrant@localhost sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ./kubeconfig-mac $ oc --kubeconfig=./kubeconfig-mac get nodes NAME STATUS ROLES AGE VERSION microshift.local.com Ready <none> 111d v1.21.0 $ oc --kubeconfig=./kubeconfig-mac get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system kube-flannel-ds-24jwq 1/1 Running 2 111d kubevirt-hostpath-provisioner kubevirt-hostpath-provisioner-g9678 1/1 Running 2 111d openshift-dns dns-default-h74m9 2/2 Running 4 111d openshift-dns node-resolver-w2hs8 1/1 Running 2 111d openshift-ingress router-default-6c96f6bc66-m8btk 1/1 Running 2 111d openshift-service-ca service-ca-7bffb6f6bf-km6wq 1/1 Running 2 111d まとめ 今回は、エッジデバイスへOpenShiftをインストールできるMicroShiftをご紹介しました。 エッジデバイスでもKubernetesを活用し、エッジのスケールに対応していきましょう！

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Automating JDK Flight Recorder in containers | Red Hat Developer の翻訳記事です。 この記事は、Cryostat 2.0、またはコンテナ用JDK Flight Recorderを使用するためのハンズオンガイドのシリーズの一部です。この記事では、自動化されたルールのためのCryostatの新しいAPIを紹介します。この API の簡潔ながら強力なルール定義を際立たせる 2 つの使用例について説明します。ルール定義を使用して、1つまたは複数のターゲットJavaアプリケーションの条件式を指定する方法と、これらのターゲットで開始したいフライトレコーディングのタイプを構成する方法を説明します。 あなたがルールを作成したら、Cryostatはすぐにすべての既存の検出されたターゲットに対してそれを適用し、あなたのフライトのレコーディングを開始します。Cryostatはまた、その定義に合致する新たに発見されたターゲットにルールを適用します。あなたは、ターゲットの異なる部分集合に一致する、またはあなたの目的のために異なる記録オプションを重ねるために複数のルールを作成できます。 自動化されたルールAPIはCryostat 2.0の新機能で、我々はまだそのためのユーザインタフェース（UI）を開発してはいません。今のところ、Cryostat HTTP APIと直接対話するために curl を使用します。 このシリーズの全記事を読む Part 1: Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ Part 2: Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ Part 3: CryostatによるカスタムターゲットのJavaモニタリング - 赤帽エンジニアブログ Part 4: Automating JDK Flight Recorder in containers - 赤帽エンジニアブログ Part 5: Creating Custom JFR event templates with Cryostat 2.0 注意 ：Cryostat 2.0 の Red Hat ビルドは、現在技術プレビュー版として広く利用できます。Cryostat 2.0 は、自動化されたルール、JSON 形式によるレスポンスの優れた API 、カスタムターゲット、同時ターゲット JMX 接続、WebSocket プッシュ通知など、多くの新機能と改良点を導入しています。Red Hat ビルドには、OpenShift での Cryostat の導入を簡素化し、自動化するための Cryostat Operator が含まれています。 使用例1：コンテナ型JVMでの継続的な監視 以前は、コンテナ化されたJava仮想マシン（JVM）でJDK Flight Recorder（JFR）を使用して常時連続監視を有効にしたい場合、ターゲットアプリケーションにJVM起動引数を設定し、アプリケーションを再起動して監視を開始する必要がありました。Cryostatの自動化されたルールを使えば、JDK Flight Recorderを実行時に有効にして、すでに動作しているターゲットアプリケーションを継続的に監視することができ、再起動や再デプロイ、停止時間が不要になります。 また、停止時間なしで、実行時に連続監視イベントのテンプレートを修正できます。まず、使用したいテンプレートでルールを作成します。次に、新しいテンプレートと、新規または更新されたイベントテンプレートで新しいルールを作成します。最後に、 clean=true パラメータを指定して、元のルールを削除します。以下はそのソースです。 # このURLを実際のCryostatインスタンスのURLに置き換えます。 $ export CRYOSTAT= https://cryostat.example.com # Profiling テンプレートを使って firstRule という名前のルールを作成 $ curl -F name = " firstRule " -F matchExpression =” target.alias = = ‘com.example.MainClass’” -F eventSpecifier =” template = Profiling,type =TARGET” $CRYOSTAT /api/v2/rules # Profiling テンプレートをコンピュータにダウンロード $ curl $CRYOSTAT /api/v1/targets/ $serviceUri /templates/Profiling/ type /TARGET -o profiling.jfc # Profiling テンプレートを編集して、内部のイベント定義を更新し、Profiling から Demo に名前を変更 $ $EDITOR profiling.jfc # Demoプロファイルとして識別しやすいように、ファイル名をdemo.jfcに変更 $ mv profiling.jfc demo.jfc # 新しいDemoプロファイルをCryostatにアップロードする $ curl -F template =@demo.jfc $CRYOSTAT /api/v1/templates # Demoプロファイルを使用して2つ目のRuleを作成 $ curl -F name = " secondRule " -F matchExpression =” target.alias = = ‘com.example.MainClass’” -F eventSpecifier =” template = Demo,type =CUSTOM” $CRYOSTAT /api/v2/rules # Profilingテンプレートを使用した最初のRuleを削除し、それが作成したアクティブなレコーディングを削除 $ curl -X DELETE $CRYOSTAT /api/v2/rules/firstRule? clean = true 使用例2：Kubernetesのラベルやアノテーションを使用したカスタム監視 Kubernetesのラベルやアノテーションなど、プラットフォーム固有の属性を持つターゲットアプリケーションに適用するルールを定義できます。以下はJSON記法による例です。 { " name ": " k8sMonitoring ", " description ": " jfrMonitoring=trueアノテーションを使用して、任意のターゲットでDemoテンプレートを有効にします ", " matchExpression ": " target.annotations.platform[‘jfrMonitoring’]==’enabled’ ", " eventSpecifier ": " template=Demo,type=CUSTOM ", " archivalPeriodSeconds ": 300 , " preservedArchives ": 12 } このルール定義を作成すると、Cryostatは既存のターゲットアプリケーションを全て確認し、 jfrMonitoring=enabled アノテーションが付いた新しいターゲットを探します。一致するターゲットが見つかると、最初の使用例で使用したカスタム Demo テンプレートを使用して、自動的にレコーディングが開始されます。5分ごとに保存されたスナップショットが作成され、1時間分のデータがストレージに保存されます。 このルール定義があれば、Kubernetes や Red Hat OpenShift のユーザーは、 kubectl/oc や OpenShift コンソールなどの使い慣れたツールを使って、Cryostat API や UI と直接対話しなくても、監視対象のアプリケーションに目印を付けられるようになります。これは、作業工程のさらなる自動化への扉を開くものです。 例として、通信量やポッドの再起動を監視し、何らかの基準閾値を満たした後にポッドの監視を有効にし、対象アプリケーションの動作が正常に戻ったらその監視を再び無効にするOperatorを使用または実装することが考えられます。Kubernetes 管理者として、この現象が発生したときに通知を受け取り、Cryostat アーカイブをチェックして、問題が発生した期間に記録されたターゲット アプリケーションの JDK Flight Recorder データを取得したり、Cryostat の Grafana ダッシュボードでこれらの保存されたレコーディングを表示できます。 注意 ：重要な注意点として、CryostatはKubernetesのアノテーションやラベルの変更を監視するものではなく、ターゲットアプリケーションが現れたり消えたりするかどうかだけを監視しています。ターゲットアプリケーションにアノテーションを適用するには、デプロイではなく、アプリケーションポッド（Kubernetesに新しいレプリカを展開させる）にアノテーションまたはラベルを適用します。 Cryostatで条件式の使い方 ルール定義のmatchExpressionは、Cryostatが解釈し、与えられたターゲットにルールを適用すべきかどうかを判断するために使用する、Javaのようなコードの断片です。matchExpressionは論理値で評価されなければなりません。最も単純な matchExpressions は true か false という論理値で、true を使うと、ルールはすべてのターゲットに適用されます。この式は全体に対してターゲット・オブジェクトを持ち、JSON記法では次のような形になります。 { “ alias ”: “ myAppAlias ”, “ connectUrl ”: “ service : jmx : rmi : ///jndi/rmi://cryostat:9091/jmxrmi”, “ labels ”: { “ com . example / service ”: “ customer - login ” , } , “ annotations ”: { “ platform ”: { “ io . kubernetes / annotation ”: “ annotated ” } , “ cryostat ”: { “ PORT ”: 9091 , “ HOST ”: “ cryostat ”, “ NAMESPACE ”: “ myproject ” } } } alias 、 connectUrl 、 labels 、 annotations.platform 、 annotations.cryostat プロパティはすべてターゲットオブジェクトに存在することが保証されています。 alias と connectUrl は空でない文字列になります。 labels と platform のアノテーションは、OpenShiftまたはKubernetesでは、これらはターゲットのPodに適用されたラベルとアノテーションから入力されます（もしあれば）。Cryostatのアノテーションのマップはプラットフォームごとに異なりますが、OpenShiftまたはKubernetesでは、 HOST 、 PORT 、 NAMESPACE 、および POD_NAME のキーが存在し、空でないことが期待されます。 以下はmatchExpressionsの例です。 target.alias == ’com.example.MainClass’ target.alias == ’myAlias’ target.labels[‘com.example/service’] == ’customer-login’ target.labels[‘com.example/service’] != ’customer-login’ target.annotations.cryostat.PORT > 3000 target.annotations.cryostat.PORT > 3000 && target.annotations.platform[‘io.kubernetes/annotation’] == ‘enabled’ !!target.annotations.platform[‘io.kubernetes/annotation’] /^customer-login[0-9]*$/.test(target.alias) まとめ この記事では、条件式を使用して Cryostat 監視の自動化ルールを作成する方法について学びました。一度自動化ルールを設定すれば、Cryostat はそのルールで定義された基準を満たすアプリケーションを継続的に監視し、それらのアプリケーションを再起動または再デプロイする必要がありません。詳細については、 Cryostat.io をご覧ください。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Java monitoring for custom targets with Cryostat | Red Hat Developer の翻訳記事です。 デフォルトでは、CryostatはリモートJava Management Extensions (JMX)とJMX-RMIが有効な接続性を持つ、発見可能で有効なターゲットを自動的に認識します。発見機能は、Kubernetes APIベースのサービスエンドポイントやJava Discovery Protocol (JDP)など、さまざまなメカニズムに基づいています。 Cryostat 2.0では、開発者は、有効だがまだ発見されていない既知の潜在的なJavaアプリケーションのターゲットにカスタムURLを提供することによって、接続を作成できるようになりました。カスタムターゲット定義は、Cryostatインスタンスが再起動した後でも利用できるように保存できます。この機能は、CryostatのWebフロントエンドで、この記事で紹介したターゲットの作成機能を通じて利用できます。 Cryostat 2.0では、新しいclientlibディレクトリも導入されました。このディレクトリにターゲットアプリケーションJARを追加することで、作成するカスタムターゲットにカスタム接続プロトコルを指定できます。ここでは、そのような接続プロトコルを使用するカスタムターゲットを追加する方法を説明します。 このシリーズの全記事を読む Part 1: Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ Part 2: Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ Part 3: CryostatによるカスタムターゲットのJavaモニタリング - 赤帽エンジニアブログ Part 4: Automating JDK Flight Recorder in containers - 赤帽エンジニアブログ Part 5: Creating Custom JFR event templates with Cryostat 2.0 注：CryostatはKubernetesまたはRed Hat OpenShiftのためのJDK Flight Recorderです。 Cryostat 2.0 の Red Hat ビルド は、現在、技術プレビューで広く利用できます。Red Hat ビルドには、Red Hat OpenShift 上での Cryostat のデプロイを簡素化および自動化するための Cryostat Operator が含まれています。 前提条件とセットアップ方法 このデモでは、クライアント定義の接続プロトコルでカスタムターゲットに接続します。前提条件として、Red Hat OpenShift クラスタ上で Cryostat Operator を介して Cryostat をインストールし、動作させておく必要があります。インストールの詳細については、 Cryostat.io を参照してください。 ターゲットには単純な WildFly アプリケーションを使用することにします。まず、Cryostat インスタンスが動作しているのと同じ名前空間にアプリケーションを追加します。 oc new-app quay.io/andrewazores/wildfly-demo:v0. 0 . 2 && oc expose svc wildfly-demo --port=8082 アプリケーションがクラスタ上で動作しているので、 oc status を入力すると、 cryostat-operator とCryostatインスタンスと一緒に表示されます。 注：JavaアプリケーションがCryostatを使用するように設定する手順については、 このシリーズの前の記事 を参照してください。Cryostatについて学ぶ他の方法については、この記事の最後を参照してください。 クライアント定義の接続プロトコルを追加 アプリケーションはポート 9990 で JMX remote+http プロトコルを使ってリッスンしますが、Cryostat のデフォルト接続プロトコルである JMX-RMI ではありません。Cryostat インスタンスがターゲットアプリケーションを認識し、通信する（つまり、カスタム接続プロトコルを受け入れる）ためには、追加の JAR を提供しなければなりません。 WildFly クライアント JAR をダウンロード WildFly アプリケーションの場合、JAR は WildFly の完全なリリースをダウンロードすると入手できます。選択したバージョンは、アプリケーションの作成に使用したものと一致しなければならず、この場合、バージョン 23.0.1.Final です。したがって、このバージョンの Jakarta EE Full & Web ディストリビューションの tarball をダウンロードしなければなりません。ダウンロードしたら、次のようにtarballを展開します。 tar -xvf ~/Downloads/wildfly-23.0.1.Final.tar.gz 必要な jboss-client.jar は解凍した wildfly-23.0.1.Final/bin/client/ ディレクトリに配置されています。 クライアントJARをclientlibに追加 必要な JAR が手に入ったので、あとは Cryostat インスタンスにマウントされている永続ボリューム内の clientlib ディレクトリに追加するだけです。まず、インスタンスを収容するポッドの名前を取得します。 oc get pods -l app=cryostat-sample Pod名がわかったので、 oc cp コマンドでJARを転送します。 oc cp ~/Downloads/wildfly-23.0.1.Final/bin/client/jboss-client.jar ${PROJECT_NAME}/${CRYOSTAT_POD_NAME}:/opt/cryostat.d/clientlib.d 注： PROJECT_NAME はクラスタを含むプロジェクト（すなわち名前空間）の名前、 CRYOSTAT_POD_NAME は前のコマンドを実行した結果です。 Cryostatインスタンスを再起動 JARをCryostatのクラスパスに追加したので、ファイルをロードするためにCryostatインスタンスを再起動します。 oc rollout restart deployment/cryostat-sample -n ${PROJECT_NAME} Cryostatモニタリング用カスタムターゲットの追加 ポッドが復旧したら、Cryostat が監視するカスタムターゲットとして WildFly アプリケーションを追加できます。まず、アプリケーションを収容しているポッドの IP アドレスを取得します。 ポッド名とIPアドレスの取得 まず、ポッド名を取得することから始めます。 oc get pods -l deployment=wildfly-demo ここで、ポッド名を使って、IPアドレスを取得します。 oc get pod ${WILDFLY_POD_NAME} -o jsonpath='{.status.podIP}' ; echo 注： WILDFLY_POD_NAME は、前のコマンドを実行したときの結果です。 WildFlyをカスタムターゲットとして追加 IPアドレスが分かったので、先に進んでWildFlyアプリケーションをカスタムターゲットとして追加します。 CryostatのWebフロントエンドを使用するには、 oc status を確認し、 cryostat-sample サービスのアプリケーションURLを辿ってください。認証トークンの入力を求められたら、 oc whoami -t を使って取得できる OpenShift アカウントのトークンを入力します。図1は、Cryostatのログインページです。 図1. Cryostatのログインページ Target JVM の横にある + アイコンを押して、カスタムターゲットを作成します。接続 URL には service:jmx:remote+http://${IP_ADDRESS}:9990 と入力します。ここで IP_ADDRESS は WildFly アプリケーション・ポッドのアドレスです。エイリアスには、図2に示すように「WildFly」を使用することにします。 図2. カスタムターゲット定義の作成 図3の画面で、ターゲットが作成されたことが確認できます。 図3．ターゲットが作成されたことを確認 ターゲットJVMでの認証 WildFlyターゲットが作成されたら、それを選択して、図4に示すように、「Recordings」に移動できます。 図4．新しく作成されたターゲットを選択 ターゲット JVM（つまり WildFly アプリケーション）で認証するよう促されます。アプリケーションは、ユーザー名 "admin"、パスワード "password" で JMX 認証を使用するように設定されています。図 5 は認証画面です。 図5. 新しいターゲットに接続するための認証情報を入力 セットアップが完了したら、図 6 に示すように WildFly ターゲット アプリケーションで新しいフライト レコーディングを作成できます。 図 6. カスタムターゲットで新規録画を開始 図7は、私たちが成功したことを示しています。 図7. ターゲット上で実行されているレコーディング まとめ この記事では、クライアント定義のプロトコルを使用して、Cryostat モニタリング用のカスタムターゲットを定義する方法を学びました。Cryostat でカスタムターゲットを設定したら、様々な方法でそのターゲットと対話できます。詳細はCryostat.ioにアクセスするか、以下の記事を参照してください。 ContainerJFR入門: コンテナのためのJDK Flight Recorder - 赤帽エンジニアブログ Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Announcing Cryostat 2.0: JDK Flight Recorder for containers | Red Hat Developer の翻訳記事です。 Cryostat は、HotSpot JVM アプリケーションにすでに存在する JDK Flight Recorder (JFR) フレームワークを活用したプロファイリングおよび監視ツールです。Cryostatは、クラスタ内の収集拠点を提供し、クラスタ外からJDK Flight Recorderのデータに簡単かつ安全にアクセスできます。 この記事は、先日発表されたCryostat 2.0に続くものです。これは、Java アプリケーションで Cryostat 2.0 を使用するための、いくつかの手引き書の最初のものです。この記事では、Red Hat OpenShift 上で Cryostat を使用するために Quarkus ベースの Java アプリケーションをセットアップして設定する方法について探ります。 このシリーズの全記事を読む Part 1: Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ Part 2: Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ Part 3: CryostatによるカスタムターゲットのJavaモニタリング - 赤帽エンジニアブログ Part 4: Automating JDK Flight Recorder in containers - 赤帽エンジニアブログ Part 5: Creating Custom JFR event templates with Cryostat 2.0 注意: Red Hat ビルドの Cryostat 2.0 は、現在技術プレビューで広く利用可能です。Cryostat 2.0 は、自動化されたルール、より優れた API 応答 JSON 形式、カスタムターゲット、同時ターゲット JMX 接続、WebSocket プッシュ通知など、多くの新機能と改善点を導入しています。Red Hat ビルドには、OpenShift での Cryostat デプロイを簡素化し、自動化するための Cryostat Operator が含まれています。 JMX と Cryostat Cryostat を使用するための主な前提条件は、アプリケーションが Java Management Extensions (JMX) を有効にして公開していることです。OpenShiftでは、JMXポートを公開するということは、Cryostatのデフォルトのポート番号である9091を使用するか、ポートに jfr-jmx という名前を付けるかのどちらかです。OpenShiftにデプロイされたQuarkusベースのJavaアプリケーションで、JMXを公開する手順を探っていきます。 Step 1: Quarkusサンプル・アプリケーションを生成 それでは、Quarkusのサンプルアプリケーションを使用してみましょう。まず、code.quarkus.ioにアクセスし、新しいアプリケーションを生成します。この記事では、デフォルトの org.acme グループと code-with-quarkus の artifactId を使用します。これらを自由にカスタマイズしてください。生成オプションを設定したら、.zipをダウンロードし、作業ディレクトリに展開します。 $ mv Downloads/code-with-quarkus.zip workspace $ cd workspace $ unzip code-with-quarkus.zip $ cd code-with-quarkus これで、Quarkusアプリケーションが生成され、変更する準備が整いました。続行する前に、簡単な整合性チェックを行いましょう。 mvnw がQuarkusの依存関係をダウンロードし、アプリケーションを構築したら、次のようなメッセージが表示されます。"Listening on: http://localhost:8080. "このURLにアクセスし、Quarkusのデフォルトのウェルカムページが表示されることを確認します。 $ ./mvnw compile quarkus:dev Step 2: JMX用のアプリケーションを設定 ここまでで問題がなければ、QuarkusアプリケーションをJMX用にセットアップできます。Quarkusアプリケーションを実行しているターミナルに戻り、Ctrl-Cを押して、開発サーバを停止します。 開発サーバが停止したので、プロジェクトの Dockerfile.jvm を編集します。このファイルには、Podman、Buildah、DockerなどのOpen Container Initiative（OCI）イメージビルダーが、QuarkusアプリケーションをOCIイメージに組み入れる際に従うべき指示が含まれています。(特に、アプリケーションをネイティブイメージモードではなくJVMモードで構築する場合）。JVMモードのアプリケーションをOCIイメージにパッケージングしたら、そのイメージをOpenShiftまたはPodmanのコンテナとしてデプロイして実行できます。続けて、Dockerfileを編集してみましょう。 $ $VISUAL src/main/docker/Dockerfile.jvm こんな行があるはずです。 ENV JAVA_OPTIONS=”-Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager” この行を修正し、JMXを有効にするためのオプションを追加しましょう。 ENV JAVA_OPTIONS="-Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dcom.sun.management.jmxremote.port=9096 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false" ここでは、9096番ポートでJMXを有効にしています。この記事のために、JMX SSL と JMX 認証を無効にしています。実稼働環境では、両方とも有効にする必要があります（JMXの管理については、Oracleのドキュメントを参照してください）。 さて、最後にDockerfileにもう一つ変更を加える必要があります。 EXPOSE 8080 の行は、 EXPOSE 8080 9096 にする必要があります。これにより、OCIイメージにメタデータが追加され、中のアプリケーションがポート 8080 と 9096 をリッスンすることを示します。これにより、後でOpenShift上にこれをデプロイしたときに、これらの2つのポートが自動的にクラスタ内のネットワークトラフィックのために生成されたサービスに含まれるようになります。 QuarkusをJVMモードで動作させている理由 ：Dockerfile.jvmのみを編集し、Dockerfile.nativeなどの他のDockerfileを編集していないことにお気づきかもしれません。これは、ネイティブイメージモードのQuarkusは、現在JMXをサポートしていないためです。JMXにアクセスするためには、QuarkusをJVMモードで実行する必要があり、その結果、Cryostatに対応します。 Step 3: 試してみる（オプション） この設定により、サンプルQuarkusアプリケーションをビルドしてOCIイメージとして実行する際に、JMXを使用するように設定されます。この段階に至る前に、QuarkusでJMXとJFRを試したい場合は、以下を実行できます。 $ ./mvnw -Djvm.args=”-Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dcom.sun.management.jmxremote.port=9096 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false” compile quarkus:dev これにより、JMXが有効になり、Dockerfile.jvmで指定したのと同じ方法で設定された quarkus:dev サーバーが実行されます。ここで、JDK Mission Controlを開くと、JVMブラウザパネルにQuarkusアプリケーションが表示されるはずです。 Step 4: アプリケーションをコンテナイメージにビルド 設定に満足したら、アプリケーションをコンテナイメージにビルドしてみましょう。このアプリケーションをOpenShiftにデプロイしたいので、例として quay.io タグを付けますが、これは自分のユーザー名とアプリケーション名に置き換えてください。 $ ./mvnw package $ podman build -f src/main/docker/Dockerfile.jvm -t quay.io/<namespace>/code-with-quarkus . もう1回正常性を確認し、良さそうならquay.ioにプッシュします。 $ podman run -i --rm -p 8080:8080 -p 9096:9096 quay.io/<namespace>/code-with-quarkus $ # ブラウザで http://localhost:8080 を開き、Quarkus のウェルカムページが表示されることを確認 $ podman push quay.io/<namespace>/code-with-quarkus そのイメージがプッシュされたら、quay.ioにアクセスして（例えば、 https://quay.io/ /code-with-quarkus?tab=settings）、イメージリポジトリを公開します。その後、OpenShiftクラスターにデプロイすることができます。 $ oc new-app quay.io/ < namespace > /code-with-quarkus:latest $ oc edit svc code-with-quarkus $ # ポート「9096-tcp」を「jfr-jmx」にリネーム、port、targetPortなどはそのまま $ oc expose --port=8080 svc code-with-quarkus $ oc status # code-with-quarkusアプリがアクセス可能で、Quarkusのウェルカムページが表示されていることを確認します。 Step 5: Cryostat 2.0をOpenShiftにインストール Cryostat Operator を使用して OpenShift クラスタに Cryostat をインストールする方法については、 Cryostat 2.0 のアナウンス を参照してください。Cryostat をインストールし、code-with-quarkus サンプルアプリケーションと同じ OpenShift ネームスペースに存在させたら、すべてが正しく接続されたことを確認できます。 $ oc get flightrecorders code-with-quarkus-5645dbdd47-z7pl7 というような項目があるはずです。これは、Cryostat Operatorが動作しており、私たちのQuarkusアプリケーションがCryostatに対応していると認識されたことを示します。 oc status を再度確認し、Cryostat の URL にアクセスします。OpenShiftアカウントのトークンを入力し（OpenShiftコンソールから、または oc whoami -t で取得できます）、 code-with-quarkus アプリケーションを選択して、 Event ビューに移動してください。読み込まれたイベントテンプレートのリストが表示されれば、CryostatとQuarkusインスタンスが正常に通信していることになります! まとめ この記事は、あなたのJavaアプリケーションでCryostatを使用するための入門書を提供するいくつかの記事の最初のものでした。次回は、Cryostat のカスタムターゲットの定義について紹介します。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Announcing Cryostat 2.0: JDK Flight Recorder for containers | Red Hat Developer の翻訳記事です。 Cryostat は、JDK Flight Recorder (JFR) を使用してコンテナのプロファイリングと監視を行うための安全な API を提供する、コンテナネイティブな JVM アプリケーションです。JDK Flight Recorderは、バイナリのフライトレコーディングに保存されたJFRイベントを使用して、アプリケーションからプロファイリングと診断データを収集します。Cryostatは、要求に応じて、コンテナ化されたJava仮想マシン（JVM）からフライトレコーディングを取得、保存、分析し、アプリケーションの全体的な健全性を評価できます。ユーザは、レコーディングファイルをダウンロードし、JDK Mission Control（JMC）またはGrafanaにアップロードして、さらに分析できます。 この記事では、Cryostatの紹介と、使用例、使い始めるためのヒント、追加のリリースノートなど、2.0リリースの新機能を共有します。Cryostat の基本的な情報については ContainerJFR入門: コンテナのためのJDK Flight Recorder - 赤帽エンジニアブログ をごらん下さい。 シリーズを読む Cryostat 2.0の使い方ハンズオンガイドのシリーズ記事をすべて読みましょう： Part 1: Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ Part 2: Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ Part 3: CryostatによるカスタムターゲットのJavaモニタリング - 赤帽エンジニアブログ Part 4: Automating JDK Flight Recorder in containers - 赤帽エンジニアブログ Part 5: Creating Custom JFR event templates with Cryostat 2.0 注： Cryostat 2.0 の Red Hat ビルド は、現在、テクノロジープレビューで広く利用可能です。Red Hat ビルドには、OpenShift 上での Cryostat のデプロイを簡素化および自動化するための Cryostat Operator が含まれています。 CryostatとJDKフライトレコーダーの連携 Cryostatは、(1) JMX接続を受け入れることができ、(2)JDK Flight Recorderを含むJVMで動作します。これには、OpenJDKと、Red Hat OpenJDKやAdoptium OpenJDKなど、OpenJDKのほとんどのダウンストリームビルドまたはディストリビューションが含まれます。 デスクトップ専用アプリケーションのJDK Mission Controlでは、ユーザがローカルディスクにあるフライトレコーディングを取得しなければなりません。ベアメタル型のJDK Flight Recorderがコンテナ内のローカルファイルシステムに記録を書き込むと、コンテナが再起動したときにそれらの記録が失われます。複雑で安全でない可能性の高い回避策としては、Java Management Extensions（JMX）を介して、デスクトップワークステーションとクラウド上のコンテナ化されたJVMの間に直接接続を確立することが挙げられます。 Cryostatは、コンテナ化されたJVMからフライトレコーディングを安全に取得・保存するため、ユーザーはHTTP/HTTPSでこれらのレコーディングにアクセスできます。Cryostatは、プロファイリングと継続的な監視の両方で低オーバーヘッドなので、ユーザは本番環境でアプリケーションのパフォーマンスを監視できます。ユーザーは、複数のJVMでビルトインまたはカスタムの イベントテンプレート を使って一度にレコーディングを開始できます。 Cryostat 2.0の使用例 Cryostat 2.0の使用例としては、自動化されたルール、JDK Flight Recorderデータの一括取得、カスタムターゲット定義、非RMI JMXコネクタのサポートなどがあります。これらの各使用例については、今後の記事で詳しく説明します。 2.0リリースの主な内容 Cryostat 2.0では、以下の主要な新機能が追加されました。 Cryostat Operator: Cryostatは現在、OpenShift Operatorとして提供されており、技術プレビューでも、OpenShift 4.6以降でOperatorHubから利用可能です。Cryostat Operatorは、CryostatのOpenShift名前空間への設定と展開を容易にし、Cryostat APIへのOpenShiftカスタムリソースインターフェースを提供し、他のOpenShift Operatorとサービスとの統合をより柔軟に構築できるようにします。 自動化されたルール：Cryostatの一般的な使用例は、ターゲットアプリケーションのJVMのすべてまたはいくつかの部分集合に、継続的な監視、または他のJFRイベントテンプレートを有効にすることです。自動化されたルール定義は、ユーザーがどのような種類のJDKフライトレコーディングイベントが記録されるべきか、そしてどのくらいの頻度でJFRデータが各ターゲットからCryostatアーカイブにコピーされるべきかとともに、その上でトリガーされるべきかを指定できます。これは、ポート番号、OpenShiftアノテーション、OpenShiftラベル、またはJVMエイリアスのような基準を使用しています。 バッチ操作。Cryostatのもう一つの一般的な使用例は、何らかの外部イベントが発生したときに、ターゲットJVMのセットからすべてのJFRデータを取得することです。Cryostat 1.0では、クライアントは外部イベントを観察し、N個のターゲットアプリケーションのそれぞれからJFRデータを取得するために、CryostatにN個のHTTPリクエストを発行する必要がありました。Cryostat 2.0では、クライアントは1つのHTTPリクエストを発行し、Cryostatのアーカイブにターゲットのセットからデータを取得するようにCryostatを要求できます。その後、クライアントは必要に応じてCryostatからJFRデータをダウンロードできます。 カスタムターゲット Cryostatのプラットフォームに合わせたJVM検出メカニズムに依存するのではなく、ユーザが手動でターゲット定義を作成できます。 今後、これらの機能を紹介する記事を掲載する予定です。 Cryostat 2.0の始め方 OpenShiftや他のKubernetesクラスタにCryostatをデプロイするために、Cryostat Operatorをインストールします。インストール方法と使用方法については、以下のリンクを確認してください。 cryostat.io の推奨インストールガイド テストとデモのための 手動によるCryostatのインストールとセットアップ のための私たちのガイド CryostatのWeb UIを使い始めるには 、cryostat.io.をご覧ください Cryostat API使用ガイド： HTTP_API.md CryostatのREADME 2.0の追加機能 Cryostat 2.0には、他にもいくつかの細かい新機能があります。 クライアント定義の接続プロトコル ：Cryostatが異なるJMXプロトコル実装を使用してターゲットJVMと通信できるようにします（詳細は プルリクエスト#482 を参照） POST /api/v2/certificates ：ターゲットJVMに接続する際に、信頼するSSL証明書をアップロード GET /api : すべてのAPI操作をリストアップ Cryostat操作のプッシュ通知 Cryostat 1.0からの主な変更点 Cryostat 2.0のリリースでは、バージョン1.0からいくつかの破壊的な変更が行われました。Cryostatがユーザーの多様なニーズに対応できる本格的な製品に成熟するにつれ、これらの変更は必要であると考えました。 対話型コマンドチャンネルの削除 対話型コマンドチャンネルは、一方通行のWebSocket通知チャンネルに置き換えられました。Cryostat は当初、ユーザの操作をあらかじめ定義されたコマンドの集合に限定した対話型モードのツールとして実装されました。この機能は、後にWebSocketを使用してリモートネットワークアクセスを可能にするために拡張され、コマンドチャンネルが生まれました。しかし、コマンドチャネル機能のすべてがHTTP APIに移植された今、チャネルは代わりにCryostatインスタンスに接続されているすべてのターゲットに一方的な通知を提供するようになりました。 イベント指定文字列の削除 これまでは、イベント指定子文字列構文（ jdk.SomeEvent:optionName=value; jdk.AnotherEvent:secondOption=value2;... など）を使用して、レコーディング中に監視するJDK Flight Recorderイベントを指定できました。現在では、JDK Flight Recorderのイベントテンプレート名を指定することで、レコーディング作成時にイベントを指定できます。ユーザは、さまざまな標準テンプレートから選ぶか、独自のカスタムテンプレートをCryostatにアップロードできます。テンプレートはXMLで構成されているため、作成、編集、検証、共有が容易であり、JDKの標準フォーマットであるため相互運用も可能です。 まとめ Cryostat 2.0の技術プレビューリリースでは、OpenShiftまたはKubernetesクラスタ上のコンテナ化されたJVMを監視できます。さらに、JDK Mission ControlやGrafanaで分析するためのJDKフライトレコーディングの作成、管理、ダウンロードが可能です。Cryostat 2.0の詳細については、Cryostatのホームページ、 cryostat.io をご覧ください。また、上流のコミュニティに接続するために、 メーリングリスト にお気軽にご参加ください。

こんにちは、ソリューションアーキテクトの蒸野（ムシノ）です。 前回はFuseのベースになっている Apache Camel の特徴やサンプルコードをご紹介しました。 今回はようやく Red Hat Fuse について説明していきたいと思います。 前回の振り返り rheb.hatenablog.com それでは Fuse をご存知無い方に向けて、製品の概要や利用する上でのメリット、どこから始めるべきか？という点のご紹介をしていきたいと思います。 Fuse 概要 Fuse は、Apache Camel 2.x をベースにし多様なインテグレーションパターンを実装したインテグレーションエンジンと位置づけています。Apache Camel の思想を受け継ぎ、様々なシステムへのコネクターやデータフォーマットに対応し、インテグレーションの課題に対応します。 ここでは大きく5つの特徴を紹介します。 Enterprise Integration Patterns（EIP）に基づいている 前回記事でも紹介しました Enterprise Integration Patterns（EIP）にですが、Fuse 開発ガイド にも記載があります。 access.redhat.com Fuse開発ガイドでは Apache Camel のEIPパターンよりも実現できるパターンは若干少なくなっていますが、「 メッセージングシステム 」「 メッセージングチャネル 」「 メッセージの構築 」「 メッセージルーティング 」「 メッセージの変換 」「 メッセージングエンドポイント 」「 システム管理 」のカテゴリに分けられてインテグレーションを実現できる点は同様です。Fuse開発ガイドのほうが日本語対応している為、入りやすいかも知れません。 200以上のコンポネントを利用できる Fuseには多くの SaaS システムなどへ接続できるコンポーネントが豊富に用意されています。 developers.redhat.com ちなみに、Apache Camel には現時点300以上のコンポーネントが存在しています。特殊な環境を除けば標準のコンポーネントだけで十分インテグレーションが可能です。 注意点： コンポーネントによってはサポートしていないものが存在します。開発時、適用する場合には事前にご確認ください。 Chapter 1. Components Overview Red Hat Fuse 7.10 | Red Hat Customer Portal データ変換に対応する Fuse では様々なデータフォーマットによるデータ変換、データマッピングにも対応しています。 access.redhat.com DSLによる素早くインテグレーションできる DSLを理解するにはまずはFuseの開発者ガイドにある「ルート構築の基本原則」を確認いただくことをお勧めいたします。 access.redhat.com 上記URLにも書かれているようにシェルでパイプ(|)でコマンドを連結するようにEIPのパターンを組合せてルーティングをデザインできます。 単純な例ですが、ファイルを取得しContent Based Router EIPを使って、その人がロンドン出身かどうかを判定したいとします。 これを Java DSLで記述すると下記のようになります。 Java DSL from( "file:src/data?noop=true" ) .choice() .when(xpath(“/person/city = ‘London’”)) .log( "UK Message" ) .to(“file:target/messages/uk”) .otherwise() .log(“Other Message”) .to( "file:target/messages/others" ); 参照： Java DSL :: Apache Camel REST APIを簡単に作成できる Fuse は Apicurio Studio がベースとなっている API Designer を使用して、REST API 定義に基づいて Camel Fuse プロジェクトを生成することができます。 access.redhat.com その他のFuse メリット www.redhat.com Fuse 開発の始め方 前置きが長くなりましたが、それではFuseを始めるにあたって最も簡単なスタートポイントをご紹介したいと思います。 Fuseは、「Fuse on Spring Boot」「Fuse on Karaf」「Fuse on JBoss EAP」の3つの方法で始めれますが、今回は「Fuse on Spring Boot」でご説明したいと思います。 1. ブースタープロジェクトにアクセスする Fuseのブースタープロジェクトは fuse アプリケーションの雛形を作成し、実行可能なサンプルを提供することにあります。Fuse開発者はここから簡単にFuseのアプリケーション開発を始めることができます。 前回の記事ではサーキットブレーカーのサンプルコードがありましたが、これと似たFuseサーキットブレーカブースターを作ってみたいと思います。 https://developers.redhat.com/launch にアクセスします。 2. ブースタープロジェクトを開始します 上部中央にある、「Start」をクリックします。 Red Hat アカウントを求められるのでアカウントがない場合は事前に作成しておきます。 Red Hat アカウントはこちらから作成できます。 https://access.redhat.com/ 3. Launcherを開始する ランチャーページで「Deploy an Example Application」をクリックします。 5. Example Application の作成 Create Example Application ページの名前を「fuse-circuit-breaker」とします。この名称でアプリケーションが作成されます。 名前を決めたら次はサンプルアプリケーションタイプを指定します。「Select an Example」をクリックします。 6. Example Application タイプの指定 Exampleにはいくつかのサンプルアプリケーションタイプが並んでいます。今回はFuseのサンプルを動作させますので、右上にあるメニューからFuseを選択します。5つのアプリケーションタイプに絞られたと思います。この中から「Circuit Breaker」を選択します。Fuseのバージョンを選ぶプルダウンメニューが表示されますので、ここでは「7.9.0 sb2 (Red Hat Fuse)」を選択します。その後「Save」をクリックしてください。 7. Example Application の ダウンロード サンプルアプリケーションができたと思いますので、中央のダウンロードをクリックします。 8. Example Application のビルド ダウンロードしたサンプルアプリケーションをUnZipし、任意の場所に配置します。 注意： ビルドにはJava Developer Kit (JDK) とApache Maven 3.3以上が必要です。サポートされる構成は下記をご覧ください https://access.redhat.com/ja/articles/522893 ❯ ls LICENSE greetings-service/ mvnw* name-service/ README.adoc itest/ mvnw.cmd* pom.xml 8.1. プロジェクトビルド サンプルアプリケーションの位置まで移動し、MVNコマンドでプロジェクトをビルドします。 ❯ cd fuse ❯ cd fuse-circuit-breaker ❯ mvn clean -DskipTests =true package [ INFO ] Scanning for projects... [ INFO ] ------------------------------------------------------------------------ [ INFO ] Reactor Build Order: [ INFO ] [ INFO ] Fuse :: Boosters :: Springboot :: Circuit Breaker [ pom ] [ INFO ] Fuse :: Boosters :: Springboot :: Circuit Breaker :: Name service [ jar ] [ INFO ] Fuse :: Boosters :: Springboot :: Circuit Breaker :: Greetings service [ jar ] [ INFO ] Fuse :: Boosters :: Springboot :: Circuit Breaker :: Integration Tests [ jar ] [ INFO ] [ INFO ] ------------< com.yourcompany.newapp:fuse-circuit-breaker > ----------- -- [ INFO ] Building Fuse :: Boosters :: Springboot :: Circuit Breaker 1 . 0 . 0 [ 1 / 4 ] [ INFO ] --------------------------------[ pom ] ------------------------------- -- ...省略... INFO ] Compiling 1 source file to /.../fuse-circuit-breaker/itest/target/test-classes [ INFO ] [ INFO ] --- maven-surefire-plugin:2. 22 .0:test ( default-test ) @ itest --- [ INFO ] Tests are skipped. [ INFO ] [ INFO ] --- maven-jar-plugin:2.4:jar ( default-jar ) @ itest --- [ WARNING ] JAR will be empty - no content was marked for inclusion ! [ INFO ] Building jar: /Users/nmushino/Development/fuse/fuse-circuit-breaker/itest/target/itest -1 . 0 . 0 .jar [ INFO ] ------------------------------------------------------------------------ [ INFO ] Reactor Summary for Fuse :: Boosters :: Springboot :: Circuit Breaker 1 . 0 .0: [ INFO ] [ INFO ] Fuse :: Boosters :: Springboot :: Circuit Breaker .. SUCCESS [ 0 . 090 s ] [ INFO ] Fuse :: Boosters :: Springboot :: Circuit Breaker :: Name service SUCCESS [ 3 . 201 s ] [ INFO ] Fuse :: Boosters :: Springboot :: Circuit Breaker :: Greetings service SUCCESS [ 1 . 336 s ] [ INFO ] Fuse :: Boosters :: Springboot :: Circuit Breaker :: Integration Tests SUCCESS [ 0 . 993 s ] [ INFO ] ------------------------------------------------------------------------ [ INFO ] BUILD SUCCESS [ INFO ] ------------------------------------------------------------------------ [ INFO ] Total time: 5 . 957 s [ INFO ] ------------------------------------------------------------------------ 8.2. name サービスを起動します このサンプルでは呼び名を返すバックエンドサービスである「name」サービスがあります。このサービスを8081ポートで起動させます。 ❯ cd name-service ❯ mvn spring-boot:run -DskipTests -Dserver . port = 8081 [ INFO ] Scanning for projects... ...省略... 2022-06-02 18:39:05. 077 INFO 30925 --- [ main ] o.a.camel.spring.SpringCamelContext : Apache Camel 2 . 23 . 2 .fuse-790054-redhat-00001 ( CamelContext: camel-1 ) started in 0 . 181 seconds 2022-06-02 18:39:05. 080 INFO 30925 --- [ main ] com.redhat.fuse.boosters.cb.Application : Started Application in 2 . 568 seconds ( JVM running for 2 . 839 ) 8.3. greetings サービスを起動します 次に名前を取得するよう name サービスを呼び出し、文字列 Hello, 「NAME」 を返すフロントエンドサービスである greetings サービスを起動させます。このサービスは8080ポートで起動させます。 ❯ cd greetings-service ❯ mvn spring-boot:run -DskipTests -Dserver . port = 8080 [ INFO ] Scanning for projects... ...省略... 2022-06-02 18:42:53. 980 INFO 31447 --- [ main ] o.a.camel.spring.SpringCamelContext : Apache Camel 2 . 23 . 2 .fuse-790054-redhat-00001 ( CamelContext: camel-1 ) started in 0 . 246 seconds 2022-06-02 18:42:53. 981 INFO 31447 --- [ main ] com.redhat.fuse.boosters.cb.Application : Started Application in 2 . 822 seconds ( JVM running for 3 . 16 ) 8.4. greetings リクエストを行う ブラウザーで 「 http://localhost:8080/camel/greetings 」にリクエストします。 { " greetings ": " Hello, Jacopo " } とレスポンスが返却されれば問題なく実行されていることになります。「greetings-service」サービスのログには下記のように name サービスが呼ばれている結果が表示されているはずです。 2022-06-02 18:47:03. 204 INFO 31447 --- [ -CamelHystrix -6] route1 : Try to call name Service 2022-06-02 18:47:03. 216 INFO 31447 --- [ -CamelHystrix -6] route1 : Successfully called name Service 8.5. サーキットブレーカーを確認する それでは name サービス側を「Ctrl−C」などで停止します。 2022-06-02 18:51:05. 663 INFO 30925 --- [ extShutdownHook ] o.a.c.c.s.CamelHttpTransportServlet : Destroyed CamelHttpTransportServlet [ CamelServlet ] 2022-06-02 18:51:05. 667 INFO 30925 --- [ extShutdownHook ] o.s.s.concurrent.ThreadPoolTaskExecutor : Shutting down ExecutorService ' applicationTaskExecutor ' [ INFO ] ------------------------------------------------------------------------ [ INFO ] BUILD SUCCESS [ INFO ] ------------------------------------------------------------------------ [ INFO ] Total time: 12:05 min [ INFO ] Finished at: 2022-06-02T18:51:05+09:00 [ INFO ] ------------------------------------------------------------------------ 次にもう一度ブラウザーで 「 http://localhost:8080/camel/greetings 」にリクエストします。 { " greetings ": " Hello, default fallback " } とレスポンスがあれば、サーキットブレーカーが動作していることを示しています。同様に「greetings-service」サービスのログを見ると「We are falling back!!!!」という内容が表示されているはずです。 2022-06-02 18:54:00. 337 INFO 31771 --- [ -CamelHystrix -6] route1 : We are falling back!!!! 2022-06-02 18:54:03. 200 INFO 31771 --- [ -CamelHystrix -7] route1 : Try to call name Service 2022-06-02 18:54:03. 204 INFO 31771 --- [ -CamelHystrix -7] o.a.c.httpclient.HttpMethodDirector : I/O exception ( java.net.ConnectException ) caught when processing request: Connection refused 2022-06-02 18:54:03. 204 INFO 31771 --- [ -CamelHystrix -7] o.a.c.httpclient.HttpMethodDirector : Retrying request 2022-06-02 18:54:03. 207 INFO 31771 --- [ -CamelHystrix -7] o.a.c.httpclient.HttpMethodDirector : I/O exception ( java.net.ConnectException ) caught when processing request: Connection refused 2022-06-02 18:54:03. 207 INFO 31771 --- [ -CamelHystrix -7] o.a.c.httpclient.HttpMethodDirector : Retrying request 2022-06-02 18:54:03. 211 INFO 31771 --- [ -CamelHystrix -7] o.a.c.httpclient.HttpMethodDirector : I/O exception ( java.net.ConnectException ) caught when processing request: Connection refused 2022-06-02 18:54:03. 211 INFO 31771 --- [ -CamelHystrix -7] o.a.c.httpclient.HttpMethodDirector : Retrying request その後再度「name」サービスを起動しましょう。先程同様に文字列 Hello, 「NAME」が返ってくることが分かります。 8.6. Hystrix ダッシュボードを確認する。 このサンプルアプリケーションではHystrix ダッシュボードを備えています。ブラウザーで 「 http://localhost:8080/ 」にアクセスします。 アクセスすると1秒毎に「greetings」サービスにリクエストするのが分かります。この中で「name」サービスを停止・起動してみましょう。リクエスト結果は常に上位に表示されるため、「name」サービスが停止したときには、「Hello, default fallback」が上位に表示され、「name」サービスが再開したときには代わって「Hello, Jacopo」が上位に表示されることが分かります。 停止 起動 注意： このサンプルアプリケーションに含まれる、 Netflix/Hystrix はメンテナンスモードになっています。 実運用時の場合に採用する場合いおいては、十分ご検討・ご配慮いただくようにお願いします。 Fuse の管理UI Fuse Console は、HawtIO をベースとする Web コンソールです。Fuse Console は、Fuse の詳細を確認および管理するインターフェースを提供し、 Fuse のシステムリソースの監視、更新の実行、およびサービスの開始と停止を行うこともできます。ここではスタンドアローンアプリケーションにFuse Console を導入する方法を説明します。 1. hawtio-springboot を pom.xml に追加 サンプルアプリケーションの pom.xml ファイルに hawtio-springboot の dependency に追加します <dependency> <groupId> io.hawt </groupId> <artifactId> hawtio-springboot </artifactId> </dependency> 2. application.properties に各種プロパティを追加 src/main/resources/application.properties ファイルを編集し次のように追加・変更します。 endpoints.jolokia.sensitive = false endpoints.hawtio.sensitive = false hawtio.authenticationEnabled = false endpoints.hawtio.enabled = true endpoints.jolokia.enabled = true 編集後、以下のような設定になっていると思います。 management.port= 10001 # enable management endpoints for healthchecks and hawtio endpoints.enabled = false endpoints.hawtio.enabled = true endpoints.jolokia.enabled = true endpoints.health.enabled = true management.health.defaults.enabled= false camel.health.enabled= false camel.health.indicator.enabled= true endpoints.jolokia.sensitive= false endpoints.hawtio.sensitive= false hawtio.authenticationEnabled= false 3. Fuse Console へアクセス 先程実施したように greetings サービスを起動させます。 その後、src/main/resources/application.properties ファイルで指定した management.port のポート番号にアクセスします。これでFuseの詳細情報を確認することができます。 http://localhost:10001/hawtio Fuse IDE 最後によく聞かれる質問として開発ツールはどういうものがありますか？と尋ねられることがありますので、参考程度としてご紹介いたします。 Red Hat CodeReady Studio 注意： Red Hat CodeReady Studio は Jboss Tools のコミュニティプロジェクトに移管しました。 製品サポートは現在ご提供しておりませんのでご利用時はご承知おき下さい。 ご利用可能なもので、1つ目には Red Hat CodeReady Studio があります。 Red Hat CodeReady Studio には下記のURLから入手してください。 https://developers.redhat.com/products/codeready-studio/download https://tools.jboss.org/downloads/devstudio/ Language Support for Apache Camel 注意： 下記のLanguage Support for Apache Camel はテクノロジープレビューの機能のため製品サポートは提供しておりません。 ご利用時にはご注意ください。 もしくは、Visual Studio Code の機能エクステンションとして、Language Support for Apache Camel エクステンションがあります。 marketplace.visualstudio.com まとめ 如何でしたでしょうか？ Fuse は製品マニュアルも豊富にまとまっており、スタートポイントとしては始めやすい印象を受けていただけたのではないでしょうか？ この記事をご覧いただいて、まずはやってみようと思っていただけたら幸いです。 参照リンク Apache Camel： https://camel.apache.org/ Fuseの記事： https://thinkit.co.jp/story/2015/03/20/5746 Fuse製品説明： https://www.redhat.com/ja/technologies/jboss-middleware/fuse Apache Camel 開発者ガイド： https://access.redhat.com/documentation/ja-jp/red_hat_fuse/7.10/html/apache_camel_development_guide/index Fuse on Spring Boot のスタートガイド： https://access.redhat.com/documentation/ja-jp/red_hat_fuse/7.10/html/getting_started_with_fuse_on_spring_boot/index

ソリューションアーキテクトの瀬戸です。 直近となりますが、Open Hybrid Cloud Week 2022が6月14日(火)〜 17日(金)に オンラインイベントとして開催されます。 大きく分けて前半2日がセッション、後半2日がハンズオンとなっております。 ohc.redhat-event.com セッション(6月14日～15日) 昨今のビジネス環境は大きく、素早く変化をしています。 それにITシステムを追従させるためにレガシーモダナイズ(アプリケーションの近代化)が必須となっております。 レッドハットはオープンハイブリッドクラウドを提唱し、推進しています。 レガシーモダナイズになぜレッドハットが提唱するオープンハイブリッドクラウドが必要となるのか。 そういう用途に最適化された新しいミドルウェアの料金体系であるRed Hat Application Foundations。 6月にリリースされたばかりのすべての基本となるRed Hat Enterprise Linux 9.0の新機能。 また、それらを使いこなすのためには組織の変革も必要となります。 社内のITシステムが古くなって使いにくい、修正するのに多額のコストがかかる等でお悩みの方がいらっしゃいましたら必見です。 古いシステムの改修に追加のミドルウェアが必要だけれども、稟議を通すだけで数週間から数か月かかるため新しいミドルウェアを投入できないとお困りの方、そういう方にも新しいRed Hat Application Foundationsはお勧めです。 是非、企業の中心たるシステム基盤を生かし発展させていくためのアイデアを見に来てください。 ハンズオン(6月16日～17日) ハンズオンは技術者向けとなっております。 大きく分けてAnsibleによる自動化とOpenShiftによるkubernatesの運用及びにkubernates上での開発体験となります。 Ansible 多数のサーバーを手動で設定していたりしませんか？サーバーだけではなくネットワーク機器を手動で設定したりはしていませんか？ 本番環境と検証環境で同じ設定にしなければいけないのを手動で変更しているため、実際には違う設定になっていたということはありませんか？ 自動化はしたもののシェルスクリプトやバッチファイルを自前で書いていたため、担当者が退職したら読み解けなくなった等はありませんか？ Ansibleを使うことでサーバーやネットワーク機器設定の自動化、標準化を行えます。 以上のことに心当たりがある方はぜひご参加ください。 OpenShift OpenShiftはKubernates上に構築されたアプリケーション開発、運用基盤です。すでにKubernatesの運用をしているがistio等いくつかの決められたアプリの導入を毎回してて面倒くさいとか、 Kubernatesを使うとマイクロサービスの開発が容易になると聞いたが実際にどうやって開発していけば判らないとか、そもそもKubernatesの運用方法がわからないとか、お困りの方はいらっしゃらないでしょうか。 OpenShiftにはKubernates運用のベストプラクティスが詰まっており、また、設定を簡素化するためのGUIツールもそろっているため、 Kubernates運用をすでにしているもののKubernates自体が使いにくく感じている人や、Kubernatesをこれから使い始める方には非常にお勧めとなっております。 ぜひご参加ください。 以下がOpen Hybrid Cloud Week 2022の公式サイトです。申し込みたい方はアクセスしてください。 ohc.redhat-event.com

レッドハットの杉村です。Ansible のテクニカルサポートをしています。毎月1つは何か書くことを目標にしています。5月があっという間に去ってしまいまして、5月34日(6月3日) ということにさせてください。 これまで2回に分けまして、Ansible で扱う変数について紹介しました。 rheb.hatenablog.com rheb.hatenablog.com これまではコマンドラインから ansible-playbook を実行する例を見てきましたが、Ansible automation controller ではもう少々複雑な変数の受け渡しができます。2つの方法について紹介していきます。 Ansible Automation Platform 2.2 (Ansible automation controller 4.2.0) を利用した例で説明していきます。 set_stats ワークフロージョブテンプレートを定義して、複数のプレイブックの実行の間で処理結果を次のプレイブックに引き継ぎたいことがあると思います。 簡単すぎる例で恐縮ですが、このようなワークフローを考えてみます。文字列を引き継ぎたいということだけの例なので、内容の妥当性についてはここでは気にしないでください。 ジョブテンプレートA パスワード文字列を外部変数として受け取る 管理対象にパスワードを設定する パスワード文字列を次のジョブテンプレートで使えるようにする --- - hosts: all gather_facts: false vars: service_account: ansible tasks: - name: store a password for further use set_stats: data: service_account_password: "{{ password_string }}" aggregate: false - name: change a password for a service account user: name: "{{ service_account }}" state: present password: "{{ password_string | password_hash('sha512', 65534 | random(seed=inventory_hostname) | string) }}" become: true set_stats: では aggregate: false を指定しました。これを指定しない場合はデフォルトの true となり、呼び出した数だけ文字列が連結されてしまいます。 ジョブテンプレートB ジョブテンプレートAからパスワード文字列を受け取る 管理対象にアクセスしてhostnameコマンドを実行する --- - hosts: all gather_facts: false vars: ansible_user: ansible ansible_password: "{{ service_account_password }}" tasks: - name: run something command: hostname register: result - name: debug debug: var: result ワークフロー ワークフローでは survey を定義して、実行時に入力を受け付けるようにしました。 実行結果 ワークフロージョブテンプレートを起動すると入力を求められるので適当に入れます。 無事実行されました。 このときそれぞれのジョブテンプレートの結果を見ると、1つ目のジョブテンプレートで set_stats で格納された変数 service_account_password の値が Artifacts として保存されて、2つ目のジョブテンプレートの外部変数として渡っていることがわかります。 入力した文字列は隠したいということはあるでしょうが、ここでは本題ではありません。 ここでは set_stats モジュールで Artifacts として保存されて、外部変数に渡っていくということを示したかったです。 set_fact 先ほどの例では、ジョブテンプレートで生成した変数を次のジョブテンプレートに外部変数として渡せることがわかりました。 もしこれが100台あった場合を考えてみます。今回の例では単純な1つの変数でしたが、100台別々に設定したいということになると、外部変数として100台分のデータをリストにして作成し、後段のジョブテンプレートでは渡ってきた100台分のうち該当するものを選択して使うという処理が必要となってしまいます。 Ansible では fact の仕組みがありまして、以前の記事までで出てきたようなインベントリに設定するホスト変数に対して動的に格納することができます。これにより、100台でも何台であってもシンプルにプレイブックを実装することができます。 先ほど set_stats で実装したものを、set_fact で書き換えてみました。今回はパスワード文字列を外から与えるのではなく、プレイブックの中でホストごとにランダムに生成しています。 ジョブテンプレートA パスワード文字列をランダムに生成する 管理対象にパスワードを設定する パスワード文字列を次のジョブテンプレートで使えるようにする --- - hosts: all gather_facts: false vars: service_account: ansible tasks: - name: generate a password set_fact: service_account_password: "{{ lookup('password', '/dev/null', seed=inventory_hostname) }}" cacheable: true - name: change a password for a service account user: name: "{{ service_account }}" state: present password: "{{ service_account_password | password_hash('sha512', 65534 | random(seed=inventory_hostname) | string) }}" become: true set_fact: では cacheable: true を指定してください。ジョブテンプレートでも Enable Fact Storage オプションを有効にすることで、プレイブックから fact データへの読み書きができるようになります。 ジョブテンプレートB ジョブテンプレートAからパスワード文字列を受け取る 管理対象にアクセスしてhostnameコマンドを実行する --- - hosts: all gather_facts: false vars: ansible_user: ansible ansible_password: "{{ ansible_facts.service_account_password }}" tasks: - name: run something command: hostname register: result - name: debug debug: var: result 外部変数から受け取るのではなく、 ansible_facts から受け取ってきています。これを使うジョブテンプレートでも同様に Enable Fact Storage オプションを有効にしておいてください。 実行結果 このワークフロージョブテンプレートを2台のホストを定義したインベントリーを指定して実行してみました。 それぞれのジョブテンプレートでは入出力がありませんので、Variables や Artifacts は空です。 fact データは、インベントリーからホストをたどると見ることができます。生成した文字列がホストのそれぞれで別々に格納されていることがわかります。 終わりに 今回は Ansible の変数を複数のジョブで受け渡しする方法について紹介しました。 まとめて一つの外部変数として渡したいときは set_stats を使い、ホストごとに別々な値を設定して使いたいときは set_fact を使うことができます。 fact のデータはプレイブックの先頭で gather_facts: true と書いたときに setup モジュールが実行して情報収集された結果や、ダイナミックインベントリでクラウドサービスから API で取得した情報なども格納されます。少々使い方や設定が複雑なところもありますが、automation controller 上で使うことによって便利にお使いいただけるものと思います。 Ansible Automation Platform の試用版はこちらをご覧ください。 www.redhat.com Happy Automation!

Red Hat で Solution Architect として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 JDK Flight Recorder support for GraalVM Native Image: The journey so far | Red Hat Developer の翻訳記事です。 過去1年間、OracleとRed Hatのエンジニアは、GraalVM ネイティブイメージにJDK Flight Recorder（JFR）サポートを導入するために協力してきました。プロトタイプのプルリクエストは、2020 年後半と 2021 年前半に Red Hat と Oracle によって最初に導入されました。その後、すべての関係者の作業を組み込んだ新しいプルリクエストを寄稿する予定で、共有リポジトリで作業が続けられました。2021年6月には、GraalVM上のJDK Flight Recorderをサポートするためのインフラを導入する最初のプルリクエストをOpenJDK 11のアップストリームにマージしました。これは、GraalVMの21.2リリースで利用可能です。この記事では、その背後にある詳細な情報を共有します。ネイティブ・イメージとは何か、なぜJDK Flight Recorderの追加に取り組んだのか、私たちが直面した技術的課題のいくつか、そして私たちが次に何をしようとしているのか、です。 GraalVMネイティブイメージのパフォーマンスプロファイリング GraalVMは、Javaアプリケーションのネイティブイメージを生成するためのサポートを含む高性能ランタイムです。この機能は、Javaのクラスファイルを受け取り、ターゲットプラットフォーム用のバイナリ実行ファイルを生成します。出来上がったネイティブ実行ファイルには、SubstrateVMと呼ばれるJavaで書かれたランタイムシステムが組み込まれており、メモリ管理やスレッドスケジューリングなどのコンポーネンツを含んでいます。これは、OpenJDKがHotSpot仮想マシン（VM）を使ってJavaアプリケーションを実行するのに似ています。ネイティブ実行ファイルは、ポインタ解析とヒープ生成を繰り返し、その後、事前コンパイルを経て生成されます。GraalVMによって生成されるネイティブ実行ファイルは、HotSpotのような従来のJVM上で実行されるJavaアプリケーションと比較して、理想的にはかなり速い起動時間を実現します。 より良いパフォーマンスを約束するバイナリ実行可能ファイルは、モニタリングとパフォーマンスプロファイリングのためのサポートツールのエコシステムをまだ必要とします。しかしながら、現時点では、OpenJDK上のJavaアプリケーションのために一般的に使用されるモニタリング機能のほとんどは、GraalVM上のGraalVM ネイティブイメージのために利用できません。アプリケーションの実行とランタイム実行レイヤーを調査するツールを持たずに、アプリケーションのパフォーマンス問題を診断することは困難です。この不備は、コンテナであろうとベアメタル上であろうと、本番にデプロイされるアプリケーションにとって重要です。 なぜ JDK Flight Recorder か? JDK Flight Recorderは、Hotspot VMのプロファイリングシステムで、イベントベースのロギングシステムを通じてJVM内部データとカスタム、アプリケーション固有のデータを提供します。JDK Flight Recorderは、実稼働環境における重要なデータを最小限のパフォーマンスオーバーヘッドで収集するよう設計されています。従来、出力はJFRファイル（.jfr）であり、JDK Mission Controlなどのツールで読み込むことができました。JDK 14以降では、Java APIを通じてデータをストリーミングできます。 GraalVM ネイティブイメージに対するJDK Flight Recorderのサポートは、HotSpot VMの体験に似た強力なパフォーマンスプロファイリングツールをユーザーに提供することになります。理想的には、OpenJDK上のJavaアプリケーションのプロファイリングにJDK Flight Recorderを使用している開発者が、ネイティブ実行ファイルにも同じように使用できるようにすることです。ネイティブイメージ用のJFRは、HotSpotと同じJFRファイルとストリーミング機能でSubstrateVM内部データ、およびカスタムでアプリケーション固有のデータを提供するSubstrateVMのプロファイリングシステムとなります。 JFR for GraalVM ネイティブイメージは、SubstrateVMシステムの内部データを提供し、HotSpotで見られるデータの種類を多く模倣しています。これには、ガベージコレクション操作、スレッド状態、モニター状態、例外、セーフポイント、オブジェクト割り当て、ファイルまたはソケットI/Oイベントなどについての情報が含まれます。 内部イベントとカスタムイベントによるプロファイリング HotSpotのJDK Flight Recorderやその他のプロファイリングツールは、さまざまな質問に答えるのに役立っています。GraalVM ネイティブイメージのJDK Flight Recorderは、同じことをするのが目的です。これらの質問には、以下のようなものがあります。 ガベージコレクタで消費される実行時間はどれくらいですか？ セーフポイント、Stop-the-World操作にどれだけの時間が費やされていますか？ 実行フローにボトルネックはあるか、それはどこにありますか？ 私のアプリケーションでホットなメソッドは何ですか？ I/O処理にはどれくらいの時間がかかっていますか？ デッドロックやロック待ちのオペレーションなど、同期の問題はどうでしょうか？ JDK Flight Recorderは、内部イベントとともに、開発者が独自のイベントをシステムに追加するためのAPIを備えています。これにより、ユーザーは、既存の低オーバーヘッドで本番環境でも使えるJFRインフラストラクチャの利点を生かした分析用にさらに多くのデータを追加できます。カスタムイベントは、ランタイム定数（クラス名、メソッド名、文字列など）の共通プールを利用でき、個別のカスタムイベントやメトリックを書き出すエージェントと比較して、全体的に出力コストを削減できます。 パフォーマンスの問題を解決 イベント単体では、性能問題を診断するのに十分ではありません。幸い、既存のJFRフォーマットでは、JDK Mission Controlのような可視化・解析ツールとすばやく統合できます。これらのツールを併用することで、ネイティブイメージのアプリケーションのパフォーマンス問題を解決できるのです。SubstrateVMのイベントのうち、HotSpotのイベントと一対一で一致するものは、既存の解析ツールに変更を加えることなく、すでに理解されていることでしょう。 注：JDK Flight Recorder for HotSpotには多数のリソースがあり、そのうちのいくつかは記事の最後にリストアップしています。JDK Flight Recorder全般について、またパフォーマンス問題の解決にもたらすメリットについて、ぜひご覧ください。 GraalVMネイティブイメージのためのJDKフライトレコーダサポートの実装 私たちの作業以前は、GraalVMネイティブイメージのJDK Flight Recorderサポートはなく、そのサポートを実装する際に多くの課題に遭遇しました。Java APIはアクセス可能ですが、JDK Flight Recorderシステムを管理する仕組みはありません。さらに、JDK Flight RecorderのJava APIを直接使用する既存のコード、例えば記録を開始するコードは、unsatisfied link errorで失敗します。この失敗は、JDK Flight RecorderのネイティブAPIが存在しないために起こります。この特定のエラーは、HotSpot ライブラリである libjvm.so にある JDK Flight Recorder のネイティブ コードが SubstrateVM システムに含まれていないために発生します。残念ながら、ネイティブコードはHotSpotの内部と深いつながりがあるため、取り込むのに適していません。 GraalVMネイティブイメージにJDKフライトレコーダーを追加するため、HotSpot VMのJDKフライトレコーダー用ネイティブインフラを、SubstrateVMのJavaコードで完全に再実装しました。しかし、C++で書かれたHotSpotのコードを、Javaで書かれたSubstrateVMの対応するコードに一対一で変換できませんでした。この項では、その理由のいくつかを説明します。 クラス変換 まず、HotSpotのイベントクラスは名目上は空で、実行時にクラス変換を行い、有効なイベント用のメソッドに実装を追加しています。メソッドは空の本体を持ち、finalとマークされ、extendsを防いでいます。イベントが変換されたときに実装がどのようになるかは、EventInstrumentationのコードを見てください。 変換されたイベントクラスは、イベントを発するためにSubstrateVMで必要とされますが、ネイティブイメージの場合、クラスの変換をランタイムで実行できません。OpenJDK JDK Flight Recorderには、Java Virtual Machine Tool Interface（JVMTI）経由でクラスを変換するためのretransformというブーリアン・フラグがあります。デフォルト値はtrueです。これを回避するには、例えば以下のコマンドを使用して、SubstrateVM解析のために実行されているJVMの値をfalseに設定できます。 $ mx native-image -J-XX:FlightRecorderOptions=retransform=false ... その結果、SubstrateVMが見るイベントクラスには、イベントが有効でJDK Flight Recorderが実行されているかのように、変換された実装が含まれます。 もうひとつの解決策は、 jdk.jfr.internal.JVM の内部 API である retransformClasses を使用して、コンパイル前にイベントクラスを変換することです。この回避策も HotSpot JDK Flight Recorder の実装の詳細に依存していますが、変換するクラスをより細かく制御できます。 無停止型セーフティポイント デフォルトでは、ネイティブコード（HotSpot）はセーフポイントのために割り込むことができませんが、Javaコード（SubstrateVM）は割り込めます。幸いなことに、SubstrateVMにはuninterruptibleアノテーションがあり、これを用いてセーフポイントのために中断されないメソッドブロックをマークできます。すべての「ネイティブ」部分をuninterruptibleとしてマークするのは、パフォーマンスが影響を受けるので、理想的ではありません。同様に、HotSpotのJDK Flight Recorderコードパスの中には、「can safepoint here」とコメントされている（そしてセーフポイントを許可するように適切にマークされている）ものもあるので、やはりSubstrateVMの実装には細心の注意を払って、整合性を保つ必要があります。 Uninterruptibleアノテーションの使用には、制限もあります。オブジェクトの割り当てができないのです。これは、オブジェクト指向のプログラミング言語であるJavaでおなじみのコードパターンを実装する際に、非常に問題となります。オブジェクトの割り当てを行うtoStringメソッドはUninterruptibleメソッドコールで使用できないため、ロギングさえも難しくなります。特に、同時実行の問題を扱う場合、単純なデバッガーでは、追いかけている問題と同じ実行フローを見られないため、デバッグが通常より少し難しくなってしまうのです。 さらに、ガベージコレクタのようなSubstrateVMの重要な部分には、中断可能とマークされているメソッドがあります。これらの場所でイベント書き込みインフラを起動できるようにする必要があるため、そのコンポーネントも中断できる必要があります。そのためには、Javaオブジェクトを割り当てないようにする必要があります。幸いなことに、SubstrateVMは、ガベージコレクションによって管理されないmalloc、つまりメモリを解放するためのメソッドを提供しています。しかし、これらのインスタンスはObjectを拡張していないため、ArrayListのような既存のJava APIを使ってデータを操作できません。これらのデータ構造が必要な場合は、再実装する必要があります。 JFR Recorder スレッド データ書き込みのための重要な作業の一部は、HotSpotではJFR Recorderスレッドという単一のスレッドに与えられ、それ自体はJDK Flight Recorderシステムから除外されています。どのスレッドもガベージコレクションなどの仮想マシン操作に流用できるため、SubstrateVMではこの除外を真似できません。ガベージコレクタは、関連するJDK Flight Recorderイベントを発行する可能性があり、除外すると、そのような操作からイベントデータが欠落することになります。 イベントがディスクに書き込まれ、エポックが遷移し、メタデータと定数プールが書き込まれるチャンクのクローズが、ガベージコレクション操作のために一時停止されることさえ可能です。このアクションは、それからガベージコレクションイベントをバッファに書き込めます。ここでのタスクは、これらのガベージコレクションイベントとその定数プールデータのための一貫性を保つために、分析され、中断できないように適切にマークされる必要があります。先に説明したチャンクを閉じるための書き込み操作は、ガベージコレクションに充当される可能性を考慮して、中断できない部分を持つセーフポイント操作として慎重に書く必要があります。 まとめ JDK Flight Recorderは、HotSpot VMの重要な機能で、実稼働環境での連続実行に適した低いオーバーヘッドで、JVMの実行に関する膨大な量のデータをユーザーに提供します。SubstrateVMでネイティブイメージアプリケーションを実行する際、開発者が同じツールにアクセスできるのは便利でしょう。 JFRインフラの初期マージは完了しましたが、HotSpotで可能なのと同様に、GraalVMで生成されたネイティブ実行ファイルへのビューをシステムが提供できるまでには、長い道のりが待っています。次は、ガベージコレクション、スレッド、例外など、SubstrateVMの有用な場所に対するイベントを追加する作業です。SubstrateVMには今のところRJMX APIが実装されていないため、JDK Flight Recorderをリモートで管理するAPIはありません。これと並行して、OpenJDKとHotSpotでは、JFRシステムの大幅な改良と強化がまだ行われています。異なる基礎となるOpenJDKのバージョンを適切にサポートするために、SubstrateVMの実装でAPIに影響を与える大きな変更を考慮する必要があります。現時点では、コードベースはOpenJDK 11のみを対象としています。 とりあえず、最新のGraalVMを試し、ビルド時のネイティブイメージプロセスに-H:+AllowVMInspectionというフラグを渡して、JDK Flight Recorderをテストできます。それが終わったら、実行時にアプリケーション・バイナリに -XX:+FlightRecorder -XX:StartFlightRecording="filename=recording.jfr" などのフラグを追加するとよいでしょう。 GraalVMと並んで、Quarkusのコミュニティ・ディストリビューションであるMandrelも、当然JFRのサポートを引き継ぎます。JDK Flight Recorder for GraalVM Native Imageの改善と改良を続けながら、QuarkusとMandrel環境でのネイティブイメージでのJFRの使用に関する発表と記事をお待ちください。 JDK Flight Recorderについてもっと知る JDK Flight Recorderの詳細と、パフォーマンス問題の解決に使用するためのリソースは、以下のとおりです。 An introduction to Middleware Application Monitoring with Java Mission Control and Flight Recorder (Mario Torre and Marcus Hirt, FOSDEM 2019) Get started with JDK Flight Recorder in OpenJDK 8u (Mario Torre, Red Hat Developer) Using Java Flight Recorder with JDK 11 (Laszlo Csontos, DZone) Troubleshoot Performance Issues Using JFR (Java Platform, Standard Edition Troubleshooting Guide, Oracle) JDK Flight Recorder—a gem hidden in OpenJDK (BellSoft) JDK11—Introduction to JDK Flight Recorder (Markus Grönlund, Oracle YouTube) Monitoring REST APIs with Custom JDK Flight Recorder Events (Gunnar Morling) Introduction to ContainerJFR: JDK Flight Recorder for containers (Andrew Azores, Red Hat Developer)

5/18に、Red Hat Enterprise Linux(RHEL)として8番目のリリース、RHEL9がリリースされました!! 5/11のRed Hat Summitでの発表から1週間ほど後のリリースでした。みなさんすでにチェック済でしょうか？ www.redhat.com えっもうRHEL9でたの!? 早くない?? という反応をチラホラお見受けします。そう思われた方は鋭いです。そうなんです。RHEL8のリリースから、「メジャーバージョンのリリースは3年ごと、マイナーリリースは6ヶ月ごとに行う」というリリースモデルを定めるようになり、RHEL9はその メジャーバージョンのリリースは3年 のルールに従ってリリースされた初めてのRHELということになります。 過去のものも含め、RHELの各バージョンのリリース日はここで確認することができます。 access.redhat.com 前回、RHEL7.0のリリース(2014/06/09)からRHEL8.0のリリース(2019/05/07)の間はおおよそ 5年弱(!) でしたから、今回のリリースはとても早く思われるのも当然です。これからは、新しいリリーススケジュールでRHELの新しいバージョンがリリースされていきますので、 皆さんついてきてください!! :) CentOS Streamで開発、リリースされる初めてのRHEL また、RHEL9は、 CentOS Stream をベースに開発し、リリースされた最初のRHELでもあります。CentOS Stream 9の開発は オープンな場所 で行われ、RHEL9のリリース前にRed Hatの開発チームではない外部のコントリビューターの方々からのフィードバックが製品に取りこまれています。Red Hat Summitのトークセッション「 Ask the experts anything about Red Hat Enterprise Linux 9 」でCentOS StreamとRHEL9の話がされていますので、 登録 してオンデマンド配信(日本語字幕つき)ををぜひチェックしてみてください!! ちなみに、セッションのリンクはこちらです Red Hat Summit 2022 - Ask the experts anything about Red Hat Enterprise Linux 9 https://events.experiences.redhat.com/widget/redhat/sum22/SessionCatalog22/session/1646250804645001HBvF 早速RHEL9を堪能しよう!! さて、RHEL9の始め方は人によって様々だと思いますので、目的別に始め方をご紹介します。あなたのRHEL9はどこから？ 何はともあれドキュメントを確認したい どんな新機能や変更点があるかを眺めてニヤニヤしたい方は、まずリリースノートがオススメです。いきなり動かしてアレができない!!みたいなことが起きるのを避けたい慎重派の方にもオススメです!! access.redhat.com 個人的には、将来のC ABI互換性維持のためにこのタイミングでupstreamのベースバージョンであるFedora 34から一歩進んでglibc2.34を入れたところが、長期サポートするRHELならではのポイントなのですがあまり伝わりませんよね。わかります。 ライフサイクルもこちらで確認しておくとよいです access.redhat.com RHEL8から登場したApplication Streamsリポジトリにあるパッケージのライフサイクルはこちら access.redhat.com isoイメージがDVDメディアのサイズを超えているかどうか確かめたい これもちょこちょこ反応ありましたね... RHELのisoイメージがどんどん大きくなる昨今ですが、さっそくイメージをダウンロードしたい方はこちらへどうぞ!! developers.redhat.com もちろん、従来通りカスタマーポータルの Product Downloads からでも入手できます。qcow2の仮想マシンイメージなどもこちらから。個人で試してみたいけどサブスクリプションがないよーという方は、ぜひ Developer Subsicription for Individualsを取得 してください。個人の開発目的で、最大16台までRHELが無償で使えます。登録から20分くらいでお使いのRed Hat IDにサブスクリプションが付与されます。 さて、上記のダウンロードページを見ると、 Boot iso という、サイズの小さなisoイメージがあるのにお気づきかと思います。昔からRHELをインストールされている方は「知ってるよ、NFSサーバとかにDVD isoのイメージを展開しておいてインストールできるやつでしょ？」とすぐに用途がわかるかもしれません。しかし実は、RHEL8.4以降、そしてRHEL9では、Red Hat ID とサブスクリプションを持っていて、インターネットに接続できるなら、anacondaインストーラーの中でRed Hat IDでログインして、 Red Hat CDNからインストールに必要なパッケージだけをダウンロード、インストールすることが可能 になっています。DVDメディアに収まらないほどのコンテンツを全部ダウンロードしなくても大丈夫です!! rhel-installer-red-hat-connect コンテナ大好きなのでコンテナで試したい RHEL9ベースのUniversal Base Image(UBI)もリリースされています。RHELでは Universal Base Image という、RHELのサブセットコンポーネントで作られている、再配布可能なコンテナイメージを提供しています。 Red Hatのコンテナレジストリ や、 DockerHub から入手可能です。 「UBIって何？」という方は、こちらの資料もご覧ください。 speakerdeck.com パブリッククラウドが大好きなので(略 認定クラウドプロバイダー様の認定イメージは順次提供されていきます。提供されしだいアップデートします。 Cloud Accessをお使いで、イメージを自分で用意して動かしたいよ、という方は、Red Hat SummitでGAになった、Red Hat Open Hybrid Consoleの新機能 Image Builder Service からイメージを作ってプロビジョニングしてみてください!! 俺はそのさらに先に行く...止めるな RHEL9.0がリリースされましたので、CentOS Stream 9は次のRHEL9のマイナーリリースである9.1に向かって走り始めています。RHEL9.0と併せて、違いがどのくらいあるのか見るなどしてみてはいかがでしょうか? CentOS StreamでRHELの開発への参加、お待ちしていますよ!! 他にもRHEL9についての色々なポイントを記事にしていきますのでお楽しみに!! ではでは、ソリューションアーキテクトの橋本( id:kenya888 )がお届けしました。皆さんRHEL9をエンジョイしてください!!

こんにちは、ソリューションアーキテクトの蒸野（ムシノ）です。 今回から「Red Hat Fuse」について数回に分けて取り上げてみたいと思います。 まず、Fuseの製品紹介については、下記をご覧ください。 www.redhat.com 初回はFuseのベースとなっている「Apache Camel」の概要に絞って説明をしたいと思います。 「Apache Camelのユーザ会」では以下のように説明しています。 オープンソースのコンポーネントベースのルーティングエンジン 例えば自分のマシン上で作成したExcelやCSVデータがあるとします。 この時、自分のPCの作業場所から別の場所に移動/コピーしたり、他のコンピュータに送信したり、不足している情報を他のコンピュータから取得してExcelやCSVに追加する作業が必要となるケースがあります。 処理するデータ量が少なければ手作業でやっても全然差し支えありませんが、これを1日に何千件も処理する必要があるとしたらさすがに自動化したいと思いませんか？ Javaやシェルスクリプトを使って自動化することも可能ですが、データの送信先が1台のPCから複数台に増えたら送信先を改めて追加する必要があり、更に送信するにしてもメールやFTPと別々のプロトコルで送る必要があったりした場合、プログラムが煩雑になってしまいます。Apache Camelはまさしくこのようなことを自動化するのに最適なフレームワークになります。 SOA全盛期のインテグレーション方式 　　　　 SOAによるシステム統合が活発な時期には、インテグレーション方式として Enterprise Service Bus（ESB）がよく使われていました。 しなしながら同時に多くの課題も見受けられるようになっていきました。例えば、 ESB自体が巨大なモノリシックなアプリケーションとなっていった。 当時は相当高価なソリューションであり一部の大企業しか導入ができない製品だった。 企業ガバナンスとして通信をESBに集めるように求められるようになった結果、パフォーマンスボトルネックが問題になった。 ESBが単一障害点になってしまい、これを運用するチームも保守的体制になることでビジネス柔軟性を損なっていった。 運用するチーム独自の接続方式標準化がなされ、利用側はその独自の標準方式に則って接続することで使いづらいシステム接続になっていった。 ESBにはデータ変換機能もあったが、性能を維持するため通信を通過させるためだけに利用するケースも散見され本来の機能を活かしきれていなかった。 Apache Camel こういったESBの課題に対して、軽量ルーティングフレームワークとして登場したのが Apache Camelです。 先程同様「Apache Camelのユーザ会」を参考にしていますが、下記のように定義しています。 Apache Camelを使うことで以下のことが簡単に実現できます。 ・各種プロトコルを使った送受信 ・キーワードを元に送信先の振り分け ・Apache Software Foundation(ASF)を始めとした100以上のOSSの活用 Camel を紹介するサイトでは、軽量なルーティングエンジンと言ったり、ライブラリやフレームワークとバラバラな表現となっていますが、大雑把に捉えれば軽量かつ、様々なシステムを統合するために豊富なコンポーネントを持ち、インテグレーションに必要なルーティング機能を提供してくれると理解すれば良いでしょう。よく誤解されがちな点として、100以上のOSSを組み合わていることから大規模なインテグレーションOSSと思われますが、実際には約数M程度のライブラリで構成された軽量なOSSです。また、様々なコンポーネントを追加することで拡張することができるプラガブルなアーキテクチャを採用していますので、必要なインテグレーションにあわせてコンポーネントを選択して利用することができます。現在は200を超えるコンポーネントが存在しており、ドキュメントも豊富にあります。 Apache Camelの得意分野 ・定期的な処理、バッチ処理、クーロンで行っている処理 ・各種プロトコルから各種プロトコルへの変換、データ変換 Apache Camelの不得意分野 ・MVCモデルのView部分 ・ワークフロー（状態を永続化させるフロー） 基本的なアーキテクチャ Apache Camel のドキュメントにも紹介されているシンプルな全体アーキテクチャになります。 https://camel.apache.org/manual/architecture.html Apache Camel のコア機能として CamelContext があり、この CamelContext にはCamelのランタイムすべてを含んでいます。 ルートは、CamelのDSLを使って定義されます。 プロセッサはルーティング中にメッセージを変換・操作・仲介、またはEnterprise Integration Patterns（EIP）を実行するために利用されます。 コンポーネントは、Camelの接続機能を強化し他のシステムとの接続性を容易にします。 次に、このルートについてのシンプルなアーキテクチャが、Japan Camel User Group で説明されていますので、こちらのほうも示しておきたいと思います。 まずルーティングエンジンは、一連のフローを定義する「ルート」を使用します。このルートをCamelルートとも言ったりします。 次に、開始点になる「スタートポイント」、および終了ポイントになる「エンドポイント」があります。これはシステムが外部とのメッセージを送受信するインターフェースと思えば理解しやすいかと思います。 エンドポイントは、データを受け取る「コンシューマ」と、データを送信する「プロデューサ」として区別されることもあります。 また、コンシューマはイベント駆動コンシューマと、ポーリングコンシューマが存在します。 最後に、メッセージの変換や加工、コンポーネントを呼び出し処理を行ったりする「プロセッサ」になります。このプロセッサは処理をチェーンさせた形で定義されます。 Java DSLで定義したルートの例 // Consumer from("jetty:http://localhost:8080/orders?httpMethodRestrict=POST") .process().body(this::process1)) // Processor 1 .process().body(this::process2)) // Processor 2 .to("jms:queue:order?timeToLive=86400000"); // Producer ETLとEAIの違い こういった特徴を説明していくとよくEAIやETLとどう違うのか？といった質問を受けるケースがあります。 ETLは、データの抽出・変換・書き出しを行う一連のプロセスであり、一般的には、DWHにデータを保存する際の前処理として行われます。 EAIとは業務システムやメインフレームシステムといったシステム間のデータ連携を行う方式であり、各システムへ接続するインターフェース、フォーマット変換、ルーティング処理、プロセス制御などの機能を有しており以前からインテグレーション製品としても良く知られていました。CamelはEAIやESBと同様のことが実現可能ですが、これに加え軽量で分散インテグレーションが可能なことが特徴とも言えます。Camelの登場によって、大規模なプロジェクトに留まらず一般的なプロジェクトでもインテグレーション機能が利用しやすくなったというところが大きな変換点と言えるかと思います。 特徴のまとめ いろいろな特徴を持っているので簡単には説明しにくいところではありますが、Apache Camel 超概要ということで、5つだけピックアップして説明したいと思います。 特徴1：ルーティング処理 Camelの代表的な強力な機能の一つと言えるルーティング。Camelでは受け取ったデータは、分岐やフィルタリングさせたり、分割して並列処理させたり、それらを集約したりすることができます。 またHTTP通信のような同期処理から、非同期処理へと切り替えることや、並列実行なども可能であり、さらには分散したマイクロサービスに複数のキューを経由させながら、応答メッセージを受け取るようなルーティングも実現できます。特殊な用途としては、分散処理としてラウンドロビンで宛先を切り替えて簡易なロードバランサーのように振り分けたり、または一度に流れるデータの流量を調整するといったことも可能です。 特徴2：様々な変換処理が可能 Camel には150を超えるデータ変換機能があります。JSON、XML、CSV、Javaオブジェクトなどのデータタイプを扱うことができ、データタイプを相互に変換することができます。その他、Camel がサポートしないデータ変換が必要な場合には独自のコンバータを作成し利用することができます。 特徴3：様々なコンポーネントが用意されている 標準で200以上のコンポーネントが存在しており、FTPやSSH、HTTP(S)といった昔からある通信プロトコルや、RESTやSOAP、ファイル、データベース、メッセージキュー、メール、MQTTなどを相互に接続して連携させることが可能です。また、AWSや、ビッグデータやNoSQL関連プロダクトとのアクセス、FacebookやTwitterへの連携などのコンポーネントも用意されており、ほぼ標準コンポーネントで必要な連携が実現できます。また、必要があればモジュラーアーキテクチャにより独自のコンポーネントを実装することで統合ができます。コンポーネントによりますが、大方のコンポーネントは接続エンドポイントに対してURI設定を行うだけで利用できます。 特徴4：非同期処理 Camelはノンブロッキングによる非同期処理に対応します。例えば背後のシステムにAPIリクエストしたがレスポンスに時間がかかる場合、その応答までスレッドをブロックながら待ち続けるのはシステムの性能を大きく損なわせます。Camelはスレッドを有効に再利用することで高いスケーラビリティを発揮します。エンドポイントのコンポーネントが対応しているかなどのいくつかの条件が揃えば、Camelのエンジンは自動的に非同期処理を選択するため、何もせずとも非同期処理が実現できます。 特徴5：エラーハンドリング システム連携で実現方法の課題となりやすいものの代表例がエラーハンドリングです。Camelは一時的なエラー時のリトライ処理の実現はもちろんのこと、中長期に渡る障害がシステム全体に波及していくことを防ぐためサーキットブレーカーやバルクヘッドといったより高度なエラーハンドリングも簡単な設定で利用することができます。また、エラーの滞留を防ぐために専用のキューにメッセージを移動させる機能もあります。 サンプルコード このコードは「Japan Camel User Group 」にあるコードの再掲ですが、大雑把な処理内容としては下記処理を行っています。 ユーザ登録用のJSONリクエストをRESTサービスで受けつける DBにユーザデータを登録する テンプレートエンジンでメールの文面を作成して、ユーザにメールを送信する(別スレッドを用いて非同期で処理) ユーザの追加を他システムに通知するためのイベント(XML)をキューに登録する エラーハンドリングを行う // usersのパスにpostが送信されたら処理を開始 // 次のようなリクエストを想定 {name:"username_1", email:"xxxx@redhat.com"} rest("/users") .post() .route() .hystrix() // サーキットブレーカーの設定 // 10秒以内に処理が終了しなかったらタイムアウトエラーにする // 何らかのエラーが15秒以内に2回以上発生したら本サービスを120秒間停止(サーキットブレーカーをOpen)する .hystrixConfiguration() .executionTimeoutInMilliseconds(10000) .metricsRollingPercentileWindowInMilliseconds(15000) .circuitBreakerRequestVolumeThreshold(2) .circuitBreakerSleepWindowInMilliseconds(120000) .end() // JSONをMapオブジェクトに変換 .unmarshal().json(JsonLibrary.Jackson, Map.class) // DBにUserデータを保存 .to("sql:insert into users(name, email) values(:#name, :#email)") // [サブルート呼び出し(別スレッドを用いて非同期で処理)] ユーザへメールを送信 .wireTap("direct:userCreatedNotificationMail").end() // ユーザの追加を他システムに通知するためのイベント(XML)をキューに登録する .transform(new Map2XML("user-created")).to("jms:UserCreated") // 成功を応答する .transform().constant("{result:\"true\"}") // エラーやサービスがクローズされている場合には、失敗を応答する .onFallback() .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(503)) .transform().constant("{result:\"false\"}") .end(); // [サブルート] メールの文面をテンプレートを用いて作成し、ユーザへメールを送信 from("direct:userCreatedNotificationMail") .setHeader("to", simple("${body[email]}")) .to("velocity:template/velocity/createdUserNotification.vm") .to("smtp://smtpserver?password=&username="); 用語説明 最後に説明時に登場しました重要キーワードの整理をしておきます。 Enterprise Integration Patterns（EIP） システム統合のプロジェクトに携わった方であればご存知かとは思いますが、エンタープライズインテグレーションではインテグレーションの方式設計が欠かせません。 しかしながら様々なインテグレーション現場では独自に標準化していることもしばしばあり、非効率な処理を強制していることも少なくありません。 Enterprise Integration Patternsは、Gregor Hohpe 氏と Bobby Woolf 氏によりインテグレーションのベストプラクティスをまとめ、 エンタープライズ統合パターンとして著書にしたものです。かなり分厚い英書の書籍ですが、もしも Camel でのインテグレーションを考えているのであれば一度読んでみることをお勧めいたします。 60パターン以上のインテグレーションパターンが紹介されています。 www.enterpriseintegrationpatterns.com ちなみに、Camelで実現可能なインテグレーションパターンは下記URLにまとまっています。 EIPのほとんどのパターンを実現し、EIPとCamel DSLはほぼ1対1で対応しています。 https://camel.apache.org/components/3.17.x/eips/enterprise-integration-patterns.html: ドメイン固有言語(DSL) ドメイン固有言語は一般的に、ある特定の領域に特化したプログラミング言語のことを示します。 Apache CamelはEnterprise Integration Patterns（EIP）とドメイン固有言語（DSL）の組み合わせで処理したいインテグレーション処理を定義します。 この時、Camelルートにドメイン固有言語（DSL）を使用して処理を記述します。例えば、Java DSL、Spring XML、XML DSL、Yaml DSLなどが利用できます。 他のインテグレーションフレームワークも近年DSLを備えているものが増えていますが、Camelと異なり独自の言語により実現していることがあります。CamelはJavaを始めとする複数のプログラム言語で記述することができます。 まとめ 如何でしたでしょうか？ 今回は、Apache Camel の概要をテーマに記載させていただいたのでかなり概念的な内容でしたが、なぜ Camel を使うのか？どんな特徴があるのか？など理解いただけたのではないでしょうか。 次回以降は、Camelをベースにした製品であるFuseとその製品ファミリについてご紹介していきたいと思います。 参照リンク Apache Camel： https://camel.apache.org/ 日本Apache Camelユーザ会： https://ja.osdn.net/projects/cameluserjp/wiki/FrontPage Japan Camel User Group： https://jcug-oss.github.io/article/why-do-we-have-to-learn-camel-q Fuseの記事： https://thinkit.co.jp/story/2015/03/20/5746 Fuse製品説明： https://www.redhat.com/ja/technologies/jboss-middleware/fuse Apache Camel 開発者ガイド： https://access.redhat.com/documentation/ja-jp/red_hat_fuse/7.10/html/apache_camel_development_guide/index

Red Hat のソリューションアーキテクトの森です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトがご紹介していきます。 今回は 2022/6月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: JBoss EAP 6のセキュリティフィックスが行われなくなるのでEAP 7への移行を検討する JBoss EAP 6.xのELS-1 が2022年6月30日に終了する予定ですが、EAP 6からEAP 7へ移行をしようと思っても何から手を付けてよいのかわからないという人もたくさんいると思います。 この記事では移行内容の見積もりや実際に移行するときに使える「MTA(Migration Toolkit for Applications)」と「JBoss サーバー移行ツール(JBoss Server Migration Tool)」の二つを紹介します。 rheb.hatenablog.com 特集2: アプリケーション・モダナイゼーション： マイクロサービスのメリットって？ 企業のDXを実現するために、レガシーなシステムをマイクロサービス化する、という話は、皆さん一度は耳にしたことがあるのではないでしょうか。 しかし一方で、全てのシステムに対して、マイクロサービス化をすることが最適解というわけではありません。 今回は、マイクロサービスのメリットとデメリットについて、改めて再確認をしてみました。 rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat build of Quarkus 2.7

Red Hatでは非営利団体や教育機関（わかりやすくいうと大学、専門学校などの学校）向けに一部のトレーニングを無償で提供しています。 学校でLinuxのトレーニングコースを作ったけれどもいつの間にか陳腐化して、古いコマンドで、古いOSのバージョンのまま授業を行っていることはないでしょうか？ Red Hatが準備しているRed Hat アカデミーを利用することでいつでも最新の環境での授業を行えるようになります。 現在、ほとんどの企業ではLinuxやJavaを使用しています。また、先進的なサービスを提供している企業においては、 Docker等のコンテナやKubernates等のコンテナオーケストレーションツールを使用してシステムの開発や運用が行われております。 Red Hat アカデミーではそれらに関する教育コースを無償で提供しております。 もちろん日本語でです。 E-Learningの形式で、Web上で読みながら進める形となっています。 コース中に使用するマテリアル *1 については別途ダウンロードして実行して頂く形になります。 *2 *3 新しくIT業界に入られる方にとって非常にメリットのある話だと思いますので、ぜひお知り合いの学校関係者でIT教育をどうするか頭を悩ませてる方がいらっしゃいましたらぜひご紹介ください。 古いトレーニングコースのマイグレーションについて頭を悩ませることはなくなります。 無償で公開しているコースは現時点では以下の通りです。 それぞれのコースが標準的に40時間程度かかるコースとなっております。 ※リンク先はRed Hatが企業向けに研修を行う場合のページであり、あくまで提供されるのはE-Learningの形式のみです。 Red Hat Training: Getting Started with Linux Fundamentals (RH104) Getting Started with Linux Fundamentals (RH104) は、Linux システムにアクセスして Linux ベースのアプリケーションとサービスを実行するが、UNIX または Linux の経験がわずかしかない、またはまったくない IT プロフェッショナルおよびビジネスユーザーを対象としています。このコースでは、Linux システムの管理や運用を担当していない Linux ユーザーに、Linux の概念と基本的なスキルを紹介します。システム管理者のスキルが必要な場合は、このコースではなく Red Hat システム管理 I (RH124) を受講してください。 www.redhat.com Red Hatシステム管理I（RH124） Red Hat System Administration I (RH124) は、これまでに Linux システムを管理した経験がない IT プロフェッショナルを対象としています。このコースは、コア管理タスクに重点を置いて、受講者に対して Linux の管理の「必須スキル」を提供することを目的としています。また、Red Hat System Administration I では、基本的なコマンドラインの概念とエンタープライズレベルのツールを紹介することにより、フルタイムの Linux システム管理者になる予定の受講生を対象に基礎知識について解説します。これらの概念については、後続のコースである Red Hat System Administration Ⅱ (RH134) でさらに詳しく取り上げます。 www.redhat.com Red Hatシステム管理II（RH134） Red Hat システム管理 II (RH134) では、フルタイムの Linux 管理者になるために必要な主要タスクと、このようなスキルを Red Hat 認定システム管理者試験によって確認するために必要な主要タスクについて学習します。このコースでは、ファイルシステムとパーティション、論理ボリューム、SELinux、ファイアウォール、トラブルシューティングなど、Enterprise Linux 管理について詳しく説明します。 www.redhat.com Red Hatシステム管理III:Linux 自動化（RH294） Red Hat Enterprise Linux Automation with Ansible (RH294) は、プロビジョニング、構成、アプリケーション・デプロイメント、およびオーケストレーションを自動化する必要がある、Linux システム管理者および開発者向けです。 受講生は、Ansible を管理ワークステーションにインストールして設定し、管理ホストの自動化を準備する方法を学びます。受講生は、タスクを自動化する Ansible Playbook を作成し、それらを実行してサーバーが正しくデプロイおよび設定されていることを確認します。一般的な Linux システム管理タスクを自動化するためのアプローチの例を学習します。 www.redhat.com Red Hat OpenStack管理I（CL110） Red Hat OpenStack Administration I: Core Operations for Domain Operators (CL110) は、OpenStack を使用したクラウドコンピューティング環境の管理を検討しているドメインオペレーターを対象としています。受講生は、Red Hat® OpenStack Platform の運用と保守の方法について学習します。 www.redhat.com Containers、Kubernetes、Red Hat OpenShiftの紹介（DO180） Red Hat OpenShift I: Containers & Kubernetes (DO180) では、コンテナを構築および管理し、Kubernetes クラスタ上にデプロイする方法を紹介します。このコースは、開発者、管理者、サイト信頼性エンジニアなど、複数の職務で必要とされるコンテナ、Kubernetes、および Red Hat OpenShift Container Platform に関する実践形式の授業で、コンテナ管理の基本的な知識とスキルを習得できます。 https://www.redhat.com/ja/services/training/do180-introduction-containers-kubernetes-red-hat-openshift www.redhat.com Red Hat OpenShift Development I: Introduction to Containers with Podman(DO188) Red Hat OpenShift Development I: Introduction to Containers with Podman (DO188) では、Podman と Red Hat OpenShift を使用したコンテナの構築、実行、管理について紹介します。このコースでは、実践的な体験を通じて、コンテナ化アプリケーションを開発するためのコアスキルを構築します。これらのスキルは、Red Hat OpenShift on AWS (ROSA)、Azure Red Hat OpenShift、OpenShift Container Platform など、OpenShift のすべてのバージョンの使用に適用できます。 www.redhat.com OpenShiftアプリケーションの紹介（ DO101） OpenShift アプリケーションのビルド、デプロイ、スケーリング、およびトラブルシューティングのための開発者向け入門コース。 www.redhat.com Red Hatアプリケーション開発 I：Java™ EEプログラミング（ AD183） Red Hat Application Development I: Programming in Java EE (AD183) は、経験豊富な Java Standard Edition (Java SE) 開発者に Java Enterprise Edition (Java EE) の世界を紹介します。 このコースは、Red Hat® Enterprise Application Platform 7.0 に基づいています。 このコースでは、Java EE を構成するさまざまな仕様について学習します。実践演習を通じて、シンプルな Java SE コマンド・ライン・アプリケーションを多層エンタープライズ・アプリケーションに変換します。そのために、Enterprise Java Beans、Java Persistence API、Java Messaging Service、REST サービス用 JAX-RS、Contexts and Dependency Injection (CDI)、アプリケーションを保護するための JAAS など、さまざまな Java EE 仕様を使用します。 www.redhat.com Python Programming with Red Hat（ AD141） 初心者向け Python プログラミング Python は、システム管理者、データサイエンティスト、開発者が Web アプリケーションの作成、Red Hat Ansible Automation カスタムモジュール、統計分析の実行、AI/ML モデルのトレーニングに使用する人気のプログラミング言語です。このコースでは Python 言語の概要と、制御フロー、ループ、データ構造、関数、ファイル I/O、正規表現、JSON の構文解析、デバッグなどの基本的な概念を学びます。このコースは、Python 3 および RHEL 9.0 に基づいています。 www.redhat.com これらのコースに関しては企業向けに有償で公開しているものと同じになります。いつでも最新版です！ 問い合わせ先 これ使いたいかもと思われる教育機関の方がいらっしゃいましたら、是非以下からお問い合わせください。 docs.google.com Red Hat アカデミーの公式サイトは以下となります。 www.redhat.com ご参考(事例) ict-enews.net SAの瀬戸でした。 *1 : Java™ EEプログラミングコースであれば使用するミドルウェアやサンプルプログラム等 *2 : クラウド上に構築した研修環境をRed Hatにて準備することも可能ですが、そちらは有償となります。 *3 : 例外としてDO180 Containers、Kubernetes、Red Hat OpenShiftの紹介 についてはRed Hat側で無償で環境を準備します。

レッドハットのソリューションアーキテクトの森です。 今回は、アプリケーション・モダナイゼーションの話についてです。 企業のDXを実現するために、レガシーなシステムをマイクロサービス化する、という話は、皆さん一度は耳にしたことがあるのではないでしょうか。 しかし一方で、全てのシステムに対して、マイクロサービス化をすることが最適解というわけではありません。そこで、マイクロサービスの特徴や、開発・運用するにあたって必要な要素、実際に移行する際の方法論などを数回に分けてご紹介していきたいと思います。 そもそもマイクロサービスって何？ マイクロサービスとは、サービスと呼ばれる、独立して開発されて稼働するコンポーネントを、複数組み合わせて１つのアプリケーションとして構成するものです。各コンポーネントは別々のマシン（あるいはサーバー、またはコンテナ）に分かれており、１つのリクエストに対して、RESTやメッセージングによる通信でデータを送り合うことで処理を行います。この小さな単位に分割された構造と分散コンピューティングが、マイクロサービスの大きな特徴です。 サービスの分割の粒度ついては、こちらの記事も参照して頂ければと思います。 rheb.hatenablog.com マイクロサービスについての理解を深めるために、従来型のアーキテクチャとの比較をしてみましょう。 よく、マイクロサービスとの対比で引き合いに出される従来型のアーキテクチャに、モノリス（またはモノリシック）と呼ばれるものがあります。モノリスは、英語で「一枚岩」という意味ですが、よくある形としては、３層構造（ユーザーインターフェイス、ビジネスロジック、データ）で構成されているものが多いかと思います。また実際には、ビジネスロジックも内部的にはいくつかの機能ごとに分かれていると思います。ここでは、複数の機能が単一のアプリケーションで構成されるもの、として考えてみます。 図1：モノリスとマイクロサービスの違い モノリスとマイクロサービスの違い 上記で見た構造の違いにおいて、モノリスとマイクロサービスにはそれぞれメリット・デメリットがあります。 その内容を、以下の表のように整理をしてみました。 図2：モノリスとマイクロサービスのメリット・デメリット 敏捷性 従来のモノリスにおいても、アプリケーションの中は複数の機能から構成をされています。開発もその単位では行われるものの、アプリケーションとしては単一のモジュールとなっており、各機能は独立しておらず依存関係があります。そのため、ある機能が先行して開発を完了したとしても、他の機能との整合性が取れていないと稼働することができず、全ての機能の開発の完了を待ってリリースをする必要があります。 しかし、マイクロサービスを適用してアプリケーションを小さい単位に分割をしていれば、サービスごとに独立した開発やデプロイが可能となります。結果として開発・リリース速度の向上が期待でき、ユーザーも速やかに新しい機能を使うことができるようになります。 図3：敏捷性 独立性 モノリスでは、開発に使うプログラミング言語や製品などもアプリケーションで共通のものを使用する必要があるため、個々のアプリケーションやチーム特性に対して最適化することはできません。 対してマイクロサービスでは、サービスごとに異なるプログラミング言語や開発手法を採用することが可能になります。プログラミング言語には、用途によって向き不向きがあるため、サービスごとに適した言語を選択できることは、開発効率の最適化に繋がります。 図4：独立性 保守性 モノリスでは、アプリケーションの改修を繰り返す度に、プログラムは大きく、複雑化していき、機能間の結合度も密になって行きます。そして複雑化したアプリケーションでは、「プログラムが複雑なため機能追加がしにくく、バグも発生しやすい」「機能が多く巨大なためテストに時間がかかる」「システム全体に影響する可能性があるため、気軽にデプロイできない」といった問題が発生しやすく、高速な開発の足枷となってしまいます。 その点、マイクロサービスにおいては、サービスの境界を明確することで、機能追加における影響範囲を限定し、分かりやすくなります。そのため改修の難易度は低くなり、テストも変更箇所のみとすることができます。 図5：保守性 拡張性 アプリケーションの性能に問題がある場合は、サーバのCPUやメモリ等のハードウェアの増強をするか、アプリケーションを並列稼働して分散処理を行うことで、全体の処理能力を向上させる必要があります。モノリスの場合には、一部の機能の性能に問題があったとしても、アプリケーション全体を、よりスペックの高いハードウェアに載せ替えたり、並列稼働させる必要がありました。ここには性能対策が不要な機能も含まれるため、リソースの使用効率は低くなります。 マイクロサービスでは、サービスごとに負荷分散やスケールが可能です。アプリケーション全体ではなく、負荷の大きいサービスのみをスケールさせられるという柔軟性と、負荷の低いサービスはスケールしなくてよいため、リソース最適化の容易さを兼ね備えています。 図6：拡張性 可用性 一部の機能で障害が発生した場合、モノリスではアプリケーション全体が落ちてしまい、障害の復旧まで全ての機能停止してしまいます。 マイクロサービスを適用していた場合は、特定の機能に障害が発生しても、他の機能は稼働を継続することが可能で、障害の影響を局所的に抑えることができます。そのため、アプリケーション全体の耐障害性を向上させることができます。 図7：可用性 再利用性 新しい業務システムを作る際に、既存のアプリケーションの中の一部機能と同じものが必要になることがあります。既存のアプリケーションの機能を流用し、足りない機能を追加してリリース・・・としたいところですが、新しい業務システムには不要な機能も、既存のアプリケーションには含まれていることがあります。そのまま既存のアプリケーションに機能追加を行っていくと、アプリケーションが複雑化していくことになるため、効率化のために既存のソースコードを流用し、新規のアプリケーションとして開発を始めるケースもあります。その場合は、既存の不要な機能も含めてコピーしてしまう点と、同じ機能が複数のアプリケーションに存在し、二重管理をとなる点が課題になってきます。 マイクロサービスであれば機能を分割しているため、新しいアプリケーションを作る際にも、既存の機能をそのまま流用して開発をすることが容易です。これにより、開発のボリュームが減り、ビジネスのニーズに合わせた迅速なシステム変更にも対応ができるようになります。 図8：再利用性 パフォーマンス ここまでは、従来のモノリスと比較して、マイクロサービスが優れている点を紹介してきました。しかし、もちろん良いことばかりではありません。その構造によるデメリットも存在します。 マイクロサービスでは、アプリケーションの１リクエストを完結するために、複数のサービスがAPIを用いて相互に連携します。そのため、複数回のネットワーク通信が発生することでシステムのパフォーマンスが劣化する可能性があります。また例えば、RESTなどの同期通信のみで構成した場合には、仮にどこかのサービスで何か障害が発生したとすると、そのサービスを起点に下流側の機能が全て止まってしまうことになります。そのため、処理の途中でエラーとなった際の対応などを考慮する必要があります。これに対しては、非同期通信にてサービス間の連携を行うやり方もあり、詳細については次回のブログでお話しします。 図9：パフォーマンス データ管理 マイクロサービスの設計の方針の１つに、疎結合があります。各サービス間の依存関係を疎にすることで、素早く柔軟に変更を行うことができるようになります。これは、アプリケーションだけでなくデータベースも含まれます。ビジネス側の要望により、データベースのスキーマ変更が必要になるケースもあるでしょう。その際の設計変更要求に対して柔軟な対応ができるように、サービスとデータベースの関係を１：１とするモデルが推奨されます。しかしその一方で、サービスをまたぐような処理をする場合に、データの一貫性を保証することが難しくなってしまうという課題があります。 図10：サービスとデータベースは１：１ マイクロサービスにおいて、複数のデータベース間の同期については、「結果整合性」が許容できないか、ということも考慮に入れて検討していくことが重要です。IT側の人間だけでは判断が難しいので、ビジネス側のエキスパートとよく業務要件を確認し、データベース間の同期／整合性の設計を進めると良いでしょう。 運用・監視 マイクロサービス化が進むにつれて、アプリケーションは小さな単位に分割をされていきます。大規模なシステムの場合には、その数が数百〜数千に及ぶこともあり、手動によるサービスの管理は現実的に不可能でしょう。またマイクロサービスの各サービスは、コンテナを利用してデプロイするのが一般的となっていますが、コンテナの管理もサービス同様に煩雑となりがちです。そのため、コンテナのオーケストレーションシステムとして、デファクトスタンダードとなっている Kubernetes や、サービスメッシュの導入を併せて検討するのがお勧めです。 マイクロサービスはどのようなシステムに適用すべきか？ ここまで見てきたように、マイクロサービスには様々なメリットがあります。しかし、すべてのシステムをマイクロサービス化すべきかと言うと、必ずしもそうではありません。「Microservices」の共同執筆者であるMartin Fowlerは、「 MicroservicePremium 」において、「モノリスでは管理しきれないほど複雑なシステムでない場合は、マイクロサービスを検討する必要はない」と述べています。 図11：MicroservicePremium とはいえ、従来のモノリスでは開発・運用ともに負荷が大きく、遠からずスケールの限界が見えてくるのも事実です。大規模なシステムであれば、どこかのタイミングでアーキテクチャを見直して、マイクロサービスに移行するという判断を下す必要は出てくるのではないでしょうか。 次回 次回については、マイクロサービスの課題として挙げた、パフォーマンスやデータ管理の面で有効なデザインパターンについて、ご紹介して行きたいと思います。

Red Hat のソリューションアーキテクトをしている瀬戸です。 JBoss EAP 6.xのELS-1 が2022年6月30日に終了します。 今後はELS-2となり、ELS-2は現在の製品リリースへの移行に関するアドバイスとガイダンス、問題の評価と回避策を含む限定的な継続的技術サポートのみが提供されるようになります。 バグフィックスやセキュリティフィックス、ハードウェアイネーブルメント、根本原因分析（可能な回避策を決定する以外）はこのフェーズでは提供されず、サポートは既存のインストールのみに限定されます。 昨年末に Log4Shell が発見されて猛威を振るいました。そのあとも Spring4Shell 等の大きなセキュリティ脆弱性が発見されて問題となっていました。 今後はこのような致命的な問題が発生しても修正版の提供はなくなります。 そのため、可能な限り早くEAP 7に移行することが推奨されます。 発見されてから移行を考えればいいでしょう、と考える人もたくさんいると思います。 YAGNI原則(You Ain't Gonna Need It)もあり、必要になった時に初めて行うというのは良い考えだとされています。 しかしながらバージョンアップには時間がかかります。 Log4Shellでは脆弱性が知れ渡ってから数日以内にPoC(脆弱性の検証用サンプルプログラム)がgithubで公開され、数日後には多くの攻撃が発生していました。 数日間での移行は可能でしょうか？ 不可能であると断言はできませんが非常に難しい作業となります。 そのため可能な限り早くから計画を立てて対応する必要があります。 ただ、EAP 6からEAP 7へ移行をしようと思っても何から手を付けてよいのかわからないという人もたくさんいると思います。 この記事では移行内容の見積もりや実際に移行するときに使える「MTA(Migration Toolkit for Applications)」と「JBoss サーバー移行ツール(JBoss Server Migration Tool)」の二つを紹介します。 MTA(Migration Toolkit for Applications)はアプリケーションの移行に、サーバー移行ツール(JBoss Server Migration Tool)はEAP本体の設定の移行に使用します。 [NOTE] このツールを使うことで移行が容易になりますが、このツールだけでは移行は完了しません。 OS周りの設定やアプリに含まれる個別の業務ロジック等の変更も必要になる可能性があります。 必要に応じてRed Hatのサポートへの質問や、Red Hatにコンサルティングのご依頼をください。 MTA(Migration Toolkit for Applications) MTAはJavaアプリケーションの移行とモダナイゼーションを簡単に行えるようにする静的解析ツールです。 MTAには最初からEAP 6からEAP 7の非互換の機能一覧が搭載されており、Webアプリケーションを解析することができます。 warファイルやearファイルの場合は逆コンパイルをして、ソースコードの場合はそのまま静的解析を行うことができます。 バイナリでもソースコードでも解析できるのが大きな特徴になっています。 EAP6から移行したいウェブアプリケーションがある人は手元にそのwarファイル(もしくはearファイル)を準備してください。簡単に解析できます。 MTA(Migration Toolkit for Applications)の入手 MTAは以下のページからダウンロードすることができます。※要Red Hatアカウント ttps://developers.redhat.com/products/mta/download ※ 2022年11月にWebConsole版はMTR(Migration Toolkit for Runtimes)という名前に変更され、ダウンロードできるページが変わりました。 こちらのの記事についてはMTR1.0についても有効です。実行ファイルがrun_windup.batもしくはrun_windup.shに変更されているのだけご注意ください。 MTRは次のページからダウンロードしてください。 developers.redhat.com WebConsole版、CLI版、IDEプラグイン版がありますが、今回はオプションを知らなくてもなんとなくで使えるWebConsole版を使用します。 ページを下に移動して、All DownloadsからWeb Console版をダウンロードします。 ダウンロードしたら適切な場所に解凍します。 前提のJDKについて 本記事では、MTAのバージョン5.3で解析を行います。 前提のJDKは、以下となります。 OpenJDK 11 Oracle JDK 11 https://access.redhat.com/documentation/en-us/migration_toolkit_for_applications/5.3/html/introduction_to_the_migration_toolkit_for_applications/prerequisites 注意事項：Windows版のOracle JDK 11 "11.0.15"では、WindowsでのFileIOの修正でWebコンソールが起動しない不具合がありますので、 不具合の修正が入っている "11.0.15.1"以降をご利用ください。 MTA(Migration Toolkit for Applications)の実行 解凍先の run_mta.bat (Windowsの場合) run_mta.sh (Mac、Linuxの場合) を起動します。※ダブルクリックで大丈夫です。 起動時にログにいくつかエラーが出ますが、気にせず待つと1分後ぐらいに起動します。 http://localhost:8080/ からアクセスできますので、アクセスしてください。 起動に成功している場合は以下のような画面が表示されるはずです。 [NOTE] すでにポート8080で他のアプリが起動している場合は起動に失敗します。その場合は他のアプリを停止したうえでMTAを再起動してください。 起動したら解析するためのプロジェクトを作成します。Create Projectを押してください。 NameにEAP6to7と入れてNextを押します。(名前は自由につけてください。) ローカルファイルを指定します。Servar pathを選択して、warファイル、earファイル、もしくはソースコードのあるディレクトリを入力してください。 ディレクトリを入力した場合は、「If the directory contains Java source code or an exploded application, select the check box below」にチェックを入れてください。 入れたらNextを押します。 Select transformation targetでApplication server migration to EAP 7を選択します。選択されている場合は上部に小さく青い線が出ます。※デフォルトで選択されています。 選択したらNextを押します。 Select packagesで解析するパッケージを指定します。※自分たちで作ってるパッケージを指定します。なにを除外してよいかわからない場合はすべてを指定します。 選択したらNextを押します。 Custom rules、Custom labelsは何も入れずにNextを押します。 OptionsではSourceにeap6を入力して、Nextを押します。 少し時間がかかりますが、今まで入力した内容が表示されます。 ざっと確認してSave and runを押してください。 すると、解析が開始されます。アプリケーションの大きさにもよりますが、数十秒から数十分程度かかるのでしばらくお待ちください。 MTA(Migration Toolkit for Applications)の解析結果を確認する 解析が終わると、Compleredと表示されます。Actionsにあるreportsボタンを押します。 どのアプリケーションが解析されたのかが表示されます。 解析されたアプリケーションをクリックしてDashboardを参照してください。 Dashboardには今回の解析結果のサマリーが表示されます。 ここで重要なのはIncidents(問題)の数とTotal Story Pointsです。Story Pointsは問題解決の難易度を示し、修正にどれくらいの工数がかかるのかを示します。 ただ、実際にどれくらい工数がかかるのかは作業する人の熟練度によりますので、目安であることには注意をしてください。 Issuesを参照してください。 Issuesには実際に見つかった問題が表示されます。Issue by Categoryをクリックすることで、問題の詳細が表示されます。黄色い欄には修正方法へのリンクが表示されています。実際に修正するときはリンク先を確認しながら修正を行ってください。 [NOTE] 修正方法へのリンクですが、私が試したところEAP 7.0の英語版のドキュメントにリンクされていました。 現在の最新版であるEAP 7.4の日本語版のドキュメント(Red Hat JBoss Enterprise Application Platform7.4 移行ガイド )もありますので、必要に応じてそちらを参照するようにしてください。 参考資料に日本語版へのリンクがあります。 MTAを使用することでアプリケーションの修正箇所を見つけることができます。今回のブログを書くにあたり、Red Hatがgithubで公開しているEAP6.4用のサンプルコードを解析にかけてみました。 ほとんどのコードがJava EE準拠であるため、ほとんど修正が必要なものは見つかりませんでした。 EAPの移行ガイドには多くの注意点が記載されていますが、ほとんどの注意点については遭遇するのはまれです。 見ればわかるものについてはMTAを使用することで要・不要を判断することができますので、ぜひ一度解析してみてください。 JBoss サーバー移行ツール(JBoss Server Migration Tool) JBoss サーバー移行ツールはEAPの設定を移行するためのツールです。EAP6.4以上からEAP 7.4(=最新版)への移行をサポートしています。 EAP6.4未満の場合は一度6.4に手動でアップデートする必要がありますのでご注意ください。 JBoss サーバー移行ツール(JBoss Server Migration Tool)の入手 EAP 7に入っています。使用するためにはEAP 6とEAP 7を同時にインストールする必要があります。※同時に起動させる必要はありません。 rpmによるインストール、zipファイルの解凍、インストーラーの起動等でEAP 7をインストールしてください。 standalone.xml等のEAP本体で使用する設定ファイルを移行することができます。 JBoss サーバー移行ツール(JBoss Server Migration Tool)の実行 EAP 7のインストール先のbin/に入っている jboss-server-migration.bat (Windowsの場合) jboss-server-migration.sh (Mac、Linuxの場合) をEAP 6のディレクトリを引数として起動します。 ex. jboss-server-migration.sh --source $EAP_6_HOME jboss-server-migration.bat--source C:\Apps\jboss-eap-6.4 起動するとどの設定ファイルを移行するかを聞かれますので、今回はstandalone.xmlのみを移行します。yes/noの選択肢がいくつか表示されますので、実際に使用されている設定ファイルを移行するようにしてください。 C:\Apps\EAP-7.4.0\bin>jboss-server-migration.bat --source C:\Apps\jboss-eap-6.4 ---------------------------------------------------------- ---- JBoss Server Migration Tool ----------------------- ---------------------------------------------------------- Retrieving servers... 18:18:19,795 INFO [logger] SOURCE server name: EAP, version: 6.4.0.GA. 18:18:19,820 INFO [logger] TARGET server name: JBoss EAP, version: 7.4.0.GA. ---------------------------------------------------------- ---------------------------------------------------------- Server migration starting... 18:18:19,906 INFO [ServerMigrationTask#1:1] --- Migrating modules requested by environment... 18:18:19,908 INFO [ServerMigrationTask#1:1] No modules to migrate. Migrate the source's standalone server? yes/no? yes 18:18:22,388 INFO [ServerMigrationTask#1:2] --- Migrating standalone server... 18:18:22,403 INFO [ServerMigrationTask#1:2:3] Source's standalone configurations found: [standalone-full-ha.xml, standalone-full.xml, standalone-ha.xml, standalone-osgi.xml, standalone.xml] Migrate all configurations? yes/no? no Migrate configuration standalone-full-ha.xml ? yes/no? no Migrate configuration standalone-full.xml ? yes/no? no Migrate configuration standalone-ha.xml ? yes/no? no Migrate configuration standalone-osgi.xml ? yes/no? no Migrate configuration standalone.xml ? yes/no? yes 18:18:35,993 INFO [ServerMigrationTask#1:2:3:1] Migrating standalone configuration standalone.xml... 18:18:36,040 INFO [ServerMigrationTask#1:2:3:1:1] Unsupported extensions removed: [org.jboss.as.threads] 18:18:36,060 INFO [ServerMigrationTask#1:2:3:1:2] Unsupported subsystems removed: [urn:jboss:domain:threads:1.1] 18:18:38,163 INFO [security] ELY00001: WildFly Elytron version 1.15.3.Final-redhat-00001 18:18:38,367 INFO [ServerMigrationTask#1:2:3:1:7] Subsystem elytron added. 18:18:38,555 INFO [ServerMigrationTask#1:2:3:1:8] Subsystem web migrated. 18:18:38,746 INFO [ServerMigrationTask#1:2:3:1:9] Subsystem undertow updated. 18:18:38,907 INFO [ServerMigrationTask#1:2:3:1:12] Subsystem infinispan updated. 18:18:39,014 INFO [ServerMigrationTask#1:2:3:1:13] Subsystem ee updated. 18:18:39,046 INFO [ServerMigrationTask#1:2:3:1:14] Subsystem remoting updated. 18:18:39,166 INFO [ServerMigrationTask#1:2:3:1:15] Subsystem ejb3 updated. 18:18:39,241 INFO [ServerMigrationTask#1:2:3:1:17] Subsystem batch-jberet added. 18:18:39,288 INFO [ServerMigrationTask#1:2:3:1:18] Subsystem core-management added. 18:18:39,328 INFO [ServerMigrationTask#1:2:3:1:19] Subsystem request-controller added. 18:18:39,384 INFO [ServerMigrationTask#1:2:3:1:20] Subsystem security-manager added. 18:18:39,436 INFO [ServerMigrationTask#1:2:3:1:21] Subsystem singleton added. 18:18:39,482 INFO [ServerMigrationTask#1:2:3:1:22] Subsystem discovery added. 18:18:39,522 INFO [ServerMigrationTask#1:2:3:1:23] Subsystem ee-security added. 18:18:39,565 INFO [ServerMigrationTask#1:2:3:1:24] Subsystem health added. 18:18:39,608 INFO [ServerMigrationTask#1:2:3:1:25] Subsystem metrics added. 18:18:39,651 INFO [ServerMigrationTask#1:2:3:1:26] HTTP Upgrade Management configured. 18:18:39,712 INFO [ServerMigrationTask#1:2:3:1:28] Socket binding's port expressions added. 18:18:39,734 INFO [ServerMigrationTask#1:2:3:1:30] Security realms migrated. 18:18:39,759 INFO [ServerMigrationTask#1:2:3:1:31] Security realm ApplicationRealm SSL server identity configured. Migrate the source's managed domain? yes/no? no Server migration done. 18:18:42,217 INFO [logger] -------------------------------------------------------------- Task Summary -------------------------------------------------------------- server .............................................. SUCCESS standalone ......................................... SUCCESS standalone-configurations ......................... SUCCESS standalone-configuration(source=standalone.xml) .. SUCCESS -------------------------------------------------------------- Migration Result: SUCCESS -------------------------------------------------------------- [NOTE] 今回は単独で動いているEAPを前提としてstandalone.xmlを対応しました。 ドメインモードで動いているEAPのクラスタに対しても実行できますが、ゼロダウンタイムで移行するためには移行の順番に気を付ける必要があります。 詳細については参考資料の JBoss Server Migration Tool の実行 の 6.2. JBoss EAP 6.4 管理対象ドメインの JBoss EAP 7.4 への移行 を参照してください。 JBoss サーバー移行ツールを使用することでサーバーの設定を自動的に移行することができます。すべての場合に設定をそのまま移行できるわけではありませんが、多数の設定については移行することができます。移行できなかったものについては個別で確認をする必要がありますが少量ですので解消がしやすいと思います。 まとめ EAP 6.XのELS-1 が2022年6月30日に終了します。 今までは重要なバグが発生していた時はパッチが提供されていましたが今後はパッチが提供されなくなります。 日々セキュリティインシデントは発生しており、修正されなくなったEAP6.Xが狙われる可能性もあります。 移行は難しい作業ですがMTA(Migration Toolkit for Applications)とJBoss サーバー移行ツール(JBoss Server Migration Tool)を利用することで思ってたよりは簡単にできるかもしれないのでぜひお試しください。 ただし、これだけで必ず移行ができるというものではありません。 どうしても難しい場合はRed Hatのサポートやコンサルティングサービスを利用することもできます。そちらもご検討ください。 参考資料 Red Hat Application Services Product Update and Support Policy https://access.redhat.com/support/policy/updates/jboss_notes MTA ダウンロード(要Red Hatアカウント) https://developers.redhat.com/products/mta/download Download Red Hat JBoss Enterprise Application Platform https://developers.redhat.com/products/eap/download Migration Toolkit for Applications の概要 https://access.redhat.com/documentation/ja-jp/migration_toolkit_for_applications/5.3/html/introduction_to_the_migration_toolkit_for_applications/index MTA Visual Studio Code 拡張機能ガイド(MTAをVisual Studio Codeで使用したい場合) https://access.redhat.com/documentation/ja-jp/migration_toolkit_for_applications/5.2/html-single/visual_studio_code_extension_guide/index Red Hat JBoss Enterprise Application Platform7.4 移行ガイド https://access.redhat.com/documentation/ja-jp/red_hat_jboss_enterprise_application_platform/7.4/html-single/migration_guide/index Red Hat JBoss Enterprise Application Platform7.4 インストールガイド https://access.redhat.com/documentation/ja-jp/red_hat_jboss_enterprise_application_platform/7.4/html-single/installation_guide/index JBoss サーバー移行ツールの使用 https://access.redhat.com/documentation/ja-jp/red_hat_jboss_enterprise_application_platform/7.4/html-single/using_the_jboss_server_migration_tool/index EAP 6.4のサンプルソースコード https://github.com/jboss-developer/jboss-eap-quickstarts/tree/6.4.x

Red HatでOpenShiftのサポートをしている id:nekop です。 インターネット非接続環境でOpenShiftを利用する場合、ミラーレジストリを作成して非接続環境でイメージをホストする必要があります。このエントリでは、実際にミラーレジストリをセットアップし、そのミラーを使ったインストールを行ないます。 このエントリではAWS上でクラスタを構成しますが、インターネット非接続環境として構成することはせず、インターネット接続環境です。ただし利用する認証情報、pull secretはミラーレジストリのものに限定しているので、本来のquay.ioに接続できてもイメージをpullすることはできない構成としています。 また、非接続環境のシナリオではイメージ群を一旦ファイルに保存、非接続環境へ持ち込んでファイルからミラーレジストリ構築、という方法をとる場合もありますが、手順はそれほど変わらないのでこのエントリでは扱いません。このエントリではファイルを経由せず、ミラーレジストリへ直接イメージをミラーします。 OpenShift 4.10.12を利用しますが、OpenShift 4.10のTechnology Preview新機能である oc-mirror plugin は利用していません。4.6+で利用可能な現行の方法となります。 ミラーレジストリはOpenShiftのオマケで提供されている Mirror registry for Red Hat OpenShift というスタンドアロンのQuayベースのレジストリを利用します。ミラー用途以外、たとえばユーザのイメージの保存には利用できないことに注意してください。 大まかな流れ ミラーレジストリホストの準備 ミラーレジストリのインストール ミラー用pull secret作成 OpenShiftのイメージのミラー Operatorのミラー エントリ中ではディレクトリを整理したりする操作をはぶいています。雑多なディレクトリおよびファイル群ができるので、実際の運用に向けてはきちんと整理して実行していくほうが良いです。 Mirror registryホストの準備 以下の設定でインスタンスを作成します。Mirror registry for Red Hat OpenShiftのインストールにはpodmanを必要とするのでRHELを利用します。Amazon Linuxにはpodmanパッケージが無いので注意してください。 ミラーレジストリは8443ポートを利用するので、追加で許可します。 RHEL 8.5 m5.large (2 vCPU, 8GB memory) 500GB gp3 disk Security GroupでTCP 8443をallow ミラーレジストリのインストール 事前に pull-secret.txt を以下からダウンロードしてください。 pull-secret.txt https://console.redhat.com/openshift/install/pull-secret ファイルを転送してpodmanをインストールし、ミラーレジストリをインストールします。 rsync -e "ssh -i $AWS_SSH_PRIVATE_KEY" pull-secret.txt ec2-user@ec2-public-ip.ap-northeast-1.compute.amazonaws.com: ssh -i $AWS_SSH_PRIVATE_KEY ec2-user@ec2-public-ip.ap-northeast-1.compute.amazonaws.com sudo dnf update -y sudo dnf install podman -y curl -LO https://developers.redhat.com/content-gateway/file/pub/openshift-v4/clients/mirror-registry/1.1.0/mirror-registry.tar.gz tar xf mirror-registry.tar.gz sudo ./mirror-registry install --quayHostname ec2-public-ip.ap-northeast-1.compute.amazonaws.com --quayRoot /var/lib/quay ミラーレジストリのinitユーザのパスワードはmirror-registry installの出力に表示されるのみとなります。ファイル上に平文保存などはされないため確実に保存してください。 ミラー用pull secret作成 インストール後に生成されるミラーレジストリのCA証明書はそのままOSに登録し、ミラーレジストリにアクセスするためのmirror-pull-secret.txtを生成します。 sudo cp /var/lib/quay/quay-rootCA/rootCA.pem /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust podman login \ --authfile ./mirror-pull-secret.txt \ -u init \ -p PASSWORD \ ec2-public-ip.ap-northeast-1.compute.amazonaws.com:8443 ミラー処理はミラー元レジストリのpull-secret.txtとミラーレジストリのmirror-pull-secret.txtの両方を必要とするので、連結してデフォルトのauthファイル位置 ~/.config/containers/auth.json へ配置します。古いツールが ~/.docker/config.json を参照するのでリンクも作成します。JSON形式なので単純連結はできず、少し編集する必要があります。 mkdir -p ~/.config/containers/ ~/.docker/ cat mirror-pull-secret.txt pull-secret.txt > ~/.config/containers/auth.json ln -s ~/.config/containers/auth.json ./.docker/config.json vi ~/.config/containers/auth.json ファイル編集してミラーレジストリのエントリ末尾にカンマ挿入、 "cloud.openshift.com" 直前までを削除すれば良いです。 { "auths": { "ec2-public-ip.ap-northeast-1.compute.amazonaws.com:8443": { "auth": "xxx" }, "cloud.openshift.com":{... OpenShiftのイメージのミラー OpenShiftのイメージのミラーにはocコマンド、Operatorのミラーでopmコマンドを利用しますので、まずはそれらを配置します。 curl -LO https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/fast-4.10/openshift-client-linux-4.10.12.tar.gz tar xf openshift-client-linux-*.tar.gz oc sudo cp oc /usr/bin/ https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/fast-4.10/opm-linux-4.10.12.tar.gz tar xf opm-linux-*.tar.gz opm sudo cp opm /usr/bin/ マニュアル記載のミラー手順 を実行し、openshift-installバイナリを生成します。 export OCP_RELEASE=4.10.12 export LOCAL_REGISTRY=ec2-public-ip.ap-northeast-1.compute.amazonaws.com:8443 export LOCAL_REPOSITORY='ocp4/openshift4' export PRODUCT_REPO='openshift-release-dev' export LOCAL_SECRET_JSON='/home/ec2-user/.config/containers/auth.json' export RELEASE_NAME="ocp-release" export ARCHITECTURE=x86_64 oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}" この環境では6分ほどで終了しました。 生成されたopenshift-installバイナリはミラーレジストリ上のイメージが指定されています。 $ ./openshift-install version ./openshift-install 4.10.12 built from commit 1e29cdacf65d54a7fad50683daff9e3083013ab1 release image ec2-public-ip.ap-northeast-1.compute.amazonaws.com:8443/ocp4/openshift4@sha256:f77f4f75c1e1a4ddd0a0355f298a834db3473fd9ca473235013e9419d1df16db release architecture amd64 アップデートする場合も上記と同じ手順でアップデート先のバージョンをミラーして、 oc adm upgrade --to-image=... 指定でミラー上のリリースイメージを指定します。 Operatorのミラー Operatorは膨大な量が提供されており、通常はopm index pruneコマンドを利用して標準のindexイメージから必要なOperatorに絞ったindexイメージを作ってミラーします。今回はCluster Logging Operator, Elasticsearch Operator, Local Storage Operatorのみミラーします。 Sqlite-based catalogs are deprecated. という警告が表示されますが無視してください。 File-basedカタログ への移行フェーズであるため表示される警告ですが、今時点では無視して構いません。 opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.10 \ -p cluster-logging,elasticsearch-operator,local-storage-operator \ -t ${LOCAL_REGISTRY}/mirror/mirror-operator-index:v4.10 podman push ${LOCAL_REGISTRY}/mirror/mirror-operator-index:v4.10 oc adm catalog mirror \ -a ${LOCAL_SECRET_JSON} \ ${LOCAL_REGISTRY}/mirror/mirror-operator-index:v4.10 \ ${LOCAL_REGISTRY} \ --index-filter-by-os=linux/amd64 この環境では8分ほどで終了しました。 Operatorを全てミラーする場合は大量のディスクを消費するので注意してください。今回利用しているミラーレジストリホストではこの時点で50GB程度のディスク消費です。 Operatorのアップデートする場合も上記と同じ手順でindexイメージ再作成、ミラーを実行します。 OpenShiftのインストール ミラーレジストリを利用したインストールの install-config.yaml では、通常のOpenShiftのインストール項目の他に、以下の3つの項目の追加、変更が必要となります。ミラーレジストリを利用する指示となるimageContentSources, additionalTrustBundleにミラーレジストリのCA証明書、pullSecretにミラーレジストリのpull secret指定が必要になります。 imageContentSources oc adm release mirror の出力 additionalTrustBundle /var/lib/quay/quay-rootCA/rootCA.pem の内容 pullSecret mirror-pull-secret.txt の内容 apiVersion: v1 (省略) imageContentSources: - mirrors: - ec2-public-ip.ap-northeast-1.compute.amazonaws.com:8443/ocp4/openshift4 source: quay.io/openshift-release-dev/ocp-release - mirrors: - ec2-public-ip.ap-northeast-1.compute.amazonaws.com:8443/ocp4/openshift4 source: quay.io/openshift-release-dev/ocp-v4.0-art-dev additionalTrustBundle: | -----BEGIN CERTIFICATE----- xxx -----END CERTIFICATE----- pullSecret: '{"auths": {"ec2-public-ip.ap-northeast-1.compute.amazonaws.com:8443": {"auth": "xxx"}}}' install-config.yaml が用意できたら実際にインストールを実行します。 openshift-install create cluster これでミラーレジストリのみを利用したOpenShiftのインストールができます。 ミラーレジストリのOperatorを利用 非接続環境およびミラーレジストリのみ接続可能な構成では、OpenShiftインストール後にopenshift-marketplace内に作成される標準のOperator indexイメージを利用するPod群がImagePullBackoffとなります。これらは quay.io を直接参照する設定となっているので期待通りの動作となります。 マニュアル通り、disableAllDefaultSourcesを設定して標準のOperator indexイメージの利用を無効化し、これらのPodが作成されないようにします。 oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]' 次にミラーしたOperatorを利用する設定です。Operatorのミラー実行時にミラーしたOperator indexイメージを指定するCatalogSource、およびOperator関連イメージにミラーを参照する設定であるimageContentSourcePolicyが生成されているので、それを作成します。 oc create -f manifests-mirror-operator-index-xxx/imageContentSourcePolicy.yaml oc create -f manifests-mirror-operator-index-xxx/catalogSource.yaml これでミラーしたOperatorが利用可能になり、Operatorがインストールできるようになります。 Operator一覧 インストールされたOperator一覧 マイナーバージョンアップデートの際にはCatalogSourceのimage行を書き換え、たとえば mirror-operator-index:v4.10 を mirror-operator-index:v4.11 に更新することでアップデートが可能になります。別のCatalogSourceとして作成してしまうと同じパッケージのアップグレードとはみなされなくなりますので注意してください。

レッドハットの杉村です。Ansible のテクニカルサポートをしています。毎月1つは何か書くことを目標にしています。3月分は3月38日(4月7日ですが)になってしまいましたが、4月は何とか滑り込みできました。 前回は変数の基本的なところを紹介しました。 rheb.hatenablog.com 今回はその変数の受け渡しについて紹介します。変数をプレイブックの外から与えられるようにすることで、より再利用性の高い自動化が実現できるようになります。 タスク間でやりとりする変数 task1の処理結果をtask2で使いたいというときにどう渡せるかを見ていきます。 タスクごとに定義できる register を使って、そのタスクの処理結果を変数に格納することができます。インデントに注意してください。 name: や command: (モジュール定義) と並列に並べます。 --- - hosts: all gather_facts: true tasks: - name: task1 command: cmd: "hostnamectl status" register: result - name: task2 debug: msg: "{{ result }}" 実行結果はこのようになります。 $ ansible-playbook tasks.yml -i 192.168.0.xxx, -k SSH password: PLAY [all] ************************************************************************************************************************************************************************ TASK [Gathering Facts] ************************************************************************************************************************************************************ ok: [192.168.0.xxx] TASK [task1] ********************************************************************************************************************************************************************** changed: [192.168.0.xxx] TASK [task2] ********************************************************************************************************************************************************************** ok: [192.168.0.xxx] => { "msg": { "changed": true, "cmd": [ "hostnamectl", "status" ], "delta": "0:00:00.148812", "end": "2022-04-20 13:53:49.593813", "failed": false, "msg": "", "rc": 0, "start": "2022-04-20 13:53:49.445001", "stderr": "", "stderr_lines": [], "stdout": " Static hostname: xxxxxxxx\n Icon name: computer-vm\n Chassis: vm\n Machine ID: 428067dxxxxxxxxxxxxxxxxxxxxxx\n Boot ID: 5a15d0a8xxxxxxxxxxxxxxxxxxxx\n Virtualization: vmware\n Operating System: Red Hat Enterprise Linux 8.5 (Ootpa)\n CPE OS Name: cpe:/o:redhat:enterprise_linux:8::baseos\n Kernel: Linux 4.18.0-348.el8.x86_64\n Architecture: x86-64", "stdout_lines": [ " Static hostname: xxxxxxxx", " Icon name: computer-vm", " Chassis: vm", " Machine ID: 428067dxxxxxxxxxxxxxxxxxxxxxx", " Boot ID: 5a15d0a8xxxxxxxxxxxxxxxxxxxx", " Virtualization: vmware", " Operating System: Red Hat Enterprise Linux 8.5 (Ootpa)", " CPE OS Name: cpe:/o:redhat:enterprise_linux:8::baseos", " Kernel: Linux 4.18.0-348.el8.x86_64", " Architecture: x86-64" ] } } PLAY RECAP ************************************************************************************************************************************************************************ 192.168.0.xxx : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 コマンドラインから渡す変数 前回は変数をプレイブックの中に定義したり、外のファイルに書いて vars_files: で指定したりという方法で利用するものを紹介しました。 コマンドラインから渡すこともできます。 --- - hosts: localhost connection: local gather_facts: false tasks: - name: debug debug: msg: "Good morning {{ message }} !" 例えばこのようなプレイブックでは、変数 message が定義されていないときにはこのように fatal エラーになります。 $ ansible-playbook extra.yml [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all' PLAY [localhost] ****************************************************************************************************************************************************************** TASK [debug] ********************************************************************************************************************************************************************** fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'message' is undefined\n\nThe error appears to be in '/home/sugimura/blog/extra.yml': line 7, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n tasks:\n - name: debug\n ^ here\n"} PLAY RECAP ************************************************************************************************************************************************************************ localhost : ok=0 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 --extra-vars オプションを使って、変数定義を渡すことができます。短縮形 -e も使えます。 $ ansible-playbook extra.yml -e message=ansible [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all' PLAY [localhost] ****************************************************************************************************************************************************************** TASK [debug] ********************************************************************************************************************************************************************** ok: [localhost] => { "msg": "Good morning ansible !" } PLAY RECAP ************************************************************************************************************************************************************************ localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 このように変数が複数あるときや、ディクショナリやリストを渡したいときを見てみます。 --- - hosts: localhost connection: local gather_facts: false tasks: - name: debug debug: msg: "Good morning {{ item }} !" loop: "{{ messagelist }}" この message にリストを渡したいとすると、コマンドラインから [ ] の形で渡す場合はこのようになります。 $ ansible-playbook extra.yml -e messagelist="['ansible','automation','platform']" [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all' PLAY [localhost] ****************************************************************************************************************************************************************** TASK [debug] ********************************************************************************************************************************************************************** ok: [localhost] => (item=ansible) => { "msg": "Good morning ansible !" } ok: [localhost] => (item=automation) => { "msg": "Good morning automation !" } ok: [localhost] => (item=platform) => { "msg": "Good morning platform !" } PLAY RECAP ************************************************************************************************************************************************************************ localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 extra_vars はファイルで渡すこともできます。ファイルに YAML でこのように書いて、@ファイル名 で渡します。もしプレイブックの中に変数がたくさんあるような場合には、この方法で渡すのが楽だと思います。将来的にロールにまとめるときも、この方式を覚えておくと便利です。 --- messagelist: - "ansible" - "automation" - "platform" $ ansible-playbook extra.yml -e @parameterlist.yml [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all' PLAY [localhost] ****************************************************************************************************************************************************************** TASK [debug] ********************************************************************************************************************************************************************** ok: [localhost] => (item=ansible) => { "msg": "Good morning ansible !" } ok: [localhost] => (item=automation) => { "msg": "Good morning automation !" } ok: [localhost] => (item=platform) => { "msg": "Good morning platform !" } PLAY RECAP ************************************************************************************************************************************************************************ localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 普段使うものでは VMware vCenter で VM を作るときに VM 名や OS テンプレートを引数で渡すときにこのようなやり方をしています。 ホスト変数とグループ変数 変数定義は上の例のようにプレイブックに一括して渡すというものもあれば、インベントリに定義するホストやグループにそれぞれ決めて渡したいということもあるかと思います。 例えばインベントリをこのように用意したとします。 [RHEL] 192.168.0.100 192.168.0.120 [Windows] 192.168.0.200 それぞれの対象について変数を定義したいことがあります。接続方式や認証情報もありますし、プレイブックを具体的に書き進めたときにはその使っているモジュールに対する変数定義も書きたいことがあります。 まずはインベントリファイルに定義することができます。これはグループに変数を定義した例です。YAML 形式に慣れていると、たまにインベントリを ini 形式で書いたときに : だったか = だったかがごちゃごちゃになりますので注意してください。 [RHEL] 192.168.0.100 192.168.0.120 [Windows] 192.168.0.200 [RHEL:vars] ansible_connection=ssh ansible_user=ansibleuser ansible_ssh_private_key_file=~/.ssh/privatekey.pem [Windows:vars] ansible_connection=winrm ansible_winrm_transport=basic ansible_winrm_server_cert_validation=ignore ansible_user=ansibleuser ansible_password=XXXXXXXX ホストに変数を定義することもできます。 [RHEL] 192.168.0.100 ansible_user=sugimura 192.168.0.120 ansible_user=ansible グループとホストの両方に定義を書いたときは、ホストに書いた方で上書きされます。実際にどう反映されているかは、 ansible-inventory コマンドで知ることができます。 [RHEL] 192.168.0.100 ansible_user=sugimura ansible_ssh_private_key_file=~/.ssh/sugimura.pem 192.168.0.120 ansible_user=ansible ansible_ssh_private_key_file=~/.ssh/ansible.pem [Windows] 192.168.0.200 [RHEL:vars] ansible_connection=ssh ansible_user=ansibleuser ansible_ssh_private_key_file=~/.ssh/privatekey.pem [Windows:vars] ansible_connection=winrm ansible_winrm_transport=basic ansible_winrm_server_cert_validation=ignore ansible_user=ansibleuser ansible_password=XXXXXXXX このようにインベントリファイルを書いたとしたとき、ansible-inventory --list で確認することができます。 $ ansible-inventory -i inventory --list { "RHEL": { "hosts": [ "192.168.0.100", "192.168.0.120" ] }, "Windows": { "hosts": [ "192.168.0.200" ] }, "_meta": { "hostvars": { "192.168.0.100": { "ansible_connection": "ssh", "ansible_ssh_private_key_file": "~/.ssh/sugimura.pem", "ansible_user": "sugimura" }, "192.168.0.120": { "ansible_connection": "ssh", "ansible_ssh_private_key_file": "~/.ssh/ansible.pem", "ansible_user": "ansible" }, "192.168.0.200": { "ansible_connection": "winrm", "ansible_password": "XXXXXXXX", "ansible_user": "ansibleuser", "ansible_winrm_server_cert_validation": "ignore", "ansible_winrm_transport": "basic" } } }, "all": { "children": [ "RHEL", "Windows", "ungrouped" ] } } インベントリファイルに書くだけでなく、命名規則に従ったディレクトリ構成を作ることで外のファイルに書いて読ませることもできます。このようにホストやグループの定義と変数定義を完全に分割することで、変更に強くすることができることもあります。 ansible-inventory -i inventory --list で得られる結果は同じですので確認してみてください。インベントリファイルは ini 形式のままにしていますが、外出しした変数定義は YAML にしてみました。読める形式であれば自動的に判別しますので好きな形式で書いてください。 $ cat inventory [RHEL] 192.168.0.100 192.168.0.120 [Windows] 192.168.0.200 $ cat group_vars/RHEL.yml --- ansible_connection: ssh ansible_user: ansibleuser ansible_ssh_private_key_file: ~/.ssh/privatekey.pem $ cat group_vars/Windows.yml --- ansible_connection: winrm ansible_winrm_transport: basic ansible_winrm_server_cert_validation: ignore ansible_user: ansibleuser ansible_password: XXXXXXXX $ cat host_vars/192.168.0.100.yml --- ansible_user: sugimura ansible_ssh_private_key_file: ~/.ssh/sugimura.pem $ cat host_vars/192.168.0.120.yml --- ansible_user: ansible ansible_ssh_private_key_file: ~/.ssh/ansible.pem もっと量が多くなってきたときには、group_vars などのディレクトリの下にさらにグループ名のディレクトリを作って読ませることもできます。詳しくはドキュメントをご覧ください。 docs.ansible.com Ansible automation controller では、Web UI から定義することができます。定義した変数はデータベースの中に保存されます。このとき、認証情報は別に定義して実行の時に差し込む形にすることをお勧めします。 終わりに Ansible での変数の扱いについて2回に分けて紹介してみました。4月ということでこれから Ansible を触っていただける方もいらっしゃると思いますし、何か役に立つところがありましたらとてもうれしいです。 この変数について書き始めたきっかけはこの先にありました。Ansible automation controller でプレイブックを実行するときにはジョブテンプレートやワークフロージョブテンプレートを使うのですが、そのジョブの間での受け渡しについて次回紹介しようと考えています。 Ansible Automation Platform の試用版はこちらをご覧ください。 www.redhat.com Happy Automation!

Red Hat のソリューションアーキテクトの暮林です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2022/5月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: TomcatからはじめるコンテナとOpenShift (その2) TomcatからはじめるコンテナとOpenShiftということで、Tomcatを題材にして、コンテナ化して、OpenShiftに持っていったら、デプロイ、tomcatの設定、NW等がどうなるか・設定どうなるなどの連載記事の第２弾となります。 qiita.com 特集2: OpenJDK Shenandoah GC 日本語情報まとめ Javaのデファクトスタンダードな実装である OpenJDK で Red Hat が主導して開発している超低遅延ガベージコレクションである Shenandoah GC について Red Hat が英語で出している情報を日本語に翻訳してまとめページを作成しました。 Shenandoah GC がどの様なもので各バージョンでどの様に改善されて言っているかを紹介しています。 OpenJDK Shenandoah GC 日本語情報まとめ - 赤帽エンジニアブログ 特集3: （初心者向け）3scale 再入門 これからAPI管理を検討している方向けに3scaleの基本的な機能紹介を行っています。直ぐに始められるSaaS版 3scaleを使いったハンズオン形式のご紹介も含めておりますので、ご興味のある方は是非トライしてみて頂けたらと思っています。 rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 RED HAT INTEGRATION 2022.Q1 AMQ STREAMS 2.1