概要 Red Hat でコンサルタントをしている陳といいます。 仕事の中でお客様にワークショップを行うための開発環境を提供する場面があって、検討した結果、 ブラウザでhttpsでvscodeが使えるようにした。メリットは以下です。 お客様のセキュリティ対策で遮断される可能性が低い 開発環境としての利便性が高い extensionをインストールして使い勝手を良くすることができる 開発環境の構築内容が自由 nodejs、python、事前にインストールするextensionなどContainerfileで自由に変更可能 構築方法 全体概要図 前提条件 下記ツールがインストールされていること podman podman-compose podman-desktop(option) コンテナ カスタマイズしたcode-serverのイメージをビルド Containerfile FROM lscr.io/linuxserver/code-server:latest LABEL description="node-16.16.0の実行環境を構築した code-server container image" LABEL maintainer="author <abc@example.com>" SHELL ["/bin/bash", "-c"] RUN git clone https://github.com/anyenv/anyenv ~/.anyenv && \ echo 'export PATH="$HOME/.anyenv/bin:$PATH"' >> ~/.bashrc && \ echo 'eval "$(anyenv init -)"' >> ~/.bashrc && \ source ~/.bashrc && \ anyenv --version && \ anyenv install --force-init && \ anyenv install nodenv && \ source ~/.bashrc && \ echo 'eval "$(nodenv init -)"' >> ~/.bashrc && \ nodenv install 16.16.0 && \ nodenv global 16.16.0 && \ /app/code-server/bin/code-server --extensions-dir /config/extensions --install-extension firsttris.vscode-jest-runner && \ /app/code-server/bin/code-server --extensions-dir /config/extensions --install-extension dracula-theme.theme-dracula SHELL ["/bin/bash", "-c"] でbashに切り替えて、anyenvとnodenvを使ってnodeの実行環境を構築する。 最後の2行はvscodeのextensionをインストールしている。 code-server だけだと、 command not found エラーが出るため、フルパス指定した。 また、 --extensions-dir でextersionのインストール先を指定しないと、webブラウザでログインした後extensionが見つからない事象が生じた。 Containerfileと同じディレクトリで podman build --format docker --layers=false -t code-server-nodejs16:latest . を実行すると、カスタムイメージがビルドされる。 --format docker を入れた理由は SHELL ["/bin/bash", "-c"] を有効にしたいから。このオプションを追加しなければpodmanは SHELL を識別しない。 カスタムイメージのコンテナを起動 code-server.yml(post-composeのファイル) --- version: "2.1" services: code-server: image: localhost/code-server-nodejs16:latest container_name: code-server1 environment: - PUID=0 - PGID=0 - TZ=Asia/Tokyo - PASSWORD=password #optional # - SUDO_PASSWORD=password #optional # - SUDO_PASSWORD_HASH= #optional # - PROXY_DOMAIN=code-server.my.domain #optional - DEFAULT_WORKSPACE=/config/workspace #optional # volumes: # - ./config:/config ports: - 8443:8443 restart: unless-stopped environmentの各環境変数の意味は こちら をご参考ください。 podman-compose -f code-server.yml up -d を実行すると、コンテナが起動される。 複数起動したい場合はcode-server.ymlをコピーして、container_nameとportsの設定を変更すればいい。 動作確認 http://localhost:8443 にアクセスしてパスワードを入力すれば、下記画面が表示される サンプルコード https://github.com/coolboy0961/code-server 今後記事の内容と合わなくなるくらい変更していく可能性あり SSL証明書およびリバースプロキシ 前提条件 SynologyのNASを所有していること 外からhttpsでNASのWeb Console画面にアクセスできていること リバースプロキシの設定 リバースプロキシにWebSocketのサポートを追加しなければ、リバースプロキシ経由でcode-serverに繋げると 1006 エラーが発生する。 詳細は こちら をご参考ください。 SSL証明書の発行 リバースプロキシの設定と証明書を紐づける設定 動作確認 動作確認時に Error code: SSL_ERROR_BAD_CERT_DOMAIN がブラウザで表示されたら、しばらく待ってからブラウザを開き直したりして再度確認してみてください。 リバースプロキシの設定と証明書を紐づける設定を反映するのに時間がかかる場合がある。 まとめ 以上、Podmanでcode-serverのcontainerを起動しサービスとして公開する方法でした。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat が主導して開発している JDK Flight Recorder を管理するツールである Cryostat に関するブログのまとめ記事です。 Cryostat 2.1 9つの素晴らしいCryostat 2.1のアップデート - 赤帽エンジニアブログ Cryostat 2.1での不要な通知をフィルタリング - 赤帽エンジニアブログ Cryostat 2.1の新ダウンロードAPIでJFRデータに高速にアクセス - 赤帽エンジニアブログ Cryostat 2.1のサイドカーレポートによるリソース消費量の削減 - 赤帽エンジニアブログ Cryostat 2.1によるKubernetes上のJMX認証情報の管理 - 赤帽エンジニアブログ CryostatとGraphQLによるインスタンス間のJFR管理 - 赤帽エンジニアブログ Cryostat 2.1でJFRデータを記録ラベルで整理する方法 - 赤帽エンジニアブログ Cryostat 2.1の新UIでJFRの自動化ルールを構築する方法 - 赤帽エンジニアブログ OpenShiftでCryostat 2.1にログインする方法：SSOを使う - 赤帽エンジニアブログ Cryostat 2.0 コンテナ型アプリケーションにカスタム JDK Flight Recorderイベントを注入 - 赤帽エンジニアブログ OperatorHub.ioからKubernetes上へCryostat Operatorをインストール - 赤帽エンジニアブログ JDK Flight Recorderデータへの高速アクセス方法 - 赤帽エンジニアブログ Cryostat 2.0によるカスタムJFRイベントテンプレート - 赤帽エンジニアブログ JDK Flight Recorderのコンテナでの自動化 - 赤帽エンジニアブログ CryostatによるカスタムターゲットのJavaモニタリング - 赤帽エンジニアブログ Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ Cryostat 2.0を発表：コンテナ用JDK Flight Recorder - 赤帽エンジニアブログ

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 9 awesome updates in Cryostat 2.1 | Red Hat Developer の翻訳記事です。 皆さんは、Java Flight Recorderを使ったことがあるのではないでしょうか。これは、Javaの動作状況を分析し、理解するための優れたツールです。開発中や本番で稼動している作業量を把握するのに重宝します。Cryostatは、コンテナとKubernetesに同じ機能を提供することで、それをさらに推し進めます。ユーザは、クラスタ全体のアプリケーションを記録して、アプリケーションの挙動を理解できるようになります。また、ユーザは様々なAPIを利用し、異なるフォーマットで分析データを取得できます。 RBAC と OAuth のサポート Cryostat 2.1 では、Red Hat OpenShift Container Platform に内蔵された OAuth サーバーを使用して OAuth 認証ができます。これにより、ユーザは認証トークンを手動で貼り付ける必要がなくなりました。また、複数のユーザが 1 つの名前空間で Cryostat を使用して JDK フライトレコーディングを管理する場合、Cryostat 固有の RBAC パーミッションを持つロールを作成し、そのロールをユーザアカウントに関連付けることによって、各ユーザに固有の権限を付与できます。 詳しくは、「 OpenShiftでCryostat 2.1にログインする方法：SSOを使う - 赤帽エンジニアブログ 」をごらん下さい 自動化ルール Cryostat 2.1では、その自動化ルールのための全く新しいユーザインタフェースを備えています。2.0リリースでは、我々は、API機能としてこれを導入しました。自動化されたルールは、適切な適用ルールを決定するための強力かつ柔軟な判定式で、ターゲットJVMに対する新しいJDKフライトレコーディングの作成を開始するために使用できます。これらのマッチ式は、さまざまなアプリケーション属性（ポッド名、JMXポート、Kubernetesラベル、アノテーションなど）を参照します。ルールが作成されると、Cryostatはルールで定義されたJFRイベントテンプレートを使用して新しい記録を選択し、開始します。 詳しくは、「 Cryostat 2.1の新UIでJFRの自動化ルールを構築する方法 - 赤帽エンジニアブログ 」をごらん下さい 記録のラベル ユーザーは、Cryostatが管理するJDKフライトレコーディングにメタデータやカスタムラベルを添付できます。記録のラベルは、記録に関連するメタデータを添付したり、クエリ中に記録を識別したり、同じKubernetesラベルを含む複数の記録に対して操作を実行するために使用できます。 詳しくは、「 Cryostat 2.1でJFRデータを記録ラベルで整理する方法 - 赤帽エンジニアブログ 」をごらん下さい GraphQL サポート Cryostat 2.1には、新しいGraphQL APIも含まれています。これにより、ユーザはターゲットJVMと、それに属する稼働中または保管された記録のクエリを作成できます。Cryostat に保管されている記録は、稼働中または保管中の記録を開始、停止、保管、削除するための処理と組み合わせて、Cryostat と JDK Flight Recorder の周囲に自動化を構築するための強力なクエリを作成できます。 詳しくは、「 CryostatとGraphQLによるインスタンス間のJFR管理 - 赤帽エンジニアブログ 」をごらん下さい Java Management Extensions コンテナ化されたJVM上でJava Management Extensions（JMX）認証を有効にしている場合、CryostatはターゲットJVM上のJDKフライトレコーディングにアクセスする前にJMX認証情報を入力するよう促します。CryostatコンソールのAutomated rules、Recordings、Eventsタブでは、JMX認証が有効なターゲットで既存のフライトレコーディングを表示したり、記録操作を実行するために、JMX認証情報を入力する必要があります。 詳しくは、「 Cryostat 2.1によるKubernetes上のJMX認証情報の管理 - 赤帽エンジニアブログ 」をごらん下さい サイドカー・レポート・コンテナ Cryostat 2.1では、JDKフライトレコーディングの自動分析レポートを生成するために、サイドカー・レポート・コンテナを使用するオプションが導入されています。以前は、レポート生成はメインのCryostatコンテナによってのみ処理されました。レポート生成を サイドカー・コンテナに委ねるこの新しいオプションにより、ユーザーはより効率的にリソースを配置しやすくなります。 詳しくは、「 Cryostat 2.1のサイドカーレポートによるリソース消費量の削減 - 赤帽エンジニアブログ 」をごらん下さい JSON web トークン (JWT) Cryostat 2.1では、JWTダウンロードを容易にするために新しいAPIハンドラを実装しました。ユーザがWebクライアントを通じてファイルをダウンロードすることを決定すると、必要な認証ヘッダと要求されたリソースを特定するマルチパートフォーム属性を含むPOSTリクエストをCryostatエンドポイントに送信します。APIハンドラは、この情報をJWTトークンにエンコードし、対称的に暗号化し、トークンに関連付けられたリソースのURLを返します。 通知 Cryostat は、Cryostat バックエンドとブラウザで動作する Web クライアントの間で WebSocket 接続を使用し、様々な動作や状態の変化が発生したときに通知を表示します。Cryostat 2.1では、発生しうるすべての概念的な操作や 状態変化に対してWebSocket通知が発行されますが、Cryostatの以前のバージョンでは、ある種の活動や状態変化に対する通知が含まれていませんでした。形式もより一貫しており、各通知タイプに明確なタイトルと説明を提供しています。 詳しくは、「 Cryostat 2.1での不要な通知をフィルタリング - 赤帽エンジニアブログ 」をごらん下さい Helm charts Cryostat 2.1がHelmチャートを使ってインストールできるようになりました。Cryostat Operatorは本番環境でのお勧めのインストール方法ですが、Cryostat Helm chartはデモ目的でCryostatを試すのに最適で、できるだけ多くのユーザに対応できるよう、権限が少なく、柔軟に設計されています。Cryostat Helm Chartは、OpenShift 4.8以降にデフォルトで含まれています。 このテーマについては、今後の赤帽エンジニアブログの記事で詳しく紹介する予定です。 Cryostatのサポートを受けるには Cryostat のサポートは、Red Hat Enterprise Linux、Red Hat OpenShift、および Red Hat Runtimes のサブスクリプションを通じて Red Hat のお客様に提供されます。Red Hat とその世界的なパートナーネットワークが提供する世界クラスのサポートを享受する方法の詳細については、お近くの Red Hat 担当者または Red Hat 営業にお問い合わせください。 今後は、Red Hatの製品アップデートとサポートライフサイクルに沿って、Cryostatとその他のランタイムのサポートが期待できます。 Red Hat RuntimesとCryostatのサポートを担当する人々 このソフトウェアは、Red Hat Runtimes のプロダクトおよびエンジニアリングチームと Cryostat アップストリームコミュニティによって制作されました。この制作には、何時間もの開発、広範なテスト、文書作成、そしてお客様、パートナー、Cryostat 開発者の Red Hat コミュニティとの協力があり、大小さまざまな貢献を取り込みました。私たちは、あなたがそれを使うことを選択したことを嬉しく思い、それがあなたの期待を上回ることを望みます！ Red Hat Runtimesの詳細 Red Hat Runtimes は、クラウドネイティブアプリケーション開発の必要性を持つ開発者、アーキテクト、IT リーダー向けに、包括的なフレームワーク、ランタイム、プログラミング言語のセットを提供します。ビジネスソリューションの開発と提供を加速させるために設計されています。Red Hat Runtimes を使用してマイクロサービスを作成するために、さまざまなランタイムと実現機能が用意されています。

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 今回はROSAで使用することができるスポットインスタンスについて紹介していきたいと思います。 そもそもROSAとは何かについて知りたいという方はこちらの過去記事をご参照下さい。 rheb.hatenablog.com スポットインスタンスの概要とROSAクラスタへの追加 スポットインスタンスはAWSが提供するEC2インスタンスの提供形態の一つであり、休止中のEC2キャパシティーを使用することで、オンデマンド価格より低料金で利用することが特徴のサービスです。オンデマンド価格と比較し、最大で90%ものコスト削減が可能となるそうです。 一方でスポットインスタンスは稼働中に中断（Terminate）される可能性があり、使用する場合は適切なワークロードを選択する必要があります。 実行が長時間に亘るジョブや、ステートフルなアプリケーションなどに対しては利用を避けるのが良いでしょう。 スポットインスタンス自体の詳細な説明については AWSのサイト をご確認下さい。 さて、このスポットインスタンスですがROSAでも使用することができます。 ROSAでは OCMコンソール から自身が構築したクラスタに対しての設定やアドオンの追加などができるようになっており、その中の一つにWorker Nodeの追加や削除を行う Machine pools というタブがあります。 クラスタを構築した段階ではDefaultのMachine poolが存在するだけですが、この画面から新たにMachine poolを追加することができ、その際にスポットインスタンスを選ぶことが可能です。 使用するインスタンスタイプや台数などを設定した後、 Use Amazon EC2 Spot Instances にチェックを入れると、追加するインスタンスをスポットインスタンスにすることができます。 スポットインスタンスの設定として、 Use On-Demand instance price か、 Set maximum price の二つからどちらかを選択します。 Use On-Demand instance price は文言だけを見るとオンデマンドインスタンスの価格がスポットインスタンスに適用されるように見えますが、実際はスポットインスタンスの利用価格が変動し高くなった場合に、オンデマンドインスタンスの価格と同じになることを許容するという設定です。 一方の Set maximum price は自分で1時間あたりのスポットインスタンスの価格の最大値を設定することができます。設定する場合、 スポットインスタンスの料金履歴 などを参考にすると良いでしょう。 ただ後者の場合、設定した価格を超えてしまうとインスタンスが起動できなくなるため、基本的には Use On-Demand instance price を利用することをおすすめします。 あとは Add machine pool するだけでROSAクラスタにスポットインスタンスを追加できます。非常に簡単ですね。 一点気を付けたいポイントとして、一度スポットインスタンスとしてMachine poolを作成すると後からその設定を変更することはできないため注意しましょう。 中断に対しての対処 スポットインスタンスを使う場合に検討する必要があるのがインスタンスの中断に対してどのように対処するかです。 以下のAWSのドキュメントを見ると、中断の通知は実際にスポットインスタンスが停止、または終了が行われる2分前に行われるとあります。 docs.aws.amazon.com 通知は、Amazon EventBridgeを使用してイベント情報として受け取るか、あるいは インスタンスメタデータ から確認することができます。 もしこの通知を無視した場合、該当のインスタンスがいきなりシャットダウンするような形となり、その上で稼働するコンテナが正常に処理を終了できず、アプリのダウンタイムが発生する等、様々な問題が起こる可能性があります。 そのため、ROSAではこの通知を自動で確認するための仕組みとして、 machine-api-termination-handler というDaemonSetが、スポットインスタンス上で稼働します。 （起動したスポットインスタンスには machine.openshift.io/interruptible-instance: '' というラベルが付与されており、このラベルを見て対象のノードを判断しています。） 各ノードにデプロイされた machine-api-termination-handler のPodは、5秒に一回インスタンスメタデータにアクセスし、自ノードが中断の対象となっているかを確認します。 # machine-api-termination-handler Podのログ（中断対象ではないことが出力されている） I0908 14:49:28.434019 1 handler.go:119] "msg"="Instance not marked for termination" "namespace"="openshift-machine-api" "node"="ip-10-0-196-218.us-east-2.compute.internal" I0908 14:49:33.433734 1 handler.go:119] "msg"="Instance not marked for termination" "namespace"="openshift-machine-api" "node"="ip-10-0-196-218.us-east-2.compute.internal" I0908 14:49:38.433317 1 handler.go:119] "msg"="Instance not marked for termination" "namespace"="openshift-machine-api" "node"="ip-10-0-196-218.us-east-2.compute.internal" ... 注意点したいのが、スポットインスタンスにTaintを付与すると machine-api-termination-handler Podが起動できなくなってしまいます。そのためスポットインスタンスで特定のPodのみ動かしたい場合はNodeAffinity等を利用するのが良いでしょう。 インスタンスメタデータを確認した結果、中断対象であると分かった場合、 machine-api-termination-handler はNodeの .status.conditions にTerminatingであるという情報を追加します。 - type: Terminating status: 'True' lastHeartbeatTime: '2022-09-07T09:02:32Z' lastTransitionTime: '2022-09-07T09:02:32Z' reason: TerminationRequested message: The cloud provider has marked this instance for termination 上記が追加されると、 machine-healthcheck-controller が対象のノードをUnhealthyと判断し、Drain処理が行われます。これにより対象のノードはスケジュール対象外となり、このノードで稼働していたPodに対して正常な終了処理が行われます。 スポットインスタンスに限った話ではないですが、稼働しているPodを適切に終了するためには、PodのpreStopやterminationGracePeriodSecondsなどを適切に設定しましょう。 スポットインスタンスの中断を実験する ここまでROSAではどのようにスポットインスタンスの中断に対処しているのかについてご紹介しました。 基本的に、１）スポットインスタンスで動かすワークロードを適切に選択する、２）それらに対して適切なPodの終了処理が実施できるよう設定を行う、という二点が守れていれば、急にインスタンスが中断された場合も問題ないと考えられますが、そうは言っても実際に正しく設定ができているかについて不安を感じられる方は多いかと思います。 そういう時に役立つのがAWSが提供する AWS Fault Injection Simulator というサービスです。 このサービスを使うと意図的にスポットインスタンスの中断を発生させることができるので、その際にROSAがどういった挙動を取るのかといったことを確認することができます。 以下のドキュメントでは、チュートリアルとしてAWS FISを使用してスポットインスタンスを中断する方法が紹介されています。 docs.aws.amazon.com スポットインスタンスを利用する際はこちらについても利用を検討してみてはいかがでしょうか。 まとめ 今回はROSAへのスポットインスタンスへの追加についてご紹介しました。 ROSAではスポットインスタンスを利用する際に起こりうる中断に対して、デフォルトで適切に対応するための仕組みを提供しています。 スポットインスタンスは上手く利用することでコストを大きく抑えることもできますので、今回の内容を参考に是非お試しください。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Filter unwanted notifications in Cryostat 2.1 | Red Hat Developer の翻訳記事です。 Cryostatは、Java Flight Recorder (JFR)でJavaアプリケーションを監視する際、常に通知を発行してきました。Cryostatのバージョン2.1では、提供される情報の量を増やし、表示されるものに対するユーザの制御を強化し、Cryostatの性能を向上させる通知のための新しい実装とインタフェースがあります。 Cryostat インタフェース 新しいWebSocketインタフェースのおかげで、Cryostatは以前報告されなかったイベントに対して通知を発行します。このように、デフォルトでは、より多くの通知がユーザへ報告されます。例えば、新しい自動ルール機能は、一度に多くのインスタンスにルールを追加し、各ルールが作成または削除されたとき、またルールが記録を開始、記録をアーカイブにコピー、またはアーカイブから古い記録を削除するときに通知を発行します。図1に示すように、通知の量は特に膨大になる可能性があります。 図1： Cryostatは膨大な数の通知を届けることができる。 この問題に対処するため、Cryostat 2.1では、新しい設定ページ（図2）を通じて、ユーザが受け取る通知の有効化と無効化を行う機能を提供します。ユーザは、カテゴリごとに通知を選択したり、ワンクリックですべての通知を有効または無効にできます。 図2：Cryostat 2.1のSettingsビューには、各通知カテゴリの切り替えが可能なNotificationsの機能が搭載 例えば、自動ルールのバックグラウンドでの活動によって発せられる可能性のあるすべての通知を無効にするには、次のカテゴリーをオフに切り替えます。 Recording Created (自動化ルールがターゲットに新しい記録を作成するときに発行) Recording Saved (自動化されたルールが稼働中の記録を保管するときに発行) Archived Recording Deleted (自動化されたルールが過去の記録を削除したときに発行) 実装と性能 Cryostat は、Cryostat バックエンドとブラウザで動作する Web クライアントの間で WebSocket 接続を使用し、様々な操作や 状態の変化が発生したときに通知を表示します。Cryostat 2.1では、発生しうる全ての概念的なアクションや状態変化に対してWebSocket通知が発行されます。以前のバージョンのCryostatでは、一部のタイプの操作や 状態変化に対する通知が含まれていなかったのに対して、今回のCryostatでは、そのような通知が含まれています。書式もより一貫しており、各通知タイプに詳細なタイトルと説明があります。 通知カテゴリを無効にすると、メッセージは WebSocket 接続を介して送信されますが、Web クライアントのポップアップ通知は単に表示されなくなります。ユーザが選択した設定は、完全に Web クライアント側で行われ、ブラウザのローカル ストレージに永続化されます。Web クライアントは依然として通知情報を受信し、メモリに保持します。したがって、通知カテゴリを再度有効にした場合、そのカテゴリで以前に発せられた通知は、まだあなたが読むことができるようになります。このようにして、Cryostatは、必要に応じて調べるために操作と状態変化のログを保存しながら、通知でユーザインタフェースを乱雑にするのを避けます。 注意 : 通知カテゴリは、自動化されたルールによって実行された操作と、ユーザがAPIリクエストを経由して別のクライアントによって対話的に実行された操作とを区別していません。これらの通知を無効にすると、自動化されたルールが実行したときだけでなく、すべてのケースで無効になります。 また、Web クライアントのパフォーマンスも、通知を使用して稼働中の記録、保管された記録、およびテンプレートなどのリソースの状態を更新することで改善されました。たとえば、稼働中の記録を削除した場合、Web クライアントはバックエンドからの対応する通知を使用して、該当する記録を削除することで稼働中の記録リストを更新するようになりました。その他の状態の更新も、同様の方法で行われます。以前は、この作業の流れは、バックエンドにHTTP GETリクエストを送信して、稼働中の記録全体の更新された一覧を取得し、この一覧を使用して、ユーザに表示される古い一覧を完全に置き換える必要がありました。現在、Web クライアントは、削除された 1 つの記録項目のみを更新するだけです。 まとめ Cryostatの通知方法は、バージョン2.1でより良く構造化され、より充実しています。それはあなたが望む通知を取得し、あなたが邪魔に感じるかもしれない多くの他のものを除外するために、あなたのブラウザで少し準備を必要とします。しかし、一貫性と性能の改善は、より良いユーザインタフェースを生み出します。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Access JFR data faster with Cryostat 2.1's new download APIs | Red Hat Developer の翻訳記事です。 Cryostatは、Kubernetes上でJDK Flight Recorderのデータを管理するためのツールです。この記事では、JSON Web Token (JWT) に基づく新しいダウンロード API が、Cryostat 2.1 Web クライアントにおいて、より応答性が高く効率的なダウンロードの流れを促進するのに役立つことを説明します。 Cryostat Webクライアントのダウンロードの流れ 以前は、Web クライアントの記録、レポート、テンプレートなどのリソースのダウンロードの流れは、アプリケーションがバックエンドに適切な認証ヘッダー付きの HTTP GET 要求を行い、返されたファイルをブラウザのメモリにダウンロードし、その blob に対してローカルオブジェクト URL を作成し、その URL をアンカー要素（ <a> タグ）に割り当ててユーザの応答を促すというものでした。ファイルサイズによってダウンロード速度が決まり、「ファイルを保存する」プロンプトが表示されるタイミングも決まりました。このプロセスが完了すると、ファイルがすでにユーザーのマシンに転送されているにもかかわらず、ユーザーはファイルをディスクに保存するか、ダウンロードをキャンセルするかを尋ねられます。 Cryostat 2.1では、ほとんどのブラウザで利用可能なHTML 5の download 属性を使用することにより、ダウンロードの流れを改良しています。具体的には、アンカー要素を作成し、 href 属性にバックエンドが提供するリソースのURLを設定し、 download 属性にファイル名を設定します。アンカーをクリックすると、"Save File" というプロンプトが表示されます (図 1 参照)。 図1：「Save File」プロンプトで、記録ファイルをディスクに保存するかどうかを決定可能 ユーザが「ファイルを保存」をクリックすると、ファイルは直接ディスクにダウンロードされます。ユーザが「キャンセル」をクリックすると、ファイルはダウンロードされません。また、ブラウザのメモリに何もダウンロードされないため、「ファイルを保存」ダイアログの表示時間がファイルサイズに依存しなくなるというメリットもあります。 しかし、 href 属性の制限として、リソースを取得するための権限なしにURLと一緒にヘッダを提供することは不可能です。そこでJSONウェブトークンの出番です。 JSON Web Tokenによるダウンロードの流れ改善方法 JWTは、サーバリクエストを送信するユーザが、セッション内で以前に認証された（すなわち、ログインした）同じユーザであり、要求されたリソースへのアクセス権も持っていることを保証する認証情報です。JWTは、認証メタデータを含むJSONデータ本体で構成されています。 Cryostat 2.1では、JWTダウンロードを容易にするために新しいAPIハンドラが実装されました。ユーザがWebクライアントを通してファイルをダウンロードするとき、POSTリクエストは必要な認証ヘッダと要求されたリソースを特定するマルチパートフォーム属性を含み、 /api/v2.1/auth/token エンドポイントに送信されます。APIハンドラは情報をJWTトークンにエンコードし、それを対称的に暗号化して、トークンに関連付けられたリソースURLを返します。これは前述の href 属性が設定されている URL です。アンカー要素がクリックされると、ファイルリソースへの GET リクエストが JWT トークンを使って認証され、 href 属性でヘッダーを提供できない問題が解決されます。 JWTトークンに関連するすべてのGETリクエストは、この目的のために特別に設計された新しいバージョン2.1 APIハンドラによって処理されます。ブラウザ関連のパフォーマンスが向上したため、Webクライアントではこれらを広範に使用しています。しかし、ユーザーが作成した自動ワークフローなどの他のAPIクライアントは、新しいバージョン2.1ハンドラと機能的に同じであるJWTトークンを生成する必要がないため、元のバージョン1のダウンロードAPIを引き続き使用できます。 図2は、Webクライアントからの記録ダウンロード要求を受信したときのCryostatコンテナのメインログです。 図2：図1の記録ダウンロードのリクエストは、ここに示す2つのHTTPリクエストになります。 まとめ 新しいJWTベースのダウンロードAPIにより、CryostatのWebクライアントは、ユーザに改善されたリソースのダウンロードの流れを提供できます。Cryostatの詳細については、 cryostat.io を参照してください。質問、コメント、フィードバックは、 GitHub で私たちとつながるか、私たちの メーリングリスト に参加してください。 赤帽エンジニアブログでCryostatのチュートリアルをもっと見る。 ContainerJFR入門: コンテナのためのJDK Flight Recorder - 赤帽エンジニアブログ Cryostat 2.1の新UIでJFRの自動化ルールを構築する方法 - 赤帽エンジニアブログ Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Eat up fewer resources in Cryostat 2.1 with sidecar reports | Red Hat Developer の翻訳記事です。 Cryostatは、Kubernetes上でJDK Flight Recorderのデータを管理するためのツールです。Cryostatのバージョン2.1では、JDKフライトレコーディングの自動分析レポートを生成するために、サイドカーレポートコンテナを使用するオプションが導入されています。以前は、メインのCryostatコンテナがレポート生成を処理していました。レポート生成はリソース集約的な操作であり、その結果、ユーザーはピーク時のリソース要求を満たすためにCryostatコンテナを過剰に割り当てていることに気づくかもしれません。レポート生成をしていない場合、それらのリソースは逆に使用されずに終わるかもしれません。 レポート生成をサイドカーコンテナに委ねるこの新しいオプションにより、ユーザはより効率的にリソースを準備しやすくなりました。レポート作成が重要でない場合、メインの Cryostat コンテナは、Web サーバーや HTTP および JMX を介したさまざまな軽量操作を含めて、小さなリソースしか必要としません。ユーザは、レポート生成の一連の作業に基づいて、サイドカー・レポート・コンテナに適宜リソースを割り当て、そのコンテナのレプリカを任意の数だけ起動させることができます。 本記事では、Red Hat OpenShift上でCryostatを使用して分析レポート自動生成のためのサイドカーレポートコンテナレプリカを設定するプロセスについて説明します。 サイドカーコンテナを使用するための前提条件 開始するには、Cryostat Operator がインストールされた稼働中の OpenShift または Kubernetes クラスタを使用します。OpenShift または Kubernetes クラスタにまだアクセスできない場合は、Red Hat OpenShift Local を試してみてください。この記事では、Cryostat Operator と対話するために OpenShift UI を利用します。 次に、Java Management Extensions (JMX) を有効にし、Cryostat Operator と同じ名前空間で動作するように公開した、コンテナ化した Java アプリケーションをデプロイします。サンプルQuarkusアプリケーションを作成してこの要件を満たす方法の詳細については、赤帽エンジニアブログの記事『 Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ 』を参照してください。 サイドカー・レポート・コンテナを有効にして、Cryostatリソースを作成 Cryostat Operator がインストールされると、サイドカー・レポート・コンテナのセットアップは簡単な作業になります。OpenShift Web コンソールの Installed Operators タブにある Cryostat Operator に移動し、Cryostat リソースのインスタンスを作成します (図 1 を参照)。 図1：Cryostatリソースを作成するためにCreate instanceを選択 図2に示すように、様々な設定項目がある Create Cryostat ページが表示されます。 図2：Cryostatリソースの設定オプション 下に移動して Report Options を選択し、次に Resources を選択します (図 3 を参照)。 図3：レポート生成の設定オプションを選択 次に、デプロイするレポート・サイドカー・コンテナのレプリカ数を選択し、各レプリカの Limits および Requests リソースを設定します。デフォルトのレプリカ数は0であり、メインのCryostatコンテナがサブプロセスを通じてレポート生成を処理することを意味します。このサブプロセスのデフォルトの最大ヒープサイズは200MiBですが、必要に応じてユーザが上限を調整できます。少なくとも 1 つのレポートサイドカーコンテナレプリカを要求すると、 Sub Process Max Heap Size フィールドは無視されます。 この例では、図 4 に示すレポートオプションの設定を使用して Cryostat インスタンスを作成する必要があります。 図4：Replicas、Limits、Requestsフィールドをこのように設定し、下に移動してCreateを選択 自動解析レポートを作成するには、Cryostat Web クライアントに移動します。Cryostat Operatorページの Installed Operators から、 Cryostat タブを選択し、 cryostat-sample リソースを選択します。表示されたページで、WebクライアントのURLを確認できます(図5)。 図5：アプリケーションのURLに従って、Cryostat Webクライアントにアクセス プロンプトが表示され、Webクライアントで認証するためのクラスタの認証情報が要求されます。ログインしたら、ターゲットアプリケーションを選択し（自作でも、上記のリンク先のサンプルQuarkusアプリケーションでも）、 Recordings タブに移動します（図6）。一定時間のカスタムフライト レコーディングを作成します。記録終了後、記録の自動分析レポートを要求します。これらのステップの詳細な手順については、 Cryostatの使用に関するガイド を参照してください。 図6：自動分析レポートをリクエストすると、サイドカーコンテナでのレポート作成が開始 サイドカー・レポート・コンテナがレポート生成を処理したことを再確認するには、OpenShift コンソールに戻り、 Workloads タブの下の Pods に移動します。ここで、sidecar レポートコンテナが含まれるポッドを見つけられます (図 7 を参照)。 図7：cryostat-sample-reportsポッドを選択します。ポッド名には、ランダムに生成された英数字の文字列も付加 次に、図 8 に示す Logs タブに移動し、ログストリームを一時停止します。次に、繰り返される HTTP GET /health リクエストを下に移動し、サイドカー・レポート・コンテナが Cryostat メイン・コンテナからの HTTP リクエストを受信し、実行したことを確認するログ・メッセージを探します。 図8：サイドカーレポートコンテナは、生成されたレポートに対するメインのCryostatコンテナからの要求を受信し、応答 まとめ 解析レポートの自動生成にサイドカーレポートコンテナを使用することで、ユーザーはCryostat用のリソースを効率的に用意できます。Cryostatの詳細については、 cryostat.io を参照してください。質問、コメント、フィードバックは、 GitHub で私たちとつながるか、私たちの メーリングリスト に参加してください。 赤帽エンジニアブログでCryostatのチュートリアルをもっと見る。 ContainerJFR入門: コンテナのためのJDK Flight Recorder - 赤帽エンジニアブログ Cryostat 2.1の新UIでJFRの自動化ルールを構築する方法 - 赤帽エンジニアブログ Cryostatを使用するためのJavaアプリケーションの設定 - 赤帽エンジニアブログ

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Manage JMX credentials on Kubernetes with Cryostat 2.1 | Red Hat Developer の翻訳記事です。 Cryostatは、Kubernetes上のJDK Flight Recorderのデータを管理するためのツールです。コンテナ化されたJava仮想マシン（JVM）上でJava Management Extensions（JMX）認証を有効にしている場合、CryostatはターゲットJVM上のJDKフライトレコーディングにアクセスする前にJMX認証情報を入力するよう促します。Cryostatコンソールの Automated Rules 、 Recordings 、 Events タブでは、JMX認証情報を入力する必要があります。これは、JMX認証を有効にしたターゲットで既存のフライトレコーディングを表示したり録画操作を実行したい場合に必要です。自動ルールなどのCryostatの機能で複数のターゲットJVMを監視する場合、Cryostatが各ターゲット接続のJMX認証情報を記憶し再利用することを望むでしょう。 Cryostatは、各ターゲットの接続URLとして知られる一意のJMXサービスURLに従って、JMX認証情報を保存します。基盤となるJVMインスタンスの変更、ターゲットエイリアスの変更、ターゲットアプリケーションの再起動があっても、Cryostatは、保存されたJMX認証情報を、認証情報が関連付けられている接続URLに適用します。 ターゲットアプリケーション上で自動的に記録を開始し保存する自動化ルールを開始したい場合、ルールを作成する前に、 Security タブで選択した各ターゲットの認証情報を保存しなければなりません。Cryostat に JMX 認証を必要とするターゲットの認証情報がない場合、ルールはターゲット JVM に接続できず、記録は開始されません。 ここでは、CryostatのWeb UIを使用して、保存されたJMX認証情報を管理する方法を紹介します。 CryostatにJMXの認証情報を保存する方法 まず、 Security タブに移動します。Stored Credentials 表は、Cryostat が JMX 認証情報を保存しているすべてのターゲットを一覧表示します。図 1 に示すように Add をクリックして、希望するターゲット JVM の JMX 認証情報を入力します。 図1：JMXの認証情報を保存するために「Security」タブに移動 図2に示すように、ターゲットJVMを選択し、JMX認証情報を入力するよう促す画面が表示されます。 図2：JMXの認証情報を入力 また、図3に示すように、 Recordings または Events タブに移動して、JMX認証を有効にしたターゲットJVMを選択すると、JMX認証情報が自動的に保存されます。同様の認証画面が表示され、JMX認証情報を入力するよう促されます。認証情報は自動的に保存され、「Stored JMX Credentials」表に表示されます。認証情報は自動的に記憶され、いつでも削除できます。 図3：このJMX認証ポップアップ画面は、ターゲットJVMの記録を閲覧する前に認証が必要な場合に表示される ターゲットに認証情報を保存すると、ターゲットエイリアスと接続 URL が Security タブの Stored Credentials 表に表示されます。これは、図 4 に示すように、Cryostat がそのターゲットの JMX 認証情報を保存していることを示します。繰り返しになりますが、特定のターゲットに保存された認証情報を関連付ける場合、接続 URL だけが重要です。ターゲットエイリアスはいつでも自由に変更でき、Cryostat が保存された JMX 認証情報を見つけ、ターゲット JVM に適用する能力に影響を与えることはありません。 セキュリティ対策として、登録後は実際の認証情報を確認できません。既存のターゲットの保存された認証情報を置き換えたい場合、古い認証情報項目を削除し、古い項目と同じ接続 URL で新しい項目を追加できます。保存されている認証情報を削除するには、ターゲットの横にあるチェックボックスを選択し、 Delete をクリックします。保存されているすべてのJMX認証情報を削除するには、表の上部にあるヘッダのチェックボックスを選択し、 Delete をクリックします。 図4：保存されたJMX認証情報の表 まとめ この記事では、コンテナ化されたJVMに接続する際にCryostatが再利用するためのJMX認証情報を保存する方法について説明しました。Cryostatの詳細については、cryostat.ioを参照してください。質問、コメント、フィードバックは、GitHubで私たちとつながるか、メーリングリストに参加することで、お気軽にどうぞ。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 Manage JFR across instances with Cryostat and GraphQL | Red Hat Developer の翻訳記事です。 Cryostatは、Java Flight Recorder (JFR) を用いたJavaアプリケーションの監視をクラウド上で管理します。Cryostat 2.1では、複数のアプリケーション、コンテナ、Kubernetesポッドのフライトレコーディングを制御するためのGraphQLがサポートされており、強力な絞り込み機能を備えています。この記事では、GraphQL サポートを追加した動機について説明し、期待される結果とともにいくつかのクエリ例を共有し、GraphQL エンドポイントでの基礎となる Web リクエストを見ていきます。 なぜCryostatでGraphQLを使うのか？ Cryostatの以前のバージョンは、単純なHTTP REST APIでフライトレコーディングを公開しました。そのAPIは、各リクエストを単一の概念的なアクションに制限していました - 例えば、1つのレプリカインスタンスで1つの記録を開始します。しかし、Cryostatは、複数のスケールされたレプリカ内の多数のインスタンスを実行するマイクロサービスアーキテクチャを作成する開発者にサービスを提供し、各レプリカインスタンスは、様々な目的のために実行されている多くのフライトレコーディングを保持します。 したがって、単純なコンテナの12個のレプリカで同一の記録を開始しようとする開発者は、12回のAPIリクエストが必要でした。さらに悪いことに、10個のマイクロサービス上の10個のレプリカで同一の記録を開始しようとする開発者は、10x10=100のAPIリクエストを行う必要があります（よくある使用例です）。 明らかに、Cryostatはこれらすべての条件を管理するために、柔軟で強力なAPIを必要としています。GraphQLは、厳選されたインスタンスのグループに対してクエリを発行するための、シンプルで有能な言語です。複数のアクションを単一のAPIリクエストに減らすことで、通信量のオーバーヘッドが減少するため、全体の性能が大幅に改善されます。さらなる利点として、開発者は複雑なアクションを実行するために、APIのJSONレスポンスを解析し、レスポンスデータに対して繰り返しアクションを実行するカスタムクライアントを書くのではなく、より短くシンプルなクエリーを書けます。 ターゲットJVMとそれに属する稼働中または保管された記録、および一般的なCryostatアーカイブに存在する記録に対するクエリは、稼働中または保管された記録を開始、停止、保管、削除する命令と組み合わせて、CryostatとJDK Flight Recorder周辺の自動化を構築するための強力なクエリを作成できます。 クエリの例 Cryostatは /api/beta/graphql エンドポイントでGraphQLで記述されたクエリを受け付けます。もしあなたがGraphQLを全く知らないのであれば、この記事の例でどの部分が単なるGraphQLの構文や概念なのか、それともCryostat特有の動作なのかをより理解するために、 このドキュメント を簡単に見てみることをお勧めします。 最初の簡単なクエリを以下に示します。 query { targetNodes { name nodeType labels target { alias serviceUri } } } これは Cryostat に targetNodes の結果を求めます。これは Cryostat が認識している全ての JVM ターゲットを返すクエリです。レスポンスは、それらのオブジェクトの配列です。クエリは、 name や nodeType のような様々なフィールドを指定するので、配列内のオブジェクトは、それらのフィールドだけを含みます。 もう一つ、より高度なクエリを紹介します。 query { environmentNodes ( filter : { name : "my-app-pod-abcd1234" } ) { descendantTargets { doStartRecording ( recording : { name : "myrecording" , template : "Profiling" , templateType : "TARGET" , duration : 30 } ) { name state } } } } これは Cryostat に environmentNodes の結果を求めます。これは Cryostat が認識している、JVM ターゲットアプリケーションではないデプロイメントグラフ内の全てのノードを返すクエリです。Red Hat OpenShift のコンテキストでは、結果は、例えば Deployments や DeploymentConfigs 、そしてそれらに属する Pods を含むでしょう。 前のクエリでは名前ベースの絞り込みを行い、 my-app-pod-abcd1234 という名前のノードのみを選択しました。この文字列が、プロジェクトの名前空間内の 1 つの Pod に判定されると仮定します。そのポッドに対して、このクエリは、入れ子になったクエリ descendantTargets を実行し、前の例のクエリと同様に、JVMターゲット・オブジェクトの配列を生成します。 それらのJVMターゲットの各々で、 doStartRecording の更新処理を実行します。その名前が示すように、この更新処理は、提供された構成を使用して、JVMターゲットのそれぞれで新しいJDKフライトレコーディングを開始するようにCryostatを仕向けます。レスポンスは、これらの記録それぞれの名前と状態（ myrecording と RUNNING であると予想される）を含んでいます。 先ほどの例は、GraphQL APIの威力と実用性を示しています。ここでは、1回のリクエストで、CryostatがOpenShiftと通信して特定のPodに属するCryostat対応JVMをすべて決定し、各JVMで記録を開始するという複雑な動作を実行できます。 最後にクエリの例を挙げます。 query { targetNodes ( filter : { annotations : "PORT = 9093" } ) { recordings { active ( filter : { labels : "mylabel = redhatdevelopers" } ) { doArchive { name } } } } } OpenShiftに慣れている人なら、ここの labels の仕分けは見慣れたものになるかもしれません。このラベルの選択子はOpenShiftのラベルの選択子と同じ構文で、Cryostatの記録ラベルだけでなく、デプロイメントのグラフのラベルや注釈にも適用されます。 mylabel = redhatdevelopers , env in (prod, stage) , または !mylabel のような式を使用できます。また、複数のラベル選択子を配列として指定することで、論理的なAND接続を作成できます。 active ( filter : { labels : [ "mylabel = redhatdevelopers" , "env in (prod, stage)" ] } ) Cryostat が特定の名前空間のデプロイメントのグラフで見ているものをよりよく理解するために、次のようなコマンドで Discover API エンドポイント を確認します。 $ curl https://my-cryostat.openshift.example.com/api/v2.1/discovery | jq いくつかの異なる種類のフィルタがあり、それらを組み合わせて様々な入れ子になったクエリに適用できます。そのため、多数の可能な意味があるリクエストを繋ぎ合わせられます。CryostatのGraphQL queries.graphqlsとtypes.graphqlsリポジトリを参照し、実装されている全てのクエリと更新処理を確認し、どのフィルタがどの種類のフィルタを受け入れるかを学びます。この名前は自明であるべきです。FilterInputで終わるタイプはフィルタであり、doで始まるタイプフィールドは、実際には、記録を開始したり、記録を保管場所へコピーするなどのアクションを実行する入れ子となった更新処理です。 APIエンドポイントの詳細 この記事の例では、GraphQLエンドポイントの典型的なクエリのデータ本体、実行可能な動作、および期待される応答がどのようなものかを示しています。このセクションでは、これらのリクエストをどのように行うか、具体的な詳細を詳しく見ていきます。 Cryostat 2.1の主要なGraphQLエンドポイントは、 POST /api/beta/graphql です。このパスに送られる POST リクエストは、 { query: "the_query" } のような形式の本文が含まれます。これは、前のセクションの例で示されたように、 THE_QUERY をクエリのテキストに置き換えています。以下は、リクエストとそのメタデータの具体例です。 POST /api/beta/graphql HTTP/1.1 Accept: application/json, */*;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Content-Length: 171 Content-Type: application/json Host: localhost:8181 User-Agent: HTTPie/3.1.0 { "query": "query {\n targetNodes {\n name\n nodeType\n labels\n target {\n alias\n serviceUri\n }\n }\n}\n" } GET /api/beta/graphql のリクエストでも同じ結果が得られます。 "/api/beta/graphql?query={targetNodes{name nodeType labels target{alias serviceUri}}}" HTTP/1.1 200 OK content-encoding: gzip content-length: 247 content-type: application/json GraphQLをさらに活用 前のセクションの例では、いくつかの可能なクエリの絞り込みを探りました。あなたの環境の中でGraphQLインターフェースの力を発揮するために、次の演習を試してみてください。 すべてのJVMアプリケーションを一度にスナップショットし、得られた記録をCryostatアーカイブにコピーするGraphQLクエリを作成します。 cURL またはお好みの HTTP クライアントを使用して Cryostat にリクエストを送信し、クエリを実行します。 このAPIリクエストを使ったスクリプトを作成し、毎日午後5時に実行するようにcrontabに追加します。 このスクリプトをCryostat自動化ルールと組み合わせ、JVMアプリケーションが現れるたびに、新しい 継続的な監視記録を自動的に開始させます。 これらの部品はそれぞれ単独では単純ですが、一緒になると強力な自動化された流れが形成されます。 最後にもう一つ。古いバージョンのCryostatにおける標準APIは2.1でもまだ存在し、GraphQLに適さないアクションや機能のために、このAPIにさらに追加されたものがあります。それは、AuthorizationヘッダではなくJWTトークンを使用してJDKフライトレコーディングファイルをダウンロードするための新しいエンドポイントです。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 How to organize JFR data with recording labels in Cryostat 2.1 | Red Hat Developer の翻訳記事です。 Cryostat 2.1の技術プレビューリリースでは、コンテナで管理されたJavaアプリケーションを監視するJDKフライトレコーディングにメタデータやカスタムラベルを添付し、Cryostatを使ってそれらの記録を管理できます。記録のラベルは、クエリで記録を識別し、同じラベルを含む複数の記録に対して操作を実行できます。この記事では、自動化されたルールで管理されている記録を含む、JDKフライトレコーディングのメタデータラベルを追加および編集する方法を説明します。 JDKフライトレコーディングに記録ラベルを追加 Cryostatコンソールの Recordings タブに移動し、ドロップダウンメニューからターゲットJVMを選択します。 Create をクリックして、カスタムフライトレコーディングを作成します（図 1）。フライトレコーディングを作成する際、 Show metadata options 欄を展開します。 Add Label をクリックして、キーと値のラベルの組み合わせを記録に追加します。記録の作成に関する詳細については、Cryostatガイドを参照してください。 図1：カスタムフライトのレコーディングは、カスタムラベルで追跡可能 新しい記録は、図 2 に示すように、選択した記録テンプレートに関する情報を含むデフォルトのラベルとともに、カスタムラベルを使用して Recordings タブに表示されます。 図2：「稼働中の記録」の表には、各記録のラベルが表示 JDKフライトレコーディングの記録ラベルの編集 記録ラベルは、記録が作成された後やアーカイブに再アップロードされた後にも編集できます。例えば、この例のカスタムラベルにはタイプミスが含まれているように見えます。みなさんはラベルを編集して修正できます。 記録表のエントリの横にある省略記号メニューをクリックし、 Edit Metadata（メタデータの編集） をクリックします。ラベル欄がフォーム形式で表示され、既存のラベルを追加、編集、または削除できます。図3に示すように、 Save（保存） をクリックして編集したラベルを保存します。 図3：ラベルの値が編集された状態 図 4 に示すように、 Active Recordings（稼働中の記録） 表の記録ラベルが更新されているはずです。 図4：更新されたラベルが表示された Active Recordings（稼働中の記録） 表 Active Recordings（稼働中の記録） 表で、記録の横にあるチェックボックスをクリックし、 Archive（保管） をクリックして記録を保管します。 図 5 に示すように、保管された記録は、稼動中の記録からラベルをコピーします。つまり、稼働中の記録に適用されたメタデータ・ラベルを検索することで、稼働中の記録に関連する保管された記録を簡単に見つけられます。また、Cryostatの書庫にアップロードされた記録には、さらにラベルを追加できます。ラベルは、記録が保管されている限り保存されます。 図5： Archived Recordings（保管された記録） タブでは、各記録にラベルも表示 自動化されたルールで作成されたラベル付き記録 Cryostat 2.1の新UIでJFRの自動化ルールを構築する方法 - 赤帽エンジニアブログ の記事で紹介した自動化ルールは、複数のJDKフライトレコーディングの追跡と管理を簡素化します。自動化ルールは、その記録を作成した自動化ルールの名称を示すメタデータラベルを自動的に適用します。たとえば、自動化ルールの名前が my_automated_rule であった場合、そのルールで生成されたすべての記録には、 Rule: my_automated_rule というメタデータ・ラベルが付きます。これらの記録が保管されるとき、ラベルは保存され、 my_automated_rule によって生成されたすべての記録を簡単に見つけられます。 まとめ この記事では、単一のJDKフライトレコーディング、または自動化されたルールで管理されている場合は複数の記録に対して、記録のメタデータラベルを追加および編集する方法について説明しました。自動化されたルールは、作成した各記録にメタデータラベルを適用させます。 これらのラベルを使った録画の検索や操作については、このシリーズの別の記事「 Manage JFR across instances with Cryostat and GraphQL | Red Hat Developer （英語）」をご覧ください。Cryostatの詳細については、プロジェクトの 入門ページ （英語）をご覧ください。ご質問、コメント、フィードバックは、 GitHub で私たちとつながるか、私たちの メーリングリスト に参加すること自由に感じてください。

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 以前の記事でKubernetes上でサーバーレスのアプリケーション実行を行うKnativeのコンポーネント、Knative Servingについてご紹介させて頂きました。 rheb.hatenablog.com rheb.hatenablog.com Knativeにはもう一つ主要なコンポーネントとしてKnative Eventingがあります。 Knative Eventingはその名前の通り、イベントソースからのイベントを契機としてKnative Servingでデプロイしたサーバーレスアプリを呼び出すためのもので、イベント情報の保持や、どのイベントに対し何のアプリを実行するのかという紐付け行うためのコンポーネントとなっています。 Knative Eventingを使うことで、例えば毎日決まった時間にサーバーレスアプリを起動したり、Kafkaのトピックが配信されたらそれに応じてアプリを起動するといったことが可能となります。 本記事はKnative入門ということでKnative Eventingの概要や仕組みついて解説していきたいと思います。 Knativeで利用可能なイベントソース Knative Eventingでは複数のカスタムリソースを使ってイベントソースの設定、イベント情報の保持、その配信を管理します。 まずイベントソースについて、OpenShiftで利用する場合デフォルトでは以下の4つのSourceを使用することが出来ます。 ・ PingSource 　cronでスケジュールしたタイミングで定期的にメッセージを送信する ・ ContainerSource 　定期的にカスタムのイベントを送信するコンテナイメージをソースとして利用する ・ KafkaSource 　KafkaのTopicメッセージをソースとして利用する ・ ApiServerSource 　APIサーバから得られるKubernetesイベントをKnativeイベントとして利用する また今回は詳細は割愛しますが、Camel Kと連携することで、様々なクラウドサービスを含むより多くのイベントソースを選択することも可能です。 access.redhat.com これらのSourceに対し、あて先を紐づけていきます。Knative Eventingではあて先のことをsinkと呼び、Sourceのマニフェストの .spec.sink にて設定が可能です。 apiVersion: sources.knative.dev/v1 kind: PingSource metadata: name: test-ping-source spec: schedule: "*/2 * * * *" jsonData: '{"message": "Hello world!"}' sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: sample-app 上記のマニフェストではシンプルにsinkとしてKnative ServingのServiceを設定しており、 スケジュールされた時刻（上の例では2分に一度）メッセージを送信しアプリを起動します。 この際イベント情報はCNCFで標準化されている CloudEvents というフォーマットで配信されます。 Sourceに直接Serviceを設定する方法は、直感的にわかりやすい反面、以下のようなデメリットも存在しています。 ・一つのSourceを元に複数のアプリを起動したい場合であっても、sinkとしてリスト型の記述が出来ないため、Source自体を複数作成し管理する必要がある。 ・イベント情報の配信が失敗したとしてもあて先への再送は行われない。 そのためSourceに対し直接Serviceを設定する方法については、開発環境でサーバーレスアプリの動作を試す場合など、限定的に使用するのが良いでしょう。 以降では、これ以外にどのような方法でイベントとServiceの紐付けが可能かを見ていきたいと思います。 Channel ans Subscription 一つ目のパターンがChannel ans Subscriptionです。 このパターンではSourceからのイベント情報をChannelと呼ばれる一時保管場所に置き、その後あて先となるServiceに対し配信を行います。 Sourceの .spec.sink にはServiceを設定する代わりにChannelを指定します。 apiVersion: sources.knative.dev/v1 kind: PingSource metadata: name: test-ping-source spec: schedule: "*/2 * * * *" jsonData: '{"message": "Hello world!"}' sink: ref: apiVersion: messaging.knative.dev/v1beta1 kind: InMemoryChannel name: dafault-channel ChannelからどのServiceにイベントを配信するかを決めるのがSubscriptionというカスタムリソースです。 Subscriptionではマニフェストの .spec.channel で対象のChannelを、 .spec.subscriber で配信先となるServiceを記載し、これらの紐付けを管理します。 apiVersion: messaging.knative.dev/v1 kind: Subscription metadata: name: default-to-service spec: channel: apiVersion: messaging.knative.dev/v1beta1 kind: InMemoryChannel name: default-channel subscriber: ref: apiVersion: serving.knative.dev/v1 kind: Service name: sample-app ここで注目したいのがChannelの種類です。 上記ではInMemoryChannelを指定していますが、これ以外にもApache Kafkaをイベント情報の保存場所とするKafkaChannelを選択することが出来ます。（Upstream版のKnativeではこれ以外にもいくつかChannelの種類が提供されています。） InMemoryChannelの場合、実際にイベント情報を保存するのはPodとなっています。そのため何かの折にPodが再起動したりすると保存されていたイベント情報が消失してしまい、その後の処理が実行できないというリスクが考えられます。 InMemoryChannelの特徴については こちらのページ が参考になるでしょう。 inmemory-channel.yaml (クリックで展開) apiVersion: messaging.knative.dev/v1 kind: Channel metadata: name: default-channel これに対しKafkaChannelの場合、Kafkaを構成するPodの一つが再起動したとしてもイベント情報は保持され、また配信先に対しても少なくとも一度(at least once)は必ず情報が配信されるため、より安定的な運用が可能となります。OpenShiftにおいては、クラスタ上でKafkaを構築することができるAMQ Streams Operatorが利用可能なため、これを使うことで簡単にKafkaChannelを利用することが出来ます。 本格的にKnativeを運用するのであればInMemoryChannelではなく、KafkaChannelの利用を検討するのが良いでしょう。 kafka-channel.yaml (クリックで展開) apiVersion: messaging.knative.dev/v1beta1 kind: KafkaChannel metadata: name: kafka-channel spec: numPartitions: 10 replicationFactor: 3 Broker ans Trigger 二つ目のパターンがBroker and Triggerです。 こちらのパターンも、基本的な考え方としてはChannel and Subscriptionと同様で、Sourceから得たイベント情報をBrokerに一時的保存し、Brokerとアプリの紐付けとしてTriggerを作成します。 Channel and SubscriptionにおけるChannel相当がBrokerであり、Subscription相当がTriggerだと考えると理解しやすいかもしれません。 ただし、Broker and Triggerのパターンでは、Triggerの中でイベント情報のフィルタリングが可能であるという点がChannel and Subscriptionのパターンとは異なっています。 例えば、以下の図のように二つのSourceを一つのBrokerに繋ぎ、イベント情報のフィルタリングを設定しなければ、それぞれのSourceで発生した全てのイベントを契機にアプリが起動、実行することとなります。 対して、Triggerの中でフィルタリング設定を入れることにより、特定のSourceからのイベントのみに反応してアプリを起動するということが可能となります。 Channel and Subscriptionのパターンでは、Sourceの種類ごとに起動するアプリを変えたい場合、その分だけChannelを複数作成する必要がありました。 Broker and Triggerパターンでは、単一のBrokerで複数のSourceからのイベントを受け取り、その属性ごとに配信先の振り分けが可能となるため、よりシンプルに運用することが可能となります。 Triggerにおけるフィルタリングの記述は .spec.filter にて実施します。 この際、ここに書かれた条件に合致する場合のみイベント情報を配信する、という形となるため注意しましょう。 apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: kafka-to-app spec: broker: kafka-broker # 以下の条件に合致する場合のみイベント情報をSubscriberに配信する。 filter: # この例ではSourceがPingSourceの場合のみServiceへの配信が行われる。 attributes: source: /apis/v1/namespaces/test-serverless/pingsources/ping-source subscriber: ref: apiVersion: serving.knative.dev/v1 kind: Service name: sample-app Broker and Triggerパターンを採用する際の注意として、Kafkaを使ったBrokerについては2022年9月現在Tech Previewのステータスとなっています。 そのため商用環境でKafkaBrokerを使う場合は利用やサポートに関しての条件を事前にご確認頂くとよいでしょう。 access.redhat.com OpenShiftコンソールの活用 ここまでKnative Eventingのイベント配信パターンについてご紹介してきました。 最後にKnative関連でOpenShiftのコンソールから操作できる便利なポイントにも触れたいと思います。 Channel and Subscriptionの場合も、Broker and Triggerの場合もカスタムリソースを作成することで、あるイベント情報に対して起動するアプリケーションを決めるわけですが、OpenShiftの場合、コンソールからの操作で必要なカスタムリソースを簡単に作ることが出来ます。 トポロジービュー画面から、紐付けをしたいコンポーネント（上図の場合はBrokerとService）間で矢印をドラッグすると、GUIでTriggerやSubscriptionの作成を行うことができます。 Triggerであれば、マニフェストで記載するのと同様にフィルターについての設定も画面から可能です。 またOpenShift Serverlessをインストールすると、コンソールの監視ダッシュボードから、Serverless関連のメトリクスを確認することができます。 こうした機能が設定不要ですぐに使えるという点もOpenShiftでKnativeが使いやすくなっているポイントと言えるでしょう。 まとめ 今回はKnative Eventingにおける基本的な考え方や、イベント配信のパターンについてご紹介しました。 OpenShiftではコンソールからServerlessを扱いやすくする様々な機能を提供したり、Operatorを使ってKafka等がインストール可能であるため、Knative Eventingに必要な環境を簡単に準備することが出来ます。 本ブログを読んでもしご興味持たれたら是非Knativeを使ったサーバーレスアプリケーションを試してみて下さい！

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 How to build automated JFR rules with Cryostat 2.1's new UI | Red Hat Developer の翻訳記事です。 Cryostatは、Kubernetes上でJDK Flight Recorderのデータを管理するためのツールです。最新バージョンであるCryostat 2.1では、Cryostat 2.0でAPI機能として導入されていた自動化ルールのユーザインタフェースが一新されています。これにより、多くのJavaアプリケーションに対してJDKフライトレコーディング（JFR）を大規模に管理することがより容易になりました。 自動化されたルールの威力 自動化されたルールは、ターゲットJVMに対してJFRを起動し、各ルールが適用されるアプリケーションを判断するための強力かつ柔軟な判定式を提供します。これらの判定式は、ポッド名（文字列の直接比較または正規表現を使用して比較可能）、JMXポート番号、ポッド上に存在するOpenShiftまたはKubernetesラベルやアノテーションなど、ターゲットアプリケーションのさまざまなプロパティを参照できます。 ルールが作成されると、Cryostatはその式に該当するすべてのアプリケーションを選択し、そのルールで定義されたJFRイベントテンプレートを使用して新しい記録を開始します。新しいターゲットアプリケーションインスタンスが発見されるたびに、同じことが起こります。Cryostatは、新しいアプリケーションインスタンスが以前に作成されたルールの式に一致するかどうかを確認し、該当する場合は、イベントテンプレートを使用して新しい記録を開始します。 さらに、自動化されたルールは、ターゲットアプリケーションのメモリからCryostatのストレージに記録データをコピーするためのオプションを含められます。このルールでは、記録データをコピーする頻度と、この保管データの過去のコピーを保存し、最も古いものを削除する頻度を指定できます。 新しいユーザインターフェース 新しいユーザインタフェース（UI）により、この強力な機能をこれまで以上に簡単に使用できるようになりました。入力フォームを表示することで、APIとの連携を容易にするだけでなく（たとえば、持続時間の数値入力）、ユーザーが観察したい対象アプリケーションにぴったり合った式を作成できるよう、その式を入力するためのウィザードが用意されています（図1）。 図1：自動化ルールのUIは、ルールのあらゆる側面を制御するためのフィールドやその他の要素を提供 ターゲットを選択すると、判定式ウィザードはそのターゲットに適合するための簡単な判定式の例を表示します。これは、単に判定式の構文を思い出させるためのヒントとして提供されます。 ビューの右側の分割部分には、選択したターゲットがJSON構造体として表示されます。これには、判定式内で参照できるターゲット・アプリケーションのすべての情報が表示されます（図2）。 図2：ページの右側には、自動化ルールのすべてのパラメーターがJSONとして表示 目的のアプリケーションに適合させるべき表現が決まったら、それを「判定式」フィールドに入力します。UIが更新され、あなたの表現が現在選択されているターゲットに適合するかどうかが、色分けされた形で表示さ れます。 緑色は、指定された式が選択されたアプリケーションに合致することを示します。 黄色は、指定された式が有効な式であるが、選択されたアプリケーションに適合しないことを示します。 赤は、指定された式が無効であることを示し、おそらく不正な構文が原因です。 必要に応じて、表示部が緑色になり、その式がターゲットに判定されるように、判定式を調整します。次に、同じ自動化ルールを適用したい別のターゲットアプリケーションを選択し、表示がまだ緑色であることを確認します。適合しない場合は、両方のアプリケーションで表示が緑になるまで、判定式を再度調整します。また、一致させたくないアプリケーションを選択し、その表示が黄色であることを確認することもできます。 図3では、 target.labels.deployment == "quarkus-test" という判定式を記述しています。緑色とチェックマークは、この式が選択されたターゲットアプリケーションに合致することを示します。 図3：チェックマークと緑のハイライトは、ターゲットアプリケーションに合致するルールを示す 判定式の構文、自動化ルール API、およびいくつかの使用例についての詳細と情報については、Red Hat Developer の以前の記事「 JDK Flight Recorderのコンテナでの自動化 - 赤帽エンジニアブログ 」 を参照してください。 このフォームを送信した後、Automated Rules ビューに戻り、新しいルールの定義が表に表示されるはずです。Cryostatは直ちにすべての既知のターゲットアプリケーションをチェックし、判定式がそれらに適合するかどうかを評価し、適合する場合は、定義した設定を使用して記録を開始します。将来のターゲットアプリケーションが発見された場合、それらも自動的に判定され、必要に応じて記録が開始されます。 次回：Cryostat記録のラベル付け方法 Cryostat 2.1では、記録物に対してラベルを追加する新機能が導入されました。自動化されたルールによって記録が開始されると、その記録を開始したルールの名前を指定するラベルが自動的に付与されます。このラベルは、録画がストレージにコピーされた場合にも適用されます。この機能については、近日中に記事を掲載する予定です。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、Red Hat Developerのブログ記事、 How to log into Cryostat 2.1 on OpenShift: SSO for all | Red Hat Developer の翻訳記事です。 Kubernetes上でJDK Flight Recorderのデータを管理するツールであるCryostatは、Cryostat 2.1の技術プレビューリリースとして、Red Hat OpenShift上の組み込みOAuthサーバーに統合されました。OpenShift上のCryostatにログインすると、OpenShiftのログインページにリダイレクトされ、OpenShiftのユーザーアカウントに対応するユーザー名とパスワードを入力するよう促されます。成功すると、複数のセッションでログイン状態を維持できます（デフォルトで24時間）。 CryostatはOpenShiftの認証を何に使っているのですか？ Cryostatがコンテナ化されたJava仮想マシン（JVM）で動作するJavaアプリケーションを監視するために、CryostatはCryostatがデプロイされている同じ名前空間内でターゲットアプリケーションを検索します。これは、Cryostat が Pod やデプロイメントなどの Kubernetes オブジェクトを検出するために、OpenShift ユーザーアカウントからの権限が必要であることを意味します。ユーザがターゲットアプリケーション上で JDK フライトレコーディングを開始、停止、または保存するリクエストを行うたびに、Cryostat はユーザのリクエストが同じ名前空間から来ること、およびユーザが各ターゲットアプリケーション上の JDK フライトレコーディングを表示および管理するアクセス権を持っていることを確認します。 Cryostat 2.0からのCryostat認証の変更点 Cryostat 2.0では、ユーザーはOpenShiftコンソールからCryostatログインページに認証トークンを貼り付け、ブラウザセッションの更新時にトークンを再入力する必要がありました。 Cryostat 2.1では、OpenShiftのOAuthサーバとCryostatのRBAC権限を組み合わせ、OpenShiftのユーザアカウントごとに設定可能な権限をユーザに与えています。デフォルトでは、各Webブラウザセッションは24時間継続します。 Cryostat 2.1へのログイン方法 この記事は、OpenShift 4.6+のクラスタでCryostatのインスタンスが動作していることを想定しています。Cryostat のインストール方法については、 Getting started with Cryostat 2.1 を参照してください。 Cryostatのインスタンスが稼働したら、OpenShiftのWebコンソールにログインし、Installed Operatorsに移動し、Cryostat Operatorを選択します。そこから、[Cryostat]タブで目的のCryostatインスタンスを選択します。[Application URL] リンクをクリックしてログイン画面にアクセスし、OpenShift ユーザアカウントのユーザ名とパスワードを入力します。 Cryostatのすべての機能にアクセスするには、OpenShiftのユーザアカウントにRBAC権限を要求する必要があるかもしれません。制限された権限を持つユーザーは、それらが許可されているCryostatの機能のみにアクセスできます。例えば、読み取り専用権限を持つユーザは、他のユーザが作成したJDKフライトレコーディングを見れますが、レコーディングを作成したり削除できません。この記事の執筆時点では、Cryostat の全機能にアクセスするためには以下の権限を持つユーザが必要です。 - apiGroups : - "" resources : - pods verbs : - create - get - apiGroups : - "" resources : - replicationcontrollers - endpoints verbs : - get - apiGroups : - operator.cryostat.io resources : - cryostats verbs : - create - delete - get - apiGroups : - operator.cryostat.io resources : - flightrecorders - recordings verbs : - create - delete - get - patch - apiGroups : - apps resources : - deployments verbs : - create - get - apiGroups : - apps resources : - daemonsets - replicasets - statefulsets verbs : - get CryostatのRBAC権限の概要 複数のユーザーが一つの名前空間でCryostatを使用してJDKフライトレコーディングを管理しており、各ユーザにCryostatの機能に対する特定の権限を与えたい場合、希望のCryostat固有のRBAC権限を持つロールを作成し、そのロールを希望のユーザアカウントに紐付けます。 一般的に、Cryostatは前のセクションで列挙した apiGroups: "" と apiGroups: apps リソースに対して get パーミッションを使用し、名前空間内の任意のターゲットアプリケーションを検出します。Cryostatの flightrecorders と recording リソースに対する create 、 delete 、 get 、 patch パーミッションは、ユーザーがターゲットアプリケーションからJDKフライトレコーディングを作成、削除、取得、保存できるようにします。 まとめ この記事では、OpenShift 上の Cryostat 2.1 にログインする方法を説明し、ユーザーアカウントに必要な RBAC 権限の概略を説明します。RBAC権限の定義の詳細については、OpenShift Container Platformの ドキュメント をご覧ください。Cryostatの詳細については、cryostat.ioを参照してください。質問、コメント、フィードバックについては、Githubで私たちとつながるか、メーリングリストに参加することをお気軽にどうぞ。

