検索
サポートコンソール開発者トライアルの開始お問い合わせ

Red Hat ソフトウェア認定ワークフローガイド

download PDF
Red Hat Software Certification 8.64

Red Hat Enterprise Linux および Red Hat OpenShift 向け

Red Hat Customer Content Services

概要

Red Hat ソフトウェア認定ワークフローガイドは、共同でサポートされるお客様の環境で Operator を利用して、Red Hat OpenShift プラットフォームに独自のアプリケーション、管理アプリケーション、またはソフトウェアをデプロイする Red Hat パートナー向けの認定プロセスを概説します。
バージョン 8.64 は 2023 年 6 月 27 日に更新されました。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメントにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。多様性を受け入れる用語に変更する取り組みの詳細は、Red Hat の CTO、Chris Wright のメッセージ を参照してください。

第1章 Red Hat ソフトウェア認定の概要

このガイドを使用して、Red Hat Enterprise Linux および RedHat OpenShift プラットフォームでソフトウェアアプリケーション製品を認定および配布します。

1.1. Red Hat ソフトウェア認定を理解する

Red Hat ソフトウェア認定プログラムは、デプロイメントプラットフォームとして Red Hat Enterprise Linux および Red Hat OpenShift を対象とするソフトウェアアプリケーション製品の互換性を保証します。

プログラムには 4 つの主要な要素があります。

  • プロジェクト: 認定リクエストの進捗状況とステータスが追跡および報告されるオンラインワークフロー。
  • テストスイート: 認定を受けているソフトウェアアプリケーション製品の統合パイプラインとして実装されたテスト。

  • 公開:

    • コンテナー化されていない製品: 認定された従来のコンテナー化されていない製品は、Red Hat Ecosystem Catalog に公開されています。
    • コンテナー: 認定されたコンテナーは、Red Hat Ecosystem Catalog に公開されています。
    • Operator: 認定 Operator は、Red Hat Ecosystem Catalog および組み込み OperatorHub で公開されており、IBM が提供する Red Hat に公開するオプションがあります。
    • Helm チャート: 認定された Helm チャートは Red Hat Ecosystem Catalog で公開されます。
    • クラウドネイティブネットワーク機能 (CNF): ベンダーによって検証および認定された CNF プロジェクトは製品リストに添付され、Red Hat Red Hat Ecosystem Catalog で公開されます。
  • サポート 認定されたソフトウェアアプリケーション製品を導入する際のお客様の成功を確実にするための、お客様と Red Hat の間の共同サポート関係。

1.2. Red Hat ソフトウェア認定のメリット

Red Hat ソフトウェア認定プログラムは、お客様とパートナーの両方にメリットをもたらします。

プログラムの主な利点は次のとおりです。

  • Red Hat パートナーが、自社の製品が、お客様が依存する相互運用性、セキュリティー、およびライフサイクル管理の Red Hat の基準を引き続き満たしていることを確認および監視する方法を提供します。
  • OpenShift Container Platform ユーザーが、OperatorHub と Red Hat Marketplace の両方を介して OpenShift クラスターに認定ソフトウェアをより簡単にインストールできるようにします。
  • お客様および潜在的なお客様が、Red Hat Ecosystem Catalog に公開されているソフトウェアを検索および検出できるようにします。
  • Red Hat の組み込み OperatorHub および IBM が提供する Red Hat Marketplace を通じて、Operator 向けの配布チャネルを提供します。

この認定を通じて、お客様とそのオープンハイブリッドクラウドジャーニーに焦点を当てた他の ISV パートナーと協力して、製品の大幅な拡張をサポートするためのアライアンスを作成できます。

1.3. サポートの利用とフィードバックの提供

Red Hat 製品、Red Hat 認定ツールセット、またはこのドキュメントに記載されている手順で認定プロセス中に問題が発生した場合は、 Red Hat カスタマーポータル にアクセスして、RedHat 製品のドキュメントならびに、RedHat 製品に関するソリューションおよび技術文書を参照してください。

1.3.1. フィードバックを受ける

次の場合のサポートケースを開くこともできます。

  • 問題を報告し、認定プロセスに関するヘルプを取得する。
  • 認定ツールセットおよびドキュメントのフィードバックおよび機能強化のリクエストを送信する。
  • 製品/アプリケーションが認定されている Red Hat 製品に関するサポートを受ける。
注記

Red Hat の製品サポートを受けるには、必要な製品エンタイトルメントまたはサブスクリプションが必要です。これらは、パートナープログラムおよび認定プログラムのメンバーシップとは別のものである場合があります。

1.3.2. サポートケースを開く

サポートケースを開くには、How do I open and manage a support case を参照してください。

認定の問題についてサポートケースを開くには、次のフィールドに特に注意して、Partner Acceleration Desk のサポートケースフォームに記入してください。

  • Issue Category から ProductCertification を選択します。
  • 製品フィールドから、必要な製品を選択します。
  • 製品バージョン フィールドから、製品またはアプリケーションが認定されているバージョンを選択します。
  • Problem Statement フィールドに、以下の形式で、問題のステートメント、問題の発行、またはフィードバックを入力します。

{Partner Certification} (The Issue/Problem or Feedback)

  • (The Issue/Problem or Feedback) に、認定プロセス/Red Hat 製品の問題や、認定ツールセットまたはドキュメントに関するフィードバックを入力してください。 

    For example: {Partner Certification} Error occurred while submitting certification test results using the Red Hat Certification application.
注記

Red Hat では、Red Hat 認定エンジニアまたは同等の経験を有するユーザーが、認定プロセスを開始することを推奨しています。

関連情報

第2章 認定パートナーのオンボーディング

新しいパートナーの場合は、Red Hat Partner Connect ポータルを使用して新しいアカウントを作成します。現在のパートナーの場合は、既存の Red Hat アカウントを使用して、製品の認定のために Red Hat とのオンボーディングの手続きをします。

2.1. 既存の認定パートナーのオンボーディング

既存のパートナーとしては、次のようなパートナーが考えられます。

  • 1 対多の EPM プログラムのメンバーで、EPM チームである程度の代表権を持っていますが、認定プロセスについては支援を受けていません。

    または、

  • 認定要求に関する質問など、パートナーの管理に割り当てられた専用 EPM チームメンバーを使用して、従来の方法で EPM チームによって完全に管理されるメンバーです。
注記

会社に既存の Red Hat アカウントがあると思われるが、会社の組織管理者が誰であるかがわからない場合は、connect@redhat.com に電子メールを送信して、会社の既存のアカウントに追加してください。

前提条件

既存の Red Hat アカウントがある。

手順

  1. Red Hat Partner Connect にアクセスし、Log in をクリックします。
  2. Certified technology portal セクションから、Log in for technology partner をクリックします。

  3. Red Hat ログインまたはメールアドレスを入力し、Next をクリックします。

    次に、以下のオプションのいずれかを使用します。

    1. 企業用シングルサインオンでログイン
    2. Red Hat アカウントへのログイン

  4. ヘッダーのメニューバーからアバターをクリックし、アカウントの詳細を表示します。

    1. アカウント番号がアカウントに関連付けられている場合は、Red Hat Partner Connect にログインし、認定プロセスに進みます。

    2. アカウント番号がアカウントに関連付けられていない場合は、まず Red Hat グローバルカスタマーサービスチーム に連絡して、新しいアカウント番号作成のリクエストを作成してください。

      その後、Red Hat Partner Connect にログインし、認定プロセスを続行します。

2.2. 新しい認定パートナーのオンボーディング

新しい Red Hat アカウントの作成は、新しい認定パートナーのオンボーディングの最初のステップです。

  1. Red Hat Partner Connect にアクセスし、Log in をクリックします。
  2. Certified technology portal セクションから、Log in for technology partner をクリックします。
  3. Register for a Red Hat account をクリックします。

  4. 以下の詳細を入力して、新しい Red Hat アカウントを作成します。

    1. Account Type フィールドで Corporate を選択します。

      企業タイプのアカウントを作成していて、アカウント番号が必要な場合は、Red Hat グローバルカスタマーサービス チームにお問い合わせください。

注記

個人アカウントではなく、企業アカウントを作成するようにしてください。この手順で作成したアカウントは、認定リクエストを使用する際に Red Hat Ecosystem Catalog にサインインするために使用します。

  1. Red Hat のログインとパスワードを選択します。
重要

ログイン ID が複数のアカウントに関連付けられている場合は、ログイン時に問題が発生する可能性があるため、連絡先メールアドレスをログイン ID として使用しないでください。また、作成後にログイン ID を変更することはできません。

  1. Personal information と Company information を入力します。

  2. Create My Account をクリックします。

    新しい Red Hat アカウントが作成されます。Red Hat Partner Connect にログインし、認定プロセスを続行します。

パート I. コンテナー化されていない製品の認定

第3章 コンテナー化されていない製品認定の概要

従来のコンテナー化されていない製品の Red Hat Software 認定プログラムは、独立系ソフトウェアベンダー (ISV) が、共同でサポートされているお客様の環境で Red Hat Enterprise Linux (RHEL) を実行しているシステムおよびサーバー環境でアプリケーションソフトウェアを構築、認定、および配布するのに役立ちます。RHEL に関する高度な実務知識が必要です。

第4章 コンテナー化されていないアプリケーションの認定ワークフロー

注記

Red Hat では、Red Hat 認定エンジニアまたは同等の経験を有するユーザーが、認定プロセスを開始することを推奨しています。

次の図は、コンテナー化されていないアプリケーションの認定ワークフローの概要を示しています。

図4.1 コンテナー化されていないアプリケーションの認定ワークフロー

コンテナー化されていないアプリケーションの認定ワークフローを視覚的に表したフローチャートについては、次の手順で説明しています。

タスクの概要

認定ワークフローには、次の 3 つの主要な段階が含まれます。

  1. 「認定のオンボーディングと最初のプロジェクトの開始」
  2. 「認定テスト」
  3. 「認定アプリケーションの公開」

4.1. 認定のオンボーディングと最初のプロジェクトの開始

前提条件

特定の認定テスト要件に加えて、対象の Red Hat プラットフォームでの製品の機能を検証します。対象の Red Hat プラットフォームで製品を実行した結果、標準を下回るエクスペリエンスが得られた場合は、認定前に問題を解決する必要があります。

Red Hat Partner Acceleration Desk (PAD) は、製品およびテクノロジーレベルのパートナーヘルプデスクサービスであり、(将来の) テクノロジーパートナーが、Red Hat の提供、パートナープログラム、製品認定、エンゲージメントプロセスなどに関する非技術的な質問を一元的に行える場所です。

PAD - PAD ケースの作成方法と管理方法 を参照して、PAD チケットを作成します。

Partner Subscriptions プログラムを通じて、Red Hat は、対象の Red Hat プラットフォームで製品を検証するために使用できる無料の非再販ソフトウェアサブスクリプションを提供します。プログラムへのアクセスをリクエストするには、Partner Subscriptions サイトの指示に従ってください。

手順

認定のオンボーディングに記載されている手順を実行します。

  1. Red Hat Connect for Technology パートナープログラムに参加してください。
  2. コンテナー化されていないソフトウェア製品を追加して認定します。
  3. 会社プロファイルに記入します。
  4. 認定前チェックリストに記入します。
  5. 製品用のコンテナー化されていないアプリケーションプロジェクトを作成します。

関連情報

最初のアプリケーションプロジェクトを作成するための詳細な手順については、アプリケーションプロジェクトの作成 を参照してください。

4.2. 認定テスト

次の概要手順に従って、認定テストを実行します。

  • Red Hat Certification portal にログインします。
  • テスト計画をダウンロードします。
  • テストを実行するためのテスト対象システム (SUT) を設定します。
  • テスト計画を SUT にダウンロードします。
  • システムで認定テストを実行します。
  • テスト結果を確認し、認定ポータルにアップロードします。

関連情報

認定テストの詳細な手順については、コンテナー化されていないアプリケーションのテスト向けテスト環境のセットアップ を参照してください。

4.3. 認定アプリケーションの公開

すべての認定チェックを正常に完了すると、テスト結果を Red Hat に送信できます。検証が成功すると、Red Hat Ecosystem Catalog で製品を公開できます。

関連情報

アプリケーションの公開に関する詳細な手順については、認定済みアプリケーションの公開 を参照してください。

第5章 コンテナー化されていないアプリケーションプロジェクトの作成

手順

次の手順に従って、コンテナー化されていないアプリケーションプロジェクトを作成します。

  1. Red Hat Partner Connect ポータル にログインします。

    パートナーポータルへのアクセス Web ページが表示されます。

  2. 認定テクノロジーポータル タイルに移動し、テクノロジーパートナーのログイン をクリックします。

  3. ログイン資格情報を入力し、ログイン をクリックします。

    Red Hat Partner Connect の Web ページが表示されます。

  4. ページヘッダーで、製品認定 を選択し、認定プロジェクトの管理 をクリックします。

    My Work Web ページには、製品リスト と利用可能な場合 認定プロジェクト が表示されます。

  5. Create Project をクリックします。
  6. What platform do you want to certify? ダイアログボックスで、目的のプラットフォームを選択し、Next をクリックします。たとえば、コンテナー化されていないプロジェクトを作成するには、Red Hat Enterprise Linux のラジオボタンを選択します。
  7. What do you want to certify? ダイアログボックスで、Non-containerized application ラジオボタンを選択し、Next をクリックします。

  8. Create non-containerized Red Hat Enterprise Linux project Web ページで、以下の詳細を指定してプロジェクトを作成します。

    重要

    プロジェクトの作成後に RHEL のバージョンを変更することはできません。

    1. プロジェクト名 - プロジェクト名を入力します。この名前は公開されておらず、内部使用のみを目的としています。
    2. Red Hat Enterprise Linux (RHEL) バージョン - コンテナー化されていないアプリケーションを認定する特定の RHEL バージョンを選択します。
  9. Create project をクリックします。

第6章 コンテナー化されていないアプリケーションプロジェクトの設定

コンテナー化されていないプロジェクトが作成されると、新しく作成されたアプリケーションプロジェクトの Web ページが表示されます。

新しいアプリケーションプロジェクトの Web ページは、以下のタブで構成されています。

  • Overview - 認定前チェックリストが含まれています。
  • Settings - 設定済みプロジェクトの詳細を表示できます。

さらに、アプリケーションプロジェクトで次のアクションを実行するには、コンテナー化されていないアプリケーションプロジェクトの Web ページで Actions メニューをクリックします。

6.1. 認定前チェックリストの記入

コンテナー化されていないアプリケーションを認定する場合は、認定前チェックリストを完了してから、アプリケーションプロジェクトを公開する必要があります。プロジェクトの Overview タブには、認定前チェックリストが含まれています。認定前チェックリストは、アプリケーションプロジェクトを認定および公開するために完了する必要のある一連のタスクで構成されています。

アプリケーションプロジェクトを公開する前に、チェックリストの以下のタスクを実行します。

  1. 認定に関する詳細の入力
  2. 会社プロファイルを完了する
  3. Red Hat Enterprise Linux での製品機能の検証
  4. 完了済み製品リストを添付する

6.1.1. 認定に関する詳細の入力

  1. Provide details about your certification タイルに移動して、カタログに表示されるプロジェクトの詳細を設定します。これにより、ユーザーはアプリケーションイメージをプルできるようになります。
  2. Review をクリックします。xref:[設定] タブに移動します。
  3. 必要なプロジェクトの詳細を編集します。
  4. Save をクリックします。

6.1.2. 会社プロファイルを完了する

会社のプロファイルが最新の状態であることを確認してください。この情報は、認定済みのコンテナー化されていないアプリケーション製品とともにカタログに公開されます。

情報を確認するには、以下を実行してください。

  1. Complete your company profile タイルに移動します。
  2. チェックリストの Review をクリックします。
  3. 変更を加えるには、Edit をクリックします。
  4. 詳細を更新したら、Save をクリックします。

6.1.3. Red Hat Enterprise Linux での製品機能の検証

この機能により、以下を実行できるようになります。

  • Red Hat Certification Tool のローカルでの実行
  • テスト計画のダウンロード
  • テスト結果の Red Hat 認定チームとの共有
  • 認定チームとのやりとり (必要な場合)

Red Hat Enterprise Linux で製品の機能を検証するには、以下を行います。

  1. Validate the functionality of your product on Red Hat Enterprise Linux タイルに移動し、Start をクリックします。Red Hat Certification ポータル で新しいプロジェクトが作成され、適切なプロジェクトポータルページにリダイレクトされます。

6.1.4. 完了済み製品リストを添付する

この機能を使用すると、新しい製品リストを作成するか、新しいプロジェクトの既存の RHEL 製品リストにプロジェクトを添付することができます。

  1. Attach a completed product listing に移動します。
  2. Select method ドロップダウンメニューから、Attach or edit を選択します。Attach product listing ページが表示されます。

  3. プロジェクトを既存の製品リストにアタッチするか、新しい製品リストを作成するかを決定します。

    1. プロジェクトを既存の製品リストに添付するには:

      1. Related product listing セクションから、Select a product listing ドロップダウン矢印をクリックして、必要な製品リストを選択します。
      2. Save をクリックします。

    2. 新しい商品リストを作成するには:

      1. Create new product listing をクリックします。
      2. Product Name テキストボックスに、必要な製品名を入力します。
      3. Save をクリックします。
  4. Select method ドロップダウンメニューから、View product listing をクリックして、新しい製品リストに移動し、必要な製品リストの詳細をすべて入力します。
  5. Save をクリックします。
注記

認定申請書を提出する前に、Red Hat Enterprise Linux で製品の機能を検証する ステップ以外の認定前チェックリストのすべての項目を完了してください。

すべての手順を完了すると、タイルの横に緑色のチェックマークが表示され、設定が完了したことを示します。

6.2. プロジェクト設定の管理

プロジェクトの詳細は、Settings タブから確認および編集することができます。

次のフィールドに必要なプロジェクトの詳細を入力します。

  • プロジェクト名 - プロジェクト名を入力します。この名前は公開されておらず、内部使用のみを目的としています。
  • Red Hat Enterprise Linux (RHEL) バージョン - コンテナー化されていないアプリケーションを認定する RHEL バージョンを指定します。
重要

プロジェクトの作成後に RHEL のバージョンを変更することはできません。

  • テクニカルサポートの電子メールアドレス - プロジェクトメンテナーの電子メールアドレスをコンマで区切って入力します。
  • Save をクリックします。
注記

アスタリスク * が付いているフィールドはすべて必須であり、認定を続行する前に入力を完了する必要があります。

第7章 コンテナー化されていないアプリケーションのテスト向けテスト環境のセットアップ

製品を認定するための最初のステップは、テストを実行できる環境をセットアップすることです。

テスト環境は、すべての認定テストが実行されるシステムで構成されます。

7.1. テスト対象システムとして動作するシステムのセットアップ

認定を必要とする製品がインストールまたは設定されているシステムは、テスト対象システム (SUT) と呼ばれます。

前提条件

  • SUT に RHEL バージョン 8 または 9 がインストールされている。便宜上、Red Hat は SUT のオペレーティングシステムをインストールするための キックスタートファイル を提供します。インストールプロセスを起動する前に、お使いのシステムに適したファイルに記載されている指示に従ってください。

手順

  1. Red Hat Certification リポジトリーを設定します。

    1. RHN の認証情報を使用して、Red Hat Subscription Management でシステムを登録します。 

      $ subscription-manager register

    2. お使いのシステムで利用可能なサブスクリプションの一覧を表示します。 

      $ subscription-manager list --available*
    3. Red Hat 認定 (RHEL Server 用) リポジトリーを提供するサブスクリプションを検索し、サブスクリプションとそのプール ID を書き留めます。

    4. システムにサブスクリプションを割り当てます。 

      $ subscription-manager attach --pool=<pool_ID>

      pool_ID をサブスクリプションのプール ID に置き換えます。

    5. Red Hat 認定チャンネルにサブスクライブします。

      1. RHEL 8 の場合: 

        $ subscription-manager repos --enable=cert-1-for-rhel-8-<HOSTTYPE>-rpms

        HOSTTYPE をシステムアーキテクチャーに置き換えます。システムアーキテクチャーを確認するには、以下を実行します。 

        $ uname -m

        以下に例を示します。 

        $ subscription-manager repos --enable=cert-1-for-rhel-8-x86_64-rpms

      2. RHEL 9 の場合: 

        $ subscription-manager repos --enable=cert-1-for-rhel-9-<HOSTTYPE>-rpms

        HOSTTYPE をシステムアーキテクチャーに置き換えます。システムアーキテクチャーを確認するには、以下を実行します。 

        $ uname -m

        以下に例を示します。 

        $ subscription-manager repos --enable=cert-1-for-rhel-9-x86_64-rpms

    6. ソフトウェアテストスイートパッケージをインストールします。 

      $ dnf install redhat-certification-software

