この記事は Building Developer Portals with Backstage and Amazon EKS Blueprints を翻訳したものです。

現代のソフトウェア開発環境の複雑さにより、近年、内部開発者プラットフォーム（IDP）の作成と採用が進んでいます。IDP の目的は、仕事を遂行するために多数のツールや製品を使用する必要があるソフトウェア開発者の認知負荷を軽減することです。このような断片化は、時間のかかるコンテキストの切り替えを引き起こし、新規参加者の学習曲線を険しくします。IDP は、統一されたフロントエンドを提供することで、このような欠点に対処します。このフロントエンドでは、さまざまなツールや製品が1つのカタログにまとめられ、開発者が利用できるようになっています。

Backstage は Spotify で発足した、2020年3月にオープンソース化されたデベロッパーポータル（DP）です。DP は、IDP の機能を探索し、アクセスするためのユーザーインターフェースの役割を果たします。DP として、Backstage は企業内のさまざまな種類のエンティティを一元管理します： 例えば、API、リソース、ユーザー、チーム、ドキュメントなどです。また、例えば AWS の Proton プラグインのように、追加のサードパーティコンポーネントを同じコンテキストでプラグインして利用できる拡張可能なアーキテクチャも特徴です。Amazon EKS Blueprints for CDK（以後、Amazon EKS Blueprints と呼ぶ）は、Infrastructure as Code（IaC）モジュールのセットで、アカウントやリージョンをまたいで、完全な Amazon Elastic Kubernetes Service（Amazon EKS）クラスタを最小限のコードで迅速にブートストラップするのに役立ちます。当初はAWSで開発され、2022年4月にオープンソース化されました。アドオンは Amazon EKS Blueprint の構成要素で、クラスタのコンテキスト内で実行される Kubernetes アドオンの管理 を支援します。

このブログでは、Amazon EKS Blueprints Patterns の助けを借りて、Amazon EKS Blueprints 用の Backstage アドオンをインストールして設定する方法を紹介します。このアドオンを使用すると、新しくデプロイされた Amazon EKS クラスターに Backstage アプリケーションを効果的にインストールできます。Elastic Load Balancing（Amazon ELB）を介して Backstage にアクセスできるようになります。このブログでは、Amazon EKS Blueprints と Backstage の間の緊密な統合、例えば、環境、パイプラインのステータス、チームのオンボーディングなどを表示および制御することについては触れていません。

ソリューション概要

次の図は、このブログで説明する完全な解決策を示しています：

Backstage のビルド済み Docker イメージが必要で、お好みのプラグインを追加するなどして、お好みの構成にしてください。このステップと次のステップを実行する方法に関する技術的な詳細については、この投稿の後の「Backstage のデプロイ」のセクションを参照してください。

Backstage のパターンはこのようになります：

• このイメージを新しい Amazon EKS クラスタにデプロイします。
• Amazon EKS クラスタの VPC に、新しい Amazon Relational Database Service (Amazon RDS) for PostgreSQL インスタンスを作成します。
• 上記のデータベースの認証情報を AWS Secrets Manager でシークレットとして設定します。
• データベースの認証情報を反映した External Secret を作成します。
• External Secret から Kubernetes Secret を作成し、環境変数 $POSTGRES_USER と $POSTGRES_PASSWORD として Backstage に読み込ませます。
• AWS Load Balancer Controller アドオンをインストールし、Backstage Helm チャートの Ingress に記載されているルールを実装して、Application Load Balancer（ALB）をデプロイします。
• ALB 用の証明書を作成します。

前提条件

この記事のステップを完了するには、以下のものが必要です：

• AWS アカウント
• aws-cli 、aws-cli の設定
• make
• Node.js
• npm
• Docker
• AWS Cloud Development Kit (CDK)、選択したアカウントとリージョンでの bootstrap

また、ここに示す AWS マネジメントコンソールの画像と同様に、Amazon Route 53 のパブリックホストゾーンの1つに保持されるドメイン名が必要です：

