こんにちは、ソリューションアーキテクトの蒸野（ムシノ）です。 今回は「AMQ Streams」のベースとなっている「Apache Kafka」の超概要を説明をしたいと思います。 Apache Kafka とは 2010年にLinkedInで開発され、2011年にLinkedInから公開されたオープンソースの分散メッセージングシステムです。 Apache Kafkaはストリームデータのために設計された分散システムであり、大量のログやイベントデータなどの大量のデータをハイスループット／低レイテンシで収集・配信することが目的で、スケールアウト、対障害性、分散データストリーム処理やイベントドリブンアプリケーションを可能にします。 Apache Kafka の公式ドキュメントでは次のように示されています。 Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. Apache Kafkaは、オープンソースの分散型イベントストリーミングプラットフォームであり、高性能データパイプライン、ストリーミング分析やデータ統合、ミッションクリティカルなアプリケーションのために、多くの企業で利用されているというところでしょうか。 上記の概要や文面からだけではどんな用途で使うのかいまいち分かりにくいですね。弊社では概ね次のようなユースケースで説明しています。 メッセージング 既存のメッセージングブローカではできなかったハイスループット、パーティショニングによる分散管理とレプリケーション、フォールトトレランスによる強力な耐久性を実現。 メトリクス収集 分散したアプリケーションの統計情報集約や複数のデバイスからオペレーションデータの統計情報を継続的に集約を実現する。 ストリーム処理 ストリームの処理や継続的なリアルタイムアプリケーションを実現する。 Webサイト行動追跡 リアルタイムでユーザアクティビティトラッキングを行うデータパイプラインとして実現する。 ログ集約 ログデータを集約する。ハイスループットで高い耐久性とレプリケーションによる対障害性を提供するためログの欠損を抑止。 データインテグレーション（データパイプライン） イベントやストリームデータをキャプチャし、別のデータシステムに送付するデータパープラインとしてのシステム統合に実現する。 分かりやすい具体例として こちら では下記のようなものも紹介されています。 証券取引所、銀行、保険などの金融取引をリアリアルタイムで処理するケース。 自動車、トラック、船隊、出荷を、物流や自動車業界などで、ニアリアルタイムで追跡および監視。 工場や風力発電などの IoT デバイスや他の機器から、センサーデータを継続的にキャプチャ。 小売り、ホテル、旅行業界、モバイルアプリケーションなど、顧客とのやり取りや注文を収集し、即座に対応する。 企業の様々な部門で作成されたデータを接続、利用するようなケース。 データプラットフォーム、イベント駆動アーキテクチャ、マイクロサービスの基盤として利用。 Apache Kafka の特徴 特徴として公式ドキュメントには下記のように記載されています。 HIGH THROUGHPUT Deliver messages at network limited throughput using a cluster of machines with latencies as low as 2ms. SCALABLE Scale production clusters up to a thousand brokers, trillions of messages per day, petabytes of data, hundreds of thousands of partitions. Elastically expand and contract storage and processing. PERMANENT STORAGE Store streams of data safely in a distributed, durable, fault-tolerant cluster. HIGH AVAILABILITY Stretch clusters efficiently over availability zones or connect separate clusters across geographic regions. 上記の要約、および補足するならば下記のようなことが言えるかと思います。 Kafka自身分散システムであり、高スループット／低レイテンシである 大量のメッセージを扱うことができ、高速処理、高拡張性、高可用性にデザインされている メッセージはファイルとして保存され、かつクラスタ内でデータパーティショニングとしてレプリカが作成されるためデータの損失を防げる シングルクラスタで大規模なメッセージを扱うことができダウンタイムなしでスケールすることができ、大規模なコンシューマにも対応できる Apache Kafka が生まれてくる以前の課題 ではなぜこのような特徴を持つKafkaが生まれてきたのでしょうか？Linkedinの レポート に詳細がありますが、おおよそ以下のような課題に対応したかったと記述されています。 リアルタイムログのような多くのボリュームのイベントデータを取り扱うためにハイスループットを実現したい オフラインシステムからの定期的で莫大なデータロードを可能とする大容量バックログを取り扱いたい 伝統的なメッセージングのユースケースも取り扱いつつ、大量のデータも取り扱うことができるように低レイテンシである必要がある 当然のようにフォールトトレランスに対応しメッセージのロストを無くしたい 詳細は過去の記事に整理されていますので、こちらをご覧ください。 kenta-kosugi.medium.com Apache Kafka の全体像 Kafka を説明する記事は多くありますので、ここではそれほど詳しく説明がしませんが全体像としては下記のようになっています。 Kafka は、大まかに分けると「Broker」と呼ばれるトピックを使用してメッセージを配信するための中心的コンポーネントと、「Producer」「Consumer」と呼ばれるメッセージの送受信を行うJavaベースのクライアントのコンポーネントに分かれます。また、Brokerを管理するためのJava/Scalaベースのツールとしての「管理ツール」、「Kafka Connect」と呼ばれるKafkaと他のシステム間でデータをやり取りするためのフレームワーク、データセンターをまたがって構成されたKafkaクラスタ間でトピックのデータレプリケーションするためのツールである「Mirror Maker」とKafkaクラスタのノードおよびトピック/パーティションのステータスを管理するために使用されるKafkaクラスタ管理の「Apache Zookeeper」で構成されます。 メッセージはTopicという入れ物を通じて送受信され、Topicは複数のパーティションに分散され、Brokerに分散配置されています。Brokerはストレージレイヤー含むKafkaサーバとして機能します。 複数に分散しているパーティションですが、メッセージはリーダレプリカという1つのパーティションに書き込まれます。このパーティショニングはメッセージのキーに基づいて実施され、パーティション内の順序性は維持されます。Kafkaに接続しようとする場合、「Producer API 」「Consumer API」 もしくは「Kafka Connect」を利用して接続、他システムやデータベース等と統合します。ミッションクリティカルなユースケースを実現できるように、Kafka クラスタはBrokerのいずれかに障害が発生した場合、他のBrokerのレプリカがリーダレプリカに昇格し、作業を引き継ぎ、データを失うことなく継続的な運用を保証します。 Apache Kafkaのメリット もう何度か特徴的なものは説明しているため、おおよその理解ができているとは思いますが、今一度改めてメリットを整理すると下記の様なことが言えるかと思います。 高スループット／低レイテンシである Kafkaが生まれてきた背景にあるように大量のログや大量のイベントストリームに対応できることが求められた背景を考えれば、高スループット／低レイテンシであることは必然の要件でした。Kafka自身はpub/subではありますが、メッセージングモデルと若干異なる構成を取ることや設計段階からBrokerを複数台構成することを前提としていることから、スケールアウトをしやすいものになっています。このスケールアウトのしやすさはKafkaの高速性に寄与しています。 高速にデータ送達保証が可能 メッセージングを扱う以上、メッセージをロストしたくないというのは自然な要件であり、ミッションクリティカルで利用する以上必要最低限の要件とも言えます。 Kafkaでは、送達保証レベルを複数用意し「１回は送達を試みる」「少なくとは１回は送達する」「１回だけ送達する」これを選別するオプションを提供することでデータ送達保証の現実的な落とし所を推し量ることが可能です。 任意のタイミングでメッセージを利用できる Linkedinではリアルタイムで活用するニーズの一方、一定時間でバッチ処理的に扱いたいニーズもありました。Kafkaではデータをメモリ上だけでなくディスクへ書き込むことで永続的な保存を可能にしています。それにより比較的大量のデータを保持することが可能となっています。またこれらのデータに対して、メッセージを呼び出した側はどこまで呼んだかを記憶することで任意のタイミングでメッセージを呼び出すことができます。 Kafkaを中心としたエコシステムへの拡大 KafkaのコンポーネントであるProducerとConsumerは分散構成が可能です。このkafkaとPublisherとConsumerと間を取り持つ接続用APIが重要になってきますが、このレイヤに対して「Kafka Connect」が提供されています。APIをユーザー側で開発するのは非常に手間がかかるので、豊富なAPIが提供されていることはKafkaをより活用しやすくしています。 これまでの Apache Kafka 関連記事まとめ rheb.hatenablog.com rheb.hatenablog.com kenta-kosugi.medium.com rheb.hatenablog.com kenta-kosugi.medium.com Apache Kafka に関する性能情報 LinkedIn が公表している時点（2019年）での情報でありますが下記のようなデータボリュームを扱うことができていると発表しています。 Kafka のメッセージ処理量は 7兆件 / 日 4000以上のBrokerで構成し、100以上のKafkaクラスタ 10万件以上のトピックスと700万件以上のパーティションを運用 また、国内では2020年に LINE 社が比較的大きなボリュームで利用されていると発表しており、下記のようなボリュームを公表しています。 166を超えるシステムで利用（2018年には50システムで利用し、単一クラスタとしては世界最大のスケールと発表しています） 2500億件／日（2018年時点） 1500万件／秒 1.4ペタバイト／日 サービスレベルは99.999（最も遅いレイテンシでも50ミリ秒） AMQ Streams (Apache Kafka) に寄せられる代表的なQA 最後にAMQ Streams (Apache Kafka) でよく聞かれる質問について回答して締めくくろうかと思います。 パーティション／レプリケーションを複数持つメリットは？ パーティションを複数持つことにより冗長化ができ、高可用性が実現できることがメリットです。また、レプリケーションはパーティション単位で行われるため、レプリケーション対象のデータ量を小さくするという効果もあります。ケースバイケースですが、典型的にはトピック作成時にブローカー数の10倍程度のパーティション数を設定しておくことを推奨しています。これは将来スケールアウト等によるブローカー数の変更が発生しても偏りが起きにくくするためのプラクティスです。 ブローカに障害が発生した場合復旧手順の概要を教えてください Kafkaブローカーは3台以上の物理サーバ上で内部に保存するデータをコピー（レプリカ）して冗長化を行います。万が一障害が発生した場合でも、残りのサーバで縮退して動作の継続が可能です。そのため、手動での切り離し作業は不要です。復旧手順もシンプルで、障害が発生したブローカーを再度起動するないしはブローカーを追加するのみです。また、OpenShift上でRed Hat IntegrationないしRed Hat Application Foundationsに含まれるAMQ Streams(エンタープライズ版Kafka)をご利用いただく場合には、ブローカー障害の検知・復旧や、ブローカー数の変更はOperatorによって自動化されます。 ブローカの構成数を稼働中に増やしたり減らす事は可能か？ 可能です。ただし削除されたノードのパーティションのリバランスは自動的に行われないため、kafka-reassign-partitions.shスクリプトを使用して手動で行う必要があります。 https://kafka.apache.org/documentation/#basic_ops_cluster_expansion メッセージの削除やコンパクションにおけるオーバーヘッドは存在するか？ メッセージの削除に伴うオーバーヘッドはありません。古いメッセージブロックを記録したファイルを削除するのみであるためです。 KafkaをKey Value Storeとして利用する場合には、コンパクション実行時にオーバーヘッドがありますが、このような用法はKafkaのメインユースケースではないため、実用上問題になることはあまりません。 Kafkaブローカーのオートスケーリングに対応しているか？ Kafkaアーキテクチャは自動スケーリングには適していません。Kafkaのクラスタをスケーリングするには、膨大な量のデータを別のBrokerに移行する必要があります。接続されているコンシューマーとプロデューサーのパフォーマンスに影響を与えない方法でこれを行うには、限られた速度でデータを移動させる必要があり、クラスタをスケールアップするのに数日かかってしまうケースが多くあり現実的ではありません。Kafkaのスケーリングには、長期的なメトリクスに基づく必要があり、これは運用者の複合的な判断に委ねることを推奨しています。 最後に いかがでしたでしょうか？ 今回は「AMQ Streams」のベースとなっている「Apache Kafka」の超概要として、特徴やメリット、生まれてきた背景、または、よく質問されるケースなどを取り上げさせていただきました。 参照リンク https://access.redhat.com/documentation/ja-jp/red_hat_amq/2021.q4/html/introducing_red_hat_amq_7/index https://kenta-kosugi.medium.com/apache-kafka-%E3%81%8C%E7%94%9F%E3%81%BE%E3%82%8C%E3%81%9F%E7%90%86%E7%94%B1-2a6f022b2935 https://rheb.hatenablog.com/entry/2021/09/17/Red_Hat%E3%81%AEManaged_Kafka%E3%81%ABQuarkus%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A7%E6%8E%A5%E7%B6%9A%E3%81%97%E3%81%A6%E3%81%BF%E3%82%88%E3%81%86%EF%BC%81 https://rheb.hatenablog.com/entry/2021/07/20/Red_Hat%E3%81%AB%E3%82%88%E3%82%8BManaged_Kafka%2C_RHOSAK%E3%81%AE%E3%83%88%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%AB%E3%82%92%E8%A9%A6%E3%81%97%E3%81%A6%E3%81%BF%E3%82%8B%EF%BC%81 https://kenta-kosugi.medium.com/openshift-amq-streams-apache-kafka-quarkus-%E3%81%A7%E5%AE%9F%E7%8F%BE%E3%81%99%E3%82%8B%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3-17481f0dd63d https://rheb.hatenablog.com/entry/2020/07/06/Apache_Kafka_on_K8s%28Strimzi%29_%E3%82%92%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B_Cruise_Control https://kenta-kosugi.medium.com/kafka-mirrormaker-2-%E3%81%A8-kafka-connect-92930a769e84 https://logmi.jp/tech/articles/325945 https://drive.google.com/viewerng/viewer?url=http://sites.computer.org/debull/A12june/pipeline.pdf https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines https://techblog.yahoo.co.jp/entry/20191216789293/ https://www.amazon.co.jp/dp/4798152374 https://www.amazon.co.jp/Kafka-Neha-Narkhede/dp/4873118492 http://mogile.web.fc2.com/kafka/intro.html

Red Hat のソリューションアーキテクトの蒸野（ムシノ）です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトがご紹介していきます。 今回は 2022年8月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: JMCエージェントによるJVM性能監視 Javaアプリケーションの性能監視にはコストがかかるものですが、JVMの性能を監視および診断するための強力なツールのセットが存在しています。 JMCエージェントとはなにか？また、JMCエージェントプラグインの入手方法や使用方法について解説した記事になります。 rheb.hatenablog.com 特集2: Camel Extensions for Quarkus と Camel K の入門 先月号に引き続き、Apache Camelをベースとした製品ファミリの「Camel Extensions for Quarkus」と「Camel K」をご紹介いたします。 Apache Camel 3 をベースにした「Camel Extensions for Quarkus」と「Camel K」はそれぞれどんなメリットがあるのかご紹介いたします。 rheb.hatenablog.com 特集3: Red Hat Single Sign-onで、WebAuthnがGAに WebAuthnがRed Hat Single Sign-On 7.6 からとうとうサポートになりました！！ こちらの記事で、サポート記念にRed Hat Single Sign-onのインストールからWebAuthnを試し見る手順をご紹介いたします。 rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat Single Sign-On 7.6 Red Hat Fuse 7.11 Red Hat Camel Extensions for Quarkus 2.7