第8章 Red Hat 認定ポータルからのテストプランのダウンロード

手順

  1. Red Hat Certification portal にログインします。
  2. 製品認定に関連するケース番号を検索してコピーします。
  3. Cases をクリックし、製品ケース番号を入力します。

  4. オプション: Test Plans をクリックします。

    テストプランには、テストの実行中にテストされるコンポーネントの一覧が表示されます。

  5. Download Test Plan をクリックします。

第9章 CLI を使用した認定テストの実行および結果ファイルのダウンロード

CLI を使用して認定テストを実行するには、テスト計画を SUT にダウンロードする必要があります。テストの実行後、結果をダウンロードして確認します。

9.1. CLI を使用した認定テストの実行

手順

  1. テストプランを SUT にダウンロードします。

  2. 次のコマンドを実行して、テストプランを使用するように認定パッケージに指示します。 

    # rhcert-provision <test-plan-doc>

  3. 以下のコマンドを実行します。 

    # rhcert-run

  4. プロンプトが表示されたら、yes または no を入力して、各テストを実行するかどうかを選択します。

    select を入力して、リストから特定のテストを実行することもできます。

9.2. 実行したテストプランの結果ファイルを確認してダウンロードする

手順

  1. 以下のコマンドを実行します。 

    # rhcert-cli save
  2. rhcert-cli save コマンドを使用して結果ファイルをローカルシステムにダウンロードします。

関連情報

認定テストを実行するための cockpit の設定と使用方法の詳細は、付録を 参照してください。

第10章 実行したテストプランの結果ファイルを Red Hat 認定ポータルにアップロードする

前提条件

  • SUT または Cockpit のいずれかからテスト結果ファイルをダウンロードしている

手順

  1. Red Hat Certification portal にログインします。

  2. ホームページで、検索バーに製品のケース番号を入力します。

    表示される一覧からケース番号を選択します。

  3. Summary タブの Files セクションで、Upload をクリックします。

Red Hat は、提出されたテスト結果ファイルを確認し、次のステップを提案します。

関連情報

詳細については、Red Hat Certification portal にアクセスしてください。

第11章 再認定

既存のパートナーとして、以下についてアプリケーションの再認定が必要です。

  • Red Hat Enterprise Linux のすべてのメジャーおよびマイナーリリースについて
  • アプリケーションのすべてのメジャーリリースとマイナーリリースについて
注記

アプリケーションの再認定を行うには、再認定のための新しい認定リクエストを作成する必要があります。

アプリケーションを再認定するには、Red Hat Certification ツールから 新しい認定リクエストを送信するか、Red Hat Partner Connect で新しいプロジェクトを作成します。SUT 上で認定テストを実行し、新規の認定と同様に通常の認定ワークフローへと進みます。

第12章 認定アプリケーションの公開

Red Hat の認定ポータル を介してテスト結果を提出すると、プロジェクト内でアプリケーションの脆弱性がスキャンされます。スキャンが完了すると、Product Listings ページでアプリケーションの Publish ボタンが有効になります。必要な情報をすべて入力した後、Publish ボタンをクリックすると、Red Hat Ecosystem Catalog でアプリケーションが利用できるようになります。

重要

Red Hat ソフトウェア認定は、選択したプラットフォームでのパートナー製品の機能またはパフォーマンスのテストを実施しません。認定候補製品の品質保証は、すべてパートナーの責任において行われるものとします。

付録A cockpit を使用した認定テストの実行

注記

cockpit を使用して認定テストを実行することは オプション となります。

次の手順に従い、cockpit を使用して認定テストを設定および実行します。

A.1. Cockpit を使用したシステムの設定とテストの実行

Cockpit を使用して認定テストを実行するには、まずテスト計画を SUT にアップロードする必要があります。テストの実行後、結果をダウンロードして確認します。

注記

必須ではありませんが、Red Hat では、認定プロセス用に Cockpit を設定して使用することを推奨しています。cockpit を設定すると、SUT での認定プロセスの管理および監視に非常に役立ちます。

A.1.1. Cockpit サーバーのセットアップ

Cockpit は、ユーザーフレンドリーな Web ベースのインターフェイスからシステムの設定を変更したり、システムのリソースを監視したりできる RHEL ツールです。

注記
  • SUT または新しいシステムで Cockpit をセットアップする必要があります。
  • Cockpit が SUT にアクセスできることを確認します。

前提条件

  • Cockpit サーバーに RHEL バージョン 8 または 9 がインストールされている。
  • システムに Cockpit プラグインがインストールされている。
  • Cockpit サービスが有効になっている。

手順

  1. Cockpit をインストールしたシステムにログインします。

  2. Red Hat 認定チームが指定する Cockpit RPM をインストールします。 

    # dnf install redhat-certification-cockpit

デフォルトでは、Cockpit はポート 9090 で実行されます。

関連情報

Cockpit のインストールおよび設定の詳細は、Cockpit の使用 および Introducing Cockpit を参照してください。

A.1.2. テスト対象システムの Cockpit への追加

テスト対象システム (SUT) を Cockpit に追加すると、パスワードなしの SSH を使用して通信できるようになります。

前提条件

  • SUT の IP アドレスまたはホスト名がある

手順

  1. ブラウザーに http://<Cockpit_system_IP>:9090/ を入力し、Cockpit Web アプリケーションを起動します。
  2. ユーザー名とパスワードを入力し、Login をクリックします。

  3. ログインしている cockpit ユーザー名の下矢印をクリックし、Add new host をクリックします。

    ダイアログボックスが表示されます。

  4. Host フィールドに、システムの IP アドレスまたはホスト名を入力します。
  5. User name フィールドに、このシステムに割り当てる名前を入力します。
  6. オプション: 追加されたホストに対して、事前定義された色を選択するか、任意の新しい色を選択します。
  7. Add をクリックします。
  8. Accept key and connect をクリックして、パスワードなしの SSH で Cockpit が SUT と通信できるようにします。
  9. Password を入力します。
  10. Authorize SSH Key チェックボックスを選択します。
  11. Log in をクリックします。

検証

左側のパネルで Tools →Red Hat Certification をクリックします。
追加したばかりの SUT が右側の Hosts セクションの下に表示されていることを確認します。

A.1.3. テスト計画を使用したテスト対象システムのテストへの準備

テスト対象システム (SUT) のプロビジョニングには、次の操作が含まれます。

  • Cockpit とのパスワードなしによる SSH 通信の設定
  • 認定の種類に応じた必要なパッケージのシステムへのインストール
  • 実行する最終的なテスト計画の作成。これは、Red Hat が提供するテスト計画とシステム要件の検出時に生成されたテストの両方から得られた一般的なテストのリストです。

たとえば、テスト計画がソフトウェア製品の認定用に設計されている場合は、必要なソフトウェアパッケージがインストールされます。

前提条件

  • Red Hat が提供するテスト計画をダウンロードしている

手順

  1. ブラウザーのアドレスバーに http://<Cockpit_system_IP>:9090/ を入力し、Cockpit Web アプリケーションを起動します。
  2. ユーザー名とパスワードを入力し、Login をクリックします。
  3. 左側のパネルで Tools →Red Hat Certification を選択します。
  4. Hosts タブをクリックしてから、テストを実行するテスト対象ホストをクリックします。

  5. Provision をクリックします。

    ダイアログボックスが表示されます。

    1. Upload をクリックして、新しいテストプランの .xml ファイルを選択します。Next をクリックします。アップロードに成功したというメッセージが表示されます。

      必要に応じて、以前にアップロードしたテストプランを再利用する場合は、もう一度選択して再アップロードします。

      注記

      認定プロセス中に、進行中の製品認定のために再設計されたテストプランを受け取った場合は、前のステップに従ってアップロードできます。ただし、続行する前に、ターミナルタブで rhcert-cli clean all を実行する必要があります。

    2. Role フィールドで、System under test を選択し、Submit をクリックします。デフォルトでは、ファイルはパス /var/rhcert/plans/<testplanfile.xml> にアップロードされます。

A.1.4. Cockpit を使用した認定テストの実行

前提条件

  • テスト対象システムを準備している

手順

  1. ブラウザーのアドレスバーに http://<Cockpit_system_IP>:9090/ を入力し、Cockpit Web アプリケーションを起動します。
  2. ユーザー名とパスワードを入力し、Login をクリックします。
  3. 左側のパネルで Tools →Red Hat Certification を選択します。
  4. Hosts タブをクリックし、テストを実行するホストをクリックします。

  5. Terminal タブをクリックして、Run を選択します。

    アップロードされたテストプランに基づいた推奨テストのリストが表示されます。実行する最終的なテストプランは、Red Hat が提供するテストプランと、システム要件を検出して生成したテストの両方から取得した一般的なテストのリストです。

  6. プロンプトが表示されたら、yes または no を入力して、各テストを実行するかどうかを選択します。

    select を入力して、リストから特定のテストを実行することもできます。

A.1.5. 実行したテストプランの結果ファイルを確認してダウンロードする

手順

  1. ブラウザーのアドレスバーに http://<Cockpit_system_IP>:9090/ を入力し、Cockpit Web アプリケーションを起動します。
  2. ユーザー名とパスワードを入力し、Login をクリックします。
  3. 左側のパネルで Tools →Red Hat Certification を選択します。

  4. Result Files タブをクリックして、生成されたテスト結果を表示します。

    1. オプション: Preview をクリックして、各テストの結果を表示します。
    2. 結果ファイルの横にある Download をクリックします。デフォルトでは、結果ファイルは /var/rhcert/save/hostname-date-time.xml として保存されます。

パート II. コンテナー認定

第13章 コンテナーの使用

13.1. コンテナーの紹介

コンテナーには、ライブラリー、フレームワーク、その他の追加の依存関係など、必要なすべてのコンポーネントが含まれています。これらのコンポーネントは、独自の実行可能ファイル内で 分離 され、他に依存していません。Red Hat コンテナー認定は、オペレーティングシステムとアプリケーション層の両方のサポートを保証します。Red Hat コンポーネントの脆弱性スキャンとヘルスグレーディングによってセキュリティーが強化され、Red Hat またはパートナーコンポーネントが更新されるたびにライフサイクルコミットメントが提供されます。

ただし、特権 モードで実行されているコンテナー、つまり特権コンテナーは、範囲を拡大し、ホストと対話してコマンドを実行したり、ホストのリソースにアクセスしたりします。たとえば、ホストにマウントされたファイルシステムの読み取りまたは書き込みを行うコンテナーは、特権モードで実行する必要があります。

特権コンテナーはセキュリティーリスクを引き起こす可能性があります。特権コンテナーが侵害されると、そのホストと環境全体の整合性も侵害される可能性があります。

さらに、コマンド、ライブラリー、ABI、API などのオペレーティングシステムインターフェイスが時間の経過とともに変更または非推奨になる可能性があるため、特権コンテナーはホストとの非互換性の影響を受けやすくなります。これにより、特権コンテナーが、サポートされていない方法でホストと対話する危険にさらされる可能性があります。

ポリシーガイドに記載されているように、Red Hat によって承認されない限り、認定プロセス中はコンテナーを非特権モードで実行する必要があります。

コンテナーが、お客様の環境内のサポートされているホスト上で実行できることを確認する必要があります。Red Hat は、互換性を最大限に高めるために、Red Hat 製品のパブリックベータまたは以前のバージョンで、コンテナーをテストできる継続的統合モデルを採用することを推奨しています。

13.2. コンテナー認定ワークフロー

注記

Red Hat では、Red Hat 認定エンジニアまたは同等の経験を有するユーザーが、認定プロセスを開始することを推奨しています。

次の図は、コンテナー認定ワークフローの概要を示しています。

図13.1 コンテナー認定ワークフロー

次の手順で説明するコンテナー認定ワークフローを視覚的に表したフローチャート。

タスクの概要

認定ワークフローには、次の 3 つの主要な段階が含まれます。

  1. 「認定のオンボーディングと最初のプロジェクトの開始」
  2. 「認定テスト」
  3. 「認定されたコンテナーの Red Hat Ecosystem Catalog での公開」

13.2.1. 認定のオンボーディングと最初のプロジェクトの開始

前提条件

特定の認定テスト要件に加えて、ターゲット Red Hat プラットフォームで製品の機能を確認します。ターゲット Red Hat プラットフォームで製品を実行すると標準以下のエクスペリエンスが得られる場合は、認定前に問題を解決する必要があります。

Red Hat Partner Acceleration Desk (PAD) は、製品およびテクノロジーレベルのパートナーヘルプデスクサービスであり、(将来の) テクノロジーパートナーが、Red Hat の提供、パートナープログラム、製品認定、エンゲージメントプロセスなどに関する非技術的な質問を一元的に行える場所です。

PAD - PAD ケースの作成方法と管理方法 を参照して、PAD チケットを作成します。

Partner Subscriptions プログラムを通じて、Red Hat は、対象の Red Hat プラットフォームで製品を検証するために使用できる無料の非再販ソフトウェアサブスクリプションを提供します。プログラムへのアクセスをリクエストするには、Partner Subscriptions サイトの指示に従ってください。

コンテナーイメージは、認定基準とポリシーを満たすように作成する必要があります。詳細は、イメージコンテンツの要件 を参照してください。

手順

コンテナー化されたソフトウェアを認定するには、次の概要手順に従います。

  1. Red Hat Partner Connect for Technology Partner Program に参加してください。
  2. プログラムの利用規約に同意します。
  3. 会社プロファイルに記入します。
  4. 目的のプラットフォームを選択して、認定プロジェクトを作成します。たとえば、Red Hat OpenShift を選択し、Container Image を選択します。
  5. 該当する場合は、コンテナーイメージのエクスポートコンプライアンスに関する質問を含む認定前チェックリストに記入します。

関連情報

最初のコンテナープロジェクトの作成に関する詳細な手順については、コンテナーアプリケーションプロジェクトの作成 を参照してください。

13.2.2. 認定テスト

次の概要手順に従って、認定テストを実行します。

  1. コンテナーイメージを作成します。
  2. コンテナーイメージを選択したレジストリーにアップロードします。任意のレジストリーを選択できます。
  3. Preflight 認定ユーティリティー をダウンロードします。
  4. コンテナーイメージでプリフライトを実行します。
  5. Red Hat パートナーコネクト で結果を送信します。

関連情報

認定テストの詳細な手順については、認定テストスイートの実行 を参照してください。

13.2.3. 認定されたコンテナーの Red Hat Ecosystem Catalog での公開

認定されたコンテナーイメージは、Red Hat Connect Image Registry を介してお客様に配信され、サポートされている Red Hat コンテナープラットフォームで実行できます。製品とそのイメージは、提供されたリスト情報を使用して Red Hat Container Catalog にリストされます。

関連情報

第14章 コンテナーアプリケーションプロジェクトの作成

前提条件

  • UBI または RHEL をベースイメージとして使用してコンテナーを構築します。
  • 選択したパブリックまたはプライベートレジストリーにコンテナーをアップロードします。

手順

次の手順に従って、コンテナーアプリケーションプロジェクトを作成します。

  1. Red Hat Partner Connect ポータル にログインします。

    パートナーポータルへのアクセス Web ページが表示されます。

  2. 認定テクノロジーポータル タイルに移動し、テクノロジーパートナーのログイン をクリックします。

  3. ログイン資格情報を入力し、ログイン をクリックします。

    Red Hat Partner Connect の Web ページが表示されます。

  4. ページヘッダーで、製品認定 を選択し、認定プロジェクトの管理 をクリックします。

    My Work Web ページには、製品リスト と利用可能な場合 認定プロジェクト が表示されます。

  5. Create Project をクリックします。
  6. 何を証明したいですか ? ダイアログボックスで、目的のプラットフォームを選択し、次へ をクリックします。たとえば、コンテナープロジェクトを作成するための Red Hat OpenShift ラジオボタンを選択します。
  7. 何を証明したいですか ? ダイアログボックスで、コンテナーイメージ ラジオボタンを選択し、次へ をクリックします。

  8. コンテナーイメージ認定プロジェクトの作成 Web ページで、プロジェクトを作成するために次の詳細を入力します。

    重要

    プロジェクトの作成後に、プロジェクト名やその配布方法を変更することはできません。

    1. プロジェクト名 - プロジェクト名を入力します。この名前は公開されておらず、内部使用のみを目的としています。

    2. OS コンテンツタイプ - コンテナープロジェクトに使用するイメージのタイプを選択します。

      1. Red Hat Universal Base Image: Red Hat コンテナーレジストリーまたはその他のサードパーティーレジストリーを介して、UBI ベースのコンテナーイメージを配布できます。さらに、IBM が提供する Red Hat への公開の対象となります。
      2. Red Hat Enterprise Linux: RHEL ベースのコンテナーイメージは、Red Hat Container レジストリー経由でのみ配布できます。

    3. 配布方法 - コンテナーイメージの配布に使用するコンテナーレジストリーを選択します。コンテナーイメージをこの場所からプルし、以下のすべての方法でコンテナーイメージをプルします。コンテナーイメージは、管理するレジストリーで引き続きホストされます。Red Hat は、イメージをホストするために Quay.io を推奨しますが、Kubernetes 互換レジストリーを使用できます。

      1. Red Hat Container Registry: Red Hat が Red Hat のコンテナーレジストリーでコンテナーを配布する場合は、このオプションを選択します。このディストリビューション方法が設定されたイメージは独自のコンテナーレジストリーでホストされますが、Red Hat レジストリープロキシーアドレスを介してお客様に配布されます。このオプションを選択すると、設定にレジストリーを追加せずにコンテナーにアクセスできますが、プロキシーからお客様固有のダウンロードメトリクスや他の使用状況データを表示できません。

      2. Red Hat Marketplace のみ: Red Hat Marketplace (powered by IBM) で認定コンテナーを公開するには、このオプションを選択します。認定済みコンテナーは、特定の Red Hat マーケットプレイス認定インデックスを通じてのみ利用可能になります。お客様には、コンテナーをプルする権利が必要です。このオプションは、IBM の Red Hat Marketplace チームとすでに連絡を取り合っており、その影響を理解している場合にのみ選択してください。質問がある場合は、サポートケース を開きます。このレジストリーの使用方法については、資格のあるレジストリー を参照してください。

        注記

        このオプションは、イメージが、Red Hat Marketplace にリストする予定の Operator によってデプロイされたアプリケーションの一部である場合にのみ選択してください。このオプションを選択すると、ホストされたパイプライン を Operator メタデータバンドルの認定に使用することはできず、代わりにローカルの CI パイプラインセットアップを使用する必要があります。

      3. 独自のコンテナーレジストリー: このオプションを選択して、認定済みのコンテナーを独自のレジストリーに公開します。独自のサードパーティーレジストリーを使用する場合、お客様はレジストリーに対して認証を行い、認定済みのコンテナーをプルして、製品を使用する必要があります。接続されていない環境では、お客様は Red Hat プラットフォームにレジストリーを追加して、認定済みコンテナーをインストールする必要があります。

        重要

        Red Hat では、コンテナーのメトリクス全体にアクセスでき、製品へのアクセスを完全に制御できるため、独自のレジストリーでのセルフホスティングを推奨しています。Red Hat は、この目的で Quay.io を使用することを推奨していますが、Kubernetes と互換性のある任意のレジストリーを使用できます。

    4. Create project をクリックします。

第15章 コンテナープロジェクトの設定

コンテナープロジェクトが作成されると、新しく作成されたコンテナープロジェクトの Web ページが表示されます。

コンテナープロジェクトの Web ページは、次のタブで構成されています。

  • 概要 - 認定前チェックリストが含まれています。
  • イメージ - プリフライトツールから送信したイメージテスト結果を表示します。
  • 設定 - レジストリーとリポジトリーの詳細を設定できます。

さらに、コンテナープロジェクトで次のアクションを実行するには、コンテナープロジェクトの Web ページで アクション メニューをクリックします。

15.1. 認定前チェックリストの記入

認定コンテナーは、パッケージング、配布、およびメンテナーンスに関する Red Hat のベストプラクティスを満たすアプリケーションです。認定されたコンテナーは、イメージを最新の状態に維持し、OpenShift を含む Red Hat のお客様のコンテナー対応プラットフォームに最高レベルの信頼とサポートを提供するというパートナーからのコミットメントを意味します。