Amazon EKS Blueprints Pattern をクローンする

お気に入りのコマンドライン・インターフェース（CLI）を開き、EKS Blueprints Patterns GitHub リポジトリをクローンします：

$ git clone https://github.com/aws-samples/cdk-eks-blueprints-patterns.git

Backstage をデプロイする

EKS Blueprints Patterns リポジトリの docs フォルダにある Backstage ファイルの指示に従ってください。必要な手順は以下の通りです：

1. Backstage アプリケーションを作成し、Docker イメージをビルドします。
2. Amazon Elastic Container Registry（Amazon ECR）とリポジトリの作成します。
3. 新しく作成したリポジトリに Docker イメージをアップロードします。
4. AWS CLI プロファイルの一部としてアカウントとリージョンを設定し、CDK コンテキストに必要なパラメータを入力します：

説明

1.  Amazon EKS Blueprints Patterns ドキュメントの説明に従ってデプロイします。

$ make deps
$ npm i
$ make build
$ make pattern backstage deploy

最後に、ウェブブラウザで{"parent.domain.name"}.{"subdomain.label"}に移動します。Backstage アプリケーションの設定によっては、以下のような画面が表示されます：

コード解析

実際の Backstage アドオンは Amazon EKS Blueprints リポジトリの下でホストされている一方で、アドオンを構成して必要なリソースをデプロイする方法を示す Backstage パターンは Amazon EKS Blueprints Patternsリポジトリの下でホストされていることに注意することが重要です。

このアドオンは、GitHubで公開されている Backstage Helmチャートに依存しています。
その値を通して、Helm チャートを以下のように設定する必要があります：

• Ingress パラメータを設定する
• Backstage アプリケーションの Docker イメージの場所を提供する
• Backstage アプリケーションに渡す：
  • 割り当てるサブドメイン
  • データベース・エンドポイントと環境変数（後にデータベース認証情報に設定される)
  • 実際のデータベース認証情報を保持するシークレット名

Ingress の最も注目すべき構成は、Certificate の Amazon リソース名（ARN）です。

デフォルトのインメモリ SQLite データベースではなく、PostgreSQL を使用することで、より優れたスケーラビリティ、並行性、集中化、制御を実現しています（詳細については Backstage ガイドにアクセスしてください）。この認証情報は、Secret から取得した環境変数を介して Backstage アプリケーション Pod に注入されます。チャートは、Secret名に関する情報をbackstage.extraEnvVarsSecrets値から取得し、Kubernetes Deployment マニフェストのenvFromセクションに設定します：

kind: Deployment
…
containers:
…
          envFrom:
            {{- range .Values.backstage.extraEnvVarsSecrets }}
…

したがって、アドオンが期待するパラメータは以下の通りとなります：

subdomain: string,
certificateResourceName: string,
imageRegistry: string,
imageRepository: string,
imageTag?: string,
databaseResourceName: string,
databaseSecretTargetName: string

このパターンは、アドオンの依存関係を提供します。

Resource Provider (DatabaseInstanceCredentialsProvider) は、AWS Secrets Manager (ASM)にデータベースの認証情報を作成し、保存します。

2番目のリソースプロバイダ(DatabaseInstanceProvider)は、クラスタVPC内にAmazon RDS for PostgreSQLデータベースインスタンスを作成し、コンテキストからASMのシークレット名を取得し、作成時にそれをデータベースに渡します。

External Secrets アドオンを活用するアドオン（BackstageSecretAddOn）は、ASMを指すClusterSecretStoreオブジェクトと、ASM から認証情報を取得するExternalSecretを作成し、POSTGRES_USERとPOSTGRES_PASSWORDをキーとする新しい Kubernetes Secret に注入します：

…
data: [
    {
        secretKey: "POSTGRES_PASSWORD",
        remoteRef: {
            key: databaseInstanceCredentialsSecretName,
            property:  "password"
        }
    },
    {
        secretKey: "POSTGRES_USER",
        remoteRef: {
            key: databaseInstanceCredentialsSecretName,
            property:  "username"
        }
    },
],
…

