Red Hat Developer Hub 管理ガイド


Red Hat Developer Hub 1.2

Red Hat Customer Content Services

概要

Red Hat Developer Hub は、開発者ポータルを構築するためのエンタープライズグレードのプラットフォームです。管理ユーザーは、他のユーザーのロールと権限を管理し、組織の特定のニーズを満たすように Developer Hub を設定できます。

はじめに

Red Hat Developer Hub は、開発者ポータルの構築に使用できるエンタープライズグレードのオープンな開発者プラットフォームです。このプラットフォームには、開発者の生産性を高めつつ、衝突やフラストレーションの軽減に役立つ、サポート対象の独自フレームワークが含まれています。

Red Hat Developer Hub のサポート

このマニュアルに記載されている手順で問題が発生した場合は、Red Hat カスタマーポータル を参照してください。Red Hat カスタマーポータルは次の目的に使用できます。

  • Red Hat 製品に関する技術サポート記事の Red Hat ナレッジベースの検索または閲覧。
  • Red Hat Global Support Services (GSS) の サポートケース の作成。サポートケースを作成するには、製品として Red Hat Developer Hub を選択し、適切な製品バージョンを選択してください。

第1章 Red Hat OpenShift Container Platform へのカスタムアプリケーション設定ファイルの追加

Red Hat Developer Hub にアクセスするには、Red Hat OpenShift Container Platform にカスタムアプリケーション設定ファイルを追加する必要があります。OpenShift Container Platform では、次のコンテンツをベーステンプレートとして使用して、app-config-rhdh という名前の ConfigMap を作成できます。

kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
data:
  app-config-rhdh.yaml: |
    app:
      title: {product}

次のいずれかの方法で、カスタムアプリケーション設定ファイルを OpenShift Container Platform に追加できます。

  • Red Hat Developer Hub Operator
  • Red Hat Developer Hub Helm チャート。

Red Hat Developer Hub Helm チャートを使用して、カスタムアプリケーション設定ファイルを OpenShift Container Platform インスタンスに追加できます。

前提条件

  • Red Hat OpenShift Container Platform アカウントを作成している。

手順

  1. OpenShift Container Platform Web コンソールから、ConfigMaps タブを選択します。
  2. Create ConfigMap をクリックします。
  3. Create ConfigMap ページで、Configure viaYAML view オプションを選択し、必要に応じてファイルに変更を加えます。
  4. Create をクリックします。
  5. Helm リリースのリストを表示するには、Helm タブに移動します。
  6. 使用する Helm リリースのオーバーフローメニューをクリックし、Upgrade を選択します。
  7. Helm 設定を編集するには、Form view または YAML view のいずれかを使用します。

    • Form view を使用する場合

      1. Root Schema → Backstage chart schema → Backstage parameters → Extra app configuration files to inline into command arguments を展開します。
      2. Add Extra app configuration files to inline into command arguments リンクをクリックします。
      3. 以下のフィールドに値を入力します。

        • configMapRef: app-config-rhdh
        • filename: app-config-rhdh.yaml
      4. Upgrade をクリックします。
    • YAML view を使用する場合

      1. 以下のように upstream.backstage.extraAppConfig.configMapRef パラメーターおよび upstream.backstage.extraAppConfig.filename パラメーターの値を設定します。

        # ... other Red Hat Developer Hub Helm Chart configurations
        upstream:
          backstage:
            extraAppConfig:
              - configMapRef: app-config-rhdh
                filename: app-config-rhdh.yaml
        # ... other Red Hat Developer Hub Helm Chart configurations
      2. Upgrade をクリックします。

カスタムアプリケーション設定ファイルは、Red Hat Developer Hub インスタンスの設定を変更するために使用できる ConfigMap オブジェクトです。Developer Hub インスタンスを Red Hat OpenShift Container Platform にデプロイする場合は、ConfigMap オブジェクトを作成して Developer Hub カスタムリソース (CR) で参照することで、Red Hat Developer Hub Operator を使用して OpenShift Container Platform インスタンスにカスタムアプリケーション設定ファイルを追加できます。

カスタムアプリケーション設定ファイルには、BACKEND_SECRET という名前の機密性の高い環境変数が含まれています。この変数には、OpenShift Container Platform シークレットで定義された環境変数を参照するために Developer Hub が使用する必須のバックエンド認証キーが含まれます。'secrets-rhdh' という名前のシークレットを作成し、それを Developer Hub CR で参照する必要があります。

注記

Red Hat Developer Hub インストールは、ユーザー自身で外部および不正アクセスから保護する必要があります。バックエンド認証キーを他のシークレットと同様に管理します。強力なパスワード要件を満たし、パスワードを設定ファイルで公開せず、環境変数としてのみ設定ファイルに挿入します。

前提条件

  • アクティブな Red Hat OpenShift Container Platform アカウントがある。
  • 管理者により OpenShift Container Platform に Red Hat Developer Hub Operator がインストールされている。詳細は、Red Hat Developer Hub Operator のインストール を参照してください。
  • OpenShift Container Platform で Red Hat Developer Hub CR を作成している。

手順

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブから Topology ビューを選択し、Developer Hub Pod の Open URL アイコンをクリックして、Developer Hub の外部 URL <RHDH_URL> を特定します。
  2. OpenShift Container Platform Web コンソールの Developer パースペクティブから、ConfigMaps ビューを選択します。
  3. Create ConfigMap をクリックします。
  4. Configure viaYAML view オプションを選択し、次の例をベーステンプレートとして使用して、app-config-rhdh.yaml などの ConfigMap オブジェクトを作成します。

    kind: Backstage
    apiVersion: rhdh.redhat.com/v1alpha1
    metadata:
      name: app-config-rhdh
    data:
      "app-config-rhdh.yaml": |
        app:
          title: Red Hat Developer Hub
          baseUrl: <RHDH_URL> 
    1
    
        backend:
          auth:
            keys:
              - secret: "${BACKEND_SECRET}" 
    2
    
          baseUrl: <RHDH_URL> 
    3
    
          cors:
            origin: <RHDH_URL> 
    4
    1
    Red Hat Developer Hub インスタンスの外部 URL を設定します。
    2
    OpenShift Container Platform シークレットを公開する環境変数を使用して、必須の Developer Hub バックエンド認証キーを定義します。
    3
    Red Hat Developer Hub インスタンスの外部 URL を設定します。
    4
    Red Hat Developer Hub インスタンスの外部 URL を設定します。
  5. Create をクリックします。
  6. Secrets ビューを選択します。
  7. Create Key/value Secret をクリックします。
  8. secrets-rhdh という名前のシークレットを作成します。
  9. BACKEND_SECRET という名前のキーと、base64 でエンコードされた文字列を値として追加します。Red Hat Developer Hub インスタンスごとに一意の値を使用します。たとえば、次のコマンドを使用してターミナルからキーを生成できます。

    node -p 'require("crypto").randomBytes(24).toString("base64")'
  10. Create をクリックします。
  11. Topology ビューを選択します。
  12. 使用する Red Hat Developer Hub インスタンスのオーバーフローメニューをクリックし、Edit Backstage を選択して、Red Hat Developer Hub インスタンスの YAML ビューを読み込みます。

    Operator インストール 2
  13. CR で、spec.application.appConfig.configMaps フィールドの値としてカスタムアプリケーション設定の config map の名前を入力し、spec.application.extraEnvs.secrets フィールドの値としてシークレットの名前を入力します。以下に例を示します。

    apiVersion: rhdh.redhat.com/v1alpha1
    kind: Backstage
    metadata:
      name: developer-hub
    spec:
      application:
        appConfig:
          mountPath: /opt/app-root/src
          configMaps:
             - name: app-config-rhdh
        extraEnvs:
          secrets:
             - name: secrets-rhdh
        extraFiles:
          mountPath: /opt/app-root/src
        replicas: 1
        route:
          enabled: true
      database:
        enableLocalDb: true
  14. Save をクリックします。
  15. Topology ビューに戻り、Red Hat Developer Hub Pod が起動するまで待ちます。
  16. Open URL アイコンをクリックして、Red Hat Developer Hub プラットフォームを使用し、設定変更を行います。

関連情報

第2章 外部 PostgreSQL データベースの設定

管理者は、Red Hat Developer Hub で外部 PostgreSQL データベースを設定および使用できます。PostgreSQL 証明書ファイルを使用すると、Operator または Helm チャートを使用して外部 PostgreSQL インスタンスを設定できます。

注記

Developer Hub は、外部 PostgreSQL データベースの設定をサポートします。データのバックアップや外部 PostgreSQL データベースの高可用性 (HA) の設定など、メンテナンスアクティビティーを実行できます。

デフォルトでは、Red Hat Developer Hub Operator または Helm チャートによってローカル PostgreSQL データベースが作成されます。ただし、この設定は実稼働環境には適していません。実稼働環境のデプロイメントでは、ローカルデータベースの作成を無効にし、代わりに外部の PostgreSQL インスタンスに接続するように Developer Hub を設定します。

2.1. Operator を使用した外部 PostgreSQL インスタンスの設定

Red Hat Developer Hub Operator を使用して外部 PostgreSQL インスタンスを設定できます。デフォルトでは、Operator は RHDH インスタンスのデプロイ先と同じ namespace に PostgreSQL のローカルインスタンスを作成して管理します。ただし、このデフォルト設定を変更して、Amazon Web Services (AWS) Relational Database Service (RDS) や Azure データベースなどの外部 PostgreSQL データベースサーバーを設定することもできます。

前提条件

  • サポートされているバージョンの PostgreSQL を使用している。詳細は、製品ライフサイクルのページ を参照してください。
  • 次の情報がある。

    • db-host: PostgreSQL インスタンスの Domain Name System (DNS) または IP アドレスを示します。
    • db-port: PostgreSQL インスタンスのポート番号 (5432 など) を示します。
    • username: PostgreSQL インスタンスに接続するためのユーザー名を示します。
    • password: PostgreSQL インスタンスに接続するためのパスワードを示します。
  • Red Hat Developer Hub Operator がインストールされている。
  • オプション: TLS プロトコルを使用してデータベース接続を保護できるように、CA 証明書、Transport Layer Security (TLS) 秘密鍵、および TLS 証明書がある。詳細は、PostgreSQL ベンダーのドキュメントを参照してください。
注記

デフォルトでは、Developer Hub は各プラグインのデータベースを使用します。見つからない場合は、自動的にデータベースを作成します。外部 PostgreSQL インスタンスを設定するには、PSQL Database 権限に加えて、Create Database 権限が必要になる場合があります。