コンテナーを認定するには、認定前チェックリストに記入してから、コンテナーイメージを公開する必要があります。コンテナープロジェクトの 概要 タブには、認定前チェックリストが含まれています。認定前チェックリストは、コンテナーイメージを認定および公開するために完了する必要のある一連のタスクで構成されています。

コンテナーイメージを公開する前に、チェックリストで次のタスクを実行します。

  1. Red Hat コンテナーの付録を受け入れる
  2. コンテナーに関するリポジトリーの詳細を提供する
  3. 会社プロファイルを完了する
  4. 完全な輸出管理質問票
  5. 確認のためにコンテナーを送信します
  6. 記入済み製品リストの添付

15.1.1. Red Hat コンテナーの付録を受け入れる

  1. イメージを公開するには、パートナーコンテナーイメージの配布に関する条件に同意します。
  2. Red Hat コンテナーの同意する付録 タイルにナビゲートし、承認された条件の確認 をクリックします。Red Hat Partner Connect コンテナーの付録 ドキュメントが表示されます。ドキュメントを読んで、コンテナーイメージの配布に関連する用語を理解してください。

15.1.2. コンテナーに関する詳細を提供する

  1. カタログに表示されるリポジトリーの詳細を入力するには、コンテナータイルの詳細を提供する に移動します。これにより、ユーザーはコンテナーイメージをプルできるようになります。
  2. Add details をクリックします。Settings タブに移動します。
  3. 必要なすべてのリポジトリー情報を入力します。
  4. すべてのフィールドに入力したら、保存 をクリックします。
注記

アスタリスク * が付いているすべてのフィールドは必須であり、コンテナー認定を続行する前に入力する必要があります。

15.1.3. 会社プロファイルを完了する

会社のプロファイルを最新の状態に保ちます。この情報は、認定製品とともにカタログに公開されます。

確認するには、以下を実行します。

  1. Complete your company profile タイルに移動します。
  2. チェックリストの Review をクリックします。
  3. 変更を加えるには、Edit をクリックします。
  4. Save をクリックします。
注記

Operator バンドルイメージを送信する前に、Operator バンドルデータをテストする 以外のすべての認定前チェックリストの項目を必ず完了してください。

すべての手順を完了すると、タイルの横に緑色のチェックマークが表示され、設定が完了したことを示します。

15.1.4. 完全な輸出管理質問票

エクスポートコントロール質問票 には、Red Hat 法務チームがサードパーティーベンダーによるエクスポートコンプライアンスを評価するための一連の質問が含まれています。

パートナーの法定代理人は、質問を確認して回答する必要があります。Red Hat は、応答を評価するのに約 5 営業日かかり、応答に基づいて、Red Hat はパートナーを承認するか、パートナーを拒否するか、決定を延期するか、詳細情報を要求します。

注 - UBI (Universal Base Image) のバージョンを使用してコンテナーイメージを構築している場合は、プライベートリポジトリーでイメージをホストできます。これにより、エクスポートコンプライアンスをスキップできます。このエクスポートコンプライアンスフォームは、Red Hat Container Catalog でイメージをホストしている場合にのみ必要です。

15.1.5. 確認のためにコンテナーを送信します

プリフライトをローカルで設定し、コンテナーを検証用に送信 タイルに移動して、ソフトウェア認定テストの結果を送信します。

15.1.6. 記入済み製品リストの添付

新しい製品リストを作成するか、プロジェクトを既存の製品リストにアタッチできます。

15.1.6.1. 新しい製品リストの作成

手順

  1. Attach a completed product listing タイルに移動します。
  2. Select method ドロップダウンメニューから、Attach or edit を選択します。Attach product listing ポップアップウィンドウが表示されます。
  3. Create new product listing をクリックします。
  4. Product Name テキストボックスに、必要な製品名を入力します。
  5. Product listing type から、必要な製品タイプを選択します。
  6. Save をクリックします。
  7. Select method ドロップダウンメニューから、View product listing をクリックして、新しい製品リストに移動し、必要な製品リストの詳細をすべて入力します。
  8. Save をクリックします。

検証

Partner Connect ポータルのプロジェクトページに移動し、Certification Projects > Attached Listings 列に移動します。新しい添付の製品リストが表示されます。

15.1.6.2. 既存の製品リストへのコンテナープロジェクトの割り当て

手順

  1. Attach a completed product listing タイルに移動します。
  2. Select method ドロップダウンメニューから、Attach or edit を選択します。Attach product listing ポップアップウィンドウが表示されます。
  3. Related product listing セクションから、Select drop-down arrow をクリックして 1 つ以上の製品リストを選択します。
  4. Save をクリックします。

検証

Partner Connect ポータルのプロジェクトページに移動し、Certification Projects > Attached Listings 列に移動します。添付されたすべての製品リストが表示されます。

15.1.6.3. 1 つの製品リストへの複数のコンテナープロジェクトのアタッチ

製品に複数のコンテナープロジェクトが設定されている場合、必要なすべてのコンテナープロジェクトを Listing Details の単一の製品リストに割り当てることができます。

手順

  1. My Work ページで、必要な製品リストを選択します。
  2. 製品ページの Listing Details サイドバーメニューで、Certification Projects オプションをクリックします。
  3. Attach Project をクリックします。
  4. Attach certification projects ポップアップウィンドウで、1 つ以上のコンテナープロジェクトを選択します。
  5. Attach をクリックします。

検証

Partner Connect ポータルのプロジェクトページに移動し、Certification Projects > Attached Listings 列に移動します。添付の製品リストが表示されます。

15.1.6.4. 既存の製品リストから割り当てられたコンテナープロジェクトを削除

製品リストにアタッチされているコンテナープロジェクトが製品で使用されなくなった場合は、削除できます。

手順

  1. My Work ページで、必要な製品リストをクリックします。
  2. 製品ページの Listing Details サイドバーメニューで、Certification Projects オプションをクリックします。
  3. 削除するアタッチされているコンテナープロジェクトをすべて選択し、Remove をクリックします。

15.2. イメージテスト結果の表示

イメージタブには、プリフライトツールから送信したイメージテストの結果が表示されます。

コンテナーイメージの次の詳細が表示されます。

  • 特定のイメージ ID
  • 認定テスト - 合格/不合格 - 詳細については、クリックしてください。
  • ヘルスインデックス - コンテナーヘルスインデックスは、コンテナーイメージで利用可能な最も古くて最も重大なセキュリティー更新の尺度です。A は F よりも最新です。詳細については、Red Hat Container Catalog 内で使用されている ContainerHealth Index のグレード を参照してください。
  • アーキテクチャー - 該当する場合、イメージの特定のアーキテクチャー。
  • 作成済み - 送信が処理された日。

  • アクションメニューを使用すると、以下のタスクを実行できます。

    • イメージの削除: このオプションをクリックして、イメージが公開されていないときにコンテナーイメージを削除します。
    • タグの同期 - イメージタグを変更した場合、このオプションを使用して、Red Hat Partner Connect と Red Hat Container catalog の両方で利用可能なコンテナーイメージ情報を同期します。
    • カタログでの表示: コンテナーイメージが公開されている場合、このオプションをクリックして、公開されたコンテナーイメージを Red Hat Ecosystem Container カタログ で表示します。

15.3. コンテナープロジェクト設定の管理

Settings タブを使用してレジストリーおよびリポジトリーの詳細を設定できます。

以下のフィールドに必要な詳細を入力します。

フィールド名説明

コンテナーレジストリーの名前空間

このフィールドは編集できず、会社のプロファイルから自動入力されます。たとえば、mycompany。

アウトバウンドリポジトリー名

選択したリポジトリー名、またはイメージがホストされているプライベートレジストリーから取得した名前。たとえば、ubi-minimal。

リポジトリーの概要

エコシステムカタログリストに表示される要約情報。技術情報 → 一般情報 → 要約 で入手できます。

リポジトリーの説明

エコシステムカタログリストに表示されるリポジトリーの説明。概要と 技術情報 → 一般情報 → 説明 で入手できます。

アプリケーションカテゴリー

ソフトウェア製品のそれぞれのアプリケーションタイプを選択します。

サポート対象プラットフォーム

ソフトウェア製品でサポートされているプラットフォームを選択します。

ホストレベルのアクセス

2 つのオプションから選択します。

  • 権限なし - コンテナーがホストから分離されている場合。

    または

  • 権限あり - コンテナーに特別なホストレベルの特権が必要な場合。

    注記

    製品の機能にルートアクセスが必要な場合は、プリフライトツールを実行する前に、特権オプションを選択する必要があります。この設定は、Red Hat のレビューの対象となります。

リリースカテゴリー

2 つのオプションから選択します。

  • 一般提供 - このオプションを選択すると、アプリケーションは一般提供され、サポートされます。

    または

  • ベータ版 - このオプションを選択すると、アプリケーションはプレリリース候補として利用できます。

Project name

内部目的のプロジェクトの名前。

自動公開

このオプションを有効にすると、コンテナーイメージは、すべての認定テストに合格した後、Red Hat Container Catalog に自動的に公開されます。

Technical contact email address

製品の主な技術担当者の詳細。

注記

注: アスタリスク * が付いているすべてのフィールドは必須であり、コンテナー認定を続行する前に入力する必要があります。

第16章 認定テストスイートの実行

指示に従って、認定テストスイートを実行します。

前提条件

  • Red Hat Enterprise Linux (RHEL) システムがあります。

  • Podman を使用して、イメージレジストリーにログインできます。以下に例を示します。 

    $ podman login --username <your_username> --password <your_password> --authfile ./temp-authfile.json <registry>
  • Red HatPartner Connect ポータル でコンテナープロジェクトを設定しました。少なくとも認定前チェックリストが進行中である必要があります。
  • pyxis API キー があります。

手順

  1. Podman を使用してコンテナーイメージを構築します。

    注記

    Podman を使用してコンテナーイメージを構築することはオプションです。

  2. コンテナーを任意のプライベートまたはパブリックレジストリーにアップロードします。
  3. 最新の プリフライト認定ユーティリティー をダウンロードします。

  4. 認定されているコンテナーの機能を確認するには、次の手順を実行します。

    1. Preflight 認定ユーティリティーを実行します。 

      $ preflight check container \
registry.example.org/<namespace>/<image_name>:<image_tag>

    2. ログ情報を確認し、必要に応じてコンテナーを変更します。詳細については、トラブルシューティング情報 ページを参照してください。

      問題を見つけた場合は、サポートチケット を送信するか、次のコマンドを実行してください。 

      $ preflight support

      Red Hat は、コミュニティーの貢献を歓迎します。Preflight または Red Hat Connect Portal に関連するバグが発生した場合、または機能の改善や貢献について提案がある場合は、問題を報告してください。問題を報告する前に、重複を避けるために未解決の問題を確認してください。

    3. コンテナー認定ユーティリティーを実行し、すべてのテストに合格するまで変更を加えます。

  5. 次のコマンドを実行して、認定テストの結果を送信します。 

    $ preflight check container \
registry.example.org/<namespace>/<image_name>:<image_tag> \
--submit \
--pyxis-api-token=<api_token> \
--certification-project-id=<project_id> \
--docker-config=./temp-authfile.json

    テスト結果を Red Hat Connect ポータルに送信すると、Red Hat はコンテナーのレイヤーをスキャンしてパッケージの脆弱性を検出します。

  6. Red Hat Partner Connect ポータル の Images タブに移動して、認定プロジェクト UI で認定と脆弱性のテスト結果を確認します。詳細については、イメージテスト結果の表示 を参照してください。

関連情報

RHEL アプリケーションを認定する場合は、コンテナー化されていない製品の認定ワークフロー に従って、製品の機能を検証してください。

プリフライトツールが組み込まれている Red Hat 認定ツール を使用して RHEL アプリケーションコンテナーを認定することもできます。これにより、コンテナーを検証することができます。

手順

組み込みのプリフライトツールを使用するには、次の手順に従います。

  1. プリフライトパッケージをインストールします。

    # dnf install redhat-certification-preflight

  2. rhcert を実行し、指示に従ってください。

    # rhcert-run

  3. テスト結果を確認し、保存します。

    # rhcert-cli save

第17章 認定コンテナーの公開

Partner Connect プロジェクト のプリフライトツールからテスト結果を送信した後、プロジェクト内の脆弱性についてコンテナーイメージがスキャンされます。スキャンが正常に完了すると、イメージの Publish ボタンが有効になります。Publish ボタンをクリックすると、イメージがRed Hat Ecosystem Catalog で利用できるようになります。

重要

Red Hat ソフトウェア認定は、選択したプラットフォームでのパートナー製品の機能またはパフォーマンスのテストを実施しません。認定候補製品の品質保証は、すべてパートナーの責任において行われるものとします。

17.1. 資格のあるレジストリー

  1. Red Hat Marketplace の資格のあるレジストリーを使用する場合は、registry.connect.redhat.com でイメージをホストします。
  2. http://registry.connect.redhat.com でイメージをホストするには、registry.marketplace.redhat.com/rhm を使用して、Operator のメタデータバンドルを docker イメージでスキャンし、すべてのイメージ参照を置き換えて、この docker レジストリーを使用します。
  3. そこから、ImageContentSourcePolicy を適用して、 registry.marketplace.redhat.com/rhm を registry.connect.redhat.com にポイントします。

パート III. Operator 認定

第18章 Operator との連携

注記

Red Hat Operator 認定に進む前に、Operator イメージまたは必要なコンテナーイメージをコンテナーアプリケーションプロジェクトとして認定します。Operator バンドルで参照されるすべてのコンテナーは、Operator バンドルの認定を開始する前に、Red Hat Ecosystem Catalog で認定および公開されている必要があります。

18.1. Operator の概要

Kubernetes Operator は、Kubernetes アプリケーションをパッケージ化、デプロイ、および管理する方法です。当社の Operator 認定プログラムは、パートナーの Operator が OpenShift プラットフォーム上の Operator Lifecycle Manager によってデプロイ可能であり、Red Hat 認定のコンテナーイメージを使用して適切にフォーマットされていることを保証します。

18.2. Operator の認定ワークフロー

注記

Red Hat では、Red Hat 認定エンジニアまたは同等の経験を有するユーザーが、認定プロセスを開始することを推奨しています。

タスクの概要

認定ワークフローには、3 つの主要なステップが含まれます -

  1. 「認定のオンボード」
  2. 「認定テスト」
  3. 「認定 Operator を Red Hat Ecosystem Catalog に公開する」

18.2.1. 認定のオンボード

認定のオンボーディングについて概説した手順を実行します。

  1. Red Hat Connect for Technology パートナープログラムに参加してください。
  2. 認定するソフトウェア製品を追加します。
  3. 会社プロファイルに記入します。
  4. 認定前チェックリストに記入します。
  5. 製品の OpenShift Operator プロジェクトバンドルを作成します。

18.2.2. 認定テスト

認定テストを実行するには。

  1. Red Hat アップストリームリポジトリーをフォークします。
  2. テスト環境に Red Hat 認定パイプラインをインストールして実行します。
  3. テスト結果を確認し、問題がある場合はトラブルシューティングします。
  4. プルリクエストを介して認定結果を Red Hat に送信します。
  5. Red Hat ですべてのテストを実行する場合は、プルリクエストを作成します。これにより、認定がホストするパイプラインがトリガーされ、Red Hat インフラストラクチャーですべての認定チェックが実行されます。

18.2.3. 認定 Operator を Red Hat Ecosystem Catalog に公開する

すべての認定チェックを正常に完了すると、テスト結果を Red Hat に送信できます。個々の目標に応じて、この結果送信ステップをオンまたはオフにすることができます。テスト結果が送信されると、Red Hat インフラストラクチャーがトリガーされ、プルリクエストが自動的にマージされて Operator が公開されます。

次の図は、Operator をローカルでテストする概要を示しています。

図18.1 Operator のローカルテストの概要

このセクションで説明する OpenShift Operator を視覚的に表現したフローチャート。
注記

Red Hat は、Operator をテストするためにこのパスを選択することをお勧めします。

関連情報

演算子の詳細については、以下を参照してください。

第19章 Operator バンドルプロジェクトの作成

前提条件

Operator バンドルを作成する前に、Operator イメージまたは必要なコンテナーイメージをコンテナーアプリケーションプロジェクトとして認定します。

手順

  1. Red Hat Partner Connect ポータル にログインします。

    パートナーポータルへのアクセス Web ページが表示されます。

  2. 認定テクノロジーポータル タイルに移動し、テクノロジーパートナーのログイン をクリックします。

  3. ログイン資格情報を入力し、ログイン をクリックします。

    Red Hat Partner Connect の Web ページが表示されます。

  4. ページヘッダーで、製品認定 を選択し、認定プロジェクトの管理 をクリックします。

    My Work Web ページには、製品リスト と利用可能な場合 認定プロジェクト が表示されます。

  5. Create Project をクリックします。
  6. 認定するプラットフォーム ダイアログボックスで、Red Hat OpenShift ラジオボタンを選択し、次へ をクリックします。
  7. 何を証明したいですか? ダイアログボックスで、Operator Bundle Image ラジオボタンを選択し、次へ をクリックします。

  8. Operator バンドルイメージ認定プロジェクトの作成 Web ページで、プロジェクトを作成するための次の詳細を入力します。

    重要

    プロジェクトの作成後に、プロジェクト名とその配布方法を変更することはできません。

    1. Project Name - プロジェクト名を入力します。この名前は公開されておらず、内部使用のみを目的としています。

    2. Specialized Certification: この機能を使用すると、専門の Operator を認定できます。

      1. 専門の Operator を認定する場合は、My operator is a CNI or CSI チェックボックスをオンにします。

      2. 必要な Operator を選択してください:

        1. Container Network Interface (CNI)
        2. クラウドストレージインターフェイス (CSI)

    3. 公開オプション: Operator を公開するための次のオプションのいずれかを選択します。

      1. Web カタログのみ (catalog.redhat.com): Operator は Red Hat Container Catalog に公開され、Red Hat OpenShift OperatorHub または Red Hat Marketplace には表示されません。これは、新しいプロジェクトを作成するときのデフォルトのオプションです。このオプションは、Operator を OpenShift 内にパブリックにインストールしたくないが、認定の証明が必要なパートナーに適しています。このオプションは、OpenShift 製品内カタログ (認定済み) オプションに含まれていないディストリビューション、資格、またはその他のビジネス要件がある場合にのみ選択してください。
      2. OpenShift 製品内カタログ (認定): Operator は Red Hat Container Catalog にリストされ、OpenShift の OperatorHub に組み込まれた認定 Operator インデックスに公開されます。
      3. OpenShift 製品内カタログ (Red Hat Marketplace): Operator は Red Hat Container Catalog に公開され、OpenShift 内の OperatorHub に組み込まれ、特別な Marketplace ラベルが付けられます。この埋め込みリストから Red Hat Marketplace の製品ページに移動できるようにするには、認定を完了する前に、IBM Cloud Paks チーム が運営する Red Hat Marketplace で追加のオンボーディング手順を完了する必要があります。
    4. Create project をクリックします。

第20章 Operator バンドルの設定

プロジェクトが作成されると、新しく作成された Operator バンドルプロジェクトの Web ページが表示されます。

Operator バンドルの Web ページは、次のタブで構成されています。

  • 概要 - 認定前チェックリストが含まれています。
  • テスト結果 - 認定の実行後のテスト結果を表示します。
  • グラフの更新 -OpenShift バージョン、チャネルステータス、更新パス、およびその他の利用可能なチャネルの詳細を表示します。
  • 設定 - レジストリーとリポジトリーの詳細を設定できます。

さらに、Operator バンドルで次のアクションを実行するには、Operator バンドル Web ページの アクション メニューをクリックします。

20.1. 認定前チェックリストの記入

Operator バンドルプロジェクトの 概要 タブには、認定前チェックリストが含まれています。認定前チェックリストは、Operator バンドルを認定および公開するために完了する必要のある一連のタスクで構成されています。

Operator バンドルイメージを公開する前に、チェックリストで次のタスクを実行します。

  1. Red Hat コンテナーの付録を受け入れる
  2. コンテナーのプルに使用されるリポジトリーの詳細を提供する
  3. 会社プロファイルを完了する
  4. Operator バンドルデータをテストし、プルリクエストを送信する
  5. 記入済み製品リストの添付
  6. Red Hat OpenShift で CNI または CSI の機能を検証する

20.1.1. Red Hat コンテナーの付録を受け入れる

