Red Hatの森若です。 2025-08-13 更新: 365日以内にサポートケースと関連づけされたものも表示対象になることを追加、期間の誤り(4年→3年, 3年→2年)を訂正 Red Hat カスタマーポータル内の検索仕様について大きな変更がありましたのでおしらせです。 要するに... Red Hat カスタマーポータル内の 「検索」や「Search」 および 「Ask Red Hat」 では3年以内に作成されたナレッジ、もしくは 2年以内に更新されたナレッジ、もしくは365日以内にサポートケースと関連づけされたものだけが表示対象になりました。 網羅的なナレッジ検索を行う場合は上記を避けて以下で検索します。 http://access.redhat.com/kb を開きます 英語設定にします Englishを選ぶ 検索ボックスで検索します 検索ボックス 検索の仕様変更 2025年8月8日に、カスタマーポータル内の 「検索」や「Search」 および 「Ask Red Hat」 では「3年以内に作成されたナレッジ」もしくは「2年以内に更新されたナレッジ」もしくは「365日以内にサポートケースと関連づけされたナレッジ」だけが表示対象になりました。 3年前は、RHEL で言えば RHEL 8.6が出荷されて2〜3ヶ月ほどです。そのため現時点で RHEL 8.7以降、RHEL 9.1以降しか扱わない、その他の製品についても3年以内のものしか扱わない場合には、大きな問題はありません。不要なナレッジが検索結果に表れなくなって便利になるケースもありそうです。 全ナレッジを検索する方法 上記の条件にあてはまらない古いナレッジは、削除されたわけではなく、引き続き存在しています。これらの検索を行う場合には、 ナレッジベースの検索 を利用することができます。 注意点として、この検索ではカスタマーポータルの言語設定が利用されます。つまり、日本語設定にしている時には日本語翻訳済みのナレッジだけが検索対象になります。そのため網羅的な検索をするにはカスタマーポータルを英語設定にする必要があります。 検索方法による違い たとえば "rsyslog filter" というキーワードで検索すると、以下のようになります。網羅的な検索が必要な場合は、access.redhat.com/kb を英語設定で利用するのがベストです。 access.redhat.com/search → 51件 (古いものを含まない) access.redhat.com/kb (日本語設定) → 2件 (和訳されたもののみ検索対象) access.redhat.com/kb (英語設定) → 124件 (英語のみ)

Red Hatの森若です。 「RHELは常にアップデートして、最新バージョンを使ってください。既知の問題が直っているからいいですよ」という話はよくします。 ふと「具体的にどんな問題があったのか/直したのかがわかるといいのかもしれない」と思いつきました。 最近は暑いので怖い話も多少は需要があるでしょう。 そこでナレッジベースからsystemdの大きめの問題修正をピックアップしてみました。 以下では、私が独断と偏見でピックアップした systemdの大きめの問題 について、修正されたマイナーリリース毎に紹介していきます。 RHEL 8.1 systemd-journald プロセスのヒープメモリ使用量が徐々に増加する問題 ： systemd-journald プロセスのヒープメモリ使用量が徐々に高くなることがありましたが、これは systemd-239-18.el8_1.1 で修正されました。 systemd-journald: amount of heap memory is getting gradually high - Red Hat Customer Portal RHEL 8.2 Type=Notify および NotifyAccess=All が設定されたサービスが意図せず停止する可能性がある問題 ：これらの設定を持つサービスが、PID の不足などが原因で、他のサービスによって不意に終了させられる可能性がありました。これは systemd-239-29.el8 で修正されました。 Services using the "Type=Notify" and "NotifyAccess=All" settings are vulnerable to being inadvertently shut down by other services - Red Hat Customer Portal RHEL 8.3 システムシャットダウン時に「Reached target Shutdown」でシステムがハングする問題 ：システムがシャットダウン中に swap がアクティブなままで、「Reached target Shutdown」メッセージの後にハングすることがありました。これは systemd-239-40.el8 で修正されました。 System hangs on shutdown after printing "Reached target Shutdown" - Red Hat Customer Portal RHEL 8.4 systemd --user が bus_process_internal() でアサートに失敗しクラッシュする問題 ：この問題は systemd-239-45.el8 以降 で修正されました。    RHEL8: "systemd --user" crashes on assert in bus_process_internal() - Red Hat Customer Portal RHEL 8.5 systemd がセグメンテーション違反でクラッシュする問題 ： systemd がセグメンテーション違反でクラッシュし、ログインの遅延やシステムの応答不能を引き起こすことがありました。 systemd-239-51.el8_5.2 以降に更新することで修正されます。    RHEL8: systemd crashes with Segmentation Fault, causing slowness logging in and later system to become unusable - Red Hat Customer Portal RHEL 8.7 systemctl list-unit-files コマンドが CPU 使用率を大幅に増加させ、操作を遅延させる問題 ：このコマンドを頻繁に実行すると、 systemd の CPU 使用率が急増し、システムが使用不能になる問題がありました。これは systemd-239-68.el8 以降 で修正されました。     The ListUnitFiles operations in systemd causing high CPU consumption and causing delays in other system operations and makes system unusable - Red Hat Customer Portal RHEL 8.8 ジャーナルにおけるサービスユニットからのログ出力が不正な形式になる問題 ：サービスユニットからのジャーナルログ出力が不正な形式になる問題がありました。これは systemd-239-74.el8_8 で修正されました。 rhel8: The output of certain journal logs is corrupted - Red Hat Customer Portal systemd-logind が「Assertion 'pid > 1' failed」でアサートに失敗しクラッシュする問題 ： systemd-logind プロセスがアサートでクラッシュする問題が報告されました。これは systemd-239-74.el8_8.3 で修正されました。    systemd-logind fails with "Assertion 'pid > 1' failed at ../src/login/logind-dbus.c:3332, function manager_start_scope()" - Red Hat Customer Portal RHEL 8.10 DefaultTasksMax= が system.conf で値なしでコメント解除されていると、systemdが起動時にセグメンテーション違反でクラッシュする問題 ：この誤った設定により、サーバー起動時に systemd がクラッシュし、起動に失敗することがありました。これは systemd-239-82.el8_10.4 以降 で修正されました。 systemd crashes due to a segmentation fault on boot, resulting in the server boot failure. - Red Hat Customer Portal おわりに systemdの問題では、起動中だと起動不能になるものもあり、運用中だとシャットダウンやサービスの起動・終了もできなくなるケースがあります。 最新のバージョンを使ってこれらの問題を回避しましょう。

こんにちは。OpenShift SSAの瀬戸です。 限られた環境でJBoss EAPを起動したい場合にどれくらい時間がかかるようになるのかを調べる機会があったので情報を共有します。 ※実際はCPUの種類などによっても起動速度に影響が出てきますので、参考値としてください。 方法：OpenShift上のデプロイメントでresources.limits.cpuを制限しJBoss EAPの起動時間がどれくらい変わるのかを確認する。 環境：AWS上のEC2に構築されたOpenShift(m6a.2xlarge) アプリ： JBoss EAP 8.0 が OpenShift上へのデプロイをいかに簡単にするか - 赤帽エンジニアブログ で使用したhelmでデプロイするアプリ(EAP8.0.8) 補足1：cpu以外については制限なし、デフォルトの割り当てとする 補足2：HyperThreadingは有効 結果 resources.limits.cpu=1の場合→およそ9秒 resources.limits.cpu=2の場合→およそ5秒 resources.limits.cpu=4の場合→およそ4秒 JBoss EAP のハードウェアおよびメモリー要件 - Red Hat Customer Portal のページによるとJBoss EAP 6以降は明示的なハードウェア要件を提供しなくなっていますが、1CPU(2vCPU)ないと起動速度に明確に影響が出るという事ですね。 これはデフォルトの設定なので、チューニングの余地はあることについてはご注意ください。

Red Hat コンサルタントのフェンです。 「アプリケーションモダナイゼーション」に関連する連載の第3回目となります。 本連載では「アプリケーションモダナイゼーション（アプモダ）」をテーマに、現場で役立つ実践的な知見をお届けしています。 第１回では モダナイゼーションの定義と「6R」という主要なアプローチ を、第２回ではその背景にある 「技術的負債」の深刻さについて掘り下げ ました。 rheb.hatenablog.com   rheb.hatenablog.com そして、今回はモダナイゼーションの「最初の一歩：現状分析（アセスメント）」を紹介したいと思います。   はじめに 1. なぜアセスメントが羅針盤となるのか？ 2. 何を評価するのか？：4つの評価領域 3. どのような観点で見るのか？：4つの評価軸 4. どうやって評価するのか？：定性と定量の評価 5. 評価結果をどう活かすか？：優先順位付け Gartner TIMEモデルの紹介 仕上げ：TIMEモデルと6Rアプローチの連携 まとめ はじめに 多くの企業が「このままではいけない」という危機感を共有し、変革の必要性を感じています。しかし、その一方で、「では、膨大なシステム群のどこから、何から手をつければいいのか？」という問いの前で立ち尽くしてしまう、いわゆる「現状麻痺」の状態に陥るケースが後を絶ちません。「この帳票のレイアウトをちょっと変えるだけで1ヶ月かかる」という現場の悲鳴は、問題の氷山の一角に過ぎません。その根本原因はどこにあるのでしょうか？どのシステムを最初に手術台に乗せるべきなのでしょうか？ この問いに答えるための唯一の、そして重要な活動が、今回ご紹介する 「現状分析（アセスメント）」 です。アセスメントとは、モダナイゼーションという先の見えない航海における「羅針盤」であり「海図」です。勘や口コミ、あるいは「声の大きい部門」の意見に流されることなく、データに基づいて自社のIT資産の「健康状態」を客観的に診断し、進むべき航路を定めるための戦略的なプロセスです。 本記事では、このアセスメントをどのように進めていけばよいのか、その重要性から具体的な手法、そして評価結果を戦略にする方法までを解説していきます。この記事を読み終える頃には、皆さんの組織でアセスメントを実施するための具体的なイメージと、次の一歩を踏み出すための確信が持てるはずです。   1. なぜアセスメントが羅針盤となるのか？ モダナイゼーションのプロジェクトにおいて、アセスメントは単なる「資産の棚卸し」ではありません。それは、企業のIT戦略そのものの妥当性を問い直し、未来への投資対効果を最大化するための、戦略的な診断プロセスです。 第2回の記事 で見たように、多くのシステムは長年の運用を経て「ブラックボックス化」し、「属人化」が進んでいます 。このような不確実性の高い状況で、適切なアセスメントを経ずにモダナイゼーションに着手することは、羅針盤を持たずに荒波に乗り出すようなものです。 もし、この重要なステップを省略したり、簡易的に済ませてしまったりすると、モダナイゼーションの実施段階で以下のリスクに直面します。 予算の誤配分: ビジネス上の価値が低いアプリケーションの延命に多額の予算を投じてしまう。 的外れな解決策: 例えば、根本的な問題が複雑なアーキテクチャにあるにもかかわらず、表層的なインフラ移行（Rehost）に終始してしまい、本質的な課題解決に至らない。 新たな技術的負債の産出: チームのスキルセットや組織のプロセスに合わない最新技術を拙速に導入した結果、逆に開発・運用が複雑化し、新たな「レガシーシステム」を生み出してしまう 。 プロジェクトの失敗: 期待されたROI（投資対効果）を達成できず、ビジネス部門からの信頼を失い、将来のIT投資そのものが停滞する。 これを避けるためのアセスメントは、人間ドックに例えることができます。いきなり過酷なトレーニングを始める前に、まずは健康診断で自身の体力や課題を正確に把握するように、モダナイゼーションもまずは自社のIT資産の「健康状態」を客観的に診断することから始まります。実際、多くの先進的な取り組みでは、アセスメントがモダナイゼーションの「出発点」として位置づけられています。 さらに、アセスメントの価値は、最終的に得られるデータやレポートだけに留まりません。そのアセスメント活動自体が、組織にとって重要な副次的効果をもたらします。これまでサイロ化しがちだったIT部門とビジネス部門が、アセスメントという共通の目的で会話をせざるを得なくなるのです。アセスメントでは、アプリケーションのビジネス価値を評価するために、ビジネスオーナーへのヒアリングやワークショップが不可欠です。この過程で、IT部門はビジネスの優先順位や現場のペインポイントを深く理解し、ビジネス部門はシステムの技術的な制約やリスク（IT部門がなぜ予算を要求するのかの背景）を学びます。このように、アセスメントは、IT部門の独走ではなく、「ビジネスとITの連携」を自然に生み出し、この成功体験は組織変革や、持続可能な組織に進化するための触媒となると考えられます。   2. 何を評価するのか？：4つの評価領域 効果的なアセスメントは、単にアプリケーションのコードをマイグレーションツールや、静的分析などにかけるだけでは不十分です。アプリケーションを取り巻く環境全体、すなわち、技術と人が織りなす「複合体」として捉え、包括的に評価する必要があります。この「複合体」は大きく4つの領域に分けて評価できます。 表1: 4つの評価領域 領域 概要 主な評価項目 アプリ  アセスメントの中核となるソフトウェア資産そのもの。組織内の全アプリケーションのインベントリ作成が第一歩。 プログラミング言語、フレームワーク、データベース管理システム、サードパーティ製ライブラリ、ソースコードの管理方法、設計書の最新状態、アプリケーション間の連携・依存関係。 インフラ アプリケーションが稼働する土台となるプラットフォーム。インフラ自体が変化の足かせとなるケースも。 物理サーバーや仮想サーバーの老朽化度、OSやミドルウェアのバージョンとサポート期限、現在のクラウド利用状況、ネットワークアーキテクチャ、拡張性（スケーラビリティ）の限界。 組織 システムを開発・運用・保守する「人」と「チーム」に関する領域。技術的問題の根源が組織構造やスキルセットにあることも。 チームの構成（サイロかクロスファンクショナルか）、保有技術スキルセット（レガシー技術、クラウドネイティブ技術）、知識の分布状況（属人化のリスク）、変化に対する組織文化や部門間協力体制。 プロセス ソフトウェアを構築し、展開し、運用監視するための一連のワークフロー。非効率なプロセスは開発リードタイム増大や品質低下の直接原因となる。 開発手法（ウォーターフォールかアジャイルか）、CI/CDの自動化成熟度、テストプラクティス（手作業での回帰テストの有無など）、リリース頻度、システムの監視や障害対応の仕組み。   これら4つの評価領域は、独立しているわけではなく、密接に絡み合っています。例えば、技術的負債は、これら複数の領域にまたがって、まるでクモの巣のように張り巡らされています。巨大で複雑なモノリシックアプリケーション（ アプリケーション領域 の問題）は、変更が困難なため、長年アップデートされずに放置されがちです。その結果、サポート切れの古いOSが稼働する老朽化した物理サーバー上で動き続けることになります（ インフラ領域 の問題）。その古い技術を扱えるのは、社内でもごく一部のベテランエンジニアのみとなり、深刻な「属人化」を引き起こします（ 組織領域 の問題）。そして、どんな些細な変更もリスクが高く、影響範囲の特定が困難なため、リリース前には膨大な手作業でのテストが必要となり、年に数回しかリリースできない、という状況に陥ります（ プロセス領域 の問題）。 このように、ある領域で見つかった一つの問題は、他の領域における問題の兆候でもあります。良いアセスメントとは、単に各領域の問題点をリストアップするだけでなく、これらの因果関係を解き明かし、課題の全体像を体系的に描き出すことです。このシステム全体への深い洞察こそが、場当たり的な技術修正ではなく、真に効果的なモダナイゼーション戦略を立案するための鍵となるのです。   3. どのような観点で見るのか？：4つの評価軸 評価対象となる4つの評価領域を特定したら、次はその「健康状態」を測るための統一された物差し、すなわち「評価軸」を定義する必要があります。この評価軸を定めることで、ポートフォリオ内の多種多様なアプリケーションを客観的に比較し、戦略的な意思決定を下すことが可能になります。ここで紹介する評価軸は、後述するGartnerのTIMEモデルのようなポートフォリオ分析フレームワークの基礎となる、極めて重要な要素です。 ここでは、特に重要となる4つの評価軸を、その評価項目と戦略的な意味合いと共に整理します。 表2: 4つの評価軸 評価軸 主な評価項目 なぜ重要なのか？ ビジネス価値 事業戦略への貢献度 売上/利益へのインパクト 利用ユーザー数・業務クリティカリティ 顧客満足度への影響 投資の優先順位を決定する上で最も重要な指標です。この価値を維持・向上させることがモダナイゼーションの最終目的であり、すべての判断の起点となります。 技術的健全性 アーキテクチャの質（モノリシックかマイクロサービスか等） コードの保守性・可読性 利用技術の陳腐化度（サポート状況） テスト自動化率 システムの「柔軟性」、「疎結合」に直結する指標です。健全性が低い、すなわち技術的負債が溜まったシステムは、改修コストとリードタイムを増大させ、ビジネスの俊敏性を著しく阻害します。 リスク セキュリティ脆弱性（サポート切れOS/ライブラリなど） コンプライアンス要件（個人情報保護法、業界規制など） 運用上の障害発生率と復旧時間 属人化・特定ベンダーへの依存（ベンダーロックイン） 事業継続性を脅かす潜在的なリスクを特定します。放置されたリスクは、ある日突然、ビジネス価値損失や顧客信用失墜といった形でビジネスに壊滅的なインパクトをもたらす可能性があります。 運用コスト ソフトウェアライセンス費用 インフラ（サーバー、ストレージ、ネットワーク）費用 保守・運用にかかる人件費 手作業による非効率な業務に起因する隠れコスト IT予算の圧迫要因を可視化します。コスト削減はモダナイゼーションの主要な動機の一つであり、投資対効果（ROI）を算出する上での基礎データとなります。 これらの評価軸を用いて各アプリケーションをスコアリングすることで、組織のITポートフォリオ全体を俯瞰的に、そして定量的に把握することが可能になります。   4. どうやって評価するのか？：定性と定量の評価   評価軸が定まったら、次はいよいよ具体的なデータ収集のフェーズです。信頼性の高いアセスメントを実現するためには、定性的なアプローチと定量的なアプローチを組み合わせた情報収集が不可欠です。 表3: 定性・定量の評価 目的 主な手法 定性的評価 ツールでは見えない「生きた情報」の収集。ドキュメント化されていない暗黙知、ビジネスプロセスにおける重要性、過去の改修経緯、開発者・運用者のペインポイントなどを引き出す。特に「ビジネス価値」の正確な測定に不可欠。 構造化インタビュー ワークショップ アンケート 定量的評価 人の主観や記憶だけでなく、客観的なデータで裏付けを取る。自動化ツールを活用し、アプリケーションのソースコードやバイナリ、インフラの構成情報を大規模かつ効率的に分析。「技術的健全性」や「リスク」といった評価軸を客観的なデータに基づいて評価する。 マイグレーションツール（例：Red Hat Migration Toolkit for Applications (MTA) ） SonarQube AWS/Azureの移行評価ツール 補足: 定性的評価と定量的評価は互いに補完し合い、その結果を突き合わせることで、より深く、確かな洞察を得ることができます。これにより、定量的データが示す「What（何が起きているか）」と、定性的情報が示す「So What（だから何なのか）」を往復し、アセスメントの精度を向上させます。 市場には様々なアセスメントツールが存在しますが、私たちRed Hatが提供するツール「Red Hat Migration Toolkit for Applications (MTA) 」の詳細情報は過去のブログをご参考ください。 Migration Toolkit for Applicationsを使って組織のシステムのクラウドへの移行を促進させる 1.概要編 Migration Toolkit for Applicationsを使って組織のシステムのクラウドへの移行を促進させる 2.インストール編 Migration Toolkit for Applicationsを使って組織のシステムのクラウドへの移行を促進させる 3. 使用(アセスメント)編 【令和6年最新版】JBoss EAP 7.4からJBoss EAP 8.0への移行 5. 評価結果をどう活かすか？：優先順位付け さて、アセスメントによって情報が集まりました。しかし、情報はそれだけでは価値を生みません。次に必要なのは、このデータを意思決定に繋げるための「集約」と「可視化」です。ここで活躍するのが、 アプリケーションポートフォリオ管理（APM: Application Portfolio Management） の枠組みです。「APM」という大きな枠組みの中で、具体的な手法として、業界標準として広く認知されている「GartnerのTIMEモデル」を紹介します。 GartnerのTIMEモデル はアプリケーション単体の評価ではなく、ビジネスプロセス全体との整合性からIT投資の優先順位を決める、よりトップダウンで戦略的なアプローチです。 Gartner TIMEモデルの紹介 TIMEモデルは下図のように、「 ビジネス価値 （Functional Fit）」と「 技術的健全性 （Technical Fit）」の2つの軸 を用いて、アプリケーションを分類します。 縦軸 - ビジネス価値 (Business Value) そのアプリケーションがどれだけビジネスに貢献しているかを示します。 高: 企業の収益に直結する、競争優位性を生み出す、基幹業務に不可欠など。 低: 利用者が少ない、代替手段がある、ビジネス戦略との関連性が薄いなど。 横軸 - 技術的適合性 (Technical Fit) そのアプリケーションが、企業の目指すITアーキテクチャや技術標準にどれだけ適合しているかを示します。 高: モダンな技術で作られている、保守性が高い、セキュリティリスクが低い、他システムと連携しやすいなど。 低: 古い技術（レガシー）で作られている、保守できる人材がいない、セキュリティリスクが高いなど。 これにより、各アプリケーションは以下の4つの象限のいずれかに分類され、それぞれ取るべき戦略が明確になります。 表4: TIMEモデルの象限 象限 特徴 方針 Tolerate (許容) 技術的健全性は高いが、ビジネス価値は低いアプリケーション群。安定稼働しており、手もかからないが、戦略的な重要性は低い。 積極的な投資は行わず、現状を維持する。リソースは他のより価値の高い領域に集中させる。 Invest (投資) 技術的健全性、ビジネス価値ともに高いアプリケーション群。組織の「スター選手」であり、競争力の源泉。 さらなる価値向上のため、機能強化やパフォーマンス改善に積極的に投資する。 Migrate (移行) ビジネス価値は高いが、技術的健全性が低いアプリケーション群。ビジネスに不可欠だが、技術的負債の塊でリスクも高い「問題児」。 ビジネス価値を維持・向上させつつ、技術的な問題を解消するため、モダナイゼーションを積極的に検討する。 Eliminate (廃止) 技術的健全性、ビジネス価値ともに低いアプリケーション群。もはや組織のお荷物であり、維持しているだけでコストがかかる。 リソースを解放するため、計画的に廃止・削除する。   仕上げ：TIMEモデルと6Rアプローチの連携 このTIMEモデルによる戦略的な分類（何をすべきか）と、本連載の 第1回でご紹介した具体的なモダナイゼーションアプローチである「6R」 （どうやるか）を結びつけることで、アセスメントから実行計画までの一貫したストーリーが完成します。これは、モダナイゼーション戦略を策定する上で重要な検討プロセスです。 以下の表は、TIMEの各象限に対して、どのような6Rアプローチが対応するのかを整理した一例です。これで、皆さんの組織がモダナイゼーションの具体的なアクションを意思決定の参考になればと考えています。 表5: TIMEモデルと6Rアプローチの戦略 象限 特徴と戦略 対応する6Rアプローチの提案 Tolerate (許容) ビジネス価値: 低 技術的健全性: 高 安定稼働しているため、積極的な投資は行わない。現状を維持し、リソースを他に集中させる。 Retain: 現状維持。定期的に監視し、状況が変化（価値がさらに低下、または技術が陳腐化）すれば再評価する。 Invest (投資) ビジネス価値: 高 技術的健全性: 高 さらなる価値向上のため、機能強化やクラウドネイティブ化を推進する。 Refactor / Re-architect : クラウドネイティブ機能（スケーラビリティ、回復性）を最大限に活用するためにアーキテクチャを刷新する。 Replatform : 最新のコンテナプラットフォーム等に移行し、運用効率をさらに高める。 Migrate (移行) ビジネス価値: 高 技術的健全性: 低 ビジネス価値を維持しつつ、技術的負債とリスクを解消する。最も多様な選択肢が存在する。 Rehost : まずはインフラの老朽化リスクを回避するため、迅速にクラウドへ移行する（Lift & Shift）。 Replatform : アプリケーションに軽微な変更を加え、クラウドの利点（DBサービス等）を享受する。 Refactor / Rebuild : 根本的な問題を解決するため、本格的に再設計・再開発する。 Repurchase : 要件を満たす優れたSaaSがあれば、開発・保守から脱却し、そちらに乗り換える。 Eliminate (廃止) ビジネス価値: 低 技術的健全性: 低 組織にとってお荷物。リソースを解放するため、計画的に廃止・削除する。 Retire: アプリケーションを完全に停止し、関連するインフラやライセンス契約を解約する。 このマトリックスを活用することで、「どのアプリケーションに」「どのようなアプローチで」モダナイゼーションを適用すべきか、また優先順位が明確になり、モダナイゼーションのロードマップを策定することが可能になります。   まとめ アプリケーションモダナイゼーションは、単なるコーディング作業ではなく、現状分析（アセスメント）から始まる問いの旅です。本記事で述べたように、成功への羅針盤となるのは、アプリケーション、インフラ、組織、プロセスの4つの領域を、ビジネス価値、技術的健全性、リスク、コストの4つの視点から評価することです。 このような現状分析により、IT資産の実態が明らかになり、勘や経験則に頼っていた場当たり的な意思決定が、事実情報に基づいた戦略的な投資判断へと進化します。その過程で、ITとビジネス間の対話が促進され、組織全体の方向性が一致するという価値が生まれます。 また、現状分析を一過性のイベントで終わらせないことも重要です。ビジネス環境も技術も絶えず変化するため、アセスメントとポートフォリオ評価は、年次や半期ごとのサイクルで継続的に見直し、IT資産が常にビジネス目標に最適化された状態を維持する「規律」として組織に定着させるべきです。 これで、どこから手をつけるべきか、そのための「地図」の入手方法が分かりました。しかし、地図があっても、実際に旅を進めるには具体的な旅程計画と、共に旅をする仲間からの協力が不可欠です。 次回は、このアセスメント結果という地図を基に、具体的なモダナイゼーションロードマップの策定方法について、さらに深く掘りしていきます。   Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート  「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？  Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」  ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。  www.redhat.com    

こんにちは。Red Hatコンサルティングチームの木嶋です。 組織の変革において「うちの若手にはもっと積極的になって欲しいんだけど」とお嘆きの声を耳にする機会があります。 人のマインドや組織の文化を変えるのは、そう簡単ではありませんよね。 この赤帽エンジニアブログにガンガン投稿するような猛者たちって、どのようにして育つのでしょう? 意外に思われるかもしれませんが、弊社Red Hatでも、新しく入社される方々が全員積極的な猛者であるわけではありません。 最初は狼の群れに放り込まれた羊のように戸惑いながら、少しずつ環境に馴染み、いつの間にか情報発信の中心に立つようになっていくのです。 では弊社ではなぜ自然と猛者が育つのでしょうか。 (手前味噌で恐縮ですが) この変化が自然に起こる背景には、文化の土壌があります。 この記事ではお悩みの皆様の参考になるように、どのような仕組みになっているかを紐解いてみたいと思います。 最初は誰でも怖い なぜか動き出せる OSSらしい文化とは何か まずは一つの “Encouragement” から まとめ Appendix 最初は誰でも怖い 入社して最初に思うのが、「何この猛者の集団こわい。」 正直自分は場違いなんじゃないかと思うのです。 以前からいるメンバーは自信を持って社内社外に情報発信をするし、専門家としての地位を確立しています。 私も前職ではそれなりに知見を積んでいましたけど、役に立つのか正直不安な時もありました。 そのうち自分がそれなりに知見を持っている領域で、誰もやっていない領域が見えてきます。 猛者だからこそ気が付かない初学者の視点は特に盲点になりがちです。 こういう点を見つけた時に、「自分がやっていいのか」という戸惑いがありました。 なぜか動き出せる では、やっていいかどうか誰に聞けば良いのか。あるいはどこに書いてあるのかわからない。 調べてもどこにも出てこない。 こういう時、マネージャーが怒ったり、あるいは隠れた重鎮がいらっしゃり、明文化されていないルールをお持ちだったりすることがありますよね。 もめるのはいやなので同僚に聞いてみました。 聞き先があるかもわからないので、やってみて怒られたらやめたらいいんじゃない？ この時教えてもらったのは、聞き先が見つからないのにクヨクヨと探す行為はコストだという考え方でした。 答えがないものを探しても意味はないので、であれば実行して怒られたらやめた方が「コストが低い。」 この言葉が目から鱗でした。 これはある意味、GitでのPull Requestと似ています。 やってみて、フィードバックをもらってから直す。その方が早くて合理的だ、という考え方です。 その言葉に勇気をもらい、MVPを作って社内で発表してみました。 さらにそのMVPは、後日お客様に紹介してもらう機会を頂戴しました。 この段階でやっと似たような領域をやっている人に紹介いただき、その人と話をしてやっと「ああ、この内容って実は本当に誰もやってなかったんだ！」と気がつきました。 その段階のプロトタイプが当面の私の名刺がわりになっていたように思います。 私はこうして弊社での一歩を踏み出したわけですが、これは決して私だけの話ではありません。 実は先日弊社内でアンケートを実施したのですが、多くのメンバーが、大小の差はあれど、ほぼ同じ道筋を辿っていることがわかりました。 つまり弊社内ではこのように自然と動き出せるような文化が根付いているのです。 OSSらしい文化とは何か 弊社はOSSの会社と言われます。 これは単にソースコードをオープンにし、誰でもアクセスできるよう開示している会社というだけではありません。 私が弊社で経験しているのは、貢献を通じて関係性が生まれ、信頼が育ち、さらに次の行動を呼び込む構造をOSSを基盤にして作っている会社です。 これはガイシ系ソフトウェア会社にありがちなJob Descriptionや成果主義などの人事制度だけではなく、以下3つの特徴的な文化があります。 情報発信が自己紹介に 貢献がつながりに フィードバックが共創のきっかけに この記事の前半では、私自身の体験をもとにこうした文化がどのように機能しているかをご紹介しました。 とはいえ、最初の行動のきっかけは、実に小さなものでした。 周囲の振る舞いが一貫して “Encouraging (後押ししてくれる)” だったことです。 例えば、このように。 マネージャーがチャレンジを当たり前だとして背中を押してくれたこと 同僚が「いいね！」と言ってくれたこと 他の人に「あれを作った人だよ」と紹介してくれたこと 既存のアウトプットとの重複が多少あったとしても、視点のユニークさを認めてもらえること まずは一つの “Encouragement” から こう考えると、トリガーになっている小さな “Encouragement”、背中を押す一言や振る舞いなら、今日からでも始められそうな気がしませんか。 よく言われるように、行動がマインドセットをつくり、マインドセットが文化をつくります。 文化の形成が難しいのは、それがこれらの積み重ねの集大成だからです。 まずは自分が “Encouragement” を当たり前にできるようになることを目指してみましょう。気がつくばそれは自分のマインドセットになり、やがてチームの文化に育つはずです。 まとめ このように弊社の文化を紹介してみましたが、正直に申し上げてこんなにうまくいっていないことも多々あります。 情報が多すぎてうまく探しきれなかったり、コミュニティが多すぎてうまく情報を届けにくかったり、この文化になじむのが難しいと感じる人もいます。 でも多くのRed Hatter (弊社メンバー) が貢献を歓迎し、お互いをEncourageしあう文化を大切にしています。 ご興味があれば、ぜひ弊社の誰かにどんな文化として体験しているのかを聞いてみてください。 Appendix 今回の社内アンケートをもとにまとめたJourney Mapを以下に共有します。 新しい文化づくりに取り組まれている皆様にとって、何かのヒントになりましたらうれしく思います。 Journey Map (New Red Hatter)

