Backstageはなぜ製品ではなくフレームワークなのか
一言でいうと
Backstageは、Spotifyが社内で使っていた開発者ポータルを2020年にオープンソースとして公開し、CNCFに寄贈したものです(2022年にインキュベーティング段階へ進みました)。そして、インストールしてすぐ使える製品ではなく、自分たちのポータルを作るためのフレームワークです。この違いを知らずに導入すると、必ず失敗します。
なぜ必要なのか
ある程度の規模になった組織に、次の質問を投げてみると、たいてい答えが出ません。
- うちの会社にサービスはいくつあるか。
- このサービスのオーナーは誰か。午前3時に誰を起こす必要があるか。
- このAPIを誰が使っているか。今なくしたら何が壊れるか。
- 新しく入った開発者が最初のデプロイをするには、何を読む必要があるか。
答えがない理由は、情報がないからではなく、散らばっているからです。オーナーはWikiに、デプロイはCIダッシュボードに、依存関係は誰かの頭の中に、ドキュメントは3年前のConfluenceにあります。それぞれは最新なのに、合わせると何の絵も出てきません。
Backstageの答えは、こうです。ソフトウェアカタログを作り、そのカタログがコードリポジトリから自動的に埋まるようにします。所有権の情報がコードの隣(catalog-info.yaml)にあれば、コードを移すときに一緒に移り、レビューを経て、古いまま残る確率が大きく下がります。
どう動くのか
3本の柱
Backstageをはじめて見るときに知っておくべきことは、3つです。
- ソフトウェアカタログ(Software Catalog): 私たちが持つすべてのものの一覧と、その関係です。Backstageの心臓部です。
- ソフトウェアテンプレート(Software Templates / スキャフォルダー): 新しいサービスをゴールデンパスで作り出す仕組みです。
- TechDocs: コードの隣にあるMarkdownのドキュメントを、ポータルでレンダリングして見せる機能です。
ここにプラグインのエコシステムが加わります。Kubernetes、CI、オンコール、コスト、セキュリティスキャナーなど、各ツールの情報をエンティティページの中へ引き込みます。これがポータルの核心となる価値です。ツールを1つに統合するのではなく、エンティティ(サービス)を中心に情報を集めて見せることです。
フロントエンドプラグインとバックエンドプラグイン
Backstageは、2つのアプリに分かれています。
| フロントエンド | バックエンド | |
|---|---|---|
| 何か | Reactアプリケーション | Node.jsサービス |
| プラグインの役割 | ページ・タブ・カード・アイコンの提供 | APIエンドポイント、データ収集、外部システムの認証 |
| 例 | エンティティページの「Kubernetes」タブ | クラスターに問い合わせてワークロードを取得するサービス |
| なぜ分けるのか | ブラウザーに認証情報を置いてはいけないから | トークンや秘密情報はサーバーにだけ置くため |
この分離は、セキュリティ上重要です。フロントエンドプラグインが直接Kubernetes APIを呼び出すと、ユーザーのブラウザーにクラスターの認証情報が必要になります。そのため、バックエンドプラグインが代わりに呼び出し、フロントエンドはバックエンドのエンドポイントだけを呼び出します。
なぜ製品ではないのか
Backstageを使うには、npx @backstage/create-appで自分たちが所有するアプリのソースツリーを作ります。それ以降は、それが自分たちのコードです。プラグインを追加するには、コードを直し、ビルドして、デプロイします。アップグレードも自分たちの役目です。
この選択の長所と短所は、はっきりしています。
- よい点: 組織に合わせて、何でも変えられます。社内専用のプラグインを作って付けられ、情報の構造を自分たちの組織の言葉で定義できます。
- 悪い点: 保守の担い手が必要です。TypeScript/Reactを扱えるチームが常時付いている必要があり、アップグレードの負担が継続的に発生します。
そのため、CBA試験でも、「Backstageをインストールすれば、すぐ使えるポータルができるか」という類いの問題が出たら、答えはいいえです。導入の決定は、技術の選択ではなく、人員配置の決定です。このフレームワークを製品のように扱うチームがなければ、6か月後に、誰もアップグレードしない放置されたポータルが、また1つ増えます。
現場での姿
著者の7ノードのホームラボを見ただけでも、カタログがなぜ必要なのかがわかります。1つのクラスターの中に、Cilium(CNI)、MetalLB(L4 LB)、Cilium Gateway API(L7)、csi-driver-nfs(ストレージ)、GPU Operator(GPU 4枚)、KubeVirt+CDI(仮想化)、CloudNativePG(DB)、kube-prometheus-stack(オブザーバビリティ)、Gitea(10.0.0.200)、Argo CD(10.0.0.201)、Harbor(10.0.0.202)、Grafana(10.0.0.203)が載っています。それぞれに事情があります。Gateway APIにはCRD v1.6.1が必要で、KubeVirtはcontainerDiskのパスに欠陥があり、DataVolumeによる回避が必要でした。
1人で運用するホームラボでも、この一覧と事情を覚えておかなければ、半年後に迷います。組織なら、言うまでもありません。何があり、なぜそう設定され、誰が知っているのかを人の頭の外に置くこと、それがカタログの存在理由です。
そして、このクラスターで繰り返し得た教訓、つまり状態がReadyであることと実際に動作することは別の命題だという点も、ポータルの設計にそのまま当てはまります。エンティティページに緑のバッジをいくつも表示するのは簡単です。難しいのは、そのバッジが実際のユーザー体験とつながっているかどうかです。ポータルは情報を集めるツールであって、集めたからといって、その情報が真になるわけではありません。
次のクイズで確認すること
このモジュールは、クイズで締めくくります。次のモジュールで、カタログのエンティティの種類と関係を学び、/root/cba-catalog/に実際のcatalog-info.yamlのセットを自分で書きます。Backstage自体はラボ環境にないので、エンティティファイルの作成と、その所有権の情報をクラスターのラベルで表現する方式で扱います。