動的プラグインの設定

手順

1. Backstage インスタンスの app-config.yaml ファイルで、kubernetes 設定に次の customResources コンポーネントを追加して、Argo Rollouts と AnalysisRuns を有効にします。

   kubernetes:
     ...
     customResources:
       - group: 'argoproj.io'
         apiVersion: 'v1alpha1'
         plural: 'Rollouts'
       - group: 'argoproj.io'
         apiVersion: 'v1alpha1'
         plural: 'analysisruns'

   Copy to Clipboard

2. カスタムリソースに対する ClusterRole 権限を付与します。

   注記
   • Backstage Kubernetes プラグインがすでに設定されている場合は、Rollouts および AnalysisRuns の ClusterRole 権限がすでに付与されている可能性があります。
   • 準備したマニフェスト を使用して、Kubernetes プラグインと ArgoCD プラグインの両方に読み取り専用の ClusterRole アクセスを割り当てます。
   1. ClusterRole 権限が付与されていない場合は、次の YAML マニフェストを使用して ClusterRole を作成します。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: backstage-read-only
   rules:
     - apiGroups:
         - argoproj.io
       resources:
         - rollouts
         - analysisruns
       verbs:
         - get
         - list

   Copy to Clipboard

   1. kubectl を使用してマニフェストをクラスターに適用します。

      kubectl apply -f <your-clusterrole-file>.yaml

      Copy to Clipboard
   2. クラスターにアクセスする ServiceAccount にこの ClusterRole が割り当てられていることを確認します。

3. Backstage の Kubernetes リソースを識別するために、catalog-info.yaml にアノテーションを追加します。

   1. エンティティー ID でリソースを識別する場合:

      annotations:
        ...
        backstage.io/kubernetes-id: <BACKSTAGE_ENTITY_NAME>

      Copy to Clipboard

   2. (オプション) 名前空間でリソースを識別する場合:

      annotations:
        ...
        backstage.io/kubernetes-namespace: <RESOURCE_NAMESPACE>

      Copy to Clipboard

   3. エンティティー ID または名前空間によるリソース識別をオーバーライドするカスタムラベルセレクターを使用する場合:

      annotations:
        ...
        backstage.io/kubernetes-label-selector: 'app=my-app,component=front-end'

      Copy to Clipboard
      注記

      Kubernetes リソースの backstage.io/kubernetes-label-selector で宣言されたラベルを必ず指定してください。このアノテーションは、backstage.io/kubernetes-id や backstage.io/kubernetes-namespace などのエンティティーベースまたは名前空間ベースの識別アノテーションをオーバーライドします。

4. Backstage が適切な Kubernetes リソースを見つけられるように、Kubernetes リソースにラベルを追加します。

   1. Backstage Kubernetes プラグインラベル: このラベルを追加して、リソースを特定の Backstage エンティティーにマップします。

      labels:
        ...
        backstage.io/kubernetes-id: <BACKSTAGE_ENTITY_NAME>

      Copy to Clipboard

   2. GitOps アプリケーションマッピング: このラベルを追加して、Argo CD ロールアウトを特定の GitOps アプリケーションにマッピングします。

      labels:
        ...
        app.kubernetes.io/instance: <GITOPS_APPLICATION_NAME>

      Copy to Clipboard
   注記

   ラベルセレクターアノテーション (backstage.io/kubernetes-label-selector) を使用する場合は、指定されたラベルがリソースに存在することを確認します。ラベルセレクターは、kubernetes-id や kubernetes-namespace などの他のアノテーションをオーバーライドします。

検証

1. 更新された設定を GitOps リポジトリーにプッシュして、ロールアウトをトリガーします。
2. Red Hat Developer Hub インターフェイスを開き、設定したエンティティーに移動します。
3. CD タブを選択し、対象の GitOps アプリケーション を選択します。サイドパネルが開きます。

4. サイドパネルの Resources テーブルで、次のリソースが表示されていることを確認します。

   • Rollouts
   • AnalysisRuns (オプション)

5. ロールアウトリソースを展開し、次の詳細を確認します。

   • Revisions の行には、さまざまなロールアウトバージョンのトラフィックの分布が詳細に表示されます。
   • Analysis Runs の行には、ロールアウトの成功を評価する分析タスクのステータスが表示されます。

1. 以下のように、app-config.yaml ファイルで目的の JFrog Artifactory サーバーにプロキシーを設定します。

   proxy:
     endpoints:
       ‘/jfrog-artifactory/api’:
         target: http://<hostname>:8082 # or https://<customer>.jfrog.io
         headers:
         # Authorization: 'Bearer <YOUR TOKEN>'
         # Change to "false" in case of using a self-hosted Artifactory instance with a self-signed certificate
         secure: true

   Copy to Clipboard

2. 以下のアノテーションをエンティティーの catalog-info.yaml ファイルに追加して、RHDH コンポーネントで JFrog Artifactory プラグイン機能を有効にします。

   metadata:
       annotations:
         'jfrog-artifactory/image-name': '<IMAGE-NAME>'

   Copy to Clipboard

1. 次のように、app-config.yaml ファイルでプロキシーを目的の Nexus Repository Manager サーバーに設定します。

   proxy:
       '/nexus-repository-manager':
       target: 'https://<NEXUS_REPOSITORY_MANAGER_URL>'
       headers:
           X-Requested-With: 'XMLHttpRequest'
           # Uncomment the following line to access a private Nexus Repository Manager using a token
           # Authorization: 'Bearer <YOUR TOKEN>'
       changeOrigin: true
       # Change to "false" in case of using self hosted Nexus Repository Manager instance with a self-signed certificate
       secure: true

   Copy to Clipboard