Red Hat コンサルタントの金子です。「アプリケーションモダナイゼーション」に関連する記事の第２回目となります。 この記事では、"技術的負債"がどのような影響をもたらすのかを具体例を用いながら見ていけたらと思います。 アプリケーションモダナイゼーションシリーズの他の記事の以下もご覧ください。 rheb.hatenablog.com はじめに エンジニアが直面する技術的負債 開発における負債：変更を恐れるコードとプロセス 基盤における負債：変化を拒む「塩漬け」の土台 運用における負債：手作業と属人化の温床 セキュリティにおける負債：見過ごされたサイバー攻撃の脅威 技術的負債がもたらす影響 なぜ今、モダナイゼーションが必須なのか モダナイゼーションの技術的な目標 おわりに Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート はじめに 企業のIT部門や事業部門の皆様は、日々の業務の中でシステムの「重さ」や、変化するビジネス要求になかなか追随できない「もどかしさ」を感じているのではないでしょうか。新しいサービスを迅速に立ち上げたい、既存の機能を改善したい、といった際に、予期せぬ時間やコストがかかり、計画通りに進まないことも少なくないかもしれません。本連載では、この「システムの重さ」や「ビジネスの変化への追随の難しさ」といった課題の根本原因を探り、それを解決するための 「アプリケーション・モダナイゼーション」 について、技術的な側面から深掘りしていきます。 エンジニアが直面する技術的負債 なぜ既存のシステムは「重く」、変化への対応が難しいのでしょうか。その背景には、長年の運用の中で蓄積されてきた 「技術的負債」 があります。技術的負債とは、過去の意思決定や時間の経過により、システムの保守性や柔軟性が損なわれ、将来的な変更や機能追加、あるいは日々の運用・保守に余分なコストや手間がかかる状態を指します。特に、老朽化・複雑化したシステムには、この技術的負債が色濃く現れがちです。そして、その最前線で奮闘している現場のエンジニアの皆様こそが、この技術的負債が引き起こす様々な具体的な問題に日々直面しています。 技術的負債は、開発、基盤、運用、セキュリティといった様々な領域に根深く存在し、互いに影響しあっています。皆様の現場でも、以下のような状況に心当たりがあるかもしれません。 開発における負債：変更を恐れるコードとプロセス システムの柔軟性を最も損なうのが、開発プロセスに潜む負債です。 システムのブラックボックス化：コードの可読性が低く、内部ロジックが複雑怪奇になっているため、少しの回収でも影響範囲の予測が困難となります。 自動テストの欠如：変更を加えるたびに手作業での膨大な回帰テストが必要となり、開発のリードタイムを増大させ、品質の低下を招きます。 非効率なリリース作業：ビルドやデプロイのプロセスが自動化されておらず、リリース作業そのおのが一つの危険なイベントになっています。 基盤における負債：変化を拒む「塩漬け」の土台 アプリケーションが稼働する土台そのものが、変化の足かせとなります。 OS・ミドルウェアの陳腐化：サポートが切れたOSや古いバージョンのミドルウェアを使い続けており、最新技術の恩恵を受けられないだけでなく、セキュリティリスクを抱えています。 スケーラビリティの限界：物理サーバーの老朽化やアーキテクチャの制約により、ビジネスの要求に応じた迅速なリソース拡張ができません。 運用における負債：手作業と属人化の温床 日々の安定稼働を脅かすのが、運用現場の負債です。 業務の属人化：特定の担当者しか知らない運用手順やバッチ処理が存在し、その担当者の不在がサービス停止に直結するリスク（Single Point of Failure) を抱えています。 非効率な手作業：システム間のデータ連携などを手作業で行っており、ヒューマンエラーの温床となっています。 形骸化した監視と障害対応：障害発生時の原因特定や復旧のノウハウが共有されておらず、対応が後手に回りがちとなります。 セキュリティにおける負債：見過ごされたサイバー攻撃の脅威 直接的に企業の信頼を揺るがすのが、セキュリティ上の負債です。 既知の脆弱性の放置：サポート切れのソフトウェアを利用し続けることで、既知の脆弱性が修正されないまま放置され、サイバー攻撃の格好の標的となります。 不適切なアクセス管理：手動による管理などを多なっていると意図せず退職者のアカウントが残っていたり、必要以上の権限が付与されていたりするなど、基本的なアクセス管理徹底がされていない可能性があります。 技術的負債がもたらす影響 これらの技術的負債は、システムが 「継続的に更新可能なアーキテクチャになっていない」という根本的な問題に直結しています。保守や変更が困難な構造になっているため、新しい機能の開発や既存機能の改修に膨大な時間とコストがかかります。その結果、開発からリリースまでのリードタイムが増大し、システムの変更に伴うリスク も高まってしまいます。これは、企業のIT部門や事業部門が、ビジネスの変化に迅速に対応することを妨げる大きな足かせとなります。 なぜ今、モダナイゼーションが必須なのか こうした状況から脱却し、変化への対応力を高めるために、今、多くの企業でアプリケーション・モダナイゼーションが必須の取り組みとなっています。他社の動向や市場のトレンドを見ても、この動きは明らかです。Red Hat による調査結果によると、企業のアプリケーション責任者の95%が、自身の組織のアプリケーションのモダナイゼーションが必須であると考えている、というデータもあります。 https://www.gartner.com/document/4021775 www.redhat.com GartnerのVPアナリストであるRichard Watson氏も、この現状を指摘 しています。同氏は、「多くの企業では、既存アプリケーションの規模と技術的負債のため、新規アプリケーションのモダンな開発よりも既存アプリケーションのモダナイゼーションを優先している」と述べています。さらに、「既存アプリケーションの数は、毎年構築される新規システムの数をはるかに上回る。この不均衡は、企業が新規構築よりもアプリケーションの最新化に多くの費用を費やす必要があることを意味する」とも語っており、既存システムの変革が避けられない喫緊の課題であることを示唆しています。 モダナイゼーションの技術的な目標 アプリケーション・モダナイゼーションの技術的な目標は、まさにこれらの課題を解決することにあります。ブラックボックス化や属人化を解消し、非効率な手動作業を減らすことで、保守性が高く、継続的に更新可能なアーキテクチャを目指します。これにより、開発・運用のリードタイムを短縮し、変更リスクを低減させ、ビジネス要求に俊敏に対応できるIT基盤を構築することが可能になります。 おわりに 本記事では、システムの「重さ」やビジネス変化への追随の難しさの背景にある「技術的負債」に焦点を当て、なぜ今アプリケーション・モダナイゼーションが必須の取り組みとなっているのかを解説しました。 ブラックボックス化、属人化、そして非効率な手動作業といった技術的負債は、開発や運用のリードタイムを増大させ、システムの継続的な進化を阻む大きな足かせとなります。これらの課題を解消し、保守性が高く、継続的に更新可能なアーキテクチャを目指すことが、モダナイゼーションの技術的な目標です。 では、いざモダナイゼーションを始めようとしたとき、具体的に自社のシステムはどのような状態にあるのか、そして、どこからどのように着手するのが良いのでしょうか？ 次回の記事では、モダナイゼーションを成功に導くための重要なステップとして、現状をどのように評価し、具体的な進め方をどう計画していくかについて、さらに掘り下げて解説します。 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート 「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？ Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」 ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。 www.redhat.com

Red Hatの小島です。 オフライン環境でもRed Hatの様々なナレッジを参照できるようにするためのオフラインナレッジポータル(Red Hat Offline Knowledge Portal. 通称RHOKP)の提供が、2025年5月に開始されました。 www.redhat.com RHOKPによってオフライン環境でナレッジが参照しやすくなるだけでなく、Red Hatの製品ドキュメントやナレッジベースなどに記載されている設定ファイルや実行コマンドのコピペをオフライン環境にあるシステム上でも実行しやすくなっています。 オフラインの開発環境などで、ナレッジに記載されている設定ファイルや実行コマンドなどを色々試したいときに便利です。 本記事ではRHOKPの利用方法や、RHOKPのコンテナを例にしてPodmanのQuadletによるsystemdとの連携方法をご紹介します。 Red Hat Offline Knowledge Portal (RHOKP) RHOKPの利用方法 PodmanのQuadletによるsystemdとの連携 おまけ Red Hat Offline Knowledge Portal (RHOKP) RHOKPはRed Hat製品に関する独自のナレッジを安全にオフラインで利用するためのポータルであり、軽量な Open Container Initiative (OCI) 準拠のコンテナイメージとして提供しています。RHOKPはRed Hat製品に関する以下の情報をまとめて提供します。 製品ドキュメント 製品ライフサイクル ナレッジベース 製品のエラータ(更新情報) 公開されたCVEとRed Hat製品への影響度 上記のCVEや影響度を照会するためのAPI情報 これらの情報の検索エンジン 有効なRed Hat Satelliteのサブスクリプションを持っているユーザーであれば、無料でRHOKPを利用できる ようになっています。Red Hat Satelliteのサブスクリプションは AWS/Azure/Google Cloudなどのパブリッククラウドの従量課金制のRHELユーザーは無料で利用できる ため、これら従量課金制のRHELユーザーはRHOKPも無料で利用できるようになっています。Red Hat Satelliteと同様に、RHOKPもRed Hatがサポートを提供します。 Red Hatのナレッジ更新に従って、RHOKPのコンテナイメージも定期的に更新されていきます。 RHOKPコンテナイメージの情報 (更新日/イメージサイズ/タグ/取得方法など)は、Red Hat Ecosystem Catalog(Red Hatとパートナー企業の様々な製品情報を掲載しているWebページ)から参照できます。 RHOKPの利用方法 RHOKPはOCI準拠のコンテナイメージ(x86_64版とARM64版を提供)であるため、RHELのPodmanやOpenShiftだけでなく、OCI準拠のコンテナランタイム(Dockerなど)でも実行できます。ただし、RHELかOpenShift以外でRHOKPを実行する場合、RHOKPのサポートは サードパーティーソフトウェアに関するRed Hatサポートポリシー に従って提供されますのでご注意ください。 RHOKPの公式ドキュメントは以下にあります。RHOKPのユーザーガイドに システム要件 ( CPU2コア以上/メモリ2GB以上を推奨 )も記載されています。 docs.redhat.com 上記のユーザーガイドに沿ったRHOKPの利用方法をご紹介したブログがありますので、参考にしてください。RHOKPコンテナをユーザーガイドに沿って実行すると、 http://localhost:8080 または https://localhost:8443 でアクセスできます。 qiita.com RHOKPは最新のRHEL10に関する製品ドキュメントも提供しています。 PodmanのQuadletによるsystemdとの連携 OCI準拠のRHOKPコンテナは podman run や docker run コマンドなどで実行できますが、Podman v4.4以降に導入されたQuadletを利用すると、systemdでコンテナを実行するためのユニットファイルを簡単に作成できるようになります。RHEL8/RHEL9/RHEL10では、Podman v4.6以降でQuadletが利用できるようになっています。以下のブログでは、Quadletを使ってローカルユーザー権限で実行するコンテナをsystemdで管理するためのユニットファイルを作成/実行する例を紹介しています。 www.redhat.com このブログを参考にして、RHOKPコンテナ実行をrootユーザー権限で永続化してみます。以下のユニットファイルを作成します。RHOKPのコンテナイメージをrootユーザー権限で取得していない場合は、 sudo podman pull コマンドでRHOKPのコンテナイメージを取得しておいて下さい。 sudo podman login registry.redhat.io sudo podman pull registry.redhat.io/offline-knowledge-portal/rhokp-rhel9:latest cat <<EOF > rhokp.container [Unit] Description=RHOKP container [Container] Image=registry.redhat.io/offline-knowledge-portal/rhokp-rhel9:latest PublishPort=8080:8080 PublishPort=8443:8443 Environment=ACCESS_KEY=XXXXX Pull=never [Install] WantedBy=multi-user.target default.target EOF [Container] セクションでは以下のオプションを指定しています。それ以外は通常のユニットファイルと同じです。各オプションの詳細は man podman-systemd.unit コマンドで確認できます。 Image : 実行するコンテナイメージ。 PublishPort : コンテナのポートをホストに公開。 podman run コマンド実行時の -p 8080:8080 -p 8443:8443 オプション。 Environment : コンテナ実行時の環境変数。key: ACCESS_KEY , value: XXXXX を指定。 Pull : イメージプルのポリシー。 never に設定すると、イメージがローカルホストに無い場合にイメージをpullしない。 この rhokp.container ユニットファイルを、rootユーザー権限で /etc/containers/systemd/ ディレクトリにコピーした後に、systemdの設定として読み込ませて起動します。 RHOKPユーザーガイド記載の podman run コマンドなどで実行しているRHOKPコンテナがある場合、ホストのポート重複を避けるため、 sudo systemctl start コマンド実行前に podman stop コマンドなどでRHOKPコンテナを停止しておいて下さい。 sudo cp rhokp.container /etc/containers/systemd/ sudo systemctl daemon-reload sudo systemctl start rhokp.service rhokp.service を起動した後にしばらく待ちます。 systemctl status コマンドで下記のように出力されれば、正常にRHOKPコンテナがsystemdのサービスとして実行できていることを確認できます。ここで generated と表示されているのは、この rhokp.service のユニットファイルがsystemdによって自動生成されたことを示しています。このように自動生成されたユニットファイルについては自動的に有効化されているため、永続化のための systemctl enable コマンドを実行する必要はありません。 systemctl status rhokp.service ● rhokp.service - RHOKP container Loaded: loaded ( /etc/containers/systemd/rhokp.container ; generated ) Active: active ( running ) since Tue 2025-06-10 06:09:59 UTC; 9h ago Invocation: 9bc4e8e5d9c848a1bbcd4f6f20202322 Main PID: 1717 ( conmon ) Tasks: 285 ( limit: 22851 ) Memory: 2 .6G ( peak: 3 .1G ) CPU: 26min 39 .111s CGroup: /system.slice/rhokp.service ├─libpod-payload-d65230555cdadc2d959e1fc58c87c868c7d8b2311ce1256d83789020cd296b9f │ ├─ 1723 mel │ ├─ 4795 httpd -D FOREGROUND │ ├─ 4796 /bin/bash /usr/local/bin/run-solr │ ├─ 4892 java -server -Xms 1g -Xmx 1g -XX :+UseG1GC -XX :+PerfDisableSharedMem -XX :+ParallelRefProcEnabled -XX :MaxGCPauseMillis = 250 -XX :+UseLargePages -XX :+AlwaysPreTo > │ ├─ 4934 /usr/bin/coreutils --coreutils-prog-shebang =cat /usr/bin/ cat │ ├─ 4935 /usr/bin/coreutils --coreutils-prog-shebang =cat /usr/bin/ cat │ ├─ 4936 /usr/bin/coreutils --coreutils-prog-shebang =cat /usr/bin/ cat │ ├─ 4937 /usr/bin/coreutils --coreutils-prog-shebang =cat /usr/bin/ cat │ ├─ 4939 httpd -D FOREGROUND │ ├─ 4941 httpd -D FOREGROUND │ ├─ 4943 httpd -D FOREGROUND │ ├─ 4961 httpd -D FOREGROUND │ ├─ 7017 /bin/sh │ ├─ 9609 httpd -D FOREGROUND │ └─ 47392 /usr/bin/coreutils --coreutils-prog-shebang =sleep /usr/bin/ sleep 60 └─runtime └─ 1717 /usr/bin/conmon --api-version 1 -c d65230555cdadc2d959e1fc58c87c868c7d8b2311ce1256d83789020cd296b9f -u d65230555cdadc2d959e1fc58c87c868c7d8b2311ce1256d837 8> systemdによって自動生成された rhokp.service のユニットファイルは、 /run/systemd/generator/ にあります。 cat /run/systemd/generator/rhokp.service # Automatically generated by /usr/lib/systemd/system-generators/podman-system-generator # [ Unit ] Wants =network-online.target After =network-online.target Description =RHOKP container SourcePath =/etc/containers/systemd/rhokp.container RequiresMountsFor =%t/containers [ X-Container ] Image =registry.redhat.io/offline-knowledge-portal/rhokp-rhel9:latest PublishPort =8080:8080 PublishPort =8443:8443 Environment =ACCESS_KEY = XXXXX Pull =never [ Install ] WantedBy =multi-user.target default.target [ Service ] Environment =PODMAN_SYSTEMD_UNIT = %n KillMode =mixed ExecStop =/usr/bin/podman rm -v -f -i --cidfile = %t/%N.cid ExecStopPost =-/usr/bin/podman rm -v -f -i --cidfile = %t/%N.cid Delegate =yes Type =notify NotifyAccess =all SyslogIdentifier =%N ExecStart =/usr/bin/podman run --name systemd-%N --cidfile = %t/%N.cid --replace --rm --cgroups = split --pull never --sdnotify = conmon -d --publish 8080:8080 --publish 8443:8443 --env ACCESS_KEY =XXXXX registry.redhat.io/offline-knowledge-portal/rhokp-rhel9:latest RHOKPのコンテナイメージを更新する場合、 sudo podman pull コマンドで最新のRHOKPのコンテナイメージを取得して、 sudo systemctl restart コマンドでRHOKPコンテナを最新のRHOKPイメージで再起動します。この時、不要になった古いRHOKPのコンテナイメージを sudo podman rmi コマンドで削除できます。 sudo podman login registry.redhat.io sudo podman pull registry.redhat.io/offline-knowledge-portal/rhokp-rhel9:latest sudo systemctl restart rhokp.service sudo podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/offline-knowledge-portal/rhokp-rhel9 latest daebbdb5e677 32 hours ago 11 . 1 GB < none > < none > 3a22adf3b92f 8 days ago 11 . 1 GB sudo podman rmi 3a22adf3b92f systemdで管理しているPodmanコンテナの状態をWebコンソールで確認したい場合は、RHELの標準機能の1つとして提供される Cockpit を利用できます。Cockpit関連のパッケージをインストールして起動した後に、 https://localhost:9090 でWebコンソールにアクセスできます。rootユーザーでログインしたい場合、以下のように /etc/cockpit/disallowed-users ファイルの root をコメントアウトして下さい。 sudo dnf -y install cockpit cockpit-podman sudo systemctl enable --now cockpit.socket cat /etc/cockpit/disallowed-users # List of users which are not allowed to login to Cockpit # root RHELのWebコンソールでは、Podmanで保存/実行したコンテナイメージ、実行中のコンテナのCPU/メモリの利用率(以下の画像の例では、ホストのCPU(2コア)/メモリ(4GB)に対する利用率)、コンテナの環境変数/ログ/コンソールを見ることができます。また、Podmanコンテナを以下の「コンテナーの作成」ボタンから実行できるようにもなっています。 QuadletによるRHOKPコンテナの永続化を解除したい場合、 sudo systemctl stop コマンドでRHOKPコンテナを削除した後に、 /etc/containers/systemd/rhokp.container ファイルを削除して sudo systemctl daemon-reload を実行します。すると、systemdが自動生成した /run/systemd/generator/rhokp.service ファイルが自動削除されて、永続化が解除されます。 sudo systemctl stop rhokp.service sudo rm -f /etc/containers/systemd/rhokp.container sudo systemctl daemon-reload ls /run/systemd/generator/rhokp.service ls: cannot access ' /run/systemd/generator/rhokp.service ' : No such file or directory systemctl status rhokp.service × rhokp.service Loaded: not-found ( Reason: Unit rhokp.service not found. ) Active: failed ( Result: exit-code ) since Tue 2025-06-10 16:45:15 UTC; 8min ago Duration: 10h 35min 6 .202s Invocation: 9bc4e8e5d9c848a1bbcd4f6f20202322 Main PID: 1717 ( code =exited , status = 137 ) Mem peak: 3 .1G CPU: 29min 42 .898s おまけ 2025年6月時点でのRHOKPをPodmanで実行する場合のナレッジのURLと、それらに対応するRed HatのWebページのURLは以下のようになっています。 製品ドキュメント 例: RHEL10のリリースノート RHOKP: https://localhost:8443/documentation/en-us/red_hat_enterprise_linux/10/html-single/10.0_release_notes/index Red HatのWebページ: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/10.0_release_notes/index ナレッジベース 例: RHELのsosreportの紹介 RHOKP: https://localhost:8443/solutions/3592 Red HatのWebページ: https://access.redhat.com/solutions/3592 製品ライフサイクル RHOKP: https://localhost:8443/product-life-cycles/update_policies/ Red HatのWebページ: https://access.redhat.com/product-life-cycles/update_policies/ Red Hat CVEのデータベース 例: CVE-2025-5384 RHOKP: https://localhost:8443/security/cve/CVE-2025-5384/ Red HatのWebページ: https://access.redhat.com/security/cve/cve-2025-5384/ 製品のエラータ 例: RHSA-2025:8374 - Moderate: kernel security update RHOKP: https://localhost:8443/errata/RHSA-2025:8374/ Red HatのWebページ: https://access.redhat.com/errata/RHSA-2025:8374/ そのため、RHOKPのナレッジのURLをRed HatのWebページのURLに変換したい場合は、 製品ドキュメントの場合: localhost:8443/documentation/en-us を docs.redhat.com/en/documentation に置換 ナレッジベースやCVEなどの場合: localhost:8443 を access.redhat.com に置換 といった置換作業をする必要があります。こちらも参考にしてください。

こんにちは、Red Hatでコンサルをしている中川です。 今回から不定期にアプリケーションモダナイゼーションに関連する記事をアップしていこうと思います。 初回となるこの記事では、「アプリケーションモダナイゼーションって何？」という問いに対して、現場視点で噛み砕いてお伝えします。 はじめに：なんとなく知ってるけど、よくは知らない「モダナイゼーション」 モダナイゼーションとは、「今も価値を発揮できる状態」にアプリケーションを進化させること ❌ よくある誤解：「最新技術にすればモダナイゼーション」？ 🔄 モダナイゼーションは「今の業務とのギャップ」を埋める営み 💡 モダナイゼーションの目的は、“変えやすくすること” なぜモダナイゼーションが必要なのか？ — 止まったシステム、進む現実 モダナイゼーションの主要なアプローチ：Red Hatの「6R」 おわりに：モダナイゼーションとは“技術”の話ではなく“価値”の話 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート はじめに：なんとなく知ってるけど、よくは知らない「モダナイゼーション」 最近、IT業界では「アプリケーションモダナイゼーション（以下、モダナイゼーション）」という言葉をよく聞くようになりました。 ただ、実際に関わってみると、「それって結局何をすることなの？」と迷うことも多いです。 私自身、もともとJavaやPythonでWebシステムの設計・開発・運用をしてきた中で、現在はApache Camelなどを活用したシステムの導入支援に携わっています。では、現場では「モダナイゼーション」とはどのように受け止められているのでしょうか？ モダナイゼーションとは、「今も価値を発揮できる状態」にアプリケーションを進化させること モダナイゼーションとは、単に古いシステムを新しい技術で作り直すことではありません。 モダナイゼーションの目的は、「業務の変化」「技術の進化」「セキュリティや法令対応」などに柔軟に対応できる状態をつくることにあります。 もう少し踏み込んで言えば、 「アプリケーションの価値を、現在・未来の業務に適した形で再構築・持続させること」 といえるかもしれません。 ❌ よくある誤解：「最新技術にすればモダナイゼーション」？ たとえば「クラウドネイティブにする」「マイクロサービスに分割する」「コンテナに載せる」といった技術的な話題と一緒にモダナイゼーションが語られることがあります。 しかし、 “技術の新しさ”は目的ではなく、手段の1つ にすぎません。 最新技術を導入した結果、開発や運用が複雑になったり、チームに馴染まなかったりして、逆に価値を下げてしまうこともあります。 🔄 モダナイゼーションは「今の業務とのギャップ」を埋める営み 業務はどんどん進化していきます。 たとえば顧客対応のスピードやチャネルは年々多様化し、柔軟な連携や可視化も求められるようになります。 一方で、システムはリリースされた時点から“古くなっていく”ものです。 この進化していく現実と、変化しにくいシステムとのギャップを埋める営みこそが、モダナイゼーションです。 💡 モダナイゼーションの目的は、“変えやすくすること” 最終的に目指すのは、「変えること」ではなく 「変えやすくすること」 です。 変化し続ける業務に対して、システムも柔軟に、スピーディに追従できる状態をつくることが、モダナイゼーションの価値です。 なぜモダナイゼーションが必要なのか？ — 止まったシステム、進む現実 こういう課題、ありませんか？ 「この帳票のレイアウトをちょっと変えるだけで1ヶ月かかるって本当？」 「クラウドに移行したいが、現行システムのコードが複雑かつ属人化していて、誰も安全に修正できない状態になっている」 「あの人が異動したらこのアプリをメンテできる人がいなくなるんだけど…」 現場では、こうした“あるある”がモダナイゼーションの火種になることが多いです。 また、技術が古いと、見えないコストが増え続けます。 開発言語やミドルウェアがレガシーで、対応できるエンジニアが社内にいない OSやライブラリがサポート切れで、セキュリティリスクが高い ドキュメントがなく、特定の人にしかわからない状態になっている 結果的に「ちょっとした改修」でも大きな工数がかかり、「変えたくても変えられない」状態に陥ります。 「まだ動いてるから大丈夫」は本当に大丈夫でしょうか？ テストコードがなく、動作確認はすべて手動でおこなう 開発環境が古く、ビルドに時間がかかりすぎる 何か障害が起きたときに、誰も中身を触れない 動いてはいるけれど、変更もできず、壊れたら復旧もできない——それがレガシーの本当の怖さです。 こうした課題の多くは、「技術的負債」が蓄積された結果です。 モダナイゼーションは、その負債を解消し、開発や運用の“健全性”を取り戻すための取り組みとも言えます。 特に日本企業では、SIerに委託して開発されたシステムがブラックボックス化し、変更や見積もりの妥当性が社内で判断できない状況も少なくありません。 モダナイゼーションを通じて構成や仕様を整理・可視化することで、ベンダとのやり取りも“アンダーコントロール”に近づけることができます。 モダナイゼーションの主要なアプローチ：Red Hatの「6R」 モダナイゼーションと言っても、方法は1つではありません。Red Hatでは、そのアプローチを「6つのR（6R）」として整理しています。 各アプローチがどのような課題に対応し、どんな効果をもたらすのかを整理すると、現状や目的に応じた選択がしやすくなります。 Rの種類 アプローチ概要 主な効果 Retire すでに使われていない、もしくは業務的に不要となったアプリケーションを廃止・削除します。レガシー資産の棚卸しの一環として実施されることが多く、意外と見落とされがちですが重要なアプローチです。 利用されていないシステムの保守・運用コストを削減し、限られたリソースを本当に必要なものに集中できる Retain 現時点では十分に機能しており、他システムと密に連携しているなどの理由から、あえて変更せずに現状維持する選択です。将来的な移行対象として棚上げする場合も含まれます。 コストやリスクをかけず、当面は安定稼働を優先することで全体最適を図れる Rehost アプリケーションの構造を変えずに、既存環境（オンプレミス等）からクラウドや仮想基盤へそのまま移行する、いわゆる「Lift & Shift」のアプローチです。 インフラ老朽化のリスクを回避しつつ、比較的短期間での環境刷新が可能 Replatform アプリケーションの基本構造は保ちつつ、一部をクラウドサービスやコンテナプラットフォームに適応させるなど、運用効率化やスケーラビリティ向上を目的とした改修を行います。 運用の効率化・自動化が可能になり、技術的負債の一部も軽減される Refactor アプリケーションのコードやアーキテクチャを抜本的に見直し、クラウドネイティブ化やマイクロサービス化といった変化に対応するものです。中長期的な開発・運用の柔軟性を重視します。 技術的負債の抜本解消、ビジネス要件の変化に追従できる構造への進化 Repurchase 独自開発していたシステムをやめて、市販パッケージやSaaSなどの既製品で置き換えるアプローチです。再開発を避けることでスピーディな導入が可能です。 保守・運用コストの大幅削減、機能の標準化と外部委託負荷の軽減 このように、モダナイゼーションは“全部作り直すこと”ではなく、現状と目的に応じて柔軟にアプローチを選ぶべきです。 各アプローチの詳細や、どう選び分けるか？については、今後の記事で詳しく紹介する予定です。 おわりに：モダナイゼーションとは“技術”の話ではなく“価値”の話 現場で感じるのは、モダナイゼーションとは「技術を最新にすること」ではなく、「業務や組織にとって価値を出せるシステムを維持・進化させること」です。 古くても価値を出しているシステムもあります。 逆に、新しくても業務にフィットしていなければ意味がありません。 「どう変えるか？」を考える前に、「なぜ変える必要があるのか？」を自分たちの業務の文脈で見つめ直すことが、モダナイゼーションの第一歩です。 次回は、こうした背景にある“技術的負債”が現場にどのような影響を与えるのか、具体例を交えて掘り下げてみたいと思います。 Red Hat コンサルティングのご紹介：カスタム・ソリューションの構築をエキスパートがサポート 「技術的負債を解消し、ビジネスの変革を加速する第一歩を踏み出しませんか？ Red Hatが提供するベストプラクティスと実践的なコラボレーションにより、お客様に最適化された『戦略的ロードマップの作成』から、最終的な『全社規模への拡張』までを伴走支援します。」 ご興味のある方は、Red Hat コンサルティングへぜひお問い合わせください。 www.redhat.com