Red Hatの森若です。 今回はRHELで『よくわからないサービス』が動作しているときに、調べる方法を見てみます。 謎(?)のサービス systemctl -t service のようなコマンドを使うと、そのシステムでのサービス一覧を見ることができます。 $ systemctl -t servce (中略) osbuild-composer.service loaded active running OSBuild Composer osbuild-dnf-json.service loaded active running OSbuild dnf-json service osbuild-worker@1.service loaded active running OSBuild Composer Worker (1) (以下略) この記事では、馴染みがないサービスを見つけた時の調べ方をみていきます。 今回は例としてこの osbuild-composer.service が何をするためのサービスか調べてみます。 サービスの設定を見る systemdのサービスから対応する設定(unitファイル)を見るには、 systemctl cat コマンドを使います。 サービスによってはunitファイル内にDescriptionやDocumentationが定義されていて何なのかが記載されていたり、 ドキュメントへのリンクを見つけたりできます。 unitファイルを表示させてみましょう。 # ではじまる行は設定ファイル名または設定ファイル中のコメントです。 $ systemctl cat osbuild-composer.service # /usr/lib/systemd/system/osbuild-composer.service [Unit] Description=OSBuild Composer Requires=osbuild-dnf-json.socket After=network.target (中略) ExecStart=/usr/libexec/osbuild-composer/osbuild-composer (以下略) Descriptionは"OSBuild Composer"ということで特に追加の情報はありませんでした。 Documentationは記載がありませんでした。 ExecStart はサービスを起動するためのコマンドです。これも osbuild-composer という名前で追加の 情報はありませんでした。 "OSBuild Composer"が正式名称のようなのでこの名前でGoogle検索する方法もありますが、もう少し粘ってみます。 rpmパッケージを探す 前のステップでサービスに対応するunitファイルや、実行ファイルの名前がわかりました。 あるファイルに対して、どのrpmパッケージに含まれているかを探すには rpm -qf コマンドを使います。 rpmパッケージに含まれていないファイル場合はその旨が表示されます。 これらのファイルを提供しているrpmパッケージを探してみましょう。 $ rpm -qf /usr/lib/systemd/system/osbuild-composer.service osbuild-composer-46.3-1.el9_0.x86_64 $ rpm -qf /usr/libexec/osbuild-composer/osbuild-composer osbuild-composer-core-46.3-1.el9_0.x86_64 これらのファイルはrpmパッケージでインストールされたもののようで、対応するパッケージ名が表示されました。 rpmパッケージにはファイルだけでなく各種のメタデータが含まれていて、システムへインストールしたrpmパッケージのメタデータをあとで表示・検索できます。 rpmパッケージの概要を表示するには rpm -qi コマンドを使います。 $ rpm -qi osbuild-composer osbuild-composer-core Name : osbuild-composer Version : 46.3 Release : 1.el9_0 Architecture: x86_64 Install Date: Thu 19 May 2022 08:44:15 PM JST Group : Unspecified Size : 17645 License : ASL 2.0 Signature : RSA/SHA256, Sun 01 May 2022 12:33:21 AM JST, Key ID 199e2f91fd431d51 Source RPM : osbuild-composer-46.3-1.el9_0.src.rpm Build Date : Fri 29 Apr 2022 03:25:01 AM JST Build Host : x86-vm-55.build.eng.bos.redhat.com Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Vendor : Red Hat, Inc. URL : https://github.com/osbuild/osbuild-composer Summary : An image building service based on osbuild Description : A service for building customized OS artifacts, such as VM images and OSTree commits, that uses osbuild under the hood. Besides building images for local usage, it can also upload images directly to cloud. It is compatible with composer-cli and cockpit-composer clients. (以下略) Description を機械翻訳してみます。 VMイメージやOSTreeコミットなど、カスタマイズされたOSアーティファクトを 構築するためのサービスで、osbuildを基盤としています。ローカルで使用する イメージの構築のほか、クラウドに直接アップロードすることも可能です。 composer-cli、cockpit-composerクライアントと互換性があります。 どうやらosbuild-composerは仮想マシンイメージなどを作るためのサービスのようです。 URLの欄にアップストリームプロジェクトへのリンクがあります。 パッケージによってはリンク切れになっている場合もあるのですが、今回は到達できました。 github.com ここから詳しい説明が得られそうです。 rpmパッケージ内のドキュメントを探す URLに到達できない場合もありますから、もう少しRHELの中で調べる方法を見ていきます。 rpmパッケージ内にはドキュメントが含まれているかもしれません。 rpm -qd コマンドでパッケージ内のドキュメント一覧を表示します。 $ rpm -qd osbuild-composer osbuild-composer-core /usr/share/doc/osbuild-composer/README.md /usr/share/man/man7/osbuild-composer.7.gz 2つのファイルが見つかりました。読んでみると、README.mdはさきほどのgithubにあるREADME.mdで、man 7 osbuild-composerは概要説明になっていました。 $ less /usr/share/doc/osbuild-composer/README.md $ man 7 osbuild-composer 関連パッケージを探す ドキュメントが実行ファイルとは別のパッケージとして提供されていて、上記の方法では見つからない場合もあります。 パッケージ名の先頭の単語 (今回の例では osbuild ) をキーワードにして検索すると、関連するパッケージを探すことができます。 何か手がかりがあるかもしれません。 yum search コマンドで関連パッケージを検索してみます。 この検索ではシステムにインストールされていないrpmパッケージも表示されます。 $ sudo yum search osbuild Updating Subscription Management repositories. Last metadata expiration check: 0:09:23 ago on Thu 28 Jul 2022 02:30:28 AM JST. ======================================== Name Exactly Matched: osbuild ========================================= osbuild.noarch : A build system for OS images ======================================= Name & Summary Matched: osbuild ======================================== osbuild-composer.x86_64 : An image building service based on osbuild osbuild-composer-core.x86_64 : The core osbuild-composer binary osbuild-composer-dnf-json.x86_64 : The dnf-json binary used by osbuild-composer and the workers osbuild-composer-worker.x86_64 : The worker for osbuild-composer ============================================ Name Matched: osbuild ============================================= osbuild-luks2.noarch : LUKS2 support osbuild-lvm2.noarch : LVM2 support osbuild-ostree.noarch : OSTree support osbuild-selinux.noarch : SELinux policies python3-osbuild.noarch : A build system for OS images =========================================== Summary Matched: osbuild =========================================== weldr-client.x86_64 : Command line utility to control osbuild-composer