Red Hatのソリューションアーキテクトの井上たかひろです。 WebAuthnがRed Hat Single Sign-On 7.6 からとうとうサポートになりました。 (7.6以前はTechnology Previewでした) これによって、FIDO2規格に対応したOS/ブラウザ(スマートフォーン含む)で、生体認証やパスワードレス認証などが実現できます。 この記事では、サポート記念にWebAuthnを超簡単に試してみる設定手順を紹介します。 イチから超簡単に試せるようにlocalhost(localhost以外はhttps接続が必要になります)でやります。 また、端末はmacOS(Montery)で実施しています。 なお、WebAuthnがサポートになった旨の記載は下記にあります。 access.redhat.com WebAuthnをやってみる やってみる内容 やってみる内容は、初めてログインした際にwebauthnで生体認証(macのTouch ID)を登録して、 ログアウト後に、ユーザとパスワードを入力後に、webauthnで生体認証(macのTouch ID)してログインするシナリオです。 これから記載する手順は、はじめての方にもハマらずにwebauthnを試して頂けるように、設定を最小限にし、スクショ全張りで記載しています。 Red Hat Single Sign-On 7.6をインストールして起動 Red Hat Single Sign-on 7.6もしくはKeycloak 18をzipでダウンロードしてください。 Red Hat Single Sign-on 7.6.0のKeycloakのベースバージョンは18.0.0になります。 以降は、Red Hat Single Sign-on 7.6.0で実施しています。 Red Hat Single Sign-onのzipインストールは、zip解凍すれば終わりです。配置場所は、任意です。 $ unzip rh-sso-7.6.0-server-dist.zip zipを展開して作成したディレクトリーは、SSO_HOMEとします。 環境変数にしておきます。 $ export SSO_HOME="zipを展開して作成したディレクトリー" Red Hat Single Sign-Onの管理ユーザも作っておきます。(便宜上、admin/adminで作ってます) $ $SSO_HOME/bin/add-user-keycloak.sh -u admin -p admin Added 'admin' to '/xxxx/standalone/configuration/keycloak-add-user.json', restart server to load user Red Hat Single Sign-Onを起動しておきます。 $ $SSO_HOME/bin/standalone.sh Realmを作成する testという適当な名前のRealmを作成します。 Red Hat Single Sign-Onの管理コンソールに、ブラウザで http://localhost:8080/auth/ にアクセスします。 下図の左側にある「Administration Console」をクリックします。 admin/adminでログインします。 ログイン後、左上のMasterにカーソルを合わせると、[Add relam]という青いボタンがあるので、クリックします。 Nameにと入力して、[Create]ボタンをクリックします。 webauthn policyの設定 test Realmを作成したら、Authenticationの設定で、webauthn policyの設定をやります。 test Realmを作成後、test Realmの画面に移動しています。 左側のペインにある[configure]の[Authentication]をクリックします。 Authenticationの設定画面で[Webauthn policy]のタブがあり、クリックします。 [Webauthn policy]の画面で、以下を設定します。 Relying Party ID : localhost Required Actionsの設定 Authenticationの設定画面で[Required Actions]のタブがあり、クリックします。 表の[Register]をクリックし、プルダウンから[Webauthn Register]を選択し、[OK]ボタンをクリックします。 表に[Webauthn Register]が追加され、Webauthn Registerのところの[Default Action]にチェックをつけます。 これで、新規ユーザでログインした際に、Webauthnの登録が求められるようになります。 認証フローの設定 test Realmを作成したら、Authenticationの設定で、webauthnの設定をやっていきます。 (はじめて、認証フローを設定する場合は、画面の操作に癖を感じますが、慣れるとそうでもなくなります) 左側のペインにある[configure]の[Authentication]をクリックします。 Authenticationの設定画面でFlowsのタブがあり、[Browser]が表示されています。 右側にある[copy]ボタンをクリックして、[Copy of browser]を[webauthn browser]にして、[OK]ボタンをクリックします。 表の左上にあるプルダウンを[Browser]から追加された[webauthn browser]に切り替えます。 表にある[Webauthn Browser Browser - Conditional OTP ]の行の一番右の[Actions]->[Edit Flow]をクリックします。 [New Name]の[webauthn browser Browser - Conditional OTP]を[Conditional webauthn]に修正し、[New Description]の文字列を消して、[OK]ボタンをクリックします。 (この作業自体実施しなくても問題ないのですが、OTPの文字列が残ってるのが気持ち悪いので修正しているだけです) 表の一番下にある[OTP Form]の行の一番右の[Actions]->[Delete]をクリックします。 消していいか？と聞かれるので、[Delete]ボタンをクリックして消します。(webauthnをこの後で追加します) 表にある[Conditional Webauthn]の行の一番右の[Actions]->[Add exectuion]をクリックします。 Providerを選ぶプルダウンで[WebAuthn Authenticator]を選んで、[register]ボタンをクリックします。 さきほどの操作後、Flowの設定画面に戻っています。表の一番下に[WebAuthn Authenticator]が追加され、Requirementで[ALTERNATIVE]にチェックします。(最初は[DISABLED]になっています) 認証フローの設定はこれで終わりです。 Bindingsの設定 さきほど設定した認証フローの[webauthn browser]をbrowserの認証フローで使うように設定します。 Authenticationの設定画面でBindingsのタブをクリックし、Browser Flowのプルダウンから[webauthn browser]を選択し、[Save]ボタンをクリックします。 これで、webauthn周りの設定は終わりです。 ユーザの追加 webauthnを試す前に、ユーザを作成しておきます。 左側のペインにある[Manage]の[Users]をクリックし、[Add user]をクリックします。 [Add user]画面で、user nameに[user]と入力し、[Save]ボタンをクリックします。 user作成後、[Credentials]のタブをクリックし、PasswordとPassword Confirmationに[user]と入力し、TemporaryをチェックしOFFにして、[Set Password]ボタンをクリックします。 ユーザーのパスワードは本当に設定するの？と聞かれます。[Set Password]ボタンをクリックします。 webauthnを試す 今回は、Red Hat Single Sign-onのアカウントページにアクセスして、webauthnを試してみます。 このURL http://localhost:8080/auth/realms/test/account/ にアクセスします。(今回はSafariでアクセスしました) アカウントページにアクセス後、右上の[Sign in]ボタンをクリックします。 初回ログインで、user/userと入力し、[Sign in]ボタンをクリックします。 Security Key Registrationの画面になりますので、[Register]ボタンをクリックします。 Touch IDの登録画面になりますので、Macの指紋認証をやります。 登録ができたら、登録時の名前のダイアログが出てきますが、ここはそのまま[OK]ボタンをクリックします。 ログインできました。再度ログイン確認したいので、右上の[Sign Out]ボタンをクリックして、ログアウトします。 最初の画面に戻ってきたので、右上の[Sign in]ボタンをクリックして、再度ログインします。 user/userと入力し、[Sign in]ボタンをクリックします。 おっ〜、生体認証画面になりました。[Sign in with Security Key]ボタンをクリックします。また、Touch IDが出てくるので、指紋認証後、ログインできます。 終わりに 今回は、webauthnで生体認証(macのTouch ID)をやってみました。この他にも、Passwordlessなども可能なので、ぜひ色々お試し頂いて、ご活用して頂ければと思います。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Inject custom JDK Flight Recorder events in containerized applications | Red Hat Developer の翻訳記事です。 JDK Mission Control (JMC) エージェントは、Java 仮想マシンを再起動することなく、ランタイムにカスタム JDK Flight Recorder (JFR) イベントを注入できる強力なツールです。JMCエージェントプラグインがコンテナ化されていない環境でエージェントを使用するプロセスを簡素化するのと同様に、Cryostatエージェントプラグインはコンテナ化された環境でも同じことをします。 JMCエージェントのサポートはCryostatに統合され、Cryostatはコンテナ環境でJMCエージェントを使用するための様々なAPIハンドラをサポートするようになりました。本記事では、CryostatエージェントとそのAPIハンドラについて紹介します。 注 ：この記事で取り上げた技術について理解を深めるには、 JMCエージェントによるJVM性能監視 - 赤帽エンジニアブログ と ContainerJFR入門: コンテナのためのJDK Flight Recorder - 赤帽エンジニアブログ をご覧ください。 前提条件とセットアップ Cryostatエージェントの使用は、Cryostatプロジェクトのアップストリームリポジトリから可能です。始めるには、最新版をpullしてビルドしてください： $ git clone https://github.com/cryostatio/cryostat $ cd cryostat $ mvn clean verify ビルドが完了したら、 smoketest スクリプトでCryostatのデモインスタンスを実行できます： $ smoketest.sh CryostatとJMCエージェントの統合を使用するためには、そのJARがアプリケーションと同じコンテナに存在することを保証しなければなりません。そして、JARを指定した javaagent フラグでアプリケーションを実行します： -javaagent:target/org.openjdk.jmc.agent-1.0.0-SNAPSHOT.jar 注 ：JMCエージェントは、AdoptiumのJMCリリースからダウンロードできます Cryostat JMCエージェント統合の利用 Cryostatエージェントは、APIハンドラの集合を提供します。これは JMC エージェントと対話し、カスタムイベント用のテンプレートを管理します。 ProbeTemplate ハンドラにより、ユーザは Probe テンプレートを登録または削除できます。これらのテンプレートは、注入されるカスタムイベントを記述した XML ファイルです。Cryostatに保存され、エージェントが動作している有効なターゲットに適用したり、不要になったら削除できます。同様に、 TargetProbePost 、 Delete 、 Get ハンドラは、ターゲットJVMからのカスタムイベント設定の追加、削除、取得を容易にします。 カスタムイベント監視 作業の流れの例として、Cryostat エージェントが、Cryostat 自体をターゲットアプリケーションとして現在動作しているとします。ここで、Cryostat にカスタムイベントを追加して、Cryostat の実行状況を監視したいとします。手始めに、作業するためのProbeテンプレートが必要なので、次のように考えてみます： <jfragent> <!-- グローバル設定オプション --> <config> <!-- イベントクラス名を生成する際に使用する接頭辞です。 --> <classprefix> __JFREvent </classprefix> <!-- 配列やオブジェクトのパラメータを文字列として記録できるようになります。 これにより、配列の要素や文字列以外のオブジェクトに対して toString が呼び出されるようになります。 これは、toStringメソッドの実装が悪いとトラブルの原因になります。 注意して使用してください。 --> <allowtostring> true </allowtostring> <!-- 変換機能を使用できるようにする。 詳しくは org.openjdk.jmc.agent.converters パッケージをご覧ください。 --> <allowconverter> true </allowconverter> </config> <events> <event id = "demo.cryostat.jfr" > <label> CryostatDemoEvent </label> <description> Event for the agent plugin demo </description> <path> demo </path> <stacktrace> true </stacktrace> <class> io.cryostat.net.web.http.generic.HealthGetHandler </class> <method> <name> handle </name> <descriptor> (io/vertx/ext/web/RoutingContext;)V </descriptor> </method> <!-- 位置 {ENTRY, EXIT, WRAP}--> <location> ENTRY </location> </event> </events> </jfragent> これは、 handl e メソッドのエントリポイントにカスタムイベントを追加する単純な設定です。一旦注入されると、この設定は handle メソッドが呼ばれるたびにカスタム CryostatDemoEvent を発行します。 テンプレートの <config> セクションは、カスタムイベントクラスに使用するプレフィックスと、高度な機能が必要であるかどうかを決定します。Cryostatエージェントは、イベントと共に発行されるフィールドとメソッドパラメータの取得をサポートします。そして、ユーザ定義の変換メソッドを利用して、これらのフィールドとパラメータをJDK Flight Recorderが使用できるコンテンツタイプに変換します。ただし、この機能は <config> セクションで特別に有効にする必要があります。 <config> セクションに続いて、注入するイベントをいくつでも指定できます。必要なのは、イベントID、ラベル、説明だけです。 <path> 要素は、JDK Mission Control のようなグラフィカルなツールで表示されるイベントのパスに対応します。 <stacktrace> 要素は、イベントと共にスタックトレースを記録するかどうかを決定します。 <class> , <method> , <location> 要素は、イベントが注入されるべき場所を正確に決定します。メソッドの正式な記述子をここで指定する必要があります。これは、 (Parameter Descriptor*)Return Descriptor という形式を取ります。例えば、 int isAlive() というメソッドの場合、メソッド記述子は、 ()Z となります。メソッド記述子の形式についての詳細は、JVMの仕様を参照してください。 カスタムイベントの注入と記録 Probeのテンプレートがあれば、あとはCryostatに数回のAPIリクエストを送り、それをアップロードしてターゲットに適用するだけです。(今回は、ターゲットがCryostat自身であることを忘れないでください)。 $ curl -F probeTemplate=@cryostat-probe.xml http://0.0.0.0:8181/api/v2/probes/ この最初のリクエストは ProbeTemplateUpload ハンドラ( api/v2/probes )を呼び出すものです。このハンドラは ProbeTemplate が probeTemplate という名前のフォームにアップロードされることを想定しています。 あとは、もう一回リクエストを送るだけです： $ curl -X POST localhost:8181/api/v2/targets/localhost/probes/cryostat-probes 2番目のリクエストは TargetProbePost ハンドラ( api/v2/targets/:targetID/probes/:probeTemplate )を呼び出します。このハンドラにターゲットと Probe テンプレートを与えると、ターゲットに Probe テンプレートを適用し、カスタムイベントを注入します。次にレコーディングが実行されたとき、カスタムイベントが記録されます。 まとめ JMCエージェントは、カスタムイベントを作成・記録するための強力なツールで、それらのイベントを手動で書き込んだり、アプリケーションを再構築する必要がありません。Cryostatエージェントは、同じ利点をコンテナ化された環境にもたらしてくれます。JMCエージェントの対応がアップストリームに組み込まれたことで、これらの機能をこれまで以上に簡単に活用できるようになりました。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Install the Cryostat Operator on Kubernetes from OperatorHub.io | Red Hat Developer の翻訳記事です。 Cryostat はコンテナネイティブのJVM アプリケーションで、JDK Flight Recorder(JFR) を使ってコンテナのプロファイリングと監視を行うためのセキュアな API を提供します。Cryostat 2.0では、他の機能として、OperatorHub.ioカタログの一部として提供されているCryostat Operatorが導入されました。Cryostat Operator を使用すると、既存のKubernetes環境に Cryostat を簡単にインストールできます。この記事では、インストール手順を説明します。 前提条件 開始するには、cert-managerがインストールされた実行中のKubernetesクラスタが必要です。この記事で説明する手順は、ローカルのMinikubeクラスターを想定しています。 ステップ1．Cryostat Operatorのインストール まず、OperatorHub.io の Cryostat Operator ページに移動することから始めましょう。このページには、簡単な概要、前提条件、Kubernetesカスタムリソース定義（CRD）、Cryostatに関する詳細情報へのリンクなど、Cryostat Operatorに関する有用な情報が記載されています。 install をクリックすると、クラスタに Operator をインストールするために必要な手順を示すポップアップウィンドウが表示されます。 指示に従って、OLM（Operator Lifecycle Manager）をインストールすることから始めます。 curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.19.1/install.sh | bash -s v0.19.1 コマンドが終了したら、インストールが正常に行われたことを確認します。 kubectl get pods -n olm このような感じで出力されるはずです。 ​NAME READY STATUS RESTARTS AGE catalog-operator-84976fd7df-9w7ds 1/1 Running 0 44s olm-operator-844b4b88f8-pvrtn 1/1 Running 0 44s operatorhubio-catalog-5p87x 1/1 Running 0 43s packageserver-5b7c7b9c65-7nfwc 1/1 Running 0 42s packageserver-5b7c7b9c65-stvq8 1/1 Running 0 42s 次に、Cryostat Operator をインストールします。以下のコマンドで、 my-cryostat-operator 名前空間にOperator が展開されます。 kubectl create -f https://operatorhub.io/install/cryostat-operator.yaml 注 ： このコマンドが何をするかについての詳細については、OperatorHub.ioを参照してください。 Cryostat Operatorが展開されるまで、20〜30秒かかります。以下のコマンドでその様子を確認できます。 kubectl get csv -n my-cryostat-operator -w operator フェーズで Succeeded と表示されたら、Cryostat のデプロイメントを作成する準備はほぼ完了です。しかし、最初にいくつかのネットワーク設定に取り組む必要があります。 ステップ2．Ingressルーティングを設定 Kubernetesでは、Cryostat Operatorがクラスタ外で利用できるようにするために、各サービスにIngressの設定が必要です。より詳細な説明は、Cryostat OperatorのドキュメントのNetwork Optionsのセクションを参照してください。(ドキュメントには、さまざまなニーズに対応するための他のCryostat設定オプションに関する情報も含まれています)。 必要なIngressの設定を行うには、クラスタ上でIngress Controllerが動作している必要があります。Kubernetesには様々なIngress Controllerがありますが、今回のデモではNGINX Ingress Controllerを使用します。 Kubernetesのドキュメントには、NGINX Ingress Controllerを使用してMinikube上でIngressをセットアップする方法についての有益な情報が記載されています。まず、Ingress Controllerを有効化します。 minikube addons enable ingress 次に、NGINX Ingress Controllerが期待通りに動作していることを確認します。 kubectl get pods -n ingress-nginx 以下のような出力になり、コントローラのPodが READY になったら、次のステップに進みます。 ​NAME READY STATUS RESTARTS AGE ingress-nginx-admission-create--1-9x9s4 0/1 Completed 0 37s ingress-nginx-admission-patch--1-76m8b 0/1 Completed 1 37s ingress-nginx-controller-5f66978484-ntw6f 1/1 Running 0 37s ステップ3．Cryostatのデプロイメントを作成 Cryostat インスタンスをデプロイするには、Cryostat CRD を表す YAML ファイルを使用して、Cryostat オブジェクトを作成します。Cryostat Operator のドキュメントのNetwork Options セクションには、いくつかの小さな変更を行った後にこのデモで動作する Ingress の仕様の例があります。 まず、 spec の下にある minimal フィールドは、Cryostat CRD の必須フィールドなので追加し、 false に設定します。これにより、最小値でないCryostatのデプロイが確保されます。 次に、3つのIngress設定の annotations フィールドで、 proxy-read-timeout と proxy-send-timeout の値をデフォルトの60秒から3600秒に増やします。こうすることで、Cryostatが依存するウェブソケット接続が閉じられるのを防げます。 この例を修正すると、次のようになります。 <200b>apiVersion : operator.cryostat.io/v1beta1 kind : Cryostat metadata : name : cryostat-sample spec : minimal : false networkOptions : coreConfig : annotations : nginx.ingress.kubernetes.io/backend-protocol : HTTPS nginx.ingress.kubernetes.io/proxy-read-timeout : "3600" nginx.ingress.kubernetes.io/proxy-send-timeout : "3600" ingressSpec : tls : - {} rules : - host : testing.cryostat http : paths : - path : / pathType : Prefix backend : service : name : cryostat-sample port : number : 8181 commandConfig : annotations : nginx.ingress.kubernetes.io/backend-protocol : HTTPS nginx.ingress.kubernetes.io/proxy-read-timeout : "3600" nginx.ingress.kubernetes.io/proxy-send-timeout : "3600" ingressSpec : tls : - {} rules : - host : testing.cryostat-command http : paths : - path : / pathType : Prefix backend : service : name : cryostat-sample-command port : number : 9090 grafanaConfig : annotations : nginx.ingress.kubernetes.io/backend-protocol : HTTPS nginx.ingress.kubernetes.io/proxy-read-timeout : "3600" nginx.ingress.kubernetes.io/proxy-send-timeout : "3600" ingressSpec : tls : - {} rules : - host : testing.cryostat-grafana http : paths : - path : / pathType : Prefix backend : service : name : cryostat-sample-grafana port : number : 3000 このコードを cryostat-sample.yaml という名前のファイルにコピーしてください。このファイルの準備ができたら、それを使って my-cryostat-operator ネームスペースに Cryostat のデプロイメントを作成できます。 kubectl apply -f cryostat-sample.yaml -n my-cryostat-operator 次に、デプロイの健全性を確認します。 kubectl get pods -n my-cryostat-operator -w cryostat-sample podを構成する3つのコンテナが全て READY になったら、次に進みます。 ​NAME READY STATUS RESTARTS AGE cryostat-operator-controller-manager-6f7fdb5c68-cwgc5 1/1 Running 0 85s cryostat-sample-d57dd74bb-5bqj9 0/3 Pending 0 0s cryostat-sample-d57dd74bb-5bqj9 0/3 Pending 0 0s cryostat-sample-d57dd74bb-5bqj9 0/3 ContainerCreating 0 0s cryostat-sample-d57dd74bb-5bqj9 2/3 Running 0 2s cryostat-sample-d57dd74bb-5bqj9 2/3 Running 0 11s cryostat-sample-d57dd74bb-5bqj9 3/3 Running 0 11s ステップ4．CryostatのサービスURLをMinikubeにルーティング 次に、Ingressのコンフィギュレーションを入手します。 kubectl get ingress -n my-cryostat-operator ここまでの設定が正しければ、このコマンドの出力は次のようになります。 ​NAME CLASS HOSTS ADDRESS PORTS AGE cryostat-sample nginx testing.cryostat localhost 80, 443 5m4s cryostat-sample-command nginx testing.cryostat-command localhost 80, 443 5m4s cryostat-sample-grafana nginx testing.cryostat-grafana localhost 80, 443 5m4s Minikubeはローカルで動作しているため、 ADDRESS 列のIPv4アドレスは実際には3つのサービスの内部アドレスとなります。クラスタ内のサービスが公開される外部アドレスを取得するには、次のコマンドを実行します。 minikube ip 注 ： この記事では、 IP_ADDRESS はこのコマンドが返すアドレスの代わりに使用します。 次のステップでは、コンピュータの /etc/hosts ファイルを編集します。(このファイルのパスは、LinuxとmacOSの両方で有効です。Windowsの場合、パスは C: \Windows\System32\Drivers\hosts です)このファイルを編集するには、管理者権限が必要です。 SUDO_EDITOR=gedit sudoedit /etc/hosts ファイルの一番下に次の行を追加します。 {IP_ADDRESS} testing.cryostat testing.cryostat-command testing.cryostat-grafana {IP_ADDRESS} は、上記の minikube ip コマンドを実行したときの結果であることを忘れないでください。 この追加により、Webブラウザは上記3つのホストのいずれかを含むHTTPS URLへのリクエストをMinikubeにルーティングするようになります。 testing.cryostat-grafana ホストは、現在の Cryostat インスタンスにリンクされている Grafana ダッシュボードにアクセスするためのものです。 testing.cryostat-command ホストは、非推奨のコマンドチャンネルから残されたものです。 hosts ファイルを変更すると、 https://testing.cryostat でCryostatのウェブクライアントUIにアクセスできるようになります。 結論 この記事で説明した手順でCryostat Operatorをインストールした後、次にできることがいくつかあります。Cryostat で動作するように Java アプリケーションを構成して、Web クライアントを使用して監視できます。また、Java アプリケーションを監視するためのカスタムターゲットを設定できます。Cryostat 2.0 のその他の便利な新機能については、 Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ を参照してください。Cryostat で何ができるかについては、 ContainerJFR入門: コンテナのためのJDK Flight Recorder - 赤帽エンジニアブログ をご覧ください。