Streams for Apache Kafka の リリースサイクルと Zookeeper のサポートについて レッドハットのソリューションアーキテクトの森です。 Red Hat の Apache Kafka 製品「Streams for Apache Kafka」(旧 Red Hat AMQ Streams) は、2025年3月に LTS版の 2.9 をリリースしました。 このバージョンでは Zookeeper も KRaft も両方サポートされていますが、次のバージョン（3.0）から Zookeeper のサポートが終了する予定です。 そのため、2.9 以降に Kafka クラスタを新たに構築する場合や、既存の Zookeeper モードを継続利用している場合でも、KRaft モードへの移行が必須となってきます。 access.redhat.com ZookeeperとKRaftの違いとは？ 従来の Apache Kafka は、クラスタのメタデータ管理に外部の Zookeeper を必要としていました。 KRaft（Kafka + Raft）はこれを置き換えるもので、Kafka 自身がクラスタの構成・状態管理を内包するアーキテクチャです。 （Raftとは、分散システムにおけるコンセンサスアルゴリズムの一種ですが、詳細についてはここでは割愛します） KRaft モードに移行すると、主に以下のメリットがあります。 構成がシンプルに Kafka のみでクラスタ管理が完結し、Zookeeper の構築や監視が不要になります。 可観測性とデバッグ性が向上 メタデータが Kafka 内部に統合されているため、Kafka の API やログからクラスタ状態を一貫して確認可能です。 高可用なメタデータ管理 Raft アルゴリズムによりメタデータが複製され、リーダー障害時も高速にフェイルオーバーします。 KRaftモードにおける2種類のKafka Node管理 KRaftモードにおいて、Kafkaクラスターの各Nodeには、BrokerロールもしくはControllerロール、あるいはその両方のどちらかが割り当てれられます。 Broker ロール メッセージの受信・送信・ログ保存を担当 パーティションデータのレプリケーションを行い、可用性を確保 Controller ロール クラスタ構成のメタデータを管理（トピック作成・ISR更新・リーダー選出 など） 3台構成が一般的で、1台が Active Controller に選出 Raftアルゴリズムにより、3台の間で強い整合性を持ってメタデータを複製 この構成により、トピック作成やパーティション移動などのメタデータ操作は Controller ノードが一元的に担当し、Broker はデータ処理に専念できます。 下の図は、KRaftモードにおいて、BrokerとControllerを分離した構成と、BrokerとControllerを兼任するNodeがある場合の構成です BrokerとControllerを分離した構成 BrokerとControllerを兼任するNodeがある場合の構成 Streams for Apache Kafka on OpenShift での KRaft モード移行手順 ここでは、実際にStreams for Apache Kafka on OpenShift において、KRaftモードに移行するための手順をご紹介します。 まだ移行が完了していない場合、Kafka クラスターのカスタムリソースにKRaftへの移行に関するWarning通知が表示されるようになっています。 手順1. KafkaNodePool (broker ロール) の作成 name : kafka にすること（PVC の再利用ができず、データが消失してしまいます） replicas , storage は 移行対象の Kafkaクラスター の カスタムリソース の内容と完全に一致させる 手順2. Kafkaクラスターのカスタムリソース に strimzi.io/node-pools アノテーションを追加 以下のアノテーションを Kafkaクラスターのカスタムリソース に追加します。 KafkaNodePool を使った管理に切り替える宣言 このアノテーションを 追加するだけでは KRaft移行 はまだ始まらない metadata: annotations: strimzi.io/node-pools: enabled 手順3. Kafkaクラスターのカスタムリソース から不要な設定を削除 これらは KafkaNodePool 側に管理を移すため削除が必要です spec.kafka.replicas spec.kafka.storage spec.kafka.config.inter.broker.protocol.version 手順4. KafkaNodePool (controller ロール) の作成 name : controller で作成する 名前は任意だが、クラスタ YAML 内の可読性や整合性のため controller が推奨 Storage は既存zookeeperの設定と一致させる必要はない。少し余裕をもって 10〜20Gi程度にしておく 手順5. Kafkaクラスター の カスタムリソース に strimzi.io/kraft　アノテーションを追加 下記アノテーションを追加することで、KRaftモードへの移行がスタートします metadata: annotations: strimzi.io/kraft: migration 手順6. 数分待機し、移行の完了を待つ KafkaMetadataState: KRaftPostMigration になったらKRaftへの移行完了です。 手順7. Kafka クラスターのカスタムリソース の strimzi.io/kraft アノテーションを更新して移行完了を宣言する これで完全に KRaft に移行完了を宣言します 宣言後は、Zookeeperを使った管理にはロールバックができなくなります metadata: annotations: strimzi.io/kraft: enabled strimzi.io/node-pools: enabled 手順8. Kafka クラスターのカスタムリソース から不要な spec.zookeeper を削除 手順9. zookeeperで使用していた PVC も不要になるので削除しておく 手順10. KRaft移行した Kafka クラスターのコンディションを確認し、Warning通知がないことを確認 参考情報 今回はOpenShiftのKafka Operatorを使用したKRaftモードへの移行についてご紹介しました。Streams for Apache kafka を RHEL上でご利用の場合は、マイグレーションの手順が異なりますので、RHEL版のマイグレーション手順のドキュメントをご確認頂ければと思います。 on OpenShift でのマイグレーション手順 docs.redhat.com on RHEL でのマイグレーション手順 docs.redhat.com 終わりに いかがでしたでしょうか？ Red Hat Streams for Apache Kafka は、次のメジャーリリース（3.0）で Zookeeper のサポートが終了予定です。 今後も Kafka を安定的に活用していくためには、KRaft モードの理解と早めの移行準備が重要になります。 本記事や公式ドキュメントを参考に、今のうちから構成や移行手順を見直しておくことをぜひご検討ください。 なお、KRaft への移行に関する具体的な技術検討や、より詳細な構成相談などが必要な場合は、Red Hat からの技術支援も提供可能です。お気軽に担当営業までお問い合わせいただければと思います。

皆様こんにちは、Red Hat の中島です。 ここでは2025年4月より日本から利用できるようになった ”Red Hat Ansible Automation Platform Service on AWS” （以下 AAP on AWS）について紹介させてください。 このサービスは従来のRed Hat Ansible Automation Platform(以下AAP)とはいくつかの異なる特徴を持っています。 AAP on AWS の特徴 特徴 メリット 補足 SaaS型で利用できる AAPサーバーの構築・運用不要 Red Hat の SREチームが実施 従量課金で利用可能 契約期間中に自動化した対象の台数で課金されます 詳細は後述します 今回の記事ではこの AAP on AWS の利用方法を紹介致します。 注意: 本手順を実施してAAP on AWS の契約を行うと実際に課金されますのでご注意ください。 またAAPは従来通りのSelf-managed(自分でサーバーを構築して自分でAAPをインストールして利用する)方法も引き続き利用できます。こちらのSubscription「 Red Hat Ansible Automation Platform Subscription on AWS 」もAWS経由で購入可能になっており、AWSだけでなくオンプレや他のクラウドでも利用可能なAAPのSubscriptionを購入できます。ぜひこちらもご活用ください。 合わせて同じタイミングで多くの新サービスが利用可能になっておりますので、興味があればぜひこちらもご確認ください。 rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com 利用までの流れ AAP on AWS は以下の流れになります。 必要なアカウントを作成する AWS で AAP on AWS を契約する Red Hat Hybrid Cloud Console で AAP on AWS をディプロイする AAP on AWS へログインして Subscription を設定する 注意: ここで紹介する手順は将来的に変更される可能性があります。最新の手段については マニュアル をご確認ください。 では、個別の内容について見ていきましょう。 AAP on AWS を利用するための準備 本サービスを利用するには2つのアカウントをあらかじめ作成しておく必要がありますので、まだの方は以下のリンクから作成してください。 Red Hat アカウント AWS アカウント AWS で AAP on AWS を契約する 1) AWSにログインします。 2) 検索ボックスで「red hat ansible automation platform service」を検索 "Marketplace" の項目に表示される「Red Hat Ansbile Automation Platform Service on AWS Sold by: Red Hat」を選択します。 注意： Sold by Red Hat Limited ← 欧州の一部の国の税制に対応するため購入先、 Sold by Red Hat ← 日本を含むそれ以外国の購入先となっております。 3) サービスページが表示されたら「View parchase option」を選択 4) 契約内容を選択 本記事の執筆時点では、以下が選択可能な項目になっています。利用方法に合わせて選択してください。 選択項目 内容 補足 契約期間 月単位、年単位 自動更新 ON/OFF 基本契約台数 何台を自動化するか 自動化の対象となる仮想マシンの台数、ネットワーク機器などの台数を合計して選択します 何を「ノード」としてカウントするかについては こちら をご参照ください 次で補足します 補足) 追加コストについて 上記で契約したノード数を上回って自動化を行った場合は、以下の追加コストが請求されます。また、実際にAAP on AWS サービスが開始されると、サービスを起動するためのサーバーやストレージリソース等を含めた各種管理費用として「Control Plane Infrastructure and Service Fee」も請求されます。 注意: 超過分の自動化ノードのコストは契約期間が終了すると（月単位の契約の場合は1ヶ月後）リセットされ、次の契約期間で超過が発生しなければその分のコストは発生しません。 5) 契約内容に問題がなければ「Subscribe」を選択 6) 契約が完了するのを待つ 通常数分で終わります ↓ これでAWS側での作業は終了しました。 「Set up your account」を選択して、Red Hat の画面へと操作を移してください。 Red Hat Hybrid Cloud Console で AAP on AWS をディプロイする 1) AWSとRed Hat のアカウントをリンクさせる AWS側で「Set up your account」をクリックすると、Red Hat Hybrid Cloud Console のログイン画面へ移ります。こちらへRed Hat アカウントを使ってログインしてください。ログインするとAWSとのアカウント接続のメニューが起動しますので「 connect accounts」を選択してください。 2) AWSのアカウントIDを入力 補足) AWSのアカウントIDの確認 AWSコンソールの右上から確認できます。 3) AAP on AWS のディプロイ先リージョンを選択 2025年12月時点で ap-northeast-1(東京)、ap-northeast-3（大阪）が選択可能になっております。 執筆時点で東京リージョン ap-northeast-1 を選択することができません（将来的に対応される予定です）。AAPの自動化は遠距離でも利用できますが、「Execution Node」を自動化の対象の近くに配置することで、距離による自動化のオーバーヘッドを解消することができます。 Execution Node の配置については こちら のマニュアルをご確認ください。 4) 「Provisioning」を選択しディプロイを開始 5) ディプロイが完了 暫く待つ（数分〜数十分程度）と、アクセスのためのURL情報が表示されます。 万一、いつまで立ってもディプロイが完了しない場合は Red Hat のサポート にご連絡ください。 次の手順でログインパスワードを取得してAAP on AWS へログインしましょう！ AAP on AWS へログインして Subscription を設定する 1) ログインパスワードの取得 サービスのディプロイが開始されると、RHアカウントに登録したメールアドレスにログインパスワードの情報が届きます。 こちらのリンクは「1度」しかクリックできません。必ずパスワードは自分の手元にメモしておいてください。 本メールが届かない、パスワードのメモを忘れてしまった場合は、 Red Hat のサポート に連絡してパスワードの初期化を依頼してください。 2) Subscription の登録 取得したパスワードを使ってログインすると、AAPの Subscriptionの登録画面が開きます。以下の設定を行います。 項目 内容 補足 Select your Ansible Automation Platform subscription to use Username / password を選択 Red Hat Username 先ほど Red Hat Hybrid Cloud Console にログインしたRed Hat アカウント Red Hat Password 先ほど Red Hat Hybrid Cloud Console にログインしたRed Hat アカウント Subscription Red Hat Ansible Automation Platform Service, Premium (On-Demand, Enablement) を選択 このSubscription は AAP on AWS 専用の特別なSubscripitionで、契約後に AWS − Red Hat のアカウントをリンクすると自動的に付与されています 3) これで手順は完了です！ 後は自由に Playbook を登録して自動化ジョブを動かしてください。 まとめ 今回の記事では AAP on AWS を利用するまでの流れを紹介いたしました。 これまでは自分でサーバーを準備して、そこに可用性などを考慮してAAPをインストールする必要がありましたが、本サービスを使えば2時間前後でAAPを利用することができます。また構築後の運用（バージョンアップ等）もSREチームによって行われるため、自動化の担当者はPlaybookとジョブの開発に専念することができます。 ぜひ活用して自動化の実現に役立ててください。