Red Hat のソリューションアーキテクトの瀬戸智です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトがご紹介していきます。 今回は 2022/9月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: Apache Kafka 超入門 AMQ StreamsのベースとなっているApache Kafkaの入門記事です。 近年各企業で採用が進んでいる分散メッセージングシステムの「Apache Kafka」について今一度概要をご紹介いたします。 rheb.hatenablog.com 特集2: MTAを使用してWebLogic/WebSphereからJBoss EAPへの移行を検討する JBoss EAPはJava EEに準拠したアプリケーションサーバーです。Red Hatでは他のJava EE準拠のAPサーバーからJBoss EAPに移行するときに使用できるツールを準備しています。 そちらの使用方法をまとめました。 rheb.hatenablog.com JakartaOne Livestream - Japan 2022年9月16日(金) 午後１時～ に開催！ Red Hatを含めたいくつかのJava EE/Jakarta EEベンダーが協力してイベントを立ち上げました！ Jakarta EE 10もリリースされて、最新の情報を集めるには良いチャンスです。 ぜひご参加ください！ jakartaone.org Red Hat Summit: Connect | Japan 2022 年10月27日(木) に開催決定！ Red Hat Forum が Red Hat Summit: Connect | Japan と名前を変え3年ぶりに対面イベントとして開催されることになりました！ イベントの参加登録開始は先となりますが、ぜひ日程を開けておいてください！ 参加費は無料です。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat Debezium 1.9 Red Hat 3scale API Management 2.12.0 Red Hat Process Automation Manager 7.13.0 Camel for Spring Boot 3.14