こんにちは、Red Hat で Middleware Technical Account Manager を担当している生井沢（ @hnamaizawa ）です。 この記事は Red Hat Developer のブログ記事、 The road to JBoss EAP 8 を許可をうけて翻訳したものです。 オープンソースの Jakarta Enterprise Edition (Jakarta EE) に対応するアプリケーションサーバーである Red Hat JBoss Enterprise Application Platform (JBoss EAP) は、過去10年間にわたり Enterprise Java ワークロードの主力製品として信頼を得てきました。この記事では、現行バージョンである JBoss EAP 7 のリリース以降に Jakarta EE 仕様がどのように進化したのか、また JBoss EAP 8 では何が期待できるのかについて説明します。 JBoss EAP 7 はクラウド環境に最適化されており、 Red Hat OpenShift で展開すると、 コンテナ 、ロードバランシング、Elastic Scaling、ヘルスモニタリング、および IDE から直接コンテナにデプロイできる機能によって開発者の生産性とエクスペリエンスを向上します。 Jakarta EEの進化 Red Hat は Jakarta EE ワーキンググループの創設メンバーの 1 つであり、Java Enterprise Edition (Java EE) の初期段階から革新と貢献に積極的に関わってきました。Java EE が Oracle 社から Eclipse Foundation の Jakarta EE に移行した後、 Jakarta EE 8 がリリース され、仕様をよりベンダーニュートラルなものに設定し、Red Hat や他のベンダーがこの移行を支持しました。 次のメジャーリリースである Jakarta EE 9 では、目立った新機能は導入されませんでしたが、その代わりに Jakarta API パッケージの名前空間を javax.* から jakarta.* へ変更するという大きな修正が行われました。この名称変更により、既存のプログラムとの間に大きな非互換性が生じました。Jakarta EE 9 は、次のメジャーバージョンである Jakarta EE 10 への足がかりと見なされることがほとんどでした。また、JBoss EAP がこの足がかりをサポートしていないのは、Jakarta EE 9 へ移行するために説得力のある新たな理由がなく、お客様やアプリケーションへ付加価値が提供できないからです。 Jakarta EE 10 の現在の計画 では、2022年第2四半期にリリースすることになっており、Jakarta EE 8（Java EE 8と同一）、Jakarta EE 9（名前空間の変更）と比較して、プラットフォームを大幅に改訂する機会を提供します。 Jakarta EE のいくつかの仕様に新機能が追加されます。特に目立つのは、 Core Profile の導入です（Java EE または Jakarta EE に何年も前からある既存の Full Profile と Web Profile を補完するものです）。この新しい Profile には、マイクロサービス、サーバレスワークロード、ネイティブに事前にコンパイルされたアプリケーションなど、小規模で用途を絞ったアプリケーションに最も有用な Jakarta EE 仕様のサブセットが含まれています。Core Profile はこの仕様にとって大きな前進であり、Jakarta EE をクラウドネイティブとコンテナの領域へより踏み込ませるものです。 JBoss EAP 8 の計画について いつものように、お客様は展開されたランタイムのアップグレードや移行を計画するために、 life cycles of the Runtimes products （EAPを含む）を参照する必要があります。この記事に記載されている情報は、予告なく変更されることがあります。 JBoss EAP はアップストリームの WildFly プロジェクトをベースにしています。このプロジェクトは、Jakarta EE の進化に合わせた feature-boxed release に移行しており、Jakarta EE 10 をサポートする WildFly の最初のバージョンは WildFly 27 になる予定です。そのため、JBoss EAP の今後の展開を知りたい方は、WildFly に注目してください。 EAP の次のメジャーリリースである JBoss EAP 8 は、2023年の前半に予定されており、ベータ版リリースは2022年の後半を目標としています。ベータ版リリースでは、お客様に新機能のテストドライブの機会を提供しますが、より重要なのは、JBoss EAP の以前のバージョンからの移行を計画することです。新機能とともに、 Red Hat Enterprise Linux 、Red Hat OpenShift、Windows、データベース、およびその他の依存関係に対するプラットフォームのサポートの更新が行われる予定です。最終的なリストはリリース間近に決定される予定です。 既存バージョンである JBoss EAP 7.x のサポートは、現在のお客様が JBoss EAP 8 への移行を計画するための猶予期間を提供するために延長されました。JBoss EAP の最新のサポート日程については、 Product Support and Update Policy ページを参照してください。 製品ライフサイクル JBoss EAP の現行バージョンと同様に、お客様は JBoss EAP 8 でも Red Hat Application Services の Long-life Product Life Cycle に対応する長期サポートを引き続き享受することができます。業界をリードする 24x7 サポート と複数年のアップデートおよびメンテナンスポリシーと相まって、このコミットメントにより、お客様は Red Hat が今後何年にもわたってお客様の最も重要なアプリケーションをサポートできることに安心感を持つことができます。 JBoss EAP 8 への移行について EAP 7 は、 support life cycle に基づき、引き続きサポートされます。お客様は、EAP 7 のライフサイクルを超えてサポートを継続するために、EAP 8 への移行の計画を開始する必要があります。今年後半の EAP 8 ベータ版リリースが近づくにつれ、移行の詳細が明らかになるでしょう。しかし、一般的に移行はサーバーとアプリケーションの2つの主要な領域で構成されています。 サーバーの移行 このプロセスには、 standalone.xml などの JBoss EAP 設定ファイルの移行が含まれます。 JBoss Server Migration Tool は、既存の構成を維持したまま、新しい JBoss EAP リリースの新機能や設定を含めるためにサーバー構成を更新するのに適した方法です。JBoss Server Migration Tool は既存の JBoss EAP 設定ファイルを読み込み、新しいサブシステムの設定を追加し、既存のサブシステム設定を新機能で更新し、古くなったサブシステム設定や "pruned" サブシステム設定を削除します。 このツールのプレビューは、JBoss EAP 8 ベータ版リリースの一部として含まれる予定です。このツールの詳細な動作を理解するには、この移行ツールに関する既存の EAP 7 のドキュメントを参照してください (EAP 8 用に更新される予定です)。 アプリケーションの移行 ここでの主な移行トピックは Jakarta API の名前空間を javax.* から jakarta.* へと変更することです。多くの場合、この変更は単純な置換だけで済みますが（そして migration toolkit では、これを自動化するための OpenRewrite レシピなどが新たにサポートされています）、すべてのケースでそうなるわけではありません。 アプリケーションの移行を支援するために、お客様は migration toolkit for applications を使用することができます。このツールキットは拡張可能でカスタマイズ可能なルールベースのツールセットで、Java アプリケーションの移行を簡素化するのに役立ちます。移行を予定しているアプリケーションで使用されている API、テクノロジー、アーキテクチャを分析し、各アプリケーションの詳細な移行レポートを提供します。このツールは、JBoss EAP 8 ベータ版（テスト目的のみ）および JBoss EAP 8 GA がリリースされた後の移行をサポートする予定です。EAP 8 への具体的な移行方法の詳細は、EAP 8 ベータ版のリリース間近に公開される予定です。 アプリケーションの移行とモダナイゼーション は、それ自体大きなトピックです。Red Hat はここでも革新を続けており、クラウド、コンテナ、Kubernetes への移行に伴うアプリケーションの移行とモダナイゼーションを容易にする Tackle ( Konveyor コミュニティの一部) などの新しいプロジェクトがあります。 JBoss EAP 8 のリリースに向けての詳細については、本サイトと公式の新しい @RedHatJava Twitter ストリーム を引き続き確認してください。

こんにちは、Red Hat の Middleware Technical Account Manager のイアンです。 Red Hat Security Data ページに提供されている daysofrisk.pl というスクリプトがご存知でしょうか？このスクリプトを使っていただくと、特定の製品のセキュリティ更新の数とその一覧を簡単に取得することが可能です。 NOTE: 当記事は Red Hat TAM Blog に公開された Getting a list of fixes for a Red Hat product between two dates is easy with daysofrisk.pl を参照して作成しました。 準備 始める前に、スクリプトとスクリプトが利用するデータをダウンロードしてください。Linux環境の場合は以下のようなコマンドを実行します。 $ mkdir security_review $ cd security_review $ wget https://www.redhat.com/security/data/metrics/release_dates.txt https://www.redhat.com/security/data/metrics/rhsamapcpe.txt https://www.redhat.com/security/data/metrics/cve_dates.txt https://www.redhat.com/security/data/metrics/daysofrisk.pl $ chmod 700 daysofrisk.pl 準備が整いましたら、 daysofrisk.pl を実行しましょう。 脆弱性報告数の取得 例えば、 Red Hat JBoss Enterprise Application Platform 7.2 (以降EAPとして表記) の Critical、Important および Moderate のセキュリティ更新を確認したい場合は以下のコマンドを実行します。 $ ./daysofrisk.pl --cpe jboss_enterprise_application_platform:7.2 --severity CIM EAP 7.2 の Common Platform Enumeration (略: CPE) の製品名が jboss_enterprise_application_platform:7.2 になります。重大度を絞り込むために --severity CIM のオプションを使って、Critical、Important および Moderate のセキュリティ更新のみにします（重大度Lowを除外しています）。 NOTE: 他のコマンドライン引数に関しては、 daysofrisk.pl --help を実行してください。 その結果が以下のようになります。 ** Product: Red Hat Jboss Enterprise Application Platform 7.2 (all packages) ** CPE: redhat:jboss_enterprise_application_platform:7.2 ** Severity: Critical Important Moderate ** Dates: 20190122 - 20220719 (1275 days) ** 46 advisories (I=37 M=9 ) ** 75 vulnerabilities (I=29 M=46 ) ** Advisory Workload index is 0.03 ** Vulnerability Workload index is 0.03 ** Average is 129 days ** Median is 117 days ** 13% were 0day ** 16% were within 1 day ** 18% were within 7 days ** 21% were within 14 days ** 28% were within 31 days ** 34% were within 90 days 結果を見ていただくと、EAP 7.2 がリリースされた2019年01月22日から2022年7月現在までに、46個のセキュリティ報告の中に75個の脆弱性が報告されていることがお分かり頂けます。セキュリティ報告の内の37個が Important で、9個が Moderate の重大度になっていました。 CVEの詳細情報の取得 daysofrisk.pl は上記の情報だけではなく、CVE情報をデフォルトで summary.xml に出力します。残念ながら、 summary.xml の情報量は少ないです。各CVEの情報は以下のとおりです。 <item> <cve> CVE-2017-18640 </cve> <severity> M </severity> <source> cvenotification </source> <reportedon> 20191219 </reportedon> <cvss3> 7.6 </cvss3> <fixedby> RHSA-2021:3140 </fixedby> <fixedon> 20210811 </fixedon> <publicon> 20191212 </publicon> <daysdiff> 608 </daysdiff> </item> このXMLと Red Hat Security API の CVE一覧 機能を使って、もう少し詳細な情報を取得することが可能です。Security API はカスタマーポータルのアカウントがなくてもご利用頂けます。 以下のスクリプトは summary.xml からCVE番号を抽出し、コンマ区切りの形に変換してから、APIを呼び出します。 #!/usr/bin/env bash # XMLからCVE IDを抽出しコンマ区切り文字列に変換する cve_ids = " $( xmllint --nowarning --xpath ' /summary/item/cve/text() ' summary.xml | sort -r | paste -sd " , " - ) " # APIを使ってCVE詳細を取得する curl -s -H " accept: application/json " " https://access.redhat.com/hydra/rest/securitydata/cve.json?ids= $cve_ids " その結果は以下のようなJSON形式のデータになります。 [ { " CVE ": " CVE-2021-3859 ", " severity ": " important ", " public_date ": " 2022-02-01T00:00:00Z ", " advisories ": [ " RHSA-2022:5532 ", ... ] , " bugzilla ": " 2010378 ", " bugzilla_description ": " CVE-2021-3859 undertow: client side invocation timeout raised when calling over HTTP2 ", " cvss_score ": null , " cvss_scoring_vector ": null , " CWE ": " CWE-214 ", " affected_packages ": [ " eap7-wildfly-http-client-0:1.1.10-1.Final_redhat_00001.1.el8eap ", ... ] , " resource_url ": " https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2021-3859.json ", " cvss3_scoring_vector ": " CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H ", " cvss3_score ": " 7.5 " } , { " CVE ": " CVE-2021-40690 ", " severity ": " moderate ", " public_date ": " 2021-09-17T00:00:00Z ", " advisories ": [ " RHSA-2022:5532 ", ... ] , " bugzilla ": " 2011190 ", " bugzilla_description ": " CVE-2021-40690 xml-security: XPath Transform abuse allows for information disclosure ", " cvss_score ": null , " cvss_scoring_vector ": null , " CWE ": " CWE-200 ", " affected_packages ": [ " camel-quarkus-xmlsecurity ", ... ] , " resource_url ": " https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2021-40690.json ", " cvss3_scoring_vector ": " CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N ", " cvss3_score ": " 7.5 " } ] jq コマンドやPythonでJSONを処理し、分かりやすい形に変換できます。また上記の resource_url を使って、個別のCVEのより詳細（概要も含め）な情報を取得できます。 他の製品 他のミドルウェアも同じように一覧を生成できます。 jboss_enterprise_application_platform:7.2 の変わりに以下のCPEを使ってください。 製品名 CPE AMQ Broker 7 amq_broker:7 AMQ Streams 2 amq_streams:2 Red Hat Fuse 7 jboss_fuse:7 Red Hat Single Sign-On 7 red_hat_single_sign_on:7 マイナーバージョンがない場合 マイナーバージョンまで管理されている製品が少ないため、マイナーバージョンを使った場合にセキュリティ報告が0件の場合はマイナーバージョンの公開日を使うことを推奨いたします。 例えば、Red Hat Fuse 7.8 の一覧を作りたい場合は、 Fuse Maintenance Schedule によりますと、7.8が2020年12月17日に公開されることが分かります。開始日として指定して、 daysofrisk.pl を実行できます。 $ ./daysofrisk.pl --cpe jboss_fuse:7 --datestart 20201217 --severity CIM

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 A faster way to access JDK Flight Recorder data | Red Hat Developer の翻訳記事です。 この記事では、Cryostat 2.0の特別なルール定義について紹介します。これにより、アプリケーションの通常スケジュールされたアーカイブプロセスを待たずに、JDK Flight Recorder (JFR) データにその場でアクセスできます。Cryostat の新しい POST ルール定義を紹介し、それを使って Kubernetes や Red Hat OpenShift 上で動作するコンテナ化アプリケーションのパフォーマンス問題を迅速に診断する方法を紹介します。 シリーズを読む： Kubernetes のための JDK Flight Recorder (JFR) であるCryostat 2.0を使用するためのハンズオンガイドをシリーズで公開しています。このシリーズの全記事をご覧ください。 ContainerJFR入門: コンテナのためのJDK Flight Recorder - 赤帽エンジニアブログ Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ CryostatによるカスタムターゲットのJavaモニタリング - 赤帽エンジニアブログ Automating JDK Flight Recorder in containers - 赤帽エンジニアブログ 注意 ：Cryostat 2.0 の Red Hat ビルドは、現在、技術プレビューで広く利用可能です。Red Hat ビルドには、OpenShift 上での Cryostat のデプロイを簡素化および自動化するための Cryostat Operator が含まれています。 サービスの中断を継続的に監視 クラスタ管理者がプロジェクトの名前空間に Cryostat をデプロイし、Cryostat の自動化ルールを使って継続的なアプリケーション監視を可能にしたシナリオを考えてみましょう。 このようなルール定義は、次のようになります。 { " name ": " continuousMonitoring ", " description ": " Enable the Continuous template on all parts of our service ", " matchExpression ": " target.labels.platform[‘app’]==’myService’ ", " eventSpecifier ": " template=Continuous,type=TARGET ", " archivalPeriodSeconds ": 3600 , " preservedArchives ": 4 } continuousMonitoring と呼ばれるこのルールは、 app=myService ラベルを持つすべてのターゲットで Continuous イベントテンプレートを使用して記録を作成します。そして、1時間に1回、レコーディングデータをアーカイブにコピーし、このアーカイブされたコピーを4つ維持します。 このシナリオでは、プロジェクトに多くのマイクロサービスのインスタンスが含まれ、それらが一緒になって顧客に大きな外部サービスを提供します。マイクロサービスは、顧客のトラフィックを処理する一方で、お互いに内部リクエストをします。時折、クラスタ管理者がまだ理解していない理由で不具合が発生し、顧客のリクエストに対応する時間が突然急増することがあります。 OpenJDKのフライトデータのPOSTルールを利用 管理者がスパイクが発生したという通知を受け取ったとします。しかし、 continuousMonitoring ルールは、JDK Flight Recorderのデータをアーカイブにコピーするために、さらに40分設定されていません。明らかに、管理者はそんなに長く待ちたくはありません。サービスの遅延が急増した原因を突き止め、すぐに修正する必要があります。そのためには、JDK Flight Recorderのデータを即座に取得する方法が必要です。 Cryostat 2.0では、クラスタ管理者が以下のような形式のルール定義を POST することで、OpenJDKのフライトデータを即座に取得できます。 { " matchExpression ": " target.annotations.platform[‘app’]==’myService’ ", " eventSpecifier ": " archive " } eventSpecifier: archive プロパティに注目してください。これは、一致するすべてのターゲットに新しい記録を作成するのではなく、一致するすべてのターゲットからCryostatアーカイブに直ちに記録データをコピーすることをCryostatに指示する特殊なケースです。元のルール定義と同じ matchExpression を使用することで、アーカイブアクションが同じターゲットに適用されることが保証されます。 たとえば、管理者がマイクロサービスのターゲットの特定のグループに問題があると疑った場合、それに合わせて matchExpression を細かく調整できます。たとえば、ログインサービスに検索を集中させることもできます。 { " matchExpression ": " target.annotations.platform[‘app’]==’myService’ && /^my-app-login-service-/.test(target.alias) ", " eventSpecifier ": " archive " } 新しいルール定義をCryostatに POST した後、管理者はすぐにCryostatアーカイブ内の各マイクロサービスレプリカの記録データのコピーにアクセスできるようになります。見てみましょう。 $ CRYOSTAT=https://cryostat.example.com $ curl -F name="continuousMonitoring" -F description=”Enable the Continuous template on all parts of our service” -F matchExpression=”target.annotations.platform[‘app’]==’myService’” -F eventSpecifier=”template=Continuous,type=TARGET” -F archivalPeriodSeconds=3600 -F preservedArchives=4 $CRYOSTAT/api/v2/rules $ # some time passes $ curl -F matchExpression=”target.annotations.platform[‘app’]==’myService’ && /^my-app-login-service-/.test(target.alias)” -F eventSpecifier=archive $CRYOSTAT/api/v2/rules $ curl $CRYOSTAT/api/v1/recordings ここから、JSONレスポンスを処理し、様々なアクションを起こせます。レスポンスは、アーカイブ内の各レコーディングに関する情報を含むオブジェクトの配列です。レコーディング名は、 アーカイブ ルールによって生成されたものを分離するために、フィルタリングできます。管理者は、JSONオブジェクトの reportUrl または downloadUrl プロパティを使用して、自動分析またはJDK Flight Recorderデータダンプのいずれかを含むHTMLドキュメントを取得することができます。 まとめ JDK Flight Recorderのレコーディングデータは、定期的にアーカイブされるため、ほとんどの場合、診断の目的には十分です。しかし、時にはデータへのより迅速なアクセスが必要な場合があります。この記事では、Cryostatの新しいPOSTルール形式を使用して、JDK Flight Recorderのデータに即座にアクセスする方法を学びました。クラスタ管理者として、特別に策定したルールをPOSTすることでシステムの中断に対応し、その後、コンテナ化されたアプリケーションのパフォーマンスの中断を診断するためにデータをバッチで取得できます。Cryostat 2.0のこの他の新機能の詳細については、Cryostat.ioをご覧ください。

こんにちは、Red Hatでソリューションアーキテクトをしている北村です。 Red Hatでは、Kubernetes環境で動作しているコンテナやマニフェストのセキュリティ対策状況を管理する Red Hat Advanced Cluster Security for Kubernetes(RHACS) という製品を展開しています。 今回はRHACSのインストール手順と、RHACSを使ったサンプルアプリのセキュリティ対策方法について以下の2つの記事にまとめてみました。 qiita.com qiita.com ちなみにRHACSの概要については、赤帽エンジニアブログの以下のページにて詳しく書かれていますので、まずはこちらをご一読いただくといいかと思います。 RHACS (Red Hat Advanced Cluster Security for Kubernetes) のご紹介 rheb.hatenablog.com RHACSって色々できるらしいけど、どうやって使うの？という方や、導入してみたけど実運用にどう繋げればいいんだろう？といった方はぜひ参考にしていただければと思います。