こんにちわ。 Red HatのSolution Adoption Architectの石倉です。 Red Hatで、カスタマーサクセスチームに所属する技術営業です。 昨今、SAP社の基幹システムアプリケーション(SAP S/4HANA)をSAP社が提供するクラウドサービス(RISE with SAP)に移行するケースも増えてきていますが、 従来通り、管理・運用をお客様ご自身で実施されたいというご要望も多く頂きます。 更にその際、HW資産管理業務の省力化などの理由で、データセンターにSAP社基幹システムアプリケーション(SAP S/4HANA)を設置するのではなく、AWSのようなパブリッククラウド上でセルフマネージド型のSAP S/4HANAを構築し、データ移行、最新版へのバージョンアップを実施するケースもよくお聞きします。 Red Hatでは、SAP社、AWSとも協業し、以前はデータセンターでセルフマネージド型運用を行っていたECCのような旧バージョンのSAP社アプリケーションをバージョンアップする際、 AWSにマイグレーションしても、データセンターに配置していた場合と同様の操作感で利用出来るOSのサブスクリプションもご用意をしています。 本稿では、AWS上でSAP S/4HANAをセルフマネージド運用する場合に利用可能なSAP向けRHELソリューションの紹介をさせて頂きます。 SAP S/4HANAはLinux上で稼働し、Red Hat製のRHEL(Red Hat Enterprise Linux)でも動作サポートされています。 Red Hatでは、RHEL(Red Hat Enterprise Linux)に、SAP S/4HANAの動作、運用で必要な機能を追加した、 SAP向けRHELである、RHEL for SAP Solutionsという型番でSAPユーザ様向けにOSをご提供しています。 AWS Marketplaceにて購入する際は、RHEL for SAP Solutionsとほぼ同じコンポネントを含んでいる、 「RHEL for SAP with HA and US」という型番でご提供をしています。 　＊HA : High Availability の略 　＊US : Update Services の略 具体的にどのような機能が含まれているかは、弊社Knowledgebaseの記事で確認が可能です。 Amazon Web Services のよくある質問での Red Hat Enterprise Linux for SAP - Red Hat Customer Portal 標準のRHELと同様、SAPアプリケーション用のRHELでも、追加で以下がAWS Marketplaceで購入・利用できるようになっています。 Red Hatがサポートする従量課金制のSAP向けRHELサブスクリプション (3P PAYG SAP向けRHEL) AWSだけでなく、オンプレミス(以下、オンプレと記載)や他のクラウドでも利用できる年間契約制のSAP向けRHELサブスクリプション なお、通常のRHELの場合は、Red Hat小島さんが書かれたこちらを御覧ください。 AWS Console/Marketplaceで購入できるRHELサブスクリプション(オンプレ/他クラウド用含む) - 赤帽エンジニアブログ 以降で、AWS Console/Marketplaceから購入できるSAP向けRHELサブスクリプションや、それらに紐づいているRHEL AMIの種類について、2025年5月時点の情報をご紹介します。 AWS Consoleで購入できるSAP向けRHELサブスクリプション (1P PAYG SAP向けRHEL) AWS Marketplaceで購入できるSAP向けRHELサブスクリプション (3P SAP向けRHEL) 利用料金 3P PAYG SAP向けRHEL Red Hat SubscriptionsカタログでのSAP向けRHEL 利用方法 3P PAYG SAP向けRHEL Red Hat SubscriptionsカタログでのSAP向けRHEL まとめ AWS Consoleで購入できるSAP向けRHELサブスクリプション (1P PAYG SAP向けRHEL) 以前から利用が可能であった、AWSがサポートするSAP向けRHELサブスクリプションです。 これはAWS Consoleから購入して利用しますが、AWS Marketplaceにもそのリストが掲載されており、 提供元またはパブリッシャーが「Amazon Web Services」 「Red Hat Enterprise Linux for SAP with HA and Update Services ?.?」という名前が付いている 　注: ?.?は、8.8など、OSのバージョンが入り、バージョン毎にMarketplaceでページが違うの特徴です。 ものです。 SAP向けには、RHEL8 と、 RHEL9 があります。 　＊下記は、Marketplace上で、パブリッシャーが「Amazon Web Services」、OSが「Red Hat Enterprise Linux」でフィルターした、SAP関連の検索結果です。 AWS Marketplace: Search Results これらのSAP向けRHELはAWSにとってのファーストパーティ製品でもあるので、便宜上1P PAYG SAP向けRHELと呼ぶことにします。 通常のRHELと異なり、SAP向けのRHELのリリース状態は以下のようになっています。 - SAP向けRHEL8 : Red Hat Enterprise Linux for SAP with HA and Update Services 8.8 が最新(最終)リリース - SAP向けRHEL9 : Red Hat Enterprise Linux for SAP with HA and Update Services 9.2 が最新(最終)リリース 注：残念ながら、 8.10 や、 9.4 以上のバージョン、また、最新メジャーバージョンの 10.x シリーズは2025年5月現在、将来のリリース予定がありません。ですので、新規に導入をお考えのお客様は、特別な理由がない限りは後述する3P PAYG SAP向けRHELのご利用をご検討ください。 なお、例えば 8.8 などの古いリリースをご購入頂き、ご自身でマイナーリリースをアップデートしてご利用頂くことは可能ですし、サポートもされます。 以下はSAP向けRHEL8でのアップデート例です。数個のコマンドを実行することで、古い 8.* の OS を、簡単に最新版の 8.10 にアップデートする事が可能です。 How to update RHEL from 8.* to 8.10 on Cloud images with the "RHEL for SAP with High Availability and Update Services" subscription - Red Hat Customer Portal AWS Marketplaceで購入できるSAP向けRHELサブスクリプション (3P SAP向けRHEL) Red HatがサポートするSAP向けRHELサブスクリプションです。従量課金制と年間契約制で利用できるRHELサブスクリプションがあります。これらは、Red HatがAWS Marketplaceで販売しているものとなります。 Red HatがAWS Marketplaceで販売している製品は、提供元またはパブリッシャーが「Red Hat」のものとなります。 　＊「Red Hat Limited」提供の製品はEMEA地域専用のものなので、基本的に日本のお客様は使えません。 　＊下記は、Marketplace上で、パブリッシャーが「Red Hat」でフィルターした、SAP関連の検索結果です。 AWS Marketplace: Search Results 「Red Hat Enterprise Linux for SAP with HA and Update Services」をご選択します。 　注: 購入ステップの中で、対象のOSバージョンを選択する形になるのが特徴です。 3P PAYG SAP向けRHELは、以下が含まれています。詳細はリンク先のWebページをご参照ください。 Red Hatサポートチームが提供する プレミアムサポート Red Hat - SAP社間での協業サポート (問題の早期解決のため、Red HatとSAP社間でサポート情報の連携を行っています) Red Hat Update Infrastructure (RHUI)を利用したRHELパッケージのダウンロード/インストール/アップデート 一般提供 (GA) の開始日から 4 年間、特定の RHEL マイナーリリースのサポートを提供する Update Services for SAP Solutions 注: RHUIはクラウド環境専用のRHELリポジトリであり、3P PAYG SAP向けRHELではデフォルトで利用できます。 利用料金 3P PAYG SAP向けRHEL 3P PAYG SAP向けRHELの利用料金は、EC2インスタンスの利用料金とは別にAWSから請求されます。つまり、 ソフトウェア(SAP向けRHEL)の利用料金 (AWSリージョンごとの違いは無し) EC2インスタンス(OSタイプはLinux)を含むAWSインフラの利用料金 の合計金額がAWSから請求されることになります。料金情報は、Marketplace画面などから確認できます。 Red Hat SubscriptionsカタログでのSAP向けRHEL SAPアプリケーションを利用する場合、数ヶ月という短期利用ではなく、数年を見越した長期利用のケースは多いと思います。 その場合、「Red Hat Subscription」カタログから、SAP向けRHELを年間サブスクリプションで購入することもご検討下さい。 AWS Marketplace: Red Hat Subscriptions Pricing欄で、sapを検索ワードで検索します。 表示される価格は、EC2インスタンス利用料は含まれない、OSのみの料金ですのでご注意下さい。 「Red Hat Subscription」カタログで購入するSAP向けRHELではインスタンスタイプによらずにOS価格が固定になります(インスタンスタイプによらず、仮想マシン2台分の提供価格)。インスタンスタイプによっては、 「Red Hat Subscription」カタログで年間契約をする方が価格面で有利となりますので、ぜひこちらもご検討下さい。 これらの型番は、Red Hatがこれまでオンプレミスのお客様に販売してきたRHELサブスクリプションの型番と同じであり、 オンプレミスや他のクラウドでも利用できる年間契約制のRHELサブスクリプション となります。定価も同じです。これらをAWS上で利用する場合、 RHELサブスクリプションの年間料金 (前払い形式で、購入月の月末にAWSから請求) EC2インスタンス(OSタイプはLinux)を含むAWSインフラの利用料金 の合計金額がAWSから請求されます。 利用方法 AWS Marketplaceのカタログから購入手続きを実施するための事前準備をします。 こちらのブログの「事前準備」 と全く同じです。 3P PAYG SAP向けRHEL AWS Marketplaceの3P PAYG SAP向けRHELの利用方法をご紹介します。 以下のWebページから3P PAYG SAP向けRHELの購入手続きを実施します。 AWS Marketplace: Red Hat Enterprise Linux for SAP with HA and Update Services 画面右上にある「View purchase options」をクリックします。 その次に表示されるEULAなどの契約を読んで「Accept Terms」をクリックします。 1分ほど待つと、以下のような画面が表示されます。これで3P PAYG SAP向けRHELの購入手続きは完了です。以下の画面から年間課金制の契約を作る(「Contract options」でインスタンスタイプと数量を選択→「Add」または「Update」→「Create Contract」)こともできますが、時間課金制で3P PAYG SAP向けRHELを利用したい場合、画面右上にある「Continue to Configuration」をクリックします。 起動する3P PAYG SAP向けRHELのバージョンとリージョンを選択して、画面右上の「Continue to Launch」をクリックします。 最終確認を行った後、「Launch」ボタンをクリックします。 無事、購入が完了すると、Red Hatのカスタマーポータル( https://access.redhat.com/ )のSubscriptions Inventory一覧でも、「Red Hat Enterprise Linux for SAP with High Availability and Update Services, Full Support (Large Virtual Node, Multi-Tenant, Hourly)」(SKU : RH00806HR)という形でエントリが参照できるようになります。 　＊下記の赤枠の表示 なお、上述したよう、こちらはRed Hatのプレミアムサブスクリプションになりますので、Red Hatは24時間365日のサポートをご提供します。 Red Hat SubscriptionsカタログでのSAP向けRHEL 以下のWebページから購入手続きを実施します。 aws.amazon.com 画面右上にある「View purchase options」をクリックします。 ユニット「RHEL for SAP Premium」を選択して、数量を入力します。この時、サブスクリプションの自動更新を無効化したい場合は、「Auto-renewal」の箇所で「Do not automatically renew this contract」を選択します。そして、画面下部にある「Subscribe」ボタンをクリックすると、購入手続きが完了します。 ここで購入したサブスクリプションの料金は前払いとなり、購入月の月末にAWSから請求されます。AWSアカウントとRed Hatアカウントとの連携設定をしていない場合、 購入後に表示される「Set up your account」ボタンからRed Hatアカウントとの連携を設定して下さい。 無事、購入が完了すると、Red Hatのカスタマーポータル( https://access.redhat.com/ )のSubscriptions Inventory一覧でも、「Red Hat Enterprise Linux for SAP Solutions, Premium (Physical or Virtual Nodes)」(SKU : RH00763)という形でエントリが参照できるようになります。 　＊下記の赤枠の表示 なお、上述したように、こちらはRed Hatのプレミアムサブスクリプションになりますので、Red Hatは24時間365日のサポートをご提供します。 まとめ SAP S/4HANAで必要となるAWS上のSAP向けRHELサブスクリプションをご紹介しました。 ぜひご活用いただき、S/4HANA移行プロジェクトのお役に立てば幸いです。

Red Hatの小島です。 日本のお客様がOpenShiftをAWSで利用する場合、従来は以下のいずれかとなっていました。いずれの場合も、 OpenShiftのサポートはRed Hatが、EC2インスタンスを含むAWSインフラのサポートはAWSが提供 します。 年間契約制のOpenShiftサブスクリプションをAWSで利用する AWS Management Console(以下、AWS Consoleと記載)から購入する従量課金制のROSAを利用する しかし、2025年4月1日からの AWS Marketplaceでの取引における日本の消費税の取り扱い変更 や、2025年5月1日からの AWS MarketplaceにおけるSaaS出品のガイドライン変更 に伴い、以下をAWS Marketplaceから購入して利用できるようになりました。 Red Hatがサポートする従量課金制のSelf-Managed OpenShiftサブスクリプション AWSだけでなく、オンプレミス(以下、オンプレと記載)や他のクラウドでも利用できる年間契約制のOpenShiftサブスクリプション 本記事ではAWS Console/Marketplaceから購入できるOpenShiftサブスクリプションや、それらに紐づいているAMIについて、2025年5月時点の情報をご紹介します。予め記載しておくと、AWS MarketplaceでのRed Hat製品の購入手順は、基本的に以下のブログで紹介している手順と同様のものになります。 rheb.hatenablog.com AWS Consoleで購入できるOpenShiftサブスクリプション (ROSA) ROSAの種類 利用料金 利用方法 AWS Marketplaceで購入できるOpenShiftサブスクリプション (3P (3rd Party) OpenShift) 利用料金 3P PAYG OpenShift Red Hat SubscriptionsカタログのOpenShift 利用方法 事前準備 3P PAYG OpenShift Red Hat SubscriptionsカタログのOpenShift ROSAとSelf-Managed OpenShift on AWSの比較 AWS Console/Marketplaceで購入したOpenShiftサブスクリプションへの移行 オンプレのOpenShiftを利用している場合 Red Hat SubscriptionsカタログのOpenShiftへの移行 ROSA HCP/3P PAYG OpenShiftへの移行 AWSにOpenShiftサブスクリプションを持ち込んで利用している場合 (BYOS) Red Hat SubscriptionsカタログのOpenShiftへの移行 ROSA HCPへの移行 3P PAYG OpenShiftへの移行 まとめ Appendix ROSA HCPに関する製品ドキュメント Self-Managed OpenShiftのインストール方式 Self-Managed OpenShiftでサポートされるノード構成 OpenShiftだけでなく他のサービスも利用可能になっているので、ぜひこちらもご確認ください。 rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com AWS Consoleで購入できるOpenShiftサブスクリプション (ROSA) Red Hat OpenShift Service on AWS(以下、ROSAと記載)はマネージドOpenShiftサービスの1つあり、AWS上で実行されます。ROSAには後述するOpenShiftのエディションのうち、OpenShift Container Platformの機能が含まれています。AWS ConsoleからROSAのサービスを有効化して利用開始できます。ROSAは24時間365日のOpenShiftプレミアムサポートを提供しており、かつ、 ROSA 4.16以降の偶数バージョンからEUSアドオン Term 1による最大24ヶ月間のマイナーバージョンサポート を提供するようになりました。 OpenShiftをAWS上で利用する場合、基本的にはROSAの利用を推奨しています。 Self-Managed OpenShiftを利用する場合と比較して、ROSAを利用する際に得られる主なメリットは以下のとおりです。 OpenShiftインフラ部分の運用をRed Hatに任せることで、ユーザーはアプリケーション開発や運用に専念することが可能 コントロールプレーンやワーカーノードの障害復旧 を、Red Hatに任せることが可能 Red Hatは、障害が発生したワーカーノードを手動または自動で交換できる機能をユーザーに提供 OpenShiftの監査ログ保管をRed Hatに任せることが可能 Red Hatは監査ログを1年間保持 Red Hatのサポートケース経由で ユーザーが監査ログを要求可能 OpenShiftサブスクリプションの利用料金が、Self-Managed OpenShiftと比べて安い (後述) 赤帽エンジニアブログでは、様々なROSAの紹介記事がありますので参考にしてください。 rheb.hatenablog.com ROSAの種類 ROSAにはClassicとHosted Control Plane(以下、HCPと記載)の2種類があります。 ROSA Classic: コントロールプレーンなど全てのOpenShiftコンポーネントが、ユーザーのAWSアカウントに作成されます。 ROSA HCP (推奨): Amazon EKSのように、ユーザーのAWSアカウントにはワーカーノードのみが作成され、コントロールプレーンはRed HatのSREチームのAWSアカウントに作成されて管理されます。 2026年4月1日以降にROSA Classicの新規クラスター作成機能が終了 しますので、Red HatはROSA ClassicからROSA HCPへの移行を推奨しています。ROSA ClassicクラスターからROSA HCPクラスターに直接変換することはできません。ROSA HCPクラスターを新規構築して、アプリケーションやデータを適宜移行していただくことになります。2025年5月時点での、ROSA ClassicからROSA HCPへの移行の主な注意点は以下となります。 ROSA HCPのデフォルトのネットワークプラグインとして利用されている OVN-Kubernetes については、 内部で利用されているCIDR範囲が定義 されていて、これらと重複しないネットワーク構成を作る必要があります。 ROSA HCPではコントロールプレーンがユーザーに見えないために、ROSA Classicでは見えていた様々な監査ログなどがリアルタイムで見えなくなっています。これらの監査ログのうち、 OAuthについてはROSA HCPでもCloudWatchへのログ転送機能を利用 することで、リアルタイムで見えるようになっています。その他の監査ログは、ワーカーノードの /var/log/audit/audit.log を除いて、ユーザーにはリアルタイムで見えないままになります。ただし、前述のとおりRed Hatのサポートケース経由でユーザーが監査ログを要求できますので、後から監査ログを見ることはできます。 ROSA Classicでは対応していてROSA HCPでは対応していないその他機能一覧については、以下のナレッジをご参照ください。 access.redhat.com 2025年5月時点の最新版のOpenShift 4.18では、ROSA HCPクラスターの新規作成後に 内部IPアドレスのサブネットを変更 することはできますが、ROSA HCPクラスターの新規作成時に内部IPアドレスのサブネットを変更する機能はGAされていません。 利用料金 ROSAを利用する場合、 OpenShiftサブスクリプションの利用料金 EC2インスタンス(OSタイプはLinux)を含むAWSインフラの利用料金 の合計金額がAWSから請求されます。 上記のROSAのOpenShiftサブスクリプション利用料金は、 1つのROSAクラスターにつき、US$0.25/hour (年間割引なし. HCP版のみ請求) ワーカーノードのサービス料金 US$0.171/4vCPU/hour (年間割引あり. HCP版/Classic版で共通) ワーカーノードのEC2インスタンスが利用する4vCPU単位での課金 の合計金額となります。 利用料金の詳細情報は、以下のWebページを参考にしてください。 aws.amazon.com 利用方法 ROSA HCPの利用方法は、以下で紹介しています。 rh-open.github.io また、Red Hatの正式ドキュメントも以下にありますので、参考にしてください。 docs.redhat.com ROSAは年間契約も利用できます。 aws.amazon.com 余談ですが、ROSA HCPではAmazon EKSのようにArmベースのGravitonプロセッサのワーカーノードを利用できます。さらに、 マルチアーキテクチャクラスターにも対応 しており、1つのROSA HCPクラスターで、x86_64ベースとAWS Armベースの両方のワーカーノードを混ぜて利用することもできます。下記の画像は、m5.xlarge(x86_64ベース)とm6g.xlarge(AWS Armベース)インスタンスの、計4台のワーカーノードから成るROSA HCPクラスターの例です。 ROSA HCPでサポートしているインスタンスタイプの一覧は、以下をご参照ください。 docs.redhat.com AWS Marketplaceで購入できるOpenShiftサブスクリプション (3P (3rd Party) OpenShift) Red HatがサポートするSelf-ManagedのOpenShiftサブスクリプションです。従量課金制と年間契約制で利用できるOpenShiftサブスクリプションがあります。これらは、Red HatがAWS Marketplaceで販売しているものとなります。 Red HatがAWS Marketplaceで販売している製品は、提供元またはパブリッシャーが「Red Hat」のものとなります。「Red Hat Limited」提供の製品はEMEA地域専用のものなので、基本的に日本のお客様は使えません。 aws.amazon.com これらの製品のうち、OpenShiftに関連するものは以下です。7番以外は全て従量課金制のOpenShiftです。 Red Hat OpenShift Kubernetes Engine (x86_64版) Red Hat OpenShift Kubernetes Engine for Arm (AWS Arm版) Red Hat OpenShift Container Platform (x86_64版) Red Hat OpenShift Container Platform for Arm (AWS Arm版) Red Hat OpenShift Platform Plus (x86_64版) Red Hat OpenShift Platform Plus for Arm (AWS Arm版) Red Hat Subscriptions (年間契約制のOpenShiftを含んだRed Hat製品) 上記の従量課金制OpenShiftはAWSにとってのサードパーティ製品でもあるので、1番から6番までのOpenShiftを便宜上3P (3rd Party) PAYG OpenShiftと呼ぶことにします。 全ての3P PAYG OpenShiftはプレミアムサブスクリプションとなり、 Red Hatのプレミアムサポート を利用できます。全てのSelf-Managed OpenShiftのプレミアムサブスクリプションには、 EUSアドオン Term 1による最大24ヶ月間のマイナーバージョンサポート が付属します。 2025年5月時点で、AWS Marketplaceで販売しているOpenShiftのエディションは、 OpenShift Kubernetes Engine (以下、OKEと記載) OpenShift Container Platform (以下、OCPと記載) OpenShift Platform Plus (以下、OPPと記載) となり、違いについては以下の画像やサブスクリプションガイドを参考にしてください。各エディションでのサポートされる機能は異なりますが、2025年5月時点ではインストールなどに利用するバイナリファイルは共通しています。ただし、x86_64版とARM64版とではインストーラなどのバイナリファイルが異なります。 www.redhat.com 3P PAYG OpenShiftは通常のSelf-Managed OpenShiftと同じように、 installer-provisioned infrastructure (IPI) または user-provisioned infrastructure (UPI) を使用してAWS上にインストールできます が、以下のようないくつかの制限があります。 シングルノードと3ノード構成をサポートしない ワーカーノードとして利用できるのはRHCOSのみ 詳細は以下のWebページをご参照ください。 access.redhat.com ROSA HCPと同様にSelf-Managed OpenShiftでも マルチアーキテクチャクラスターに対応 しており、x86_64ベースとAWS Armベースのインスタンスのワーカーノード(コンピュートノード)を混ぜて構成することもできます。 2025年5月時点では、ARM64版に対応したアプリケーションはx86_64版に対応したアプリケーションより少ない傾向があるため、基本はx86_64ベースのインスタンスでSelf-Managed OpenShiftクラスターを作成しておいて、必要に応じてAWS Armベースのインスタンスをワーカーノードとして追加するのがいいでしょう。 Self-Managed OpenShift 4.18で利用できるAWSのインスタンスタイプについては、以下をご参照ください。 docs.redhat.com 利用料金 3P PAYG OpenShift 3P PAYG OpenShiftの利用料金は、EC2インスタンスの利用料金とは別にAWSから請求されます。つまり、 ソフトウェア(OpenShift)の利用料金 OpenShiftのエディションごとの違いあり OpenShiftのバージョンとAWSリージョンごとの違い無し 年間契約制のOpenShiftと同様に、 ワーカーノード(コンピュートノード)だけに課金 EC2インスタンス(OSタイプはLinux)を含むAWSインフラの利用料金 の合計金額がAWSから請求されることになります。料金情報は、EC2インスタンス起動画面などから確認できます。 年間契約制のOpenShiftと3P PAYG OpenShiftでは、x86_64版とARM64版で価格(2物理コアまたは4vCPU単位の課金)は共通しています。x86_64版とAWS Arm版のOCPの最低料金となるインスタンスタイプの例を、それぞれのOCPカタログで比較してみると、 m5.large (1物理コア=2vCPU. x86_64) のソフトウェア料金: US$0.326/hour m6g.large (2物理コア=2vCPU. AWS Arm) のソフトウェア料金: US$0.653/hour となり、AWS Arm版がx86_64版の2倍の料金となっていることが分かります。これは何故かというと、x86_64ベースのインスタンスでは、SMT(俗に言うハイパースレッティング)が有効になっているものとそうでないものがあり、SMTが有効になっている場合、1物理コア=2vCPUとしてカウントされます。ただし、全てのAWS ArmベースのインスタンスではSMTが無効化されていて、1物理コア=1vCPUとカウントされます。これによって同じvCPU数に見えるインスタンスタイプでも、料金が異なることになります。 docs.aws.amazon.com また、3P PAYG OCPの年間のソフトウェア料金を見てみると、c6i.xlarge (2物理コア=4vCPU. x86_64) と m6g.large のインスタンスタイプでは US$4,399 となり、後述する年間契約制のOCP Premiumとほぼ同じ価格となります。そのため、1年間利用する場合は m5.large のような小さいサイズのインスタンスタイプを利用しない限り、3P PAYG OCPと年間契約制のOpenShift Premiumのどちらを利用しても料金は同じと言えます。 Red Hat SubscriptionsカタログのOpenShift Red Hat Subscriptionsカタログでは、年間契約制のRHEL/OpenShift/Ansibleなどのサブスクリプションを販売しています。その中で、OpenShiftサブスクリプションは以下の6つとなります。これらはx86_64版とARM64版で共通しており、ワーカーノードが利用する2物理コアまたは4vCPU単位で課金されます。 OKE Standard (SKU: MCT3823) OKE Premium (SKU: MCT3822) OCP Standard (SKU: MCT2736) OCP Premium (SKU: MCT2735) OPP Standard (SKU: MW01622) OPP Premium (SKU: MW01621) 上記画像の Red Hat Developer Hub Premium (SKU: MW02585) はOSSであるBackstageをベースとした開発者ポータルを提供する製品であり、OpenShiftまたはManaged Kubernetesサービス(EKS/AKS/GKE)上で実行します。Developer Hubについては、赤帽エンジニアブログでも色々紹介していますので、参考にしてください。 rheb.hatenablog.com これらのSKUは、Red Hatがこれまでお客様に販売してきたOpenShiftサブスクリプションのSKUと同じであり、 オンプレや他のクラウドでも利用できる年間契約制のOpenShiftサブスクリプション となります。定価も同じです。これらをAWS上で利用する場合、 OpenShiftサブスクリプションの年間料金 (前払い形式で、購入月の月末にAWSから請求) EC2インスタンス(OSタイプはLinux)を含むAWSインフラの利用料金 の合計金額がAWSから請求されます。 これらのSKUを含んだ様々なサブスクリプションを、 AWS Marketplaceのプライベートオファー でも購入できます。ご希望の場合は「 購買専用のお問い合わせ 」のWebページから、プライベートオファーでのサブスクリプション購入希望をお問い合わせください。その際に、プライベートオファー発行に必要な情報をご案内します。 なお、AWS Marketplaceのプライベートオファーを使用して購入するソフトウェア製品に違いはありません。プライベートオファーを使用して購入したソフトウェアは、プライベートオファーを使用せずにソフトウェアを購入した場合と同じように動作します。 プライベートオファーの発行には制限があります。 全てのRed Hatサブスクリプションをプライベートオファーで購入できるわけではありません。 詳細はRed Hatまでご相談ください。 利用方法 事前準備 AWS Marketplaceのカタログから購入手続きを実施するための事前準備をします。 こちらのブログの「事前準備」 と全く同じです。 3P PAYG OpenShift AWS Marketplaceの3P PAYG OpenShiftの購入手順は、 こちらのブログで紹介している3P PAYG RHELの購入手順 と同様ですので、参考にしてください。前述のとおりOpenShiftのエディション(OKE/OCP/OPP)とアーキテクチャ(x86_64版とAWS Arm版)ごとのカタログを提供しているので、 課金を正確に実施するために、利用する全てのカタログで購入手続きを実施してください。 AWSアカウントとRed Hatアカウントを連携している場合、カタログからの購入手続きが完了すると、Red Hatアカウントに自動的に3P PAYG OpenShift専用のサブスクリプションが付与されていることを、 こちらのWebページ から確認できます。これらのOpenShiftサブスクリプションはエディションごとの違いはありますが、x86_64版とAWS Arm版で共通しています。 3P PAYG OpenShiftサブスクリプションがRed Hatアカウントに付与されていないと、Red Hatのサポートを受けられません ので注意してください。AWS Marketplaceから購入したRed Hatサブスクリプションは「Contract Number」が「Not Available」となっていますが、Red Hatからのサポートを問題なく受けることができます。 3P PAYG OKE/OCP/OPPのサブスクリプションは、以下となります。 OKE SKU: MW01961 OCP SKU: MW01965 OPP SKU: MCT4383 これらの3P PAYG OpenShiftサブスクリプションは、有効期限が切れたら自動更新される設定になっています。年間課金制の契約がある場合、一番最後に作成した契約の開始日と終了日に更新されます。サブスクリプションが不要になった場合は、OpenShiftクラスターで利用している3P PAYG OpenShift専用のワーカーノードを全て削除したあとに、 AWS Marketplaceのサブスクリプション管理画面からAMIサブスクリプションをキャンセル することで、Red Hat Subscriptions InventoryのWebページからも自動削除されます。 OpenShiftのワーカーノードとして利用する3P PAYG OpenShiftのエディションのカタログで、AMI IDを確認します。この時、 利用するAWSリージョン/OpenShiftエディション/CPUアーキテクチャ/OpenShiftバージョンごとにAMIが異なります ので、注意して下さい。 IPIを利用したOpenShiftクラスター作成や OpenShiftのMachineset によるワーカーノード(コンピュートノード)作成の際には、3P PAYG OpenShiftのワーカーノードとして利用するRHCOSの中身が自動的に上書きされます。そのため、AWSリージョン/OpenShiftエディション/CPUアーキテクチャの違いさえ考慮しておけば、AMIの中にあるRHCOSのバージョンは何でもよくなるので、 利用時点での最新版の3P PAYG OpenShiftのAMI ID を確認するだけでよくなります。なお、OpenShift IPIクラスターだけでなく、 AWS上のOpenShift UPIクラスターでもMachinesetを利用 できます。 上記画像の「Continue to Launch」ボタンからは、直接OpenShiftクラスターを作成できません。 こちらのWebページ のように、OpenShiftクラスター作成時に利用する install-config.yaml に、 上記画像で確認したAMI IDとAWSリージョンを指定 します。あとは通常どおりの手順で、Self-Managed OpenShiftクラスターを作成できます。 クラスター作成後は、3P PAYG OpenShift専用のAMI IDから起動したワーカーノードが利用するvCPU数に応じて、3P PAYG OpenShiftの利用料金が自動課金されます。 Self-Managed OpenShiftのインストーラは、 x86_64版 と ARM64版 で異なります。 Red Hat SubscriptionsカタログのOpenShift 以下のWebページから購入手続きを実施します。購入手順は こちらのブログで紹介しているRed Hat SubscriptionsカタログのRHEL購入手順 と同様ですので、参考にしてください。 aws.amazon.com 購入手続きが完了すると、以下のようなOpenShiftサブスクリプション(例: OKE Standard)がRed Hatアカウントに自動付与されます。 これはRed Hatがこれまでお客様に販売してきたOpenShiftサブスクリプション(x86_64版/ARM64版で共通)と同じであり、 AWSだけでなく、オンプレや他のクラウドでのOpenShiftに利用できます。 AWS Marketplaceから購入したRed Hatサブスクリプションは「Contract Number」が「Not Available」となっていますが、Red Hatからのサポートを問題なく受けることができます。 ROSAとSelf-Managed OpenShift on AWSの比較 前述したとおり基本的にはROSAの利用を推奨しています。ROSAに含まれるOCPの機能を利用する場合、同一構成のSelf-Managed OCPの場合と比較すると、 ROSAの方がOpenShiftサブスクリプション料金が安くなる ためです。ROSAがある程度決められた構成で提供するManaged OpenShiftサービスであり、サポート提供コストが少なくなることに起因します。以下の構成例を考えてみます。 ROSA HCPクラスター ワーカーノード: m5.xlarge (4vCPU, RAM16GiB) 2台 Self-Managed OCPクラスター (3P PAYG/BYOS OCP Premium) コントロールプレーン: t3a.xlarge (4vCPU, RAM16GiB) 3台 ワーカーノード: m5.xlarge (4vCPU, RAM16GiB) 2台 1年間利用する場合を考えてみると、それぞれのOpenShiftと関連する主なAWSインフラ(東京リージョン)の利用料金は、 ROSA HCPクラスター: 合計金額 US$6,923.12 クラスター料金: US$0.25/hour/cluster x 1cluster x 24hour x 365days = US$2,190 コントロールプレーンのEC2インスタンス料金: US$0 ワーカーノードのOpenShiftサブスクリプション料金: US$1000/4vCPU x 4vCPU x 2台 = US$2,000 ワーカーノードのEC2インスタンス料金: US$113.88/month x 2台 x 12month = US$2733.12 Self-Managed OCPクラスター (3P PAYG/BYOS OCP Premium): 合計金額 US$14,776 クラスター料金: US$0 コントロールプレーンのEC2インスタンス料金: US$90.08/month/台 x 3台 x 12month = US$3,242.88 ワーカーノードのOpenShiftサブスクリプション料金: US$4400/4vCPU x 4vCPU x 2台 = US$8,800 ワーカーノードのEC2インスタンス料金: US$113.88/month x 2台 x 12month = US$2733.12 となり、 Self-Managed OCPクラスターはROSA HCPクラスターのおよそ2倍以上の料金 がかかります。 OCP PremiumではなくOKE Standardを利用する場合だと、ワーカーノードのOpenShiftサブスクリプション年間料金が US$726/4vCPU となるので、ようやくROSA HCPより少し高いくらいの金額になります。そのため、以下のような事情がない限り、ROSA HCPクラスターを利用する方がいいでしょう。 Self-Managed OpenShiftの検証用途で 60日間の評価版サブスクリプション を利用したい Single-Node OpenShiftの1台構成 によるOpenShift機能検証など Self-Managed OpenShiftのインフラ部分を運用管理する体制がある コントロールプレーンの監視やスケールアップなど Self-Managed OpenShift UPIクラスターを利用して、以下のようなAWSリソースをシステム要件に沿ってカスタマイズしたい AWSのネットワーク構成 AWSセキュリティグループやFirewallなどのセキュリティポリシー Self-Managed OpenShift EUSアドオン Term 2による最大36ヶ月間のマイナーバージョンサポート を利用したい Self-Managed OpenShiftクラスターのコントロールプレーンのサイジングは、 こちらのWebページ を参照してください。 AWS Console/Marketplaceで購入したOpenShiftサブスクリプションへの移行 Red Hatから購入したOpenShiftサブスクリプションを、オンプレまたはAWSに持ち込んで利用(BYOS)している場合を想定して、AWS Console/Marketplaceで購入したOpenShiftサブスクリプションを利用するように移行する方法をまとめておきます。 オンプレのOpenShiftを利用している場合 Red Hat SubscriptionsカタログのOpenShiftへの移行 年間契約制のOpenShiftサブスクリプションの購入先を変更するだけなので、現在ご利用中のOpenShiftシステムを特に変更する必要はありません。今ご利用されているOpenShiftのサブスクリプションと同じ本数分を、Red Hat Subscriptionsカタログからご購入いただきます。 ROSA HCP/3P PAYG OpenShiftへの移行 AWS上に新規作成したOpenShiftクラスターに、コンテナアプリケーションやデータを移行します。この時、Migration Toolkit for Containers (MTC) という無料ツールを利用して、OpenShift 3からOpenShift 4への移行、OpenShift 4間での移行ができます。 docs.redhat.com また、OpenShift Virtualizationによる仮想化機能を利用している場合、ROSA HCPと3P PAYG OpenShiftは共にOpenShift Virtualizationに対応しているので、Migration Toolkit for Virtualization (MTV) という無料ツールを利用して、オンプレのOpenShift VirtualizationクラスターからAWS上のOpenShift Virtualizationクラスターに移行できます。 docs.redhat.com 移行前後の作業も合わせて自動化したい場合、Red HatがAWS Marketplaceで販売しているManaged Ansibleサービスを別に利用することもできます。 aws.amazon.com AWSにOpenShiftサブスクリプションを持ち込んで利用している場合 (BYOS) Red Hat SubscriptionsカタログのOpenShiftへの移行 前述の「オンプレOpenShiftサブスクリプションから、Red Hat SubscriptionsカタログのOpenShiftへの移行」と全く同じです。現在ご利用中のOpenShiftシステムを特に変更する必要はありません。 ROSA HCPへの移行 前述の「オンプレのOpenShiftからROSA HCP/3P PAYG OpenShiftへの移行」と同様に、MTC/MTV/Managed Ansibleなどのツールを利用して移行します。AWS上のSelf-Managed OpenShiftクラスターを、ROSA HCPクラスターに直接変換することはできません。 3P PAYG OpenShiftへの移行 3P PAYG OpenShiftは こちらのWebページ に記載のとおり、シングルノード構成と3ノード構成をサポートしていないので、これらの構成のOpenShiftクラスターをAWS上で利用している場合、新規構築したOpenShiftクラスターへのデータ移行が必要になります。 コントローラノード3台とワーカーノード2台以上という基本構成 のOpenShiftクラスターを利用している場合、 こちらのWebページ に記載しているようにMachinesetのAMI IDを変更します。以下の画像のように、OpenShiftのWebコンソールからMachinesetで指定しているAMI IDを、3P PAYG OpenShiftのAMI IDに変更して保存します。 あとは MachinesetのMachineのレプリカ数を変更する だけで、自動的に3P PAYG OpenShiftのAMIからワーカーノードが新規作成されます。これによって3P PAYG OpenShiftの課金が自動的に開始します。 Machineのレプリカ数は、以下の画像のようにOpenShiftのWebコンソールからも変更できます。以下の例では「0マシン」をクリックして、マシン数を「2」に編集して「保存」することでワーカーノードを0台から2台に変更しています。 1つのOpenShiftクラスター内では、AWSに持ち込んで利用している年間契約制のOpenShift(BYOS版)と3P PAYG OpenShiftのワーカーノードを混ぜて構成することもできます。ただし、OpenShiftのエディション(OKE/OCP/OPP)とサポートレベル(プレミアム)が統一されていることが条件です。 RHELのワーカーノードは OpenShift 4.16から非推奨 になり、 OpenShift 4.19から削除 された機能 なので、3P PAYG OpenShiftに移行する場合、これをきっかけにRHCOSに移行することを推奨します。RHCOSイメージのレイヤー化により、RHELをワーカーノードとして利用する機能が置き換えられ、ワーカーノードへの追加パッケージのインストールがサポートされます。RHELのワーカーノードを削除する手順は、 こちらの製品ドキュメント (RHCOSのドキュメントですが、RHELでも同じ手順です)をご参照下さい。 まとめ AWS Console/Marketplaceでは、推奨するROSA HCPをはじめとして、様々なOpenShiftサブスクリプションを購入して利用できることを紹介しました。これらのRed HatがサポートするOpenShiftサブスクリプションは、2025年5月時点では次の特徴を備えています。ぜひご活用ください。 ROSA (AWS専用のManaged OpenShiftサービス) 2種類のエディション(HCPとClassic)があり、HCPを推奨 4.16以降の偶数バージョンで、EUSアドオン Term 1による最大24ヶ月間のマイナーバージョンサポートを提供 OpenShiftのインフラ障害復旧や監査ログ保管をRed Hatに任せることが可能 Self-Managed OpenShiftと比べて、OpenShiftサブスクリプション料金が安い ROSAの利用料金はAWSインフラとは別にAWSから請求される 3P (3rd Party) PAYG OpenShift (AWS専用のSelf-Managed OpenShift) OpenShiftのプレミアムサポートを提供 偶数バージョンで、EUSアドオン Term 1による最大24ヶ月間のマイナーバージョンサポートを提供 OKE/OCP/OPP 専用のオンデマンドSKUあり (x86_64版/AWS Arm版で共通) 年間契約制のOpenShift(x86_64版/ARM64版)と課金形式/年間料金は同じ ワーカーノードとして利用できるOSはRHCOSのみ 年間契約制のOpenShift(BYOS版)と混ぜて利用することが可能 1つのOpenShiftクラスター内での、BYOS版と3P PAYG版のワーカーノードの混在構成や相互変換が可能 OpenShiftのエディション(OKE/OCP/OPP)とサポートレベル(プレミアム)が統一されていることが条件 3P PAYG OpenShiftの利用料金はAWSインフラとは別にAWSから請求される Red Hat Subscriptionsカタログで販売しているOpenShift ( AWSだけでなく、オンプレや他のクラウドでも利用可能 ) Red Hatがこれまでお客様に販売してきた年間契約制のOpenShift(x86_64版/ARM64版)のSKUと同じ Red Hatサブスクリプションの追加購入が可能 サブスクリプションが複数ある場合、一番最初に購入したサブスクリプションの契約終了日に自動統一 サブスクリプションを追加購入する場合、上記仕様により料金の日割り計算が適用 AWSで利用する場合、OpenShiftの利用料金はAWSインフラとは別にAWSから請求される Appendix ROSA HCPに関する製品ドキュメント docs.redhat.com Self-Managed OpenShiftのインストール方式 rheb.hatenablog.com Self-Managed OpenShiftでサポートされるノード構成 rheb.hatenablog.com

こんにちは。OpenShift SSAの瀬戸です。 小島さんが次のような記事を書いてくれていました。 rheb.hatenablog.com 実は、これに伴い、AWS Marketplaceにおいて JBoss EAPも従量課金で購入できるようになっています。 そちらの中身を覗いていきたいと思います。 MarketplaceでRed HatからJBoss EAPを購入した場合のサポート体制等は先の記事での3P PAYG RHEL(AWSから見てRed Hatというサードパーティーベンダーが直接サポートする場合)に準じます。 OSから上のサポートは全部Red Hatというだけでもお客様が選ばれる理由になりえるのかなと思います。 先の記事で説明されていることについてはこの記事では説明をしないので、必要に応じてそちらの記事を参照してください。 また、AWS EC2での基本的な操作方法(ログインユーザーは何か、ログインに必要な認証情報は何か等)についても説明はしません。 製品ドキュメントとしては次のページとなります。 docs.redhat.com 購入ページはこちら。 aws.amazon.com 選択できるエディション 現時点ではマイナーバージョンごとかつ、サポートされるOpenJDKそれぞれでAMIが作成されています。 RHELのバージョンについてはJBoss EAP 8.0はRHEL 9.4で、JBoss EAP 7.4はRHEL 8.10固定のようです。 選択できるエディション 購入後にはRed Hat側のアカウントにサブスクリプションが紐づけられていることを確認してください。 Red Hat Hybrid Cloud ConsoleからSubscriptions Inventoryを選ぶことで確認することができます。 Red Hat Hybrid Cloud Console console.redhat.com サブスクリプションが表示できない場合はAWSアカウントとRed Hatアカウントの紐づけを行う必要があります。 小島さんの記事を参照して紐づけてください。 紐づいていない場合はRed Hatへの問い合わせを行うことができませんのでご注意ください。 ※今後、この記事では2025年4月28日にリリースされた8.0.7 with OpenJDK 21 on RHEL 9.4をベースに検証しています。 2025年5月19日追記: 年間契約のサブスクリプションですでに構築済みのインスタンスを従量課金に変更できるか？と問い合わせがありましたが、現時点では変更できません。従量課金専用のAMIをベースに構築する必要があります。 インスタンスの中身 インスタンスにJBoss EAPがどうやってインストールされているかについてはドキュメント上明記されていなさそうなのですが、rpmを使ってインストールした場合に準じているようです。 ですので、インストールパスは次の通りになります。 /opt/rh/eap8/root/usr/share/wildfly/ ファイル一覧を表示すると実際にインストールされたEAPが存在します。 $ ls -la /opt/rh/eap8/root/usr/share/wildfly/ total 48 drwxr-xr-x. 10 root root 4096 Apr 3 18:39 . drwxr-xr-x. 38 root root 4096 Apr 3 18:39 .. drwxr-xr-x. 2 root root 27 Apr 3 18:39 appclient drwxr-xr-x. 3 root root 4096 Apr 3 18:39 bin drwxr-xr-x. 2 root root 52 Apr 3 18:39 docs drwxr-xr-x. 2 root root 76 Apr 3 18:39 domain -rw-r--r--. 1 root root 419 Apr 1 17:30 JBossEULA.txt lrwxrwxrwx. 1 root root 50 Apr 2 05:06 jboss-modules.jar -> /opt/rh/eap8/root/usr/share/java/jboss-modules.jar -rw-r--r--. 1 root root 26530 Apr 1 17:30 LICENSE.txt drwxr-xr-x. 3 root root 20 Apr 1 17:30 modules drwxr-xr-x. 2 root root 91 Apr 3 18:39 standalone -rw-r--r--. 1 root root 71 Apr 1 17:30 version.txt drwxr-xr-x. 4 root root 158 Apr 3 18:39 welcome-content drwxr-xr-x. 3 root root 28 Apr 3 18:39 .well-known [ec2-user@ip-172-31-38-127 wildfly]$ JBoss EAPを起動してみる OSを起動してもJBoss EAPは起動されていません。 standaloneモードとdomainモードの両方がサポートされており、それぞれsystemctl を使って起動時に選択できるようになっています。 *1 standaloneモード以外は追加の設定が必要になります。 詳細についてはドキュメントを参照してください。 この記事ではstandaloneモードで起動してみます。 sudo systemctl start eap8-standalone 画面には何も表示されませんが、JBoss EAPは起動しています。 JBoss EAPはデフォルトで8080をリッスンしているので、ブラウザからアクセスすると画面が表示されます。 ブラウザでアクセスすると表示できる 外部からアクセスできない場合はcurlを使って動作確認することも可能です。 $ curl http://localhost:8080 <!DOCTYPE html> <html> ～～～以下省略～～～ JBoss EAPをストップさせます。 sudo systemctl start eap8-standalone アプリケーションのデプロイ さて、アプリケーションをデプロイしてみましょう。 次の index.jsp が含まれた example.war を準備しました。 <%@ page pageEncoding= "UTF-8" %> < html > < body > < h2 > こんにちは！ </ h2 > </ body > </ html > sftp等でファイルをアップロードした後に適切なアクセス権を付け、ファイルをデプロイします。 sudo chown root:jboss example.war sudo mv example.war /opt/rh/eap8/root/usr/share/wildfly/standalone/deployments/ 起動したらブラウザからアクセスできるはずです。 sudo systemctl start eap8-standalone デプロイしたファイルへのブラウザからのアクセス curlだと次のようになります。 $ curl http://localhost:8080/example/ <html> <body> <h2>こんにちは！</h2> </body> </html> 2025年5月19日追記: systemd(systemctl)を使用したJBoss EAPの自動起動のさせ方はRHELのマニュアルを参照ください。 docs.redhat.com おわりに 簡単に AWS Marketplaceから利用できる従量課金のJBoss EAPを試してみました。 ちょっとだけ使いたいけどサブスクリプションが足りないといったときなどに便利なのではないでしょうか。 また、今回は従量課金のものについて説明しましたが、もちろんサブスクリプション持ち込みなども引き続き利用可能です。 また、JBoss EAPが含まれたRed Hat Runtimesなどの年間契約サブスクリプションも、プライベートオファーとして発行できます。詳細はRed Hatまでご相談ください。 2025/07/14 追記: JBoss EAPが動作するためRHELもAMIに含まれていますが、RHEL自体のエンタイトルメントは含まれていません。ですので、サポートされるのはJBoss EAPに関する操作のみとなります。 *1 : 当初、HA構成もサポートされていると書きましたが、AWSの制約により現在はHA構成はサポート外となっております。ドキュメントバグという事でご了承ください。 https://access.redhat.com/solutions/6981219 https://issues.redhat.com/browse/EAP7-1387

サポートの古市です。 Integration開発に Red Hat Build of Apache Camel をご利用の皆さん、GUI開発ツールの Kaoto 2.5 がリリース されたのをご存知でしょうか？ Kaoto 2.5 色々と書きたい気持ちをグッと抑え、ぜひ注目していただきたい新機能のみ今回ご紹介します。そう、 ドキュメント生成機能 です！ 機能実装に至るまでの背景は、Red Hat Fuse 7.x 時代に遡ります。 GUI開発を望むユーザーに使われた visual editor ですが、 日本のエンタープライズユーザー様の間では、異なる評価がされていました。 プロジェクトを進める上で必要となる仕様書や設計書など、沢山の書類をメンテナンスする必要がある状況で、 Camel visual editor が生成する camel route の画像が、ドキュメント資料に有用であるとご判断されていたのです。 camel route の画像(kaoto版) camel routeを編集する度、簡単に camel route の画像もアップデートできる為、メンテナンス効率の良さを評価していただきました。 Eclipse用 camel visual editor plugin の商用サポートが終了すると告知された際、代替えツールの提供をと、日本ユーザー様から特にご要望を頂戴しました。 具体的に要望内容をヒアリングする事で、仕様書/設計書にご利用いただいている事を知り、kaoto開発チームが日本ユーザーのフィードバックを元に新規実装した機能が、今回のドキュメント生成機能です。 今までの Camel visual editor とは異なり、画像ファイルを出力するだけでなく、お客様が実装された camel route の各種パラメーターを Ascii Doc形式でドキュメント出力します。 AsciiDoc形式でドキュメントを自動生成 AsciiDocなので加筆修正もしやすく、仕様書や設計書にご利用される皆様には、より使い勝手の良いツールになったかと思います。 使い方は簡単で、画面上部の camel のライブラリーバージョンを選択するプルダウンメニューの左隣りにあるアイコンをクリックするだけです。 アイコンをクリックするだけでドキュメント生成 インテグレーションに特化した製品がもたらす恩恵は、 開発/メンテナンス だけでなく、ドキュメント管理 も含まれます。 ぜひ皆様にご利用いただき、引き続き沢山のフィードバックをいただければと思います。

Red Hatの小島です。 日本のお客様がRHELをAWSで利用する場合、従来は以下のいずれかとなっていました。 年間契約制のRHELサブスクリプションをAWSに持ち込んで、Red HatのRHELサポートを受ける AWS Management Console(以下、AWS Consoleと記載)から購入する従量課金制のRHELについて、AWSのRHELサポートを受ける しかし、2025年4月1日からの AWS Marketplaceでの取引における日本の消費税の取り扱い変更 や、2025年5月1日からの AWS MarketplaceにおけるSaaS出品のガイドライン変更 に伴い、以下をAWS Marketplaceから購入して利用できるようになりました。 Red Hatがサポートする従量課金制のRHELサブスクリプション AWSだけでなく、オンプレミス(以下、オンプレと記載)や他のクラウドでも利用できる年間契約制のRHELサブスクリプション 本記事ではAWS Console/Marketplaceから購入できるRHELサブスクリプションや、それらに紐づいているRHEL AMIの種類について、2025年5月時点の情報をご紹介します。 AWS Consoleで購入できるRHELサブスクリプション (1P (1st Party) PAYG RHEL) 利用料金 利用方法 AWS Marketplaceで購入できるRHELサブスクリプション (3P (3rd Party) RHEL) 利用料金 3P PAYG RHEL Red Hat SubscriptionsカタログのRHEL 利用方法 事前準備 3P PAYG RHEL Red Hat SubscriptionsカタログのRHEL RHELのゴールドイメージ (AWSへのRHELサブスクリプション持ち込み(BYOS)用に提供) AWS Console/Marketplaceで購入したRHELサブスクリプションへの移行 オンプレのRHELを利用している場合 Red Hat SubscriptionsカタログのRHELへの移行 1P PAYG RHELへの移行 3P PAYG RHELへの移行 AWSでRHELのゴールドイメージを利用している場合 Red Hat SubscriptionsカタログのRHELへの移行 1P PAYG RHELへの移行 3P PAYG RHELへの移行 まとめ Appendix Red Hatナレッジベースへのアクセスガイド 1P/3P PAYG RHELをRed Hat Satelliteで管理 RHUIを利用したRHELのインプレースアップグレード RHELだけでなく他のサービスも利用可能になっているので、ぜひこちらもご確認ください。 rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com AWS Consoleで購入できるRHELサブスクリプション (1P (1st Party) PAYG RHEL) AWSがサポートするRHELサブスクリプションです。AWS上で利用できる従量課金制(PAYG)のRHELということで、今まで利用してきたお客様も多いと思います。これはAWS Consoleから購入して利用しますが、AWS Marketplaceにもそのリストが掲載されており、 提供元またはパブリッシャーが「Amazon Web Services」 「Red Hat Enterprise Linux」または「RHEL」という名前が付いている ものとなります。 主なものとしてx86_64ベースのRHEL8/RHEL9とAWS ArmベースのRHEL8/RHEL9がありますが、他にRHEL for SAP with HA and US(x86_64版)などがあります。 https://aws.amazon.com/marketplace/seller-profile?id=e6a5002c-6dd0-4d1e-8196-0a1d1857229b aws.amazon.com これらのRHELはAWSにとってのファーストパーティ製品でもあるので、便宜上1P (1st Party) PAYG RHELと呼ぶことにします。 1P PAYG RHELは、追加料金無しで以下を使うこともできます。詳細はリンク先のWebページをご参照ください。 Red Hat Update Infrastructure (RHUI)を利用したRHELパッケージのダウンロード/インストール/アップデート RHEL EUSサブスクリプション ( rhui-eus-switch コマンドで設定可能) RHEL for SAP with HA and US(x86_64版) では、デフォルトでRHUIのRHEL E4Sリポジトリが有効化済み Red Hat Satelliteサブスクリプション RHUIはクラウド環境専用のRHELリポジトリであり、1P PAYG RHELではデフォルトで利用できます。 rhui-eus-switch コマンドは、 RHUIのEUSリポジトリをサブスクライブ/アンサブスクライブする ためのコマンドです。このコマンドは1P PAYG RHEL専用コマンドとなっており、後述する3P PAYG RHELやRHELゴールドイメージでは利用できません。 利用料金 1P PAYG RHELの利用料金は、1P PAYGのRHEL for SAP with HA and USとRHEL Workstation for GPU-based Instancesの場合を除き、EC2インスタンスの利用料金に含まれています。 オンデマンドインスタンスの料金表 や リザーブドインスタンスの料金表 を参照して、利用料金を見積もることができます。この時、オペレーティングシステムに「RHEL」や「Red Hat Enterprise Linux HA」などのRHEL関連のものを選択します。 利用方法 1P PAYG RHELはAWS ConsoleまたはAWS CLIから利用できるようになっており、 Red Hatアカウントは不要 です。AWS Consoleから利用する場合、Amazon EC2のインスタンス起動画面から「その他のAMIを閲覧する」→「AWS Marketplace AMI」の、 パブリッシャー: Amazon Web Services オペレーティングシステム: Red Hat Enterprise Linux というフィルターをかけて検索したAMIを選択して起動します。 上記の1P PAYG RHEL AMIリストについては aws ec2 describe-images コマンドでも確認できます。1P PAYG RHEL AMIの名前には、従量課金制であることを意味する Hourly2 が含まれています。以下は東京リージョンで利用できるRHEL9系のAMIリストを出力するコマンドです。ここで確認した1P PAYG RHELのAMI IDを指定して、AWS CLIでEC2インスタンスを起動することもできます。 aws ec2 describe-images --owners 309956199498 \ --query ' sort_by(Images, &Name)[*].[CreationDate,Name,ImageId] ' \ --region ap-northeast-1 --output table \ --filters " Name=name,Values=RHEL-9.*Hourly2* " ------------------------------------------------------------------------------------------------------------- | DescribeImages | +---------------------------+------------------------------------------------------+------------------------+ | 2023-06-06T07:43:29.000Z | RHEL-9. 0 .0_HVM-20230531-arm64-4-Hourly2-GP2 | ami-061b486e98f014dff | | 2023-06-06T07:45:51.000Z | RHEL-9. 0 .0_HVM-20230531-x86_64-4-Hourly2-GP2 | ami-01dca0aeb230ee8eb | | 2023-07-18T21:41:18.000Z | RHEL-9. 0 .0_HVM-20230712-arm64-7-Hourly2-GP2 | ami-0898cc4c891fd4ef4 | | 2023-07-18T21:42:38.000Z | RHEL-9. 0 .0_HVM-20230712-x86_64-7-Hourly2-GP2 | ami-098ef4802afd467e6 | ... < 略 > ... | 2025-03-13T20:54:51.000Z | RHEL-9. 5 .0_HVM-20250313-arm64-0-Hourly2-GP3 | ami-0404ad07a445b496e | | 2025-03-13T17:53:37.000Z | RHEL-9. 5 .0_HVM-20250313-x86_64-0-Hourly2-GP3 | ami-07f63d80296cfee44 | | 2024-11-12T15:47:22.000Z | RHEL-9. 5 .0_HVM_GA-20241029-arm64-0-Hourly2-GP3 | ami-01ab05bcff4c0f10d | | 2024-11-12T17:40:42.000Z | RHEL-9. 5 .0_HVM_GA-20241029-x86_64-0-Hourly2-GP3 | ami-0d688e6ee8638ea73 | +---------------------------+------------------------------------------------------+------------------------+ access.redhat.com 最新版より少し古いバージョンの1P PAYG RHEL AMIをAWS Consoleから利用したい場合、ここで確認したAMIの名前またはAMI IDで「コミュニティAMI」から検索して選択します。 AMI IDが同じAMIの場合、「AWS Marketplace AMI」と「コミュニティAMI」で販売されているAMIは同じ です。 AWS Marketplaceで購入できるRHELサブスクリプション (3P (3rd Party) RHEL) Red HatがサポートするRHELサブスクリプションです。従量課金制と年間契約制で利用できるRHELサブスクリプションがあります。これらは、Red HatがAWS Marketplaceで販売しているものとなります。 Red HatがAWS Marketplaceで販売している製品は、提供元またはパブリッシャーが「Red Hat」のものとなります。「Red Hat Limited」提供の製品はEMEA地域専用のものなので、基本的に日本のお客様は使えません。 https://aws.amazon.com/marketplace/seller-profile?id=8bb46e3b-6208-4ac2-bdbd-339bb37b0e64 aws.amazon.com これらの製品のうち、RHELに関連するものは以下です。6番以外は全て従量課金制のRHELです。 Red Hat Enterprise Linux (RHEL) for AWS (x86_64版) Red Hat Enterprise Linux for Arm (AWS Arm版) Red Hat Enterprise Linux for SAP with HA and Update Services (x86_64版) Red Hat Enterprise Linux 7 Extended Life Cycle Support (ELS) (x86_64版) Red Hat Enterprise Linux for Third Party Linux Migration with ELS (x86_64版) Red Hat Subscriptions (年間契約制のRHEL(x86_64版)を含んだRed Hat製品) 上記の従量課金制RHELはAWSにとってのサードパーティ製品でもあるので、1番と2番のRHELを便宜上3P (3rd Party) PAYG RHELと呼ぶことにします。 3P PAYG RHELは、追加料金無しで以下を使うこともできます。詳細はリンク先のWebページをご参照ください。 Red Hatサポートチームが提供する プレミアムサポート Red Hat Update Infrastructure (RHUI)を利用したRHELパッケージのダウンロード/インストール/アップデート RHEL EUSサブスクリプション (Arm版のRHEL EUSも提供. rhui-eus-switch コマンドによる設定不可) Red Hat Satelliteサブスクリプション RHUIはクラウド環境専用のRHELリポジトリであり、3P PAYG RHELではデフォルトで利用できます。 利用料金 3P PAYG RHEL 3P PAYG RHELの利用料金は、EC2インスタンスの利用料金とは別にAWSから請求されます。つまり、 ソフトウェア(RHEL)の利用料金 (AWSリージョンごとの違いは無し) EC2インスタンス(OSタイプはLinux)を含むAWSインフラの利用料金 の合計金額がAWSから請求されることになります。料金情報は、EC2インスタンス起動画面などから確認できます。 3P PAYG RHEL(x86_64版)には、Red Hat Satellite付きのRHEL Premium(x86_64版. 定価: US$1813.90)サブスクリプションが含まれています。定価の情報は、 Red Hat StoreのWebページ から参照できます。このサブスクリプションをAWSに持ち込んで利用する場合、 EC2インスタンスのサイズに関係なく、RHELインスタンス2台ごとにRed Hat Satellite付きのRHEL Premiumサブスクリプションが1本必要 (例: インスタンス1台なら1本、インスタンス3台なら2本)となります。 そのため、以下の 3P PAYG RHEL(x86_64版)カタログ のソフトウェア(RHEL)の年間料金情報(vCPU数が多くなるほど、RHELの料金が高くなります)を参照すると、c7i.2xlarge (8vCPU, RAM16GiB)より小さいサイズのRHELインスタンスを起動する場合、3P PAYG RHEL(x86_64版)の方がサブスクリプション持ち込み(BYOS)よりお得になる傾向があると分かります。 Red Hat SubscriptionsカタログのRHEL Red Hat Subscriptionsカタログでは、年間契約制のRHEL/OpenShift/Ansibleなどのサブスクリプションを販売しています。その中で、RHELに関するサブスクリプションは以下の3つとなります。以下の画像では 「RHEL_ELS」サブスクリプションもありますが、これはEdgeユースケース用の特別なサブスクリプションですので、基本的には購入しないでください。 RHEL Standard (x86_64版. SKU: RH00004) RHEL Premium (x86_64版. SKU: RH00003) RHEL for SAP Solutions Premium (x86_64版. SKU: RH00763) これらのSKUは、Red Hatがこれまでお客様に販売してきたRHELサブスクリプション(x86_64版)のSKUと同じであり、 オンプレや他のクラウドでも利用できる年間契約制のRHELサブスクリプション となります。定価も同じです。これらをAWS上で利用する場合、 RHELサブスクリプションの年間料金 (前払い形式で、購入月の月末にAWSから請求) EC2インスタンス(OSタイプはLinux)を含むAWSインフラの利用料金 の合計金額がAWSから請求されます。 オンプレや他のクラウドでも利用できる年間契約制のRHEL EUS、RHEL ELS(x86_64版)、Red Hat Satelliteサブスクリプションなどは、 AWS Marketplaceのプライベートオファー で購入することができます。ご希望の場合は「 購買専用のお問い合わせ 」のWebページから、プライベートオファーでのサブスクリプション購入希望をお問い合わせください。その際に、プライベートオファー発行に必要な情報をご案内します。 なお、AWS Marketplaceのプライベートオファーを使用して購入するソフトウェア製品に違いはありません。プライベートオファーを使用して購入したソフトウェアは、プライベートオファーを使用せずにソフトウェアを購入した場合と同じように動作します。 プライベートオファーの発行には制限があります。 全てのRed Hatサブスクリプションをプライベートオファーで購入できるわけではありません。 詳細はRed Hatまでご相談ください。 利用方法 事前準備 AWS Marketplaceのカタログから購入手続きを実施します。この時、購入したRHELサブスクリプションを付与するための Red Hatアカウントが必要 です。Red Hatアカウントを持っていない場合、下記を参考にしてRed Hatアカウントを作成して下さい。 access.redhat.com 「Red Hatアカウントの管理について不明点があるから確認したい」「AWSアカウントとRed Hatアカウントの連携状況を確認したい、または連携を解除したい」などのリクエストがある場合は、Red Hatのカスタマーサービスまでお問い合わせ下さい。 www.redhat.com AWSアカウントとRed Hatアカウントの連携設定をしていない場合、以下の「Red Hat Subscription Support Registration」カタログからAWSアカウントとRed Hatアカウントとの連携設定を実施する必要があります。このカタログ自体は無料であり、Red HatアカウントへのRed Hatサブスクリプション割り当てやRed Hatサポートケース作成のための、アカウント連携を目的として提供しています。 このアカウント連携は、Red Hatの3P PAYG製品を利用する時に必要となります。 https://aws.amazon.com/marketplace/pp/prodview-fyphbrmils4dg aws.amazon.com 無料の「Red Hat Subscription Support Registration」カタログ購入からの、AWSアカウントとRed Hatアカウントの連携設定手順については、「 AWS MarketplaceのカタログからRHEL7 ELSを購入 」で紹介しているものと同様の手順で実行できますので、参考にしてください。Red HatのWebページで「Connect accounts」ボタンをクリックして、次のような「Congratulations」メッセージが表示されるとアカウント連携は完了です。他にRed Hatサブスクリプションを購入していない場合、この時点では、Red Hatアカウントには何もRed Hatサブスクリプションが割り当てられていない状態となります。 3P PAYG RHEL AWS Marketplaceの3P PAYG RHEL(x86_64版)の利用方法をご紹介します。3P PAYG RHEL(AWS Arm版)の場合も同様です。 以下のWebページから3P PAYG RHEL(x86_64版)の購入手続きを実施します。 https://aws.amazon.com/marketplace/pp/prodview-aezl6to7jjkao aws.amazon.com 画面右上にある「View purchase options」をクリックします。 その次に表示されるEULAなどの契約を読んで「Accept Terms」をクリックします。 1分ほど待つと、以下のような画面が表示されます。これで3P PAYG RHEL(x86_64版)の購入手続きは完了です。以下の画面から年間課金制の契約を作る(「Contract options」でインスタンスタイプと数量を選択→「Add」または「Update」→「Create Contract」)こともできますが、時間課金制で3P PAYG RHELを利用したい場合、画面右上にある「Continue to Configuration」をクリックします。 ここで作成した年間課金制の契約の料金は、作成した時点で課金が発生します。例えば、以下の画像のようにUS$470の年間課金の契約を2025年5月に作成すると、2025年5月末にAWSからUS$470が請求されます。 3P PAYG RHELのサブスクリプション この時、Red Hatアカウントに自動的に「Red Hat Enterprise Linux, Premium (On-Demand, Production Support). SKU: RH02612」サブスクリプションが付与されていることを、以下のWebページから確認できます。これが3P PAYG RHEL専用のRHELサブスクリプションです。AWS Marketplaceから購入したRed Hatサブスクリプションは「Contract Number」が「Not Available」となっていますが、Red Hatからのサポートを問題なく受けることができます。 https://console.redhat.com/subscriptions/inventory 3P PAYG RHEL for Armのカタログからサブスクリプション購入手続きを完了すると、「Red Hat Enterprise Linux Server with Satellite, Premium (vCPU, Hourly, On-Demand, Billing). SKU: RH02657HR」サブスクリプションが付与されます。3P PAYG RHEL for Armを利用したい場合、RH02612とRH02657HRの両方のサブスクリプション購入手続きを実施してください。なお、これらの3P PAYG RHELサブスクリプションがRed Hatアカウントに付与されていないと、Red Hatのサポートを受けられませんので注意してください。 これらの3P PAYG RHELサブスクリプションは、有効期限が切れたら自動更新される設定になっています。年間課金制の契約がある場合、一番最後に作成した契約の開始日と終了日に更新されます。サブスクリプションが不要になった場合は、3P PAYG RHELのEC2インスタンスを全て削除したあとに、以下のWebページに従ってAWS Marketplaceのサブスクリプション管理画面からAMIサブスクリプションをキャンセルすることで、Red Hat Subscriptions InventoryのWebページからも自動削除されます。 https://docs.aws.amazon.com/ja_jp/marketplace/latest/buyerguide/cancel-subscription.html#cancel-ami-subscription 起動する3P PAYG RHEL(x86_64版)のバージョンとリージョンを選択して、画面右上の「Continue to Launch」をクリックします。 起動する3P PAYG RHELに含まれていないバージョン(RHEL9.2など)を利用したい場合、この画面から3P PAYG RHELを起動することはできません。一旦、後述のゴールドイメージのRHELまたは1P PAYGのRHELを起動した後に、後述の移行手順に沿って、3P PAYG RHELに移行する必要があります。 このWebページまたはEC2コンソールの画面を選択してインスタンスを起動できるようになっています。「Launch through EC2」を選択して画面右下の「Launch」をクリックすると、3P PAYG RHEL AMIが選択された状態のEC2インスタンスの起動画面に遷移するので、そこからEC2インスタンスを起動できます。 3P PAYG RHELでRHEL EUSを利用したい場合、 rhui-eus-switch コマンドによるRHEL EUSリポジトリの利用設定ができないので、 subscription-manager コマンドを使ってRHEL EUSリポジトリの利用設定をする必要があります。以下は、RHEL9.4 EUSリポジトリを有効化するコマンド例です。AWS Arm版の場合、以下のコマンドの x86_64 を aarch64 に変更してください。 sudo subscription-manager register sudo subscription-manager config --rhsm.manage_repos = 1 sudo subscription-manager repos --enable rhel-9-for-x86_64-baseos-eus-rpms --enable rhel-9-for-x86_64-appstream-eus-rpms sudo subscription-manager repos --disable rhel-9-for-x86_64-baseos-rpms --disable rhel-9-for-x86_64-appstream-rpms sudo subscription-manager release --set = 9 . 4 ファイアーウォールやプロキシ経由で subscription-manager コマンドによるRHELシステム登録などを実行する場合、下記のWebページを参考にしてください。 access.redhat.com Red Hat CDNにあるRHEL EUSリポジトリだけを利用させたい場合、3P PAYG RHELがRHUIを利用するための設定を削除しておきます。この設定は yum remove コマンドで削除できます。RHUIを利用する設定に戻すときのことも考えて、これらのパッケージを予め yum download コマンドでダウンロードしておいてもいいでしょう。以下はそのコマンド例です。 sudo yum download rh-amazon-rhui-client sudo yum remove rh-amazon-rhui-client Red Hat SubscriptionsカタログのRHEL 以下のWebページから購入手続きを実施します。 https://aws.amazon.com/marketplace/pp/prodview-4hz3uo55uaemk aws.amazon.com 画面右上にある「View purchase options」をクリックします。 購入するRed Hatサブスクリプション(以下の画像の例だと、「RHEL Standard」)を選択して、数量を入力します。この時、サブスクリプションの自動更新を無効化したい場合は、「Auto-renewal」の箇所で「Do not automatically renew this contract」を選択します。そして、画面下部にある「Subscribe」ボタンをクリックすると、購入手続きが完了します。ここで購入したサブスクリプションの料金は前払いとなり、購入月の月末にAWSから請求されます。 初めてRed Hat Subscriptionsカタログから製品購入手続きをする場合、表示される「Set up your account」ボタンからAWSアカウントとRed Hatアカウントの連携設定をする必要があります。AWSアカウントとRed Hatアカウントの連携設定手順については、「 AWS MarketplaceのカタログからRHEL7 ELSを購入 」で紹介しているものと同様の手順で実行できますので、参考にしてください。 Red Hat SubscriptionsカタログのRed Hatサブスクリプション この時、Red Hatアカウントに自動的に「Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes). SKU: RH00004」サブスクリプションが付与されていることを、以下のWebページから確認できます。これはRed Hatがこれまでお客様に販売してきたRHELサブスクリプション(x86_64版)と同じであり、AWSだけでなく、オンプレや他のクラウドでのRHELに利用できます。AWS Marketplaceから購入したRed Hatサブスクリプションは「Contract Number」が「Not Available」となっていますが、Red Hatからのサポートを問題なく受けることができます。 https://console.redhat.com/subscriptions/inventory 購入したRed Hatサブスクリプションの自動更新の設定変更や、Red Hatサブスクリプションを追加購入したい場合、Red Hat Subscriptionsカタログの「View purchase options」ボタンを再クリックして、以下の画面の「modify」をクリックします。 購入したRed HatサブスクリプションがRed Hatアカウントに割り当てられていない場合は、以下の画面の「vendor's website」をクリックして、AWSアカウントとRed Hatアカウントの連携設定をしてください。アカウント連携が完了してもRed Hatアカウントにサブスクリプションが割り当てられない場合は、 Red Hatのカスタマーサービス までお問い合わせ下さい。 次に表示される画面から、自動更新の有効化(以下の例だと、2026年4月24日に自動更新)や購入するRed Hatサブスクリプションの追加選択(以下の例だと、「RHEL Premium」を1本追加)して画面下部の「Save changes」をクリックすると、自動更新の設定変更やRed Hatサブスクリプションの追加購入が完了して、Red HatアカウントにRHEL Premiumサブスクリプションが自動付与されます。 上記の契約金額 $2,519.57 は、「RHEL Standard + RHEL Premium + RHEL_ELS」の合計金額とは若干異なっています。これは何故かというと、Red Hat Subscriptionsカタログで購入した全てのRed Hatサブスクリプションは、一番最初に購入したRed Hatサブスクリプションの契約終了日に自動統一されるためです。 上記の場合は、「RHEL Standard」と「RHEL ELS」を2025年4月24日に、「RHEL Premium」を2025年5月3日に購入したため、以下のような日割り計算が適用されます。そのため、 複数のRed Hatサブスクリプションの契約終了日を揃えたい 場合にも、「Red Hat Subscriptions」カタログをご利用いただけます。 RHEL Standard: 365日分の料金 (2025/04/24 ~ 2026/04/24) RHEL_ELS: 365日分の料金 (2025/04/24 ~ 2026/04/24) RHEL Premium: 356日分の料金 ($1428.9 x 356/365 = $1393.67) (2025/05/03 ~ 2026/04/24) RHELのゴールドイメージ (AWSへのRHELサブスクリプション持ち込み(BYOS)用に提供) 無料で使えるRed Hat Developer Subscription 、購入済みで未使用のRHELサブスクリプション、または、AWS MarketplaceのRed Hat Subscriptionsカタログから購入したRHELサブスクリプションをAWS上で利用する場合、Red Hatが提供する専用のRHEL AMI(RHELのゴールドイメージ)を、AWS ConsoleまたはAWS CLIから利用できます。 AWS Consoleから利用する場合、Amazon EC2のインスタンス起動画面から「その他のAMIを閲覧する」→「自分のAMI」の「自己所有」フィルターのチェックを外して表示されたRHEL AMIの一覧から選択して起動できます。 RHELのゴールドイメージは、デフォルトでRHUIを利用したRHELパッケージのダウンロード/インストール/アップデートが可能です。ゴールドイメージでは rhui-eus-switch コマンドでのRHEL EUSリポジトリ有効化ができないので、RHEL EUSリポジトリを使いたい場合、RHEL EUSまたはRHEL Premiumサブスクリプションが付与されたRed Hatアカウントを使って、3P PAYG RHELの紹介箇所で記載した subscription-manager コマンドによるRHEL EUSリポジトリの有効化をする必要があります。 RHELのゴールドイメージのAMIリストが表示されない場合、 RHELサブスクリプションが付与されたRed HatアカウントとAWSアカウントとの連携設定(Cloud Access手続き) をして下さい。Cloud Access手続きを実施した後に、AWSにRHELのゴールドイメージのAMIリストが表示されるようになるまで、 およそ3時間から1営業日ほど かかります。 上記のRHELのゴールドイメージのAMIリストについては aws ec2 describe-images コマンドでも確認できます。RHELゴールドイメージのAMIの名前には、Cloud Accessで持ち込んだRHELサブスクリプション用であることを意味する Access2 が含まれています。以下は東京リージョンで利用できるRHEL9系のAMIリストを出力するコマンドです。ここで確認したRHELのゴールドイメージのAMI IDを指定して、AWS CLIでEC2インスタンスを起動することもできます。 aws ec2 describe-images --owners 309956199498 \ --query ' sort_by(Images, &Name)[*].[CreationDate,Name,ImageId] ' \ --region ap-northeast-1 --output table \ --filters " Name=name,Values=RHEL-9.*Access2* " ------------------------------------------------------------------------------------------------------------- | DescribeImages | +---------------------------+------------------------------------------------------+------------------------+ | 2022-05-13T11:44:26.000Z | RHEL-9. 0 .0_HVM-20220513-arm64-0-Access2-GP2 | ami-05bca6a534e0e8753 | | 2022-05-13T11:30:11.000Z | RHEL-9. 0 .0_HVM-20220513-x86_64-0-Access2-GP2 | ami-096dfa01124362cab | | 2022-11-01T23:42:11.000Z | RHEL-9. 0 .0_HVM-20221027-arm64-1-Access2-GP2 | ami-0b06c5aa9f9aff50c | | 2022-11-02T00:06:11.000Z | RHEL-9. 0 .0_HVM-20221027-x86_64-1-Access2-GP2 | ami-02be111aec82d479e | ... < 略 > ... | 2025-03-13T20:55:54.000Z | RHEL-9. 5 .0_HVM-20250313-arm64-0-Access2-GP3 | ami-013086f675051b916 | | 2025-03-13T17:53:33.000Z | RHEL-9. 5 .0_HVM-20250313-x86_64-0-Access2-GP3 | ami-0fb629222373b9861 | | 2024-11-12T15:47:48.000Z | RHEL-9. 5 .0_HVM_GA-20241029-arm64-0-Access2-GP3 | ami-0c8de9ae88f12058b | | 2024-11-12T17:41:13.000Z | RHEL-9. 5 .0_HVM_GA-20241029-x86_64-0-Access2-GP3 | ami-067473039657edce6 | +---------------------------+------------------------------------------------------+------------------------+ 1P/3P PAYG RHEL AMIとRHELのゴールドイメージのAMIは全てRed Hatが作成したものであり、RHELのバージョン番号/アーキテクチャ/リリース日などが同じであれば、中身は全く同じになります。これは /etc/fstab ファイルで指定しているデバイスのUUIDや、 rpm -qa コマンドで確認できるインストール済みのパッケージ一覧などが同じであることから確認できます。例えば、以下の2025年3月13日にリリースされた1P/3P PAYG RHEL AMIとRHELのゴールドイメージのAMIは、中身が全て同じものとなります。 RHEL-9.5.0_HVM-20250313-x86_64-0-Hourly2-GP3 (1P PAYG) RHEL-9.5_HVM-20250313-x86_64-0-6b2625ac-e9ca-4d9a-a34f-63dc75a4d497 (3P PAYG) RHEL-9.5.0_HVM-20250313-x86_64-0-Access2-GP3 (ゴールドイメージ) RHELのゴールドイメージを利用する場合、 RHELサブスクリプションの利用料金 (購入先から請求. Red Hat Developer Subscriptionを利用している場合は無料) EC2インスタンス(OSタイプはLinux)を含むAWSインフラの利用料金 (AWSから請求) の合計金額が請求されます。 AWS Console/Marketplaceで購入したRHELサブスクリプションへの移行 Red Hatから購入したRHELサブスクリプションを、オンプレまたはAWSでのゴールドイメージ用に利用している場合を想定して、AWS Console/Marketplaceで購入したRHELサブスクリプションを利用するように移行する方法をまとめておきます。 1P/3P PAYG RHELへ移行する場合、追加料金なしでRHEL EUSとRed Hat Satelliteサブスクリプションを利用できるようになるため、RHEL EUSとRed Hat Satelliteサブスクリプションの購入が不要になります。 オンプレのRHELを利用している場合 Red Hat SubscriptionsカタログのRHELへの移行 年間契約制のRHEL StandardやRHEL Premiumサブスクリプションの購入先を変更するだけなので、現在ご利用中のRHELシステムを特に変更する必要はありません。今ご利用されているRHELのサブスクリプションと同じ本数分を、Red Hat Subscriptionsカタログからご購入いただきます。 なお、前述したとおり、年間契約制のRHEL EUSやRHEL ELS(x86_64版)などの一部のRed Hatサブスクリプションなどについては、AWS Marketplaceのプライベートオファーで発行できますので、一度Red Hatまでご相談ください。 1P PAYG RHELへの移行 AWSがサポートする1P PAYG RHELに移行する場合、AWS Application Migration Service (AWS MGN) を利用したシステム移行が可能です。以下にAWSのドキュメントとしてまとまっていますので、ご参考にしてください。AWS MGNを利用したシステム移行について不明点などあれば、AWSまでお問い合わせください。 docs.aws.amazon.com 3P PAYG RHELへの移行 新規作成した3P PAYG RHELのEC2インスタンスに、パッケージの再インストールやデータコピーをしてください。これらの移行手順を自動化したい場合、Red HatがAWS Marketplaceで販売しているManaged Ansibleサービスを別に利用することもできます。 https://aws.amazon.com/marketplace/pp/prodview-dk7owvnk45mti aws.amazon.com また、AWS License Managerのライセンスタイプ変換機能を利用することで、 停止状態のインスタンス に対して、1P PAYG RHELと3P PAYG RHELの相互変換が可能です。そのため、AWS MGNとAWS License Managerを利用することで、オンプレミスのRHEL→1P PAYG RHEL→3P PAYG RHEL、といった変換も可能になっています。パッケージの再インストールやデータコピーの手間を省略したい場合は、こうした変換機能もご利用ください。 docs.aws.amazon.com AWSでRHELのゴールドイメージを利用している場合 Red Hat SubscriptionsカタログのRHELへの移行 前述の「オンプレRHELサブスクリプションから、Red Hat SubscriptionsカタログのRHELへの移行」と全く同じです。現在ご利用中のRHELシステムを特に変更する必要はありません。 1P PAYG RHELへの移行 前述のAWS MGNを利用したシステム移行が可能です。手動の場合、以下のAWSドキュメントの 「LI インスタンスへの移行-オプション 2 (RHEL BYOL EC2 インスタンスの場合)」 を参照して、 インスタンス停止後 に移行することもできます。以下がそのイメージです。新規作成した1P PAYG RHELインスタンスに、今まで利用していたRHELのゴールドイメージのEBSを付け替えます。 RHELのゴールドイメージのAMIと1P PAYG RHEL AMIは、バージョン番号やリリース日などが同じなら中身が同じですが、インスタンスのメタデータが異なります。このメタデータは、各インスタンスから以下のコマンドを実行して表示確認できます。 RHELのゴールドイメージ curl http:// 169 . 254 . 169 . 254 /latest/dynamic/instance-identity/document ... < 略 > ... " billingProducts " : [ " bp-63a5400a " ] , " devpayProductCodes " : null, " marketplaceProductCodes " : null, " imageId " : " ami-0f946bd6a055105a0 " , " instanceId " : " i-0625c522df52c9753 " , " instanceType " : " t2.small " , ... < 略 > ... 1P PAYG RHEL curl http:// 169 . 254 . 169 . 254 /latest/dynamic/instance-identity/document ... < 略 > ... " billingProducts " : [ " bp-6fa54006 " ] , " devpayProductCodes " : null, " marketplaceProductCodes " : null, " imageId " : " ami-00d6b050f16b51e1f " , " instanceId " : " i-09be3fed6c702944f " , " instanceType " : " t2.small " , ... < 略 > ... ここで表示される billingProducts のIDが、ゴールドイメージと1P PAYG RHELのインスタンスで異なります。このメタデータの billingProducts などを元に、インスタンスの課金やRHUIのRHEL EUSリポジトリへのアクセス制御などを実施しています。ゴールドイメージのEBSを1P PAYG RHELのインスタンスに付け替えると、1P PAYG RHELインスタンスの起動時にメタデータが更新されて、 billingProducts や imageId が1P PAYG RHELインスタンスのものに変更されて、1P PAYG RHELの課金が実行されます。 この時、RHEL9.4などのEUSが使えるバージョンであれば、1P PAYG RHELインスタンス上で sudo rhui-eus-switch 9.4 コマンドを実行して、RHUIのRHEL9.4 EUSリポジトリを参照するように設定変更することもできます。 上記の curl コマンドで何も表示されない場合は、 RHELのsosreport を見ることでも billingProducts や imageId などを確認できます。RHELの sos パッケージは問題解決のためにRed Hatサポートチームが必要とすることが多いので、普段運用しているRHELシステムにインストールしておくことを 強く推奨 しています。 sudo yum -y install sos sudo sos report ... < 略 > ... Your sos report has been generated and saved in: /var/tmp/sosreport-ip-10-0-36-253-2025-05-04-mtzsefr.tar.xz Size 9 .56MiB Owner root sha256 1c1a9cc369089b364975567761804ad255d693229bb854eed8b95bbdce373946 Please send this file to your support representative. sudo tar xf /var/tmp/sosreport-ip-10-0-36-253-2025-05-04-mtzsefr.tar.xz sudo less sosreport-ip-10-0-36-253-2025-05-04-mtzsefr/run/cloud-init/instance-data.json ... < 略 > ... " billingProducts " : [ " bp-6fa54006 " ] , " devpayProductCodes " : null, " imageId " : " ami-00d6b050f16b51e1f " , " instanceId " : " i-09be3fed6c702944f " , " instanceType " : " t2.small " , ... < 略 > ... 余談ですが、1P PAYG RHELからRHELのゴールドイメージへ変換することもできます。その場合は前述の手順とは逆に、新規作成したRHELゴールドイメージのインスタンスに、今まで利用していた1P PAYG RHELインスタンスのEBSを付け替えます。これによって、ゴールドイメージのインスタンス起動時にメタデータが更新されて、 billingProducts や imageId がゴールドイメージインスタンスのものに変更されて、1P PAYG RHELのソフトウェア(RHEL)課金が止まります。 1P PAYG RHELインスタンスでRHUIのRHEL EUSリポジトリを参照していた場合、ゴールドイメージではRHUIのRHEL EUSリポジトリの参照ができなくなるので、 sudo rhui-eus-switch reset コマンドで、RHUIのRHELリポジトリを参照するようにして下さい。 3P PAYG RHELへの移行 前述のとおり、新規作成した3P PAYG RHELのEC2インスタンスに、パッケージの再インストールやデータコピーをしてください。これらの移行手順を自動化したい場合、Red HatがAWS Marketplaceで販売している Managed Ansibleサービス も別途利用できます。 なお、3P PAYG RHELについては、RHELゴールドイメージから1P PAYG RHELへの移行のように、単なるEBS付け替えでは移行できません。3P PAYG RHELインスタンスには3P PAYG RHEL専用のEBSが接続されているため、RHELゴールドイメージや1P PAYG RHELインスタンスのEBSを利用できなくなっているためです。 AWS License Managerのライセンスタイプ変換機能を利用することで、 停止状態のインスタンス に対して、1P PAYG RHELと3P PAYG RHELの相互変換が可能です。そのため、AWS License Managerを利用することで、RHELのゴールドイメージ→1P PAYG RHEL(前述のEBS付け替えによる変換)→3P PAYG RHEL、といった変換も可能になっています。パッケージの再インストールやデータコピーの手間を省略したい場合は、こうした変換機能もご利用ください。 docs.aws.amazon.com AWS License Managerを使わない場合、 インスタンス停止後 にEBSのデータをLinuxの dd コマンドで丸ごとコピーする方法があります。以下のような dd コマンドを使ったデータコピー方法があります。RHELゴールドイメージにある特定のバージョンのRHEL(RHEL9.4など)を3P PAYG RHELとして利用したい場合の、Linuxインスタンスに接続された2つのEBSデータボリューム間の、 dd コマンドによるデータコピー実行例は次のとおりです。 sudo dd if =/dev/nvme1n1 of =/dev/nvme2n1 bs =1M status= progress 11684282368 bytes ( 12 GB, 11 GiB ) copied, 88 s, 133 MB/s 11264 + 0 records in 11264 + 0 records out 11811160064 bytes ( 12 GB, 11 GiB ) copied, 100 . 835 s, 117 MB/s dd コマンドによるデータコピーの全体手順のイメージは次のとおりです。 新規作成したRHELゴールドイメージと3P PAYG RHELの両方のインスタンスからルートボリュームのEBSをデタッチ 1番でデタッチしたEBSを、Amazon LinuxなどのLinuxインスタンスにデータボリュームとしてアタッチ 2番でアタッチしたEBSに対して、 dd コマンドでデータコピーを実施 3番のコピー先のデータボリュームをデタッチして、3P PAYG RHELインスタンスのルートボリュームとして再アタッチ 3P PAYG RHELインスタンスを起動して、RHELゴールドイメージの中身に変わっていることを確認 この手順によって、RHELゴールドイメージにある特定のバージョンのRHELを、3P PAYG RHELのインスタンスとして利用できるようになります。3P PAYG RHELインスタンスメタデータの marketplaceProductCodes が3P PAYG RHEL専用のIDになっていることで、EC2インスタンス利用料金とは別に、AWS Marketplaceのソフトウェア(RHEL)利用料金が課金されていることを確認できます。このメタデータは、前述したRHELのsosreportでも確認できます。 3P PAYG RHEL curl http:// 169 . 254 . 169 . 254 /latest/dynamic/instance-identity/document ... < 略 > ... " billingProducts " : null, " devpayProductCodes " : null, " marketplaceProductCodes " : [ " 6cd5fxzrad0cu2j23p692xytz " ] , " imageId " : " ami-0750537c7c684081d " , ... < 略 > ... まとめ AWS Console/Marketplaceでは、様々なRHELサブスクリプションを購入して利用できることを紹介しました。それぞれのRHELサブスクリプションは、2025年5月時点では次の特徴を備えています。これらのRHELサブスクリプションを、ぜひご活用ください。 1P (1st Party) PAYG RHEL (AWS専用) AWSがRHELをサポート Red Hatアカウントが不要 RHUIが利用可能 rhui-eus-switch コマンドで、RHUIのRHEL EUSリポジトリを参照可能 RHEL for SAP with HA and US(x86_64版)では、デフォルトでRHUIのRHEL E4Sリポジトリが有効化済み バージョン番号/リリース日/アーキテクチャなどが同じであれば、3P PAYG RHELおよびRHELゴールドイメージと中身は同じ Red Hat Satelliteサブスクリプションを含む 一部の例外を除き、RHELの利用料金はEC2インスタンスの利用料金に含まれている AWS License Managerによる以下のライセンスタイプの相互変換が可能 「1P PAYG RHEL」と「3P PAYG RHEL」 3P (3rd Party) PAYG RHEL (AWS専用) Red HatがRHELをサポート Red Hatアカウントが必要 SKU: RH02612 AWS Arm版を利用する場合、SKU: RH02657HRが併せて必要 RHUIが利用可能 RHEL EUSサブスクリプションを含む ( subscription-manager コマンドで設定) RHEL for SAP with HA and US(x86_64版)では、デフォルトでRHUIのRHEL E4Sリポジトリが有効化済み Red Hat Satelliteサブスクリプションを含む RHELの利用料金はEC2インスタンスとは別にAWSから請求される Red Hat Subscriptionsカタログで販売しているRHEL ( AWSだけでなく、オンプレや他のクラウドでも利用可能 ) Red HatがRHELをサポート Red Hatアカウントが必要 Red Hatがこれまでお客様に販売してきた年間契約制のRHEL(x86_64版)のSKUと同じ AWSのRHELゴールドイメージを利用する場合、RHUIが利用可能 RHEL EUSのリポジトリを参照する場合、 subscription-manager コマンドで設定 Red Hatサブスクリプションの追加購入が可能 サブスクリプションが複数ある場合、一番最初に購入したサブスクリプションの契約終了日に自動統一 サブスクリプションを追加購入する場合、上記仕様により料金の日割り計算が適用 AWSで利用する場合、RHELの利用料金はEC2インスタンスとは別にAWSから請求される ルートボリュームとして利用しているEBSを付け替えることで、RHELゴールドイメージと1P PAYG RHELの相互変換が可能 Appendix Red Hatナレッジベースへのアクセスガイド Red Hatアカウントを持たない1P PAYG RHELユーザー向けのガイドが、AWSドキュメントにまとまっています。AWS Systems Managerの機能を利用するので、RHELのインスタンスにAWS Systems Managerエージェント(SSM Agent)をインストールする必要があります。 docs.aws.amazon.com docs.aws.amazon.com Red Hatアカウントを作る場合、無料でRHELなどを使えるRed Hat Developer Subscriptionを持つことでも、Red Hatナレッジベースにアクセスできるようになります。AWSでRed Hat Developer Subscriptionを利用すると、RHELの利用料金なしで(EC2利用料金は必要)最大16台のRHELゴールドイメージを利用できます。 access.redhat.com 1P/3P PAYG RHELをRed Hat Satelliteで管理 1P/3P PAYG RHELにはRed Hat Satelliteで管理するためのサブスクリプションが含まれているため、無料でRed Hat Satelliteを利用できるようになっています。 rheb.hatenablog.com RHUIを利用したRHELのインプレースアップグレード Red Hat CDNのRHELリポジトリだけでなく、RHUIのRHELリポジトリを利用しているRHELインスタンスでも、RHELのメジャーリリース(RHEL7, RHEL8, RHEL9, RHEL10など)間のインプレースアップグレードができます。 rheb.hatenablog.com

Red Hatの小島です。 AWS上でのOpenShift環境の場合、OpenShift Loggingによって主に利用されるログの保存場所はAmazon CloudWatchかAmazon S3となります。本記事では、OpenShift Loggingで利用されるAWSのストレージサイズやインフラ利用料金の目安となる情報を紹介していきます。 先に結論を書いておくと、AWSの利用料金を抑えたい場合は、OpenShift LoggingによるLokiとAmazon S3を使うことを推奨します。 OpenShift Logging 6.2によるロギング設定 Amazon CloudWatchへのログ転送 ROSA HCPクラスターの場合の注意点 Loki + Amazon S3でのログ保存 実際にOpenShift/ROSAのOpenShift Loggingで24時間ログ保存をしてみた結果 Self-Managed Single Node OpenShift の1台構成 Self-Managed OpenShift の5台構成 (Control Plane: 3台, Compute: 2台) ROSA HCP の2台構成 (Compute: 2台) ROSA Classic の7台構成 (Control Plane: 3台, Infra Node: 2台, Compute: 2台) Loki + S3利用時とCloudWatch利用時との料金比較 参考情報 OpenShift Logging 6.2によるロギング設定 Amazon CloudWatchへのログ転送 OpenShift Logging 6.2では、OpenShiftのOperatorHubにある Red Hat OpenShift Logging Operatorでログ転送のための設定を作成します。この際、必要となるものは、Amazon CloudWatchを利用するための認証情報を保存したSecretリソースと、OpenShift Logging Operatorを利用して作成するClusterLogForwarderインスタンスの2つです。 CloudWatchを利用するための認証情報には、CloudWatchのログ参照/書き込み権限を持つAWS IAMユーザーのアクセスキーとシークレットアクセスキー、または、AWS Secruity Token Service (STS) を利用するためのIAMロールを利用できます。前者の場合、AWS IAMユーザーのアクセスキーとシークレットアクセスキーをOpenShiftのSecretリソースとして保存するためのYAMLは次のようになります。 cw-secret はSecretリソースに付けられる名前であり、他に任意の名前を指定できます。 apiVersion : v1 kind : Secret metadata : name : cw-secret namespace : openshift-logging data : aws_access_key_id : XXXXXXXX aws_secret_access_key : YYYYYYYYYYYY このYAMLはOpenShift CLIの oc apply -f <YAMLファイルパス> コマンドや、OpenShift Web Consoleの右上部分にある + アイコンから辿れる YAMLのインポート メニューなどからOpenShiftクラスターに適用して、Secretリソースとして保存できます。 AWS STSを利用する場合、AWS上で次のような カスタム信頼ポリシー とCloudWatchのログ参照/書き込みを利用可能にするIAMポリシー(AWS管理ポリシーの CloudWatchLogsFullAccess など)が紐づけられたIAMロールを作成します。IAMロールのカスタム信頼ポリシーの例は次のとおりです。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " Federated ": " arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<AWS_IAM_ID_PROVIDER_ID> " } , " Action ": " sts:AssumeRoleWithWebIdentity ", " Condition ": { " StringEquals ": { " <AWS_IAM_ID_PROVIDER_ID>:sub ": " system:serviceaccount:openshift-logging:collector " } } } ] } このカスタム信頼ポリシーは、特定の AWS IAM IDプロバイダー に紐づけられたOpenShiftやROSAクラスター上の openshift-logging プロジェクトにある collector サービスアカウントに対して、IAMポリシーで指定されたAWSリソースへの特定の操作を許可するためのものとなります。AWS IAM IDプロバイダーのIDについては、Self-Managed OpenShift環境の場合、下記のブログを参考にしながら確認してください。 rheb.hatenablog.com ROSAの場合は rosa list oidc-provider コマンドで、ROSAクラスターに紐づいているAWS IAM IDプロバイダーが確認できるようになっています。下記のコマンドの出力結果で表示されている oidc.op1.openshiftapps.com/289dfjXXXXXX がAWS IAM IDプロバイダーのIDとなります。 $ rosa list oidc-provider I: Fetching OIDC providers OIDC PROVIDER ARN Cluster ID In Use arn:aws:iam:: < AWS_ACCOUNT_ID > :oidc-provider/oidc.op1.openshiftapps.com/289dfjXXXXXX 2el3cammYYYYYYY Yes CloudWatchを利用するためのポリシーを持ったIAMロールを作成した後は、次のようなYAMLでSecretリソースを作成できます。このYAMLによって、作成したAWS IAMロールを利用するためのSecretリソースを、OpenShiftクラスターの openshift-logging プロジェクトに cw-secret-sts という名前で保存できます。 apiVersion : v1 kind : Secret metadata : name : cw-secret-sts namespace : openshift-logging stringData : cw-key : |- [ default ] role_arn : arn:aws:iam::<AWS_ACCOUNT_ID>:role/<AWS_IAM_ROLE_NAME> web_identity_token_file : /var/run/secrets/openshift/serviceaccount/token こうして作成したSecretリソースを利用して、OpenShift Logging Operator の ClusterLogForwarder インスタンスを作成します。手順の概要は次のとおりです。 OpenShiftのOperatorHubメニューから Red Hat OpenShift Logging Operatorを、デフォルトのパラメーターでインストール ocコマンドで、OpenShift Loggingによるログ収集のためのサービスアカウントを作成 ↑で作成したサービスアカウントに、ログ収集のためのクラスターロールを付与 CloudWatchへのログ転送をするClusterLogForwarderインスタンスを作成 手順2, 3 については、次のようなOpenShift CLIのocコマンドを kubeadmin や cluster-admin などの、OpenShiftクラスターの管理者権限を持つユーザーで実行します。この例では collector という名前のサービスアカウントを openshift-logging プロジェクトに新規作成していますが、 collector 以外にも任意の名前を指定できます。ただし、AWS STSを利用する場合は、前述したIAMロールのカスタム信頼ポリシーで指定しているOpenShiftクラスターのサービスアカウント名を指定するようにしてください。 oc create serviceaccount collector -n openshift-logging oc adm policy add-cluster-role-to-user collect-application-logs -z collector -n openshift-logging oc adm policy add-cluster-role-to-user collect-audit-logs -z collector -n openshift-logging oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector -n openshift-logging 手順4のClusterLogForwarderインスタンスは、AWS IAMユーザーのアクセスキーとシークレットアクセスキーを保存したSecretリソースを利用する場合、次のようなYAMLで作成できます。この時指定するサービスアカウント名とSecretリソース名については、前の手順で作成したサービスアカウント名(この例では collector )とSecretリソース名(この例では cw-secret )を指定します。 また、groupNameに test-cluster-001-{.log_type||"unknown"} を指定することで、CloudWatchに保存されるロググループ名として test-cluster-001- という接頭辞にログタイプ(application, audit, infrastructure) が付いた名前を付けられます。例えば、ユーザーアプリケーションに関するログを保存するロググループ名は test-cluster-001-application となります。 apiVersion : observability.openshift.io/v1 kind : ClusterLogForwarder metadata : name : logforwarder namespace : openshift-logging spec : serviceAccount : name : collector outputs : - name : cw type : cloudwatch cloudwatch : groupName : test-cluster-001-{.log_type||"unknown"} region : us-east-2 authentication : type : awsAccessKey awsAccessKey : keyId : secretName : cw-secret key : aws_access_key_id keySecret : secretName : cw-secret key : aws_secret_access_key pipelines : - name : forward-to-cloudwatch inputRefs : - application - infrastructure - audit outputRefs : - cw AWS STSによるIAMロールをSecretリソースとして指定する場合、次のようなYAMLになります。ここで指定している cw-key は、前の手順で作成した cw-secret-sts Secretリソースで指定したstringDataの名前 cw-key です。 apiVersion : observability.openshift.io/v1 kind : ClusterLogForwarder metadata : name : logforwarder namespace : openshift-logging spec : serviceAccount : name : collector managementState : Managed outputs : - name : cw type : cloudwatch cloudwatch : authentication : type : iamRole iamRole : roleARN : secretName : cw-secret-sts key : cw-key token : from : serviceAccount groupName : 'test-cluster-001-{.log_type||"unknown"}' region : us-east-2 pipelines : - name : forward-to-cloudwatch inputRefs : - application - infrastructure - audit outputRefs : - cw これによって、OpenShiftクラスターのコンピュートノードの数だけログ収集のためのcollector Pod(vectorプロセスが実行されています)が起動して、CloudWatchへのログ転送が開始されて、CloudWatch上でロググループを確認できるようになります。 OpenShift Loggingで収集できる組み込みのログタイプ(application, infrastructure, audit)についての解説は、下記をご参照ください。 https://docs.redhat.com/ja/documentation/openshift_container_platform/4.18/html/logging/log6x-clf-6-2#clf-inputs_6-2_logging-6x-6.2 docs.redhat.com ROSA HCPクラスターの場合の注意点 ROSA Hosted Control Plane (HCP) クラスターの場合、AWSユーザーにはOpenShiftクラスターのコンピュートノード(監査ログは /var/log/audit/audit.log に保存されます)しか見えなくなっているため、コントロールプレーン上の監査ログはそのままでは見えません。これに対してはユーザーからのリクエストを受けて、ROSA HCPの特定のバージョン以降(4.18+, 4.17.2+, 4.16.19+, 4.15.43+)から、OAuthに関する監査ログをCloudWatchにログ転送できる機能が実装されました。2025年3月時点では、S3への監査ログ転送機能は提供していません。 手順の詳細は下記のナレッジベースをご参照ください。AWS STSを利用したCloudWatchへのログ転送を実施するためのIAMロールを作成して、監査ログの転送を有効化/無効化する手順を記載しています。 access.redhat.com 補足: 上記ナレッジベース記載の手順では ocm patch コマンドで監査ログ転送を有効化していますが、 rosa edit cluster コマンドでも同じ効果を得ることはできます。rosaコマンドによる、監査ログ転送の有効化コマンドは次のようになります。 rosa edit cluster -c < ROSA_HCP_CLUSTER_NAME > --audit-log-arn < AWS STSでCloudWatchを利用するためのAWS IAMロールのARN > --yes これによって、ROSA HCPクラスターのOAuthに関するログがCloudWatchに転送されて、 ocm-production-XXXXX-<ROSA_HCP_CLUSTER_NAME> という名前のロググループで確認できるようになります。転送先のCloudWatchのロググループのAWSリージョンは、ROSA HCPクラスターがあるAWSリージョンと同じものとなります。 監査ログ転送を停止したい場合、 audit-log-arn オプションで空値を指定します。 rosa edit cluster -c < ROSA_HCP_Cluster_NAME > --audit-log-arn "" --yes Loki + Amazon S3でのログ保存 AWS STSを利用せずにOpenShift Logging 6.2のLokiを利用する場合、下記の製品ドキュメントにあるクイックスタート手順に従えば、LokiによるAmazon S3へのログ保存が可能です。このクイックスタート手順に記載されている ClusterLogForwarder CR ( Custom Resource ) について、監査ログも転送する場合は spec.pipelines.inputRefs で application と infrastructure だけでなく audit も指定するようにしてください。 https://docs.redhat.com/ja/documentation/openshift_container_platform/4.18/html/logging/log6x-about-6-2#quick-start-viaq_logging-6x-6.2 また、LokiによるAmazon S3などを利用するためのSecretリソースの作成方法は、下記のナレッジベースにまとまっています。 access.redhat.com ただし、AWS STSを利用したOpenShiftクラスターやROSAの場合は、若干勝手が異なります。上記のクイックスタート手順の通りにLoki Operatorをインストールすることは同じですが、Amazon S3を利用するIAMポリシー(AWS管理ポリシーの AmazonS3FullAccess など)が紐づいたIAMロールのARNを、Loki Operatorインストール時に指定する必要があります。このIAMロールのカスタム信頼ポリシーの例は次のとおりです。 なお、この例では openshift-logging プロジェクトのサービスアカウント名として logging-loki を指定しています。Loki OperatorでLokiStackインスタンスを作成する際に、LokiStackインスタンスの名前と同じ名前のサービスアカウントが自動作成されるようになっており、Amazon S3の利用権限はこのサービスアカウントに付与する必要があります。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " Federated ": " arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<AWS_IAM_ID_PROVIDER_ID> " } , " Action ": " sts:AssumeRoleWithWebIdentity ", " Condition ": { " StringEquals ": { " <AWS_IAM_ID_PROVIDER_ID>:sub ": " system:serviceaccount:openshift-logging:logging-loki " } } } ] } OpenShiftクラスターでLoki Operatorをインストールする時には、このIAMロールのARNを指定します。 AWS STSを利用する場合、AWSアクセスキーやシークレットアクセスキーなどをSecretリソースに保存する必要はありません。Amazon S3のバケット名とリージョン名を指定するだけでいいです。下記はその1例です。 apiVersion : v1 kind : Secret metadata : name : logging-loki-s3-sts namespace : openshift-logging stringData : bucketnames : <AWS_BUCKET_NAME> region : <AWS_BUCKET_REGION(例: us-east-2)> ClusterLogForwarderによるLokiStackへのログ転送設定が正常に完了すると、OpenShift Web Consoleからアプリケーション/インフラストラクチャー/監査ログが確認できるようになります。 また、CLI経由でもLokiにはアクセスできるようになっています。アクセス手順については、下記のブログをご参照ください。 rheb.hatenablog.com 実際にOpenShift/ROSAのOpenShift Loggingで24時間ログ保存をしてみた結果 OpenShift/ROSAクラスターを作成した後に、OpenShift Loggingによるログ転送や保存に関する設定を適用した状態で、実際にどのくらいログが保存されるのかをいくつかの構成パターンで確認してみました。ここでの LokiStackインスタンスのサイズ は 1x.demo を指定しています。これらのログ保存サイズは参考値として見てください。実際の環境では application ログにユーザーのアプリケーションに関するログが追加されるなど、様々なログが追加されることに注意してください。 注: ログ転送や保存のテストのためにいくつかのサンプルアプリを実行しているため、 application ログサイズが0ではありません。また、データ圧縮のパラメーターは指定していません。 Self-Managed Single Node OpenShift の1台構成 Loki + S3 CloudWatch Self-Managed OpenShift の5台構成 (Control Plane: 3台, Compute: 2台) Loki + S3 CloudWatch ROSA HCP の2台構成 (Compute: 2台) Loki + S3 CloudWatch ROSA HCP 4.18 でのOAuthの監査ログ転送を有効化した状態です。 ROSA Classic の7台構成 (Control Plane: 3台, Infra Node: 2台, Compute: 2台) Loki + S3 CloudWatch 補足: 2026年4月1日以降に、ROSA Classicクラスターの新規作成機能が終了する予定なので、今からのROSA Classicクラスター新規作成は推奨していません。 access.redhat.com Loki + S3利用時とCloudWatch利用時との料金比較 Loki + S3を利用する場合と、CloudWatchへのログ転送をする場合との簡単な料金比較をしてみます。データ料金比較の簡単化のために、前述のS3とCloudWatchで保存されるログサイズの実測値を考慮して、S3でのログ保存サイズをCloudWatchでのログ保存サイズの2倍と仮定します。例えば、S3でのログ保存サイズが20GB、CloudWatchでのログ保存サイズがその半分の10GBとすると、S3へのログ転送サイズはそのまま20GB、CloudWatchへのログ転送サイズはCloudWatchが備えるデータ圧縮機能(圧縮率は0.15~0.2程度)を考慮して50GBとなります。なお、Lokiではログデータが自動的に圧縮される仕組みとなっています。 OpenShift LoggingでのLoki + S3を利用する場合は、デモ用途の 1x.demo サイズを除けば 1x.pico がLokiの最小サイズとなります。 1x.pico サイズで求められるvCPU数が7個以上、メモリは17GiB以上となります。また、 1x.medium が最大サイズとなり、求められるvCPU数が54個以上、メモリは139GiB以上となります。そこで、 1x.pico を利用する場合と 1x.medium を利用する場合とで、次の条件を想定してみました。 50GB/日 のログが発生する場合 (パターンA) Loki用にm5.xlarge (4vCPU, RAM16GiB) EC2インスタンスを2台用意 このEC2インスタンス2台に接続されるEBS gp3のサイズは、それぞれ150GB Lokのデータ保存用途に利用されるEBS gp3のサイズは、590GB S3(標準)への書き込み(POST)サイズは、1リクエスト辺り1MBを想定 (実測では、数KB~2MBほどの保存データが多い) S3へのログ転送サイズは20GB、CloudWatchへのログ転送サイズは50GB S3のログ保存サイズは20GB、CloudWatchのログ保存サイズは10GB 2TB/日 のログが発生する場合 (パターンB) Loki用にm5a.8xlarge (32vCPU, RAM128GiB) EC2インスタンスを2台用意 このEC2インスタンス2台に接続されるEBS gp3のサイズは、それぞれ150GB Lokのデータ保存用途に利用されるEBS gp3のサイズは、590GB S3(標準)への書き込み(POST)サイズは、1リクエスト辺り1MBを想定 (実測では、数KB~2MBほどの保存データが多い) S3へのログ転送サイズは800GB、CloudWatchへのログ転送サイズは2TB S3のログ保存サイズは800GB、CloudWatchのログ保存サイズは400GB これらの条件のもとで、パターンAとパターンBでの24時間利用料金を計算した結果が下記となります。AWSリージョンはオハイオ(us-east-2)としています。 パターンAの24時間料金 (税抜) Loki + S3: $11.71 EC2インスタンス+EBS: $0.192/hour x 2 x 24 + (150 x 2 + 590) x 0.08/GB/month x 1/30 = $11.59 S3へのリクエスト: $0.005/1000リクエスト x 20000MB x 1リクエスト/MB = $0.1 S3での保存: $0.023/GB/month x 20GB x 1/30 = $0.02 CloudWatch: $25.01 CloudWatchへの転送: $0.5/GB x 50GB = $25 CloudWatchでの保存: $0.03/GB/month x 10GB x 1/30 = $0.01 パターンBの24時間料金 (税抜) Loki + S3: $73.03 EC2インスタンス+EBS: $1.376/hour x 2 x 24 + (150 x 2 + 590) x 0.08/GB/month x 1/30 = $68.42 S3へのリクエスト: $0.005/1000リクエスト x 800000MB x 1リクエスト/MB = $4 S3での保存: $0.023/GB/month x 800GB x 1/30 = $0.61 CloudWatch: $1,000.4 CloudWatchへの転送: $0.5/GB x 2000GB = $1000 CloudWatchでの保存: $0.03/GB/month x 400GB x 1/30 = $0.4 ログサイズが大きいほど、Loki + S3を利用する場合とCloudWatchを利用する場合とで利用料金の差が大きくなっています。そのため、AWSインフラの利用料金を抑えたい場合、ログフィルターなどを活用するとしても、OpenShift LoggingによるLokiを利用する方がいいでしょう。 また、ROSAのようなManaged OpenShift Serviceの場合、OpenShiftクラスターの運用管理をSREチームに任せることができるので、OpenShift Loggingで保存するログは、ユーザーアプリケーションに関する application ログだけでいいと割り切ることもできます。リアルタイムでの監査ログ監視が必要なければ、ROSAについては ユーザーがRed Hatサポートケース経由で監査ログを要求する こともできますので、こうした仕組みもうまく活用してください。 参考情報 CloudWatch Logs と S3 にかかる料金比較 dev.classmethod.jp OpenShift Logging OperatorのClusterLogForwarderインスタンスを作成する際の、各パラメータの説明ドキュメント github.com ClusterLogForwarderインスタンスを作成するための、サンプルYAMLのリスト github.com ClusterLogForwarderのVector AtLeastOnceのログ転送パフォーマンス rheb.hatenablog.com