手順

  1. オプション: TLS 接続を使用して PostgreSQL インスタンスを設定するための証明書シークレットを作成します。

    cat <<EOF | oc -n <your-namespace> create -f -
    apiVersion: v1
    kind: Secret
    metadata:
     name: <crt-secret> 
    1
    
    type: Opaque
    stringData:
     postgres-ca.pem: |-
      -----BEGIN CERTIFICATE-----
      <ca-certificate-key> 
    2
    
     postgres-key.key: |-
      -----BEGIN CERTIFICATE-----
      <tls-private-key> 
    3
    
     postgres-crt.pem: |-
      -----BEGIN CERTIFICATE-----
      <tls-certificate-key> 
    4
    
      # ...
    EOF
    1
    証明書シークレットの名前を指定します。
    2
    CA 証明書の鍵を指定します。
    3
    オプション: TLS 秘密鍵を指定します。
    4
    オプション: TLS 証明書の鍵を指定します。
  2. PostgreSQL インスタンスに接続するための認証情報シークレットを作成します。

    cat <<EOF | oc -n <your-namespace> create -f -
    apiVersion: v1
    kind: Secret
    metadata:
     name: <cred-secret> 
    1
    
    type: Opaque
    stringData: 
    2
    
     POSTGRES_PASSWORD: <password>
     POSTGRES_PORT: "<db-port>"
     POSTGRES_USER: <username>
     POSTGRES_HOST: <db-host>
     PGSSLMODE: <ssl-mode> # for TLS connection 
    3
    
     NODE_EXTRA_CA_CERTS: <abs-path-to-pem-file> # for TLS connection, e.g. /opt/app-root/src/postgres-crt.pem 
    4
    
    EOF
    1
    認証情報シークレットの名前を指定します。
    2
    PostgreSQL インスタンスに接続するための認証情報データを指定します。
    3
    オプション: 必要な Secure Sockets Layer (SSL) モード に応じて値を指定します。
    4
    オプション: PostgreSQL インスタンスに TLS 接続が必要な場合にのみ値を指定します。
  3. Backstage カスタムリソース (CR) を作成します。

    cat <<EOF | oc -n <your-namespace> create -f -
    apiVersion: rhdh.redhat.com/v1alpha1
    kind: Backstage
    metadata:
      name: <backstage-instance-name>
    spec:
      database:
        enableLocalDb: false 
    1
    
      application:
        extraFiles:
          mountPath: <path> # e g /opt/app-root/src
          secrets:
            - name: <crt-secret> 
    2
    
              key: postgres-crt.pem, postgres-ca.pem, postgres-key.key # key name as in <crt-secret> Secret
        extraEnvs:
          secrets:
            - name: <cred-secret> 
    3
    
            # ...
    1
    enableLocalDb パラメーターの値を false に設定して、PostgreSQL のローカルインスタンスの作成を無効にします。
    2
    TLS 接続を設定した場合は、証明書シークレットの名前を指定します。
    3
    作成した認証情報シークレットの名前を指定します。
    注記

    Backstage CR にリストされている環境変数は、Operator のデフォルト設定を使用します。Operator のデフォルト設定を変更した場合は、それに応じて Backstage CR を再設定する必要があります。

  4. RHDH インスタンスをデプロイした namespace に Backstage CR を適用します。

2.2. Helm チャートを使用した外部 PostgreSQL インスタンスの設定

Helm チャートを使用して外部 PostgreSQL インスタンスを設定できます。デフォルトでは、Helm チャートは RHDH インスタンスのデプロイ先と同じ namespace に PostgreSQL のローカルインスタンスを作成して管理します。ただし、このデフォルト設定を変更して、Amazon Web Services (AWS) Relational Database Service (RDS) や Azure データベースなどの外部 PostgreSQL データベースサーバーを設定することもできます。

前提条件

  • サポートされているバージョンの PostgreSQL を使用している。詳細は、製品ライフサイクルのページ を参照してください。
  • 次の情報がある。

    • db-host: PostgreSQL インスタンスの Domain Name System (DNS) または IP アドレスを示します。
    • db-port: PostgreSQL インスタンスのポート番号 (5432 など) を示します。
    • username: PostgreSQL インスタンスに接続するためのユーザー名を示します。
    • password: PostgreSQL インスタンスに接続するためのパスワードを示します。
  • Helm チャートを使用して RHDH アプリケーションをインストールした。
  • オプション: TLS プロトコルを使用してデータベース接続を保護できるように、CA 証明書、Transport Layer Security (TLS) 秘密鍵、および TLS 証明書がある。詳細は、PostgreSQL ベンダーのドキュメントを参照してください。
注記

デフォルトでは、Developer Hub は各プラグインのデータベースを使用します。見つからない場合は、自動的にデータベースを作成します。外部 PostgreSQL インスタンスを設定するには、PSQL Database 権限に加えて、Create Database 権限が必要になる場合があります。

手順

  1. オプション: TLS 接続を使用して PostgreSQL インスタンスを設定するための証明書シークレットを作成します。

    cat <<EOF | oc -n <your-namespace> create -f -
    apiVersion: v1
    kind: Secret
    metadata:
     name: <crt-secret> 
    1
    
    type: Opaque
    stringData:
     postgres-ca.pem: |-
      -----BEGIN CERTIFICATE-----
      <ca-certificate-key> 
    2
    
     postgres-key.key: |-
      -----BEGIN CERTIFICATE-----
      <tls-private-key> 
    3
    
     postgres-crt.pem: |-
      -----BEGIN CERTIFICATE-----
      <tls-certificate-key> 
    4
    
      # ...
    EOF
    1
    証明書シークレットの名前を指定します。
    2
    CA 証明書の鍵を指定します。
    3
    オプション: TLS 秘密鍵を指定します。
    4
    オプション: TLS 証明書の鍵を指定します。
  2. PostgreSQL インスタンスに接続するための認証情報シークレットを作成します。

    cat <<EOF | oc -n <your-namespace> create -f -
    apiVersion: v1
    kind: Secret
    metadata:
     name: <cred-secret> 
    1
    
    type: Opaque
    stringData: 
    2
    
     POSTGRES_PASSWORD: <password>
     POSTGRES_PORT: "<db-port>"
     POSTGRES_USER: <username>
     POSTGRES_HOST: <db-host>
     PGSSLMODE: <ssl-mode> # for TLS connection 
    3
    
     NODE_EXTRA_CA_CERTS: <abs-path-to-pem-file> # for TLS connection, e.g. /opt/app-root/src/postgres-crt.pem 
    4
    
    EOF
    1
    認証情報シークレットの名前を指定します。
    2
    PostgreSQL インスタンスに接続するための認証情報データを指定します。
    3
    オプション: 必要な Secure Sockets Layer (SSL) モード に応じて値を指定します。
    4
    オプション: PostgreSQL インスタンスに TLS 接続が必要な場合にのみ値を指定します。
  3. values.yaml という名前の Helm 設定ファイルで PostgreSQL インスタンスを設定します。

    # ...
    upstream:
      postgresql:
        enabled: false  # disable PostgreSQL instance creation 
    1
    
        auth:
          existingSecret: <cred-secret> # inject credentials secret to Backstage 
    2
    
      backstage:
        appConfig:
          backend:
            database:
              connection:  # configure Backstage DB connection parameters
                host: ${POSTGRES_HOST}
                port: ${POSTGRES_PORT}
                user: ${POSTGRES_USER}
                password: ${POSTGRES_PASSWORD}
                ssl:
                  rejectUnauthorized: true,
                  ca:
                    $file: /opt/app-root/src/postgres-ca.pem
                  key:
                    $file: /opt/app-root/src/postgres-key.key
                  cert:
                    $file: /opt/app-root/src/postgres-crt.pem
      extraEnvVarsSecrets:
        - <cred-secret> # inject credentials secret to Backstage 
    3
    
      extraEnvVars:
        - name: BACKEND_SECRET
          valueFrom:
            secretKeyRef:
              key: backend-secret
              name: '{{ include "janus-idp.backend-secret-name" $ }}'
      extraVolumeMounts:
        - mountPath: /opt/app-root/src/dynamic-plugins-root
          name: dynamic-plugins-root
        - mountPath: /opt/app-root/src/postgres-crt.pem
          name: postgres-crt # inject TLS certificate to Backstage cont. 
    4
    
          subPath: postgres-crt.pem
        - mountPath: /opt/app-root/src/postgres-ca.pem
          name: postgres-ca # inject CA certificate to Backstage cont. 
    5
    
          subPath: postgres-ca.pem
        - mountPath: /opt/app-root/src/postgres-key.key
          name: postgres-key # inject TLS private key to Backstage cont. 
    6
    
          subPath: postgres-key.key
      extraVolumes:
        - ephemeral:
            volumeClaimTemplate:
              spec:
                accessModes:
                  - ReadWriteOnce
                resources:
                  requests:
                    storage: 1Gi
          name: dynamic-plugins-root
        - configMap:
            defaultMode: 420
            name: dynamic-plugins
            optional: true
          name: dynamic-plugins
        - name: dynamic-plugins-npmrc
          secret:
            defaultMode: 420
            optional: true
            secretName: dynamic-plugins-npmrc
        - name: postgres-crt
          secret:
            secretName: <crt-secret> 
    7
    
            # ...
    1
    upstream.postgresql.enabled パラメーターの値を false に設定して、PostgreSQL のローカルインスタンスの作成を無効にします。
    2
    認証情報シークレットの名前を指定します。
    3
    認証情報シークレットの名前を指定します。
    4
    オプション: TLS 接続の場合のみ、TLS 証明書の名前を指定します。
    5
    オプション: TLS 接続の場合のみ、CA 証明書の名前を指定します。
    6
    オプション: TLS 接続に秘密鍵が必要な場合にのみ、TLS 秘密鍵の名前を指定します。
    7
    TLS 接続を設定した場合は、証明書シークレットの名前を指定します。
  4. values.yaml という名前の Helm 設定ファイルに設定の変更を適用します。

    helm upgrade -n <your-namespace> <your-deploy-name> openshift-helm-charts/redhat-developer-hub -f values.yaml --version 1.2.6

2.3. Operator を使用したローカルデータベースの外部データベースサーバーへの移行

デフォルトでは、Red Hat Developer Hub は各プラグインのデータを PostgreSQL データベースでホストします。データベースのリストを取得すると、Developer Hub で設定されているプラグインの数によっては、複数のデータベースが表示される場合があります。ローカルの PostgreSQL サーバーでホストされている RHDH インスタンスから、AWS RDS、Azure データベース、Crunchy データベースなどの外部 PostgreSQL サービスにデータを移行できます。各 RHDH インスタンスからデータを移行するには、pg_dumppsql、または pgAdmin などの PostgreSQL ユーティリティーを使用できます。

注記

次の手順では、データベースコピースクリプトを使用して迅速な移行を実行します。

前提条件

  • ローカルマシンに pg_dump および psql ユーティリティーがインストールした。
  • データをエクスポートする場合は、ローカルデータベースの完全なダンプを作成するための PGSQL ユーザー権限がある。
  • データをインポートする場合は、外部データベースを作成し、データベースダンプを取り込むための PGSQL 管理者権限がある。