レッドハットの杉村です。Ansible のテクニカルサポートをしています。 先ほど、OpenShift での問題解析のためのコマンドを紹介する記事が掲載されました。 rheb.hatenablog.com Ansible Automation Platform (AAP) も OpenShift で動作しまして、以前 Operator からインストールしてみたという記事を書いたことがあります。 rheb.hatenablog.com オンプレミス版での問い合わせの場合は sosreport を生成して送っていただくことがあるのですが、OpenShift で動作するもののときは AAP の動作の解析には役に立ちません。ここでも must-gather での情報取得をお願いすることがあります。 access.redhat.com AAP 2.2 をインストールしているときの情報収集について紹介します。 1) oc adm inspect ns/ansible-automation-platform 先ほどの記事にも説明されていますが、must-gather での情報収集の前に、簡単に状況を把握するためにこのコマンドで namespace を特定して情報を収集することがあります。AAP Operator からインストールした場合には、namespace は ns/ansible-automation-platform です。 $ oc login https://api.ocp.sugimura.home:6443 ... $ oc adm inspect ns/ansible-automation-platform Gathering data for ns/ansible-automation-platform... Wrote inspect data to inspect.local.2396357822870305135. このコマンドでは主に Pods の情報を集めてきまして、ログを収集するだけであればこれで十分なこともあります。 例えばこのように、AAP が動作するための Pods についての情報がまとまってきますので、それぞれ見ていくことができます。 $ ls inspect.local.2396357822870305135/namespaces/ansible-automation-platform/pods/ aap22-9cb54f667-tf548/ example-6cb5c4d687-kz4vw/ aap22-postgres-13-0/ example-postgres-13-0/ automation-controller-operator-controller-manager-c4f59fc5jxqmc/ resource-operator-controller-manager-77fc5c8595-jlnml/ automation-hub-operator-controller-manager-b4797f66b-nrj87/ 2) oc adm must-gather --image=registry.redhat.io/ansible-automation-platform-22/aap-must-gather-rhel8 より詳細に状況を知りたい場合には、must-gather を使うことになります。AAP 用の情報収集のためのコンテナも用意されています。 $ oc adm must-gather --image=registry.redhat.io/ansible-automation-platform-22/aap-must-gather-rhel8 [must-gather ] OUT Using must-gather plugin-in image: registry.redhat.io/ansible-automation-platform-22/aap-must-gather-rhel8 [must-gather ] OUT namespace/openshift-must-gather-9pftx created [must-gather ] OUT clusterrolebinding.rbac.authorization.k8s.io/must-gather-5782m created [must-gather ] OUT pod for plug-in image registry.redhat.io/ansible-automation-platform-22/aap-must-gather-rhel8 created [must-gather-msfjq] POD Wrote inspect data to must-gather. [must-gather-msfjq] POD Wrote inspect data to must-gather. ... [must-gather-msfjq] OUT namespaces/ansible-automation-platform/policy/ [must-gather-msfjq] OUT namespaces/ansible-automation-platform/policy/poddisruptionbudgets.yaml [must-gather-msfjq] OUT namespaces/ansible-automation-platform/route.openshift.io/ [must-gather-msfjq] OUT namespaces/ansible-automation-platform/route.openshift.io/routes.yaml [must-gather-msfjq] OUT [must-gather-msfjq] OUT sent 2246 bytes received 31472564 bytes 6994402.22 bytes/sec [must-gather-msfjq] OUT total size is 31456608 speedup is 1.00 [must-gather ] OUT clusterrolebinding.rbac.authorization.k8s.io/must-gather-5782m deleted [must-gather ] OUT namespace/openshift-must-gather-9pftx deleted 収集した情報は inspect のときと同じようにローカルディレクトリに must-gather.XXXXXXXXXXXXXXXXXX として保存されますので、tar + gz などで固めていただいて送っていただくことで、こちらで解析を進めることができます。 $ ls must-gather.local.8087695538373383744/registry-redhat-io-ansible-automation-platform-22-aap-must-gather-rhel8-sha256-9f82060dd6a5bb202b119db9a2f81e20299b6ff18744639ac21175b0793857a4/namespaces/ansible-automation-platform/ ansible-automation-platform.yaml* autoscaling/ discovery.k8s.io/ route.openshift.io/ apps/ batch/ image.openshift.io/ apps.openshift.io/ build.openshift.io/ pods/ automationcontroller.ansible.com/ core/ policy/ ... まとめ ちょうど何か書こうとしていたところで OpenShift の記事が掲載されましたので、AAP としての利用方法についても乗っかってまとめてみました。 OpenShift と Ansible Automation Platform の評価ライセンスリクエストはこちらからご利用いただけます。60日間利用できます。 www.redhat.com www.redhat.com Happy Automation!

Red HatでOpenShiftのサポートをしている id:nekop です。 OpenShiftには問題解析のための情報収集を行なうmust-gatherというコマンドおよびイメージ群が用意されています。 特にオプションを指定しないで oc adm must-gather コマンドを実行した場合、OpenShiftのクラスタを構成するCluster Operatorの情報を取得します。 $ oc adm must-gather OpenShiftのクラスタを構成するCluster Operatorというのは以下のコマンドで参照できます。 $ oc get co NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.10.15 True False False 25h baremetal 4.10.15 True False False 25h cloud-controller-manager 4.10.15 True False False 25h cloud-credential 4.10.15 True False False 25h cluster-autoscaler 4.10.15 True False False 25h config-operator 4.10.15 True False False 25h console 4.10.15 True False False 3h13m csi-snapshot-controller 4.10.15 True False False 25h dns 4.10.15 True False False 3h14m etcd 4.10.15 True False False 25h image-registry 4.10.15 True False False 25h ingress 4.10.15 True False False 3h13m insights 4.10.15 True False False 25h kube-apiserver 4.10.15 True False False 25h kube-controller-manager 4.10.15 True False False 25h kube-scheduler 4.10.15 True False False 25h kube-storage-version-migrator 4.10.15 True False False 3h14m machine-api 4.10.15 True False False 25h machine-approver 4.10.15 True False False 25h machine-config 4.10.15 True False False 25h marketplace 4.10.15 True False False 25h monitoring 4.10.15 True False False 25h network 4.10.15 True False False 25h node-tuning 4.10.15 True False False 25h openshift-apiserver 4.10.15 True False False 25h openshift-controller-manager 4.10.15 True False False 25h openshift-samples 4.10.15 True False False 25h operator-lifecycle-manager 4.10.15 True False False 25h operator-lifecycle-manager-catalog 4.10.15 True False False 25h operator-lifecycle-manager-packageserver 4.10.15 True False False 25h service-ca 4.10.15 True False False 25h storage 4.10.15 True False False 25h オプションなしの oc adm must-gather コマンドでは、上記Cluster Operatorに関連する全てのリソースyaml、関連namespace内のConfigMapやDeployment, Podといったコアリソースyaml、Podのログを収集します。 oc adm must-gather コマンドはmust-gatherイメージを利用したコンテナをクラスタ上で実行して、must-gatherコンテナが実際の情報収集を行なうという実行モデルになっています。 類似のコマンドとして oc adm inspect があります。inspectはmust-gatherとは異なり、イメージを利用せず、ocコマンドが直接情報収集を行います。must-gatherコンテナは内部で oc adm inspect コマンドを利用して情報収集をしています。実際のスクリプトは GitHubのmust-gatherリポジトリ で参照できます。 たとえば特定ネームスペースの情報を取得するには以下のようにネームスペースを指定します。 $ oc adm inspect ns/myproject 注意点として、must-gatherはCluster Operatorの情報しか取得しないため、アプリケーションのネームスペースなどの情報は基本的に含まれていません。アプリケーションが関連する問題では、must-gatherとアプリケーションのネームスペースのinspectの両方を取得する必要があります。 omcコマンド must-gatherやinspectが収集する情報は基本的に全てyamlで保存されるため、人間がそのまま見るにはつらいフォーマットとなりますが、このyamlをoc, kubectlコマンドと同じインタフェースにしてくれる omc, OpenShift Must-Gather Clientというツール があります。oc adm inspectで保存されるデータ形式を処理することができます。 omcコマンドではまずuseオプションで対象のmust-gatherやinspectのディレクトリを指定します。そのあとは通常のoc, kubectlコマンドと同じオプションで操作します。 $ omc use ./must-gather.local.754454620684116043/ $ omc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-205-20.ap-northeast-1.compute.internal Ready master,worker 28h v1.23.5+3afdacb ip-10-0-209-54.ap-northeast-1.compute.internal Ready master,worker 28h v1.23.5+3afdacb ip-10-0-235-32.ap-northeast-1.compute.internal Ready master,worker 28h v1.23.5+3afdacb クラスタの状態を確認するときのバターンとして、以下のコマンドを実行します。 omc alert rules はomcコマンドの独自拡張で、must-gather内に保存されたalertの状況を確認できるコマンドです。 omc etcd というコマンドもあります。 omc get clusterverion omc get co omc get node omc get pod -A omc alert rules --status=firing これらの出力に問題がある場合はcoのstatusフィールドや関連するPodのログなどを参照して、問題をブレークダウンしていきます。 $ omc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.10.15 True False 28h Cluster version is 4.10.15 $ omc get co NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.10.15 True False False 26h (省略) storage 4.10.15 True False False 28h $ omc get node NAME STATUS ROLES AGE VERSION ip-10-0-205-20.ap-northeast-1.compute.internal Ready master,worker 28h v1.23.5+3afdacb ip-10-0-209-54.ap-northeast-1.compute.internal Ready master,worker 28h v1.23.5+3afdacb ip-10-0-235-32.ap-northeast-1.compute.internal Ready master,worker 28h v1.23.5+3afdacb $ omc get pod -A $ omc get pod -A | head NAMESPACE NAME READY STATUS RESTARTS AGE openshift-apiserver apiserver-6864bc57fd-92jnv 2/2 Running 1 28h (省略) openshift-service-ca-operator service-ca-operator-989b7b6b9-bcmcz 1/1 Running 2 28h $ omc alert rule --state firing RULE STATE AGE ALERTS ACTIVE SINCE UpdateAvailable firing 7s 1 24 Jun 22 01:44 UTC APIRemovedInNextEUSReleaseInUse firing 29s 3 24 Jun 22 03:10 UTC Watchdog firing 20s 1 24 Jun 22 01:43 UTC AlertmanagerReceiversNotConfigured firing 0s 1 24 Jun 22 01:43 UTC 他のmust-gatherイメージ Cluster Operatorではない、追加したOperatorの情報を取得するため、 Operator側で専用のmust-gatherイメージが提供されているもの があります。以下のようなOperatorです。 OpenShift Logging OpenShift Service Mesh OpenShift Serverless OpenShift Data Foundation OpenShift Virtualization 基本的には各must-gatherイメージについて oc adm must-gather --image=xxx として指定すればいいのですが、利用頻度が高めのOpenShift Loggingについては慣例としてバージョン指定のため以下の形式で実行します。 $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator \ -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}') 各Operatorのmust-gatherイメージで収集されるデータはinspect形式ではないものも多く、それらはomcコマンドで参照することはできません。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 JVM performance monitoring with JMC agent | Red Hat Developer の翻訳記事です。 最近のJDK Mission Control (JMC) 8.1リリースに伴い、新しいJMCエージェントプラグインに目を向ける良い機会です。アップストリームにマージされたこのプラグインは、Javaアプリケーションを再起動または再構築することなく、実行中のJava仮想マシン（JVM）にカスタムJDK Flight Recorder（JFR）イベントを追加する便利な方法を提供します。 JDK Mission Control と JDK Flight Recorder 本番環境におけるJavaアプリケーションの性能監視にはコストがかかりますが、監視機能をインストールするためにJVMを再起動できない、あるいは望ましくない環境ではなおさらのことです。JDK Flight Recorder (JFR) は、JVMに組み込まれたJavaアプリケーション監視機能で、性能の負担や 設定を最小限に抑えます。 注意 ：コンテナ化されたJVMからフライトレコーディングを取得、保存、分析できる必要があるのでしょうか？ Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ をチェックしてみてください。 JMC エージェント JMCエージェントは、JDK Mission Controlとともに開発されているツールで、JVMを再起動することなく、実行時にカスタムJDK Flight Recorderイベントを追加できます。このエージェントは、カスタムJDK Flight Recorderイベントのバイトコードと、指定されたメソッド内でイベントを発生させるバイトコードを追加することで機能します。また、JMCエージェントは、メソッド・パラメータやクラス・フィールドの値を取得し、カスタム・イベントの一部として発行できます。JDK Mission Control 8.1には、エージェントのライフサイクルを通じて制御するためのプラグインが含まれています。 Limitations of JMC agent JMCエージェントには，開発者が知っておくべきいくつかの制約があります． Synthetic Classでは動作しません。 また、入れ子のプライベート・フィールドにアクセスできません。 新たにアップロードされた設定は、システム・クラス・ローダで定義されたクラスでのみ動作します。 JMCエージェントプラグインの入手方法 JMCエージェントプラグインは、アップストリームJDK Mission Control 8.1に含まれているため、ダウンロードして実行するだけで利用を開始できます。エージェントプラグインは、JMCエージェントJARも必要となります。JDK Mission Control 8.1.0 と JMC agent JAR は、Eclipse Adoptium Working Group の jmc-overrides GitHub ページからダウンロードできます。 JMCエージェントプラグインの使用 JMCエージェントプラグインの使い方を説明するために、Webページから単語を読み込んで解析し、データベースに格納するプログラムを考えてみましょう。以下に、いくつかのメソッドのサンプルを示します。 private static void loadWords(String path) { try { List<String> lines = retrieveWords(path); for (String line : lines) { for (String word : Arrays.asList(line.split( " " ))) { doWork(word); storeWord(word); } } } catch (Exception e) { e.printStackTrace(); System.err.println(e.getMessage()); } } private static void storeWord(String word) { Jedis jedis = pool.getResource(); jedis.sadd(key, word); pool.returnResource(jedis); } この記事では、storeWord メソッドにカスタムイベントを組み込み、そのパラメータとして渡された単語を取得したいと思います。エージェントなしでこれを行うには、独自のカスタムイベントクラスを作成し、そのクラスを関数へ発行するコードを追加し、アプリケーションを再コンパイルして再起動する必要があります。実稼働環境では、これはコストがかかり、実現しにくいでしょう。しかし、エージェントを使用すれば、最小限の介入でこれを行えます。 JDK Mission Controlを起動すると、JVMブラウザの下にエージェントプラグインが利用可能になります。図1に示すように、調査したいJVMを見つけ、エージェント・オプションを選択するだけです。エージェントのJARファイルと、読み込む対象の探査定義が記述されたオプションのXMLファイルの入力を要求されます。エージェントプラグインには、作成プロセスを導くウィザードがあり、手動でXMLを記述する必要がないため、このXMLファイルはオプションとなります。 図 1. JVMブラウザは、エージェントJARとオプションのXML構成を提供するページを提供 エージェント JAR を与えると、図 2 に示すようなエージェントプラグインの表示画面が開きます。このページには、現在有効な取得イベントと、現在有効なエージェントの構成が表示されます。 図 2. エージェントプラグインの表示画面（現在は空欄）には、設定とイベントが一覧表示 このページでは、ページ右上の保存アイコンを使って、現在有効な探査と設定を保存し、後で使用できます。また、読み込みアイコンを使って設定を読み込めます。 事前マネージャでJMCエージェントを設定する 事前設定を作成するもう一つの方法は、ウィンドウメニューの下にある事前設定マネージャを使用することです。この事前設定マネージャーでは、既存の設定から新しい事前設定を作成できるだけでなく、そのプロセスを導くためのウィザードのセットから新しい事前設定を作成できます。 事前設定マネージャーを使用するときに表示される最初のページは、図3に示すエージェントの設定オプションです。これらのオプションを使用して、生成されたイベントクラスに使用される接頭辞を定義し、さらにエージェントが toString メソッドを呼び出したりコンバータを使用したりすることを許可するかどうかを設定できます。これらは高度な機能で、メソッドパラメータ、戻り値、フィールドの取り込みを可能にします。 図 3. Edit Preset Global Configurations ページは、すべてのイベントの高度な機能の使用を制御 カスタムイベントの定義 ここから、追加したいカスタムイベントの定義を開始します。図 4 に示すように、カスタムイベントの名前と説明、およびそのイベントを組み込むクラスとメソッドを定義することから始めます。クラス名には完全修飾名を、組み込み対象のメソッドにはメソッド記述子を指定します。 図 4. 特定のイベントを設定するには、「Edit Event Configurations」ページを使用 メソッド記述子は、 (Parameter Descriptor*)Return Descriptor の形式をとります。例えば、 void storeWord(String word) というメソッドの場合、メソッド記述子は、 (Ljava/lang/String;)V となります。メソッド記述子の形式についての詳細は、JVMの仕様書を参照してください。 その他のオプションとして、スタックトレースや例外を記録するかどうか、またイベントを発生させる場所 (メソッドの先頭や最後など) を指定できます。今回は、開始位置でイベントを発行することにします。 イベントのパラメータやフィールドを取得 このページの後には、図 5 に示すように、パラメータを取得するためのウィザードと、取得したメソッドの値や取得したクラス内のフィールドを返すためのウィザードが追加されています。興味のあるパラメータを取得するには、パラメータの位置とそれが戻り値であるかどうかを指定する必要があります。この場合、最初の、そして唯一のパラメータなので、それは0番目の値を持ちます。 図5. メソッドの特定の部分へのアクセスを制御するには、「Edit a Parameter or Return Value」ページを使用 イベントの作成とパラメータやフィールドの取得が完了すると、エージェントプラグインは、図6に示すように、完成したXML構成の確認をします。完了したら、設定をターゲットJVMに読み込んで、JDK Mission Controlを使用して、新しく作成されたイベントによるフライトレコーディングを開始できます。 図 6. Preview Preset Output ページには、あなたの仕様から自動的に生成された XML 設定が表示 事前設定が完了し、読み込まれると、図7に示すように、エージェントプラグインのステータスページにイベントと設定オプションが表示されます。 図7. エージェントプラグインのステータスページには、設定したパラメータが表示 まとめ JDK Flight Recorder、JDK Mission Control、およびJMC agentは、JVMの性能を監視および診断するための強力なツールのセットを提供します。これらのツールは、最小限の性能コストで、邪魔にならないように動作します。エージェントプラグインは、これらのツールをさらに発展させ、実稼働環境において長くてコスト高になりかねないJVMの再起動を必要とせずに、実行時に独自のフライトレコーダイベントを導入するための容易な方法を提供します。 JMCエージェントの代替品としてBytemanなどがありますが、これらはより一般的な用途に適していることが多いようです。JMCエージェントとエージェントプラグインは、JDK Flight Recorderイベントの作成と導入を目的として設計されており、これらの用途により適しています。JDK Mission Control 8.1のリリースでは、エージェントプラグインがすぐに利用できるようになり、性能監視のためにこれらの手段を活用することがこれまで以上に簡単にできるようになりました。 JMCエージェントとエージェントプラグインは、どちらもまだ発展途上にあります。これらの開発の最新情報を入手し、アイデアやフィードバックを提供するには、jmc-devメーリングリストに参加し、上流のGitHubリポジトリで開発を追跡してみてはいかがでしょうか。