こんにちは。Specialist Solution Architect の瀬戸です。 説明すると、たまになんで？という反応をされることもあるのですが、Red HatはMicrosoftとアライアンスを結んでおり、.NETの実行をエンタープライズ品質でサポートしています。 Red HatはOpenJDKやJBoss EAP、Quarkusなどの開発をしていて、Javaに多大なコミットメントをしているということもあり、Javaしかサポートしていないよと勘違いされる場合もあるのですが、そんなことはなくて.NET/PHP/Node.js/Ruby/Python等いくつかの言語ランタイムもサポートしています。 何がサポートされているかについては次のページを参照してください。 access.redhat.com なんと、.NETについては特設ページまであります。 developers.redhat.com .NETのサポートポリシーはこちら。 access.redhat.com というだけで終わらせてもアレなので、実際に動かしてみましょう。 OpenShift上にプロジェクトを作成します。(OpenShift 4.16で確認しています。) > oc new-project mydemo GitHubにサンプルアプリケーションが準備されているので、そちらを指定してアプリケーションをデプロイします。 > oc new-app dotnet:8.0-ubi8~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnet-8.0 --context-dir app 次のように表示されます。 warning: Cannot check if git requires authentication. --> Found image fece063 (8 days old) in image stream "openshift/dotnet" under tag "8.0-ubi8" for "dotnet:8.0-ubi8" .NET 8 ------ Platform for building and running .NET 8 applications Tags: builder, .net, dotnet, dotnetcore, dotnet-80 * A source build using source code from https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnet-8.0 will be created * The resulting image will be pushed to image stream tag "s2i-dotnetcore-ex:latest" * Use 'oc start-build' to trigger a new build --> Creating resources ... imagestream.image.openshift.io "s2i-dotnetcore-ex" created buildconfig.build.openshift.io "s2i-dotnetcore-ex" created deployment.apps "s2i-dotnetcore-ex" created service "s2i-dotnetcore-ex" created --> Success Build scheduled, use 'oc logs -f buildconfig/s2i-dotnetcore-ex' to track its progress. Application is not exposed. You can expose services to the outside world by executing one or more of the commands below: 'oc expose service/s2i-dotnetcore-ex' Run 'oc status' to view your app. デプロイが完了したかpodの状況を確認します。 > oc get pods -w NAME READY STATUS RESTARTS AGE s2i-dotnetcore-ex-1-build 0/1 Completed 0 110s s2i-dotnetcore-ex-5dd94d78d4-k95hf 1/1 Running 0 77s デプロイが完了したらルートを作成して、公開します。 > oc expose service s2i-dotnetcore-ex route.route.openshift.io/s2i-dotnetcore-ex exposed > oc get route s2i-dotnetcore-ex NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD s2i-dotnetcore-ex s2i-dotnetcore-ex-mydemo.apps.cluster-lbdm8.dynamic.redhatworkshops.io s2i-dotnetcore-ex 8080-tcp None 表示されたURLにアクセスすると実際に動いています。 .NETアプリケーションの画面 使用したソースコードは次のリポジトリにあります。 github.com s2iというOpenShiftの標準のデプロイシステムでも.NETをサポートしていますので、簡単にデプロイできます。 そのうえでRed HatとMicrosoftの強力なサポート体制もあるので、.NETアプリケーションを今まではWindowsサーバーを複数台立てて管理してたけど、インフラコストを抑えるために集約したい場合等の移行先としては良い選択肢になるのではないでしょうか。 また、デプロイの方法についてはJavaの場合とあまり変わりません。Javaの場合にどういうデプロイがされるかは次の記事を参照してください。 他の言語についても同じ感覚でデプロイすることができます。 OpenShiftの操作についての基礎知識がない場合も見ていただけるとocコマンドのインストール方法等が載ってます。 rheb.hatenablog.com ということで、簡単なOpenShift上での.NETアプリケーションの紹介でした。