前回説明したように、Secret 内に保持されている認証情報は、環境変数$POSTGRES_USERと$POSTGRES_PASSWORDとしてポッドに渡されます。

3つ目のResource Provider(CreateCertificateProvider)は、Amazon Route 53 Hosted Zoneにサブドメインを作成し、AWS Certificate Manager(ACM)に関連証明書を作成します：

blueprints.EksBlueprint.builder()

…

.resourceProvider(blueprints.GlobalResources.HostedZone, new blueprints.ImportHostedZoneProvider(props.hostedZoneId, props.parentDomain))

.resourceProvider(props.certificateResourceName, new blueprints.CreateCertificateProvider("elb-certificate", subdomain, blueprints.GlobalResources.HostedZone))

証明書は、コンテキストからBackstageアドオンによって取得され、その ARN が抽出され…

const annotations = {
    …
    "alb.ingress.kubernetes.io/certificate-arn": clusterInfo.getResource<ICertificate>(helmOptions.certificateResourceName)?.certificateArn
};

… と Ingressに割り当てられます：

setPath(values, "ingress.annotations", annotations);

AWS マネジメントコンソール の Route 53 セクションに、このスクリーンショットのように新しいサブドメインレコードが表示されます：

証明書は AWS Certificate Manager セクションに表示されます：

今から何ができるでしょうか？

Backstage は、場所に関係なく組織のリソースを単一の画面で表示できるほか、開発ツールの導入や使用開始を簡単に行うことができます。また、バックエンドやフロントエンド・アプリケーションなどの新しいリソースを、ポータルから簡単に作成することもできます。

Developer Platform のセットアップが完了したら、その利点を活かして Software Catalog の作成から始めましょう。Software Catalog を使用すると、環境内のすべてのソフトウェア（サービス、Web サイト、ライブラリ、パイプラインなど）の所有権とメタデータを一元的に追跡できます。カタログは、ソース・コントロールに保存されたメタデータ YAML ファイルから作成され、Backstage にさまざまな方法で登録され、開発者に包括的なビューで表示されます。

検討したいもう 1 つの機能は、エンジニアリング チームがコンポーネントを構築し、チームのベスト プラクティスに合わせた新しいプロジェクトを迅速に作成できるようにする Software Templates です。これは、エンジニアリングチームがコンポーネントを構築し、チームのベストプラクティスに沿った新しいプロジェクトを迅速に作成することを可能にします。これにより、エンジニアリングチームは、車輪の再発明を避け、意思決定を少なくし、よりコアな活動に集中することができます。Software Templates は Golden Paths の概念の基礎であり、バックエンド サービス、Web アプリケーション、CI/CD パイプラインなどを構築するための Backstage としてのやり方であり、支持される方法です。Golden Paths を使えば、慣習や標準を法的に制定するのではなく、チームが新しいプロジェクトを適切な状態で簡単に始められるようにすることができます。

さらに、TechDocs を使ってドキュメントを作ることもできる。これにより、関連するコードと同じ場所に保存されるMarkdown ファイルを書くことができます。これらのファイルは、Backstage でクリーンかつ明確に表示されます。

Backstage の詳細なドキュメントや機能、ユースケースについては、Backstage のウェブサイトをご覧ください。

後片付け

今後の課金を避けるため、make pattern backstage destroyコマンドを実行してください。

まとめ

この投稿では、Amazon EKS Blueprints の Backstage アドオンと Amazon EKS Blueprints Patterns の Backstage パターンを使用して、ビルド済みで設定済みの Backstage アプリケーションをデプロイする方法を紹介しました。また、依存関係を含む Backstage を実行する完全なソリューションを実現するために、パターンの設定パラメーターと、パターンがリソースプロバイダーや他のアドオンをどのように結び付けるかについて説明しました。