Red Hat のソリューションアーキテクトをしている瀬戸です。 このたびJBoss EAPや他のJavaアプリケーションサーバーが依存しているJava EE/J2EE仕様がJakarta EE仕様と名前を変えてリリースされます。 前回の大きな仕様変更が行われたのはJava EE 8が2017年9月にリリースされた時で、それからおおよそ5年ぶりの大きな仕様変更となります。 その中にはネームスペースの変更や一部機能の削減も含まれており、また、WebSphereはOpenLibertyとして作り直され互換性への影響もあり、 それならとJBoss EAPへの移行を検討されている方もいらっしゃると思います。 Jakarta EE対応のEAPはまだリリースされていませんが、事前に検討だけでもしておくことは良いことです。 以前、 JBoss EAP 6のセキュリティフィックスが行われなくなるのでEAP 7への移行を検討する という記事で紹介したMTA(Migration Toolkit for Applications)を使用することで WebLogic/WebSphereからEAPへの移行に必要な作業も見積もることができます。 MTAはいわゆる静的解析ツールで、ルールに基づいて移行に必要な作業を見つけ出すことができます。 前回の記事 ではGUI形式での機能の紹介をしました。 今回の記事では、CI環境に組み込むことを前提にコマンドラインで操作をしてみたいと思います。 ※初めて行う場合は直感的に操作できるGUIの方が楽です。慣れるまではそちらを使用することをお勧めします。 前回の記事 ではGUIでの使用方法を説明していますので、そちらを参照してください。 Optionsのsourceにeap6の代わりにweblogicもしくはwebsphereを指定する必要があるだけで、他の使用方法は全く同じです。 また、移行作業に必要なすべての作業をMTAで漏れなく見つけだすことはできない点は注意してください。 例えば、個別の業務ロジックに紛れ込んでいる環境固有のコードは別途修正する必要がありますし、必要に応じて性能検証を行う必要もあります。 この記事は以下の環境で動作確認しています。 Windows 11 Pro 22000.856 openjdk version "11.0.16" 2022-07-19 LTS OpenJDK Runtime Environment (Red_Hat-11.0.16+8-2) (build 11.0.16+8-LTS) OpenJDK 64-Bit Server VM (Red_Hat-11.0.16+8-2) (build 11.0.16+8-LTS, mixed mode) ※この記事ではコマンド例はすべてWindows版で記載されていますが、Mac、Linux等でも動作可能です。 MTA(Migration Toolkit for Applications)の入手 MTAは以下のページからダウンロードすることができます。※要Red Hatアカウント developers.redhat.com 今回はコマンドライン版を使用します。 ページを下に移動して、All DownloadsからMigration Toolkit CLI版をダウンロードします。この記事ではv5.3を使用しています。 zipファイルがダウンロードされますので適切な位置に解凍してください。 使い方 コマンドプロンプトを使用して解凍先の .\bin に移動して、 mta-cli.bat を実行することで解析を行うことができます。 主に指定するオプションは以下の通りです。 --source 移行元がWebLogicなら weblogic 、 WebSphere なら websphere --target 移行先のアプリケーションサーバー、EAPの場合は eap:7 --input 解析対象のwar、earもしくはフォルダ --sourceMode (オプション)フォルダを指定する場合に指定 --output レポートの出力先フォルダ --packages (オプション)解析対象のパッケージ、指定しない場合は依存ライブラリも含めてすべて解析してしまい時間がかかるので、指定するのを強く推奨、複数指定する場合はスペース区切り --exportCSV (オプション)指定すると追加でCSVファイルを出力する、何か別のツールで統計を取りたい場合にあると便利なので、とりあえず指定する(オーバーヘッドはほぼない) --overwrite (オプション)指定するとレポートの出力先にすでにファイルがあった場合に無確認で上書きする(指定しない場合はプロンプトで確認を求められる) コマンドのサンプルとしては以下のようになります。 WebLogicのear(もしくはwar)ファイルを解析する。 mta-cli --source weblogic --target eap:7 --input C:\source.ear --output c:\EXPORT_DIR --packages com.acme --exportCSV WebLogicのソースコードの入ったプロジェクト(フォルダ)を解析する。 mta-cli --source weblogic --target eap:7 --input C:\SOURSE_DIR --sourceMode --output c:\EXPORT_DIR --packages com.acme --exportCSV WebShepreのearファイルを解析して解析結果を解析する。出力先のフォルダがすでにあった場合は削除してから出力する。 mta-cli --source websphere --target eap:7 --input C:\source.ear --output c:\EXPORT_DIR --packages com.acme --exportCSV --overwrite 解析結果を確認する 解析結果はoutputに指定したフォルダに出力されます。中身自体は 前回の記事 で説明したものと全く一緒ですので、そちらを参照してください。 まとめ Javaのアプリケーションサーバーの移行は古いサーバーの機能と新しいサーバーの機能の両方を知らないといけないため、通常は大きな労力がかかりますが、MTAを使用することで労力を削ることができます。 移行時の選択肢が増えることは良いことだと思いますし、簡単に実行することもできますので、ぜひ試してみてください！ また、MTAはここで紹介した以外にもいくつかのオプションを備えています。 今回は紹介しませんでしたが、まだEAPが対応していないJakarta EE *1 への移行についても解析できるオプションも提供されています。そちらはEAP専用というわけではなくすべてのEEアプリに使用できます。EAPへの移行をしない場合でも試す価値はあります。 使い込みたい場合はマニュアルを参照してみてください。 access.redhat.com 参考資料 JBoss EAP 6のセキュリティフィックスが行われなくなるのでEAP 7への移行を検討する https://rheb.hatenablog.com/entry/2022/05/13/JBoss_EAP_6%E3%81%AE%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%83%95%E3%82%A3%E3%83%83%E3%82%AF%E3%82%B9%E3%81%8C%E8%A1%8C%E3%82%8F%E3%82%8C%E3%81%AA%E3%81%8F%E3%81%AA%E3%82%8B%E3%81%AE MTA ダウンロード(要Red Hatアカウント) https://developers.redhat.com/products/mta/download Migration Toolkit for Applications の概要 https://access.redhat.com/documentation/ja-jp/migration_toolkit_for_applications/5.3/html/introduction_to_the_migration_toolkit_for_applications/index Migration Toolkit for Applications CLI ガイド https://access.redhat.com/documentation/ja-jp/migration_toolkit_for_applications/5.3/html-single/cli_guide/index *1 : upstreamのwildflyではすでに対応されています。