こんにちは、Red HatでOpenShift関連のプリセールスをしている北村です。 前回の記事ではGolden Path実装の前段として、SonarQubeの導入やDeveloper Hubとの連携、そしてAWS ECRへの認証設定などを行いました。 この記事ではいよいよGolden Pathの中身について解説していきます。 【第1回】Developer Hubをインストールしてみよう 【第2回】GitHubを使用した認証を実装しよう 【第3回】GitLabを使用した認証を実装しよう 【第4回】Componentを作成・登録しよう 【第5回】Software Templateを使ってアプリのデプロイをセルフサービス化しよう 【第6回】TechDocsを作成・登録しよう 【第7回】Golden Pathの実装をマスターしよう - 前編 【第8回】Golden Pathの実装をマスターしよう - 後編 ←この記事 今回実装する環境（おさらい） 今回は以下のような環境を構築していきます。 利用者はDeveloper Hubの画面で必要なパラメータを入力してTemplateを実行する Skeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入する 新しいGitHubリポジトリ(app用リポジトリとmanifest用リポジトリ)にPushする Hello worldアプリ用のK8sマニフェストをデプロイするためのApplication CRを作成する リポジトリの作成を契機にアプリをビルド→デプロイするGitHub Actionsを実行する ビルドされたコンテナイメージはAWS ECRに保管する Application CRが新しいGitHubリポジトリ上のK8sマニフェストを検知してアプリをデプロイする Golden Path実行の準備 今回実行するGolden Pathは こちらのリポジトリ を利用します。このリポジトリを自分の環境にForkしてきてください。 Golden Pathの登録 ForkしてきたGolden Pathリポジトリにあるtemplate.yamlをDeveloper Hubに登録していきます。 app-config-rhdh.yaml を修正して、このファイルを常に読み込む状態にします。 app-config-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : app-config-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : app-config-rhdh.yaml : | app : ...omit... backend : ...omit... auth : ...omit... integrations : ...omit... signInPage : github catalog : ...omit... locations : - type : url target : https://github.com/<GitHub Organization名>/helloworld-skeleton/blob/main/template.yaml schedule : frequency : PT60S initialDelay : PT30S timeout : PT120S # ここから下を追記 - type : url target : https://github.com/<GitHub Organization名>/helloworld-goldenpath/blob/main/template.yaml # 先ほどForkしたリポジトリのtempalte.yamlを指定 schedule : frequency : PT60S initialDelay : PT30S timeout : PT120S この設定を反映します。 oc apply -f app-config-rhdh.yaml Podが再起動するのでアクセスすると、Templateが1つ追加されていることがわかります。この Hello world app with CICD が今回のGolden Pathになります。 まずは実行してみよう 中身の説明は後回しにして、一回このGolden Pathを実行してみましょう。 実際に選択して必要項目を入力していきますが、入力する内容は 第5回 で作成したものと全く一緒のものになります。 実際にデプロイ後、コンポーネント画面に移動すると、これまでのものとはいくつか異なる点があるかと思います。 Linkに App Repository と Manifest Repository の2つが存在する CI というタブが増えている Sonarqubeのスキャン結果を確認できるカードが増えている Linkを選択すると、ソースコードを管理する <repo-name>-app とK8sマニフェストを管理する <repo-name>-manifest の2種類のリポジトリに遷移できます。これらはGolden Pathの実行によって自動生成されました。 次にCIタブに移動すると、2つのパイプラインが実行されていることが確認できます。ひとつ目がコンテナをビルド・デプロイするためのCICDパイプラインworkflowです。ふたつ目が 第6回 で作成したTechdocsを作成・登録するためのworkflowです。 Message の部分のリンクを選択すると、該当のworkflowの詳細画面が表示されます。Linksにある Workflow runs on GitHub を選択すると、GitHubの画面にも遷移できます。 実際に遷移してみましょう。すると4つのjobが実行されています。 sonar_scan : ソースコードに対してSonarqubeによるスキャンを実行します。 build_and_push : コンテナをビルドしてECRにPushします。 update_manifests : manifestリポジトリ側のk8sマニフェスト内のイメージタグをビルドしたイメージのものに書き換えます。 deploy_application : ArgoCDのSyncを実行してアプリケーションを更新します。 つまり、開発者がこのGolden Pathを実行しただけで、自分たち専用のGitリポジトリが払い出され、その中にサンプルコードが格納されており、かつCIパイプラインが実行され、静的解析が走り、コンテナがビルド・デプロイされることになります。さらにその周辺のツールへもこのコンポーネント画面から簡単にアクセスできるようになりました。便利でしょう？ Golden Pathの中身を確認してみよう ではこのGolden Pathがどのように実装されているか、中身を見てみましょう。 $ tree -L 1 . ├── README.md ├── app-skeleton ├── manifest-skeleton └── template.yaml ディレクトリ直下を見てみると、 app-skeleton と manifest-skeleton 、そして template.yaml が存在します。このskeletonリポジトリがGolden Pathを実行し、リポジトリを払い出すときの元となります。 template.yaml まずはじめに template.yaml の中身を上から順に確認していきます。なお、パラメータ入力の部分は前回のものと同様のため割愛し、Stepの部分から見ていきます。 Fetch App skeleton steps : - id : fetch-app name : Fetch App skeleton action : fetch:template input : url : ./app-skeleton values : app_name : ${{ parameters.app_name }} owner : ${{ parameters.owner }} git_repo_name : ${{ parameters.git_repo_name }} git_host_url : ${{ parameters.git_host_url }} git_owner_name : ${{ parameters.git_owner_name }} targetPath : ./app-tenant - id : fetch-manifest name : Fetch Manifest skeleton action : fetch:template input : url : ./manifest-skeleton values : app_name : ${{ parameters.app_name }} owner : ${{ parameters.owner }} git_repo_name : ${{ parameters.git_repo_name }} git_host_url : ${{ parameters.git_host_url }} git_owner_name : ${{ parameters.git_owner_name }} targetPath : ./manifest-tenant ここは前回のTemplateでも行っていた fetch:template というactionです。前回では manifest-skeleton だけでしたが、今回は開発者が実際にコーディングを行うアプリ用のリポジトリを生成すべく、 app-skeleton からもfetchを行っています。 Publish GitHub - id : publish-app name : Push App Repo to GitHub action : publish:github input : repoUrl : ${{ parameters.git_host_url }}?owner=${{ parameters.git_owner_name }} &repo=$ {{ parameters.git_repo_name }} -app repoVisibility : public sourcePath : ./app-tenant defaultBranch : develop protectDefaultBranch : false - id : publish-manifest name : Push Manifest Repo to GitHub action : publish:github input : repoUrl : ${{ parameters.git_host_url }}?owner=${{ parameters.git_owner_name }} &repo=$ {{ parameters.git_repo_name }} -manifest repoVisibility : public sourcePath : ./manifest-tenant defaultBranch : develop protectDefaultBranch : false ここでGitHubにPushを行います。 repoUrl の末尾にそれぞれ -app と -manifest がついており、この命名規則に従ってリポジトリが生成されます。 ArgoCD Deploy - id : argocd name : Deploy with ArgoCD action : argocd:create-resources input : appName : ${{ parameters.app_name }}-init argoInstance : main namespace : openshift-gitops repoUrl : https://${{ parameters.git_host_url }}/${{ parameters.git_owner_name }}/${{ parameters.git_repo_name }}-manifest.git path : 'argocd/' ここは前回とほぼ同じく、ArgoCDの application リソースをデプロイするActionです。 repoUrl だけmanifestリポジトリをちゃんと参照するように変更されています。 Register Component - id : register name : Register Catalog into Developer Hub action : catalog:register input : repoContentsUrl : ${{ steps['publish-app'].output.repoContentsUrl }} catalogInfoPath : "/catalog-info.yaml" ここも前回同様、新しく生成された catalog-info.yaml をDeveloper Hubに登録しているActionです。今回の catalog-info.yaml はappリポジトリ側に存在するため、 repoContentsUrl の部分だけstepの参照先が publish-app に変わっています。 Outputs output : links : - title : Componentを開く icon : catalog entityRef : ${{ steps['register'].output.entityRef }} - title : Application Gitリポジトリを開く url : ${{ steps['publish-app'].output.remoteUrl }} icon : github - title : Manifest Gitリポジトリを開く url : ${{ steps['publish-manifest'].output.remoteUrl }} icon : github 最後にoutputの部分ですが、ここではGolden Pathの完了後にComponent、Application Gitリポジトリ、Manifest Gitリポジトリに遷移できるリンクを生成しています。 以上が template.yaml の全貌です。意外と前回までのTemplateと大差がないことがわかったかと思います。実はこのSofeware Template機能で実行すること事態はそれほどバリエーションが多くなく、結局は いかにSkeletonリポジトリを作り込むか が現時点のDeveloper Hubにおける重要なポイントになります。ただこれから様々なActionが追加され、このSoftware Templateからもさらにいろんな作業ができるようになっていきます（多分）ので、Developer Hubの進化を楽しみしてください。 Manifestリポジトリ 次にManifest用のリポジトリを見ていきましょう。こちらも多少ディレクトリ構成が変わっていますが、大きな変化はありません。 $ tree manifest-skeleton manifest-skeleton ├── argocd │   └── application.yaml └── kustomize ├── base │   ├── app-sa.yaml │   ├── deployment.yaml │   ├── ecr-secret.yaml │   ├── kustomization.yaml │   ├── route.yaml │   └── service.yaml └── overlays └── dev └── kustomization.yaml マニフェストを格納するディレクトリを名を kustomize とし、その下に base と overlays の階層を設けています。今回の環境では develop ブランチのみなので、 overlays 配下には dev のみを切っています。 前回と大きく変わった点としては、 overlays/dev 配下にある kustomization.yaml です。 kustomize/overlays/dev/kustomization.yaml apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization resources : - ../../base images : - name : ___IMAGE_URL___@___IMAGE_DIGEST___ この images の部分に name: ___IMAGE_URL___@___IMAGE_DIGEST___ と記載しています。これはのちほどCIパイプラインの中で新しいイメージタグに書き換えるためにあります。 このために、 deployment.yaml にも同様のimage名が設定されています。 deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : ...omit... spec : ...omit... template : ...omit... spec : containers : - image : ___IMAGE_URL___@___IMAGE_DIGEST___ ...omit... また、 base 配下にECR Secret Operatorの Secret カスタムリソースをデプロイする ecr-secret.yaml と、サービスアカウントをデプロイするための app-sa.yaml が追加されています。 ecr-secret.yaml apiVersion : ecr.mobb.redhat.com/v1alpha1 kind : Secret metadata : name : ecr-secret spec : generated_secret_name : ecr-auto-generated-secret ecr_registry : ___AWS_ACCOUNT_ID___.dkr.ecr.___AWS_REGION___.amazonaws.com frequency : 10h region : ___AWS_REGION___ specにECRの情報や名前を記入することで、ECRの認証情報を持つSecretを自動生成します。 ___AWS_ACCOUNT_ID___ や ___AWS_REGION___ という記載がありますが、こちらはGitHub Actions内で実際の値に置換されるのでこのままでOKです。 app-sa.yaml --- apiVersion : v1 kind : ServiceAccount metadata : name : ${{ values.app_name }}-sa imagePullSecrets : - name : ecr-auto-generated-secret --- apiVersion : rbac.authorization.k8s.io/v1 kind : RoleBinding metadata : name : ${{ values.app_name }}-sa-admin subjects : - kind : ServiceAccount name : ${{ values.app_name }}-sa namespace : ${{ values.app_name }} roleRef : kind : ClusterRole name : admin apiGroup : rbac.authorization.k8s.io こちらはアプリケーションのデプロイ、すなわち該当イメージのPullに使用されるサービスアカウントです。 imagePullSecrets に自動生成されるECR認証情報のSecret名を記入しておくことで、その認証情報を使ってECRからイメージをPullしてきます。 以上がManifestリポジトリの主な変更点です。 Appリポジトリ 次にAppリポジトリについてです。 $ tree app-skeleton -L 1 -a app-skeleton ├── .dockerignore ├── .github ├── .gitignore ├── Dockerfile ├── README.md ├── catalog-info.yaml ├── docs ├── mkdocs.yml ├── package-lock.json ├── package.json └── src 今回は簡単なHello Worldアプリのため、ディレクトリ構成もシンプルです。Techdocs生成に必要な docs や mkdocs.yml 、そしてコンポーネント画面用の catalog-info.yaml はこちらのリポジトリに移してあります。 このディレクトリで重要なのはやはりGitHub Action用のworkflowファイルです。今回は新たにビルド・デプロイ用のパイプラインファイル build-deploy.yaml が追加されています。早速中身を見てみましょう。 .github/workflows/build-deploy.yaml SonarQube Scan jobs : sonar_scan : runs-on : ubuntu-latest if : github.ref == 'refs/heads/develop' steps : - name : Checkout code uses : actions/checkout@v3 with : fetch-depth : 0 - name : SonarQube Scan uses : sonarsource/sonarqube-scan-action@master env : SONAR_TOKEN : ${{ "${{" }} secrets.SONARQUBE_USER_TOKEN }} SONAR_HOST_URL : ${{ "${{" }} vars.SONARQUBE_URL }} with : args : > -Dsonar.projectKey="${{ values.app_name }} " まず最初のJobはSonarqubeによるスキャンです。 sonarsource/sonarqube-scan-action@master アクションを使って実行します。必要な変数は GitHub Organization Secrets/Variables から取ってきたり、Developer HubのGolden Path Tempalte実行時のユーザー入力値から持ってきます GitHubから取得する場合の記載方法が ${{ "${{" }} secrets.SONARQUBE_USER_TOKEN }} と不思議な記載になっていますが、これはScaffolderの fetch:template アクションでの変更を防ぐためになります。 奇しくもScaffolderの fetch:template アクションとGitHubの変数の代入ロジックがともに ${{...}} となっており、これをそのまま ${{ secrets.SONARQUBE_USER_TOKEN }} と記述してしまうとScaffolderの fetch:template アクション側で代入が走り、結果としてnull値となってしまいます。今回のように ${{ "${{" }} secrets.変数名 }} とすることで、 fetch:template で ${{ "${{" }} → ${{ という変換をしてもらいます。 Build and Push build_and_push : runs-on : ubuntu-latest needs : [ sonar_scan ] permissions : id-token : write contents : read steps : - name : Checkout source code uses : actions/checkout@v3 - name : Configure AWS Credentials uses : aws-actions/configure-aws-credentials@v3 with : role-to-assume : arn:aws:iam::${{ "${{" }} secrets.AWS_ACCOUNT_ID }}:role/GitHubActionsPushECRRole role-session-name : GitHubActionsSession aws-region : ${{ "${{" }} secrets.AWS_REGION }} - name : Login to Amazon ECR id : ecr-login uses : aws-actions/amazon-ecr-login@v1 with : mask-password : 'true' - name : Create ECR repository if not exists run : | REPOSITORY_NAME="${{ values.app_name }} " if ! aws ecr describe-repositories --repository-names " $REPOSITORY_NAME" > /dev/ null 2>&1; then aws ecr create-repository --repository-name "$REPOSITORY_NAME" fi - name : Build Docker image run : | docker build -t ${{ "${{" }} steps.ecr-login.outputs.registry }}/${{ values.app_name }}:${{ "${{" }} github.sha }} . - name : Push Docker image run : | docker push ${{ "${{" }} steps.ecr-login.outputs.registry }}/${{ values.app_name }}:${{ "${{" }} github.sha }} 次に行っているのがコンテナのビルドとECRへのイメージのPush処理になります。 Configure AWS Credentials : 第7回 で設定したGitHub Actions用のIAMロールを指定し、認証情報を取得しています。 Login to Amazon ECR : ECRへログインします。 Create ECR repository if not exists : 該当のECRリポジトリが存在しない場合にECRの作成処理を行います。 Build Docker image : コンテナイメージをビルドします Push Docker image : ECRへイメージをPushします。 Update Manifests update_manifests : runs-on : ubuntu-latest if : github.ref == 'refs/heads/develop' needs : [ build_and_push ] steps : - name : Create token for manifest repository id : app-token uses : actions/create-github-app-token@v1 with : app-id : ${{ "${{" }} secrets.GITHUBAPP_ID }} private-key : ${{ "${{" }} secrets.GITHUBAPP_PRIVATE_KEY }} owner : ${{ values.git_owner_name }} repositories : ${{ values.git_repo_name }}-manifest - name : Checkout manifest repository uses : actions/checkout@v4 with : repository : ${{ values.git_owner_name }}/${{ values.git_repo_name }}-manifest path : ${{ values.git_repo_name }}-manifest token : ${{ "${{" }} steps.app-token.outputs.token }} - name : Install kustomize run : | curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash sudo mv kustomize /usr/local/bin - name : Update Manifests run : | cd ${{ values.git_repo_name }}-manifest/kustomize/overlays/dev kustomize edit set image ___IMAGE_URL___@___IMAGE_DIGEST___=${{ "${{" }} secrets.AWS_ACCOUNT_ID }}.dkr.ecr.${{ "${{" }} secrets.AWS_REGION }}.amazonaws.com/${{ values.app_name }}:${{ "${{" }} github.sha }} sed -i "s|___AWS_ACCOUNT_ID___|${{ " ${{" }} secrets.AWS_ACCOUNT_ID }}|g" ../../base/ecr-secret.yaml sed -i "s|___AWS_REGION___|${{ " ${{" }} secrets.AWS_REGION }}|g" ../../base/ecr-secret.yaml - name : Commit and push changes run : | cd ${{ values.git_repo_name }}-manifest git config user.name "github-actions[bot]" git config user.email "github-actions[bot]@users.noreply.github.com" git add . git diff-index --quiet HEAD || git commit -m "Update kustomize manifests for commit ${{ github.sha }}" git push origin HEAD:develop 次に行っている update_manifests Jobでは、パイプライン上で manifest リポジトリをチェックアウトしてきて、今回ビルドしたコンテナイメージの情報をもとにマニフェストを書き換える処理を行っています。 Create token for manifest repository : GitHub Appの認証情報を利用して、対象となるManifestリポジトリにアクセスするためのアクセストークンを生成します。 Checkout manifest repository : 前のステップで生成したトークンを利用して、対象のManifestリポジトリをチェックアウトします。 Install kustomize : 次ステップで利用するkustomizeコマンドをインストールします。 Update Manifests : kustomize edit set image コマンドで、プレースホルダーになっている ___IMAGE_URL___@___IMAGE_DIGEST___ を実際のECRのURLと github.sha で表されるコミット識別子に更新しています。また、sed コマンドで base/ecr-secret.yaml 内の AWS アカウントIDおよびリージョンのプレースホルダーを実際の値に置換します。 Commit and push changes : 変更内容をコミットし、develop ブランチにプッシュします。 Deploy Application deploy_application : runs-on : ubuntu-latest if : github.ref == 'refs/heads/develop' needs : [ update_manifests ] steps : - name : Install ArgoCD CLI run : | curl -sSL -o argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64 chmod +x argocd sudo mv argocd /usr/local/bin/argocd - name : Sync and wait for deployment run : | argocd login "${{ " ${{" }} vars.ARGOCD_INSTANCE_URL }} " --username " ${{ "${{" }} secrets.ARGOCD_USERNAME }} " --password " ${{ "${{" }} secrets.ARGOCD_PASSWORD }} " --skip-test-tls --grpc-web argocd app sync ${{ values.app_name }} --revision develop argocd app wait ${{ values.app_name }} --health 最後のJobはArgoCDにSyncコマンドを送信するためのものです。これにより、前のJobで変更したマニフェストの内容を実環境に反映させます。 Install ArgoCD CLI : ArgoCD CLIをインストールします。 Sync and wait for deployment : ROSA上のArgoCDにログインして、syncを実行します。 以上が今回のCICDパイプラインの全貌です。 おわりに 前回と今回の記事で、簡単ですが実践的なGolden Pathの準備と実行を実現してきました。 これはコンテナ環境におけるCICDのベースとなるものになります。これから様々なJob（例えばイメージのスキャンやSBOMの作成など）を追加して、自分なりのGolden Pathにブラッシュアップしていっていただけばと思います。