ユーザーは、イメージを公開する前に、パートナーコンテナーイメージの配布に関する条件に同意する必要があります。

Red Hat コンテナー付録の同意 タイルにナビゲートし、承認済み条件の確認 をクリックします。コンテナーイメージの配布に関連する用語について表示される Red Hat の付録ドキュメントをお読みください。

20.1.2. コンテナーのプルに使用されるリポジトリーの詳細を提供する

  1. Provide repository details used for pulling your container に移動し、カタログに表示されるリポジトリーの詳細を入力して、お客様がコンテナーイメージをプルできるようにし、Add details をクリックします。
  2. Settings タブで、必要なすべてのリポジトリー情報を入力し、Save をクリックします。
注記

アスタリスク*が付いているすべてのフィールドは必須であり、Operator バンドル認定に進む前に入力する必要があります。

20.1.3. 会社プロファイルを完了する

会社のプロファイルを最新の状態に保ちます。この情報は、認定製品とともにカタログに公開されます。

確認するには、以下を実行します。

  1. Complete your company profile タイルに移動します。
  2. チェックリストの Review をクリックします。
  3. 変更を加えるには、Edit をクリックします。
  4. Save をクリックします。
注記

Operator バンドルイメージを送信する前に、Operator バンドルデータをテストする 以外のすべての認定前チェックリストの項目を必ず完了してください。

すべての手順を完了すると、タイルの横に緑色のチェックマークが表示され、設定が完了したことを示します。

20.1.4. Operator バンドルを Red Hat Marketplace に公開する

Operator バンドルを Red Hat に公開する場合は、Red Hat Marketplace 公開タスクの完了 タイルに移動して 販売者になる をクリックします。

Red Hat Marketplace のオンボーディングチームから連絡があり、このチェックリスト項目を承認するために協力します。遅延が発生した場合は、サポートチケット を開いてください。

認定前チェックリストが完了したら、Operator バンドルイメージを送信できます。これは、Operator バンドルイメージの認定を完了するための最後のステップです。

20.1.5. Operator バンドルデータをテストし、プルリクエストを送信する

Operator 認定スイートを実行するには、Operator バンドルデータのテストに移動し、プルリクエストタイルを送信 して、オプションの表示 をクリックします。Operator をテストおよび認定する方法を決定するための 2 つのタブが表示されます。

20.1.5.1. OpenShift を使用してローカルでテストする

テストと認定には、選択した OpenShift クラスターを使用します。このオプションを使用すると、提供されたパイプラインを独自のワークフローに統合して、継続的な検証と包括的なログへのアクセスを行い、フィードバックループを高速化できます。これは、推奨の手法です。詳細については、認定テストスイートをローカルで実行する を参照してください。

20.1.5.2. Red Hat のホストパイプラインでテストする

このアプローチは、OpenShift ソフトウェアのテストと認定とは別のものです。認定したいバージョンの OpenShift で Operator をテストした後、包括的なログが必要ない場合、または独自のワークフローに含める準備ができていない場合は、このアプローチを使用できます。詳細については、Red Hat がホストするパイプラインを使用した認定スイートの実行 を参照してください。

認定テストオプションの比較

長期的には、Red Hat は、Operator のテストにローカルテストオプション (CI パイプラインとも呼ばれる) を使用することをお勧めします。この方法により、テストを CI/CD ワークフローおよび開発プロセスに組み込むことができるため、OpenShift プラットフォームでの製品の適切な機能が保証され、Operator の将来の更新と再認定が合理化されます。

最初は、メソッドの学習とエラーのデバッグに時間がかかる場合がありますが、これは高度なメソッドであり、最良かつ最速のフィードバックを提供します。

一方、Red Hat は、緊急の締め切りに取り組んでいる場合や、ツールを使用するのに十分なリソースと時間が利用できない場合など、多くのイベントで Red Hat インフラストラクチャーオプションで実行される、ホストされたパイプラインを使用することをお勧めします。

ローカルツールを長期的に組み込む方法を学ぶときに、ホストされたパイプラインを CI/ ローカルパイプラインと同時に使用できます。

20.1.6. 完了済み製品リストを添付する

この機能を使用すると、新しい製品リストを作成するか、新しいプロジェクトの既存の OpenShift 製品リストにプロジェクトを添付することができます。

  1. Attach a completed product listing に移動します。
  2. Select method ドロップダウンメニューから、Attach or edit を選択します。Attach product listing ページが表示されます。

  3. プロジェクトを既存の製品リストにアタッチするか、新しい製品リストを作成するかを決定します。

    1. プロジェクトを既存の製品リストに添付するには:

      1. 関連製品リスト セクションから、選択 ドロップダウン矢印をクリックして製品リストを選択します。
      2. Save をクリックします。

    2. 新しい商品リストを作成するには:

      1. Create new product listing をクリックします。
      2. Product Name テキストボックスに、必要な製品名を入力します。
      3. Product list type から、必要な製品タイプ (OpenShift Operator など) を選択します。
      4. Save をクリックします。
  4. Select method ドロップダウンメニューから、View product listing をクリックして、新しい製品リストに移動し、必要な製品リストの詳細をすべて入力します。
  5. Save をクリックします。

20.1.7. Red Hat OpenShift で CNI または CSI の機能を検証する

注記

この機能は、CNI および CSI Operator にのみ適用されます。

この機能により、認定テストをローカルで実行し、テスト結果を Red Hat 認定チームと共有できます。

専用の CNI または CSI Operator の機能を検証するには、次のようにします。

  1. このオプションを選択し、開始 をクリックします。Red Hat Certification ポータル で新しいプロジェクトが作成され、適切なプロジェクトポータルページにリダイレクトされます。
  2. 概要 タブで、ファイル セクションに移動し、アップロード をクリックして、テスト結果をアップロードします。
  3. ディスカッション セクションに関連するコメントを追加し、コメントの追加 をクリックします。

Red Hat は、送信された結果ファイルを確認し、専門の CNI または CSI Operator を検証します。検証が成功すると、Operator は承認され、公開されます。

関連情報

  • 詳細は、CNI および CSI のワークフローを参照してください。

20.2. テスト結果の表示

テスト認定スイートを実行した後、プロジェクトヘッダーの テスト結果 タブに移動して、テスト結果を表示します。

2 つのタブがあります。

  • 結果 - すべての認定テストの概要とその結果を表示します。
  • アーティファクト - ログファイルを表示します。

20.3. 更新グラフの操作

グラフの更新機能を使用して、OpenShift バージョン、チャネルステータス、更新パス、およびその他の使用可能なチャネルの詳細を表示および更新できます。

プロジェクトヘッダーの グラフの更新 タブに移動して、Operator プロジェクトの必要な詳細を表示および更新します。アップグレードの詳細については、Operator 更新のドキュメント タイルを参照してください。

20.4. プロジェクト設定の管理

設定タブからレジストリーとリポジトリーの詳細を設定できます。

以下のフィールドに必要な詳細を入力します。

  • コンテナーレジストリーの名前空間
  • アウトバウンドリポジトリー名
  • 承認された GitHub ユーザーアカウント
  • OpenShift Object YAML - プライベートコンテナーレジストリーを使用している場合は、このオプションを使用して docker config.json シークレットを追加します。
  • Red Hat Ecosystem Catalog の詳細 - リポジトリーの概要、リポジトリーの説明、アプリケーションカテゴリー、サポートされているプラットフォームが含まれます。
  • プロジェクトの詳細 - プロジェクト名、技術担当者、および電子メールアドレスが含まれます。
重要

この情報は内部使用のためのものであり、公開されていません。

注記

アスタリスク*が付いているすべてのフィールドは必須であり、Operator バンドル認定に進む前に入力する必要があります。

第21章 認定テストスイートのローカルでの実行

このオプションを選択すると、独自の OpenShift クラスターで認定ツールを実行できます。

注記

Red Hat は、この方法に従って Operator を認定することをお勧めします。

このオプションは、次のようなパートナー向けの高度な方法です。

  • 継続的な検証のためにツールを独自の開発者ワークフローに統合することに関心があります。
  • より高速なフィードバックループのために包括的なログにアクセスしたい、
  • または、デフォルトの OpenShift インストールでは使用できない依存関係があります。

プロセスの概要は次のとおりです。

図21.1 認定テストスイートをローカルで実行する概要

認定テストスイートをローカルで実行することを視覚的に表したフローチャート

Tekton に基づく OpenShift パイプラインを使用して、認定テストを実行し、包括的なログの表示とデバッグ情報をリアルタイムで有効にします。Operator バンドルを認定して公開する準備ができたら、パイプラインはユーザーに代わってプルリクエスト (PR) を GitHub に送信します。すべてが正常に成功すると、Operator は自動的にマージされ、Red Hat Container Catalog および OpenShift の組み込み operatorHub に公開されます。

指示に従って、認定テストスイートをローカルで実行します。

前提条件

Red Hat OpenShift テスト環境でソフトウェア製品を認定するには、以下を確認してください。

  • OpenShift クラスターバージョン 4.8 以降がインストールされます。
注記

OpenShift Operator Pipeline は、5GB ボリュームの永続的なボリューム要求を作成します。ベアメタルで OpenShift クラスターを 実行している場合は、動的ボリュームプロビジョニング が設定されていることを確認してください。動的ボリュームプロビジョニングが設定されていない場合は、ローカルボリューム のセットアップを検討してください。Permission Denied エラーが発生しないようにするには、次のコマンドを使用してローカルボリュームストレージパスを変更し、container_file_t SELinux ラベルを付けます。 

chcon -Rv -t container_file_t "storage_path(/.*)?"
  • クラスター管理者権限を持つ管理者ユーザーの kubeconfig ファイルがあります。
  • 有効な Operator バンドルがある。
  • OpenShift CLI ツール (oc) バージョン 4.7.13 以降がインストールされています。
  • Git CLI ツール (git) バージョン 2.32.0 以降がインストールされています。
  • Tekton CLI ツール (tkn) バージョン 0.19.1 以降がインストールされています。

関連情報

プログラムの前提条件については、Red Hat Openshift 認定の前提条件 を参照してください。

21.1. Operator バンドルの追加

フォークの operators ディレクトリーには、一連のサブディレクトリーがあります。

21.1.1. 以前にこの Operator を認定したことがある場合

Operator ディレクトリーで、Operator のそれぞれのフォルダーを見つけます。Operator バンドルの内容をこのディレクトリーに配置します。

注記

パッケージ名が Operator の既存のフォルダー名と一致していることを確認してください。Red Hat Marketplace バンドルの場合、パッケージ名に接尾辞 -rhmp を手動で追加する必要があります。以前は、これは自動的に行われていたため、手動で変更してもお客様のアップグレードには影響しません。

21.1.2. この Operator を新たに認定する場合

新しく認定する Operator のサブディレクトリーが Operator の親ディレクトリーの下にない場合は、サブディレクトリーを作成する必要があります。

演算子の下に新しいディレクトリーを作成します。このディレクトリーの名前は、Operator のパッケージ名と一致している必要があります。たとえば、my-operator。

  • この operators ディレクトリーに、<my-operator> などの演算子の名前で新しいサブディレクトリーを作成し、<V1.0> などのバージョンディレクトリーを作成してバンドルを配置します。これらのディレクトリーは、以前に認定された Operator 用にプリロードされています。 

    ├── operators
    └── my-operator
        └── v1.0
  • バージョンディレクトリーの下に、clusterserviceversion.yaml ファイルを含むすべての OpenShift マニフェストを含む manifests フォルダーを追加します。

推奨されるディレクトリー構造

次の例は、推奨されるディレクトリー構造を示しています。 

├── config.yaml
├── operators
    └── my-operator
        ├── v1.4.8
        │   ├── manifests
        │   │   ├── cache.example.com_my-operators.yaml
        │   │   ├── my-operator-controller-manager-metrics-service_v1_service.yaml
        │   │   ├── my-operator-manager-config_v1_configmap.yaml
        │   │   ├── my-operator-metrics-reader_rbac.authorization.k8s.io_v1_clusterrole.yaml
        │   │   └── my-operator.clusterserviceversion.yaml
        │   └── metadata
        │       └── annotations.yaml
        └── ci.yaml
設定ファイル説明

config.yaml

このファイルには、Operator の組織が含まれています。certified-operators または redhat-marketplace にすることができます。例 organization: certified-operators

注記

Operator を Red Hat Marketplace ディストリビューションのターゲットにしている場合は、clusterserviceversion.yaml に次のアノテーションを含める必要があります。

marketplace.openshift.io/remote-workflow:https://marketplace.redhat.com/en-us/operators/ {package_name}/priceing?utm_source=openshift_console

marketplace.openshift.io/support-workflow:https://marketplace.redhat.com/en-us/operators/{package_name}/support?utm_source=openshift_console

ci.yaml

このファイルには、Red Hat テクノロジーパートナーのプロジェクト ID と、この Operator の組織ターゲットが含まれています。

例 cert_project_id: <your partner project id>。このファイルには、認定プロセスを成功させるために必要なすべてのメタデータが保存されています。

annotations.yaml

このファイルには、OpenShift バージョンの範囲を参照する OpenShift バージョンのアノテーションが含まれています。たとえば、v4.8-v4.10 は、バージョン 4.8 から 4.10 を意味します。これを既存のコンテンツに追加します。

例: # OpenShift annotations com.redhat.openshift.versions: v4.8-v4.10Operator バンドルのメタデータの一部である com.redhat.openshift.versions フィールドは、特定の OpenShift バージョンの認定カタログに Operator が含まれているかどうかを判断するために使用されます。Operator がサポートする OpenShift の 1 つ以上のバージョンを示すために使用する必要があります。

バージョンの前に文字 v を使用する必要があり、スペースは使用できないことに注意してください。構文は次のとおりです。

  • 単一バージョンは、Operator がそのバージョンの OpenShift 以降でサポートされていることを示します。Operator は、以降のすべての OpenShift リリースの認定カタログに自動的に追加されます。
  • = が前に付いた単一のバージョンは、Operator がその特定のバージョンの OpenShift でのみサポートされることを示します。たとえば、=v4.8 を使用すると、OpenShift 4.8 の認定カタログに Operator が追加されますが、それ以降の OpenShift リリースでは追加されません。
  • 範囲を使用して、その範囲内の OpenShift バージョンのみのサポートを示すことができます。たとえば、v4.8-v4.10 を使用すると、Operator は OpenShift 4.8 から 4.10 の認定カタログに追加されますが、OpenShift 4.11 または 4.12 には追加されません。

関連情報

21.2. リポジトリーのフォーク

  1. GitHub にログインし、RedHat OpenShift operators のアップストリームリポジトリーをフォークします。
  2. 配布の対象となるカタログに応じて、次の表から適切なリポジトリーをフォークします。
カタログアップストリームリポジトリー

認定カタログ

https://github.com/redhat-openshift-ecosystem/certified-operators

Red Hat Marketplace

https://github.com/redhat-openshift-ecosystem/redhat-marketplace-operators

  1. フォークされた認定 Operator リポジトリーのクローンを作成します。
  2. Operator バンドルのコンテンツを、フォークされたリポジトリーで使用可能な Operator ディレクトリーに追加します。

Operator バンドルを複数のカタログで公開する場合は、各カタログをフォークして、フォークごとに 1 回認定を完了することができます。

関連情報

GitHub でフォークを作成する方法の詳細については、フォークリポジトリー を参照してください。

21.3. OpenShift Operator パイプラインのインストール

前提条件

OpenShift クラスターの管理者権限。

手順

OpenShift Operator パイプラインは、次の 2 つの方法でインストールできます。

21.3.1. 自動化されたプロセス

Red Hat は、OpenShift Operator Pipeline のインストールに自動プロセスを使用することを推奨しています。自動化されたプロセスにより、CI パイプラインを実行する前にクラスターが適切に設定されていることが保証されます。このプロセスは、Operator をクラスターにインストールします。これにより、手動による介入を必要とせずに、すべての CI パイプラインタスクを自動的に更新できます。このプロセスは、同じクラスター内で多くの Operator を繰り返しテストできるマルチテナントシナリオもサポートします。

以下のステップに従って、Operator を介して OpenShift Operator パイプラインをインストールします。

注記

Operator パイプラインをインストールする前に、Operator バンドルのソースファイルを準備しておいてください。

21.3.1.1. 前提条件

OpenShift Operator パイプラインをインストールする前に、ターミナルウィンドウで以下のコマンドを実行して、すべての前提条件を設定します。

注記

Operator はすべての名前空間を監視します。したがって、secrets/configs/etc がすでに別の名前空間に存在する場合は、既存の名前空間を使用して Operator Pipeline をインストールできます。

  1. 新規の namespace を作成します。 

    oc new-project oco

  2. kubeconfig 環境変数を設定します。 

    export KUBECONFIG=/path/to/your/cluster/kubeconfig
    注記

    この kubeconfig 変数は、テスト対象の Operator をデプロイし、認定チェックを実行するために使用されます。 

    oc create secret generic kubeconfig --from-file=kubeconfig=$KUBECONFIG

  3. 認定結果を送信するには、次のコマンドを実行します。

    • プルリクエストが作成されるリポジトリーに github API トークンを追加します。 

      oc create secret generic github-api-token --from-literal GITHUB_TOKEN=<github token>

    • RedHat Container API アクセスキーを追加します。 

      oc create secret generic pyxis-api-secret --from-literal pyxis_api_key=< API KEY >

      この API アクセスキーは、Red Hat Partner Connect ポータルの一意のパートナーアカウントに特に関連しています。

  4. ベアメタルで OpenShift クラスターを実行するための前提条件:

    1. ベアメタルで OpenShift クラスターを実行している場合、Operator パイプラインを実行するには 5Gi 永続ボリュームが必要です。次の yaml テンプレートは、ローカルストレージを使用して 5Gi 永続ボリュームを作成するのに役立ちます。

      以下に例を示します。 

      apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVoumeReclaimPolicy: Delete
  local:
    path: /dev/vda4  ← use a path from your cluster
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
              - crc-8k6jw-master-0  ← use the name of one of your cluster’s node

    2. CI パイプラインは、テストと検証のために、Operator バンドルイメージとバンドルイメージインデックスを自動的に構築します。デフォルトでは、パイプラインはクラスター上の OpenShift Container Registry にイメージを作成します。

      ベアメタルでこのレジストリーを使用するには、パイプラインを実行する前に内部イメージレジストリーを設定します。内部イメージレジストリーの設定の詳細な手順は、イメージレジストリーストレージの設定 を参照してください。

      外部のプライベートレジストリーを使用する場合は、シークレットを追加して、アクセス資格情報をクラスターに提供します。詳細な手順については、プライベートコンテナーレジストリーの使用 を参照してください。

関連情報

21.3.1.2. Operator を介したパイプラインのインストール

次の手順に従って、Operator をクラスターに追加します。

  1. Operator Certification Operator をインストールします。

    • OpenShift クラスターコンソールにログインします。
    • メインメニューから、Operators → OperatorHubに移動します。
    • All Items - Filter by keyword フィルター/検索ボックスでフィルターに Operator Certification Operator と入力します。
    • 表示されたら、Operator Certification Operator タイルを選択します。Operator Certification Operator ページが表示されます。
    • Install をクリックします。Install Operator Web ページが表示されます。
    • 下にスクロールして、インストール をクリックします。
    • 演算子の表示 をクリックして、インストールを確認します。

  2. 新しくインストールされた Operator パイプラインにカスタムリソースを適用します。

    • OpenShift Cluster Console にログインします。
    • プロジェクト ドロップダウンメニューから、カスタムリソースを適用するプロジェクトを選択します。

    • Operator Pipeline を展開し、Create instance をクリックします。

      Operator パイプラインの作成 画面には、デフォルト値が自動的に入力されます。

      注記

      前提条件 に従って、すべてのリソース名を作成した場合は、デフォルト値を変更する必要はありません。

    • Create をクリックします。

    カスタムリソースが作成され、Operator が調整を開始します。

検証手順

  1. カスタムリソースの条件を確認してください。

    • OpenShift クラスターコンソールにログインします。
    • Operator パイプラインカスタムリソースを新しく作成したプロジェクトに移動し、カスタムリソースをクリックします。
    • 条件 セクションまで下にスクロールして、すべての ステータス 値が True に設定されているかどうかを確認します。
注記