Red Hatの森若です。 「RHELをインストールしたらよくわからない物がいっぱい動いてるなぁ」と思う方むけの記事です。 RHEL 9を最小構成(minimal + Standard)でインストールした時にデフォルトで動作しているプロセスをそれぞれ1〜2行で紹介してみます。 minimal + Standardを選択します インストーラ内でRed Hat Subscription Management(RHSM)とRed Hat Insightsへ登録します。 インストールが完了したところでさっそくコンソールからログインして、pstreeコマンドでプロセスの様子を見てみます。 実質的に何もしていませんから、プロセスの数はそれほど多くありません。 systemd-+-NetworkManager---2*[{NetworkManager}] |-atd |-auditd-+-sedispatch | `-2*[{auditd}] |-chronyd |-crond |-dbus-broker-lau---dbus-broker |-firewalld---{firewalld} |-irqbalance---{irqbalance} |-login---bash---pstree |-lsmd |-polkitd---11*[{polkitd}] |-rhsmcertd |-rsyslogd---2*[{rsyslogd}] |-sshd |-systemd---(sd-pam) |-systemd-journal |-systemd-logind |-systemd-udevd `-tuned---3*[{tuned}] システムの基本的な管理を行うためのサービス群: systemd: システム全体の起動・終了、サービスの起動・終了などを管理する NetworkManager: ネットワーク接続の設定管理・有効化・無効化を行う dbus-broker-launch, dbus-broker: 1システム内でのメッセージ送受信を行うdbusサービスを提供。systemdやNetworkManagerなどはdbus経由でAPI(application program interface)を提供している。 polkitd: dbus経由で一般ユーザからシステムのサービスへリクエストを送った時に権限管理ポリシーを処理する。 systemd-udevd: デバイスの挿抜や状態変更などのイベントをうけてコマンドを実行したりファイル操作を行う。 systemd-logind: ユーザのセッション、linuxコンソールに対応するagettyの起動、電源管理API、ユーザ毎のデバイスアクセス管理などを行う。 自動的なチューニングを行うサービス群: irqbalance: ハードウェアからの割り込みを処理するCPUを振り分けるデーモン。無いとほとんどの割り込みがCPU 0に割り当てられるので起動推奨。 tuned: システムの自動チューニングを行うデーモン。ハードウェア環境から該当しそうなプロファイルを自動選択します。 ログの記録に関係するサービス群: auditd: linux kernelやプロセスからの監査ログの受取とストレージへの記録を行うデーモン sedispatch: SELinuxのAVC(access vector cache)ログが監査ログへ出力されると、読みやすいログを出力するsetroubleshootdを呼び出す。 systemd-journal: 各種ログ出力をうけつけ、journalとよばれるデータベースへ保存するデーモン rsyslogd: systemd-journaldのjournalを設定に従いフィルタして/var/log/messagesのようなファイルへ保存したり他のホストへ転送する。他ホストからのsyslogメッセージの受け付けも行う。 (場合によっては)無くてもなんとかなるサービス群: chronyd: NTP(network time protocol)による時刻同期を行うデーモン。時刻がずれると証明書が正しく処理できなくなるため起動推奨。 atd: atもしくはbatchコマンドによるジョブ実行のためのデーモン crond: 定期実行をを行うためのデーモン sshd: ssh(secure shell)デーモン。システム外部からのログインをうけつけ、認証したのちシェルを起動して対話的に利用するためのサービス。 firewalld: ファイアウォールを設定・管理するデーモン lsmd: libstoragemgmt(ストレージアレイ管理用ライブラリ)のプラグイン用デーモン。 RHEL特有のサービス: rhsmcertd: RHSMで利用する証明書の定期更新を行うデーモン。RHSMかRed Hat Satelliteを利用する場合には必須。 ログインに関係するプロセス群: login: バナーとログインプロンプトを表示してユーザのログインを待ちうけるプロセス。 (sd-pam): systemdでPAMセッションを追跡するために利用されるプロセス。 bash: シェル pstree: 実行中のpstreeコマンド 気になるものや知らなかったものがあったら調べてみましょう。

