はじめに
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
- Red Hat OpenShift on AWS(ROSA): 4.14.6
- GitHub
- github.com アカウント1つ
- 作業端末
- Macbook
- oc : 4.14.6
- user-role: cluster-admin
- vault : v1.14.4
- helm : v3.13.3
- oc : 4.14.6
- Macbook
ここではこれらの前提条件を満たすための手順は割愛します。
ちなみにここでは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
内の以下の部分を修正してください。
# 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
内の以下の部分を修正してください。
# 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します。
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へさまざまな設定を投入したり、必要な認証情報の取得を行なっていきます。