リソースが調整に失敗した場合は、メッセージ セクションを確認して、エラーを修正するための次の手順を特定してください。

  1. Operator ログを確認してください。

    • ターミナルウィンドウで、次のコマンドを実行します。 

      oc get pods -n openshift-marketplace

    • certification-operator-controller-manager pod の完全な podman 名を記録し、次のコマンドを実行します。 

      oc get logs -f -n openshift-marketplace <pod name> manager
    • Operator の調整が行われたかどうかを確認します。

関連情報

  1. Operator パイプラインカスタムリソースをアンインストールするには。

    • OpenShift Cluster Console にログインします。
    • Operator Certification Operator のメインページに移動し、アンインストールするOperator パイプラインをクリックします。
    • カスタムリソースオーバーフローメニューをクリックして、アンインストール を選択します。

  2. Operator をアンインストールするには、以下を行います。

    • OpenShift Cluster Console にログインします。
    • Operator → Installed Operators にナビゲートし、アンインストールするOperator を検索します。
    • それぞれの Operator のオーバーフローメニューをクリックし、Uninstall Operator をクリックします。
21.3.1.3. パイプラインの実行

パイプラインを実行するには、tkn コマンドを実行するディレクトリーのテンプレートフォルダーに workspace-template.yml ファイルがあることを確認します。

workspace-template.yml ファイルを作成するには、ターミナルウィンドウで次のコマンドを実行します。 

cat <<EOF> workspace-template.yml
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
EOF

パイプラインはさまざまな 方法 で実行できます。

21.3.2. 手動プロセス

以下のステップに従って、OpenShift Operator パイプラインを手動でインストールします。

21.3.2.1. OpenShift Pipeline Operator のインストール
  1. OpenShift クラスターコンソールにログインします。
  2. メインメニューから、Operators > OperatorHub に移動します。
  3. すべてのアイテム - キーワードでフィルター フィルター/検索ボックスでフィルターに OpenShift Pipelines と入力します。
  4. 表示されたら、Red Hat OpenShift Pipelines タイルを選択します。Red Hat パイプラインページが表示されます。
  5. Install をクリックします。Install Operator Web ページが表示されます。
  6. 下にスクロールして、インストール をクリックします。
21.3.2.2. OpenShift (oc) CLI ツールの設定

クラスターへのアクセスを設定するために使用されるファイルは、kubeconfig ファイルと呼ばれます。これは、設定ファイルを参照する一般的な方法です。kubeconfig ファイルを使用して、クラスター、ユーザー、名前空間、および認証メカニズムに関する情報を整理します。

kubectl コマンドラインツールは、kubeconfig ファイルを使用して、クラスターを選択し、クラスターの API サーバーと通信するために必要な情報を検索します。

  1. ターミナルウィンドウで、KUBECONFIG 環境変数を設定します。 
export KUBECONFIG=/path/to/your/cluster/kubeconfig

kubeconfig ファイルは、テスト対象の Operator をデプロイし、認定チェックを実行します。

関連情報

kubeconfig ファイルの詳細については、kubeconfig ファイルを使用したクラスターアクセスの整理 を参照してください。

21.3.2.3. OpenShift プロジェクトの作成

新しい名前空間を作成して、パイプラインでの作業を開始します。

名前空間を作成するには、ターミナルウィンドウで次のコマンドを実行します。 

oc adm new-project <my-project-name> # create the project
oc project <my-project-name> # switch into the project
重要

デフォルトのプロジェクトまたは名前空間でパイプラインを実行しないでください。Red Hat は、パイプライン用の新しいプロジェクトを作成することをお勧めします。

21.3.2.4. kubeconfig シークレットの追加

認定パイプラインを実行しているクラスターへの認定用に、kubeconfig を含む kubernetes シークレットを作成します。認定パイプラインでは、OpenShift クラスターで Operator のテストデプロイメントを実行するために kubeconfig が必要です。

kubeconfig シークレットを追加するには、ターミナルウィンドウで次のコマンドを実行します。 

oc create secret generic kubeconfig --from-file=kubeconfig=$KUBECONFIG

関連情報

kubeconfig シークレットの詳細については、シークレット を参照してください。

21.3.2.5. Red Hat カタログからの Operator のインポート

Red Hat カタログ から演算子をインポートします。

ターミナルウィンドウで、次のコマンドを実行します。 

oc import-image certified-operator-index \
  --from=registry.redhat.io/redhat/certified-operator-index \
  --reference-policy local \
  --scheduled \
  --confirm \
  --all
oc import-image redhat-marketplace-index \
  --from=registry.redhat.io/redhat/redhat-marketplace-index \
  --reference-policy local \
  --scheduled \
  --confirm \
  --all
注記

IBM Power cluster for ppc64le アーキテクチャーで OpenShift を使用している場合は、許可の問題を回避するために以下のコマンドを実行してください。

oc adm policy add-scc-to-user anyuid -z pipeline

このコマンドは、デフォルトのパイプラインサービスアカウントに anyuid Security Context Constraints (SCC) を付与します。

21.3.2.6. 認定パイプラインの依存関係のインストール

ターミナルウィンドウで、次のコマンドを使用して、クラスターに認定パイプラインの依存関係をインストールします。 

$git clone https://github.com/redhat-openshift-ecosystem/operator-pipelines
$cd operator-pipelines
$oc apply -R -f ansible/roles/operator-pipeline/templates/openshift/pipelines
$oc apply -R -f ansible/roles/operator-pipeline/templates/openshift/tasks
21.3.2.7. 認定結果を送信するためのリポジトリーの設定

ターミナルウィンドウで、次のコマンドを実行して、認定結果を送信するためのリポジトリーを設定します。

21.3.2.7.1. GitHub API トークンの追加

すべての設定を実行した後、パイプラインは自動的にプルリクエストを開いて Operator を Red Hat に送信できます。

これを機能的に有効にするには、GitHub API トークンを追加し、パイプラインの実行時に --param submit=true を使用します。 

oc create secret generic github-api-token --from-literal GITHUB_TOKEN=<github token>
21.3.2.7.2. Red Hat Container API アクセスキーの追加

Red Hat から受け取る特定のコンテナー API アクセスキーを追加します。 

oc create secret generic pyxis-api-secret --from-literal pyxis_api_key=< API KEY >
21.3.2.7.3. ダイジェストの固定を有効にする
注記

このステップは、認定結果を Red Hat に送信するために必須です。

OpenShift Operator パイプラインは、バンドル内のすべてのイメージタグをイメージダイジェスト SHAs に自動的に置き換えることができます。これにより、パイプラインは、すべてのイメージの固定バージョンを使用しているかどうかを確認できます。パイプラインは、固定されたバージョンのバンドルを新しいブランチとして GitHub リポジトリーにコミットします。

この機能を有効にするには、GitHub にアクセスできる秘密鍵を秘密としてクラスターに追加します。

  1. Base64 を使用して、バンドルを含む GitHub リポジトリーにアクセスできる秘密鍵をエンコードします。 

    base64 /path/to/private/key

  2. base64 でエンコードされた秘密鍵を含むシークレットを作成します。 

    cat << EOF > ssh-secret.yml
kind: Secret
apiVersion: v1
metadata:
  name: github-ssh-credentials
data:
  id_rsa: |
    <base64 encoded private key>
EOF

  3. シークレットをクラスターに追加します。 

    oc create -f ssh-secret.yml
21.3.2.7.4. プライベートコンテナーレジストリーの使用

パイプラインは、テストと検証のために、Operator バンドルイメージとバンドルイメージインデックスを自動的に構築します。デフォルトでは、パイプラインはクラスター上の OpenShift Container Registry にイメージを作成します。外部プライベートレジストリーを使用する場合は、クラスターにシークレットを追加して資格情報を提供する必要があります。 

oc create secret docker-registry registry-dockerconfig-secret \
    --docker-server=quay.io \
    --docker-username=<registry username> \
    --docker-password=<registry password> \
    --docker-email=<registry email>

21.4. OpenShift Operator パイプラインを実行します

以下のメソッドを使用して、OpenShift Operator パイプラインを実行できます。

ヒント

次の例から、要件に応じてパラメーターとワークスペースを削除または追加します。

以前は Red Hat CodeReady Containers (CRC) と呼ばれていた Red Hat OpenShift Local、または ppc64le アーキテクチャー用の IBM Power 上の Red Hat OpenShift を使用している場合は、権限の問題を回避するために、すべての ci パイプラインコマンドに次の tekton CLI 引数を渡します。

--pod-template templates/crc-pod-template.yml

トラブルシューティング

OpenShift Pipelines Operator 1.9 以降が機能しない場合は、次の手順に従って修正してください。

前提条件

カスタム Security Context Constraints (SCC) を作成する前に、クラスターの管理者権限があることを確認してください。

手順

OpenShift Pipelines Operator 1.9 以降が機能し、特権エスカレーションが必要な ci-pipeline 内のタスクのサブセットを実行するには、次のコマンドを使用してカスタム Security Context Constraints (SCC) を作成し、それをパイプラインサービスアカウントにリンクします。

  1. 新規 SCC を作成するには、以下を実行します。 

    oc apply -f ansible/roles/operator-pipeline/templates/openshift/openshift-pipelines-custom-scc.yml

  2. 新しい SCC を ci-pipeline サービスアカウントに追加するには、以下を実行します。 

    oc adm policy add-scc-to-user pipelines-custom-scc -z pipeline

関連情報

SCC の詳細については、Security Context Constraints について を参照してください。

21.4.1. 最小限のパイプラインの実行

手順

ターミナルウィンドウで、次のコマンドを実行します。 

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (For example - operators/my-operator/1.2.8)

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --showlog

コマンドを実行した後、パイプラインは追加のパラメーターを指定するように要求します。すべてのデフォルト値を受け入れて、パイプラインの実行を終了します。

以下はデフォルトとして設定されており、明示的に含める必要はありませんが、kubeconfig シークレットが別の名前で作成されている場合はオーバーライドできます。 

--param kubeconfig_secret_name=kubeconfig \
--param kubeconfig_secret_key=kubeconfig

ppc64le および s390x アーキテクチャーで ci パイプラインを実行している場合は、パラメーター param pipeline_image の値をデフォルト値 quay.io/redhat-isv/operator-pipelines-images:released から quay.io/redhat-isv/operator-pipelines-images:multi-arch に編集します。

トラブルシューティング

SSH URL を使用しているときに Permission Denied エラーが発生した場合は、GITHUB HTTPS URL を試してください。

21.4.2. イメージダイジェストの固定でパイプラインを実行する

前提条件

ダイジェストピン留めの有効化 の手順を実行します。

手順

ターミナルウィンドウで、次のコマンドを実行します。 

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --showlog

トラブルシューティング

エラーが出される場合、could not read Username for https://github.com。--param git_repo_url の SSH github URL を指定します。

21.4.3. プライベートコンテナーレジストリーを使用してパイプラインを実行する

前提条件

プライベートコンテナーレジストリーを使用して に含まれている手順を実行します。

手順

ターミナルウィンドウで、次のコマンドを実行します。 

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>
REGISTRY=<your image registry.  ie: quay.io>
IMAGE_NAMESPACE=<namespace in the container registry>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --param registry=$REGISTRY \
  --param image_namespace=$IMAGE_NAMESPACE \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --workspace name=registry-credentials,secret=registry-docker config-secret \
  --showlog \

21.5. 認定結果の提出

次の手順は、認定テストの結果を Red Hat に送信するのに役立ちます。

前提条件

  1. 証明書の結果を送信するためのリポジトリーの設定 の手順を実行します。

  2. 以下のパラメーターを、Red Hat 認定のプルリクエストを送信する GitHub アップストリームリポジトリーに追加します。デフォルトでは Red Hat 認定リポジトリーですが、独自のリポジトリーをテストに使用できます。 

    -param upstream_repo_name=$UPSTREAM_REPO_NAME #Repo where Pull Request (PR) will be opened

--param submit=true

    以下はデフォルトとして設定されており、明示的に含める必要はありませんが、Pyxis シークレットが別の名前で作成されている場合はオーバーライドできます。 

    --param pyxis_api_key_secret_name=pyxis-api-secret \
--param pyxis_api_key_secret_key=pyxis_api_key

手順

次の 4 つの異なるシナリオで Red Hat 認定テストの結果を送信できます。

21.5.1. 最小限のパイプラインからテスト結果を送信する

手順

ターミナルウィンドウで、次のコマンドを実行します。 

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param upstream_repo_name=redhat-openshift-ecosystem/certified-operators \
  --param submit=true \
  --param env=prod \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --showlog

21.5.2. イメージダイジェストの固定を使用してテスト結果を送信する

ターミナルウィンドウで、次のコマンドを実行します。

前提条件

次の手順を実行します。

手順 

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --param upstream_repo_name=red-hat-openshift-ecosystem/certified-operators \
  --param submit=true \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --showlog

トラブルシューティング

エラーが出される場合、could not read Username for https://github.com。-param git_repo_url の SSH github URL を指定します。

21.5.3. プライベートコンテナーレジストリーからのテスト結果の送信

ターミナルウィンドウで、次のコマンドを実行します。

前提条件

次の手順を実行します。

手順 

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>
REGISTRY=<your image registry.  ie: quay.io>
IMAGE_NAMESPACE=<namespace in the container registry>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --param registry=$REGISTRY \
  --param image_namespace=$IMAGE_NAMESPACE \
  --param upstream_repo_name=red hat-openshift-ecosystem/certified-operators \
  --param submit=true \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --workspace name=registry-credentials,secret=registry-docker config-secret \
  --showlog

21.5.4. イメージダイジェストの固定とプライベートコンテナーレジストリーからのテスト結果の送信

ターミナルウィンドウで、次のコマンドを実行します。

前提条件

次の手順を実行します。

手順 

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>
REGISTRY=<your image registry.  ie: quay.io>
IMAGE_NAMESPACE=<namespace in the container registry>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --param upstream_repo_name=red-hat-openshift-ecosystem/certified-operators \
  --param registry=$REGISTRY \
  --param image_namespace=$IMAGE_NAMESPACE \
  --param submit=true \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --workspace name=registry-credentials,secret=registry-docker config-secret \
  --showlog

正常に認定されると、認定された製品は Red Hat Ecosystem Catalog に掲載されます。

認定された Operator は、組み込みの OpenShift operatorHub を介してお客様にリストされ、消費され、ソリューションを簡単にデプロイして実行する機能を提供します。さらに、製品と Operator イメージが Red Hat Ecosystem Catalog にリストされます。

第22章 Red Hat がホストするパイプラインで認定スイートを実行する

Red Hat Hosted Pipeline を使用して Operator を認定する場合は、Red Hat 認定リポジトリーのプルリクエストを作成する必要があります。

包括的なログの受信に関心がない場合、または独自の CI/CD ワークフローにツールを含める準備ができていない場合は、このパスを選択してください。

プロセスの概要は次のとおりです。

図22.1 Red Hat がホストするパイプラインの概要

Red Hat がホストするパイプラインでの認定テストの実行を視覚的に表したフローチャート

このプロセスは、GitHub プルリクエストを介して Operator バンドルを送信することから始まります。次に、Red Hat は、社内の OpenShift クラスターを使用して認定テストを実行します。このパスは、以前の Operator バンドル認定と同様です。認定テストの結果は、プルリクエストへのコメントと Red Hat Partner Connect Operator バンドルプロジェクト内の両方で確認できます。すべての認定テストが成功すると、Operator は自動的にマージされ、OpenShift の Red Hat Container Catalog および組み込み OperatorHub に公開されます。

指示に従って、Red Hat がホストするパイプラインで Operator を認定します。

前提条件

  • Red Hat Partner Connect Web サイトで入手可能な ソフトウェア認定前チェックリスト に記入します。

  • Red Hat Partner Connect Web サイトで、プロジェクト名 をクリックし、設定タブにナビゲートします。

    • 承認された GitHub ユーザーアカウント フィールドで、承認された GitHub ユーザーのリストに GitHub ユーザー名を入力します。
    • プライベートコンテナーレジストリーを使用している場合は、OpenShift Object YAML フィールドで、追加 をクリックして、docker config.json シークレットを追加し、保存 をクリックします。

手順

注記

この手順は、Red Hat がホストするパイプラインで Red Hat 認定を実行する場合にのみ実行してください。

22.1. リポジトリーのフォーク

  1. GitHub にログインし、RedHat OpenShift operators のアップストリームリポジトリーをフォークします。
  2. 配布の対象となるカタログに応じて、次の表から適切なリポジトリーをフォークします。
カタログアップストリームリポジトリー

認定カタログ

https://github.com/redhat-openshift-ecosystem/certified-operators

Red Hat Marketplace

https://github.com/redhat-openshift-ecosystem/redhat-marketplace-operators

  1. フォークされた認定 Operator リポジトリーのクローンを作成します。
  2. Operator バンドルのコンテンツを、フォークされたリポジトリーで使用可能な Operator ディレクトリーに追加します。

Operator バンドルを複数のカタログで公開する場合は、各カタログをフォークして、フォークごとに 1 回認定を完了することができます。

関連情報

GitHub でフォークを作成する方法の詳細については、フォークリポジトリー を参照してください。

22.2. Operator バンドルの追加

フォークの operators ディレクトリーには、一連のサブディレクトリーがあります。

22.2.1. 以前にこの Operator を認定したことがある場合

Operator ディレクトリーで、Operator のそれぞれのフォルダーを見つけます。Operator バンドルの内容をこのディレクトリーに配置します。

注記

パッケージ名が Operator の既存のフォルダー名と一致していることを確認してください。Red Hat Marketplace バンドルの場合、パッケージ名に接尾辞 -rhmp を手動で追加する必要があります。以前は、これは自動的に行われていたため、手動で変更してもお客様のアップグレードには影響しません。

22.2.2. この Operator を新たに認定する場合

新しく認定する Operator のサブディレクトリーが Operator の親ディレクトリーの下にない場合は、サブディレクトリーを作成する必要があります。

演算子の下に新しいディレクトリーを作成します。このディレクトリーの名前は、Operator のパッケージ名と一致している必要があります。たとえば、my-operator。

  • この operators ディレクトリーに、<my-operator> などの演算子の名前で新しいサブディレクトリーを作成し、<V1.0> などのバージョンディレクトリーを作成してバンドルを配置します。これらのディレクトリーは、以前に認定された Operator 用にプリロードされています。 

    ├── operators
    └── my-operator
        └── v1.0
  • バージョンディレクトリーの下に、clusterserviceversion.yaml ファイルを含むすべての OpenShift マニフェストを含む manifests フォルダーを追加します。

推奨されるディレクトリー構造

次の例は、推奨されるディレクトリー構造を示しています。 

├── config.yaml
├── operators
    └── my-operator
        ├── v1.4.8
        │   ├── manifests
        │   │   ├── cache.example.com_my-operators.yaml
        │   │   ├── my-operator-controller-manager-metrics-service_v1_service.yaml
        │   │   ├── my-operator-manager-config_v1_configmap.yaml
        │   │   ├── my-operator-metrics-reader_rbac.authorization.k8s.io_v1_clusterrole.yaml
        │   │   └── my-operator.clusterserviceversion.yaml
        │   └── metadata
        │       └── annotations.yaml
        └── ci.yaml
設定ファイル説明

config.yaml

このファイルには、Operator の組織が含まれています。certified-operators または redhat-marketplace にすることができます。例 organization: certified-operators

注記

Operator を Red Hat Marketplace ディストリビューションのターゲットにしている場合は、clusterserviceversion.yaml に次のアノテーションを含める必要があります。

marketplace.openshift.io/remote-workflow:https://marketplace.redhat.com/en-us/operators/ {package_name}/priceing?utm_source=openshift_console

marketplace.openshift.io/support-workflow:https://marketplace.redhat.com/en-us/operators/{package_name}/support?utm_source=openshift_console

ci.yaml

このファイルには、Red Hat テクノロジーパートナーのプロジェクト ID と、この Operator の組織ターゲットが含まれています。

例 cert_project_id: <your partner project id>。このファイルには、認定プロセスを成功させるために必要なすべてのメタデータが保存されています。

annotations.yaml

このファイルには、OpenShift バージョンの範囲を参照する OpenShift バージョンのアノテーションが含まれています。たとえば、v4.8-v4.10 は、バージョン 4.8 から 4.10 を意味します。これを既存のコンテンツに追加します。

例: # OpenShift annotations com.redhat.openshift.versions: v4.8-v4.10Operator バンドルのメタデータの一部である com.redhat.openshift.versions フィールドは、特定の OpenShift バージョンの認定カタログに Operator が含まれているかどうかを判断するために使用されます。Operator がサポートする OpenShift の 1 つ以上のバージョンを示すために使用する必要があります。