レッドハットの杉村です。Ansible のテクニカルサポートをしています。 テクニカルサポートは土日祝日年末年始は全員休みというわけにはいかず、平日よりは少ない体制で問い合わせに対応するようにしています。今回の土日は当番になりました。空き時間ができましたのでブログを書いています。 twitter の #ansiblejp で最近少々話題になっていたのですが、Ansible Automation Platform (AAP) のジョブからファイルを保存したいときにどうするのがいいのかというお話がありました。AAP 2 からは実行環境がコンテナになったため、以前の Ansible Tower 時代とはアーキテクチャが異なっています。 まず大前提としては、原則としてはコントローラ上にはそういうファイルを置くべきではないというのがあります。ジョブの実行時に一時的にファイルを作成することはあっても、実行が終わったら消えるというのが想定した使い方です。 コントローラでは複数のユーザがさまざまなジョブを実行します。AAP のユーザ権限を細かく決めることができるというのに、ファイルは共通して自由に読み書きできるということができてしまってはその権限設定の意味がなくなってしまうこともあります。また、コントローラが稼働するOS上にファイルを置きますと、コントローラや実行ノードが分散しているときにはスケールしないこともあります。ストレージが溢れないように監視する必要があるかもしれませんし、バックアップやリストアも求められることがあるかもしれません。基本的に手間が増えるだけでいいことがないのです。 それでもどうしてもファイルを置きたいんですという要望も確かにありまして、どうすればできるのかを少々考えてみようと思います。AAP 2.2 (RHEL 8.6 / ansible-core 2.13) で動作検証しています。 こちらに詳しく書かれていますので、あわせて参照してください。この著者の Phil Griffiths とも金曜にこの件で少々話をしたばかりです。 www.ansible.com 用意したディレクトリ OS 上のディレクトリに置く例と、NFS に置く例を検証してみました。OS からは awx ユーザで書き込みできるようにしておいてください。NFS に置くことができれば、複数のコントローラや実行ノードがあっても、それぞれから読み書きできるようになることが期待されます。 # ls -ld /share /nfs drwxrwxrwx. 2 root root 71 8月 21 2022 /nfs drwxr-xr-x. 2 awx awx 6 8月 21 18:02 /share # mount | grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) 192.168.0.XXX:/share on /nfs type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.YYY,local_lock=none,addr=192.168.0.XXX) 実行したいプレイブック ただ単にファイルを書いてみる例です。 --- - hosts: all gather_facts: false tasks: - name: store something into an external file (share) copy: content: "this is a pen, that is a book" dest: /share/result.txt mode: '0644' tags: - localshare - name: store something into an external file (NFS) copy: content: "this is a pen, that is a book" dest: /nfs/result.txt mode: '0644' tags: - nfs コマンドラインから実行 awx ユーザで実行してみました。それぞれ意図通りファイルを書き出しています。 $ whoami awx $ ansible-playbook playbook.yml -i localhost, -e ansible_connection=local -t nfs PLAY [all] *************************************************************************************************************************************************************************************** TASK [store something into an external file (NFS)] *********************************************************************************************************************************************** changed: [localhost] PLAY RECAP *************************************************************************************************************************************************************************************** localhost : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 $ ansible-playbook playbook.yml -i localhost, -e ansible_connection=local -t localshare PLAY [all] *************************************************************************************************************************************************************************************** TASK [store something into an external file (share)] ********************************************************************************************************************************************* changed: [localhost] PLAY RECAP *************************************************************************************************************************************************************************************** localhost : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 $ ls -l /nfs/ /share/ /nfs/: 合計 4 -rw-r--r--. 1 awx awx 29 8月 21 18:08 result.txt /share/: 合計 4 -rw-r--r--. 1 awx awx 29 8月 21 18:08 result.txt AAP から実行 プロジェクトとジョブテンプレートを作成しました。ジョブテンプレートでは実行時に tag を入力して処理を切り替えられるようにしています。 実行してみると、このように書き出すディレクトリを見つけられずにエラーになります。実行環境はコンテナの中で動いており、そこにはこのディレクトリはないからです。 Settings > Jobs setting > Paths to expose to isolated jobs の設定で、コンテナがマウントするディレクトリを設定することができます。初期値はこのようになっています。 これは podman の -v (--volume) オプションとして実行時に渡されます。このように :rw をつけて定義することで、コンテナからも読み書きできるディレクトリとして認識させることができます。 [ "/etc/pki/ca-trust:/etc/pki/ca-trust:O", "/nfs:/nfs:rw", "/share:/share:rw", "/usr/share/pki:/usr/share/pki:O" ] この設定で、ローカルディレクトリもNFSも両方とも正しく書き込むことができました。 コントローラから見ても正しく保存されていることがわかります。 $ ls -lZ /nfs /share /nfs: 合計 4 -rw-r--r--. 1 awx awx system_u:object_r:nfs_t:s0 29 8月 21 18:27 result.txt /share: 合計 4 -rw-r--r--. 1 awx awx system_u:object_r:container_file_t:s0:c98,c728 29 8月 21 18:27 result.txt $ cat /share/result.txt this is a pen, that is a book $ cat /nfs/result.txt this is a pen, that is a book podman のオプションについては man podman-run を見てください。 設定の注意点 このようにローカルファイルをマウントしてコンテナから読ませるようにする設定は AAP 2.1.2 から導入されたのですが、2.1.x ではこのオプションには :O と :z のどちらかしか設定できないという制限があります。 O (大文字のO) : 一時的なディレクトリを作って読み書きし、実行が終わったら削除する z (小文字のz) : SELinux のラベルを付け替える もしこのオプションをつけないときには、安全のため :z が初期値として設定されます。NFS のディレクトリでは SELinux のラベルを付け替えることはできないため、例えば今回の例で /nfs:/nfs:z と設定するとエラーになります。 :rw で使いたい場合には、AAP 2.2 を使ってください。 :O を設定したときはジョブの動作はしますが、処理が終わりますと削除されるため、後でコントローラ上のOSコマンドでディレクトリを見てもファイルは見つかりません。 他の方法 今回はローカルディレクトリにデータを書いてみるという例でしたが、他の方法としては Amazon S3 などのクラウドストレージに書く方法もあります。 docs.ansible.com もしデータが小さいようであれば、以前紹介した fact に保存する方法も利用できます。fact は AAP のデータベース上にホストごとのデータとして保存するものです。 rheb.hatenablog.com 要件にあわせていろいろな方法を検討してみてください。 まとめ 最近いくつか話題になったファイルの書き出しについて検証してみました。AAP 2.1.2 から少しずつ改善され、2.2 ではより自由度も増しました。問い合わせを受けてサポートエンジニアから開発チームに伝えることもよくありますので、もしお困りの際はご相談ください。 Ansible Automation Platform の評価ライセンスリクエストはこちらからご利用いただけます。60日間利用できます。 www.redhat.com Happy Automation!