OpenStackやOpenShiftなどのCloud製品を担当しているソリューションアーキテクトの輿水です。 こんなに暑くなる前のGW頃、今年の5月11日〜12日に、Red Hat Summit 2022 がハイブリッド形式で開催されました。遅くなりましたが A Red Hat OpenStack Platform roadmap セッションで今後のロードマップの話がありましたので、とっても簡単にご紹介します。 Red Hat Summit 2022 のセッションは今年の年末までオンデマンドで見ることができます。セッションを見るためには アカウントの作成が必要になります。 登録ページ 。 セッションのリンクは「 A Red Hat OpenStack Platform roadmap 」です。 30分のセッションで、内容としては、前半10分はRed Hatのハイブリッドクラウド戦略や取り組みについて説明しており、後半20分でRed Hat OpenStack Platformのロードマップの説明をしています。 前半 Red Hatが行った 2021年の顧客への調査 ではクラウド戦略としてプライベートクラウドとパブリッククラウドファーストという結果になっている OpenStackが果たす役割として、プライベートクラウドとマルチテナンシー機能を持ち、多数のオプションを提供できる基盤である ハイブリッドクラウドを採用する主なモチベーションのひとつは、ワークロードを適切なIT環境に動的に移動することができる点 コストやパフォマンス、セキュリティ、データの主権（sovererigntyと言っている）など、オンプレミスのシステムや蓄積された情報をクラウドに移行する際には、技術的、法的な課題がある プライバシーやデータの扱いに関しては国ごとに法律が異なり厳格な国もあるがRed Hatとしては広範囲をカバーし基準を満たすよう努力している OpenStackコミュニティでの、レビューやパッチの数でわかるように、オープンソースにおいても貢献している Red Hat OpenStack Platformの 今後の発表は今年後半に行われる予定 後半 「17.0 17.1 18+」の一覧表示があり、ざっくりと17.0の説明。 リリース時期は明言されてないですが、 Red Hat OpenStack Platform 17.0 17.1というのが予定されている ことがわかります。16をご検討された方はご存知だと思いますが、16には16.0 16.1 16.2のようにマイナーリリースが存在します。その中で16.0はサポート期間が半年程度でした。17に関しても、17.0というサポート期間が短いものが存在し、その後、17.1というサポート期間が長いマイナーリリースが出てくるということです。 「画面の機能一覧を貼って欲しい」と思われるかもしれませんが、Red Hat Summit 2022 に参加した人のみ、セッションを見ることができる状態なので、表をじっくり見たい方は、アカウント登録をして、ぜひオンデマンドセッションを見てください。 機能一覧はCompute,Storage,Networkingなどでカテゴライズされております。ちなみに、これは決して確定情報ではなく、あくまで予定であり、正式発表の際には削除されたりTechPreviewになったりするものもありますのでその点はご容赦ください。 Compute：ワークロードに対してより多くのオプションをもたらすような拡張、例えばAIやMLなどアクセラレーションが必要なワークロードへの対応 Storage：ストレージ機能の改善や強化。Cephとのインテグレーション等 Networking：OVN関連の機能拡張、これはOpenStackに限ったことではなくRed Hatの戦略であり、OVNに重きをおいている Day1：OpenStackのDeploymentに関するもの。OpenStack Directorの機能改善 Day2：デプロイされたOpenStack環境の保守運用に関する改善。テレメトリーもここに含まれる。 Upgrades：OpenStackのアップグレードの仕組みの強化、アップデートの改善 Security： NFV：OVS-DPDK関連 Edge：エッジサイトにおけるのimageサービスやストレージ機能の増強 Shift on Stack：OpenShift on OpenStackに関連する機能改善 High Availability：主にコントローラーでのRabbitMQやMariaDBに関する改善、将来的な視野にはDisaster Recoveryもあり。 Scale：OpenStackの1クラスタあたり750ノード程度、Shift on Stackでは300ノードくらいを考慮 アップグレード 多くの方の関心事は、このアップグレードではないかと。 RHOSP16では、RHOSP16全体としてはロングライフですが、16.0はサポート期間が短いものでした。RHOSP17に関しても同様になります。17.0はサポート期間が短いため、この環境ではワークロードのテストや開発、3rdPartyプラグインの認定作業を行っていただき、アップデートして、17.1を利用するのが良いです。 現在16をお使いの方がアップグレードする場合、 サポートされるのは16.2から17.1へのアップグレード の予定です。ユーザーが、環境をアップグレードする際に懸念するのが、RHOSPをアップグレードする際に、RHELバージョンのアップグレードを伴いノードの再起動が必要になることです。また、何らかの理由でロールバックする可能性を考える必要もあります。大規模なクラウド環境では、すべてのノード（Compute Node）を同時じタイミング（同じメンテナンスウィンドウ）で再起動することは難しい場合があります。これに対応するために、RHOSPのコンポーネントのみを17にアップグレードし、同時にはノード再起動は行わない方法を考えています。ノード再起動は別のメンテナンスウィンドウで順次実施します。この場合、RHEL8.4のCompute NodeとRHEL9のCompute Nodeが混在している状態で、RHOSP17が稼働することになります。このような混在状態は、13→16の時はサポート例外としていたものを、サポートすることを考えています。これによって、初めにController Nodeと数台のCompute Nodeのアップグレードを行い、メンテナンスウィンドウを調整し、Compute Nodeを分けて再起動することができ、リスク回避も可能になると考えます。 OSP Director Operator AWSやAzureなどのパブリッククラウド上にOpenShift環境を構築するのと同様に、プライベートクラウドであるOpenStack上でOpenShiftを稼働させる「OpenShift on OpenStack」はRHOSP13の頃からありましたが、このOSP Director Operatorというものは、この逆で、OpenShiftでOpenStackを扱おうとするものです。16.2ではテクノロジープレビューだったものが、17では正式サポートになる模様です。 OpenShift Container Platform を使っている方には馴染みがあると思いますが、Operatorはプラットフォームを構成する部分の管理から、マネージドサービスとして提供されるアプリケーションに至るまで、スタックのあらゆるレベルで自動化を提供するものです。 Red Hat OpenStackをインストールする際にOpenStack Directorを使用しますが、その仕組をOperetorにしたというところです。 Controller Nodeは仮想化され、OpenShift Virtualization上に仮想マシンとして作成されます。 また、Compute Nodeは、仮想化はできないので、OpenShiftのベアメタル管理（Metal3）を使用して、デプロイします。RHOSPサービスの基礎となるネットワークも設定します。 実際にOSP Director OperatorをOpenShift環境にインストールすると以下の図のようになります。事前にOperator HubからOpenShift VirtualizationやSR-IOVネットワーク Operatorもインストールしてます。 OpenStack環境を構築するには、この後、従来のDirectorでも書いていたようなyamlをいろいろ書く必要があるわけで、即・簡単です、とは言いえませんが、ocコマンド等でOpenShiftのコンテナを操作するのと同じような感覚で、OpenStackを操作できるのは大きなメリットだと感じます。 また、OpenStack Controllerの仮想化のサポートはこれまではvirtual control plane on RHV（Red Hat Virtualization）一択でしたが、このRHVのEOLが2026年8月31日と発表されているので、今後のOpenShift Virtualizationの動向はお伝えしていければ、と思います。 また、明日から下期ということで、そう遠くないうちにRHOSP17がリリースされたら、ご紹介する予定です。

こんにちは、ISVパートナー担当SAの森須です。 今回は新しいコンテナ認定ツールPreflightについてご紹介します。 ツールの説明に入る前にRed Hatが提供する技術認定について簡単に説明しておきます。 プラットフォームに関連するソフトウェア技術認定として Red Hat Enterprise Linux software certification 、 Red Hat Container Certification 、 Red Hat OpenShift Certification 、 Red Hat OpenStack Platform Certification が提供されており、技術認定を取得することでISVパートナーは下記のベネフィットを得ることができます。 ISVパートナー様、ISVパートナー候補の皆様ぜひRed Hatの技術認定取得のご検討頂けますと幸いです。 一度構築すれば、ベアメタル、仮想化、パブリックおよびプライベートのクラウドインフラストラクチャ全体に展開でき、可搬性の高い製品を提供することができます。 Red Hatの専門知識を新しい製品開発で活用して、リスクを低減しながらイノベーションに時間をかけることができます。 Red HatとTSANet上での共同サポート体制を構築することにより、顧客からの信頼を高めることができます。 Red Hatエコシステムカタログ への掲載とプロモーションを通じて、市場での認知向上と顧客の需要を掘り起こすことが出来ます。 それでは本題に入ります。 今回ご紹介する Preflightは主にRed Hat Container CertificationとRed Hat OpenShift Certificationの取得プロセスの中で使用されるセルフテストツール となります。 先ずはなぜ新しいツールが開発されたのか？何が変わったのか？について説明します。 What’s new? パートナーエクスペリエンスを向上させるために、2022年4月25日に従来の認定スキャンシステムはPreflightに置き換わります。 Preflightをダウンロードし、お持ちのコンピューターで認定テストを実行できます。必要なのは、Red Hat Enterprise Linux（RHEL）オペレーティングシステムと、認証するコンテナイメージへのアクセスだけです。新しいツールを使用すると、最終的な認証スキャンのためにイメージをRed Hatに送信する前に、コンテナーテストを実行し結果を確認することができます。また、事前に既知のセキュリティの脆弱性についてイメージをチェックすることが出来ます。 自分のデバイスでコンテナテストを実施する主な利点の1つは、結果をリアルタイムで確認できることです。結果をRed Hatに正式に送信する前に、イメージを修正または変更することが容易になります。これにより、時間、およびリソースが節約され、効率的に認定テストプロセスを進めることが出来ます。 CI / CD（継続的インテグレーション、配信、および展開）ワークフローに認定テストを統合することが可能になります。この統合を構築にするために、Preflightを使用すると、独自の環境でコンテナーをテストでき、認証パイプラインとテストの可視性と制御が向上します。  次は、 Preflightを実行するための環境と準備 についてです。 テスト対象のコンテナイメージをアップロードするためのコンテナレジストリ（Quay.ioなど） RedHatのコンテナイメージ要件 Podmanを使用可能なRedHatEnterpriseLinux環境  RHELを入手 PartnerConnectオンラインポータル のアカウントおよびコンテナイメージ認定プロジェクトの作成 公式の認定ドキュメント にある要件と手順の理解 次は、 インストール です。 インストールする前にpreflightに必要な下記ソフトウェアがインストール済みでパスが通っていることを確認してください。 v1.14.0以降のOperatorSDK v4.7.19以降のOpenShiftクライアント 確認が取れましたら、 各アーキテクチャごとにビルド済みのバイナリ が用意されていますので、ダウンロードしてパスが通った場所へコピーしてください。 インストールは以上で完了です。 次に、 コンテナイメージを作成してpreflightで確認 してみます。 以下がpreflightでのテストとその準備の流れになります。 podman loginコマンドでコンテナリポジトリにログイン 作業ディレクトリを作成し、ディレクトリ内にDockerfileとライセンスファイルを作成 作業ディレクトリ内でpodman buildコマンド実行しUBIをベースイメージとしたコンテナイメージをビルド podman push コマンドでコンテナイメージを指定したコンテナリポジトリへアップロード preflight check container コマンドで指定したコンテナリポジトリからイメージを取得してテストを実行 以下は上記で説明したコマンドの実行例です # podman login quay.io/preflight-test 作業ディレクトリを作成し、ディレクトリ内にDockerfileとライセンスファイルを作成。 空ファイルでライセンスファイルを作るとテストをパスできないので注意してください。 ディレクトリ構成例 作成したDockerfileの例 FROM registry.access.redhat.com/ubi8/ubi:latest RUN useradd preflightuser COPY --chown=preflightuser:preflightuser example-license.txt /licenses/ LABEL name="preflight test image" \ vendor="preflight test vendor" \ version="1" \ release="1" \ summary="testing the preflight tool" \ description="test the preflight tool" USER preflightuser # podman build -t quay.io/preflight-test/test-ubi:test02 . # podman push quay.io/preflight-test/test-ubi:test02 # preflight check container quay.io/preflight-test/test-ubi:test02 テストをパスするとこのようなメッセージが表示されます。 最後にPreflightで テストされる項目 について説明します。 LayerCountAcceptable コンテナイメージの階層が40レイヤー未満であることを確認します。 階層数はpodman historyコマンドで確認できます。 HasNoProhibitedPackages コンテナイメージにRHELカーネルパッケージが含まれていないことを確認します。 HasRequiredLabel コンテナイメージに指定されたラベルが設定されていることを確認します。 設定方法についてはDockerfileの例を参考にしてください。 RunAsNonRoot コンテナーがrootユーザーとして実行されていないことを確認します。 BasedOnUbi UBI がベースイメージとして使用されていることを確認します。 HasModifiedFiles コンフィグファイルなど変更が認められているもの以外が変更されていないことを確認します。 HasLicense コンテナイメージに「ライセンス」ディレクトリが含まれていることを確認します。 設定方法についてはDockerfileの例を参考にしてください。 HasUniqueTag コンテナイメージには「latest」以外のタグが付いていることを確認します。 今回はここまでとなります。 次回はPreflightでオペレーターバンドルをチェックする方法を説明します。

  本日の記事はOpenShiftのマネージドサービスのひとつであるRed Hat OpenShift Service on AWS(ROSA)を、レッドハットが提供するRed Hat Hybrid Cloud Console(いわゆるWebコンソール)からウィザード形式でクラスタをデプロイする手法をご紹介します。 ROSAはクラウドサービスです、本記事は2022年6月29日現在の状態で検証した内容となっており、その後サービス提供内容が変化している可能性が御座います。 ・以前から提供されているROSAとの違い ・HCCからROSAをデプロイする手順の紹介   はじめに ROSAをデプロイする前に行っておくこと STS with ROSAのAWSの前提条件を確認し、設定します。 利用可能なAWSクォータがあることを確認します AWSコンソールでROSAを有効化します。 ワークステーションに最新のAWS、ROSA、oc CLIをインストールし、設定する 初回だけ：AWS IAMロールとレッドハットアカウントの連携 ROSAをWebコンソールからデプロイ クラスタ設定 詳細 マシンプール ネットワーキング コンフィグレーション VPC設定 Cluster-wideプロキシ CIDRレンジ クラスタロール＆ポリシー クラスタアップデート レビュー まとめ   はじめに 田舎の高地で育った暑さに苦手なクラウドインフラ全般を担当しているソリューションアーキテクトの伊藤です。最近の太陽と高気圧のコンビに対抗するには夜行性になる事くらいしか無いのではないかと考えています。＃現在JST AM2時です。 本日は2022/6/28に新しいROSAのUXとして紹介が行われたレッドハットが提供するWebコンソールからROSAクラスタをデプロイする方法を日本語で紹介したいと思います。   cloud.redhat.com   昨年春よりROSAは、セルフサービスでデプロイを開始することが出来るOpenShiftのマネージドサービスとしてレッドハットが提供を行ってきました。 先日までROSAをデプロイしようと思った場合は、ターミナル画面からデプロイを行う必要がありました。 しかしながら、デプロイをする度にターミナル画面を開いて作業を行っていくのは面倒で、もっともっと簡易にWebからデプロイを行いたいというニーズがありました。 本日の内容はROSAのデプロイ作業をWebから行えるという機能の紹介になります。 #ただし、お手持ちのAWSアカウントとレッドハットアカウントの連携が必要なので、ターミナルからAWS IAM ARNを関連付ける作業が初回1回だけ必要です。   ROSAをデプロイする前に行っておくこと さて、どんな環境からであれ、ROSAをデプロイする前に行っておくことは以下の4つです。 ＃過去STSモードでROSAデプロイをしたことがない場合は、再度ご確認されることを推奨します。 STS with ROSAのAWSの前提条件を確認し、設定します。 利用可能なAWSクォータがあることを確認します。 AWSコンソールでROSAを有効化します。 ワークステーションに最新のAWS、ROSA、oc CLIをインストールし、設定する（推奨） STS with ROSAのAWSの前提条件を確認し、設定します。 第1章 STS を使用した ROSA の AWS 前提条件 Red Hat OpenShift Service on AWS 4 | Red Hat Customer Portal AWSアカウントとレッドハットアカウントの関連付け レッドハットがAWSアカウントにアクセスするための要件 レッドハットがAWSアカウントをサポートするための要件 セキュリティ要件 上記のURLにある章1.1 から 章1.2.7 までを確認します。 利用可能なAWSクォータがあることを確認します 1.2. デプロイメントに STS を使用する場合のカスタマー要件 Red Hat OpenShift Service on AWS 4 | Red Hat Customer Portal 今回利用するAWSアカウントに十分なAWSサービスクオータが設定されていることを確認します。必要なクオータコードは以下のURLに記載されています。 第5章 必要な AWS サービスクォータ Red Hat OpenShift Service on AWS 4 | Red Hat Customer Portal AWSコンソールでROSAを有効化します。 https://ap-northeast-1.console.aws.amazon.com/rosa/home?region=ap-northeast-1#/ 上記のAWSマネージメントコンソールにアクセスして、今回ROSAをデプロイするAWSアカウント上でRed Hat OpenShiftサブスクリプションを有効にしていることを確認します。 ワークステーションに最新のAWS、ROSA、oc CLIをインストールし、設定する 以下の3つのCLIを最新版にしてインストールします。 AWS CLI https://aws.amazon.com/jp/cli/ ROSA CLI https://console.redhat.com/openshift/downloads#tool-rosa OpenShift CLI https://console.redhat.com/openshift/downloads#tool-oc 初回だけ：AWS IAMロールとレッドハットアカウントの連携 さて、デプロイ前に行う作業を終えたら早速WebからROSAをデプロイしたいところですが、唯一ターミナルで作業を行う事があります。 各CLIツールを使用して、AWS IAM ARNとレッドハットアカウントと連携する作業です。 STS with ROSAの前提条件を達成する作業の中で予め行った方もいらっしゃると思いますので、以下のURLにアクセスをして現在の連携状態を確認しておきましょう。 https://console.redhat.com/openshift/create/rosa/wizard   ウィザードの中で以下の画像のように各IAM ARNが記載されていれば既にAWSアカウントとの連携が完了しています。 通常はまだAWSアカウントとの連携が完了していないので、空白になっていると思います。 空白になっていれば、Associated AWS accountのリストボックスを開きます。 Associate AWS account という青文字のボタンが表示されていますのでクリックしましょう。 クリックをすると、Link your AWS account to your Red Hat account.という画面になります。 ここではターミナルを使って作業を行っていきます。 docs.openshift.com ROSAコマンドでターミナルでレッドハットアカウントの認証をする ROSAコマンドでOCM(Webコンソールで使う) のIAM ARNを作成する ROSAコマンドでUser(デプロイで使う) のIAM ARNを作成する 以下のようなWebコンソール画面になったと思います。 アカウントロールを作成します。 ターミナルでコマンドを打ったら、ブラウザに戻ってきて何度かRefresh ARNsをクリックしてみましょう。 おめでとうございます！アカウントロールが作成され次に進めるようになりました。 以上でIAM ARNの設定が完了しました。後はすべてWebコンソールからパラメータを入力してROSAクラスタをご自身のAWSアカウント上にデプロイするだけです！   ちなみに、ターミナルを打つ前に今回のAWSアカウントが作業対象であることか確認を行いましたか？ $ aws sts get-caller-identity などのコマンドを使って意図したAWSアカウントを利用しているか必ず確認をしましょう。   今回例で作成したIAMロールはAdmin属性が付いたものを作成しますが、企業内ポリシーなどで任意のIAMポリシーを作成して付与する場合は以下のURLを読んで適合するポリシーをマニュアルで作成することもできます。 ROSAをWebコンソールからデプロイ これからは全てWebコンソール上で作業を行います。 スクリーンショットでBlog Entryを埋めるのではなく、各パラメータを文字でご紹介します。 クラスタ設定 詳細 クラスタ名 バージョン リージョン 可用性の選択 シングルAZ か マルチAZ ユーザ領域のモニタリングの選択 ETCDの暗号化 PV暗号化のためのAWS KMS ARNの指定 マシンプール ワーカーノードのインスタンスタイプ指定 マシンプールのオートスケール有効化 初期ノード数の指定 ノードラベルの指定 ネットワーキング コンフィグレーション 初期にインターネットからアクセスを許可するかPublic / Private 既存のVPCにROSAクラスタをデプロイするか cluster-wideプロキシを使うか(エアギャップ環境か) VPC設定 既存のVPCにデプロイする場合、サブネットIDを指定します Cluster-wideプロキシ プロキシを利用する場合はプロキシのコンフィグを設定します CIDRレンジ 任意のCIDRレンジを割り当てたい場合は指定をします クラスタロール＆ポリシー OIDCプロバイダを使って利用するロールを制御する場合は設定します クラスタアップデート ROSAクラスタのアップデートタイミングを指定します。 任意のタイミングアップデート / 自動アップデート レビュー この画面では設定したコンフィグレーションが1画面に出力されるので問題なければCreate Clusterをクリックしましょう！ クラスタのデプロイが開始されるとAWS上で各種リソースの作成が始まります。途中からクラスタインストールのログも確認できるようになります。   クラスタのデプロイが完了すると、レッドハットのHCC WebコンソールからOpenShiftのWebコンソールを開くことができる画面が出てきます。（Open console) 以上でROSAクラスタを利用することができるようになりました。 まとめ まだかまだかと待っていた機能で、実際に利用可能になると本当に好きなタイミングでOpenShiftクラスタを任意の構成でデプロイできることが確認できました。   ターミナルを利用せずともどんどんクラスタを増やすことができるようになったので自分のOpenShiftクラスタを今まで以上に増やしていきたいと思います。          