バージョンの前に文字 v を使用する必要があり、スペースは使用できないことに注意してください。構文は次のとおりです。

  • 単一バージョンは、Operator がそのバージョンの OpenShift 以降でサポートされていることを示します。Operator は、以降のすべての OpenShift リリースの認定カタログに自動的に追加されます。
  • = が前に付いた単一のバージョンは、Operator がその特定のバージョンの OpenShift でのみサポートされることを示します。たとえば、=v4.8 を使用すると、OpenShift 4.8 の認定カタログに Operator が追加されますが、それ以降の OpenShift リリースでは追加されません。
  • 範囲を使用して、その範囲内の OpenShift バージョンのみのサポートを示すことができます。たとえば、v4.8-v4.10 を使用すると、Operator は OpenShift 4.8 から 4.10 の認定カタログに追加されますが、OpenShift 4.11 または 4.12 には追加されません。

関連情報

22.3. プルリクエストの作成

最後のステップは、ターゲットのアップストリームリポジトリーのプルリクエストを作成することです。

カタログアップストリームリポジトリー

認定カタログ

https://github.com/redhat-openshift-ecosystem/certified-operators

Red Hat Marketplace

https://github.com/redhat-openshift-ecosystem/redhat-marketplace-operators

Operator バンドルを複数のカタログで公開する場合は、ターゲットカタログごとにプルリクエストを作成できます。

GitHub でプルリクエストを作成することに慣れていない場合は、ここ で手順を見つけることができます。

注記

プルリクエストのタイトルは、次の形式に準拠している必要があります。operator my-operator (v1.4.8)単語 operator で始まり、Operator パッケージ名、括弧内のバージョン番号が続きます。
プルリクエストを作成すると、Red Hat がホストするパイプラインがトリガーされ、失敗または完了したときにプルリクエストコメントを介して更新が提供されます。

22.3.1. 従うべきガイドライン

  • プルリクエストを閉じて再度開くことで、Red Hat がホストするパイプラインを再トリガーできます。
  • 特定の Operator バージョンに対して、一度に開くことができるプルリクエストは 1 つだけです。
  • プルリクエストが正常にマージされると、変更することはできません。Operator のバージョンをバンプして、新しいプルリクエストを開く必要があります。
  • 演算子の下に作成したディレクトリー名として、演算子のパッケージ名を使用する必要があります。このパッケージ名は、annotations.yaml ファイルのパッケージアノテーションと一致する必要があります。このパッケージ名は、clusterserviceversion.yaml ファイル名の接頭辞とも一致する必要があります。
  • プルリクエストは、単一の Operator バージョンディレクトリー内のファイルのみを変更する必要があります。複数のバージョンへの更新または複数の Operator にわたる更新を組み合わせようとしないでください。
  • バージョンディレクトリーに名前を付けるために使用されるバージョンインジケーターは、プルリクエストのタイトルで使用されるバージョンインジケーターと一致する必要があります。
  • 認定テストの実行にはイメージタグは使用できません。SHA ダイジェストのみが使用されます。イメージタグへのすべての参照 を対応する SHA ダイジェストに置き換えます。

第23章 認定 Operator の公開

認定は完了したと見なされ、すべてのテストに合格すると、Operator が Red Hat Container Catalog および OpenShift 内の組み込み OperatorHub に表示され、認定パイプラインが RedHat に結果を送信できるようになります。

さらに、エントリーは Red Hat 認定エコシステム に表示されます。

重要

Red Hat OpenShift ソフトウェア認定は、パートナーの製品が Operator コンストラクトの外部でどのように機能または実行されるか、およびインストールおよび実行された Red Hat プラットフォームへの影響についてテストを行いません。認定候補製品の品質保証は、すべてパートナーの責任において行われるものとします。

第24章 トラブルシューティングガイドライン

トラブルシューティングのヒントと回避策については、 Operator 証明書パイプラインのトラブルシューティング を参照してください。

付録B Helm と Ansible Operator

パート IV. Helm チャート認定

第25章 Helm チャートの使用

注記

Red Hat Helm チャートの認定に進む前に、コンテナーアプリケーションプロジェクトを認定してください。Helm チャートプロジェクトを認定する前に、Helm チャートプロジェクトで参照されるすべてのコンテナーがすでに認定され、Red Hat Ecosystem Catalog で公開されている必要があります。

25.1. Helm チャートの概要

Helm は、Kubernetes ネイティブの自動化テクノロジーおよびソフトウェアパッケージマネージャーであり、アプリケーションとサービスのデプロイを簡素化します。Helm はチャートというパッケージ形式を使用します。チャートは、関連する Kubernetes リソースのセットを説明するファイルのコレクションです。クラスター内のチャートにおける特定バージョンの実行中のインスタンスは、リリースと呼ばれます。チャートがクラスターにインストールされているたびに、新規のリリースが作成されます。チャートのインストール時、またはリリースがアップグレードまたはロールバックされるたびに、増分リビジョンが作成されます。チャートは、自動化された Red Hat OpenShift 認定ワークフローを経て、セキュリティーコンプライアンスを確保し、プラットフォームとの統合とサービス全般が最適であることを保証します。

25.2. Helm チャートの認定ワークフロー

注記

Red Hat では、Red Hat 認定エンジニアまたは同等の経験を有するユーザーが、認定プロセスを開始することを推奨しています。

次の図は、Helm チャートのテストの概要を示しています。

このセクションで説明する Helm チャート認定ワークフローを視覚的に表現したフローチャート。

タスクの概要

認定ワークフローには、3 つの主要なステップが含まれます -

  1. 「認定のオンボード」
  2. 「認定テスト」
  3. 「認定 Helm チャートを Red Hat エコシステムカタログに公開する」

25.2.1. 認定のオンボード

前提条件

特定の認定テスト要件に加えて、ターゲット Red Hat プラットフォームで製品の機能を確認します。ターゲット Red Hat プラットフォームで製品を実行すると標準以下のエクスペリエンスが得られる場合は、認定前に問題を解決する必要があります。

Red Hat Partner Acceleration Desk (PAD) は、製品およびテクノロジーレベルのパートナーヘルプデスクサービスであり、(将来の) テクノロジーパートナーが、Red Hat のオファリング、パートナープログラム、製品認定、エンゲージメントプロセスなどに関する非技術的な質問を一元的に行える場所です。

PAD - PAD ケースの作成方法と管理方法 を参照して、PAD チケットを作成します。

Partner Subscriptions プログラムを通じて、Red Hat は、対象の Red Hat プラットフォームで製品を検証するために使用できる無料の非再販ソフトウェアサブスクリプションを提供します。プログラムへのアクセスをリクエストするには、Partner Subscriptions サイトの指示に従ってください。

コンテナーイメージは、認定基準とポリシーを満たすように作成する必要があります。詳細は、イメージコンテンツの要件 を参照してください。

手順

Helm チャートを認定するには、次の大まかな手順に従います。

  1. Red Hat Partner Connect for Technology Partner Program に参加してください。
  2. プログラムの利用規約に同意します。
  3. 会社プロファイルに記入します。
  4. 目的のプラットフォームを選択して、認定プロジェクトを作成します。たとえば、Red Hat OpenShift を選択してから、Helm chart を選択します。
  5. 認定前チェックリストに記入します。

関連情報

最初の Helm チャートプロジェクトの作成に関する詳細な手順については、 Helm チャートプロジェクトの作成 を参照してください。

25.2.2. 認定テスト

次の概要手順に従って、認定テストを実行します。

  1. Red Hat アップストリームリポジトリー をフォークします。
  2. テスト環境に チャート検証 ツールをインストールして実行します。
  3. テスト結果を確認し、問題がある場合はトラブルシューティングします。
  4. プルリクエストを介して認定結果を Red Hat に送信します。

関連情報

認定テストの詳細な手順については、認定のための Helm チャートの検証 を参照してください。

25.2.3. 認定 Helm チャートを Red Hat エコシステムカタログに公開する

認定された Helm チャートは Red Hat partner connect ポータル の 製品リスト ページで公開され、その後サポートされている Red Hat コンテナープラットフォームで実行できます。製品と Helm チャートは、提供されたリスト情報を使用して Red Hat Container Catalog にリストされます。

関連情報

第26章 認定のための Helm チャートの検証

chart-verifier CLI ツールを使用して、Helm チャートを検証できます。chart-verifier は、設定可能なチェックのリストを実行して、Helm チャートに Red Hat 認定基準を満たすために必要な関連メタデータと書式設定がすべて備わっているかどうかを検証する、CLI ベースのオープンソースツールです。Helm チャートの配布準備ができており、Red Hat OpenShift Container Platform 上でシームレスに動作し、認定された Helm チャートエントリーとして Red Hat OpenShift Helm チャートリポジトリー に送信できるかどうかを検証します。

このツールは、Helm チャートの URL も検証し、各チェックで肯定的または否定的な結果が得られる人間が判読可能な説明を含むレポートを YAML 形式で提供します。チェックの結果が否定的な場合は、チャートに問題があることを示しており、修正が必要です。検証プロセス中に実行するチェックをカスタマイズすることもできます。

注記

Red Hat では、最新バージョンの chart-verifier ツールを使用して、ローカルテスト環境で Helm チャートを検証することを強く推奨しています。これにより、チャート開発サイクル中に結果を自分で確認できるようになり、毎回結果を Red Hat に送信する必要がなくなります。

関連情報

chart-verifier CLI ツールの詳細は、chart-verifier を参照してください。

26.1. テスト環境の準備

製品を認定するための最初のステップは、テストを実行できる環境をセットアップすることです。chart-verifier テストの完全なセットを実行するには、Red Hat OpenShift クラスター環境へのアクセスが必要です。この環境では、chart-verifier ツールをインストールし、チャート関連のすべてのテストを実行できます。これらのテストは、いくつかの設定可能なコマンドラインオプションを使用して無効にすることができますが、Red Hat が認定を承認するにはテストの実行は必須となります。

注記

認定された Red Hat パートナーは、Red Hat OpenShift Container Platform に無料でアクセスでき、Red Hat Partner Subscription (RHPS) プログラムを使用して独自のテスト環境にクラスターをインストールできます。Red Hat Partner Connect プログラムの一環としてのソフトウェアアクセスの利点に関する詳細は、プログラムガイドを 参照してください。

独自のテスト環境をセットアップするには、以下を実行します。

  1. Red Hat Managed Services Openshift クラスター を使用して、フルマネージドクラスターをインストールします。これは 60 日間のみ有効な試用オプションです。
  2. クラウド環境、データセンター、またはコンピューターにインストールできる自己管理型クラスターをインストールします。このオプションを使用すると、NFR とも呼ばれるパートナーサブスクリプションを永続的なデプロイメントに使用できます。

環境のセットアップの詳細は、Red Hat OpenShift を試す を参照してください。

関連情報

クラスターのインストールと Helm チャートの設定に関する詳細は、以下を参照してください。

26.2. Helm chart-verifier ツールの実行

chart-verifier ツールを実行するための推奨ディレクトリー構造は次のとおりです。 

.
└── src
    ├── Chart.yaml
    ├── README.md
    ├── templates
    │   ├── deployment.yaml
    │   ├── _helpers.tpl
    │   ├── hpa.yaml
    │   ├── ingress.yaml
    │   ├── NOTES.txt
    │   ├── serviceaccount.yaml
    │   ├── service.yaml
    │   └── tests
    │       └── test-connection.yaml
    ├── values.schema.json
    └── values.yaml

前提条件

  • Podman または Docker CLI がインストールされているコンテナーエンジン
  • イメージが Red Hat 認定されていることを確認するためのインターネット接続
  • OpenShift Helm チャートリポジトリー にチャートを送信するための GitHub プロファイル
  • Red Hat OpenShift Container Platform クラスター

  • chart-verifier ツールを実行する前に、以下のコマンドを使用して Helm チャートをパッケージ化 

    $ helm package <helmchart folder>

    このコマンドは、Helm チャートをアーカイブし、.tgz ファイル形式に変換します。

手順

次の 2 つの方法を使用して、chart-verifier ツールの完全なセットを実行できます。

26.2.1. Podman または Docker を使用する方法

  1. kube config ファイルが ${HOME}/.kube: ロケーションにあると仮定し、ユニバーサルリソース識別子 (uri) を使用して、リモートで利用可能なチャートに対して利用可能なすべてのチェックを実行します。 

    $ podman run --rm -i                                  \
        -e KUBECONFIG=/.kube/config                   \
        -v "${HOME}/.kube":/.kube                     \
        "quay.io/redhat-certification/chart-verifier" \
        verify                                        \
        <chart-uri>

    このコマンドの chart-uri は、https uri で利用可能なチャートアーカイブの場所です。アーカイブが .tgz 形式である必要があることを確認してください。

  2. チャートが現在のディレクトリーで利用可能であり、kube config ファイルが ${HOME}/.kube ロケーションで利用可能であると仮定して、システム上でローカルに利用可能なチャートに対して利用可能なチェックをすべて実行します。 

    $ podman run --rm                                     \
        -e KUBECONFIG=/.kube/config                   \
        -v "${HOME}/.kube":/.kube                     \
        -v $(pwd):/charts                             \
        "quay.io/redhat-certification/chart-verifier" \
        verify                                        \
        /charts/<chart>

    このコマンドの chart-uri は、ローカルディレクトリーで利用可能なチャートアーカイブの場所です。アーカイブが .tgz 形式である必要があることを確認してください。

  3. 次の verify コマンドを実行して、コマンドに関連付けられている使用可能なオプションのリストとその使用方法を取得します。 

    $ podman run -it --rm quay.io/redhat-certification/chart-verifier verify --help

    コマンドの出力は次の例のようになります。 

    Verifies a Helm chart by checking some of its characteristics

Usage:
  chart-verifier verify <chart-uri> [flags]

Flags:
  -S, --chart-set strings           set values for the chart (can specify multiple or separate values with commas: key1=val1,key2=val2)
  -G, --chart-set-file strings      set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2)
  -X, --chart-set-string strings    set STRING values for the chart (can specify multiple or separate values with commas: key1=val1,key2=val2)
  -F, --chart-values strings        specify values in a YAML file or a URL (can specify multiple)
      --debug                       enable verbose output
  -x, --disable strings             all checks will be enabled except the informed ones
  -e, --enable strings              only the informed checks will be enabled
      --helm-install-timeout duration   helm install timeout (default 5m0s)
  -h, --help                        help for verify
      --kube-apiserver string       the address and the port for the Kubernetes API server
      --kube-as-group stringArray   group to impersonate for the operation, this flag can be repeated to specify multiple groups.
      --kube-as-user string         username to impersonate for the operation
      --kube-ca-file string         the certificate authority file for the Kubernetes API server connection
      --kube-context string         name of the kubeconfig context to use
      --kube-token string           bearer token used for authentication
      --kubeconfig string           path to the kubeconfig file
  -n, --namespace string            namespace scope for this request
  -V, --openshift-version string    set the value of certifiedOpenShiftVersions in the report
  -o, --output string               the output format: default, json or yaml
  -k, --pgp-public-key string       file containing gpg public key of the key used to sign the chart
  -W, --web-catalog-only            set this to indicate that the distribution method is web catalog only (default: false)
      --registry-config string      path to the registry config file (default "/home/baiju/.config/helm/registry.json")
      --repository-cache string     path to the file containing cached repository indexes (default "/home/baiju/.cache/helm/repository")
      --repository-config string    path to the file containing repository names and URLs (default "/home/baiju/.config/helm/repositories.yaml")
  -s, --set strings                 overrides a configuration, e.g: dummy.ok=false
  -f, --set-values strings          specify application and check configuration values in a YAML file or a URL (can specify multiple)
  -E, --suppress-error-log          suppress the error log (default: written to ./chartverifier/verifier-<timestamp>.log)
      --timeout duration            time to wait for completion of chart install and test (default 30m0s)
  -w, --write-to-file               write report to ./chartverifier/report.yaml (default: stdout)
Global Flags:
      --config string   config file (default is $HOME/.chart-verifier.yaml)

  4. チェックのサブセットを実行します。 

    $ podman run --rm -i                                  \
        -e KUBECONFIG=/.kube/config                   \
        -v "${HOME}/.kube":/.kube                     \
        "quay.io/redhat-certification/chart-verifier" \
        verify -enable images-are-certified,helm-lint      \
        <chart-uri>

  5. サブセットを除くすべてのチェックを実行します。 

    $ podman run --rm -i                                  \
        -e KUBECONFIG=/.kube/config                   \
        -v "${HOME}/.kube":/.kube                     \
        "quay.io/redhat-certification/chart-verifier" \
        verify -disable images-are-certified,helm-lint      \
        <chart-uri>
    注記

    チェックのサブセットを実行することは、開発のフィードバックループを減らすことを目的としています。チャートを認定するには、必要なチェックをすべて実行する必要があります。

  6. chart-override 値を指定します。 

    $ podman run --rm -i                                  \
        -e KUBECONFIG=/.kube/config                   \
        -v "${HOME}/.kube":/.kube                     \
        "quay.io/redhat-certification/chart-verifier" \
        verify –chart-set default.port=8080                   \
        <chart-uri>

  7. 現在のディレクトリーにあるファイルから chart-override 値を指定します。 

    $ podman run --rm -i                                  \
        -e KUBECONFIG=/.kube/config                   \
        -v "${HOME}/.kube":/.kube                     \
        -v $(pwd):/values                             \
        "quay.io/redhat-certification/chart-verifier" \
        verify –chart-values /values/overrides.yaml              \
        <chart-uri>
26.2.1.1. タイムアウトオプションの設定

chart-testing プロセスが遅延する場合は、タイムアウト値を増やします。デフォルトでは、chart-testing プロセスが完了するまでに約 30 分かかります。 

$ podman run --rm -i                                  \
        -e KUBECONFIG=/.kube/config                   \
        -v "${HOME}/.kube":/.kube                     \
        -v $(pwd):/values                             \
        "quay.io/redhat-certification/chart-verifier" \
        verify --timeout 40m                          \
        <chart-uri>
注記

chart-testing プロセスに遅れが見られる場合は、Red Hat では、検証のためにレポートを Red Hat 認定チームに提出することを推奨しています。

26.2.1.2. レポートの保存

chart-testing プロセスが完了すると、デフォルトでレポートメッセージが表示されます。レポートは、ファイルにリダイレクトすることで保存できます。

以下に例を示します。 

  $ podman run --rm -i                                  \
          -e KUBECONFIG=/.kube/config                   \
          -v "${HOME}/.kube":/.kube                     \
          "quay.io/redhat-certification/chart-verifier" \
          verify –enable images-are-certified,helm-lint      \
          <chart-uri> > report.yaml

このコマンドとともに -w オプションを使用して、レポートを ./chartverifier/report.yaml ファイルに直接書き込みます。このファイルを取得するには、ファイルを /app/chartverifer にボリュームマウントする必要があります。

以下に例を示します。 

  $ podman run --rm -i                                  \
          -e KUBECONFIG=/.kube/config                   \
          -v "${HOME}/.kube":/.kube                     \
          -v $(pwd)/chartverifier:/app/chartverifier    \
          -w                                            \
          "quay.io/redhat-certification/chart-verifier" \
          verify –enable images-are-certified,helm-lint      \
          <chart-uri>

ファイルがすでに存在する場合は、新しいレポートによって上書きされます。

26.2.1.3. エラーログの設定

デフォルトでは、エラーログが生成され、./chartverifier/verify-<timestamp>.yaml ファイルに保存されます。これには、エラーメッセージ、各チェックの結果、チャートテストに関する追加情報が含まれます。エラーログのコピーを取得するには、ファイルを /app/chartverifer にボリュームマウントする必要があります。

以下に例を示します。 

 $ podman run --rm -i                                  \
          -e KUBECONFIG=/.kube/config                   \
          -v "${HOME}/.kube":/.kube                     \
          -v $(pwd)/chartverifier:/app/chartverifier    \
          "quay.io/redhat-certification/chart-verifier" \
          verify –enable images-are-certified,helm-lint      \
          <chart-uri> > report.yaml

複数のログを同じディレクトリーに保存する場合は、一度に最大 10 個のログファイルを保存できます。ファイルの最大制限に達すると、古いログファイルが新しいログファイルに自動的に置き換えられます。

エラーログ出力を抑制するには、-E または –suppress-error-log オプションを使用します。

注記

エラーおよび警告メッセージは標準エラー出力メッセージであり、-E または –suppress-error-log オプションを使用しても抑制されません。

