はじめに

2024年1月に、Red Hatは"Red Hat Developer Hub"(以下、RHDH)をリリースしました。
RHDHはBackstageをベースとした開発者ポータルであり、サンプルのGolden Pathや、他のRed Hat製品との連携を強化するプラグイン、ならびにエンタープライズレベルのサポートを提供します。

雰囲気を知りたい人は、英語のセッションですが、YouTubeにデモ動画が上がっていますので一度見てもらうといいかと思います。

ただこういうツールあるあるなのですが、こと使用感やメリットを伝える場合は環境ありきなデモになりがちです。ツールの利用者（RHDHでいうと開発者）からすると「おーすげぇ」と感じる一方で、クラスターの運用者、すなわちPlatform Engineerからすると「で、この環境を作るには何をすればいいの？」と思うはずです。少なくとも私はそう思いました。

なので、ここでPlatform Engineer向けにRHDHを導入してサンプルコードを作成し、Golden PathとしてRHDHに登録するところまでの手順をまとめます。

実現する環境

今回は以下の環境を構成します。

章項目

今回のテーマは6つの記事で構成されています。

Red Hat Developer Hub (Backstage) でGolden Pathを作ろう〜環境導入編〜この記事
Red Hat Developer Hub (Backstage) でGolden Pathを作ろう〜認証設定編〜
Red Hat Developer Hub (Backstage) でGolden Pathを作ろう〜GitHub Integration編〜
Red Hat Developer Hub (Backstage) でGolden Pathを作ろう〜Golden Path作成編①〜
Red Hat Developer Hub (Backstage) でGolden Pathを作ろう〜Golden Path作成編②〜
Red Hat Developer Hub (Backstage) でGolden Pathを作ろう〜Component UI改善編〜

環境導入

本編に入ります。
まず今回の手順を進めるにあたり、以下の環境を前提とします。

前提条件

クラスター環境
- Red Hat OpenShift on AWS(ROSA): 4.14.6
  - Cluster API Endpoint: Public
GitHub
- github.com アカウント1つ
作業端末
- Macbook
  - oc : 4.14.6
    - user-role: cluster-admin
  - vault : v1.14.4
  - helm : v3.13.3

ここではこれらの前提条件を満たすための手順は割愛します。
ちなみにここではROSAを前提としていますが、インターネットに接続可能な環境であればAzure Red Hat OpenShift(ARO)やSelf-ManagedなOpenShiftでも問題ありません。

各種ツールのインストール

まずはGolden Pathで利用予定のツールをインストールしていきます。
インストールするツールと、記事で取り扱うバージョンは以下の通りです。

Via Operator
- OpenShift Pipelines 1.13.1
- OpenShift GitOps 1.11.0
- External Secrets 0.9.11
Via Helm
- Hashicorp Vault 1.15.2
- Sonarqube 9.9.1-community
- Red hat Developer Hub 1.0

Red Hat Developer Hub のインストール

まずは今回のメインツールであるRHDHをインストールします。
2024年1月現在では、公式ドキュメントにてHelmを使ったインストール方法が記載されています。手順上はOpenShiftのWebコンソールから実行していますが、今後の設定変更・管理を考慮してMacbook上からHelmコマンドを実行します。

まずHelmのリポジトリを取得します。

helm repo add openshift-helm-charts https://charts.openshift.io/

次にデフォルトの値を取得します。

helm show values openshift-helm-charts/redhat-developer-hub > values.yaml

ここではインストールに必要な最低限の変更のみ行います。
values.yaml内の以下の部分を修正してください。

values.yaml

# clusterRouteBaseのURLをクラスターのベースドメインに変更
clusterRouterBase: apps.rosa.<cluster_name>.xxxx.xx.openshiftapps.com

# backstageのimageのregistryをquay.ioからregistry.redhat.ioに変更
upstream:
  backstage:
    image:
      registry: registry.redhat.io     ← 変更
      repository: rhdh/rhdh-hub-rhel9

Projectを作成し、実際にデプロイしていきます。

# Project作成
oc new-project rhdh

# install
helm upgrade -i developer-hub -n rhdh -f values.yaml openshift-helm-charts/redhat-developer-hub

しばらくするとPodがrunningになるので、RouteのURLにログインします。

oc get route -n rhdh developer-hub -o jsonpath={.status.ingress[0].host}

ログイン画面が表示されれば、ひとまずインストール完了です。

【Community版 Developer Hub】 Janus のインストール

RHDHは有償のツールのため、すぐには試せない。。。という方は、RHDHのアップストリームであるJanus Projectをご利用下さい。こちらはRed Hatによるサポートは受けられませんが、無償で利用できます。開発が活発に行われているため、同様の手順での操作が実現できない可能性がありますが、それを承知の上でこちらをインストールしても、これからの手順は（おそらく）実行できます。