こんにちは。Red Hatでソリューションアーキテクトをしている杉本 拓です。 今回は先日リリースされたOpenShift API Management Developer Sandboxについて、 Red Hat Developer のブログ記事 Experiment with the OpenShift API Management Developer Sandbox の翻訳を通じて紹介したいと思います。このOpenShift API Management Developer Sandboxを利用するとOpenShift API ManagementのAPI管理機能とOpenShiftでのブラウザベースでの開発環境を無料で試すことができるようになります。 Red Hat OpenShift API Management は、開発者がクラウドネイティブなアプリケーションの更新、デプロイ、スケールを容易にできるようにするためのホスティングされたマネージドサービスです。OpenShift API Management は、Red HatのManaged OpenShift クラウドへのアドオン製品です。 最近まで、OpenShift API Management を試すには、 Red Hat OpenShift Dedicated または Red Hat OpenShift Service on AWS にアクセスする必要がありました。しかし現在、Red Hat OpenShift API ManagementがDeveloper Sandbox 環境で利用できるようになったことをお伝えすることができ、とても嬉しく思っています。この記事では、 SandboxでのOpenShift API Managementの使い方 について、ご紹介していきます。 サンプルアプリケーションの起動 OpenShift API Managementを利用することで、大規模なデプロイ環境であったとしても自社でそのインフラの運用管理をすることなく、API管理を行うことができるようになります。さらに、OpenShift API Management はマネージドの Red Hat OpenShift とネイティブに統合され、効率的な開発者エクスペリエンスを提供しており、API ファーストのアプローチでマイクロサービスベースのアプリケーションを開発、管理、セキュリティ保護、スケーリングすることが可能です。ダッシュボード画面からは、ツールのダウンロードや API の管理を簡単に行うことができます 。 Sandboxのユースケース では、Quarkus のサンプルアプリケーションを OpenShift にデプロイし、サービスディスカバリーの機能を使用してアプリケーションを Red Hat 3scale API Management にインポートし、API キーによる認証を使用して API を保護するプロセスを説明しています。 コンテナ化されたアプリケーションのデプロイ コンテナ化 されたアプリケーションには、ポータビリティ、セキュリティの向上、さらに迅速なデリバリなど、開発者にとって多くの利点があります。 Sandboxのユースケース では、OpenShift API Management Developer Sandbox環境を使用して、どのようにコンテナ化されたアプリケーションを構築していくかが紹介されています。このユースケースに記載されている手順を実行することで、QuarkusアプリケーションをOpenShiftにデプロイし、そのアプリケーションを簡単に検出してAPI管理できるようにするための設定方法についても学ぶことができます。図 2 は、開発者が どのようにサービスに関する詳細設定情報を追加して、OpenShift API Management 内でアプリケーションが検出できるようにするための方法を示しています。 図2: トポロジービューでAPIのサービス詳細設定の表示・変更が可能 API キーによるセキュリティの有効化 API キーは、アプリケーションを識別するための簡単な方法であり、プロジェクト業務としてAPI リクエストを課金などに紐付ける際にも役に立ちます。OpenShift API Management Developer Sandbox の環境では、APIキーを使用してAPIcasatインスタンスというプロキシを経由してAPIリクエストをルーティングすることができます。APIcast インスタンスを使用すると、内部APIと外部APIの両方のサービスを Red Hat OpenShift API Management で統合的に管理することが容易に実現できます。APIcastでは、API のセキュリティルールとポリシーが適用されます。また、 アプリケーションプラン （図3）を通じて、リソースの使用やその他の API の詳細を制御することができます。 図 3: アプリケーションプランではAPI を使用する際のリソースに対するアクセス可否などを決定 さらに、このSandbox環境ではシングルサインオンの機能を追加することが可能となっており、APIのセキュリティをより高いレベルに引き上げることができます。このトピックに関する今後の記事にご期待ください。 まとめ Red Hat OpenShift API Management の 概要サイト で詳細を確認し、OpenShift API Management Developer Sandbox を今すぐ試してみてください。また、 Red Hat Developer に戻って OpenShift API Management の使用方法に関するより詳細な記事とラーニングパスを参照することも忘れないでください。