2. オプション: Nexus Repository Manager プロキシーのベース URL を次のように変更します。

   nexusRepositoryManager:
       # default path is `/nexus-repository-manager`
       proxyPath: /custom-path

   Copy to Clipboard

3. オプション: 次の実験的アノテーションを有効にします。

   nexusRepositoryManager:
       experimentalAnnotations: true

   Copy to Clipboard

4. 以下のアノテーションを使用してエンティティーにアノテーションを付けます。

   metadata:
       annotations:
       # insert the chosen annotations here
       # example
       nexus-repository-manager/docker.image-name: `<ORGANIZATION>/<REPOSITORY>`,

   Copy to Clipboard

手順

1. Bulk Import プラグインはインストールされていますが、デフォルトでは無効になっています。./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import-backend-dynamic および ./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import プラグインを有効にするには、dynamic-plugins.yaml を次の内容で編集します。

   dynamic-plugins.yaml フラグメント

   plugins:
     - package: ./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import-backend-dynamic
       disabled: false
     - package: ./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import
       disabled: false

   Copy to Clipboard

   Red Hat Developer Hub でのプラグインのインストールと表示 を参照してください。

2. 管理者ではないユーザーに対して必要な bulk.import RBAC 権限を次のように設定します。

   rbac-policy.csv フラグメント

   p, role:default/bulk-import, bulk.import, use, allow
   g, user:default/<your_user>, role:default/bulk-import

   Copy to Clipboard

   一括インポート機能を使用できるのは、Developer Hub 管理者または bulk.import 権限を持つユーザーのみであることに注意してください。Red Hat Developer Hub のパーミッションポリシー を参照してください。

手順

1. 左側のサイドバーで Bulk Import をクリックします。

2. 右上隅の Add ボタンをクリックすると、設定された GitHub インテグレーションからアクセスできるすべてのリポジトリーのリストが表示されます。

   1. Repositories ビューから、任意のリポジトリーを選択したり、アクセス可能なリポジトリーを検索したりできます。選択されたリポジトリーごとに、catalog-info.yaml が生成されます。
   2. Organizations ビューでは、3 番目の列の Select をクリックして任意の組織を選択できます。このオプションを使用すると、選択した組織から 1 つ以上のリポジトリーを選択できます。

3. 各リポジトリーのプルリクエストの詳細を表示または編集するには、Preview file をクリックします。

   1. プルリクエストの説明と catalog-info.yaml ファイルの内容を確認します。
   2. オプション: リポジトリーに .github/CODEOWNERS ファイルがある場合は、content-info.yaml に特定のエンティティー所有者を含めるのではなく、Use CODEOWNERS file as Entity Owner チェックボックスを選択してそのファイルを使用できます。
   3. Save をクリックします。

4. Create pull requests をクリックします。この時点で、選択したリポジトリーに対して一連のドライランチェックが実行され、次のようなインポートの要件を満たしているかどうかが確認されます。

   1. リポジトリー catalog-info.yaml で指定された名前のエンティティーが Developer Hub カタログに存在しないことを確認します。
   2. リポジトリーが空でないことを確認します。

   3. リポジトリーの Use CODEOWNERS file as Entity Owner チェックボックスが選択されている場合、リポジトリーに .github/CODEOWNERS ファイルが含まれていることを確認します。

      • エラーが発生した場合、プルリクエストは作成されず、問題の詳細を示す Failed to create PR のエラーメッセージが表示されます。理由の詳細を表示するには、Edit をクリックします。
      • エラーがなければ、プルリクエストが作成され、追加されたリポジトリーのリストにリダイレクトされます。
5. catalog-info.yml ファイルを作成する各プルリクエストを確認し、マージします。

手順

1. 左側のサイドバーで Bulk Import をクリックして、Import ジョブとして追跡されている現在のすべてのリポジトリーとそのステータスを表示します。

   Added

   インポートプルリクエストがマージされた後、または一括インポート中にリポジトリーに catalog-info.yaml ファイルがすでに含まれていた場合、リポジトリーは Developer Hub カタログに追加されます。カタログでエンティティーが利用可能になるまで数分かかる場合があります。

   Waiting for approval

   catalog-info.yaml ファイルをリポジトリーに追加するオープンプルリクエストがあります。これにより、以下が可能になります。

   • 右側の 鉛筆アイコン をクリックして、プルリクエストの詳細を表示するか、Developer Hub からプルリクエストのコンテンツを編集します。
   • インポートジョブを削除します。この操作により、インポート PR も閉じられます。
   • インポートジョブを Added 状態に移行するには、Git リポジトリーからのインポートプルリクエストをマージします。

   Empty

   リポジトリーは他のソースからインポートされていますが、catalog-info.yaml ファイルがなく、それを追加するインポートプルリクエストもないため、Developer Hub はインポートジョブのステータスを判別できません。

手順

1. カスタムアクションプラグインを有効にするには、プラグイン名を持つ package を追加し、Helm チャートの disabled フィールドを次のように更新します。

   global:
     dynamic:
       includes:
         - dynamic-plugins.default.yaml
       plugins:
         - package: ./dynamic-plugins/dist/backstage-community-plugin-scaffolder-backend-module-servicenow-dynamic
           disabled: false

   Copy to Clipboard
   注記

   プラグインのデフォルト設定は、dynamic-plugins.default.yaml ファイルから抽出されます。ただし、pluginConfig エントリーを使用すると、デフォルト設定をオーバーライドできます。

2. カスタムアクションにアクセスするには、Helm チャートで次の変数を設定します。

   servicenow:
     # The base url of the ServiceNow instance.
     baseUrl: ${SERVICENOW_BASE_URL}
     # The username to use for authentication.
     username: ${SERVICENOW_USERNAME}
     # The password to use for authentication.
     password: ${SERVICENOW_PASSWORD}

   Copy to Clipboard