Red Hat Developer Hub 管理ガイド


Red Hat Developer Hub 1.3

Red Hat Customer Content Services

概要

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

はじめに

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: Red Hat Developer Hub
Copy to Clipboard Toggle word wrap

次のいずれかの方法で、カスタムアプリケーション設定ファイルを 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
        Copy to Clipboard Toggle word wrap
      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: ConfigMap
    apiVersion: v1
    metadata:
      name: app-config-rhdh
    data:
      "app-config-rhdh.yaml": |
        app:
          title: Red Hat Developer Hub
          baseUrl: <RHDH_URL> 
    1
    
        backend:
          auth:
            externalAccess:
                - type: legacy
                  options:
                    subject: legacy-default-config
                    secret: "${BACKEND_SECRET}" 
    2
    
          baseUrl: <RHDH_URL> 
    3
    
          cors:
            origin: <RHDH_URL> 
    4
    Copy to Clipboard Toggle word wrap
    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")'
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    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
    
            # ...
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    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
    
            # ...
    Copy to Clipboard Toggle word wrap
    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.3.5
    Copy to Clipboard Toggle word wrap

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>
    Copy to Clipboard Toggle word wrap

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

    • <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
      Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    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>
    # ...
    Copy to Clipboard Toggle word wrap
    注記

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

    oc -n developer-hub delete pvc <local-psql-pvc-name>
    Copy to Clipboard Toggle word wrap

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

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

検証

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

    oc get pods -n <your-namespace>
    Copy to Clipboard Toggle word wrap
  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 インスタンスを設定できます。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
    #...
    Copy to Clipboard Toggle word wrap

  • サービスアカウントに関連付けられたシークレットとサービス 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
    
            # ...
    Copy to Clipboard Toggle word wrap
    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
    
                # ...
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
  2. Pod ログに設定に関するエラーが表示されていないことを確認します。
  3. Catalog に移動し、Developer Hub インスタンスのコンポーネントページをチェックして、クラスター接続と作成したリソースの存在を確認します。
注記

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

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

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

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

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

4.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>'
    Copy to Clipboard Toggle word wrap

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

    <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'
    Copy to Clipboard Toggle word wrap

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

4.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'
        Copy to Clipboard Toggle word wrap

    • 開発者は、次の例に示すように、カスタムリソース (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'
      Copy to Clipboard Toggle word wrap

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

第5章 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

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

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

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

6.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
      # ...
      Copy to Clipboard Toggle word wrap

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

検証

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

6.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 }}
# ...
Copy to Clipboard Toggle word wrap

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 を提供します。

6.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
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    新しいテンプレートをカタログに追加するには、Template ルールを追加する必要があります。
    2
    GitHub や GitLab などのリポジトリーからテンプレートをインポートする場合は、url タイプを使用します。
    3
    テンプレートの URL を指定します。

検証

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

第7章 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 プラグインを設定できます。

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

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

7.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
    Copy to Clipboard Toggle word wrap
    注記

    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 設定にアクセス情報を追加します。

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

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>
    Copy to Clipboard Toggle word wrap
7.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
Copy to Clipboard Toggle word wrap

7.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>
    Copy to Clipboard Toggle word wrap
7.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
Copy to Clipboard Toggle word wrap

7.2. TechDocs サイトを生成して公開するための 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>
Copy to Clipboard Toggle word wrap

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

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

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

手順

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

    git clone <https://path/to/docs-repository/>
    Copy to Clipboard Toggle word wrap

7.2.2. TechDocs サイトの生成

手順

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

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

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

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

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

    npx @techdocs/cli generate --no-docker --source-dir <path_to_repo> --output-dir ./site
    Copy to Clipboard Toggle word wrap

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

7.2.3. TechDocs サイトの公開

手順

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

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

    npx @techdocs/cli publish --publisher-type <awsS3|googleGcs> --storage-name <bucket/container> --entity <namespace/kind/name> --directory ./site
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

第8章 Red Hat Developer Hub のデプロイメントの設定

Red Hat Developer Hub Operator は、カスタムリソース定義 (CRD) の rhdh.redhat.com/v1alpha2 API バージョンを公開します。この CRD は汎用の spec.deployment.patch フィールドを公開し、Developer Hub デプロイメントリソースを完全に制御できるようにします。このフィールドは、標準の apps.Deployment Kubernetes オブジェクトのフラグメントにすることができます。

手順

  1. 次のフィールドを使用して、Developer Hub カスタムリソース定義を作成します。

apiVersion: rhdh.redhat.com/v1alpha2
kind: Backstage
metadata:
  name: developer-hub
spec:
  deployment:
    patch:
      spec:
        template:
Copy to Clipboard Toggle word wrap

labels

Developer Hub Pod にラベルを追加します。

ラベル my=true を追加する例

apiVersion: rhdh.redhat.com/v1alpha2
kind: Backstage
metadata:
  name: developer-hub
spec:
  deployment:
    patch:
      spec:
        template:
          metadata:
            labels:
              my: true
Copy to Clipboard Toggle word wrap

volumes

my-volume という名前のボリュームを追加し、Developer Hub アプリケーションコンテナーの /my/path の下にマウントします。

追加ボリュームの例

apiVersion: rhdh.redhat.com/v1alpha2
kind: Backstage
metadata:
  name: developer-hub
spec:
  deployment:
    patch:
      spec:
        template:
          spec:
            containers:
              - name: backstage-backend
                volumeMounts:
                  - mountPath: /my/path
                    name: my-volume
            volumes:
              - ephemeral:
                  volumeClaimTemplate:
                    spec:
                      storageClassName: "special"
                name: my-volume
Copy to Clipboard Toggle word wrap

デフォルトの dynamic-plugins-root ボリュームを、dynamic-plugins-root という名前の永続ボリューム要求 (PVC) に置き換えます。$patch: replace ディレクティブに注意してください。そうしないと、新しいボリュームが追加されます。

dynamic-plugins-root ボリュームの置換例

apiVersion: rhdh.redhat.com/v1alpha2
kind: Backstage
metadata:
  name: developer-hub
spec:
  deployment:
    patch:
      spec:
        template:
          spec:
            volumes:
              - $patch: replace
                name: dynamic-plugins-root
                persistentVolumeClaim:
                  claimName: dynamic-plugins-root
Copy to Clipboard Toggle word wrap

CPU リクエスト

Developer Hub アプリケーションコンテナーの CPU リクエストを 250m に設定します。

CPU リクエストの例

apiVersion: rhdh.redhat.com/v1alpha2
kind: Backstage
metadata:
  name: developer-hub
spec:
  deployment:
    patch:
      spec:
        template:
          spec:
            containers:
              - name: backstage-backend
                resources:
                  requests:
                    cpu: 250m
Copy to Clipboard Toggle word wrap

my-sidecar コンテナー

Developer Hub Pod に新しい my-sidecar サイドカーコンテナーを追加します。

サイドカーコンテナーの例

apiVersion: rhdh.redhat.com/v1alpha2
kind: Backstage
metadata:
  name: developer-hub
spec:
  deployment:
    patch:
      spec:
        template:
          spec:
            containers:
              - name: my-sidecar
                image: quay.io/my-org/my-sidecar:latest
Copy to Clipboard Toggle word wrap

法律上の通知

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 をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

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

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る