こちらもHelmのリポジトリの取得からはじまります。

helm repo add janus-idp https://janus-idp.github.io/helm-backstage

次にデフォルトの値を取得します。

helm show values janus-idp/backstage > values.yaml

values.yaml内の以下の部分を修正してください。

values.yaml

# clusterRouteBaseのURLをクラスターのベースドメインに変更
clusterRouterBase: apps.rosa.<cluster_name>.xxxx.xx.openshiftapps.com

# imageのtagをlatestからnext-1e1e1b0に変更
upstream:
  nameOverride: backstage
  backstage:
    image:
      registry: quay.io
      repository: janus-idp/backstage-showcase
      tag: next-1e1e1b0

Projectを作成し、実際にデプロイしていきます。

# Project作成
oc new-project rhdh

# install
helm upgrade -i developer-hub -n rhdh -f values.yaml janus-idp/backstage

しばらくするとPodがrunningになるので、RouteのURLにログインします。

oc get route -n rhdh developer-hub -o jsonpath={.status.ingress[0].host}

ログイン画面が表示されれば、ひとまずインストール完了です。

OpenShift Pipelines のインストール

PipelinesはOperator Hubからインストールしていきます。
Operator Hubで検索バーにopenshift pipelinesと入力して表示されたものを選択します。

インストールを選択します。

全てデフォルトの設定のままインストールを選択します。

OpenShift Pipelinesはこれでインストール完了です。

OpenShift GitOps のインストール

GitOpsもOperator Hubからインストールします。
Operator Hubで検索バーにopenshift gitopsと入力して表示されたものを選択します。

インストールを選択します。

全てデフォルトの設定のままインストールを選択します。

インストールが完了したら、macのターミナルを開き、ocコマンドで以下を実行します。

oc patch argocd openshift-gitops --type=merge -p '{"spec":{"extraConfig":{"application.instanceLabelKey":"argocd.argoproj.io/instance"}}}' -n openshift-gitops

これはArgoCDがリソースを追跡する際に必要とするラベル情報を書き換える設定です。詳細はこちら。
デフォルト設定ではArgoCDからGitOpsでデプロイされたリソースに対してapp.kubernetes.io/instanceのラベルを自動付与することで追跡を実現しますが、この設定により代わりにargocd.argoproj.io/instanceのラベルを投入する挙動になります。なぜこの設定を変えるかは後に分かります。

次に、ArgoCDのServiceAccountに対してcluster-admin権限を付与しておきます。これはGolden Pathの実行時に様々なリソースをデプロイすることが想定されるためです。

oc adm policy add-cluster-role-to-user cluster-admin -z openshift-gitops-argocd-application-controller -n openshift-gitops

最後にArgoCDのRouteに対してTLS終端の設定を行います。ROSAであれば、この設定によってArgoCDへの通信を暗号化できます。

oc -n openshift-gitops patch argocd/openshift-gitops --type=merge -p='{"spec":{"server":{"route":{"enabled":true,"tls":{"insecureEdgeTerminationPolicy":"Redirect","termination":"reencrypt"}}}}}'

OpenShift GitOpsもこれでインストール完了です。

Hashicorp Vaultのインストール

Golden Pathの実行によって環境を払い出すには、GitOpsによる自動化が大前提になります。その際に一番の障壁となるのがSecretの管理です。
GitにSecretのyamlファイルを置くことは一般的に非推奨となっており、各種パブリッククラウドのシークレート管理サービスやVaultのような独自のシークレットストアを利用することが推奨されます。
今回はROSAなのでAWS Secrets Managerを利用しても良かったのですが、一応AROやSelf-managed OpenShiftでも通用するよう、VaultをOpenShiftクラスター上に構築してこちらをシークレットストアとします。

まずVaultをHelmでインストールしていきます。

# Project作成
oc new-project vault

# リポジトリの追加
helm repo add hashicorp https://helm.releases.hashicorp.com

# vaultのインストール
helm upgrade -i -n vault vault hashicorp/vault \
  --set "global.openshift=true" \
  --set "server.dev.enabled=true" \
  --set="injector.enabled=false" \
  --set="server.image.repository=docker.io/hashicorp/vault"

global.openshift=true: OpenShiftにVaultをインストールする際に必要なオプションです。
server.dev.enabled=true: VaultをDevelopment modeで起動します。
injector.enabled=false: Vault Sidecarをインジェクトする機能の利用有無を設定します。今回は利用しないのでfalseにします。
server.image.repository=docker.io/hashicorp/vault: vaultのイメージの取得先を設定します。