レッドハット　ソリューションアーキテクト石倉です。 この記事は、RED HAT BLOGのブログ記事、 High availability for SAP on Red Hat Enterprise Linux の翻訳記事です。 Red Hat Enterprise Linux (RHEL) は、アプリケーションおよびデータベース (DB) レベルでビジネスクリティカルなワークロードに高可用性 (HA) を長期間提供してきました。 これにより、サービスのアップタイムを最大化し、予期しない中断を最小限に抑え、重要な環境をより回復力のあるものにしています。 RHEL High Availability Solutions for SAP (Red Hat Enterprise Linux for SAP Solutions サブスクリプションに含まれるRHEL HA アドオンで実現します) を利用することで、共有ファイルシステム、データベース、メッセージ サーバー、エンキュー サーバーなどの単一障害点 (SPOF) を回避することが出来ます。 SAP HANA の場合、DB にはSAP社が提供する、 SAP HANA システム レプリケーション (HSR) と呼ばれるメカニズムが組み込まれています。 このメカニズムでは、DB を 1 つ以上のノードに複製しますが、問題が発生した場合の自動フェイルオーバーは提供しません。 代わりに、RHEL HA Solutions for SAP が自動フェイルオーバーを処理します。 RHEL HA Solutions for SAP を活用することで、真夜中に DB の手動フェイルオーバーを実行する必要がなくなり、SAP Basis エンジニアはよりぐっすりと眠ることができます。 Red Hat と SAP社 のコラボレーションは、DB レイヤーとアプリケーション レイヤーの両方に組み込まれた新しい HA シナリオとモデルが RHEL HA Solutions for SAP によってカバーされ、利用ユーザがその恩恵を受けることができることを意味します。 Red Hat は、RHEL のさまざまなリリースで HA の広範なテストを実行し、それぞれのシナリオとモデルで SAP社 の認定を取得しています。 アプリケーション レベルでの高可用性について アプリケーションレベルでは、HA を実現するために ENSA1 と ENSA2 という 2 つのモデルが SAP社 より提供されています。 ENSA1 モデルは SAP NetWeaver ベースの古いバージョンの SAP 製品で使用されます。 一方、ENSA2 モデルは SAP NetWeaver (version 7.51以降) と SAP S/4HANA (version 1809以降) で利用が推奨されています。 どちらのモデルでも、エンキュー サーバー (すべてのユーザーロック依頼をロックテーブルに格納するサーバー) が複製され、障害が発生した場合に DB でデータが上書きされないため、一貫性が保たれます ( ENSA1 と ENSA2 の違いの詳細については、次のブログ、「 Evolution of ENSA2 and ERS2… | SAP Blogs 」 を参照してください)。 前述の SAP HANA システム レプリケーションのケースと同様に、フェイルオーバーは自動的に行われないため、RHEL HA Solutions for SAP は、このレイヤーを 2 つ、ないし 3 つ以上のノードのクラスターに追加します (3 つ以上のノードは、ENSA2 を実装する場合にのみ適用出来ます)。 一部の利用ユーザは、コストを削減するために、同じサーバーに DB とアプリケーションを配置する場合があります (主にクラウド サービスを使用していて、支出を最小限に抑える必要がある場合)。 また、プライマリ アプリケーション インスタンス (PAS) と他のアプリケーション インスタンスも 1 つのホスト上に持つことができます。 これらのシナリオ、いわゆるコスト最適化デプロイメントも、RHEL HA Solutions for SAP でカバーされています。 HANA システム レプリケーションと ENSA2 の両方を単一クラスターで管理する場合の HA クラスターをセットアップ方法の詳細については、Red Hat カスタマー ポータルの 「 Configuring Cost-Optimized SAP S/4HANA ASCS/ERS/HDB with Standalone Enqueue Server 2 (ENSA 2) in a Pacemaker Cluster - Red Hat Customer Portal 」を参照してください。 DB レベルでの高可用性について DB レイヤーの可用性については、ここでは SAP HANA に焦点を当てます。 SAP HANA インスタンスは、1 つのサーバーにインストールすることも、複数のサーバーに分散してリソースを増やすこともできます。 1 つのサーバーにインストールするケースは、追加のリソースが必要な場合に同じサーバーに追加されるため、「スケールアップ構成"scale-up deployment"」と呼ばれ、複数のサーバーに分散するケースは「スケールアウト構成"scale-out deployment"」と呼ばれます。 両方のケースで高可用性を提供できます。 最初のケースでは、同じリソースを持つ同一のインスタンスが (同じリソースと SID を持つ) 別のサーバーにインストールされ、2 番目のケースでは、同じ構成が同じ数のホストに複製されます。 前述したように、SAP HANA システム レプリケーションはデータのレプリケーションと一貫性を提供しますが、問題が発生した場合にリソースの自動フェイルオーバーを処理するには、RHEL HA Solutions for SAP などのクラスター ソリューションが必要です。 さらに冗長性を実現するために、SAP HANA 1.0 SP12 ではマルチティア システム レプリケーション"Multitier System Replication"が導入されました。 これにより、DB が複製され、レプリカが第 3 層に複製されます。 その後、SAP HANA 2.0 SP03 でマルチターゲット システム レプリケーション"Multitarget System Replication"が導入され、元の DB を複数のターゲットに同時にレプリケートすることで、さらなる冗長性が提供されます。 マルチターゲットではセカンダリに障害が発生した場合でも、3 番目はプライマリと同期されますが、マルチティアでは、セカンダリに障害が発生した場合、プライマリの変更が 3 番目に伝播されなくなります。 どちらのシナリオも、RHEL 8 for SAP Solutions 以降の RHEL HA Solutions for SAP の現在のバージョンでサポートされています。 また、もう一つ、追加のコスト最適化シナリオがあります。 このシナリオでは、セカンダリ サーバーはプライマリ DB のレプリカを持つだけでなく、例えば、DEV または QAS といった本番以外のインスタンスの DB もホストします。 両方の DB がシステムリソースを共有することになるため、フェールオーバーの際は、すべてのリソースを本番データベースに割り当てるために、最初に DEV/QAS DB をシャットダウンする必要があります。 RHEL HA Solutions for SAP は、RHEL 8 for SAP Solutions (およびそれ以降) のバージョンでこのソリューションをサポートしています。このソリューションの詳細については、「 Automating Cost-Optimized SAP HANA Scale-Up System Replication using the RHEL HA Add-On - Red Hat Customer Portal 」を参照してください。 下の記事では、サポートされているすべての HA シナリオの詳細な説明を見つけることができます。 Supported HA Scenarios for SAP HANA, SAP S/4HANA, and SAP NetWeaver - Red Hat Customer Portal 自動化ソリューションの活用について Red Hat Ansible Automation Platform は、クラスターの作成や運用を含め、IT ランドスケープの多くの部分を自動化できるソリューションです。 自動化ソリューションの活用によって、Pacemaker クラスターを構成するプロセスが簡素化され、人的エラーが減少します。 構成がテストされて検証され、テンプレートとして組み込まれると、Ansible ロールと Playbook が何度でも安定したデプロイを提供します。 次のブログでは、Red Hat Ansible Automation Platform を使用して SAP HANA Pacemaker クラスターを自動的に作成する方法について説明しています。 Automating SAP HANA HA configuration with Ansible and Red Hat HA Add-On | SAP Blogs また、HA は計画外の停止を回避するだけでなく、自動化ソリューションと組み合わせて使用​​して、計画的なメンテナンス アクティビティのダウンタイムを最小限に抑えることにも利用できます。 詳細は以下のポートフォリオ アーキテクチャを参照してください。 https://www.redhat.com/architect/portfolio/architecturedetail?ppid=11 信頼性もコスト効率も高い SAP システム SAP ワークロードは組織の中核に位置しており、非常に重要です。 そのため、(計画的および計画外の) 停止を最小限に抑えながらアップタイムを最大化することは、IT 部門の重要なミッションです。 RHEL HA Solutions for SAP がサポートする最新のシナリオにより、利用ユーザは SAP システムがビジネス ニーズに対応できるという確信をさらに深めることができ、より高いレベルのデータ冗長性を実現しながらスムーズなユーザー エクスペリエンスが提供出来ます。 また、SAP HANA のコストが最適化されたソリューションのサポートは、コンピューティング リソースへの支出を大幅に削減するのに役立ちます。 特に、ハイブリッド クラウド環境で、コストをコントロールするためにパブリック クラウドを最大限に活用したいと考えている場合は効果的です。 関連情報 www.redhat.com www.redhat.com

