Red Hat 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 チャート。
1.1. Helm チャートを使用したカスタムアプリケーション設定ファイルの OpenShift Container Platform への追加 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Developer Hub Helm チャートを使用して、カスタムアプリケーション設定ファイルを OpenShift Container Platform インスタンスに追加できます。
前提条件
- Red Hat OpenShift Container Platform アカウントを作成している。
手順
- OpenShift Container Platform Web コンソールから、ConfigMaps タブを選択します。
- Create ConfigMap をクリックします。
- Create ConfigMap ページで、Configure via の YAML view オプションを選択し、必要に応じてファイルに変更を加えます。
- Create をクリックします。
- Helm リリースのリストを表示するには、Helm タブに移動します。
- 使用する Helm リリースのオーバーフローメニューをクリックし、Upgrade を選択します。
Helm 設定を編集するには、Form view または YAML view のいずれかを使用します。
Form view を使用する場合
- Root Schema → Backstage chart schema → Backstage parameters → Extra app configuration files to inline into command arguments を展開します。
- Add Extra app configuration files to inline into command arguments リンクをクリックします。
以下のフィールドに値を入力します。
-
configMapRef:
app-config-rhdh -
filename:
app-config-rhdh.yaml
-
configMapRef:
- Upgrade をクリックします。
YAML view を使用する場合
以下のように
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- Upgrade をクリックします。
1.2. Operator を使用したカスタムアプリケーション設定ファイルの OpenShift Container Platform への追加 リンクのコピーリンクがクリップボードにコピーされました!
カスタムアプリケーション設定ファイルは、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 を作成している。
手順
- OpenShift Container Platform Web コンソールの Developer パースペクティブから Topology ビューを選択し、Developer Hub Pod の Open URL アイコンをクリックして、Developer Hub の外部 URL <RHDH_URL> を特定します。
- OpenShift Container Platform Web コンソールの Developer パースペクティブから、ConfigMaps ビューを選択します。
- Create ConfigMap をクリックします。
Configure via で YAML 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 - Create をクリックします。
- Secrets ビューを選択します。
- Create Key/value Secret をクリックします。
-
secrets-rhdhという名前のシークレットを作成します。 BACKEND_SECRETという名前のキーと、base64 でエンコードされた文字列を値として追加します。Red Hat Developer Hub インスタンスごとに一意の値を使用します。たとえば、次のコマンドを使用してターミナルからキーを生成できます。node -p 'require("crypto").randomBytes(24).toString("base64")'- Create をクリックします。
- Topology ビューを選択します。
使用する Red Hat Developer Hub インスタンスのオーバーフローメニューをクリックし、Edit Backstage を選択して、Red Hat Developer Hub インスタンスの YAML ビューを読み込みます。
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- Save をクリックします。
- Topology ビューに戻り、Red Hat Developer Hub Pod が起動するまで待ちます。
- Open URL アイコンをクリックして、Red Hat Developer Hub プラットフォームを使用し、設定変更を行います。
関連情報
- Developer Hub におけるロールと責任の詳細は、Red Hat Developer Hub のロールベースのアクセス制御 (RBAC) を参照してください。
第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 権限が必要になる場合があります。
手順
オプション: 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 # ... EOFPostgreSQL インスタンスに接続するための認証情報シークレットを作成します。
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 connection3 NODE_EXTRA_CA_CERTS: <abs-path-to-pem-file> # for TLS connection, e.g. /opt/app-root/src/postgres-crt.pem4 EOF- 1
- 認証情報シークレットの名前を指定します。
- 2
- PostgreSQL インスタンスに接続するための認証情報データを指定します。
- 3
- オプション: 必要な Secure Sockets Layer (SSL) モード に応じて値を指定します。
- 4
- オプション: PostgreSQL インスタンスに TLS 接続が必要な場合にのみ値を指定します。
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: false1 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 # ...注記BackstageCR にリストされている環境変数は、Operator のデフォルト設定を使用します。Operator のデフォルト設定を変更した場合は、それに応じてBackstageCR を再設定する必要があります。-
RHDH インスタンスをデプロイした namespace に
BackstageCR を適用します。
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 権限が必要になる場合があります。
手順
オプション: 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 # ... EOFPostgreSQL インスタンスに接続するための認証情報シークレットを作成します。
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 connection3 NODE_EXTRA_CA_CERTS: <abs-path-to-pem-file> # for TLS connection, e.g. /opt/app-root/src/postgres-crt.pem4 EOF- 1
- 認証情報シークレットの名前を指定します。
- 2
- PostgreSQL インスタンスに接続するための認証情報データを指定します。
- 3
- オプション: 必要な Secure Sockets Layer (SSL) モード に応じて値を指定します。
- 4
- オプション: PostgreSQL インスタンスに TLS 接続が必要な場合にのみ値を指定します。
values.yamlという名前の Helm 設定ファイルで PostgreSQL インスタンスを設定します。# ... upstream: postgresql: enabled: false # disable PostgreSQL instance creation1 auth: existingSecret: <cred-secret> # inject credentials secret to Backstage2 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 Backstage3 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 # ...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_dump と psql、または pgAdmin などの PostgreSQL ユーティリティーを使用できます。
次の手順では、データベースコピースクリプトを使用して迅速な移行を実行します。
前提条件
手順
ターミナルで次のコマンドを実行して、ローカル 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
-
次の
db_copy.shスクリプトのコピーを作成し、設定に応じて詳細を編集します。#!/bin/bash to_host=<db-service-host>1 to_port=54322 to_user=postgres3 from_host=127.0.0.14 from_port=154325 from_user=postgres6 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")。
データをコピーするための宛先データベースを作成します。
/bin/bash TO_PSW=<destination-db-password> /path/to/db_copy.sh1 - 1
<destination-db-password>変数は、宛先データベースに接続するためのパスワードを示します。
注記データのコピーが完了したら、ポート転送を停止できます。大規模データベースの処理と圧縮ツールの使用に関する詳細は、PostgreSQL Web サイトの Handling Large Databases セクションを参照してください。
-
Backstageカスタムリソース (CR) を再設定します。詳細は、Operator を使用した外部 PostgreSQL インスタンスの設定 を参照してください。 再設定後、
BackstageCR の末尾に次のコードが存在することを確認します。# ... 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> # ...注記BackstageCR を再設定すると、対応するStatefulSetおよびPodオブジェクトは削除されますが、PersistenceVolumeClaimオブジェクトは削除されません。ローカルPersistenceVolumeClaimオブジェクトを削除するには、次のコマンドを使用します。oc -n developer-hub delete pvc <local-psql-pvc-name><local-psql-pvc-name>変数は、data-<psql-pod-name>という形式です。- 設定の変更を適用します。
検証
次のコマンドを実行して、RHDH インスタンスが移行したデータを使用して実行されており、ローカルの PostgreSQL データベースが含まれていないことを確認します。
oc get pods -n <your-namespace>出力で次の詳細を確認します。
-
backstage-developer-hub-xxxPod が実行中の状態であること。 backstage-psql-developer-hub-0Pod が利用不可であること。これらの詳細は、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
-
コンポーネントにラベルを付けるための
手順
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: false1 - package: ./dynamic-plugins/dist/backstage-plugin-kubernetes disabled: false2 # ...注記backstage-plugin-kubernetesプラグインは、現在 テクノロジープレビュー機能 です。代わりに、一般提供 (GA) 機能である./dynamic-plugins/dist/backstage-plugin-topology-dynamicプラグインを使用することもできます。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: false2 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 データを渡します。
- 設定変更を保存します。
検証
RHDH アプリケーションを実行してカタログをインポートします。
kubectl -n rhdh-operator get pods -w- Pod ログに設定に関するエラーが表示されていないことを確認します。
- 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 チャートを使用してテレメトリーデータ収集機能を無効にできます。
前提条件
- OpenShift Container Platform Web コンソールに管理者としてログインしている。
- Helm チャートを使用して、OpenShift Container Platform に Red Hat Developer Hub をインストールした。詳細は、Helm チャートを使用した OpenShift Container Platform への Red Hat Developer Hub のインストール セクションを参照してください。
手順
- OpenShift Container Platform Web コンソールの Developer パースペクティブで、Helm ビューに移動して Helm リリースのリストを表示します。
使用する Helm リリースの オーバーフロー メニューをクリックし、Upgrade を選択します。
注記Create ボタンをクリックして新しい Helm リリースを作成し、設定を編集してテレメトリーを無効にすることもできます。
Form ビューか YAML ビューを使用して、Helm 設定を編集します。
Form view を使用する場合
- Root Schema → global → Dynamic plugins configuration. → List of dynamic plugins that should be installed in the backstage application を展開します。
- Add list of dynamic plugins that should be installed in the backstage application リンクをクリックします。
以下のいずれかの手順を実行します。
プラグインを設定していない場合は、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という値があることを確認します。
- Disable the plugin チェックボックスをオンにします。
- Upgrade をクリックします。
YAML view を使用する場合
以下のいずれかの手順を実行します。
プラグインを設定していない場合は、
values.yamlHelm 設定ファイルに次の YAML コードを追加します。# ... global: dynamic: plugins: - package: './dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment' disabled: true # ...-
プラグインを設定済みの場合は、Helm 設定でプラグインを検索し、
plugins.disabledパラメーターの値をtrueに設定します。
- Upgrade をクリックします。
4.1.2. Operator を使用したテレメトリーデータ収集の無効化 リンクのコピーリンクがクリップボードにコピーされました!
Operator を使用してテレメトリーデータ収集機能を無効にできます。
前提条件
- OpenShift Container Platform Web コンソールに管理者としてログインしている。
- Operator を使用して OpenShift Container Platform に Red Hat Developer Hub をインストールした。詳細は、Operator を使用した OpenShift Container Platform への Red Hat Developer Hub のインストール セクションを参照してください。
手順
以下のいずれかの手順を実行します。
-
dynamic-plugins-rhdhConfigMap ファイルを作成し、analytics-provider-segmentプラグインを設定していない場合は、このプラグインをプラグインのリストに追加し、そのplugins.disabledパラメーターをtrueに設定します。 -
dynamic-plugins-rhdhConfigMap ファイルを作成し、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
-
dynamicPluginsConfigMapNameパラメーターの値を、Backstageカスタムリソース内の ConfigMap ファイルの名前に設定します。# ... spec: application: dynamicPluginsConfigMapName: dynamic-plugins-rhdh # ...- 設定変更を保存します。
4.2. RHDH でのテレメトリーデータ収集の有効化 リンクのコピーリンクがクリップボードにコピーされました!
テレメトリーデータ収集機能はデフォルトで有効になっています。ただし、この機能を無効にしていて再度有効にする場合は、Helm チャートまたは Red Hat Developer Hub Operator 設定を使用して analytics-provider-segment プラグインを有効にする必要があります。
4.2.1. Helm チャートを使用したテレメトリーデータ収集の有効化 リンクのコピーリンクがクリップボードにコピーされました!
Helm チャートを使用してテレメトリーデータ収集機能を有効にできます。
前提条件
- OpenShift Container Platform Web コンソールに管理者としてログインしている。
- Helm チャートを使用して、OpenShift Container Platform に Red Hat Developer Hub をインストールした。詳細は、Helm チャートを使用した OpenShift Container Platform への Red Hat Developer Hub のインストール セクションを参照してください。
手順
- OpenShift Container Platform Web コンソールの Developer パースペクティブで、Helm ビューに移動して Helm リリースのリストを表示します。
使用する Helm リリースの オーバーフロー メニューをクリックし、Upgrade を選択します。
注記Create ボタンをクリックして新しい Helm リリースを作成し、設定を編集してテレメトリーを有効にすることもできます。
Form ビューか YAML ビューを使用して、Helm 設定を編集します。
Form view を使用する場合
- Root Schema → global → Dynamic plugins configuration. → List of dynamic plugins that should be installed in the backstage application を展開します。
- Add list of dynamic plugins that should be installed in the backstage application リンクをクリックします。
以下のいずれかの手順を実行します。
プラグインを設定していない場合は、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という値があることを確認します。
- Disable the plugin チェックボックスをオフにします。
- Upgrade をクリックします。
YAML view を使用する場合
以下のいずれかの手順を実行します。
プラグインを設定していない場合は、Helm 設定ファイルに次の YAML コードを追加します。
# ... global: dynamic: plugins: - package: './dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment' disabled: false # ...-
プラグインを設定済みの場合は、Helm 設定でプラグインを検索し、
plugins.disabledパラメーターの値をfalseに設定します。
- Upgrade をクリックします。
4.2.2. Operator を使用したテレメトリーデータ収集の有効化 リンクのコピーリンクがクリップボードにコピーされました!
Operator を使用してテレメトリーデータ収集機能を有効にできます。
前提条件
- OpenShift Container Platform Web コンソールに管理者としてログインしている。
- Operator を使用して OpenShift Container Platform に Red Hat Developer Hub をインストールした。詳細は、Operator を使用した OpenShift Container Platform への Red Hat Developer Hub のインストール セクションを参照してください。
手順
以下のいずれかの手順を実行します。
-
dynamic-plugins-rhdhConfigMap ファイルを作成し、analytics-provider-segmentプラグインを設定していない場合は、このプラグインをプラグインのリストに追加し、そのplugins.disabledパラメーターをfalseに設定します。 -
dynamic-plugins-rhdhConfigMap ファイルを作成し、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
-
dynamicPluginsConfigMapNameパラメーターの値を、Backstageカスタムリソース内の ConfigMap ファイルの名前に設定します。# ... spec: application: dynamicPluginsConfigMapName: dynamic-plugins-rhdh # ...- 設定変更を保存します。
4.3. テレメトリーの Segment ソースのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
analytics-provider-segment プラグインは、収集されたテレメトリーデータをデフォルトで Red Hat に送信します。ただし、要件に応じて、テレメトリーデータを受信する新しい Segment ソースを設定できます。設定には、Segment ソースを参照する一意の Segment 書き込みキーが必要です。
新しい Segment ソースを設定すると、テレメトリーデータ収集 セクションで説明されているものと同じデータセットを収集して分析できます。アプリケーションユーザー向けに独自のテレメトリーデータ収集通知を作成する必要がある場合もあります。
4.3.1. Helm チャートを使用したテレメトリーの Segment ソースのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
Helm チャートを使用して、Segment ソースとの統合を設定できます。
前提条件
- OpenShift Container Platform Web コンソールに管理者としてログインしている。
- Helm チャートを使用して、OpenShift Container Platform に Red Hat Developer Hub をインストールした。詳細は、Helm チャートを使用した OpenShift Container Platform への Red Hat Developer Hub のインストール セクションを参照してください。
手順
- OpenShift Container Platform Web コンソールの Developer パースペクティブで、Helm ビューに移動して Helm リリースのリストを表示します。
- 使用する Helm リリースの オーバーフロー メニューをクリックし、Upgrade を選択します。
Form ビューか YAML ビューを使用して、Helm 設定を編集します。
Form view を使用する場合
- Root Schema → Backstage Chart Schema → Backstage Parameters → Backstage container environment variables を展開します。
- Add Backstage container environment variables リンクをクリックします。
Segment キーの名前と値を入力します。
- Upgrade をクリックします。
YAML view を使用する場合
以下の YAML コードを Helm 設定ファイルに追加します。
# ... upstream: backstage: extraEnvVars: - name: SEGMENT_WRITE_KEY value: <segment_key>1 # ...- 1
<segment_key>は、Segment ソースの一意の識別子に置き換えます。
- Upgrade をクリックします。
4.3.2. Operator を使用したテレメトリーの Segment ソースのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
Operator を使用して、Segment ソースとの統合を設定できます。
前提条件
- OpenShift Container Platform Web コンソールに管理者としてログインしている。
- Operator を使用して OpenShift Container Platform に Red Hat Developer Hub をインストールした。詳細は、Operator を使用した OpenShift Container Platform への Red Hat Developer Hub のインストール セクションを参照してください。
手順
Backstageカスタムリソース (CR) に次の YAML コードを追加します。# ... spec: application: extraEnvs: envs: - name: SEGMENT_WRITE_KEY value: <segment_key>1 # ...- 1
<segment_key>は、Segment ソースの一意の識別子に置き換えます。
- 設定変更を保存します。
第5章 OpenShift Container Platform 上の Red Hat Developer Hub に対する可観測性の有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、メトリクスは /metrics の正規名の下に HTTP サービスエンドポイント経由で公開されます。ServiceMonitor カスタムリソース (CR) を作成して、ユーザー定義プロジェクトのサービスエンドポイントからメトリクスをスクレイピングできます。
5.1. Helm チャートで OpenShift Container Platform クラスターにインストールした場合にメトリクス監視を有効にする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールの Developer パースペクティブから、Red Hat Developer Hub Helm デプロイメントのメトリクスを有効にして表示できます。
前提条件
- OpenShift Container Platform クラスターで、ユーザー定義プロジェクトの監視 が有効になっている。
- Helm チャートを使用して、OpenShift Container Platform に Red Hat Developer Hub をインストールしている。
手順
- OpenShift Container Platform Web コンソールの Developer パースペクティブから、Topology ビューを選択します。
Red Hat Developer Hub Helm チャートのオーバーフローメニューをクリックし、Upgrade を選択します。
Upgrade Helm Release ページで、Configure via の YAML view オプションを選択し、次の例に示すように、YAML で
metricsセクションを設定します。upstream: # ... metrics: serviceMonitor: enabled: true path: /metrics # ...
- Upgrade をクリックします。
検証
- OpenShift Container Platform Web コンソールの Developer パースペクティブから、Observe ビューを選択します。
- Metrics タブをクリックして、Red Hat Developer Hub Pod のメトリクスを表示します。
5.2. Red Hat Developer Hub Operator で OpenShift Container Platform クラスターにインストールした場合にメトリクス監視を有効にする リンクのコピーリンクがクリップボードにコピーされました!
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 を作成するには、次の手順を完了する必要があります。
ServiceMonitorCR を 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'次のコマンドを実行して、
ServiceMonitorCR を適用します。oc apply -f <filename>
検証
- OpenShift Container Platform Web コンソールの Developer パースペクティブから、Observe ビューを選択します。
- 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 アプリケーションがインストールされている。
手順
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'
- 設定変更を保存します。
6.2. Operator デプロイメントでのプロキシー情報の設定 リンクのコピーリンクがクリップボードにコピーされました!
Operator ベースのデプロイメントの場合、プロキシー設定に使用するアプローチはロールによって異なります。
- クラスター管理者は、Operator namespace へのアクセス権を持つため、Operator のデフォルトの ConfigMap ファイルでプロキシー変数を設定できます。この設定は、Operator のすべてのユーザーにプロキシー設定を適用します。
- 開発者は、カスタムリソース (CR) ファイルでプロキシー変数を設定できます。この設定は、その CR から作成された RHDH アプリケーションにプロキシー設定を適用します。
前提条件
- Red Hat Developer Hub アプリケーションがインストールされている。
手順
ロールに応じて、次のいずれかの手順を実行します。
管理者として、プロキシー情報を Operator のデフォルトの ConfigMap ファイルに設定します。
-
デフォルトの namespace
rhdh-operatorでbackstage-default-configという名前の ConfigMap ファイルを検索して開きます。 -
deployment.yamlキーを見つけます。 次の例に示すように、
Deployment仕様でHTTP_PROXY、HTTPS_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'
-
デフォルトの namespace
開発者は、次の例に示すように、カスタムリソース (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'
- 設定変更を保存します。
第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 がサポートするデプロイメント
手順
Operator の管理者として、デフォルト設定を編集して、次のように Prometheus アノテーションを追加します。
# Update OPERATOR_NS accordingly OPERATOR_NS=rhdh-operator kubectl edit configmap backstage-default-config -n "${OPERATOR_NS}"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 ---- 変更を保存します。
検証
スクレイピングが機能するかどうかを確認するには、以下の手順を実行します。
次のように、
kubectlを使用して Prometheus コンソールをローカルマシンにポート転送します。kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090-
Web ブラウザーを開いて
http://localhost:9090に移動し、Prometheus コンソールにアクセスします。 -
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 をセットアップするときは、必ず次の調整を行ってください。
-
Allowed callback URL(s) セクションに、URL
https://<rhdh_url>/api/auth/oidc/handler/frameを含めます。<rhdh_url>は Developer Hub アプリケーションの URL (my.rhdh.example.comなど) に置き換えてください。 -
同様に、Allowed sign-out URL(s) セクションに
https://<rhdh_url>を追加します。<rhdh_url>は Developer Hub アプリケーションの URL (my.rhdh.example.comなど) に置き換えます。 - OAuth 2.0 grant types で、Authorization code grant を選択して認証コードを返します。
OpenID Connect scopes で、少なくとも次のスコープを選択してください。
- OpenID
- Profile
- Helm のデプロイメント
手順
次のようにして、カスタム
app-config-rhdhConfigMap を編集または作成します。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次のテンプレートを使用して、カスタム
secrets-rhdhSecret を編集または作成します。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"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-rhdhHelm デプロイメントをアップグレードします。
helm upgrade rhdh \ openshift-helm-charts/redhat-developer-hub \ [--version 1.2.6] \ --values /path/to/values.yaml
- Operator がサポートするデプロイメント
次のコードを
app-config-rhdhConfigMap に追加します。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: autosecrets-rhdhSecret に次のコードを追加します。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"カスタムリソースに
app-config-rhdhConfigMap とsecrets-rhdhSecret の両方への参照が含まれていることを確認します。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"オプション: カスタムリソースがサポートする既存の Developer Hub インスタンスがあり、それを編集していない場合は、Developer Hub デプロイメントを手動で削除し、Operator を使用して再作成できます。次のコマンドを実行して、Developer Hub デプロイメントを削除します。
kubectl delete deployment -l app.kubernetes.io/instance=<CR_NAME>
-
Allowed callback URL(s) セクションに、URL
検証
- Developer Hub の Web URL に移動し、OIDC 認証を使用してサインインします。これにより、設定した AWS Cognito ユーザープールを介して認証するよう求められます。
- ログインしたら、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 インスタンスからのライブログの表示
- Azure Portal に移動します。
-
リソースグループ
<your-ResourceGroup>を検索し、AKS クラスター<your-Cluster>を見つけます。 - メニューから Kubernetes resources → Workloads を選択します。
-
<your-rhdh-cr>-developer-hubデプロイメント (Helm チャートインストールの場合) または<your-rhdh-cr>-backstageデプロイメント (Operator ベースのインストールの場合) を選択します。 - 左側のメニューで Live Logs をクリックします。
Pod を選択します。
注記Pod は 1 つだけである必要があります。
ライブログデータが収集され、表示されます。
- Container Engine からのリアルタイムログデータの表示
- Azure Portal に移動します。
-
リソースグループ
<your-ResourceGroup>を検索し、AKS クラスター<your-Cluster>を見つけます。 - メニューから Monitoring → Insights を選択します。
- Containers タブに移動します。
- 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 のインストール を参照してください。
- アプリケーションを作成して Azure ポータルに登録した。詳細は、Register an application with the Microsoft identity platform を参照してください。
8.2.1. Helm デプロイメントの認証プロバイダーとして Microsoft Azure を使用する リンクのコピーリンクがクリップボードにコピーされました!
Helm チャートを使用してインストールすると、Microsoft Azure を Red Hat Developer Hub の認証プロバイダーとして使用できます。
詳細は、Helm チャートを使用した AKS への Developer Hub のデプロイ を参照してください。
手順
アプリケーションが登録されたら、次の点を書き留めます。
-
clientId: アプリケーション (クライアント) ID。App Registration → Overview にあります。 -
clientSecret: シークレット。*App Registration → Certificates & secrets にあります (必要に応じて新規作成します)。 -
tenantId: ディレクトリー (テナント) ID。App Registration → Overview にあります。
-
次のフラグメントが 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新しいファイルを作成することも、既存のファイルに追加することもできます。
ConfigMap を Kubernetes クラスターに適用します。
kubectl -n <your_namespace> apply -f <app-config>.yamlAzure 認証情報を含む既存の Secret を作成または再利用し、次のフラグメントを追加します。
stringData: AZURE_CLIENT_ID: <value-of-clientId> AZURE_CLIENT_SECRET: <value-of-clientSecret> AZURE_TENANT_ID: <value-of-tenantId>シークレットを Kubernetes クラスターに適用します。
kubectl -n <your_namespace> apply -f <azure-secrets>.yamlvalue.yamlファイルが、以前に作成した ConfigMap と Secret を参照していることを確認します。upstream: backstage: ... extraAppConfig: - filename: ... configMapRef: <app-config-containing-azure> extraEnvVarsSecrets: - <secret-containing-azure>オプション: Helm チャートがすでにインストールされている場合は、アップグレードします。
helm -n <your_namespace> upgrade -f <your-values.yaml> <your_deploy_name> redhat-developer/backstage --version 1.2.6オプション:
rhdh.yamlファイルが変更されていない場合 (たとえば、そこから参照される ConfigMap と Secret のみを更新した場合)、対応する Pod を削除して Developer Hub デプロイメントを更新します。kubectl -n <your_namespace> delete pods -l backstage.io/app=backstage-<your-rhdh-cr>
8.2.2. Operator がサポートするデプロイメントの認証プロバイダーとして Microsoft Azure を使用する リンクのコピーリンクがクリップボードにコピーされました!
Operator を使用してインストールすると、Microsoft Azure を Red Hat Developer Hub の認証プロバイダーとして使用できます。
詳細は、Operator を使用した OpenShift Container Platform への Red Hat Developer Hub のインストール を参照してください。
手順
アプリケーションが登録されたら、次の点を書き留めます。
-
clientId: アプリケーション (クライアント) ID。App Registration → Overview にあります。 -
clientSecret: シークレット。*App Registration → Certificates & secrets にあります (必要に応じて新規作成します)。 -
tenantId: ディレクトリー (テナント) ID。App Registration → Overview にあります。
-
次のフラグメントが 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新しいファイルを作成することも、既存のファイルに追加することもできます。
ConfigMap を Kubernetes クラスターに適用します。
kubectl -n <your_namespace> apply -f <app-config>.yamlAzure 認証情報を含む既存の Secret を作成または再利用し、次のフラグメントを追加します。
stringData: AZURE_CLIENT_ID: <value-of-clientId> AZURE_CLIENT_SECRET: <value-of-clientSecret> AZURE_TENANT_ID: <value-of-tenantId>シークレットを Kubernetes クラスターに適用します。
kubectl -n <your_namespace> apply -f <azure-secrets>.yamlカスタムリソースマニフェストが、以前に作成した 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>カスタムリソースマニフェストを適用します。
kubectl -n <your_namespace> apply -f rhdh.yamlオプション:
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. テンプレートエディターを使用したテンプレートの作成 リンクのコピーリンクがクリップボードにコピーされました!
テンプレートエディターを使用して、テンプレートを作成できます。
手順
以下のオプションのいずれかを使用して、テンプレートエディターにアクセスします。
-
Red Hat Developer Hub インスタンスの URL
https://<rhdh_url>/create/edit開きます。 - Red Hat Developer Hub コンソールのナビゲーションメニューで Create… をクリックし、オーバーフローメニューボタンをクリックして Template editor を選択します。
-
Red Hat Developer Hub インスタンスの URL
- Edit Template Form をクリックします。
- オプション: テンプレートのパラメーターの YAML 定義を変更します。これらのパラメーターの詳細は、「YAML ファイルとしてのテンプレートの作成」 を参照してください。
- Name * に、テンプレート向けに独自の名前を入力します。
- Owner ドロップダウンメニューから、テンプレートの所有者を選択します。
- Next をクリックします。
Repository Location ビューで、テンプレートを公開するホストされたリポジトリーに関する次の情報を入力します。
ドロップダウンメニューから利用可能な Host を選択します。
注記利用可能なホストは、
allowedHostsフィールドで YAML パラメーターで定義されます。サンプル YAML
# ... ui:options: allowedHosts: - github.com # ...- Owner * フィールドに、ホストリポジトリーが属する組織、ユーザーまたはプロジェクトを入力します。
- Repository * フィールドに、ホストされているリポジトリーの名前を入力します。
- Review をクリックします。
- 正確性の情報を確認し、Create をクリックします。
検証
- ナビゲーションパネルの Catalog タブをクリックします。
- Kind ドロップダウンメニューで、Template を選択します。
- テンプレートが既存のテンプレートのリストに表示されていることを確認します。
9.2. YAML ファイルとしてのテンプレートの作成 リンクのコピーリンクがクリップボードにコピーされました!
Template オブジェクトを YAML ファイルとして定義することでテンプレートを作成できます。
Template オブジェクトは、テンプレートとそのメタデータを記述します。また、必要な入力変数と、スキャフォールディングサービスによって実行されるアクションのリストも含まれています。
Template オブジェクトの例
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: template-name
title: Example template
description: An example template for v1beta3 scaffolder.
spec:
owner: backstage/techdocs-core
type: service
parameters:
- 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:
- id: fetch-base
name: Fetch Base
action: fetch:template
# ...
output:
links:
- title: Repository
url: ${{ steps['publish'].output.remoteUrl }}
- title: Open in catalog
icon: catalog
entityRef: ${{ steps['register'].output.entityRef }}
# ...
- 1
- テンプレートの名前を指定します。
- 2
- テンプレートのタイトルを指定します。これは、Create… ビューのテンプレートタイルに表示されるタイトルです。
- 3
- テンプレートの説明を入力します。これは、Create… ビューのテンプレートタイルに表示される説明です。
- 4
- テンプレートの所有権を指定します。
ownerフィールドは、システムまたは組織内のテンプレートの管理または監視を行うユーザーに関する情報を提供します。上記の例では、ownerフィールドはbackstage/techdocs-coreに設定されています。これは、このテンプレートがbackstagenamespace の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/actionsURL にアクセスすると、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: url2 target: https://<repository_url>/example-template.yaml3 # ...
検証
- ナビゲーションパネルの Catalog タブをクリックします。
- Kind ドロップダウンメニューで、Template を選択します。
- テンプレートが既存のテンプレートのリストに表示されていることを確認します。
第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 をインストールする必要があります。
前提条件
- OpenShift Container Platform 管理者が、Red Hat OpenShift Container Platform に OpenShift Data Foundation Operator をインストールした。詳細は、OpenShift Container Platform - Red Hat OpenShift Data Foundation Operator のインストール を参照してください。
-
OpenShift Container Platform 管理者が、OpenShift Data Foundation クラスターを作成し、
StorageSystemスキーマを設定した。詳細は、OpenShift Container Platform - OpenShift Data Foundation クラスターの作成 を参照してください。
手順
生成された TechDocs ファイルを保存する
ObjectBucketClaimCR を作成します。以下に例を示します。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 の
ObjectBucketClaimCR を作成すると、Developer HubObjectBucketClaimの config map とシークレットの両方が自動的に作成されます。config map とシークレットの名前はObjetBucketClaimCR と同じです。
ObjectBucketClaim CR を作成したら、config map とシークレットに保存されている情報を使用して、Developer Hub コンテナーからその情報に環境変数としてアクセスできるようにします。Developer Hub のインストールに使用した方法に応じて、Red Hat Developer Hub の Helm チャート設定または Operator 設定にアクセス情報を追加します。
10.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 チャートを使用して、OpenShift Container Platform に Red Hat Developer Hub をインストールしている。
-
TechDocs によって生成されるファイルを保存するための
ObjectBucketClaimCR を作成した。詳細は、ファイルストレージに OpenShift Data Foundation を使用する 参照してください。
手順
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 によって生成されるファイルを保存するための
ObjectBucketClaimCR を作成した。
手順
Developer Hub
BackstageCR で、spec.application.extraEnvs.configMapsフィールドの値として Developer HubObjectBucketClaimの config map の名前を入力し、spec.application.extraEnvs.secretsフィールドの値として Developer HubObjectBucketClaimのシークレット名を入力します。以下に例を示します。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 を設定するには、次の手順を実行します。
次のコマンドを使用して、
npxパッケージをインストールし、techdocs-cliを実行します。npm install -g npx次のコマンドを使用して
techdocs-cliツールをインストールします。npm install -g @techdocs/cli次のコマンドを使用して、
mkdocsプラグインをインストールします。pip install "mkdocs-techdocs-core==1.*"次のコマンドを使用して、TechDocs サイトを生成します。
npx @techdocs/cli generate --no-docker --source-dir <path_to_repo> --output-dir ./site<path_to_repo>は、リポジトリーを複製するために使用したファイルパス内の場所です。
10.2.3. TechDocs サイトの公開 リンクのコピーリンクがクリップボードにコピーされました!
手順
TechDocs サイトを公開するには、次の手順を実行します。
- クラウドストレージプロバイダーに必要な認証環境変数を設定します。
次のコマンドを使用して、技術ドキュメントを公開します。
npx @techdocs/cli publish --publisher-type <awsS3|googleGcs> --storage-name <bucket/container> --entity <namespace/kind/name> --directory ./siteソフトウェアテンプレートに
.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