26.2.2. バイナリーファイルを使用する場合

注記

この方法は Linux システムにのみ適用できます。

  1. リリース ページから最新の chart-verifier バイナリーをダウンロードしてインストールします。

  2. 次のコマンドを使用して、tarball バイナリーを展開します。 

    $ tar zxvf <tarball>

  3. 展開したディレクトリーで次のコマンドを実行して、すべての Helm チャートチェックを実行します。 

    $ ./chart-verifier verify <chart-uri>

    このコマンドでは、chart-uri はサーバー上で利用可能なチャートアーカイブの場所です。アーカイブが .tgz 形式である必要があることを確認してください。デフォルトでは、chart-verifier ツールは、kube config ファイルがデフォルトの $HOME/.kube ロケーションにあると想定します。ファイルがデフォルトのロケーションにない場合は、環境変数を KUBECONFIG に設定します。

    chart-verifier ツールの出力には、実行されたテストの詳細と各テストの結果ステータスが含まれます。また、各テストが Red Hat 認定に必須であるか、推奨されているかも示します。詳細は、Helm チャートチェックのタイプ を参照してください。

関連情報

chart-verifier ツールの詳細は、Red Hat OpenShift 認定の Helm チャートチェック を参照してください。

第27章 Helm チャートプロジェクトの作成

前提条件

Helm チャートプロジェクトを作成する前に、チャートのコンテナーイメージをコンテナーアプリケーションプロジェクトとして認定します。

手順

  1. Red Hat Partner Connect ポータル にログインします。

    パートナーポータルへのアクセス Web ページが表示されます。

  2. 認定テクノロジーポータル タイルに移動し、テクノロジーパートナーのログイン をクリックします。

  3. ログイン資格情報を入力し、ログイン をクリックします。

    Red Hat Partner Connect の Web ページが表示されます。

  4. ページヘッダーで、製品認定 を選択し、認定プロジェクトの管理 をクリックします。

    My Work Web ページには、製品リスト と利用可能な場合 認定プロジェクト が表示されます。

  5. Create Project をクリックします。
  6. 認定するプラットフォーム ダイアログボックスで、Red Hat OpenShift ラジオボタンを選択し、次へ をクリックします。
  7. What do you want to certify? ダイアログボックスで、Helm chart ラジオボタンを選択し、Next をクリックします。

  8. Create Helm chart certification project Web ページで、プロジェクトを作成するために次の詳細を入力します。

    重要

    プロジェクトの作成後に、プロジェクト名とその配布方法を変更することはできません。

    1. Project Name - プロジェクト名を入力します。この名前は公開されておらず、内部使用のみを目的としています。
    2. チャート名: チャートの名前。Helm 命名規則 に従う必要があります。

    3. 配布方法 - Helm チャートを公開するには、次のオプションのいずれかを選択します。

      1. Helm チャートリポジトリー charts.openshift.io - Helm チャートは Red Hat Helm チャートリポジトリー (charts.openshift.io) に公開され、ユーザーはこのリポジトリーからチャートをプルできます。

        注記

        The certified helm chart will be distributed from my company’s repository チェックボックスを選択すると、チャートのロケーションに関するエントリーが Red Hat Helm チャートリポジトリー charts.openshift.io のインデックスに追加されます。

      2. Web カタログのみ (catalog.redhat.com) - Helm チャートは Red Hat Helm チャートリポジトリー charts.openshift.io には公開されず、Red Hat OpenShift OperatorHub または Red Hat Marketplace のいずれにも表示されません。これは、新しいプロジェクトを作成するときのデフォルトのオプションです。このオプションは、Helm チャートを OpenShift 内にパブリックにインストールしたくないが、認定の証明が必要なパートナーに適しています。このオプションは、OpenShift 製品内カタログ (認定済み) オプションに含まれていないディストリビューション、資格、またはその他のビジネス要件がある場合にのみ選択してください。
    4. Create project をクリックします。

関連情報

配布方法の詳細は、 Helm チャートの配布方法 を参照してください。

第28章 Helm チャートプロジェクトの設定

プロジェクトが作成されると、新しく作成された Helm チャートプロジェクトの Web ページが表示されます。

Helm チャート Web ページは、次のタブで構成されています。

  • Overview - 認定前チェックリストが含まれます。
  • Settings - レジストリーとリポジトリーの詳細を設定できます。

Helm チャート Web ページの右側で Actions メニューをクリックし、新しく作成された Helm チャートプロジェクトに対して次の操作を実行します。

28.1. 完全な認定前チェックリスト

Helm チャートプロジェクトの Overview タブには、認定前チェックリストが含まれています。認定前チェックリストは、Helm チャートを認定および公開するために完了する必要のある一連のタスクで構成されています。

Helm チャートを公開する前に、チェックリストで次のタスクを実行します。

28.1.1. 会社プロファイルを完了する

会社のプロファイルを最新の状態に保ちます。この情報は、認定製品とともに Red Hat Ecosystem Catalog に公開されます。

確認するには、以下を実行します。

  1. Complete your company profile タイルに移動します。
  2. チェックリストの Review をクリックします。
  3. 変更を加えるには、Edit をクリックします。
  4. Submit をクリックします。

28.1.2. Helm チャートの詳細を入力する

  1. Provide details for your Helm chart タイルに移動して、Red Hat Ecosystem Catalog に表示されるリポジトリーの詳細を入力し、ユーザーが Helm チャートをプルできるようにします。
  2. Add details をクリックします。Settings タブに移動します。
  3. 必要なすべてのリポジトリー情報を入力します。
  4. すべての情報を入力したら、Save をクリックします。
注記

アスタリスク * が付いているフィールドはすべて必須であり、Helm チャート認定を続行する前に入力を完了する必要があります。

28.1.3. GitHub のプルリクエストを通じてチャートを送信する

Red Hat Partner Connect で Helm チャートプロジェクトを作成した後、検証のために Helm チャートを送信する必要があります。

Helm チャートを送信するには、以下を行います。

  1. Submit your chart through a pull request in GitHub タイルに移動します。
  2. Go to GitHub をクリックします。OpenShift Helm Charts リポジトリー にリダイレクトされます。
  3. プルリクエストを送信する

プルリクエストは Red Hat 認定チームによってレビューされます。検証が正常に行われると、Helm チャートが Red Hat Ecosystem Catalog に公開されます。

関連情報

プルリクエストの送信に関する詳細は、5 を参照してください。Helm チャートを認定のために提出します。

28.1.4. 完了済み製品リストを添付する

この機能を使用すると、新しい製品リストを作成するか、新しいプロジェクトの既存の OpenShift 製品リストにプロジェクトを添付できます。

  1. Attach a completed product listing タイルに移動します。
  2. Select method ドロップダウンメニューから、Attach または edit を選択します。Attach product listing ページが表示されます。

  3. プロジェクトを既存の製品リストにアタッチするか、新しい製品リストを作成するかを決定します。

    1. プロジェクトを既存の製品リストに添付するには:

      1. Related product listing セクションから、Select a product listing ドロップダウン矢印をクリックして、必要な製品リストを選択します。
      2. Save をクリックします。

    2. 新しい商品リストを作成するには:

      1. Create new product listing をクリックします。
      2. Product Name テキストボックスに、必要な製品名を入力します。
      3. Save をクリックします。
    3. Select method ドロップダウンメニューから、View product listing をクリックして、新しい製品リストに移動し、必要な製品リストの詳細をすべて入力します。
    4. Save をクリックします。
注記

認定の申請書を提出する前に、認定前チェックリストのすべての項目を必ず完了してください。

すべての手順を完了すると、タイルの横に緑色のチェックマークが表示され、設定が完了したことを示します。

28.2. プロジェクト設定の管理

Settings タブから、レジストリーとリポジトリーの詳細を設定できます。Helm チャートが検証されると、次の詳細とともに Red Hat Ecosystem Catalog に公開されます。

以下のフィールドに必要な詳細を入力します。

注記

以下のフィールドは、選択した配布方法によって異なります。

  • Chart name
  • Container registry namespace - 会社名または略称を表します。
  • Helm chart repository - Helm チャートリポジトリーのロケーションを示します。
  • ユーザーが Helm チャートにアクセスするための Any additional instructions - この情報は、Red Hat Ecosystem Catalog に公開されます。
  • Public PGP Key - これはオプションのフィールドです。認定テスト結果に署名する場合は、キーを入力します。
  • Authorized GitHub user accounts - 会社に代わって認定のために Helm チャートを送信できる GitHub ユーザーを示します。
  • Short and Long repository descriptions and Application categories - この情報は、Red Hat Ecosystem Catalog に Helm チャートを掲載するときに使用されます。
  • Project Details - これには、プロジェクト名、技術担当者 および 電子メールアドレス が含まれます。この情報は、認定プロジェクトに固有の問題がある場合に Red Hat が連絡するために使用されます。
  • Save をクリックします。
注記

アスタリスク * が付いているすべてのフィールドは必須であり、Helm チャート認定を続行する前に入力を完了する必要があります。

第29章 認定に向けた Helm チャートの提出

Red Hat Partner Connect で Helm チャートプロジェクトを設定およびセットアップした後、Red Hat の OpenShift Helm チャートリポジトリー へのプルリクエストを作成して、Helm チャートを認定のために送信します。プルリクエストには、chart-verifier ツール によって生成されたチャートまたはレポート、あるいはその両方を含めることができます。プルリクエストの内容に基づいてチャートが認定され、レポートが提供されない場合は chart-verifier ツールが実行されます。

前提条件

プルリクエストを作成する前に、次の前提条件を満たしていることを確認してください。

  1. Red Hat の OpenShift Helm チャートリポジトリー をフォークし、ローカルシステムにクローンを作成します。ここでは、パートナーのディレクトリーの下にお客様の会社用にディレクトリーがすでに作成されていることを確認できます。

    注記

    ディレクトリー名は、コンテナーの認定時に設定したコンテナーレジストリーの名前空間と同じです。

    会社のディレクトリー内には、前の手順で作成したチャート認定プロジェクトごとにサブディレクトリーが存在します。これが正しくセットアップされているかどうかを確認するには、OWNERS ファイルを確認してください。OWNERS ファイルは、組織ディレクトリー内のチャートディレクトリーに自動的に作成されます。これには、会社を代表して Helm チャートを認定する権限を与えられた GitHub ユーザーなど、プロジェクトに関する情報が含まれています。ファイルは charts/partners/acme/awesome/OWNERS にあります。GitHub ユーザーの詳細を編集する場合は、Settings ページに移動します。

    たとえば、組織名が acme で、チャート名が awesome の場合は、以下のようになります。OWNERS ファイルの内容は次のとおりです。 

    chart:
  name: awesome
  shortDescription: A Helm chart for Awesomeness
publicPgpKey: null
providerDelivery: False
users:
  - githubUsername: <username-one>
  - githubUsername: <username-two>
vendor:
  label: acme
  name: ACME Inc.

    送信するチャートの名前は、OWNERS ファイル内の値と一致する必要があります。

  2. Helm チャートのソースまたは Helm チャート検証レポートを送信する前に、そのバージョン番号を含むディレクトリーを作成します。たとえば、awesome チャートの 0.1.0 version を公開する場合は、次のようにディレクトリーを作成します。 

    charts/partners/acme/awesome/0.1.0/
    注記

    Red Hat がサポートする製品を表すチャートの場合は、組織ディレクトリー内の redhat ディレクトリーのチャートにある OWNERS ファイルを使用して、プルリクエストをメインブランチに送信します。たとえば、awesome という名前の Red Hat チャートの場合、charts/redhat/redhat/awesome/OWNERS にあるメインブランチにプルリクエストを送信します。Red Hat がサポートするプロジェクトの場合、組織名も redhat になることに注意してください。

手順

Helm チャートを認定のために送信するには、次の 3 つの方法を使用します。

  1. チャート検証レポートなしで Helm チャートを送信する方法
  2. Helm チャートを使用せずにチャート検証レポートを送信する方法
  3. Helm チャートと共にチャート検証レポートを送信する方法

29.1. チャート検証レポートなしで Helm チャートを送信する

Helm チャートは、チャート検証レポートなしで、次の 2 つの異なる形式で認定のために送信できます。

29.1.1. tarball としてのチャート

Helm チャートを tarball として送信する場合は、helm package コマンドを使用して Helm チャートの tarball を作成し、それを 0.1.0 ディレクトリーに直接配置できます。

たとえば、Helm チャートが acme 組織の awesome の場合 

charts/partners/acme/awesome/0.1.0/awesome-0.1.0.tgz
charts/partners/acme/awesome/0.1.0/awesome-0.1.0.tgz.prov

29.1.2. ディレクトリー内のチャート

Helm チャートをディレクトリーに送信する場合は、Helm チャートをチャートソースのあるディレクトリーに配置します。

チャートに署名した場合は、providence ファイルを同じディレクトリーに置きます。OWNERS ファイルには、チャートの base64 でエンコードされた公開鍵を含めることができます。base64 でエンコードされた公開鍵が存在する場合、chart-verifier を使用してチャートのレポートを作成するときにキーがデコードされて指定されます。

公開鍵がチャートと一致しない場合、検証者レポートにはチェックの失敗が含まれ、プルリクエストはエラーで終了します。

公開鍵がチャートと一致し、他に問題がない場合は、tarball、providence ファイル、公開鍵ファイル、生成されたレポートを含むリリースが作成されます。

以下に例を示します。 

awesome-0.1.0.tgz
awesome-0.1.0.tgz.prov
awesome-0.1.0.tgz.key
report.yaml

OWNERS ファイルに公開鍵が含まれていない場合、チャート検証者チェックはスキップされ、プルリクエストの結果には影響しません。さらに、公開鍵ファイルはリリースには含まれません。

チャートがチャートソースを含むディレクトリーである場合は、チャートソースを配置するための src ディレクトリーを作成します。

以下に例を示します。

Path は、charts/partners/acme/awesome/0.1.0/src/ になります。

ファイル構造は次のようになります 

.
└── src
    ├── Chart.yaml
    ├── README.md
    ├── templates
    │   ├── deployment.yaml
    │   ├── _helpers.tpl
    │   ├── hpa.yaml
    │   ├── ingress.yaml
    │   ├── NOTES.txt
    │   ├── serviceaccount.yaml
    │   ├── service.yaml
    │   └── tests
    │       └── test-connection.yaml
    ├── values.schema.json
    └── values.yaml

29.2. Helm チャートを使用せずにチャート検証レポートを送信する

chart-verifier ツール を使用してレポートを生成し、report.yaml のファイル名でディレクトリー 0.1.0 に保存します。次の 2 種類のレポートを送信できます。

29.2.1. 署名済みレポートを提出する場合

認定用にレポートを送信する前に、チャート検証レポートに PGP public key を追加できます。PGP public key の追加はオプションです。これをレポートに追加すると、組織ディレクトリー内のチャートディレクトリーの下にある OWNERS ファイルで公開鍵を見つけることができます。PGP public key は、publicPgpKey 属性で使用できます。この属性の値は ASCII アーマー形式 に従う必要があります。

チャートなしでチャート検証レポートを送信する場合、レポートに署名し、その署名を ASCII アーマー形式 で保存できます。

以下に例を示します。 

gpg --sign --armor --detach-sign --output report.yaml.asc report.yaml
注記

署名の検証が失敗した場合は、コンソールに警告メッセージが表示されます。

29.2.2. 署名済みチャートのレポートを提出する場合

署名済みチャートのチャート検証レポートを送信する場合、レポートの生成中にチャート検証ツールに PGP public key を指定すると、レポートと共にキーのダイジェストが含まれます。

また、base64 でエンコードされた PGP 公開鍵を OWNERS ファイルに含めると、OWNERS ファイル内のデコードされたキーのダイジェストがレポート内のキーダイジェストと一致するかどうかが確認されます。

一致しない場合、プルリクエストは失敗します。ただし、キーダイジェストがレポートと一致し、プルリクエストの処理時に他のエラーがない場合は、公開鍵とレポートを含むリリースが生成されます。

以下に例を示します。 

awesome-0.1.0.tgz.key
report.yaml
注記

プロバイダー制御の配信を有効にしている場合、リリースは生成されません。

29.3. チャート検証レポートと Helm チャートの送信

レポートと一緒にチャートを提出することもできます。チャート検証レポートを使用しないチャートの送信 手順に従い、ソースまたは tarball をバージョン番号ディレクトリーに配置します。同様に、チャートを使用しないチャート検証レポートの送信 手順に従い、report.yaml ファイルを同じバージョン番号のディレクトリーに配置します。

29.3.1. 署名済みレポートを提出する場合

検証用にレポートに署名し、送信できます。署名の検証が失敗した場合は、コンソールに警告メッセージが表示されます。詳細は、チャートなしのチャート検証レポートを送信する の「署名済みレポートを送信する場合」のセクションを参照してください。

29.3.2. 署名された Helm チャートを提出する場合

署名済みチャートの場合は、レポートファイルに加えて tarball と providence ファイルを含める必要があります。詳細は、チャートなしのチャート検証レポートを送信する の「署名済みチャートのレポートを送信する場合」のセクションを参照してください。

29.4. 認定提出オプションの概要

チャートにアクセスする方法に応じて、認定用に Helm チャートを送信するためのシナリオをまとめた表に従います。また、チャートのテストがローカル環境に依存しているかどうかも確認してください。

目的Helm チャートを含めるチャート検証レポートを含めるRed Hat 認定の結果認定された Helm チャートの公開方法

次のアクションを実行したい場合:

  • 認定されたチャートを charts.openshift.io に保存します。
  • 進行中のチャートテストに Red Hat CI を活用する

Yes

No

chart-verifier ツール は、コンプライアンスを徹底するために Red Hat CI 環境で実行されます。

お客様は、charts.openshift.io から認定された Helm チャートをダウンロードできます。

次のアクションを実行したい場合:

  • 認定されたチャートを charts.openshift.io に保存します。
  • チャートには外部依存関係があるため、独自の環境でチャートをテストするようにしてください。

Yes

Yes

Red Hat 認定チームは、コンプライアンスを徹底するために結果を確認します。

お客様は、charts.openshift.io から認定された Helm チャートをダウンロードできます。

認定されたチャートを charts.openshift.io に保存したくない場合。

No

Yes

Red Hat 認定チームは、コンプライアンスを徹底するために結果を確認します。

お客様は、指定された Helm チャートリポジトリーから認定された Helm チャートをダウンロードできます。対応するエントリーが charts.openshift.io の index.yaml ファイルに追加されます。

29.5. 検証手順