手順

  1. ターミナルで次のコマンドを実行して、ローカル PostgreSQL データベース Pod のポート転送を設定します。

    oc port-forward -n <your-namespace> <pgsql-pod-name> <forward-to-port>:<forward-from-port>

    ここでは、以下のようになります。

    • <pgsql-pod-name> 変数は、backstage-psql-<deployment-name>-<_index> という形式の PostgreSQL Pod の名前を示します。
    • <forward-to-port> 変数は、PostgreSQL データの転送先のポートを示します。
    • <forward-from-port> 変数は、5432 などの PostgreSQL ローカルインスタンスのポートを示します。

      例: ポート転送の設定

      oc port-forward -n developer-hub backstage-psql-developer-hub-0 15432:5432

  2. 次の db_copy.sh スクリプトのコピーを作成し、設定に応じて詳細を編集します。

    #!/bin/bash
    
    to_host=<db-service-host> 
    1
    
    to_port=5432 
    2
    
    to_user=postgres 
    3
    
    
    from_host=127.0.0.1 
    4
    
    from_port=15432 
    5
    
    from_user=postgres 
    6
    
    
    allDB=("backstage_plugin_app" "backstage_plugin_auth" "backstage_plugin_catalog" "backstage_plugin_permission" "backstage_plugin_scaffolder" "backstage_plugin_search") 
    7
    
    
    for db in ${!allDB[@]};
    do
      db=${allDB[$db]}
      echo Copying database: $db
      PGPASSWORD=$TO_PSW psql -h $to_host -p $to_port -U $to_user -c "create database $db;"
      pg_dump -h $from_host -p $from_port -U $from_user -d $db | PGPASSWORD=$TO_PSW psql -h $to_host -p $to_port -U $to_user -d $db
    done
    1
    宛先ホスト名 (例: <db-instance-name>.rds.amazonaws.com)。
    2
    宛先ポート (例: 5432)。
    3
    宛先サーバーのユーザー名 (例: postgres)。
    4
    ソースホスト名 (例: 127.0.0.1)。
    5
    送信元ポート番号 (例: <forward-to-port> 変数)。
    6
    ソースサーバーのユーザー名 (例: postgres)。
    7
    インポートするデータベースの名前を二重引用符で囲み、スペースで区切ります (例: "backstage_plugin_app" "backstage_plugin_auth" "backstage_plugin_catalog" "backstage_plugin_permission" "backstage_plugin_scaffolder" "backstage_plugin_search")。
  3. データをコピーするための宛先データベースを作成します。

    /bin/bash TO_PSW=<destination-db-password> /path/to/db_copy.sh 
    1
    1
    <destination-db-password> 変数は、宛先データベースに接続するためのパスワードを示します。
    注記

    データのコピーが完了したら、ポート転送を停止できます。大規模データベースの処理と圧縮ツールの使用に関する詳細は、PostgreSQL Web サイトの Handling Large Databases セクションを参照してください。

  4. Backstage カスタムリソース (CR) を再設定します。詳細は、Operator を使用した外部 PostgreSQL インスタンスの設定 を参照してください。
  5. 再設定後、Backstage CR の末尾に次のコードが存在することを確認します。

    # ...
    spec:
      database:
        enableLocalDb: false
      application:
      # ...
        extraFiles:
          secrets:
            - name: <crt-secret>
              key: postgres-crt.pem # key name as in <crt-secret> Secret
        extraEnvs:
          secrets:
            - name: <cred-secret>
    # ...
    注記

    Backstage CR を再設定すると、対応する StatefulSet および Pod オブジェクトは削除されますが、PersistenceVolumeClaim オブジェクトは削除されません。ローカル PersistenceVolumeClaim オブジェクトを削除するには、次のコマンドを使用します。

    oc -n developer-hub delete pvc <local-psql-pvc-name>

    <local-psql-pvc-name> 変数は、data-<psql-pod-name> という形式です。

  6. 設定の変更を適用します。

検証

  1. 次のコマンドを実行して、RHDH インスタンスが移行したデータを使用して実行されており、ローカルの PostgreSQL データベースが含まれていないことを確認します。

    oc get pods -n <your-namespace>
  2. 出力で次の詳細を確認します。

    • backstage-developer-hub-xxx Pod が実行中の状態であること。
    • backstage-psql-developer-hub-0 Pod が利用不可であること。

      これらの詳細は、OpenShift Container Platform Web コンソールの Topology ビューを使用して確認することもできます。

第3章 Kubernetes での TLS 接続を使用した RHDH インスタンスの設定

Azure Red Hat OpenShift (ARO) クラスター、サポートされているクラウドプロバイダーのクラスター、または適切に設定された独自のクラスターなどの Kubernetes クラスターで、Transport Layer Security (TLS) 接続を使用して RHDH インスタンスを設定できます。ただし、Kubernetes クラスターを設定するには、パブリック認証局 (CA) によって署名された証明書を使用する必要があります。

前提条件

  • パブリック CA によって署名された証明書を使用して Azure Red Hat OpenShift (ARO) クラスターをセットアップした。CA 証明書の取得の詳細は、ベンダーのドキュメントを参照してください。
  • namespace を作成し、リソースに対する適切な読み取り権限を持つサービスアカウントを設定した。

    例: ロールベースアクセス制御のための Kubernetes マニフェスト

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: backstage-read-only
    rules:
      - apiGroups:
          - '*'
        resources:
          - pods
          - configmaps
          - services
          - deployments
          - replicasets
          - horizontalpodautoscalers
          - ingresses
          - statefulsets
          - limitranges
          - resourcequotas
          - daemonsets
        verbs:
          - get
          - list
          - watch
    #...

  • サービスアカウントに関連付けられたシークレットとサービス CA 証明書を取得した。
  • いくつかのリソースを作成し、それらにアノテーションを追加して、Kubernetes プラグインでそれらのリソースを検出できるようにした。適用できる Kubernetes アノテーションは、次のとおりです。

    • コンポーネントにラベルを付けるための backstage.io/kubernetes-id
    • namespace にラベルを付けるための backstage.io/kubernetes-namespace

手順

  1. dynamic-plugins-rhdh.yaml ファイルで Kubernetes プラグインを有効にします。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: dynamic-plugins-rhdh
    data:
      dynamic-plugins.yaml: |
        includes:
          - dynamic-plugins.default.yaml
        plugins:
          - package: ./dynamic-plugins/dist/backstage-plugin-kubernetes-backend-dynamic
            disabled: false 
    1
    
          - package: ./dynamic-plugins/dist/backstage-plugin-kubernetes
            disabled: false 
    2
    
            # ...
    1
    値を false に設定して、backstage-plugin-kubernetes-backend-dynamic プラグインを有効にします。
    2
    値を false に設定して、backstage-plugin-kubernetes プラグインを有効にします。
    注記

    backstage-plugin-kubernetes プラグインは、現在 テクノロジープレビュー機能 です。代わりに、一般提供 (GA) 機能である ./dynamic-plugins/dist/backstage-plugin-topology-dynamic プラグインを使用することもできます。

  2. Kubernetes クラスターの詳細を設定し、app-config-rhdh.yaml ファイルでカタログ同期オプションを設定します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: app-config-rhdh
    data:
      "app-config-rhdh.yaml": |
      # ...
      catalog:
        rules:
          - allow: [Component, System, API, Resource, Location]
        providers:
          kubernetes:
            openshift:
              cluster: openshift
              processor:
                namespaceOverride: default
                defaultOwner: guests
              schedule:
                frequency:
                  seconds: 30
                timeout:
                  seconds: 5
      kubernetes:
        serviceLocatorMethod:
          type: 'multiTenant'
        clusterLocatorMethods:
          - type: 'config'
            clusters:
              - url: <target-cluster-api-server-url> 
    1
    
                name: openshift
                authProvider: 'serviceAccount'
                skipTLSVerify: false 
    2
    
                skipMetricsLookup: true
                dashboardUrl: <target-cluster-console-url> 
    3
    
                dashboardApp: openshift
                serviceAccountToken: ${K8S_SERVICE_ACCOUNT_TOKEN} 
    4
    
                caData: ${K8S_CONFIG_CA_DATA} 
    5
    
                # ...
    1
    Kubernetes コントロールプレーンのベース URL。ベース URL は、kubectl cluster-info コマンドを実行して取得できます。
    2
    このパラメーターの値を false に設定して、TLS 証明書の検証を有効にします。
    3
    オプション: ARO クラスターを管理する Kubernetes ダッシュボードへのリンク。
    4
    オプション: secrets-rhdh シークレットで定義できる K8S_SERVICE_ACCOUNT_TOKEN 環境変数を使用して、サービスアカウントトークンを渡します。
    5
    secrets-rhdh シークレットで定義できる K8S_CONFIG_CA_DATA 環境変数を使用して、CA データを渡します。
  3. 設定変更を保存します。

検証

  1. RHDH アプリケーションを実行してカタログをインポートします。

    kubectl -n rhdh-operator get pods -w
  2. Pod ログに設定に関するエラーが表示されていないことを確認します。
  3. Catalog に移動し、Developer Hub インスタンスのコンポーネントページをチェックして、クラスター接続と作成したリソースの存在を確認します。
注記

証明書の問題や権限などに関する接続エラーが発生した場合は、コンポーネントページのメッセージボックスを確認するか、Pod のログを表示してください。

第4章 テレメトリーデータ収集

テレメトリーデータ収集機能は、テレメトリーデータを収集および分析して、Red Hat Developer Hub のエクスペリエンスを向上させるのに役立ちます。この機能はデフォルトで有効化されています。

重要

管理者は、ニーズに応じてテレメトリーデータ収集機能を無効にできます。たとえば、エアギャップ環境では、この機能を無効にすることで、RHDH アプリケーションの応答性に影響を与える不要な送信要求を回避できます。詳細は、RHDH でのテレメトリーデータ収集の無効化 セクションを参照してください。

Red Hat は以下のデータを収集して分析します。

  • ページ訪問やリンクまたはボタンのクリックのイベント。
  • システム関連の情報 (ロケール、タイムゾーン、ブラウザーや OS の詳細を含むユーザーエージェントなど)。
  • ページ関連の情報 (タイトル、カテゴリー、拡張機能名、URL、パス、リファラー、検索パラメーターなど)。
  • 匿名の IP アドレス (0.0.0.0 として記録)。
  • 匿名化されたユーザー名ハッシュ。これは、RHDH アプリケーションの一意のユーザー数を識別するためにのみ使用される一意の識別子です。

RHDH を使用すると、ニーズに応じてテレメトリーデータ収集機能とテレメトリーの Segment ソース設定をカスタマイズできます。

4.1. RHDH でのテレメトリーデータ収集の無効化

テレメトリーデータの収集を無効にするには、Helm チャートまたは Red Hat Developer Hub Operator 設定を使用して analytics-provider-segment プラグインを無効にする必要があります。

4.1.1. Helm チャートを使用したテレメトリーデータ収集の無効化

Helm チャートを使用してテレメトリーデータ収集機能を無効にできます。

前提条件

手順

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブで、Helm ビューに移動して Helm リリースのリストを表示します。
  2. 使用する Helm リリースの オーバーフロー メニューをクリックし、Upgrade を選択します。

    注記

    Create ボタンをクリックして新しい Helm リリースを作成し、設定を編集してテレメトリーを無効にすることもできます。

  3. Form ビューか YAML ビューを使用して、Helm 設定を編集します。

    • Form view を使用する場合

      1. Root Schema → global → Dynamic plugins configuration. → List of dynamic plugins that should be installed in the backstage application を展開します。
      2. Add list of dynamic plugins that should be installed in the backstage application リンクをクリックします。
      3. 以下のいずれかの手順を実行します。

        • プラグインを設定していない場合は、Package specification of the dynamic plugin to install. It should be usable by the npm pack command. フィールドに次の値を追加します。

          ./dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment

          Telemetry の無効化
        • プラグインを設定済みの場合は、Package specification of the dynamic plugin to install. It should be usable by the npm pack command. フィールドに ./dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment という値があることを確認します。
      4. Disable the plugin チェックボックスをオンにします。
      5. Upgrade をクリックします。
    • YAML view を使用する場合

      1. 以下のいずれかの手順を実行します。

        • プラグインを設定していない場合は、values.yaml Helm 設定ファイルに次の YAML コードを追加します。

          # ...
          global:
            dynamic:
              plugins:
                - package: './dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment'
                  disabled: true
          # ...
        • プラグインを設定済みの場合は、Helm 設定でプラグインを検索し、plugins.disabled パラメーターの値を true に設定します。
      2. Upgrade をクリックします。

4.1.2. Operator を使用したテレメトリーデータ収集の無効化

Operator を使用してテレメトリーデータ収集機能を無効にできます。

前提条件