レッドハットの森若です。 この記事は、RHEL 8むけの以下記事のRHEL9版です。 rheb.hatenablog.com RHEL 9ではどのパッケージがいつまでサポートされるのでしょうか? この記事ではその調べ方をご紹介します。 (※注意: サポート期間等は変更される場合があります。スクリーンショット等は執筆時点のものです。) その前にまず2点ほど前提知識をご紹介します。 Compatibility Level Red Hat Enterprise Linux では、RHEL5の頃から Application Compatibility Guideを公開して、アプリケーションの互換性を維持するために 考慮する必要があるポイントをまとめています。この中で各パッケージについての互換性維持を4段階のレベル(Compatibility Level, 以下 CL)に分けています。 RHEL 9では、RHEL 8と同じく以下のようになっています。 CL 1は3つのメジャーバージョンに渡ってAPI/ABIの互換性を維持 CL 2では1つのメジャーバージョン内でAPI/ABIの互換性を維持 CL 3は各コンポーネントについてApplication Streams Lifecycleであらかじめ定義された期間維持。期間の終了前に新しいバージョンを提供 (ただしdeprecatedとなった場合は新しいバージョンを提供しません) CL 4は互換性を維持しません 厳密な定義については以下に記載されています。 access.redhat.com RHEL 9では、公式ドキュメント「Package Manifest」内に、パッケージ毎にCompatibility Levelが記載されるようになりました。 access.redhat.com Application Streams Lifecycle CL 3に該当するのが Application Streams Lifecycleです。 access.redhat.com このページ内の表「RHEL 9 Application Streams Release Life Cycle」に記載されたコンポーネントはCL3で、ライフサイクルがRHEL 9の10年(2022年5月から2032年5月まで)とは独立したものになります。 Application Streamsはフルサポート中は新しいバージョンに対応したストリームが出てきますが、2027年5月にメンテナンスフェーズに入る前にいずれかのストリームが指定され、メンテナンスフェーズ中はそのストリームだけがメンテナンスされます。 注意が必要な点として、Application Streams Lifecycleが定義されたパッケージはRHELのEUSチャネルでもメンテナンス対象ですが、あらかじめ決められたライフサイクル終了するとEUS期間中であってもメンテナンスが終了し、EUS期間にあわせてメンテナンス期間が延長されるようなことはありません。 Full Life Application Streams RHEL 9とタイミングをあわせて登場したのが「Full Life Application Streams」です。ここに掲載されているソフトウェアは通常のRHELのライフサイクル終了まで維持されます。 ただし同じソフトウェアの別バージョンがApplication Streamsとして登場することがありえます。 従来は「Application Streams Life Cycle」には 10年維持されないバージョンだけ を提示していたため、たとえばRHEL 8でPython 2.7や3.8が短期間しか維持されないことはわかっても、Python 3.6が10年維持されることを確認するには手間がかかっていました。 その手間を減らすための工夫です。 Rolling Application Streams これらのコンポーネントはマイナーリリースのタイミングで新バージョンが提供され、最新のバージョンだけがサポート対象となります。RHEL 7でのExtrasリポジトリに相当します。 ただし container-tools については、EUSの間パッケージのメンテナンスが行われます。RHEL 8とはポリシーが異なりますのでご注意ください。 access.redhat.com 10年維持されるパッケージはどれ? やっと標題の質問に戻ります。「10年維持されるパッケージはどれ?」という質問に答えるには、CL 1またはCL 2であること もしくは CL 3でFull Life Application Streamsであることを確認する必要があります。 Package Manifestは長いドキュメントですので以下の手順で確認するのがよいでしょう。 Red Hat Enterprise Linux Application Streams Life Cycle - Red Hat Customer Portal 内で検索する。 「RHEL 9 Full Life Application Streams Release Life Cycle」に記載がある(→10年) 「RHEL 9 Application Streams Release Life Cycle」に記載がある(→短期) 記載がない(→2へ) Package manifest Red Hat Enterprise Linux 9 | Red Hat Customer Portal 内で検索する。CLを確認して1か2である(→10年) 例1: OpenJDK RHEL 9に含まれているOpenJDKのライフサイクルを確認します。 RHEL 9 Application Streams Release Life Cycle内に含まれており、それぞれ2〜5年ほどのサポート期間が定義されていることがわかります。 例2: PHP RHEL 9に含まれているPHPのライフサイクルを確認します。 検索すると、Application Streams Release Liife Cycleには含まれず、Full Life Application Streams Life Cycleに php 8.0 が含まれていることがわかります。 PHP 8.0はRHEL 9の10年間のライフサイクルの間サポートされることがわかります。