【2026年2月追記】最新の情報を元に内容をアップデートしました！ こんにちは、Red HatでOpenShift関連のプリセールスをしている北村です。 これまで、Developer Hub (Backstage) を使って認証連携やComponentの登録、さらにはSoftware Template機能を用いたシンプルなHello Worldアプリのセルフサービスデプロイをご紹介してきました。 この記事ではより実践的なテンプレート、すなわちGolden Pathを構築するためのSoftware Templateの実装に挑戦します。 なお、実践的なGolden Pathの構築には多数の手順が必要になるので、記事を前編と後編に分けてご紹介します。この記事は前編として周辺ツールの準備とDeveloper Hubとの連携手順をまとめます。 【第1回】Developer Hubをインストールしてみよう 【第2回】GitHubを使用した認証を実装しよう 【第3回】GitLabを使用した認証を実装しよう 【第4回】Componentを作成・登録しよう 【第5回】Software Templateを使ってアプリのデプロイをセルフサービス化しよう 【第6回】TechDocsを作成・登録しよう 【第7回】Golden Pathの実装をマスターしよう - 前編 ←この記事 【第8回】Golden Pathの実装をマスターしよう - 後編 Golden Pathとは Golden Pathとは、開発のベストプラクティスを実際に動作する環境と共に開発者に提供する仕組みです。 Golden Pathには実際に動くサンプルアプリとそのソースコード、アプリの開発に必要なCIパイプラインやGitOps環境、そしてGolden Pathによって構築された環境の可観測性や、Golden Pathの価値を正しく理解して活用するためのTechDocsが含まれます。 このGolden PathをPlatform Engineering Teamから提供することで、 開発者に守ってほしいルールを付与しつつ、実際に動くアプリとコードを提供することで、開発者のノウハウ習得をサポートします。 このGolden PathこそDeveloper Hubの真価の根幹であり、全てはこのGolden Pathの実行から開発者体験は始まります。 逆にいうと、Developer Hubはただ環境を準備しただけでは価値はあまりなく、このGolden Pathを提供して初めて導入価値が発揮されます。 Golden Pathの実装ステップ ここからは、Golden Path実現のための実装手順について解説します。 実装手順は大きく分けると以下のステップで進めていきます。 環境の構築 : Golden Path実行に必要な周辺ツールを準備します。今回はSonarqubeをインストールしていきます。 Developer Hub連携 : 導入したSonarqubeや、GitHub Actionsとの連携設定を行います。 Skeleton Repositoryの作成 : Golden Pathのコピー元となるリポジトリを準備します。この中にはGitHub ActionsのWorkflowも含まれます。 template.yamlの作成 : Golden Pathを実行するためのtemplate.yamlを作成します。 Golden Pathの実行・確認 : 実際にGolden Pathを実行し、挙動を確認します。 今回は1と2を実装していきます。 今回実装する環境 今回は以下のような環境を構築していきます。 利用者はDeveloper Hubの画面で必要なパラメータを入力してTemplateを実行する Skeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入する 新しいGitHubリポジトリ(app用リポジトリとmanifest用リポジトリ)にPushする Hello worldアプリ用のK8sマニフェストをデプロイするためのApplication CRを作成する リポジトリの作成を契機にアプリをビルド→デプロイするGitHub Actionsを実行する ビルドされたコンテナイメージはAWS ECRに保管する Application CRが新しいGitHubリポジトリ上のK8sマニフェストを検知してアプリをデプロイする 環境の構築 まずはGolden Path実装に必要な周辺ツールを準備します。今回はコードの静的解析として Sonarqube をROSAクラスター上にインストールして行きます。 Sonarqubeのインストール SonarqubeはGolden PathでデプロイされるCIパイプライン上でアプリケーションコードの静的解析に使用します。 SonarqubeはHelmでインストールしますが、公式のHelmチャートではOpenShiftのデフォルトのセキュリティ設定の関係でインストールすることができません。そのためGitHubの Red Hat Communities of Practiceにあるhelmチャート を利用します。 # Project作成 oc new-project sonarqube # リポジトリの追加 helm repo add redhat-cop https://redhat-cop.github.io/helm-charts # sonarqubeのインストール helm upgrade --install sonarqube redhat-cop/sonarqube -n sonarqube しばらくするとリソースがデプロイされるので、RouteのURLを取得してアクセスします。 oc get route -n sonarqube sonarqube -o jsonpath = { . status .ingress [ 0 ] .host } Sonarqubeのログイン画面が表示されるので admin / admin でログインします。 Passwordをアップデートする必要があるので適当に変更します。 Sonarqubeにログインできました。これでいったんSonarqubeのインストールも完了です。 Developer Hub連携 導入したSonarqube、GitHub Actionsとの連携設定を行います。 Dynamic Pluginをインストールする まずはいつも通りDynamic Pluginをインストールします。 dynamic-plugins-rhdh.yaml を変更していきます。GitHub ActionsのPluginと、Sonarqube Pluginを3種類追加します。 dynamic-plugins-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : dynamic-plugins-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : dynamic-plugins.yaml : | includes : - 'dynamic-plugins.default.yaml' plugins : # GitHub Plugins - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-scaffolder-backend-module-github-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-community-plugin-github-actions #追加 disabled : false # GitLab Plugins - package : ./dynamic-plugins/dist/immobiliarelabs-backstage-plugin-gitlab disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-dynamic disabled : false - package : ./dynamic-plugins/dist/immobiliarelabs-backstage-plugin-gitlab-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-scaffolder-backend-module-gitlab-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-org-dynamic disabled : false # Kubernetes Plugins - package : ./dynamic-plugins/dist/backstage-plugin-kubernetes-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-kubernetes disabled : false # OpenShift Plugins - package : ./dynamic-plugins/dist/backstage-community-plugin-topology disabled : false # ArgoCD Plugins - package : ./dynamic-plugins/dist/roadiehq-backstage-plugin-argo-cd-backend-dynamic disabled : false - package : ./dynamic-plugins/dist/backstage-community-plugin-redhat-argocd disabled : false - package : ./dynamic-plugins/dist/roadiehq-scaffolder-backend-argocd-dynamic disabled : false # Techdocs Plugins - package : ./dynamic-plugins/dist/backstage-plugin-techdocs disabled : false - package : ./dynamic-plugins/dist/backstage-plugin-techdocs-backend-dynamic disabled : false # Sonarqube Plugins - package : ./dynamic-plugins/dist/backstage-community-plugin-sonarqube #追加 disabled : false - package : ./dynamic-plugins/dist/backstage-community-plugin-sonarqube-backend-dynamic #追加 disabled : false - package : ./dynamic-plugins/dist/backstage-community-plugin-scaffolder-backend-module-sonarqube-dynamic #追加 disabled : false backstage-plugin-github-actions : GitHub Actionsのワークフロー実行状況や結果をDeveloper Hub上で表示し、CI/CDパイプラインの進捗を可視化します。 backstage-community-plugin-sonarqube : SonarQubeのコード品質分析結果や各種メトリクスをフロントエンドで表示するプラグインです。 backstage-community-plugin-sonarqube-backend-dynamic : SonarQubeサーバーと動的に連携し、各プロジェクトの分析結果をバックエンドで取得・提供するモジュールです。 backstage-community-plugin-scaffolder-backend-module-sonarqube-dynamic : Scaffolderのテンプレート実行時に、SonarQubeによるコード品質チェックを自動化するバックエンドモジュールです。 app-configを変更する app-config-rhdh.yaml に以下のような設定を追記します。 proxy部分とsonarqube部分の2箇所になります。GitHub Actionsについては、app-configの追記は不要です。 app-config-rhdh.yaml kind : ConfigMap apiVersion : v1 metadata : name : app-config-rhdh namespace : rhdh annotations : rhdh.redhat.com/backstage-name : developer-hub data : app-config-rhdh.yaml : | app : ...omit... backend : ...omit... auth : ...omit... integrations : ...omit... signInPage : github catalog : ...omit... enabled : kubernetes : true argocd : true techdocs : true sonarqube : true # ここを追記 kubernetes : ...omit... argocd : ...omit... proxy : '/argocd/api' : target : ${ARGOCD_INSTANCE_URL}/api/v1/ changeOrigin : true secure : false headers : Cookie : $env : ${ARGOCD_AUTH_TOKEN} # ここから '/sonarqube' : target : ${SONARQUBE_URL}/api allowedMethods : [ 'GET' ] auth : "${SONARQUBE_USER_TOKEN}:" # ここまで追記 techdocs : ...omit... # ここから下を追記 sonarqube : baseUrl : ${SONARQUBE_URL} apiKey : ${SONARQUBE_USER_TOKEN} Secretを設定する 最後に必要な変数をSecretに設定していきます。その前にSonarqubeの設定に必要な値を取得しましょう。 Sonarqubeにアクセスして、右上のユーザーアイコンから My Account を選択します。 Security タブからユーザーTokenを作成します。Token名は rhdh としました。 ここで表示されたTokenをSecretに設定します。 secrets-rhdh.yaml apiVersion : v1 kind : Secret metadata : name : secrets-rhdh namespace : rhdh stringData : ...omit... SONARQUBE_URL : "https://<sonarqubeのURL>" SONARQUBE_USER_TOKEN : "<sonarqubeのユーザーToken>" 3つのファイルの反映 変更した3つのファイルをデプロイします。 oc apply -f app-config-rhdh.yaml -f secrets-rhdh.yaml -f dynamic-plugins-rhdh.yaml これでSonarqubeに関するDeveloper Hubの連携設定が完了しました。 AWS ECRの認証設定を行う 次にAWS ECRに対するPullとPushを行うための認証設定を行います。 今回のGolden Pathでは、GitHub ActionsのWorkflow内でECRへの コンテナイメージPush を行います。そして、ROSA上にデプロイするために 特定のサービスアカウントでECRからイメージをPull する必要があります。この2つのアクセスを実現するための設定をここでは行います。 実装イメージは以下のとおりです。 IAMポリシーの作成 ECRへPullとPushを行うためのポリシーを登録します。 push-pull-ecr-policy.json { " Version ": " 2012-10-17 ", " Statement ": [ { " Sid ": " PushPullECR ", " Effect ": " Allow ", " Action ": [ " ecr:GetAuthorizationToken ", " ecr:BatchCheckLayerAvailability ", " ecr:GetDownloadUrlForLayer ", " ecr:BatchGetImage ", " ecr:PutImage ", " ecr:InitiateLayerUpload ", " ecr:UploadLayerPart ", " ecr:CompleteLayerUpload ", " ecr:CreateRepository ", " ecr:DescribeRepositories ", " ecr:DeleteRepository ", " ecr:SetRepositoryPolicy " ] , " Resource ": " * " } ] } 以下のコマンドでIAMポリシーを作成します。 aws iam create-policy --policy-name PushPullECRPolicy --policy-document file://push-pull-ecr-policy.json GitHub Actions用IAMロールの作成 【第6回】TechDocsを作成・登録しよう で作成したOIDC Providerの情報を使って、GitHub Actions上からECRへイメージをPushするために利用するIAMロールを作成します。 aws iam create-role --role-name GitHubActionsPushECRRole --assume-role-policy-document file://github-assume-role-policy.json IAMロールとIAMポリシーを紐づけます。 aws iam attach-role-policy --role-name GitHubActionsPushECRRole --policy-arn arn:aws:iam:: < AWSアカウントID > :policy/PushPullECRPolicy これでGitHub Actions側に必要なIAMの準備は完了しました。 次にROSA側のIAMの準備です。 ECR Secret Operatorのインストール Amazon ECRのプライベートリポジトリからコンテナイメージを取得する際にはAmazon IAMによる認証が必要ですが、認証トークンの有効期間は12時間であり、一定時間ごとに再度トークンを取得する必要があります。その取得・更新を自動化するためのOperatorとして提供されているのがECR Secret Operatorです。 このOperatorはコミュニティプラグインのためRed Hatからの正式なサポートが提供されていませんが、ECRの認証を効率化するために有効なツールですので、今回はこちらを使用していきます。 コンソール上でさくっとインストールしていきましょう。Operator Hubから検索をかけて、該当のOperatorを選択します。 特に設定を変更する必要はなく、すべてデフォルトでインストールしていきます。 すると ecr-secret-operator というNamespaceにOperatorがインストールされます。 このOperatorは、 Secret というカスタムリソース（名前が一緒でややこしいですが）をデプロイすると、その情報を元にECRの認証情報（.dockerconfigjson）の通常の Secret を自動生成します。この自動生成された Secret はECR Secret Operatorと Secret によって管理され、認証情報がExpireしたときに新しい認証情報に自動更新されます。 ECR Secret Operatorに設定するIAMロールの作成 次にこのOperatorがECRの認証トークンを取得するためのIAMロールを作成します。このIAMロールによって、ECRから有効な認証情報（トークン）を取得できるようになります。 実はこのECRの認証トークンを取得するための権限　（ecr:GetAuthorizationToken）は、先ほどのIAMポリシーに付与してあるので、このポリシーをそのまま利用します。そのため、まずは信頼ポリシーを設定するjsonファイルから作成を開始します。 rosa-ecr-assume-role-policy.json { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " Federated ": " arn:aws:iam::<AWSアカウントID>:oidc-provider/<OIDCプロバイダー名> " } , " Action ": " sts:AssumeRoleWithWebIdentity ", " Condition ": { " StringEquals ": { " <OIDCプロバイダー名>:sub ": " system:serviceaccount:ecr-secret-operator:ecr-secret-operator-controller-manager " } } } ] } このjsonを使ってIAMロールを作成します。 aws iam create-role --role-name ROSAPullECRRole --assume-role-policy-document file://rosa-ecr-assume-role-policy.json IAMロールとIAMポリシーを紐づけます。 aws iam attach-role-policy --role-name ROSAPullECRRole --policy-arn arn:aws:iam:: < AWSアカウントID > :policy/PushPullECRPolicy これで先ほどの図の青枠の部分まで設定が完了しました。これ以降の部分は後半のGolden Pathによって実装されます。 GitHub Actionsで利用する環境変数・シークレットの登録 最後に、Golden Path内のGitHub Actionsで利用する環境変数・シークレットをOrganizationに登録していきます。 登録する変数の詳細な説明は、後編のCIパイプライン作成の部分で行います。ここでは一旦記載されている内容を登録していきましょう。 登録する環境変数とシークレットは以下の通りです。 Secret ARGOCD_PASSWORD ArgoCDのadminユーザーのパスワード ARGOCD_USERNAME admin GITHUBAPP_ID 第2回で登録したGitHub AppのApp ID GITHUBAPP_PRIVATE_KEY 第2回で登録したGitHub AppのPrivate Key SONARQUBE_USER_TOKEN この記事の前半で作成したSonarqubeのユーザートークン Variables ARGOCD_INSTANCE_URL ArgoCDのURL (https://は入れない) SONARQUBE_URL SonarqubeのURL (https://を入れる) これでGitHub Actionsで利用する変数の登録が完了しました。一旦前編はここで終了です。 おわりに 今回はGolden Path作成に向けた環境の事前準備を行いました。 次回は本題であるGolden Pathの中身を実装していきます。乞うご期待！