手順

  1. 以下のいずれかの手順を実行します。

    • dynamic-plugins-rhdh ConfigMap ファイルを作成し、analytics-provider-segment プラグインを設定していない場合は、このプラグインをプラグインのリストに追加し、その plugins.disabled パラメーターを true に設定します。
    • dynamic-plugins-rhdh ConfigMap ファイルを作成し、analytics-provider-segment プラグインを設定済みの場合は、プラグインのリストでこのプラグインを検索し、その plugins.disabled パラメーターを true に設定します。
    • ConfigMap ファイルをまだ作成していない場合は、次の YAML コードを使用して作成します。

      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: dynamic-plugins-rhdh
      data:
        dynamic-plugins.yaml: |
          includes:
            - dynamic-plugins.default.yaml
          plugins:
            - package: './dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment'
              disabled: true
  2. dynamicPluginsConfigMapName パラメーターの値を、Backstage カスタムリソース内の ConfigMap ファイルの名前に設定します。

    # ...
    spec:
      application:
        dynamicPluginsConfigMapName: dynamic-plugins-rhdh
    # ...
  3. 設定変更を保存します。

4.2. RHDH でのテレメトリーデータ収集の有効化

テレメトリーデータ収集機能はデフォルトで有効になっています。ただし、この機能を無効にしていて再度有効にする場合は、Helm チャートまたは Red Hat Developer Hub Operator 設定を使用して analytics-provider-segment プラグインを有効にする必要があります。

4.2.1. Helm チャートを使用したテレメトリーデータ収集の有効化

Helm チャートを使用してテレメトリーデータ収集機能を有効にできます。

前提条件

手順

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブで、Helm ビューに移動して Helm リリースのリストを表示します。
  2. 使用する Helm リリースの オーバーフロー メニューをクリックし、Upgrade を選択します。

    注記

    Create ボタンをクリックして新しい Helm リリースを作成し、設定を編集してテレメトリーを有効にすることもできます。

  3. Form ビューか YAML ビューを使用して、Helm 設定を編集します。

    • Form view を使用する場合

      1. Root Schema → global → Dynamic plugins configuration. → List of dynamic plugins that should be installed in the backstage application を展開します。
      2. Add list of dynamic plugins that should be installed in the backstage application リンクをクリックします。
      3. 以下のいずれかの手順を実行します。

        • プラグインを設定していない場合は、Package specification of the dynamic plugin to install. It should be usable by the npm pack command. フィールドに次の値を追加します。

          ./dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment

        • プラグインを設定済みの場合は、Package specification of the dynamic plugin to install. It should be usable by the npm pack command. フィールドに ./dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment という値があることを確認します。
      4. Disable the plugin チェックボックスをオフにします。
      5. Upgrade をクリックします。
    • YAML view を使用する場合

      1. 以下のいずれかの手順を実行します。

        • プラグインを設定していない場合は、Helm 設定ファイルに次の YAML コードを追加します。

          # ...
          global:
            dynamic:
              plugins:
                - package: './dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment'
                  disabled: false
          # ...
        • プラグインを設定済みの場合は、Helm 設定でプラグインを検索し、plugins.disabled パラメーターの値を false に設定します。
      2. Upgrade をクリックします。

4.2.2. Operator を使用したテレメトリーデータ収集の有効化

Operator を使用してテレメトリーデータ収集機能を有効にできます。

前提条件

手順

  1. 以下のいずれかの手順を実行します。

    • dynamic-plugins-rhdh ConfigMap ファイルを作成し、analytics-provider-segment プラグインを設定していない場合は、このプラグインをプラグインのリストに追加し、その plugins.disabled パラメーターを false に設定します。
    • dynamic-plugins-rhdh ConfigMap ファイルを作成し、analytics-provider-segment プラグインを設定済みの場合は、プラグインのリストでこのプラグインを検索し、その plugins.disabled パラメーターを false に設定します。
    • ConfigMap ファイルをまだ作成していない場合は、次の YAML コードを使用して作成します。

      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: dynamic-plugins-rhdh
      data:
        dynamic-plugins.yaml: |
          includes:
            - dynamic-plugins.default.yaml
          plugins:
            - package: './dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment'
              disabled: false
  2. dynamicPluginsConfigMapName パラメーターの値を、Backstage カスタムリソース内の ConfigMap ファイルの名前に設定します。

    # ...
    spec:
      application:
        dynamicPluginsConfigMapName: dynamic-plugins-rhdh
    # ...
  3. 設定変更を保存します。

4.3. テレメトリーの Segment ソースのカスタマイズ

analytics-provider-segment プラグインは、収集されたテレメトリーデータをデフォルトで Red Hat に送信します。ただし、要件に応じて、テレメトリーデータを受信する新しい Segment ソースを設定できます。設定には、Segment ソースを参照する一意の Segment 書き込みキーが必要です。

注記

新しい Segment ソースを設定すると、テレメトリーデータ収集 セクションで説明されているものと同じデータセットを収集して分析できます。アプリケーションユーザー向けに独自のテレメトリーデータ収集通知を作成する必要がある場合もあります。

4.3.1. Helm チャートを使用したテレメトリーの Segment ソースのカスタマイズ

Helm チャートを使用して、Segment ソースとの統合を設定できます。

前提条件

手順

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブで、Helm ビューに移動して Helm リリースのリストを表示します。
  2. 使用する Helm リリースの オーバーフロー メニューをクリックし、Upgrade を選択します。
  3. Form ビューか YAML ビューを使用して、Helm 設定を編集します。

    • Form view を使用する場合

      1. Root Schema → Backstage Chart Schema → Backstage Parameters → Backstage container environment variables を展開します。
      2. Add Backstage container environment variables リンクをクリックします。
      3. Segment キーの名前と値を入力します。

        Segment ソースの Helm
      4. Upgrade をクリックします。
    • YAML view を使用する場合

      1. 以下の YAML コードを Helm 設定ファイルに追加します。

        # ...
        upstream:
          backstage:
            extraEnvVars:
              - name: SEGMENT_WRITE_KEY
                value: <segment_key> 
        1
        
        # ...
        1
        <segment_key> は、Segment ソースの一意の識別子に置き換えます。
      2. Upgrade をクリックします。

4.3.2. Operator を使用したテレメトリーの Segment ソースのカスタマイズ

Operator を使用して、Segment ソースとの統合を設定できます。

前提条件

手順

  1. Backstage カスタムリソース (CR) に次の YAML コードを追加します。

    # ...
    spec:
      application:
        extraEnvs:
          envs:
            - name: SEGMENT_WRITE_KEY
              value: <segment_key> 
    1
    
    # ...
    1
    <segment_key> は、Segment ソースの一意の識別子に置き換えます。
  2. 設定変更を保存します。

第5章 OpenShift Container Platform 上の Red Hat Developer Hub に対する可観測性の有効化

OpenShift Container Platform では、メトリクスは /metrics の正規名の下に HTTP サービスエンドポイント経由で公開されます。ServiceMonitor カスタムリソース (CR) を作成して、ユーザー定義プロジェクトのサービスエンドポイントからメトリクスをスクレイピングできます。

OpenShift Container Platform Web コンソールの Developer パースペクティブから、Red Hat Developer Hub Helm デプロイメントのメトリクスを有効にして表示できます。

前提条件

  • OpenShift Container Platform クラスターで、ユーザー定義プロジェクトの監視 が有効になっている。
  • Helm チャートを使用して、OpenShift Container Platform に Red Hat Developer Hub をインストールしている。

手順

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブから、Topology ビューを選択します。
  2. Red Hat Developer Hub Helm チャートのオーバーフローメニューをクリックし、Upgrade を選択します。

    Helm アップグレード
  3. Upgrade Helm Release ページで、Configure viaYAML view オプションを選択し、次の例に示すように、YAML で metrics セクションを設定します。

    upstream:
    # ...
      metrics:
        serviceMonitor:
          enabled: true
          path: /metrics
    # ...
    Helm メトリクスのアップグレード
  4. Upgrade をクリックします。

検証

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブから、Observe ビューを選択します。
  2. Metrics タブをクリックして、Red Hat Developer Hub Pod のメトリクスを表示します。

OpenShift Container Platform Web コンソールの Developer パースペクティブから、Operator によってインストールした Red Hat Developer Hub インスタンスのメトリクスを有効にして表示できます。

前提条件

  • OpenShift Container Platform クラスターで、ユーザー定義プロジェクトの監視 が有効になっている。
  • Red Hat Developer Hub Operator を使用して、OpenShift Container Platform に Red Hat Developer Hub をインストールしている。
  • OpenShift CLI (oc) がインストールされている。

手順

現在、Red Hat Developer Hub Operator は、デフォルトで ServiceMonitor カスタムリソース (CR) の作成をサポートしていません。エンドポイントからメトリクスをスクレイピングするための ServiceMonitor CR を作成するには、次の手順を完了する必要があります。

  1. ServiceMonitor CR を YAML ファイルとして作成します。

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: <custom_resource_name> 
    1
    
      namespace: <project_name> 
    2
    
      labels:
        app.kubernetes.io/instance: <custom_resource_name>
        app.kubernetes.io/name: backstage
    spec:
      namespaceSelector:
        matchNames:
          - <project_name>
      selector:
        matchLabels:
          rhdh.redhat.com/app: backstage-<custom_resource_name>
      endpoints:
      - port: backend
        path: '/metrics'
    1
    <custom_resource_name> は、Red Hat Developer Hub の CR の名前に置き換えます。
    2
    <project_name> は、Red Hat Developer Hub インスタンスが実行されている OpenShift Container Platform プロジェクトの名前に置き換えます。
  2. 次のコマンドを実行して、ServiceMonitor CR を適用します。

    oc apply -f <filename>

検証

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブから、Observe ビューを選択します。
  2. Metrics タブをクリックして、Red Hat Developer Hub Pod のメトリクスを表示します。

第6章 RHDH アプリケーションを企業のプロキシーの背後で実行

アプリケーションを起動する前に、次のいずれかの環境変数を設定することにより、RHDH アプリケーションを企業プロキシーの背後で実行できます。

  • HTTP_PROXY: HTTP リクエストに使用するプロキシーを示します。
  • HTTPS_PROXY: HTTPS リクエストに使用するプロキシーを示します。

さらに、NO_PROXY 環境変数を設定して、特定のドメインをプロキシーから除外することもできます。変数値は、プロキシーが指定されている場合でも、プロキシーを必要としないホスト名のコンマ区切りリストです。

6.1. Helm デプロイメントでのプロキシー情報の設定

Helm ベースのデプロイメントの場合、クラスター内にリソースを作成する権限を持つ開発者またはクラスター管理者は、values.yaml Helm 設定ファイルでプロキシー変数を設定できます。

前提条件

  • Red Hat Developer Hub アプリケーションがインストールされている。

手順

  1. Helm 設定ファイルでプロキシー情報を設定します。

    upstream:
      backstage:
        extraEnvVars:
          - name: HTTP_PROXY
            value: '<http_proxy_url>'
          - name: HTTPS_PROXY
            value: '<https_proxy_url>'
          - name: NO_PROXY
            value: '<no_proxy_settings>'

    詳細は以下のようになります。

    <http_proxy_url>
    HTTP プロキシー URL に置き換える必要がある変数を示します。
    <https_proxy_url>
    HTTPS プロキシー URL に置き換える必要がある変数を示します。
    <no_proxy_settings>

    プロキシーから除外するコンマ区切りの URL に置き換える必要がある変数を示します (例: foo.com,baz.com)。

    例: Helm チャートを使用してプロキシー変数を設定する

    upstream:
      backstage:
        extraEnvVars:
          - name: HTTP_PROXY
            value: 'http://10.10.10.105:3128'
          - name: HTTPS_PROXY
            value: 'http://10.10.10.106:3128'
          - name: NO_PROXY
            value: 'localhost,example.org'

  2. 設定変更を保存します。