プルリクエストを送信した後、すべてのチェックが実行され、プルリクエストが自動的にマージされるまでに数分かかります。プルリクエストを送信した後、次の手順を実行します。

  1. 新しいプルリクエスト内のメッセージを確認します。
  2. エラーメッセージが表示された場合は、プルリクエストの失敗のトラブルシューティング を参照してください。問題を修正するために必要な変更を加えてプルリクエストを更新します。

  3. 正常に実行されたというメッセージが表示された場合は、チャートリポジトリーインデックスが正常に更新されたことを示します。これは、gh-pages ブランチで最新のコミットをチェックすることで確認できます。コミットメッセージの形式は次のとおりです。 

    <partner-label>-<chart-name>-<version-number> index.yaml (#<PR-number>) (e.g, acme-psql-service-0.1.1 index.yaml (#7)).

    チャートに関連する変更は、index.yaml ファイルで確認できます。

  4. チャートソースを送信した場合は、チャートと対応するレポートを含む GitHub リリースを GitHub リリースページから入手できます。リリースタグの形式は <partner-label>-<chart-name>-<version-number> (e.g., acme-psql-service-0.1.1) です。
  5. 認定された Helm チャートは Red Hat 公式の Helm チャートリポジトリー で確認できます。ここに記載されている手順に従って、認定済みの Helm チャートを OpenShift クラスターにインストールします。

第30章 認定された Helm チャートの公開

プルリクエストを通じて検証のために Helm チャートを送信すると、Red Hat 認定チームが認定用にプロジェクトをレビューおよび検証します。検証が成功すると、Helm チャートプロジェクトが GitHub を通じて認定されます。

認定された Helm チャートを公開するには、次の手順に従います。

  1. Partner connect Web ページにアクセスします。My Work Web ページには、Product Listings および Certification Projects が表示されます。
  2. Product Listings タブに移動し、必要な製品リストを検索します。
  3. 新規に作成された製品リストで公開したいものをクリックします。製品リストの詳細をすべて確認してください。
  4. 左側のペインから、Certification Projects タブに移動します。

  5. Attach Project をクリックして、認定 Helm チャートをこのリストにアタッチします。Helm チャートで使用される認定コンテナープロジェクトも追加します。両方のプロジェクトが Published ステータスである必要があります。

    製品リストとアタッチされたプロジェクトに必要な情報をすべて入力すると、Publish ボタンが有効になります。

  6. Publish をクリックします。

認定された Helm チャートが、Red Hat Ecosystem Catalog で公開され、アクセスできるようになりました。

パート V. CNF 認証とベンダー検証

第31章 クラウドネイティブネットワーク機能の使用

31.1. クラウドネイティブネットワーク機能の概要

クラウドネイティブネットワーク機能 (CNF) は、クラウドネイティブな形式で、弾力性、ライフサイクル管理、セキュリティー、ロギング、その他の機能をサポートするマイクロサービスに分解された、従来の物理ネットワーク機能または仮想ネットワーク機能 (VNF) のコンテナー化されたインスタンスです。

CNF バッジは、Red Hat OpenShift をデプロイメントプラットフォームとして使用し、コンテナー形式で提供されるネットワーク機能を実装する製品を対象とした、Red Hat OpenShift 認定内の専門分野です。要件を満たし、認証ワークフローを完了した製品は、Red Hat OpenShift Container Platform でベンダー検証済み CNF または認定 CNF として参照および宣伝できます。認定が承認されると、CNF は Red Hat Ecosystem Catalog に掲載され、CNF バッジで識別されます。パートナーには、製品の認定を宣伝するためのロゴが与えられます。

関連情報

31.2. CNF の認定ワークフロー

注記

Red Hat では、Red Hat 認定エンジニアまたは同等の経験を有するユーザーが、認定プロセスを開始することを推奨しています。

次の図は、認定プロセスの概要を示しています。

図31.1 CNF プロジェクトの認定ワークフロー

次の手順で説明する CNF プロジェクトの認定ワークフローを視覚的に表したフローチャート。

タスクの概要

認定ワークフローには、次の 3 つの主要な段階が含まれます。

  1. 「認定のオンボーディングと最初のプロジェクトの開始」
  2. 「チェックリストの完了」
  3. 「Red Hat Ecosystem Catalog での CNF 製品リストの公開」

31.2.1. 認定のオンボーディングと最初のプロジェクトの開始

前提条件

認証プロセスに進む前に、製品が次の要件を満たしているかどうかを必ず確認してください。

  • 製品は一般公開されています。
  • 製品は Red Hat OpenShift 上でテストされ、デプロイされます。
  • 製品は Red Hat OpenShift で商用サポートされています。

特定の認定テスト要件に加えて、対象の Red Hat プラットフォームでの製品の機能を検証します。対象の Red Hat OpenShift Container プラットフォームで製品を実行した結果、標準を下回るエクスペリエンスが得られた場合は、認定前に問題を解決する必要があります。

Red Hat Partner Acceleration Desk (PAD) は、製品およびテクノロジーレベルのパートナーヘルプデスクサービスであり、(将来の) テクノロジーパートナーが、Red Hat の提供、パートナープログラム、製品認定、エンゲージメントプロセスなどに関する非技術的な質問を一元的に行える場所です。

PAD - PAD ケースの作成方法と管理方法 を参照して、PAD チケットを作成します。

Partner Subscriptions プログラムを通じて、Red Hat は、対象の Red Hat プラットフォームで製品を検証するために使用できる無料の非再販ソフトウェアサブスクリプションを提供します。プログラムへのアクセスをリクエストするには、Partner Subscriptions サイトの指示に従ってください。

注記

Red Hat では、認定を進める前に、コンテナーイメージと Operator または Helm チャートをチェックして、認定基準とポリシーを満たしているかどうかを確認することを推奨します。詳細は、イメージコンテンツの要件、Operator の要件、および Helm チャートの要件 を参照してください。

手順

認定のオンボーディングに記載されている手順を実行します。

  1. Red Hat Connect for Technology パートナープログラムに参加してください。
  2. プログラムの利用規約に同意します。
  3. 会社プロファイルに記入します。
  4. 目的のプラットフォームを選択して、認定プロジェクトを作成します。たとえば、Red Hat OpenShift を選択してから、CNF Project を選択します。
注記

各パートナー製品バージョンおよびそれに対応する Red Hat 基本バージョンに対して個別の CNF プロジェクトを作成します。CNF プロジェクトを認証したい場合は、コンテナーイメージや Operator バンドル、Helm チャートなど、接続されている CNF コンポーネントごとに個別の CNF プロジェクトを作成します。

関連情報

CNF プロジェクトの作成に関する詳細な手順については、CNF プロジェクトの作成 を参照してください。

31.2.2. チェックリストの完了

記載されている手順を実行し、チェックリストを完了します。

  1. 検証の詳細を入力します。
  2. 会社プロファイルを完成させます。
  3. 記入済み製品リストを添付します。
  4. ベンダー検証のために Red Hat OpenShift で CNF の機能を検証します。
  5. CNF プロジェクトを認定するための認定チェックリストを完了します。

関連情報

チェックリストの詳細は、CNF プロジェクトの設定 を参照してください。

31.2.3. Red Hat Ecosystem Catalog での CNF 製品リストの公開

認定済み または ベンダー検証済み の CNF プロジェクトは、Red Hat Partner Connect ポータルの製品の Product Listing ページにコンポーネントとして追加する必要があります。公開されると、提供した製品情報を使用して、製品リストが Red Hat Ecosystem Catalog に表示されます。ベンダー検証済み CNF 製品と認定 CNF 製品の両方を、それぞれのラベルを付けて Red Hat Ecosystem Catalog に公開できます。

関連情報

第32章 CNF プロジェクトの作成

手順

  1. Red Hat Partner Connect ポータル にログインします。

    パートナーポータルへのアクセス Web ページが表示されます。

  2. 認定テクノロジーポータル タイルに移動し、テクノロジーパートナーのログイン をクリックします。

  3. ログイン資格情報を入力し、ログイン をクリックします。

    Red Hat Partner Connect の Web ページが表示されます。

  4. ページヘッダーで、製品認定 を選択し、認定プロジェクトの管理 をクリックします。

    My Work Web ページには、製品リスト と利用可能な場合 認定プロジェクト が表示されます。

  5. Create Project をクリックします。
  6. 認定するプラットフォーム ダイアログボックスで、Red Hat OpenShift ラジオボタンを選択し、次へ をクリックします。
  7. What do you want to certify? ダイアログボックスで、Cloud-native Network Function (CNF) ラジオボタンを選択し、Next をクリックします。

  8. Create Cloud-native Network Function (CNF) certification project Web ページで、次の詳細を入力してプロジェクトを作成します。

    1. Project Name - プロジェクト名を入力します。この名前は公開されておらず、内部使用のみを目的としています。プロジェクトの作成後にプロジェクト名を変更するには、設定タブに移動します。

      注記

      Red Hat では、新しく作成された CNF プロジェクトを簡単に識別できるように、プロジェクト名に製品バージョンを含めることを推奨します。たとえば、<CompanyName ProductName> 1.2 - OCP 4.12.2 です。

    2. Create project をクリックします。

      注記

      各パートナー製品バージョンおよびそれに対応する Red Hat 基本バージョンに対して個別の CNF プロジェクトを作成します。また、コンテナーイメージ、オペレーターバンドル、Helm チャートなど、接続されている認定コンポーネントごとに個別の CNF プロジェクトを作成します。1 つの製品に対して複数の CNF プロジェクトを作成できます。

第33章 CNF プロジェクトの設定

プロジェクトが作成されると、新しく作成された CNF チャートプロジェクトの Web ページが表示されます。

CNF プロジェクト Web ページは、次のタブで構成されています。

  1. Overview - 公開前チェックリストと認定チェックリストが含まれています。
  2. Settings - プロジェクトの詳細を設定できます。

CNF プロジェクト Web ページの右側で Actions メニューをクリックすると、新しく作成された CNF プロジェクトに対して、現在または将来必要な場合に、次の操作を実行できます。

33.1. チェックリストの完了

CNF プロジェクトの Overview タブには、公開前チェックリストと認定チェックリストが含まれています。これらのチェックリストは、CNF プロジェクトを公開するために完了する必要がある一連のタスクで構成されています。

CNF プロジェクトを公開する前に、次のタスクを実行します。

  1. 「ベンダー検証のための公開前チェックリストを完了する」
  2. 「認定チェックリストを完了して、ベンダー検証済み CNF プロジェクトを認定する」

33.1.1. ベンダー検証のための公開前チェックリストを完了する

33.1.1.1. 会社プロファイルを完了する

会社のプロファイルを最新の状態に保ちます。この情報は、認定製品とともに Red Hat Ecosystem Catalog に公開されます。

会社プロファイルを確認するには、次の手順を実行します。

  1. Complete your company profile タイルに移動し、Edit をクリックします。
  2. すべての情報を入力したら、Submit をクリックします。
  3. 変更を加えるには、タイルを選択し、Review をクリックします。Account Details ページが表示され、入力した Company profile 情報を確認および変更できます。
注記

アスタリスク * の付いたフィールドはすべて必須であり、公開前チェックリストに進む前に入力する必要があります。

33.1.1.2. 検証に関する詳細の入力

Provide details about your validation タイルに移動して、ユーザーが CNF プロジェクトをプルできるように、Red Hat Ecosystem Catalog に表示されるプロジェクトの詳細を入力します。

検証に関する詳細を入力するには、次の手順を実行します。

  1. Start をクリックします。Settings タブに移動します。
  2. 必要なプロジェクトの詳細をすべて入力します。
  3. すべての情報を入力したら、Save をクリックします。
  4. 変更を加えるには、タイルを選択し、Edit をクリックします。
33.1.1.3. 記入済み製品リストの添付

この機能を使用すると、新しい製品リストを作成するか、新しいプロジェクトの既存の OpenShift 製品リストに CNF プロジェクトを添付することができます。

  1. Attach a completed product listing タイルに移動します。
  2. Select method ドロップダウンメニューから、Attach または edit を選択します。Attach product listing ページが表示されます。

  3. プロジェクトを既存の製品リストにアタッチするか、新しい製品リストを作成するかを決定します。

    1. プロジェクトを既存の製品リストに添付するには:

      1. Related product listing セクションから、Select a product listing ドロップダウン矢印をクリックして、必要な製品リストを選択します。
      2. Save をクリックします。

    2. 新しい商品リストを作成するには:

      1. Create new product listing をクリックします。
      2. Product Name テキストボックスに、必要な製品名を入力します。
      3. Save をクリックします。
    3. Select method ドロップダウンメニューから、View product listing をクリックして、新しい製品リストに移動し、必要な製品リストの詳細をすべて入力します。
    4. Save をクリックします。
33.1.1.4. Red Hat OpenShift で CNF の機能を検証する

この機能により、Red Hat CNF 認定チームは、製品がベンダー検証のすべての基準を満たしているかどうかを確認できます。

CNF プロジェクトの機能を検証するには、次の手順を実行します。

  1. このオプションを選択し、Start questionnaire をクリックします。CNF Questionnaire ページが表示されます。
  2. 製品と会社の情報をすべて入力します。
  3. すべての情報を入力したら、Submit をクリックします。
  4. 変更を加えるには、タイルを選択し、Review process をクリックします。CNF Questionnaire ページが表示され、入力した情報を確認および変更できます。

Submit をクリックすると、新しい機能認定リクエストが作成されます。Red Hat CNF 認定チームは、CNF アンケートに入力された詳細を確認して検証します。レビューと検証が成功すると、機能認定リクエストが承認され、製品リストの Certification Level フィールドが Vendor Validated に設定されます。

各ステップを完了すると、各タイルの横に、その設定項目が完了したことを示す緑色のチェックマークが表示されます。チェックリストのすべての項目が完了すると、公開前チェックリスト の左側にある公開キャレットが閉じます。

関連情報

検証プロセスの詳細については、CNF ワークフロー を参照してください。

33.1.2. 認定チェックリストを完了して、ベンダー検証済み CNF プロジェクトを認定する

注記

CNF プロジェクトを認定する場合にのみ、このオプションを選択してください。

これは、Red Hat 認定ツールを使用してベンダー検証済みプロジェクトを認定できるようにするオプションの機能です。Vendor Validated プロジェクトごとに、新しい機能認定リクエストが Red Hat パートナー認定ポータルで作成されます。認証をリクエストすると、機能認証リクエストは CNF チームによって認証のために処理されます。

ベンダー検証済み CNF プロジェクトを認証すると、Red Hat Ecosystem Catalog に Certified ラベルが表示されます。

前提条件

  1. 認定チェックリストに進む前に、公開前チェックリストを完了してください。
  2. CNF プロジェクトを認証のために送信する前に、添付されたコンテナーイメージ、Operator バンドル、または Helm チャートを認証します。

手順

ベンダー検証済み CNF プロジェクトを認定するには、次の手順を実行します。

  1. Certify the functionality tool to certify your CNF に移動し、Start をクリックします。新しい機能認定リクエストが作成され、Red Hat Partner Certification (rhcert) ポータル上のプロジェクトにリダイレクトされます。
  2. CNF 認定テストスイート を実行するか、DCI OpenShit App Agent を使用します。これは、製品がこれらの原則に準拠し、Red Hat 認定基準を満たしているかどうかを評価するためのベストプラクティスから派生した一連のテストケースで設定されています。

  3. CNF プロジェクトを認証するには、Red Hat パートナー認定 (rhcert) ポータルの CNF プロジェクトページで次の手順を実行します。

    1. Summary タブに移動し、

      1. CNF 認定テストの結果を送信するには、Files セクションで Upload をクリックします。claims.json ファイルと tnf_config.yml ファイルを選択します。Next をクリックします。アップロードに成功したというメッセージが表示されます。
      2. 認定に関連する質問がある場合は、Discussions テキストボックスに追加します。
      3. Add Comment をクリックします。このオプションを使用すると、Red Hat CNF 認定チームに質問を伝えることができます。Red Hat CNF 認定チームは、お客様の質問に対して明確な説明を提供します。

    2. Summary タブで、

      1. Partner Product カテゴリーに移動します。
      2. Partner Product Version オプションの下にある編集アイコンをクリックして製品バージョンを入力し、チェックマークボタンをクリックします。製品バージョンが更新されます。

    3. Properties タブに移動し、

      1. Platform リストメニューをクリックして、CNF プロジェクトを認証するプラットフォームを選択します。例 - x86_64
      2. Product Version リストメニューをクリックして、CNF プロジェクトを認証する Red Hat 製品バージョンを選択します。例 - Red Hat OpenShift Platform
      3. Update Values をクリックします。選択した値が更新されます。
注記

パートナー製品のすべてのバージョンが、Red Hat 製品のすべてのバージョンで使用できるように認定されているわけではありません。製品の各バージョンを、選択した Red Hat 基本バージョンで認証する必要があります。たとえば、製品バージョン 5.11 を Red Hat OpenShift Container Platform バージョン 4.13 で認定した場合、5.11 バージョンのみを使用でき、それ以降のバージョンは使用できません。したがって、製品のすべてのバージョンを Red Hat 基本製品の最新バージョンで個別に認定してください。

Red Hat CNF 認定チームは、CNF プロジェクトの詳細を確認して検証します。Red Hat CNF 認定チームが CNF の推奨されるベストプラクティスの問題または違反を特定すると、修復オプションとタイムラインを見出すために共同でディスカッションが行われます。チームは、特定されたリリース目標またはタイムラインで問題を解決するというコミットメントがある場合、一時的な例外も検討します。CNF が Red Hat エコシステムカタログに掲載される前に、すべての例外が文書化され、すべての非準拠項目をリストした KIE ベース記事に公開されますが、技術的な詳細は非公開のままです。

注記

CNF プロジェクトの認証を開始する前に、CNF プロジェクトで参照されているすべてのコンテナー、Operator、または Helm チャートを所定の順序で再認証する必要があります。

Red Hat CNF 認定チームによる検証に成功すると、ベンダー検証済み CNF プロジェクトが認定され、Certified ラベル付きで Red Hat Ecosystem Catalog に自動的に公開されます。

関連情報

  1. CNF 認定テストスイートの詳細については、Overview と test catalog を参照してください。
  2. DCI OpenShit App Agent のインストールと設定の詳細については、 DCI OpenShit App Agent を参照してください。

33.2. プロジェクト設定の管理

Settings タブから CNF プロジェクトの詳細を設定できます。CNF プロジェクトが Red Hat CNF 認定チームによって正常に検証されると、製品リストが以下の詳細とともに Red Hat Ecosystem Catalog に公開されます。

  1. Project Details - これには、プロジェクト名 と 技術担当者のメールアドレス が含まれます。この情報は、認定プロジェクトに固有の問題がある場合に Red Hat が連絡するために使用されます。

    注記

    Red Hat では、新しく作成された CNF プロジェクトを簡単に識別できるように、プロジェクト名に製品バージョンを含めることを推奨します。たとえば、<CompanyName ProductName> 1.2 - OCP 4.12.2 です。

  2. 追加の技術担当者のメールアドレス を追加する場合は、Add new contact をクリックします。
  3. Save をクリックします。
注記

アスタリスク * の付いたフィールドはすべて必須であり、このページの変更を保存する前に入力する必要があります。

第34章 Red Hat Ecosystem Catalog での製品リストの公開

公開前チェックリストを完了した後、検証のために CNF プロジェクトを送信すると、Red Hat CNF 認定チームが CNF アンケートに入力された詳細をレビューして検証します。ベンダー検証済み CNF プロジェクトの認定を希望する場合は、認定チェックリストを完了してください。

Red Hat 認定チームは、提出された CNF テスト結果を確認します。検証が成功したら、製品を Red Hat Ecosystem Catalog に公開するために、Product Listings ページに移動して、ベンダー検証済みまたは認定済みの CNF プロジェクトを添付します。

製品リストを公開するには、次の手順に従います。

  1. Red Hat Partner Connect Web ページにアクセスします。My Work Web ページには、Product Listings および Certification Projects が表示されます。
  2. Product Listings タブに移動し、必要な製品リストを検索します。
  3. 公開する新しく作成した製品リストをクリックします。製品リストの詳細をすべて確認してください。
  4. 左側のペインから、Versions & Certifications タブに移動します。

  5. 新しいプロジェクトのバージョンを製品リストに追加するには、Attach New Version をクリックします。

    注記

    製品バージョンと製品認定を公開する前に、添付されているすべてのプロジェクトバージョンを公開する必要があります。

  6. 左側のペインから、Certification Projects タブに移動します。

  7. Attach Project をクリックして、Vendor Validated または Certified CNF プロジェクトをこのリストに添付します。認定済み CNF プロジェクトを添付する際には、認定済みコンテナーイメージと、CNF プロジェクトで使用する Operator バンドルまたは Helm チャートプロジェクトを追加する必要があります。

    注記

    添付されたすべてのプロジェクトが Published ステータスである必要があります。

    ベンダー検証済みプロジェクトの場合、この手順は必要ありません。添付されたプロジェクトなど、製品リストに必要な情報をすべて入力すると、Publish ボタンが有効になります。

  8. Publish をクリックします。

新しい CNF 製品リストが、Red Hat Ecosystem Catalog で、Vendor Validated または Certified CNF というラベル付きで公開されます。製品リストページの Certifications 表には、次の詳細が表示されます。

  • 製品 - Red Hat OpenShift Container Platform など
  • バージョン - 選択した Red Hat 基本製品のバージョン。例: 4.12 - 4.x
  • アーキテクチャー - 例: x86_64
  • パートナー製品のバージョン - 例: 5.11
  • 認証タイプ - 例: RHOCP 4 CNF
  • レベル - Vendor Validated または Certified など

製品の各バージョンを、選択した Red Hat 基本バージョンで認証する必要があります。したがって、Certifications テーブルには、同じ Red Hat 基本バージョンに対して製品の複数のバージョンを含めることができます。以下に例を示します。

Productバージョンアーキテクチャーパートナー製品のバージョン認証の種類認定レベル

Red Hat OpenShift Container Platform

4.12

x86_64

5.11

RHOCP 4 CNF

ベンダー検証済み

Red Hat OpenShift Container Platform

4.12

x86_64

5.12

RHOCP 4 CNF

認定済み

Red Hat OpenShift Container Platform

4.12

x86_64

5.13

RHOCP 4 CNF

認定済み

Red Hat OpenShift Container Platform

4.12

x86_64

5.14

RHOCP 4 CNF

ベンダー検証済み

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.