次にMac上からインストールしたvaultコンテナにアクセスするための設定を行います。
まずはvaultへのアクセス用のRouteを作成します。

oc expose svc vault

作成したRouteのURLを取得し、環境変数に格納します。

export VAULT_ADDR="http://$(oc get route -n vault vault -o jsonpath={.status.ingress[0].host})"

vault CLIでログインしてみます。インストール直後のrootユーザーのTokenはrootとなっています。

vault login -address=$VAULT_ADDR -method=token token=root

.実行結果

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                root
token_accessor       jTsfDDPkMx5B8Hw0ePkiVyZB
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

これで一応Vaultもインストール完了ですが、今後の利用に向けてもう少し設定を施します。

まず、Vault内のPolicyを作成します。

vault policy write read-only - << EOF
path "secret/*" {
  capabilities = ["read"]
}
EOF

ここではsecret/配下に格納されているsecretへのread権限を持つread-onlyというPolicyを作成しています。

次にKubernetesのService AccountからVaultへアクセスできるように、Kubernetesによる認証をオンにします。

vault auth enable kubernetes

Vault内のRoleを作成します。

vault write auth/kubernetes/role/read-only-role bound_service_account_names=default bound_service_account_namespaces=* policies=read-only ttl=60m

ここではread-only-roleというRoleに対して、先ほど作成したpolicyをアタッチします。また、"全てのNamespaceのdefault service account"にこのRoleを利用できるようにします。

最後にVaultがKubernetesに接続するための設定を行います。このコマンドはVault Podに直接アクセスして実施します。

oc project vault
oc rsh vault-0

vault write auth/kubernetes/config token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt issuer=https://kubernetes.default.svc

以上でVaultのインストールと初期設定は完了です。

External Secretsのインストール

VaultにストアしたSecretを、External Secretsを経由して復号します。このExternal SecretsのカスタムリソースのyamlファイルをGitで管理することで、機密情報をGitにアップすることなくSecretの管理を実現します。

External SecretsのインストールもOperatorで行います。
Operator Hubで検索バーにexternal secretsと入力して表示されたものを選択します。

続行を選択します。

インストールを選択します。

全てデフォルトの設定のままインストールを選択します。

インストールが完了したら、OperatorConfigをデプロイします。
OperatorのタブからOperatorConfigを選択し、OpeartorConfig の作成を選択します。

デフォルトの設定のまま作成を選択します。

次にCluster SecretStoreを作成します。
ここでは設定がいくつか必要のため、yamlファイルを作成してapplyします。

cluster-secretstore.yaml

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-secretstore
  namespace: external-secrets
spec:
  provider:
    vault:
      server: "http://vault.vault.svc:8200"
      version: v2
      namespace: vault
      auth:
        kubernetes:
          mountPath: kubernetes
          serviceAccountRef:
            name: default
          role: read-only-role

複数のNamespaceからExternal SecretsにアクセスできるようにClusterワイドなSecretStoreを作成します。
auth.kubernetes.roleでは先ほどVaultで作成したVault Roleread-only-roleを設定します。

# Project作成
oc new-project external-secrets

# yamlのデプロイ
oc apply -f cluster-secretstore.yaml

Webコンソール上で問題なくCluster SecretStoreがデプロイできているかを確認します。

これでExternal Secretsもインストール完了です。

Sonarqubeのインストール

最後にSonarqubeをインストールします。SonarqubeはGolden PathでデプロイされるCIパイプライン上でアプリケーションコードのUTに使用します。

SonarqubeはHelmでインストールしますが、公式のHelmチャートではOpenShiftのデフォルトのセキュリティ設定の関係でインストールすることができません。そのためGitHubのRed Hat Communities of Practiceにあるhelmチャートを利用します。

# Project作成
oc new-project sonarqube

# リポジトリの追加
helm repo add redhat-cop https://redhat-cop.github.io/helm-charts

# sonarqubeのインストール
helm upgrade --install sonarqube redhat-cop/sonarqube -n sonarqube

しばらくするとリソースがデプロイされるので、RouteのURLを取得してアクセスします。

oc get route -n sonarqube sonarqube -o jsonpath={.status.ingress[0].host}

Sonarqubeのログイン画面が表示されるのでadmin/adminでログインします。

Passwordをアップデートする必要があるので適当に変更します。

Sonarqubeにログインできました。これでいったんSonarqubeのインストールも完了です。

おわりに

これでまずはRHDHのインストールと、Golden Pathの実行に必要なツール群のインストールが完了しました。
次の記事ではGolden Pathの実行に向けてRHDHへさまざまな設定を投入したり、必要な認証情報の取得を行なっていきます。