6.2. Operator デプロイメントでのプロキシー情報の設定

Operator ベースのデプロイメントの場合、プロキシー設定に使用するアプローチはロールによって異なります。

  • クラスター管理者は、Operator namespace へのアクセス権を持つため、Operator のデフォルトの ConfigMap ファイルでプロキシー変数を設定できます。この設定は、Operator のすべてのユーザーにプロキシー設定を適用します。
  • 開発者は、カスタムリソース (CR) ファイルでプロキシー変数を設定できます。この設定は、その CR から作成された RHDH アプリケーションにプロキシー設定を適用します。

前提条件

  • Red Hat Developer Hub アプリケーションがインストールされている。

手順

  1. ロールに応じて、次のいずれかの手順を実行します。

    • 管理者として、プロキシー情報を Operator のデフォルトの ConfigMap ファイルに設定します。

      1. デフォルトの namespace rhdh-operatorbackstage-default-config という名前の ConfigMap ファイルを検索して開きます。
      2. deployment.yaml キーを見つけます。
      3. 次の例に示すように、Deployment 仕様で HTTP_PROXYHTTPS_PROXY、および NO_PROXY 環境変数の値を設定します。

        例: ConfigMap ファイルでプロキシー変数を設定する

        # Other fields omitted
          deployment.yaml: |-
            apiVersion: apps/v1
            kind: Deployment
            spec:
              template:
                spec:
                  # Other fields omitted
                  initContainers:
                    - name: install-dynamic-plugins
                      # command omitted
                      env:
                        - name: NPM_CONFIG_USERCONFIG
                          value: /opt/app-root/src/.npmrc.dynamic-plugins
                        - name: HTTP_PROXY
                          value: 'http://10.10.10.105:3128'
                        - name: HTTPS_PROXY
                          value: 'http://10.10.10.106:3128'
                        - name: NO_PROXY
                          value: 'localhost,example.org'
                      # Other fields omitted
                  containers:
                    - name: backstage-backend
                      # Other fields omitted
                      env:
                        - name: APP_CONFIG_backend_listen_port
                          value: "7007"
                        - name: HTTP_PROXY
                          value: 'http://10.10.10.105:3128'
                        - name: HTTPS_PROXY
                          value: 'http://10.10.10.106:3128'
                        - name: NO_PROXY
                          value: 'localhost,example.org'

    • 開発者は、次の例に示すように、カスタムリソース (CR) ファイルにプロキシー情報を設定します。

      例: CR ファイルでプロキシー変数を設定する

      spec:
        # Other fields omitted
        application:
          extraEnvs:
            envs:
              - name: HTTP_PROXY
                value: 'http://10.10.10.105:3128'
              - name: HTTPS_PROXY
                value: 'http://10.10.10.106:3128'
              - name: NO_PROXY
                value: 'localhost,example.org'

  2. 設定変更を保存します。

第7章 Red Hat Developer Hub と Amazon Web Services (AWS) の統合

Red Hat Developer Hub アプリケーションを Amazon Web Services (AWS) と統合すると、AWS エコシステム内のワークフローを合理化できます。Developer Hub リソースを AWS と統合することで、ツール、サービス、ソリューションの包括的なスイートにアクセスできるようになります。

AWS との統合には、次のいずれかの方法を使用して Elastic Kubernetes Service (EKS) の Developer Hub のデプロイメントが必要です。

  • Helm チャート
  • Red Hat Developer Hub Operator

7.1. Red Hat Developer Hub の Amazon Web Services (AWS) によるモニタリングおよびロギング

Red Hat Developer Hub では、Amazon Web Services (AWS) の統合により、モニタリングおよびロギングが容易になります。リアルタイム監視のための Amazon CloudWatch や、包括的なログ記録のための Amazon Prometheus などの機能を使用すると、AWS インフラストラクチャーでホストされている Developer Hub アプリケーションの信頼性、スケーラビリティー、およびコンプライアンスを確保できます。

この統合により、Red Hat エコシステム内でアプリケーションを監視、診断、改良できるようになり、開発と運用のプロセスが改善されます。

7.1.1. Amazon Prometheus によるモニタリング

Red Hat Developer Hub は、実行中のアプリケーションに関連する Prometheus メトリクスを提供します。EKS クラスターで Prometheus を有効化またはデプロイする方法の詳細は、Amazon ドキュメントの Prometheus metrics を参照してください。

Amazon Prometheus を使用して Developer Hub を監視するには、Prometheus ワークスペース用の Amazon マネージドサービスを作成し、Developer Hub Prometheus メトリクスの取り込みを設定する必要があります。詳細は、Amazon ドキュメントの Create a workspace セクションおよび Ingest Prometheus metrics to the workspace セクションを参照してください。

作成したワークスペースに Prometheus メトリクスを取り込んだら、特定の Pod アノテーションに基づいて、Pod からデータを抽出するためのメトリクススクレイピングを設定できます。

7.1.1.1. モニタリング用のアノテーションの設定

Helm デプロイメントと Operator がサポートするデプロイメントの両方で監視用のアノテーションを設定できます。

Helm のデプロイメント

backstage Pod に監視用のアノテーションを付けるには、values.yaml ファイルを次のように更新します。

upstream:
  backstage:
    # --- TRUNCATED ---
    podAnnotations:
      prometheus.io/scrape: 'true'
      prometheus.io/path: '/metrics'
      prometheus.io/port: '7007'
      prometheus.io/scheme: 'http'
Operator がサポートするデプロイメント

手順

  1. Operator の管理者として、デフォルト設定を編集して、次のように Prometheus アノテーションを追加します。

    # Update OPERATOR_NS accordingly
    OPERATOR_NS=rhdh-operator
    kubectl edit configmap backstage-default-config -n "${OPERATOR_NS}"
  2. ConfigMap で deployment.yaml キーを見つけて、次のようにアノテーションを spec.template.metadata.annotations フィールドに追加します。

    deployment.yaml: |-
      apiVersion: apps/v1
      kind: Deployment
      # --- truncated ---
      spec:
        template:
          # --- truncated ---
          metadata:
            labels:
             rhdh.redhat.com/app:  # placeholder for 'backstage-<cr-name>'
            # --- truncated ---
            annotations:
              prometheus.io/scrape: 'true'
              prometheus.io/path: '/metrics'
              prometheus.io/port: '7007'
              prometheus.io/scheme: 'http'
      # --- truncated ---
  3. 変更を保存します。

検証

スクレイピングが機能するかどうかを確認するには、以下の手順を実行します。

  1. 次のように、kubectl を使用して Prometheus コンソールをローカルマシンにポート転送します。

    kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090
  2. Web ブラウザーを開いて http://localhost:9090 に移動し、Prometheus コンソールにアクセスします。
  3. process_cpu_user_seconds_total などの関連メトリクスを監視します。

7.1.2. Amazon CloudWatch ログを使用したロギング

Red Hat Developer Hub 内のロギングは、winston ライブラリー に依存します。デフォルトでは、デバッグレベルのログは記録されません。デバッグログをアクティブにするには、Red Hat Developer Hub インスタンスで環境変数 LOG_LEVEL を debug に設定する必要があります。

7.1.2.1. アプリケーションログレベルの設定

Helm デプロイメントと Operator がサポートするデプロイメントの両方で、アプリケーションログレベルを設定できます。

Helm のデプロイメント

ロギングレベルを更新するには、Helm チャートの values.yaml ファイルに環境変数 LOG_LEVEL を追加します。

upstream:
  backstage:
    # --- Truncated ---
    extraEnvVars:
      - name: LOG_LEVEL
        value: debug
Operator がサポートするデプロイメント

次のように、カスタムリソースに環境変数 LOG_LEVEL を含めることで、ロギングレベルを変更できます。

spec:
  # Other fields omitted
  application:
    extraEnvs:
      envs:
        - name: LOG_LEVEL
          value: debug
7.1.2.2. Amazon CloudWatch からのログの取得

CloudWatch Container Insights は、Amazon EKS のログとメトリクスをキャプチャーするために使用されます。詳細は、Logging for Amazon EKS ドキュメントを参照してください。

ログとメトリクスをキャプチャーするには、Amazon CloudWatch Observability EKS アドオンをクラスターにインストールします。Container Insights のセットアップ後、Logs Insights または Live Tail ビューを使用してコンテナーログにアクセスできます。

CloudWatch は、すべてのコンテナーログが統合されるロググループに、次のように名前を付けます。

/aws/containerinsights/<ClusterName>/application

以下は、Developer Hub インスタンスからログを取得するためのクエリーの例です。

fields @timestamp, @message, kubernetes.container_name
| filter kubernetes.container_name in ["install-dynamic-plugins", "backstage-backend"]

7.2. Red Hat Developer Hub の認証プロバイダーとして Amazon Cognito を使用する

Amazon Cognito は、Developer Hub に認証層を追加するための AWS サービスです。ユーザープールを使用して Developer Hub に直接サインインすることも、サードパーティーのアイデンティティープロバイダーを介してフェデレーションすることもできます。

Amazon Cognito は、Developer Hub のコア認証プロバイダーには含まれませんが、汎用の OpenID Connect (OIDC) プロバイダーを使用して統合できます。

Helm チャートベースと Operator ベースのデプロイメントの両方で Developer Hub を設定できます。