こんにちは、ソリューションアーキテクトの蒸野（ムシノ）です。 これまで Apache Camel や Red Hat Fuse のご紹介をしてきました。 今回は本シリーズ最後となります、Apache Camelをベースとした製品ファミリの「Camel Extensions for Quarkus」と「Camel K」をご紹介したいと思います。 前回までの振り返り rheb.hatenablog.com rheb.hatenablog.com Apache Camel 製品ファミリ Apache Camel はいくつかのサブプロジェクトに別れています。Red Hat ではこのサブプロジェクトに合せて Apache Camel 製品ファミリを構成しています。前回ご紹介した 「Fuse」も同製品ファミリに含まれており、現時点では「Fuse」「Camel Extensions for Quarkus」「Camel K」といった3製品を提供しています。 いくつかある製品ですが、大きな特徴として Apahe Camel 2 ベースとしているか、Apache Camel 3 ベースであるかといった違いがあります。その他には「Camel Extensions for Quarkus」ではスタンドアローン構成をとれますが、「Camel K」ではOpenShift上でしか動作させることができないといった制限があります。 それぞれ特徴と強みがありますので、個々にご紹介していきたいと思います。 Apache Camel 3 とは？ 今回紹介する「Camel Extensions for Quarkus」と「Camel K」は、Apache Camel 3をベースにした製品になります。Apache Camel 3 については下記の記事に詳細が記載されていますので、こちらをご覧いただければと思います。 rheb.hatenablog.com rheb.hatenablog.com Camel Extensions for Quarkus まず最初に「Camel Extensions for Quarkus」を紹介したいと思います。 Apache Camel では次のように説明されています。 「APACHE CAMEL EXTENSIONS FOR QUARKUS」プロジェクトは Apache Camel とその膨大なコンポーネントライブラリの統合機能を、Quarkusランタイムにもたらすことを目的としています。これにより、ユーザーはQuarkusが提供するパフォーマンスの利点、developer joy、コンテナファーストの理念を利用することができます。 製品ガイドでは、「Camel Extensions for Quarkus は、Apache Camel とその vast コンポーネントライブラリーの統合機能を Quarkus ランタイムに提供します。」とあります。同じような説明は省くとして、Apache Camel コンポーネントにも Quarkus エクステンションを提供している点や、Camel 3 でパフォーマンスが向上している点、メモリーフットプリントが少なくなり高速に動作し、かつ起動時間が短縮されるといった点がメリットと言えるでしょう。また、Camel Extensions for Quarkusでは、Red Hat Enterprise Linux 上でも、OpenShift 上でも動作させることができます。 access.redhat.com Camel Extensions for Quarkus の始め方 それでは最初の一歩として、製品ガイドにある「 Camel Extensions for Quarkus を使用した最初のプロジェクトのビルド 」 をやってみたいと思います。 1.スケルトンアプリケーションの生成 まずはスケルトンアプリケーションを取得するために、下記にアクセスして頂きます。 https://code.quarkus.redhat.com/ 下記のような画面が表示されるかと思います。 2. Extensions を選択 次に、下記2つの Extensions を選択します。 camel-quarkus-rest camel-quarkus-jackson それぞれ、Extensions の Filters で検索し、チェックボックスにチェックを入れます。 Extensions を2つとも選択できたら右のメニューからスケルトンアプリケーションをダウンロードします。 3. スケルトンアプリケーションの確認 任意の場所でダウンロードしたZIPファイルを解凍します。 スケルトンアプリケーションのディレクトリは次にようになっているかと思います。 ❯ ls README.md mvnw* mvnw.cmd* pom.xml src/ 4. Camel ルートを追加する 簡単な Camel ルートを追加してみたいと思います。 src/main/java/org/acme 以下に Routes.java という名前で作成します。 ❯ cd code-with-quarkus/src/main/java/org/acme ❯ vi Routes.java Routes.java は次のようにシンプルなコードとなっています。これを追加します。 package org.acme; import java.util.Arrays; import java.util.List; import java.util.Objects; import java.util.concurrent.CopyOnWriteArrayList; import org.apache.camel.builder.RouteBuilder; import org.apache.camel.model.rest.RestBindingMode; import io.quarkus.runtime.annotations.RegisterForReflection; public class Routes extends RouteBuilder { private final List<Fruit> fruits = new CopyOnWriteArrayList<>(Arrays.asList( new Fruit( "Apple" ))); @Override public void configure() throws Exception { restConfiguration().bindingMode(RestBindingMode.json); rest( "/fruits" ) .get() .route() .setBody(e -> fruits) .endRest() .post() .type(Fruit. class ) .route() .process().body(Fruit. class , (Fruit f) -> fruits.add(f)) .endRest(); } @RegisterForReflection // Let Quarkus register this class for reflection during the native build public static class Fruit { private String name; public Fruit() { } public Fruit(String name) { this .name = name; } public String getName() { return name; } public void setName(String name) { this .name = name; } @Override public int hashCode() { return Objects.hash(name); } @Override public boolean equals(Object obj) { if ( this == obj) return true ; if (obj == null ) return false ; if (getClass() != obj.getClass()) return false ; Fruit other = (Fruit) obj; return Objects.equals(name, other.name); } } } 5. 開発者モードでの実行 それでは一度、開発者モードで実行してみたいと思います。 最初の起動はライブラリなどをダウンロードするので数分待ちますが、次回からは数秒で起動します。 ❯ mvn clean compile quarkus:dev ・・・（省略） __ ____ __ _____ ___ __ ____ ______ --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ -/ /_/ / /_/ / __ |/ , _/ , < / /_/ /\ \ --\___\_\____/_/ |_/_/|_/_/|_|\____/___/ 2022-06-23 19:01:40, 541 INFO [ org.apa.cam.qua.cor.CamelBootstrapRecorder ] ( Quarkus Main Thread ) Bootstrap runtime: org.apache.camel.quarkus.main.CamelMainRuntime 2022-06-23 19:01:40, 730 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( Quarkus Main Thread ) Routes startup ( total:2 started:2 ) 2022-06-23 19:01:40, 730 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( Quarkus Main Thread ) Started route1 ( rest://get:/fruits ) 2022-06-23 19:01:40, 731 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( Quarkus Main Thread ) Started route2 ( rest://post:/fruits ) 2022-06-23 19:01:40, 731 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( Quarkus Main Thread ) Apache Camel 3 . 14 . 1 ( camel-1 ) started in 132ms ( build:0ms init:82ms start:50ms ) 2022-06-23 19:01:40, 848 INFO [ io.quarkus ] ( Quarkus Main Thread ) code-with-quarkus 1 . 0 .0-SNAPSHOT on JVM ( powered by Quarkus 2 . 7 . 5 .Final-redhat-00011 ) started in 2 .043s. Listening on: http://localhost:8080 2022-06-23 19:01:40, 850 INFO [ io.quarkus ] ( Quarkus Main Thread ) Profile dev activated. Live Coding activated. 2022-06-23 19:01:40, 850 INFO [ io.quarkus ] ( Quarkus Main Thread ) Installed features: [ camel-attachments, camel-core, camel-jackson, camel-platform-http, camel-rest, cdi, resteasy, smallrye-context-propagation, vertx ] -- Tests paused Press [ r ] to resume testing, [ o ] Toggle test output, [ : ] for the terminal, [ h ] for more options > 6. 実行結果の確認 Curlにて動作確認を行います。下記のように「Apple」と表示されていれば正常にインテグレーションができています。 ❯ curl http://localhost:8080/fruits [ { " name " : " Apple " } ] 7. インテグレーションアプリケーションのパッケージング MVNコマンドでカスタマイズしたスケルトンアプリケーションをパッケージングします。 ❯ mvn -DskipTests =true clean package [ INFO ] Scanning for projects... [ INFO ] [ INFO ] ---------------------< org.acme:code-with-quarkus > ------------------- -- [ INFO ] Building code-with-quarkus 1 . 0 .0-SNAPSHOT [ INFO ] --------------------------------[ jar ] ------------------------------- -- [ INFO ] [ INFO ] --- maven-clean-plugin:2.5:clean ( default-clean ) @ code-with-quarkus --- [ INFO ] Deleting /////camel-extension-for-quarkus/code-with-quarkus/target [ INFO ] [ INFO ] --- maven-resources-plugin:2.6:resources ( default-resources ) @ code-with-quarkus --- [ INFO ] Using ' UTF-8 ' encoding to copy filtered resources. [ INFO ] Copying 2 resources [ INFO ] [ INFO ] --- quarkus-maven-plugin:2. 7 . 5 .Final-redhat-00011:generate-code ( default ) @ code-with-quarkus --- [ INFO ] [ INFO ] --- maven-compiler-plugin:3. 8 .1:compile ( default-compile ) @ code-with-quarkus --- [ INFO ] Changes detected - recompiling the module ! [ INFO ] Compiling 2 source files to /////camel-extension-for-quarkus/code-with-quarkus/target/classes [ INFO ] [ INFO ] --- quarkus-maven-plugin:2. 7 . 5 .Final-redhat-00011:generate-code-tests ( default ) @ code-with-quarkus --- [ INFO ] [ INFO ] --- maven-resources-plugin:2.6:testResources ( default-testResources ) @ code-with-quarkus --- [ INFO ] Using ' UTF-8 ' encoding to copy filtered resources. [ INFO ] skip non existing resourceDirectory /////camel-extension-for-quarkus/code-with-quarkus/src/ test /resources [ INFO ] [ INFO ] --- maven-compiler-plugin:3. 8 .1:testCompile ( default-testCompile ) @ code-with-quarkus --- [ INFO ] Changes detected - recompiling the module ! [ INFO ] Compiling 4 source files to /////camel-extension-for-quarkus/code-with-quarkus/target/test-classes [ INFO ] [ INFO ] --- maven-surefire-plugin:3. 0 .0-M5:test ( default-test ) @ code-with-quarkus --- [ INFO ] Tests are skipped. [ INFO ] [ INFO ] --- maven-jar-plugin:2.4:jar ( default-jar ) @ code-with-quarkus --- [ INFO ] Building jar: /////camel-extension-for-quarkus/code-with-quarkus/target/code-with-quarkus -1 . 0 .0-SNAPSHOT.jar [ INFO ] [ INFO ] --- quarkus-maven-plugin:2. 7 . 5 .Final-redhat-00011:build ( default ) @ code-with-quarkus --- [ INFO ] [ io.quarkus.deployment.QuarkusAugmentor ] Quarkus augmentation completed in 1728ms [ INFO ] ------------------------------------------------------------------------ [ INFO ] BUILD SUCCESS [ INFO ] ------------------------------------------------------------------------ [ INFO ] Total time: 8 . 271 s [ INFO ] Finished at: 2022-06-23T19:18:41+09:00 [ INFO ] ------------------------------------------------------------------------ target/quarkus-appディレクトリ配下に「 quarkus-run.jar 」が作成されています。 これを実行します。 ❯ java -jar quarkus-run.jar __ ____ __ _____ ___ __ ____ ______ --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \ --\___\_\____/_/ |_/_/|_/_/|_|\____/___/ 2022-06-23 19:33:09,192 INFO [org.apa.cam.qua.cor.CamelBootstrapRecorder] (main) Bootstrap runtime: org.apache.camel.quarkus.main.CamelMainRuntime 2022-06-23 19:33:09,588 INFO [org.apa.cam.imp.eng.AbstractCamelContext] (main) Routes startup (total:2 started:2) 2022-06-23 19:33:09,589 INFO [org.apa.cam.imp.eng.AbstractCamelContext] (main) Started route1 (rest://get:/fruits) 2022-06-23 19:33:09,589 INFO [org.apa.cam.imp.eng.AbstractCamelContext] (main) Started route2 (rest://post:/fruits) 2022-06-23 19:33:09,589 INFO [org.apa.cam.imp.eng.AbstractCamelContext] (main) Apache Camel 3.14.1 (camel-1) started in 269ms (build:0ms init:115ms start:154ms) 2022-06-23 19:33:09,767 INFO [io.quarkus] (main) code-with-quarkus 1.0.0-SNAPSHOT on JVM (powered by Quarkus 2.7.5.Final-redhat-00011) started in 1.899s. Listening on: http://0.0.0.0:8080 2022-06-23 19:33:09,767 INFO [io.quarkus] (main) Profile prod activated. 2022-06-23 19:33:09,768 INFO [io.quarkus] (main) Installed features: [camel-attachments, camel-core, camel-jackson, camel-platform-http, camel-rest, cdi, resteasy, smallrye-context-propagation, vertx] 実行環境によりますが、1秒〜数秒ほどで起動します。高速に起動・動作することを実感してもらえるかと思います。 8. 実行結果の確認 もう一度先程と同様で、Curlにて動作確認を行います。 ❯ curl http://localhost:8080/fruits [ { " name " : " Apple " } ] Camel K 次に、「Camel K」を紹介したいと思います。 Apache Camel では次のように説明されています。 Apache Camel Kは、Kubernetes上でネイティブに動作するApache Camelをベースにした軽量な統合フレームワークで、特にサーバーレスやマイクロサービスアーキテクチャのために設計されています。Camel DSLで書かれた統合コードをクラウド上で実行することができます。 製品ガイドでは、「Red Hat Integration - Camel Kは、OpenShift上でネイティブに動作するApache Camel K からビルドされる軽量のインテグレーションフレームワークです。」と説明しています。ここでも同じような説明は省いて少し補足します。Camel K はgo言語 で実装されサーバーレスおよびマイクロサービスアーキテクチャー向けに設計されています。また、Kubernetes Operator を使用して OpenShift にデプロイでき、起動時間はかなり早く、数秒以内でサービスが立ち上がることで軽量なインテグレーションフレームワークとして利用することができます。 access.redhat.com Camel K については下記記事でも詳細に説明がなされています。是非ご覧いただけたらと思います。 rheb.hatenablog.com Camel K の始め方 事前準備 それでは最初の一歩として、製品ガイドにある、「 基本的な Camel K Java インテグレーションのデプロイ 」をやってみたいと思います。 しかしその前に Camel K ではいくつか準備が必要になります。 まず、Camel K はOpenShift上でしか動作しません。そのため、動作させるためにまずはOpenShift環境を準備する必要があります。 Redhat オンラインLAB（OPEN）環境で試したいと思います。 オンラインLAB（OPENTLC） 利用方法については下記記事をご覧ください。 レッドハットのパートナー【5】Red Hat OPEN に関する説明と利用手順 その2 - 赤帽エンジニアブログ 次にシンプルなCamel K のサンプルを実行させる為、デプロイ等を行うための OpenShift CLI、CamelK CLIが必要になります。そのため、下記URLを参考にそれぞれCLIをインストールします。 2.3. Camel K および OpenShift コマンドラインツールのインストール Red Hat Integration 2021.q1 | Red Hat Customer Portal それでは、ようやく準備が整いましたので、Camel K を実行してみたいと思います。 1.Gitリポジトリのクローン シンプルなサンプルアプリケーションを入手するため、Gitリポジトリからサンプルコードを入手します。 git clone https://github.com/openshift-integration/camel-k-example-basic.git 2.CLI環境の確認 次に事前準備で行ったCLIコマンドの確認を行います。ここで問題があると次に進めない為、コマンドが実行できない場合には事前準備を参考に再インストールを行います。 ❯ oc OpenShift Client This client helps you develop, build, deploy, and run your applications on any OpenShift or Kubernetes cluster. It also includes the administrative commands for managing a cluster under the ' adm ' subcommand. To familiarize yourself with OpenShift, login to your cluster and try creating a sample application: oc login mycluster.mycompany.com oc new-project my-example oc new-app django-psql-example oc logs -f bc/django-psql-example ・・・（省略） ❯ kamel Apache Camel K is a lightweight integration platform, born on Kubernetes, with serverless superpowers. Usage: kamel [ command ] Available Commands: bind Bind Kubernetes resources, such as Kamelets, in an integration flow. Endpoints are expected in the format " [[apigroup/]version:]kind:[namespace/]name " or plain Camel URIs. completion Generate completion scripts debug Debug an integration running on Kubernetes delete Delete integrations deployed on Kubernetes describe Describe a resource dump Dump the state of namespace get Get integrations deployed on Kubernetes help Help about any command init Initialize empty Camel K files install Install Camel K on a Kubernetes cluster kamelet Configure a Kamelet kit Configure an Integration Kit local Perform integration actions locally. log Print the logs of an integration rebuild Clear the state of integrations to rebuild them reset Reset the Camel K installation run Run a integration on Kubernetes uninstall Uninstall Camel K from a Kubernetes cluster version Display client version ・・・（省略） 3.OpenShiftへプロジェクトの作成 次も事前準備に関する確認になります。事前に用意したOpenShift環境にログインを行います。 ❯ oc login -u xxxxxx -p xxxxxx ログインできたら、次は CamelK を動作させるプロジェクトを OpenShift 上に作成します。これは OpenShift のコンソール上から実施します。「 camel-basic 」というプロジェクトを作成します。 その後、作成した「camel-basic」プロジェクトに遷移します。 ❯ oc project camel-basic Now using project " camel-basic " on server " https://api.cluster-xxxxxxxxxxx.xxxxxxxxxx.opentlc.com:XXXX " . 4.Camel K オペレータの準備 Camel K オペレータをインストールするため、OpenShiftのコンソール上から 「Operator>Operator Hub」 にアクセスします。 Camelと検索項目に入力すると対象オペレータが表示されますので、「 Red Hat Integration - Camel K 」を選択します。 Operator Hub 「Red Hat Integration - Camel K 」をインストールします。インストールする項目はすべて標準のままで大丈夫です。 Red Hat Integration - Camel K Step1 Red Hat Integration - Camel K Step2 しばらくするとインストールが完了し、オペレータが利用できるようになります。 OC コマンドでもオペレータの状況を確認しておきましょう。PHASEが「 Succeeded 」となっていれば問題ありません。 ❯ oc get csv NAME DISPLAY VERSION REPLACES PHASE red-hat-camel-k-operator.v1. 6 . 7 Red Hat Integration - Camel K 1 . 6 . 7 red-hat-camel-k-operator.v1. 6 . 6 Succeeded 5.シンプルなインテグレーションの実行 シンプルなインテグレーション例として Camel K で”Hello World...”を表示させます。今回は実行ログを表示させたい為、開発者モードで実行してみたいと思います。 では早速Cloneした「camel-k-example-basic」に移動します。「camel-k-example-basic」は下記のようになっていると思います。 ❯ ls Basic.java Routing.java readme.didact.md readme.md routing.properties test / この「 Basic.java 」を実行させるため、一度コードを確認しておきます。見ていただいて分かるように「1秒ごとにHello World! を表示させる」ような非常にシンプルなコードです。 ❯ cat Basic.java // camel-k: language=java import org.apache.camel.builder.RouteBuilder; public class Basic extends RouteBuilder { @Override public void configure() throws Exception { from( "timer:java?period=1000" ) .setHeader( "example" ) .constant( "Java" ) .setBody() .simple( "Hello World! Camel K route written in ${header.example}." ) .to( "log:info" ); } } 下記のように実行します。OpenShift環境によりますが、最初は数分ほどかかる場合があります。 ❯ kamel run Basic.java --dev No IntegrationPlatform resource in camel-basic namespace Integration " basic " created Progress: integration " basic " in phase Waiting For Platform Condition " IntegrationPlatformAvailable " is " False " for Integration basic: openshift-operators/camel -k Integration " basic " in phase " Waiting For Platform " Progress: integration " basic " in phase Initialization Condition " IntegrationPlatformAvailable " is " True " for Integration basic: openshift-operators/camel -k Progress: integration " basic " in phase Building Kit Integration " basic " in phase " Initialization " Integration " basic " in phase " Building Kit " Condition " IntegrationKitAvailable " is " False " for Integration basic: creating a new integration kit Integration Kit " openshift-operators/kit-caqnhnuipnivars9ds5g " , created by Integration " basic " , changed phase to " Build Submitted " Build " openshift-operators/kit-caqnhnuipnivars9ds5g " , created by Integration " basic " , changed phase to " Scheduling " Build " openshift-operators/kit-caqnhnuipnivars9ds5g " , created by Integration " basic " , changed phase to " Pending " Build " openshift-operators/kit-caqnhnuipnivars9ds5g " , created by Integration " basic " , changed phase to " Running " Integration Kit " openshift-operators/kit-caqnhnuipnivars9ds5g " , created by Integration " basic " , changed phase to " Build Running " ・・・（省略） [ 1 ] 2022-06-24 08:53:22, 638 INFO [ org.apa.cam.k.Runtime ] ( main ) Apache Camel K Runtime 1 . 9 . 0 .fuse-800051-redhat-00001 [ 1 ] 2022-06-24 08:53:22, 733 INFO [ org.apa.cam.qua.cor.CamelBootstrapRecorder ] ( main ) Bootstrap runtime: org.apache.camel.quarkus.main.CamelMainRuntime [ 1 ] 2022-06-24 08:53:22, 924 INFO [ org.apa.cam.k.lis.SourcesConfigurer ] ( main ) Loading routes from: SourceDefinition { name = ' Basic ' , language = ' java ' , type=' source ' , location = ' file:/etc/camel/sources/Basic.java ' , } [ 1 ] 2022-06-24 08:53:25, 521 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( main ) Routes startup summary ( total:1 started:1 ) [ 1 ] 2022-06-24 08:53:25, 521 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( main ) Started route1 ( timer://java ) [ 1 ] 2022-06-24 08:53:25, 521 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( main ) Apache Camel 3 . 11 . 5 .fuse-800012-redhat-00004 ( camel-1 ) started in 382ms ( build:0ms init:294ms start:88ms ) [ 1 ] 2022-06-24 08:53:25, 524 INFO [ io.quarkus ] ( main ) camel-k-integration 1 . 6 . 7 on JVM ( powered by Quarkus 2 . 2 . 5 .Final-redhat-00010 ) started in 5 .077s. [ 1 ] 2022-06-24 08:53:25, 524 INFO [ io.quarkus ] ( main ) Profile prod activated. [ 1 ] 2022-06-24 08:53:25, 524 INFO [ io.quarkus ] ( main ) Installed features: [ camel-bean, camel-core, camel-java-joor-dsl, camel-k-core, camel-k-runtime, camel-log, camel-timer, cdi ] [ 1 ] 2022-06-24 08:53:26, 526 INFO [ info ] ( Camel ( camel-1 ) thread #0 - timer://java) Exchange[ExchangePattern: InOnly, BodyType: String, Body: Hello World! Camel K route written in Java.] [ 1 ] 2022-06-24 08:53:27, 521 INFO [info] ( Camel ( camel-1 ) thread #0 - timer://java) Exchange[ExchangePattern: InOnly, BodyType: String, Body: Hello World! Camel K route written in Java.] [ 1 ] 2022-06-24 08:53:28, 520 INFO [info] ( Camel ( camel-1 ) thread #0 - timer://java) Exchange[ExchangePattern: InOnly, BodyType: String, Body: Hello World! Camel K route written in Java.] Podが起動するとOpenShiftのオペレータ上にあるインテグレーションタブにも実行中のインテグレーションが表示されます。実行中のインテグレーションが分かりやすく管理できます。 開発者モードでインテグレーションを停止する場合には、コマンド上から「Ctrl+c」で停止することができます。 Podも削除され、Camal K オペレータのインテグレーションからも削除されることが確認できます。 6.シンプルなインテグレーションの実行と削除 次は開発モードではなく、通常モードで実行するにはどうするか？ということですが、これは簡単です。「--dev」を付けずに実行するだけです。 ❯ kamel run Basic.java No IntegrationPlatform resource in camel-basic namespace Integration " basic " created 実行中のログも出ません。実行中のログを確認するには「kamel log」とします。一つ注意があるとすれば、対象はソース名ではなくインテグレーションの名称である必要があります。 ❯ kamel log basic No IntegrationPlatform resource in camel-basic namespace Integration ' basic ' is now running. Showing log ... [ 1 ] Monitoring pod basic-5b79788c6b-2dnfr ・・・（省略） [ 1 ] 2022-06-24 09:03:12, 333 INFO [ org.apa.cam.k.Runtime ] ( main ) Apache Camel K Runtime 1 . 9 . 0 .fuse-800051-redhat-00001 [ 1 ] 2022-06-24 09:03:12, 429 INFO [ org.apa.cam.qua.cor.CamelBootstrapRecorder ] ( main ) Bootstrap runtime: org.apache.camel.quarkus.main.CamelMainRuntime [ 1 ] 2022-06-24 09:03:12, 537 INFO [ org.apa.cam.k.lis.SourcesConfigurer ] ( main ) Loading routes from: SourceDefinition { name = ' Basic ' , language = ' java ' , type=' source ' , location = ' file:/etc/camel/sources/Basic.java ' , } [ 1 ] 2022-06-24 09:03:15, 235 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( main ) Routes startup summary ( total:1 started:1 ) [ 1 ] 2022-06-24 09:03:15, 235 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( main ) Started route1 ( timer://java ) [ 1 ] 2022-06-24 09:03:15, 235 INFO [ org.apa.cam.imp.eng.AbstractCamelContext ] ( main ) Apache Camel 3 . 11 . 5 .fuse-800012-redhat-00004 ( camel-1 ) started in 306ms ( build:0ms init:298ms start:8ms ) [ 1 ] 2022-06-24 09:03:15, 238 INFO [ io.quarkus ] ( main ) camel-k-integration 1 . 6 . 7 on JVM ( powered by Quarkus 2 . 2 . 5 .Final-redhat-00010 ) started in 5 .094s. [ 1 ] 2022-06-24 09:03:15, 238 INFO [ io.quarkus ] ( main ) Profile prod activated. [ 1 ] 2022-06-24 09:03:15, 238 INFO [ io.quarkus ] ( main ) Installed features: [ camel-bean, camel-core, camel-java-joor-dsl, camel-k-core, camel-k-runtime, camel-log, camel-timer, cdi ] [ 1 ] 2022-06-24 09:03:16, 240 INFO [ info ] ( Camel ( camel-1 ) thread #0 - timer://java) Exchange[ExchangePattern: InOnly, BodyType: String, Body: Hello World! Camel K route written in Java.] [ 1 ] 2022-06-24 09:03:17, 235 INFO [info] ( Camel ( camel-1 ) thread #0 - timer://java) Exchange[ExchangePattern: InOnly, BodyType: String, Body: Hello World! Camel K route written in Java.] さきほどはCamel K オペレータからインテグレーション状況を確認しましたが、今回はOCコマンドから確認してみましょう。同様に実行中のインテグレーションが確認できます。 ❯ oc get integration NAME PHASE KIT REPLICAS basic Running kit-caqnhnuipnivars9ds5g 1 次に先程作成したインテグレーションを削除してみます。 ❯ kamel delete basic No IntegrationPlatform resource in camel-basic namespace Integration basic deleted そして最後にもう一度、OCコマンドで実行状況を確認します。インテグレーションが削除されたことを確認することができます。 ❯ oc get integration No resources found in camel-basic namespace. Fuseのサポート情報 今回ご紹介させていただきました Apache Camel ベースの製品ファミリですが、Apache Camel 2 ベースの「Fuse」は徐々に「End of Life」が近づいてきています。今後は Apache Camel 3 をベースとした製品にマイグレーションいただく必要がありますので是非とも上記内容を参照頂き、余裕のあるマイグレーション計画を立てて頂けたらと思います。 access.redhat.com マイグレーション方法としては、Apache Camel に マイグレーションガイド がありますのでまずはこちらをご参照ください。 また Red Hat からは 「MIGRATION TOOLKIT FOR APPLICATIONS」 で Camel 3 に関するルールが追加されています。マイグレーションする際には是非とも 「MIGRATION TOOLKIT FOR APPLICATIONS」 ご利用いただけたらと思います。 リリースノート Migration Toolkit for Applications 5.0 | Red Hat Customer Portal 最後に いかがでしたでしょうか？ 非常に簡単なサンプルではありましたが、Apache Camel 3 ベースの「Camel Extensions for Quarkus」と「Camel K」をご紹介させていただきました。 Quarkus によって起動や実行が早くなり、Camel K に至ってはかなり簡単にインテグレーションが実行できることご理解いただけたのではないでしょうか。 参照リンク https://camel.apache.org/camel-quarkus/2.9.x/ https://camel.apache.org/camel-k/1.9.x/ https://camel.apache.org/manual/camel-3-migration-guide.html https://access.redhat.com/documentation/ja-jp/red_hat_integration/2022.q1/html/getting_started_with_camel_extensions_for_quarkus/ https://access.redhat.com/documentation/ja-jp/red_hat_integration/2022.q1/html/developing_applications_with_camel_extensions_for_quarkus/_introduction_to_developing_applications_with_camel_extensions_for_quarkus https://access.redhat.com/documentation/ja-jp/red_hat_integration/2022.q1/html-single/getting_started_with_camel_k/ https://access.redhat.com/documentation/ja-jp/red_hat_integration/2022.q1/html/developing_and_managing_integrations_using_camel_k/index https://access.redhat.com/documentation/ja-jp/migration_toolkit_for_applications/5.0/html/maven_plugin_guide/about_mta_maven-guide