こんにちは、レッドハットでソリューションアーキテクトをしている清水です。 はじめに 2025/2/25 に GA された OpenShift 4.18 では、ユーザーが OpenShift 上に自由に L2/L3 ネットワークを構築することのできる User Defined Network (UDN) 機能が GA されました。[1] この User Defined Network (UDN) 機能を利用することにより、テナント毎にネットワークを分離することができ、OpenShift 上の仮想ネットワークの柔軟性やセキュリティの向上をもたらすことができます。 本記事では、User Defined Network (UDN) 機能において想定されるユースケースの中から、テナント毎に L3 ネットワークを分離するシンプルな構成を設定し、ネットワーク分離が行われたことの動作確認までを行います。 User Defined Network (UDN) とは [2] User Defined Network (UDN) 機能とは、文字通りユーザーが OpenShift 上に L2 または L3 の仮想ネットワークを構築することのできる機能です。 デフォルトのネットワーク設定に加えて、ユーザーが独自のネットワークを定義し、複数のネットワークインターフェースを持つ Pod を作成することができます。 これにより、特定のネットワーク要件を持つアプリケーションやサービスを柔軟にサポートできます。​ UDN 機能を利用することで、以下のようなシナリオに対応可能です： ネットワーク分離：​異なるセキュリティ要件やトラフィックタイプに応じて Pod 間の通信を分離できます。 高性能ネットワーキング：​SR-IOV（Single Root I/O Virtualization）などの技術を使用して、高スループットかつ低レイテンシのネットワーク接続を実現できます。​ 仮想化環境からの移行：​特定のネットワーク設定を必要とする仮想マシンの OpenShift への移行を容易にします。 UDN 機能を実現するために、OpenShift は Multus CNI（Container Network Interface）プラグインを活用しています。 ​Multus は、各 Pod に複数のネットワークインターフェースを割り当てることを可能にし、これにより Pod が複数のネットワークに接続できるようになります。 User Defined Network (UDN) の設定手順 本記事にて動作確認するユースケース 本記事では、UDN を Primary ネットワークとして設定し、テナント毎にネットワークが分離されていることを確認します。 Namespace 作成時に k8s.ovn.org/primary-user-defined-network ラベルを設定 作成する UDN を Primary ネットワークとして指定するには、Namespace (Project) の作成時に k8s.ovn.org/primary-user-defined-network ラベルを付与する必要があります。 以下のようなコマンドを実行することにより、Namespace (Project) の作成時にラベルを設定してください。 $ cat << EOF | oc apply -f - apiVersion: project.openshift.io/v1 kind: Project metadata: name: green labels: k8s.ovn.org/primary-user-defined-network: "" EOF $ cat << EOF | oc apply -f - apiVersion: project.openshift.io/v1 kind: Project metadata: name: blue labels: k8s.ovn.org/primary-user-defined-network: "" EOF $ cat << EOF | oc apply -f - apiVersion: project.openshift.io/v1 kind: Project metadata: name: yellow labels: k8s.ovn.org/primary-user-defined-network: "" EOF $ cat << EOF | oc apply -f - apiVersion: project.openshift.io/v1 kind: Project metadata: name: purple labels: k8s.ovn.org/primary-user-defined-network: "" EOF ClusterUserDefinedNetwork カスタムリソースの適用 UDN を実現するためのカスタムリソースには、 UserDefinedNetwork (Namespace scoped) と ClusterUserDefinedNetwork (Cluster Scoped) の2種類が存在します。 本記事にて動作確認するユースケースでは、一つのテナントに複数の Namespace (Project) が含まれることから、Cluster Scoped である ClusterUserDefinedNetwork カスタムリソースを利用します。 テナント berlin にはサブネットに 10.100.0.0/16 を指定し、テナント munich のサブネットには 10.200.0.0/16 を指定するため、以下のような2つのカスタムリソースのマニフェストを適用します。 apiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: name: berlin spec: namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: - green - blue network: topology: Layer3 layer3: role: Primary subnets: - cidr: 10.100.0.0/16 hostSubnet: 24 apiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: name: munich spec: namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: - yellow - purple network: topology: Layer3 layer3: role: Primary subnets: - cidr: 10.200.0.0/16 hostSubnet: 24 動作確認 動作確認用アプリケーションのデプロイ テナント毎にネットワーク分離が行われたことの動作確認のため、動作確認用のアプリケーションとして Apache httpd を用いた Web サーバーをデプロイします。 $ oc new-app openshift/httpd -n green $ oc new-app openshift/httpd -n blue $ oc new-app openshift/httpd -n yellow $ oc new-app openshift/httpd -n purple UDN にて設定されたIPアドレスの確認 以下のようなコマンドを実行することにより、UDN にて設定されたIPアドレスを確認します。 以下の実行結果から、Namespace green の Pod には 10.100.0.12 が割り当てられ、Namespace blue の Pod には 10.100.0.15 が割り当てられ、Namespace yellow の Pod には 10.200.0.5 が割り当てられていることが分かります。 $ oc -n green get po -oyaml | grep -A18 k8s.v1.cni.cncf.io/network-status k8s.v1.cni.cncf.io/network-status: |- [{ "name": "ovn-kubernetes", "interface": "eth0", "ips": [ "10.132.0.52" ], "mac": "0a:58:0a:84:00:34", "dns": {} },{ "name": "ovn-kubernetes", "interface": "ovn-udn1", "ips": [ "10.100.0.12" ], "mac": "0a:58:0a:64:00:0c", "default": true, "dns": {} }] $ oc -n blue get po -oyaml | grep -A18 k8s.v1.cni.cncf.io/network-status k8s.v1.cni.cncf.io/network-status: |- [{ "name": "ovn-kubernetes", "interface": "eth0", "ips": [ "10.132.0.53" ], "mac": "0a:58:0a:84:00:35", "dns": {} },{ "name": "ovn-kubernetes", "interface": "ovn-udn1", "ips": [ "10.100.0.15" ], "mac": "0a:58:0a:64:00:0f", "default": true, "dns": {} }] $ oc -n yellow get po -oyaml | grep -A18 k8s.v1.cni.cncf.io/network-status k8s.v1.cni.cncf.io/network-status: |- [{ "name": "ovn-kubernetes", "interface": "eth0", "ips": [ "10.132.0.56" ], "mac": "0a:58:0a:84:00:38", "dns": {} },{ "name": "ovn-kubernetes", "interface": "ovn-udn1", "ips": [ "10.200.0.5" ], "mac": "0a:58:0a:c8:00:05", "default": true, "dns": {} }] 動作確認：アクセス成功パターン (green -> blue) Namespace green にある Pod から、同じ berlin テナントに属する Namespace blue の Pod ( 10.100.0.15 ) に対してアクセスできることを確認します。 以下のコマンド実行例では、デプロイした動作確認用アプリケーションの問題からレスポンスコード 403 を返していますが、同じテナント内の Namespace の Pod に対してアクセスに成功し、レスポンスが返ってきていることが分かります。 $ oc -n gree rsh httpd-6f554fd6cb-cxz57 curl 10.100.0.15:8080 -v -o /dev/null * Rebuilt URL to: 10.100.0.15:8080/ * Trying 10.100.0.15... * TCP_NODELAY set % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 10.100.0.15 (10.100.0.15) port 8080 (#0) > GET / HTTP/1.1 > Host: 10.100.0.15:8080 > User-Agent: curl/7.61.1 > Accept: */* > < HTTP/1.1 403 Forbidden < Date: Fri, 28 Feb 2025 06:22:44 GMT < Server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k < Last-Modified: Mon, 12 Jul 2021 19:36:32 GMT < ETag: "133f-5c6f23d09f000" < Accept-Ranges: bytes < Content-Length: 4927 < Content-Type: text/html; charset=UTF-8 < { [3758 bytes data] 100 4927 100 4927 0 0 801k 0 --:--:-- --:--:-- --:--:-- 801k * Connection #0 to host 10.100.0.15 left intact 動作確認：アクセス失敗パターン (green -> yellow) 次に、Namespace green にある Pod から、異なるテナントに属する Namespace yellow の Pod ( 10.200.0.5 ) に対して、ネットワークが期待した通りに分離されアクセスできないことを確認します。 以下のコマンド実行例の通り、アクセスできずにコネクションタイムアウト (Connection timed out) が発生したことが分かります。 $ oc -n green rsh httpd-6f554fd6cb-cxz57 curl 10.200.0.5:8080 -v -o /dev/null * Rebuilt URL to: 10.200.0.5:8080/ * Trying 10.200.0.5... * TCP_NODELAY set % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:02:10 --:--:-- 0* connect to 10.200.0.5 port 8080 failed: Connection timed out * Failed to connect to 10.200.0.5 port 8080: Connection timed out * Closing connection 0 curl: (7) Failed to connect to 10.200.0.5 port 8080: Connection timed out command terminated with exit code 7 さいごに 本記事では、テナント毎に L3 ネットワークを分離し、かつ Primary ネットワークとして設定するシンプルなユースケースの動作確認を行いました。 しかし、UDN では L3 だけでなく L2 ネットワークを構築すること、Primary ネットワークだけでなく Secondory ネットワークとして設定すること、Secondary ネットワークにて localnet を設定することなどの柔軟な設定を行うことができます。 OpenShift 4.18 と同時に GA されたばかりの機能ですが、デフォルトの OpenShift のネットワークでは満たすことができないネットワーク要件がある場合など、UDN の機能に興味をお持ちでしたら是非ドキュメントをご覧になってください。 参考 [1] https://docs.openshift.com/container-platform/4.18/release_notes/ocp-4-18-release-notes.html#ocp-release-notes-networking-user-defined-network-segmentation_release-notes [2] https://docs.openshift.com/container-platform/4.18/networking/multiple_networks/understanding-multiple-networks.html