前提条件

  • ユーザープールがあるか、新しいユーザープールを作成した。ユーザープールの詳細は、Amazon Cognito user pools ドキュメントを参照してください。

    注記

    ユーザープールが配置されている AWS リージョンとユーザープール ID を必ず書き留めてください。

  • ホストされた UI を統合するために、ユーザープール内にアプリケーションクライアントを作成した。詳細は、Setting up the hosted UI with the Amazon Cognito console を参照してください。

    Amazon Cognito コンソールを使用してホストされた UI をセットアップするときは、必ず次の調整を行ってください。

    1. Allowed callback URL(s) セクションに、URL https://<rhdh_url>/api/auth/oidc/handler/frame を含めます。<rhdh_url> は Developer Hub アプリケーションの URL (my.rhdh.example.com など) に置き換えてください。
    2. 同様に、Allowed sign-out URL(s) セクションに https://<rhdh_url> を追加します。<rhdh_url> は Developer Hub アプリケーションの URL (my.rhdh.example.com など) に置き換えます。
    3. OAuth 2.0 grant types で、Authorization code grant を選択して認証コードを返します。
    4. OpenID Connect scopes で、少なくとも次のスコープを選択してください。

      • OpenID
      • Profile
      • Email
    Helm のデプロイメント

    手順

    1. 次のようにして、カスタム app-config-rhdh ConfigMap を編集または作成します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: app-config-rhdh
      data:
        "app-config-rhdh.yaml": |
          # --- Truncated ---
          app:
            title: Red Hat Developer Hub
      
          signInPage: oidc
          auth:
            environment: production
            session:
              secret: ${AUTH_SESSION_SECRET}
            providers:
              oidc:
                production:
                  clientId: ${AWS_COGNITO_APP_CLIENT_ID}
                  clientSecret: ${AWS_COGNITO_APP_CLIENT_SECRET}
                  metadataUrl: ${AWS_COGNITO_APP_METADATA_URL}
                  callbackUrl: ${AWS_COGNITO_APP_CALLBACK_URL}
                  scope: 'openid profile email'
                  prompt: auto
    2. 次のテンプレートを使用して、カスタム secrets-rhdh Secret を編集または作成します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: secrets-rhdh
      stringData:
        AUTH_SESSION_SECRET: "my super auth session secret - change me!!!"
        AWS_COGNITO_APP_CLIENT_ID: "my-aws-cognito-app-client-id"
        AWS_COGNITO_APP_CLIENT_SECRET: "my-aws-cognito-app-client-secret"
        AWS_COGNITO_APP_METADATA_URL: "https://cognito-idp.[region].amazonaws.com/[userPoolId]/.well-known/openid-configuration"
        AWS_COGNITO_APP_CALLBACK_URL: "https://[rhdh_dns]/api/auth/oidc/handler/frame"
    3. values.yaml ファイルに、ConfigMap リソースと Secret リソースの両方の参照を追加します。

      upstream:
        backstage:
          image:
            pullSecrets:
            - rhdh-pull-secret
          podSecurityContext:
            fsGroup: 2000
          extraAppConfig:
            - filename: app-config-rhdh.yaml
              configMapRef: app-config-rhdh
          extraEnvVarsSecrets:
            - secrets-rhdh
    4. Helm デプロイメントをアップグレードします。

      helm upgrade rhdh \
        openshift-helm-charts/redhat-developer-hub \
        [--version 1.2.6] \
        --values /path/to/values.yaml
    Operator がサポートするデプロイメント
    1. 次のコードを app-config-rhdh ConfigMap に追加します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: app-config-rhdh
      data:
        "app-config-rhdh.yaml": |
          # --- Truncated ---
      
          signInPage: oidc
          auth:
            # Production to disable guest user login
            environment: production
            # Providing an auth.session.secret is needed because the oidc provider requires session support.
            session:
              secret: ${AUTH_SESSION_SECRET}
            providers:
              oidc:
                production:
                  # See https://github.com/backstage/backstage/blob/master/plugins/auth-backend-module-oidc-provider/config.d.ts
                  clientId: ${AWS_COGNITO_APP_CLIENT_ID}
                  clientSecret: ${AWS_COGNITO_APP_CLIENT_SECRET}
                  metadataUrl: ${AWS_COGNITO_APP_METADATA_URL}
                  callbackUrl: ${AWS_COGNITO_APP_CALLBACK_URL}
                  # Minimal set of scopes needed. Feel free to add more if needed.
                  scope: 'openid profile email'
      
                  # Note that by default, this provider will use the 'none' prompt which assumes that your are already logged on in the IDP.
                  # You should set prompt to:
                  # - auto: will let the IDP decide if you need to log on or if you can skip login when you have an active SSO session
                  # - login: will force the IDP to always present a login form to the user
                  prompt: auto
    2. secrets-rhdh Secret に次のコードを追加します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: secrets-rhdh
      stringData:
        # --- Truncated ---
      
        # TODO: Change auth session secret.
        AUTH_SESSION_SECRET: "my super auth session secret - change me!!!"
      
        # TODO: user pool app client ID
        AWS_COGNITO_APP_CLIENT_ID: "my-aws-cognito-app-client-id"
      
        # TODO: user pool app client Secret
        AWS_COGNITO_APP_CLIENT_SECRET: "my-aws-cognito-app-client-secret"
      
        # TODO: Replace region and user pool ID
        AWS_COGNITO_APP_METADATA_URL: "https://cognito-idp.[region].amazonaws.com/[userPoolId]/.well-known/openid-configuration"
      
        # TODO: Replace <rhdh_dns>
        AWS_COGNITO_APP_CALLBACK_URL: "https://[rhdh_dns]/api/auth/oidc/handler/frame"
    3. カスタムリソースに app-config-rhdh ConfigMap と secrets-rhdh Secret の両方への参照が含まれていることを確認します。

      apiVersion: rhdh.redhat.com/v1alpha1
      kind: Backstage
      metadata:
       # TODO: this the name of your Developer Hub instance
        name: my-rhdh
      spec:
        application:
          imagePullSecrets:
          - "rhdh-pull-secret"
          route:
            enabled: false
          appConfig:
            configMaps:
              - name: "app-config-rhdh"
          extraEnvs:
            secrets:
              - name: "secrets-rhdh"
    4. オプション: カスタムリソースがサポートする既存の Developer Hub インスタンスがあり、それを編集していない場合は、Developer Hub デプロイメントを手動で削除し、Operator を使用して再作成できます。次のコマンドを実行して、Developer Hub デプロイメントを削除します。

      kubectl delete deployment -l app.kubernetes.io/instance=<CR_NAME>

検証

  1. Developer Hub の Web URL に移動し、OIDC 認証を使用してサインインします。これにより、設定した AWS Cognito ユーザープールを介して認証するよう求められます。
  2. ログインしたら、Settings にアクセスしてユーザーの詳細を確認します。

第8章 Red Hat Developer Hub と Microsoft Azure Kubernetes Service (AKS) の統合

Developer Hub を Microsoft Azure Kubernetes Service と統合すると、開発が大幅に進歩し、アプリケーションをビルド、デプロイ、および管理するための合理化された環境が提供されます。

この統合には、次のいずれかの方法を使用した AKS 上の Developer Hub のデプロイメントが必要です。

  • Helm チャート
  • Red Hat Developer Hub Operator

8.1. Red Hat Developer Hub の Azure Kubernetes Services (AKS) によるモニタリングおよびロギング

監視およびロギングは、Red Hat Developer Hub での Azure Kubernetes Services (AKS) の管理および保守に不可欠な要素です。Managed Prometheus Monitoring や Azure Monitor 統合などの機能により、管理者はリソース使用率を効率的に監視し、問題を診断し、コンテナー化されたワークロードの信頼性を確保できます。

Managed Prometheus Monitoring を有効にするには、次のように、新しいクラスターの作成か既存のクラスターの更新かに応じて、az aks create または az aks update コマンドで -enable-azure-monitor-metrics オプションを使用します。

az aks create/update --resource-group <your-ResourceGroup> --name <your-Cluster> --enable-azure-monitor-metrics

上記のコマンドは、Prometheus メトリクス を収集するメトリクスアドオンをインストールします。上記のコマンドを使用すると、ネイティブ Azure Monitor メトリクスと Prometheus メトリクスの両方による Azure リソースの監視を有効にできます。ポータルの Monitoring → Insights で結果を表示することもできます。詳細は、Monitor Azure resources with Azure Monitor を参照してください。

さらに、Managed Prometheus サービスと Azure Monitor の両方のメトリクスには、Azure Managed Grafana サービスからアクセスできます。詳細は、Link a Grafana workspace セクションを参照してください。

デフォルトでは、Prometheus は最小取り込みプロファイルを使用します。これにより、取り込み量が最適化され、スクレイピング頻度、ターゲット、および収集するメトリクスのデフォルト設定が指定されます。デフォルト設定は、カスタム設定を使用してカスタマイズできます。Azure では、スクレイピング設定やその他のメトリクスアドオン設定を提供するために、さまざまな ConfigMap の使用を含むさまざまな方法が提供されています。デフォルトの設定の詳細は、Default Prometheus metrics configuration in Azure Monitor および Customize scraping of Prometheus metrics in Azure Monitor managed service for Prometheus ドキュメントを参照してください。

8.1.1. Azure Kubernetes Services (AKS) を使用したログの表示

Kubernetes オブジェクトによって生成されたライブデータログにアクセスし、AKS 内の Container Insights でログデータを収集できます。

前提条件

  • Developer Hub が AKS にデプロイされている。

詳細は、Azure Kubernetes Service (AKS) への Red Hat Developer Hub のインストール を参照してください。

assembly-install-rhdh-aks.adoc

手順

Developer Hub インスタンスからのライブログの表示
  1. Azure Portal に移動します。
  2. リソースグループ <your-ResourceGroup> を検索し、AKS クラスター <your-Cluster> を見つけます。
  3. メニューから Kubernetes resources → Workloads を選択します。
  4. <your-rhdh-cr>-developer-hub デプロイメント (Helm チャートインストールの場合) または <your-rhdh-cr>-backstage デプロイメント (Operator ベースのインストールの場合) を選択します。
  5. 左側のメニューで Live Logs をクリックします。
  6. Pod を選択します。

    注記

    Pod は 1 つだけである必要があります。

ライブログデータが収集され、表示されます。

Container Engine からのリアルタイムログデータの表示
  1. Azure Portal に移動します。
  2. リソースグループ <your-ResourceGroup> を検索し、AKS クラスター <your-Cluster> を見つけます。
  3. メニューから MonitoringInsights を選択します。
  4. Containers タブに移動します。
  5. backend-backstage コンテナーを見つけてクリックすると、Container Engine によって生成されるリアルタイムログデータが表示されます。

8.2. Red Hat Developer Hub の認証プロバイダーとして Microsoft Azure を使用する

Developer Hub の core-plugin-api パッケージは Microsoft Azure 認証プロバイダーと統合しており、Azure OAuth を使用してサインインを認証します。

前提条件

  • Developer Hub が AKS にデプロイされている。

詳細は、Azure Kubernetes Service (AKS) への Red Hat Developer Hub のインストール を参照してください。

8.2.1. Helm デプロイメントの認証プロバイダーとして Microsoft Azure を使用する

Helm チャートを使用してインストールすると、Microsoft Azure を Red Hat Developer Hub の認証プロバイダーとして使用できます。

詳細は、Helm チャートを使用した AKS への Developer Hub のデプロイ を参照してください。

手順

  1. アプリケーションが登録されたら、次の点を書き留めます。

    • clientId: アプリケーション (クライアント) ID。App Registration → Overview にあります。
    • clientSecret: シークレット。*App Registration → Certificates & secrets にあります (必要に応じて新規作成します)。
    • tenantId: ディレクトリー (テナント) ID。App Registration → Overview にあります。
  2. 次のフラグメントが Developer Hub ConfigMap に含まれていることを確認します。

    auth:
      environment: production
      providers:
        microsoft:
          production:
            clientId: ${AZURE_CLIENT_ID}
            clientSecret: ${AZURE_CLIENT_SECRET}
            tenantId: ${AZURE_TENANT_ID}
            domainHint: ${AZURE_TENANT_ID}
            additionalScopes:
              - Mail.Send

    新しいファイルを作成することも、既存のファイルに追加することもできます。

  3. ConfigMap を Kubernetes クラスターに適用します。

    kubectl -n <your_namespace> apply -f <app-config>.yaml
  4. Azure 認証情報を含む既存の Secret を作成または再利用し、次のフラグメントを追加します。

    stringData:
      AZURE_CLIENT_ID: <value-of-clientId>
      AZURE_CLIENT_SECRET: <value-of-clientSecret>
      AZURE_TENANT_ID: <value-of-tenantId>
  5. シークレットを Kubernetes クラスターに適用します。

    kubectl -n <your_namespace> apply -f <azure-secrets>.yaml
  6. value.yaml ファイルが、以前に作成した ConfigMap と Secret を参照していることを確認します。

    upstream:
      backstage:
      ...
        extraAppConfig:
          - filename: ...
            configMapRef: <app-config-containing-azure>
        extraEnvVarsSecrets:
          - <secret-containing-azure>
  7. オプション: Helm チャートがすでにインストールされている場合は、アップグレードします。

    helm -n <your_namespace> upgrade -f <your-values.yaml> <your_deploy_name> redhat-developer/backstage --version 1.2.6
  8. オプション: rhdh.yaml ファイルが変更されていない場合 (たとえば、そこから参照される ConfigMap と Secret のみを更新した場合)、対応する Pod を削除して Developer Hub デプロイメントを更新します。

    kubectl -n <your_namespace> delete pods -l backstage.io/app=backstage-<your-rhdh-cr>