こんにちはRed Hatでソリューションアーキテクトをしている石川です。 過去にもOpenShiftでCI/CDの機能を提供するOpenShift Pipelinesについて何度かご紹介してきましたが、今回はOpenShift Pipelinesのv1.7からTech Previewとして利用可能となったTekton Chainsというコンポーネントについて試してみたいと思います。 ATTENTION! Tech Preview機能の位置付けについては こちらのページ を参照して下さい。 そもそもOpenShift Pipelinesとは何か？について知りたい方は過去記事をご参照下さい。 rheb.hatenablog.com rheb.hatenablog.com Tekton Chainsの概要 まずTekton Chainsが何者なのかを把握するために、GithubのTekton Chainsページを見てみましょう。 github.com Tekton Chains is a Kubernetes Custom Resource Definition (CRD) controller that allows you to manage your supply chain security in Tekton. In its default mode of operation, Chains works by observing all TaskRuns executions in your cluster. When TaskRuns complete, Chains takes a snapshot of them. Chains then converts this snapshot to one or more standard payload formats, signs them and stores them somewhere. 最初の文を読むと、Tekton ChainsはKubernetesのCRDコントローラーであり、Tektonにおけるサプライチェーンセキュリティを管理する、とあります。 また以降の文では、Tektonにおける TaskRun の実行結果のスナップショットを標準的なペイロードフォーマットに変換し、署名をした上で保管する、とあります。 上記だけでTekton Chainsの全容を掴むことは中々難しいですが、要約すると、Tektonで実行したパイプラインの成果物に署名を行って、適切に管理するためのツールであると言えるでしょう。 ここで書かれているパイプラインの成果物は、大きく二つに分類することができます。 一つ目は TaskRun の実行結果、二つ目はパイプラインの中で作成したコンテナイメージです。 一つ目はともかく、二つ目のコンテナイメージについては、これまでもイメージの発行元を確認するために、署名や検証を実施するということはあったため、比較的理解し易いのではないでしょうか。 本記事ではまずTekton Chainsによるコンテナイメージの署名について考えてみたいと思います。 コンテナイメージに署名するメリット CIパイプラインの中でビルドしたコンテナイメージに対し署名を行うと、どんなメリットが得られるでしょうか？ 分かりやすいメリットとしてはセキュリティの向上です。 例として、コンテナレジストリに不正なアクセスを受け、悪意のあるイメージを外部からプッシュされるパターンを考えてみましょう。 コンテナイメージに対する署名や、その検証というプロセスが無い場合、外部からプッシュされたイメージをクラスタ上で稼働させるリスクがあります。 一方でCIパイプラインの中で署名し、その検証を行っていると、外部から勝手にプッシュされたイメージには署名が存在しないため、実際にクラスタ上でコンテナが稼働することを防ぐことが可能となります。 そもそもコンテナレジストリに簡単にアクセスさせない事は非常に重要ですが、上記のようなプロセスを確立しておくことで、万が一の場合もリスクを低減させることができます。 セキュリティ以外にも、例えばISVベンダーが自社のアプリケーションをコンテナとしてユーザーに提供する際にコンテナイメージに署名を行うことで、ユーザー側でイメージの提供元が正しいことを確認することができます。 Tekton Chainsの設定方法 ここからはOpenShift上でTekton Chainsを使用する方法について見ていきたいと思います。 基本的に以下のドキュメントに沿って設定を行っていくためこちらもご参照下さい。 docs.openshift.com 今回使用する環境はOpenShift 4.10で、OpenShift Pipelinesのv1.7をあらかじめインストールしています。 自身でも試してみたいという場合は、OpenShiftクラスタのバージョンとOpenShift Pipelinesのバージョンに注意しましょう。 まず以下のCustom Resourceオブジェクトを作成し、 openshift-pipelines ProjectでTekton Chainsを有効化します。 apiVersion: operator.tekton.dev/v1alpha1 kind: TektonChain metadata: name: chain spec: targetNamespace: openshift-pipelines その上で設定ファイルに必要な値を入れます。 oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.format": "in-toto", "artifacts.taskrun.storage": "tekton", "artifacts.taskrun.signer": "x509", "artifacts.oci.format": "simplesigning", "artifacts.oci.storage": "oci", "artifacts.oci.signer": "x509"}}' 設定値を見ると、 artifacts.xxx の xxx 部分でTaskRunを対象とする設定か、OCI（コンテナイメージ）に対する設定かを表しており、それ以下の箇所でフォーマットや、保管場所、署名時のキーとして何を使用するかを決めています。 コミュニティ版のTekton Chainsでは、署名時の鍵として各種クラウドサービスが提供するKMSを使用したり、実験的な機能として、自分自身で鍵管理を不要とするKeyless Signingを設定することも可能です。 設定可能な値についてより詳しく知りたい方は以下を参照してみて下さい。 docs.openshift.com tekton.dev 署名用の鍵作成 ここからは署名に必要な鍵を作成していきます。 鍵の作成には cosign というツールを使用します。 cosignは sigstore という、ソフトウェア署名の利用の簡素化を目指すプロジェクトのコンポーネントの一つとなっています。 Tekton Chainsはsigstoreのその他のコンポーネントとも深く関連しているため興味がある方は是非調べてみて下さい。 まずはcosignを作業環境にインストールします。 Githubのリリースページから最新版を取得します。 curl -L https://github.com/sigstore/cosign/releases/download/v1.9.0/cosign-linux-amd64 > cosign-linux-amd64 chmod 755 cosign-linux-amd64 mv cosign-linux-amd64 /usr/local/bin/cosign # バージョン確認 cosign version --- ______ ______ _______. __ _______ .__ __. / | / __ \ / || | / _____|| \ | | | ,----'| | | | | (----`| | | | __ | \| | | | | | | | \ \ | | | | |_ | | . ` | | `----.| `--' | .----) | | | | |__| | | |\ | \______| \______/ |_______/ |__| \______| |__| \__| cosign: A tool for Container Signing, Verification and Storage in an OCI registry. GitVersion: v1.9.0 GitCommit: a4cb262dc3d45a283a6a7513bb767a38a2d3f448 GitTreeState: clean BuildDate: 2022-06-03T13:47:07Z GoVersion: go1.17.11 Compiler: gc Platform: linux/amd64 cosignを使って鍵を作成します。作成時に暗号鍵に対するパスワードを求められるので適宜設定します。 cosign generate-key-pair k8s://openshift-pipelines/signing-secrets --- Enter password for private key: Enter password for private key again: Successfully created secret signing-secrets in namespace openshift-pipelines Public key written to cosign.pub 上記のコマンド実行結果により、ローカルにはcosign.pub、クラスタ上にはsigning-secretsというSecretが作成されました。 cosign.pubには公開鍵の情報、signing-secretsには公開鍵 + 暗号鍵 + パスワードの情報が含まれています。 間違えてパブリックGitレポジトリ等にこれらの情報をアップロードしたりしないよう注意しましょう。 コンテナビルド用のTaskの確認 CIパイプラインの中でコンテナビルドを行うためには、当然ビルドのためのTaskが必要となるのですが、Tekton Chainsによる署名を行う場合、ビルド用のTaskの実行結果として IMAGE_DIGEST と IMAGE_URL という二つのパラメーターを返却する必要があります。 github.com そのため、これらのパラメーターが返却されるよう使用するTaskに適宜変更を加えます。 以下はs2iのTaskにパラメーター設定を行った例です。 chains-s2i-nodejs.yaml (クリックで展開) apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: s2i-nodejs labels: app.kubernetes.io/version: '0.1' operator.tekton.dev/provider-type: redhat spec: description: >- s2i-nodejs task clones a Git repository and builds and pushes a container image using S2I and a nodejs builder image. params: - default: 14-ubi8 description: The tag of nodejs imagestream for nodejs version name: VERSION type: string - default: . description: The location of the path to run s2i from. name: PATH_CONTEXT type: string - default: 'true' description: >- Verify the TLS on the registry endpoint (for push/pull to a non-TLS registry) name: TLSVERIFY type: string - description: Location of the repo where image has to be pushed name: IMAGE type: string - default: >- registry.redhat.io/rhel8/buildah@sha256:e19cf23d5f1e0608f5a897f0a50448beb9f8387031cca49c7487ec71bd91c4d3 description: The location of the buildah builder image. name: BUILDER_IMAGE type: string results: - description: Digest of the image just built. name: IMAGE_DIGEST - description: '' name: IMAGE_URL steps: - command: - s2i - build - $(params.PATH_CONTEXT) - >- image-registry.openshift-image-registry.svc:5000/openshift/nodejs:$(params.VERSION) - '--as-dockerfile' - /gen-source/Dockerfile.gen env: - name: HOME value: /tekton/home image: >- registry.redhat.io/ocp-tools-4-tech-preview/source-to-image-rhel8@sha256:e518e05a730ae066e371a4bd36a5af9cedc8686fd04bd59648d20ea0a486d7e5 name: generate resources: {} volumeMounts: - mountPath: /gen-source name: gen-source workingDir: $(workspaces.source.path) - command: - buildah - bud - '--storage-driver=vfs' - '--tls-verify=$(params.TLSVERIFY)' - '--layers' - '-f' - /gen-source/Dockerfile.gen - '-t' - $(params.IMAGE) - . image: $(params.BUILDER_IMAGE) name: build resources: {} volumeMounts: - mountPath: /var/lib/containers name: varlibcontainers - mountPath: /gen-source name: gen-source workingDir: /gen-source - command: - buildah - push - '--storage-driver=vfs' - '--tls-verify=$(params.TLSVERIFY)' - '--digestfile=$(workspaces.source.path)/image-digest' - $(params.IMAGE) - 'docker://$(params.IMAGE)' image: $(params.BUILDER_IMAGE) name: push resources: {} volumeMounts: - mountPath: /var/lib/containers name: varlibcontainers workingDir: $(workspaces.source.path) - image: $(params.BUILDER_IMAGE) name: digest-to-results resources: {} script: >- cat $(workspaces.source.path)/image-digest | tee /tekton/results/IMAGE_DIGEST - image: $(params.BUILDER_IMAGE) name: url-to-results resources: {} script: 'echo $(params.IMAGE) | tee /tekton/results/IMAGE_URL ' volumes: - emptyDir: {} name: varlibcontainers - emptyDir: {} name: gen-source workspaces: - mountPath: /workspace/source name: source Tekton HubにあるKanikoのTaskでは必要なパラメーターが設定されているのでそちらを使用してもよいでしょう。 hub.tekton.dev パイプラインの実行と署名 それではいよいよパイプラインを実行してみたいと思います。 今回はソースコードをGitからクローンし、その後s2iによるコンテナビルドを行うシンプルなパイプラインを構成します。 chains-pipeline.yaml (クリックで展開) apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: chains-pipeline spec: workspaces: - name: shared-workspace description: Git Repo for Patient Health Records Apps params: - name: target-path type: string - name: git-url type: string - name: git-revision type: string - name: image-name type: string tasks: - name: git-clone-health taskRef: name: git-clone params: - name: url value: $(params.git-url) - name: revision value: $(params.git-revision) workspaces: - name: output workspace: shared-workspace - name: build-container taskRef: name: s2i-nodejs kind: Task runAfter: - git-clone-health workspaces: - name: source workspace: shared-workspace params: - name: PATH_CONTEXT value: $(workspaces.source.path)/$(params.target-path) - name: IMAGE value: ${IMAGE_REGISTRY}/$(params.image-name):$(params.git-revision) クラスタにPipelineをデプロイします。 export IMAGE_REGISTRY=$(oc get route -n openshift-image-registry default-route -o "jsonpath={.spec.host}") cat rhf-pipeline.yaml | envsubst |oc apply -f - 対応するPipelineRunを作成し、定義したPipelineを実行しましょう。 chains-pipelinerun.yaml (クリックで展開) apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: chains-pipeline-run- spec: pipelineRef: name: chains-pipeline params: - name: target-path value: 'site' - name: git-url value: 'https://gitlab.com/jpishikawa/rhf2021-cicd-app' - name: git-revision value: 'master' - name: image-name value: 'tekton-chains/sample-image' workspaces: - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi oc create -f chains-pipelinerun.yaml 実行してしばらく待つとPipelineRunが成功します。 さて、無事パイプラインが完了しましたが、今回の目的であるコンテナイメージへの署名はどこから確認できるでしょうか。 実は署名は、ビルドしたコンテナイメージと同じくレジストリに格納されています。（今回の場合OpenShiftの内部レジストリ） 上図の、 sample-image:master がコンテナイメージで、 sample-image:sha256-xxx.sig が署名となっています。 一般的なOCIレジストリでは、コンテナのイメージレイヤー以外にもMedia typeを指定することでBlobを保存することが可能になっています。 コンテナイメージの場合、各レイヤーのMedia typeに application/vnd.oci.image.layer.v1.tar+gzip が設定されていますが、 署名では application/vnd.dev.cosign.simplesigning.v1+json が設定されています。 （これらは crane などのツールを使うことで確認が可能です。） 格納された署名を検証してみましょう。 鍵を生成する際に使ったcosignで署名の検証についても実施することができます。 # 認証 cosign login -u cluster-admin -p $(oc whoami -t) $IMAGE_REGISTRY # ローカルに保存したcosign.pubにより検証を実施 cosign verify --key cosign.pub $IMAGE_REGISTRY/tekton-chains/sample-image:master --- Verification for default-route-openshift-image-registry.apps.mycluster2.t7cy.p1.openshiftapps.com/tekton-chains/sample-image:master -- The following checks were performed on each of these signatures: - The cosign claims were validated - The signatures were verified against the specified public key [{"critical":{"identity":{"docker-reference":"default-route-openshift-image-registry.apps.mycluster2.t7cy.p1.openshiftapps.com/tekton-chains/sample-image"},"image":{"docker-manifest-digest":"sha256:bc3daf4033d41be7434a72615ddbf3b68f54f65e394071a81b9c81bcbdca90c2"},"type":"cosign container image signature"},"optional":null}] 検証の結果から、署名に用いられた鍵が検証時の公開鍵と対になっていることが確認できました。 上記のようにcosignを使用し手動で検証を行う以外に、OPA GatekeeperやKyvernoといったAdmission Controllerを使うことで、コンテナをデプロイする際に署名の検証を自動化する方法が知られています。デプロイ時に署名検証を厳格化するにはこうしたツールを導入することが望ましいと言えるでしょう。 まとめ 今回はTekton Chainsについてご紹介しました。現在はTech Previewであるため、機能としての成熟はこれからというところですが、sigstoreなどの関連プロジェクトの進化も相まって、今後更なる発展が見込めるのではないでしょうか。 昨今ホットなテーマであるSupply Chain Security対策の一つとしてこれからも注目していきたいと思います。

OpenStackやOpenShiftなどのCloud製品を担当しているソリューションアーキテクトの輿水です。 本日は「OpenShiftをちょっと触ってみたいけど、どこでできるでしょう？」という話をしたいと思います。 パブクッククラウドのサービスを使う オススメ度：☆ コスト感：☆ タイミング：☆☆☆ AWSやAzure、IBM cloudで、OpenShift環境をサクッと作れるマネージド・サービスがあります。過去に、この赤帽ブログでも取り上げられていますが、ROSA、ARO、ROKSなどです。1日使うとどれくらいなのか？という紹介をした赤帽ブログもあります。クラウドサービスのダッシュボードを利用すれば割と簡単にOpenShiftの環境を作成できます。難点は、コストが高いことです。どのマネージド・サービスでも、それなりのサイズのインスタンスを複数起動するので、1日稼働させると1万近くなってしまいます。会社に経費請求できる方以外にはコスト面での敷居が高いです。また、特に何かしらの演習ガイドがある訳でないので、その環境を使って何を学習したいのか？を自分で明確にしておく必要があります。 Containers & Cloud Native Roadshow (略称CCNR) オススメ度：☆☆☆ コスト感：☆☆☆ タイミング：☆ 3ヶ月に1回行われる無償のオンライン・ワークショップです。業界標準のオープンソーステクノロジーを使用して、コンテナ化されたクラウドネイティブアプリケーションを構築、展開、管理するための実践的なワークショップで、開発者向けおよび運用者向けのコースがあります。基本的にガイドに従って自習形式で進めるコンテンツですが、インストラクターに質問することも可能です。インストラクターが付くのは約4時間ですが、ワークショップ用に準備したOpenShift環境は8時間くらいは使用できるので、インストラクター無しで自己学習もできます。 つい先日、6月に開催されました。運用者向けのコースの内容については、これも過去にブログで取り上げてますので、興味がある方は参照していただければと思います。ブログを書いた頃より、OpenShiftのバージョンが上がり現時点で4.9ベースですが、学習する内容は大きくは変わっていません。ちなみに「Windowsコンテナ」演習が新しく追加されました。 なお、環境はAWS上に作成されており、初期状態でMasterノード3台、Workerノード3台、その後の演習で、インフラノード3台、ストレージノード3台を追加するというリッチ構成です。特にストレージ（OpenShift Data Foundation）に関しては、あまりこのようなワークショップは無償では開催されていないと思います。 モジュール 内容 演習環境の概要 |演習環境におけるターミナルとGUIの使い方 OpenShiftクラスタのインストールの検証 CLIを使ったOpenShiftクラスタの確認方法 アプリケーション管理の基礎 サンプルアプリケーションのデプロイと基本的なリソース (Pod, Service等) の説明 アプリケーションストレージの基礎 アプリケーションで永続ストレージを使用する方法 MachineSets, Machines, and Nodes MachineSetとMachineを使ってWorkerノードを追加する方法 インフラストラクチャノード と Operator インフラノードの追加とOperatorを使ったインフラコンポーネントの移動方法 OpenShift ログ集約 OpenShift Loggingによるインフラとアプリケーションのログ集約 外部認証プロバイダ(LDAP)の設定 LDAPサーバと連携したユーザとグループの外部認証 OpenShift Monitoring OpenShift Monitoringによるクラスタコンポーネントの監視 プロジェクト・リクエスト・テンプレートとクォータ/制限 Project作成時のテンプレートとProjectへのリソースクォータ OpenShift の Network Policy ベースのSDN Network PolicyによるProjectをまたいだ通信の制御 Projectのセルフプロビジョニングの無効化 ユーザによるProject作成の制限方法 クラスタリソースのクォータ ユーザまたはアプリケーションに対するリソースクォータ Taint と Toleration 特定のノードでアプリケーションを稼働しないようにする方法 Windows コンテナ Windowsノードの追加とWindowsコンテナの稼働 OpenShift Data Foundationのデプロイと管理 永続ストレージであるOpenShift Data Foundationの使用 内容は超オススメなのですが、開催頻度が3ヶ月に1回なので、タイミングが合う合わないがあり、また、環境がリッチするぎる故に、参加者数に上限があるのもちょっと難点です。 Red Hat Developer 今回のオススメです。 オススメ度：☆☆ コスト感：☆☆☆ タイミング：☆☆☆ オススメ度が☆2なのは、英語だからということと、内容が頻繁に変わって、該当のハンズオンがいきなり消えている事があるためです。また各コースで環境を使用できる制限時間が設けられており、10分〜1時間が殆どで少し短く感じる点と、英語で書かれているのでOpenShiftを理解する前に英語を理解せねばならぬ、という日本人ならではの苦業があります。プラス面は、OpenShiftのバージョンを積極的に新しくしたり、演習内容をより適切なものにしている点です。 developers.redhat.com こんなサイトは初耳です、という方のが多いかもしれません。英語のサイトなので、検索で辿り着くことも少ないかもしれません。Topページを見た瞬間、そっと閉じたくなる感じもありますが、比較的技術寄りの製品に関する記事やDeveloper Sandbox、interactive lessonがまとまってます。 このページにはOpenShiftに限らず様々な製品について、interactive lessonつまり自己学習できるHands-On Labが置いてあるのです（英語ですけど）。O’Reillyが提供していたkatacoda.comという、ハンズオンを作って提供できるサイトがあったのですが、それと同様のものを提供しています。先程、久しぶりにkatacoda.comのトップページを見たら、katacoda.comが閉鎖されるというアナウンスが載ってました、残念です。Katacodaを利用するためにはアカウントを作成する必要があったのですが、こちらは特にはアカウント作成は必要ありません。 心の中で若干ハードルを感じつつ「learn」の部分をクリックすると学習コンテンツが表示されます。「View all OpenShift Learning」に進めば下の方に「All OpenShift interactive lessons」とOpenShiftに関連するHands-On Labが複数表示されます。 正直に言うと「Start」のところをクリックした瞬間 Not Found だの 404だの表示されてしまうページがあります。絶賛改修中なので、生温かい気持ちで見てください。その中でいくつか初級編の、現時点で有効なOpenShiftのコースをご紹介します。 Logging into an OpenShift cluster Logging into an OpenShift cluster | Red Hat Developer 文字通り、OpenShiftのクラスタにログインしてみよう！というコースです。初歩の初歩ですが、0penShift-consoleのPodがあることを確認して、そこへのrouteを調べてWebコンソールにアクセスしてみるという、後から振り返ればOpenShiftのObjectの様々な要素が含まれています。また、OpenShiftを利用してアプリ開発などを行う際に、複数ユーザでの開発を考慮する必要が生じますが、ユーザーに権限を付与する仕組みも説明しています。 OpenShiftクラスタのWebコンソールURLを調べアクセス OpenShift Command Line Toolの利用 OpenShiftの新規ユーザー作成と権限付与 ユーザーの切替 Build and deploy applications with OpenShift Build and deploy applications with OpenShift | Red Hat Developer getting-startedと言いながら、アプリケーションPodのスケールアウト、スケールインを実施。OpenShiftのセルフヒーリング機能についても学びます。 ocコマンドでOpenShiftクラスタにアクセス WebコンソールでOpenShiftクラスタにアクセスしてアプリケーションをビルド アプリケーションのスケーリング Routeを利用して外部に公開されたURLにアクセス Deploying Applications From Source Deploying applications from source | Red Hat Developer CCNRで実施してる「アプリケーション管理の基礎」に近い内容です。pythonアプリをビルド＆デプロイし、削除や再作成するとどのうように変化するかを確認します。 ocコマンドを利用してプロジェクトを作成、とWebコンソールで確認 Webコンソールを利用してイメージからpythonアプリをビルド＆デプロイ Webコンソールでアプリのログを確認 外部に公開されたURLにアクセスしアプリの確認 アプリの削除 ocコマンドでアプリを再度デプロイ ビルドトリガーの設定 Using OpenShift Pipelines Deploying applications from source | Red Hat Developer CI/CD パイプラインフレームワークであるOpenShift Pipelines / Tektonを触ってみるコースです。 Getting Started with ArgoCD and OpenShift GitOps Operator Deploying applications from source | Red Hat Developer OpenShift GitOps OperatorをインストールしてArgo CDを触ってみるコース。 この赤帽ブログでもArgo CDに関する記事がありますが、それに近い内容を実際に触って確認することができます。（ハンズオンで使用されているアプリの仕様が変更されていて、ドキュメントに載っている絵と実際のアプリの見え方はちょっと違いますが実施してる内容は相違ないです。） 他にも様々なコースがありまして、ページの下の方にある「All interactive lessons」でフィターをOpenShiftにして指定すると関連するものが表示されます。コースにはBeginnerとIntermediateがあり、難易度も選択できますので、ご自身のペースで実施してください。ただし、たまにNot Foundがあるのはご容赦ください。

Red Hat のソリューションアーキテクトの井上たかひろです。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトがご紹介していきます。 今回は 2022/7月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: Apache Camel 超入門とRed Hat Fuse 再入門 Red Hat Fuse(upstream: Apache Camel)は、Apache Camel 2.x をベースにし多様なインテグレーションパターンを実装したインテグレーションエンジンです。 Red Hat Fuseについて理解するためのApache Camel 超入門とRed Hat Fuse 再入門の記事になります。 rheb.hatenablog.com rheb.hatenablog.com 特集2: クラウドネイティブなアプリケーション開発を始めよう！ 〜 すぐに試せるRed Hatのマネージドサービス 〜 Red HatではOpenShiftのマネージドサービスだけでなく、その上で動作するアプリケーションやデータに関するマネージドサービスサービスも提供しており、先日行われたRed Hat Summitでもそのビジョンやロードマップについて紹介がされていました。以下の記事では、そのマネージドサービスの紹介とトライアルの始め方について紹介をしています。 rheb.hatenablog.com 特集3: 分散トレーシング(OpenTelemetry)を使う(その1) OpenShiftでは、分散トレーシングを行うためのRed Hat OpenShift distributed tracing platformとRed Hat OpenShift distributed tracing data collectionのOperator を提供しています。いきなり、分散トレーシングをはじめるのも敷居が高い場合があるので、ローカルで簡単に試してみる紹介記事になります。 qiita.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat Application Interconnect 1.0