Operator を使用してインストールすると、Microsoft Azure を Red Hat Developer Hub の認証プロバイダーとして使用できます。

詳細は、Operator を使用した OpenShift Container Platform への Red Hat Developer Hub のインストール を参照してください。

手順

  1. アプリケーションが登録されたら、次の点を書き留めます。

    • clientId: アプリケーション (クライアント) ID。App Registration → Overview にあります。
    • clientSecret: シークレット。*App Registration → Certificates & secrets にあります (必要に応じて新規作成します)。
    • tenantId: ディレクトリー (テナント) ID。App Registration → Overview にあります。
  2. 次のフラグメントが Developer Hub ConfigMap に含まれていることを確認します。

    auth:
      environment: production
      providers:
        microsoft:
          production:
            clientId: ${AZURE_CLIENT_ID}
            clientSecret: ${AZURE_CLIENT_SECRET}
            tenantId: ${AZURE_TENANT_ID}
            domainHint: ${AZURE_TENANT_ID}
            additionalScopes:
              - Mail.Send

    新しいファイルを作成することも、既存のファイルに追加することもできます。

  3. ConfigMap を Kubernetes クラスターに適用します。

    kubectl -n <your_namespace> apply -f <app-config>.yaml
  4. Azure 認証情報を含む既存の Secret を作成または再利用し、次のフラグメントを追加します。

    stringData:
      AZURE_CLIENT_ID: <value-of-clientId>
      AZURE_CLIENT_SECRET: <value-of-clientSecret>
      AZURE_TENANT_ID: <value-of-tenantId>
  5. シークレットを Kubernetes クラスターに適用します。

    kubectl -n <your_namespace> apply -f <azure-secrets>.yaml
  6. カスタムリソースマニフェストが、以前に作成した ConfigMap と Secret への参照を含むことを確認します。

    apiVersion: rhdh.redhat.com/v1alpha1
    kind: Backstage
    metadata:
      name: <your-rhdh-cr>
    spec:
      application:
        imagePullSecrets:
        - rhdh-pull-secret
        route:
          enabled: false
        appConfig:
          configMaps:
            - name: <app-config-containing-azure>
        extraEnvs:
          secrets:
            - name: <secret-containing-azure>
  7. カスタムリソースマニフェストを適用します。

    kubectl -n <your_namespace> apply -f rhdh.yaml
  8. オプション: rhdh.yaml ファイルが変更されていない場合 (たとえば、そこから参照される ConfigMap と Secret のみを更新した場合)、対応する Pod を削除して Developer Hub デプロイメントを更新します。

    kubectl -n <your_namespace> delete pods -l backstage.io/app=backstage-<your-rhdh-cr>

第9章 テンプレートの管理

テンプレートは、YAML ファイルで定義されたさまざまな UI フィールドで構成されるフォームです。テンプレートには、actions が含まれます。actions とは、順番に実行され、条件付きで実行できるステップです。

テンプレートを使用すると、Red Hat Developer Hub コンポーネントを簡単に作成し、Red Hat Developer Hub ソフトウェアカタログや、GitHub または GitLab のリポジトリーなどのさまざまな場所にこれらのコンポーネントを公開できます。

9.1. テンプレートエディターを使用したテンプレートの作成

テンプレートエディターを使用して、テンプレートを作成できます。

手順

  1. 以下のオプションのいずれかを使用して、テンプレートエディターにアクセスします。

    テンプレートエディター
    • Red Hat Developer Hub インスタンスの URL https://<rhdh_url>/create/edit 開きます。
    • Red Hat Developer Hub コンソールのナビゲーションメニューで Create…​ をクリックし、オーバーフローメニューボタンをクリックして Template editor を選択します。
  2. Edit Template Form をクリックします。
  3. オプション: テンプレートのパラメーターの YAML 定義を変更します。これらのパラメーターの詳細は、「YAML ファイルとしてのテンプレートの作成」 を参照してください。
  4. Name * に、テンプレート向けに独自の名前を入力します。
  5. Owner ドロップダウンメニューから、テンプレートの所有者を選択します。
  6. Next をクリックします。
  7. Repository Location ビューで、テンプレートを公開するホストされたリポジトリーに関する次の情報を入力します。

    1. ドロップダウンメニューから利用可能な Host を選択します。

      注記

      利用可能なホストは、allowedHosts フィールドで YAML パラメーターで定義されます。

      サンプル YAML

      # ...
              ui:options:
                allowedHosts:
                  - github.com
      # ...

    2. Owner * フィールドに、ホストリポジトリーが属する組織、ユーザーまたはプロジェクトを入力します。
    3. Repository * フィールドに、ホストされているリポジトリーの名前を入力します。
    4. Review をクリックします。
  8. 正確性の情報を確認し、Create をクリックします。

検証

  1. ナビゲーションパネルの Catalog タブをクリックします。
  2. Kind ドロップダウンメニューで、Template を選択します。
  3. テンプレートが既存のテンプレートのリストに表示されていることを確認します。

9.2. YAML ファイルとしてのテンプレートの作成

Template オブジェクトを YAML ファイルとして定義することでテンプレートを作成できます。

Template オブジェクトは、テンプレートとそのメタデータを記述します。また、必要な入力変数と、スキャフォールディングサービスによって実行されるアクションのリストも含まれています。

Template オブジェクトの例

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: template-name 
1

  title: Example template 
2

  description: An example template for v1beta3 scaffolder. 
3

spec:
  owner: backstage/techdocs-core 
4

  type: service 
5

  parameters: 
6

    - title: Fill in some steps
      required:
        - name
      properties:
        name:
          title: Name
          type: string
          description: Unique name of the component
        owner:
          title: Owner
          type: string
          description: Owner of the component
    - title: Choose a location
      required:
        - repoUrl
      properties:
        repoUrl:
          title: Repository Location
          type: string
  steps: 
7

    - id: fetch-base
      name: Fetch Base
      action: fetch:template
      # ...
  output: 
8

    links:
      - title: Repository 
9

        url: ${{ steps['publish'].output.remoteUrl }}
      - title: Open in catalog 
10

        icon: catalog
        entityRef: ${{ steps['register'].output.entityRef }}
# ...

1
テンプレートの名前を指定します。
2
テンプレートのタイトルを指定します。これは、Create…​ ビューのテンプレートタイルに表示されるタイトルです。
3
テンプレートの説明を入力します。これは、Create…​ ビューのテンプレートタイルに表示される説明です。
4
テンプレートの所有権を指定します。owner フィールドは、システムまたは組織内のテンプレートの管理または監視を行うユーザーに関する情報を提供します。上記の例では、owner フィールドは backstage/techdocs-core に設定されています。これは、このテンプレートが backstage namespace の techdocs-core プロジェクトに属していることを意味します。
5
コンポーネントタイプを指定します。この必須フィールドには任意の文字列値を指定できますが、組織でこれらに対して適切な分類を確立する必要があります。Red Hat Developer Hub インスタンスはこのフィールドを読み取り、その値に応じて異なる動作をする場合があります。たとえば、website タイプのコンポーネントは、Web サイト専用のツールを Red Hat Developer Hub インターフェイスに表示する場合があります。

このフィールドに共通する値は次のとおりです。

service
通常 API を公開するバックエンドサービス。
website
Web サイト
library
npm モジュールや Java ライブラリーなどのソフトウェアライブラリー。
6
parameters セクションを使用して、ユーザーが Red Hat Developer Hub コンソールでテンプレートを使用してコンポーネントを作成するときにフォームビューに表示されるユーザー入力のパラメーターを指定します。タイトルとプロパティーによって定義される各 parameters サブセクションにより、その定義を含む新しいフォームページが作成されます。
7
バックエンドで実行されるステップを指定するには、steps セクションを使用します。これらのステップは、一意のステップ ID、名前、およびアクションを使用して定義する必要があります。https://<rhdh_url>/create/actions URL にアクセスすると、Red Hat Developer Hub インスタンスで利用可能なアクションを表示できます。
8
output セクションを使用して、テンプレートの使用時に作成される出力データの構造を指定します。output セクション、特に links サブセクションには、テンプレートから作成されたコンポーネントにアクセスして操作するためにユーザーが利用できる貴重な参照と URL が提供されます。
9
生成されたコンポーネントに関連付けられたリポジトリーへの参照または URL を提供します。
10
さまざまなコンポーネントが表示されているカタログまたはディレクトリーで、生成されたコンポーネントを表示できるようにする参照または URL を提供します。

9.3. 既存のテンプレートを Red Hat Developer Hub にインポートする

カタログプロセッサーを使用して、既存のテンプレートを Red Hat Developer Hub インスタンスに追加できます。

前提条件

  • 少なくとも 1 つのテンプレート YAML ファイルを含むディレクトリーまたはリポジトリーを作成した。
  • GitHub や GitLab などのリポジトリーに保存されているテンプレートを使用する場合は、使用するプロバイダー用の Red Hat Developer Hub 統合を設定した。

手順

  • app-config.yaml 設定ファイルで、catalog.rules セクションを変更してテンプレートのルールを含め、追加するテンプレートを参照するように catalog.locations セクションを設定します (次の例を参照)。

    # ...
    catalog:
      rules:
        - allow: [Template] 
    1
    
      locations:
        - type: url 
    2
    
          target: https://<repository_url>/example-template.yaml 
    3
    
    # ...
    1
    新しいテンプレートをカタログに追加するには、Template ルールを追加する必要があります。
    2
    GitHub や GitLab などのリポジトリーからテンプレートをインポートする場合は、url タイプを使用します。
    3
    テンプレートの URL を指定します。

検証

  1. ナビゲーションパネルの Catalog タブをクリックします。
  2. Kind ドロップダウンメニューで、Template を選択します。
  3. テンプレートが既存のテンプレートのリストに表示されていることを確認します。

第10章 Red Hat Developer Hub での TechDocs プラグインの設定

Red Hat Developer Hub TechDocs プラグインは、組織が一元的な場所で標準化された方法でドキュメントを作成、検索、使用するのに役立ちます。以下に例を示します。

docs-like-code アプローチ
技術ドキュメントを Markdown ファイルに記述し、コードとともにプロジェクトリポジトリー内に保存します。
ドキュメントサイトの生成
MkDocs を使用して、Developer Hub で一元的にレンダリングされるドキュメント用に、フル機能の Markdown ベースの静的 HTML サイトを作成します。
ドキュメントサイトのメタデータと統合
静的ドキュメントに加えて、最終更新日、サイト所有者、トップコントリビューター、未解決の GitHub イシュー、Slack サポートチャネル、Stack Overflow Enterprise タグなど、ドキュメントサイトに関する追加のメタデータを参照できます。
組み込みのナビゲーションおよび検索機能
ドキュメントから必要な情報をより迅速かつ簡単に検索します。
アドオン
より高次のドキュメントのニーズに対応するために、アドオンを使用して TechDocs エクスペリエンスをカスタマイズします。

TechDocs プラグインは、Developer Hub インスタンスにデフォルトでプリインストールされ、有効になっています。Red Hat Developer Hub の Helm チャートまたは Red Hat Developer Hub Operator の config map を設定することで、TechDocs プラグインを無効または有効にしたり、その他のパラメーターを変更したりできます。

重要

Red Hat Developer Hub には、コードベースから静的 HTML ドキュメントを生成する TechDocs ビルダーが組み込まれています。ただし、ローカルビルダーのデフォルトの基本設定は、実稼働環境向けではありません。

TechDocs のドキュメントを生成するための専用のリポジトリーで、CI/CD パイプラインを使用できます。生成された静的ファイルは、OpenShift Data Foundation または選択したクラウドストレージソリューションに保存され、静的 HTML ドキュメントサイトに公開されます。

TechDocs によって生成されるファイルを保存するように OpenShift Data Foundation を設定した後、OpenShift Data Foundation をクラウドストレージとして使用するように TechDocs プラグインを設定できます。

10.1. TechDocs ファイルのストレージの設定

TechDocs のパブリッシャーは、生成されたファイルをローカルストレージまたは OpenShift Data Foundation、Google GCS、AWS S3、Azure Blob Storage などのクラウドストレージに保存します。

10.1.1. ファイルストレージに OpenShift Data Foundation を使用する

OpenShift Data Foundation を設定することで、他のクラウドストレージソリューションを利用することなく、TechDocs によって生成されるファイルを保存できます。

OpenShift Data Foundation は、ObjectBucketClaim カスタムリソース (CR) を備えています。これを使用すると、S3 互換のバケットバックエンドを要求できます。この機能を使用するには、OpenShift Data Foundation Operator をインストールする必要があります。

前提条件

手順

  • 生成された TechDocs ファイルを保存する ObjectBucketClaim CR を作成します。以下に例を示します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <rhdh_bucket_claim_name>
    spec:
      generateBucketName: <rhdh_bucket_claim_name>
      storageClassName: openshift-storage.noobaa.io
    注記

    Developer Hub の ObjectBucketClaim CR を作成すると、Developer Hub ObjectBucketClaim の config map とシークレットの両方が自動的に作成されます。config map とシークレットの名前は ObjetBucketClaim CR と同じです。

ObjectBucketClaim CR を作成したら、config map とシークレットに保存されている情報を使用して、Developer Hub コンテナーからその情報に環境変数としてアクセスできるようにします。Developer Hub のインストールに使用した方法に応じて、Red Hat Developer Hub の Helm チャート設定または Operator 設定にアクセス情報を追加します。

ObjectBucketClaim カスタムリソース (CR) を作成すると、Developer Hub ObjectBucketClaim の config map とシークレットの両方が自動的に作成されます。config map とシークレットには ObjectBucket のアクセス情報が含まれています。Helm チャート設定にアクセス情報を追加すると、次の環境変数がコンテナーに追加され、Developer Hub コンテナーからその情報にアクセスできるようになります。

  • BUCKET_NAME
  • BUCKET_HOST
  • BUCKET_PORT
  • BUCKET_REGION
  • BUCKET_SUBREGION
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

これらの変数は、TechDocs プラグインの設定で使用されます。

前提条件

手順

  • Helm チャート値の upstream.backstage キーに、extraEnvVarsSecrets フィールドと extraEnvVarsCM フィールドの値として、Developer Hub の ObjectBucketClaim シークレットの名前を入力します。以下に例を示します。

    upstream:
      backstage:
        extraEnvVarsSecrets:
          - <rhdh_bucket_claim_name>
        extraEnvVarsCM:
          - <rhdh_bucket_claim_name>
10.1.2.1. Helm チャート用の TechDocs プラグイン設定の例

次の例は、TechDocs プラグイン用の Developer Hub Helm チャート設定を示しています。

global:
  dynamic:
    includes:
      - 'dynamic-plugins.default.yaml'
  plugins:
    - disabled: false
      package: ./dynamic-plugins/dist/backstage-plugin-techdocs-backend-dynamic
      pluginConfig:
        techdocs:
          builder: external
          generator:
            runIn: local
          publisher:
            awsS3:
              bucketName: '${BUCKET_NAME}'
              credentials:
                accessKeyId: '${AWS_ACCESS_KEY_ID}'
                secretAccessKey: '${AWS_SECRET_ACCESS_KEY}'
              endpoint: 'https://${BUCKET_HOST}'
              region: '${BUCKET_REGION}'
              s3ForcePathStyle: true
            type: awsS3

10.1.3. Operator を使用してオブジェクトストレージをコンテナーからアクセス可能にする

ObjectBucketClaim カスタムリソース (CR) を作成すると、Developer Hub ObjectBucketClaim の config map とシークレットの両方が自動的に作成されます。config map とシークレットには ObjectBucket のアクセス情報が含まれています。Operator 設定にアクセス情報を追加すると、次の環境変数がコンテナーに追加され、Developer Hub コンテナーからその情報にアクセスできるようになります。

  • BUCKET_NAME
  • BUCKET_HOST
  • BUCKET_PORT
  • BUCKET_REGION
  • BUCKET_SUBREGION
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

これらの変数は、TechDocs プラグインの設定で使用されます。

前提条件

  • Operator を使用して OpenShift Container Platform に Red Hat Developer Hub をインストールした。
  • TechDocs によって生成されるファイルを保存するための ObjectBucketClaim CR を作成した。

手順

  • Developer Hub Backstage CR で、spec.application.extraEnvs.configMaps フィールドの値として Developer Hub ObjectBucketClaim の config map の名前を入力し、spec.application.extraEnvs.secrets フィールドの値として Developer Hub ObjectBucketClaim のシークレット名を入力します。以下に例を示します。

    apiVersion: objectbucket.io/v1alpha1
    kind: Backstage
    metadata:
     name: <name>
    spec:
      application:
        extraEnvs:
          configMaps:
            - name: <rhdh_bucket_claim_name>
          secrets:
            - name: <rhdh_bucket_claim_name>
10.1.3.1. Operator 用の TechDocs プラグイン設定の例

次の例は、TechDocs プラグイン用の Red Hat Developer Hub Operator の config map 設定を示しています。

kind: ConfigMap
apiVersion: v1
metadata:
  name: dynamic-plugins-rhdh
data:
  dynamic-plugins.yaml: |
    includes:
      - dynamic-plugins.default.yaml
    plugins:
      - disabled: false
        package: ./dynamic-plugins/dist/backstage-plugin-techdocs-backend-dynamic
        pluginConfig:
          techdocs:
            builder: external
            generator:
              runIn: local
            publisher:
              awsS3:
                bucketName: '${BUCKET_NAME}'
                credentials:
                  accessKeyId: '${AWS_ACCESS_KEY_ID}'
                  secretAccessKey: '${AWS_SECRET_ACCESS_KEY}'
                endpoint: 'https://${BUCKET_HOST}'
                region: '${BUCKET_REGION}'
                s3ForcePathStyle: true
              type: awsS3

10.2. TecDocs サイトを生成して公開するための CI/CD の設定

TechDocs は、OpenShift Data Foundation などのクラウドストレージバケットから静的に生成されたドキュメントファイルを読み取ります。ドキュメントサイトは、ドキュメントファイルを含むリポジトリーに関連付けられた CI/CD ワークフローで生成されます。techdocs-cli CLI ツールを使用して、CI でドキュメントを生成し、クラウドストレージに公開できます。

次の例を使用して、TechDocs 公開用のスクリプトを作成できます。

# Prepare
REPOSITORY_URL='https://github.com/org/repo'
git clone $REPOSITORY_URL
cd repo

# Install @techdocs/cli, mkdocs and mkdocs plugins
npm install -g @techdocs/cli
pip install "mkdocs-techdocs-core==1.*"

# Generate
techdocs-cli generate --no-docker

# Publish
techdocs-cli publish --publisher-type awsS3 --storage-name <bucket/container> --entity <Namespace/Kind/Name>

TechDocs ワークフローは、ユーザーがドキュメントファイルを含むリポジトリーに変更を加えたときに CI を開始します。docs/ ディレクトリーまたは mkdocs.yml 内のファイルが変更されたときにのみワークフローを開始するように設定できます。

10.2.1. CI 用のリポジトリーの準備

CI の最初のステップは、作業ディレクトリーにドキュメントソースリポジトリーを複製することです。

手順

  • 作業ディレクトリーにドキュメントソースリポジトリーを複製するには、次のコマンドを入力します。

    git clone <https://path/to/docs-repository/>

10.2.2. TechDocs サイトの生成

手順

技術ドキュメントを生成するように CI/CD を設定するには、次の手順を実行します。

  1. 次のコマンドを使用して、npx パッケージをインストールし、techdocs-cli を実行します。

    npm install -g npx
  2. 次のコマンドを使用して techdocs-cli ツールをインストールします。

    npm install -g @techdocs/cli
  3. 次のコマンドを使用して、mkdocs プラグインをインストールします。

    pip install "mkdocs-techdocs-core==1.*"
  4. 次のコマンドを使用して、TechDocs サイトを生成します。

    npx @techdocs/cli generate --no-docker --source-dir <path_to_repo> --output-dir ./site

    <path_to_repo> は、リポジトリーを複製するために使用したファイルパス内の場所です。

10.2.3. TechDocs サイトの公開

手順

TechDocs サイトを公開するには、次の手順を実行します。

  1. クラウドストレージプロバイダーに必要な認証環境変数を設定します。
  2. 次のコマンドを使用して、技術ドキュメントを公開します。

    npx @techdocs/cli publish --publisher-type <awsS3|googleGcs> --storage-name <bucket/container> --entity <namespace/kind/name> --directory ./site
  3. ソフトウェアテンプレートに .github/workflows/techdocs.yml ファイルを追加します。以下に例を示します。

    name: Publish TechDocs Site
    
    on:
     push:
       branches: [main]
       # You can even set it to run only when TechDocs related files are updated.
       # paths:
       #   - "docs/**"
       #   - "mkdocs.yml"
    
    jobs:
     publish-techdocs-site:
       runs-on: ubuntu-latest
    
       # The following secrets are required in your CI environment for publishing files to AWS S3.
       # e.g. You can use GitHub Organization secrets to set them for all existing and new repositories.
       env:
         TECHDOCS_S3_BUCKET_NAME: ${{ secrets.TECHDOCS_S3_BUCKET_NAME }}
         AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
         AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
         AWS_REGION: ${{ secrets.AWS_REGION }}
         ENTITY_NAMESPACE: 'default'
         ENTITY_KIND: 'Component'
         ENTITY_NAME: 'my-doc-entity'
         # In a Software template, Scaffolder will replace {{cookiecutter.component_id | jsonify}}
         # with the correct entity name. This is same as metadata.name in the entity's catalog-info.yaml
         # ENTITY_NAME: '{{ cookiecutter.component_id | jsonify }}'
    
       steps:
         - name: Checkout code
           uses: actions/checkout@v3
    
         - uses: actions/setup-node@v3
         - uses: actions/setup-python@v4
           with:
             python-version: '3.9'
    
         - name: Install techdocs-cli
           run: sudo npm install -g @techdocs/cli
    
         - name: Install mkdocs and mkdocs plugins
           run: python -m pip install mkdocs-techdocs-core==1.*
    
         - name: Generate docs site
           run: techdocs-cli generate --no-docker --verbose
    
         - name: Publish docs site
           run: techdocs-cli publish --publisher-type awsS3 --storage-name $TECHDOCS_S3_BUCKET_NAME --entity $ENTITY_NAMESPACE/$ENTITY_KIND/$ENTITY_NAME

法律上の通知

Copyright © 2025 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 では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る