トップ > OpenShift > 【Developer Hub 実践｜第5回】Software Templateを使ってアプリのデプロイをセルフサービス化しよう

【Developer Hub 実践｜第5回】Software Templateを使ってアプリのデプロイをセルフサービス化しよう

OpenShift Red Hat Developer Hub Developer Hub 実践 Backstage

こんにちは、Red HatでOpenShift関連のプリセールスをしている北村です。

これまでの記事では、Developer Hubのインストールから、GitHubやGitLabとの認証連携、さらにComponentの登録方法について解説してきました。

今回はDeveloper Hub(Backstage)が提供するSoftware Template機能を使って、簡単なHello WorldアプリケーションをセルフサービスでOpenShiftにデプロイするまでの流れをご紹介します。

Software Templateとは？

Software Template は、Backstageの Scaffolder 機能を通じて実装される仕組みで、Gitリポジトリの生成やアプリケーションのデプロイをセルフサービス化するための機能です。以下のような活用シーンがあります。

  • 新規アプリケーションの立ち上げ：テンプレート化された Skeleton Repository やディレクトリ構成を自動生成して、プロジェクトごとの初期設定にかかる時間を削減する
  • チーム標準の構成適用：Linterやテストの設定など、組織として共通化したい設定をテンプレートに含めておくことで、属人化を防止する
  • DevOpsツールチェーンとの連携：CI/CD、デプロイ、監視など、社内既定のパイプライン設定を自動で組み込む

Scaffolder はこのSoftware Templateを実行し、指定された手順どおりに「コード生成 → パラメータ置換 → GitリポジトリへのPush → デプロイ」などを行う“仕掛け”のことを指します。

また、テンプレートの定義自体は、template.yaml に記述し、Developer Hubに登録します。

Skeleton Repositoryとは？

Skeleton Repositoryとは、テンプレートのベースとなるソースコードを格納しているリポジトリを指します。 例えば、今回のように簡単なHello Worldアプリをデプロイするテンプレートでは、最低限のKubernetes/OpenShiftマニフェストやcatalog-info.yamlなどが入ったリポジトリが「Skeleton」となります。

ディレクトリ構成例

.
├── manifests
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── route.yaml
│   ├── ...
│   └── kustomization.yaml
├── catalog-info.yaml
└── README.md

Software Template機能では、このSkeleton Repoをテンプレート実行時に取得し、ユーザーが入力したアプリ名やGitHubリポジトリ名などのパラメータを差し替えることで、独自のリポジトリを生成する仕組みを提供します。

Scaffolderとは？

Scaffolder は、Developer Hub (Backstage) におけるジョブエンジンのような存在で、template.yamlに記述した様々な自動化のステップ を順番に実行します。

Scaffolderのステップで実行可能なジョブには例として以下のようなものが存在します。

  • fetch:template: Skeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入する
  • publish:github: fetch:templateで作成したソースコードをユーザー指定の新しいGitHubリポジトリにPushする
  • argocd:create-resources: 所定のGitリポジトリ及びBranchにおけるK8sマニフェストをデプロイするためのArgoCD Application CRをK8sにデプロイする
  • catalog:register: Gitリポジトリ内のcatalog-info.yamlをDeveloper Hubに登録する

Template実行手順

とりあえず概念を書いてみましたが、おそらく全然イメージが沸かないと思うので、実際にTemplateを作成・実行していきましょう。

今回実現すること

今回は以下のような仕組みを作っていきます。

  1. 利用者はDeveloper Hubの画面で必要なパラメータを入力してTemplateを実行する
  2. fetch:template StepでSkeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入する
  3. publish:github Stepで新しいGitHubリポジトリにPushする
  4. argocd:create-resources StepでHello worldアプリ用のK8sマニフェストをデプロイするためのApplication CRを作成する
  5. Application CRが新しいGitHubリポジトリ上のK8sマニフェストを検知してアプリをデプロイする

なお今回デプロイするHello worldアプリは、あらかじめQuay.ioに準備されているコンテナイメージを使います。

ArgoCDを準備する

Template作成の前に、ArgoCDそのものをOpenShift上にデプロイしていきます。

といってもデフォルトの設定のままOperatorをインストールするだけです。

Operator Hubから"OpenShift GitOps"と検索して、"Red Hat OpenShift GitOps"を選択します。特に設定も変えずにインストールしましょう。

正常にインストールできると、OperatorとともにArgoCDの本体となるCRがopenshift-gitopsというNamespaceにデプロイされます。

このArgoCDにログインするためのadminユーザーのパスワードがopenshift-gitops-clusterというSecretに格納されているので、こちらの値を保存しておきます。このログイン情報は後ほどDeveloper Hubの設定に使用します。

次にArgoCDにアクセスするためのRouteのURLを確認します。こちらも後ほどDeveloper Hubの設定に使用するので保存しておきましょう。

実際にURLにアクセスして、adminユーザーでログインします。

ログイン後、開発者ツール（ChromeだとF12）を開いて、画面更新を行い一番上のリクエスト内にあるargocd.token=ey...から始まるcookieの値を取得します。

あるいは以下のコマンドで該当の値を取得できます。

curl -sk -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"<adminのパスワード>"}' \
  https://openshift-gitops-server-openshift-gitops.apps.rosa.<domain>/api/v1/session \
| grep 'argocd.token' \
| sed 's/^set-cookie: \(argocd\.token=[^;]*\).*/\1/'

最後に、ArgoCDのサービスアカウントに対してさまざまなリソースをデプロイするための権限を付与します。今回はcluster-adminを付与しておきます。

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

これでArgoCDの準備と、Developer Hubとの連携に必要な情報の取得が完了しました。

Developer HubとArgoCDを連携する

次にDeveloper HubとArgoCDを連携して、ScaffolderによってApplication CRを実行するための準備を行います。ついでにArgoCDに関する画面をDeveloper Hubに表示するための準備も行います。

Dynamic Pluginをインストールする

Developer Hubとの連携といえばPluginです。ArgoCDとの連携に必要な各種Pluginをインストールするためにdynamic-plugins-rhdh.yamlを修正します。

Dynamic Pluginもだんだん増えてきたので、少し整形しました。

dynamic-plugins-rhdh.yaml

kind: ConfigMap
apiVersion: v1
metadata:
  name: dynamic-plugins-rhdh
  namespace: rhdh
  annotations:
    rhdh.redhat.com/backstage-name: developer-hub
data:
  dynamic-plugins.yaml: |
    includes:
      - 'dynamic-plugins.default.yaml'
    plugins:
    # GitHub Plugins
      - package: ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic
        disabled: false
      - package: ./dynamic-plugins/dist/backstage-plugin-scaffolder-backend-module-github-dynamic
        disabled: false
    # Kubernetes Plugins
      - package: ./dynamic-plugins/dist/backstage-plugin-kubernetes-backend-dynamic
        disabled: false
      - package: ./dynamic-plugins/dist/backstage-plugin-kubernetes
        disabled: false
    # OpenShift Plugins
      - package: ./dynamic-plugins/dist/backstage-community-plugin-topology
        disabled: false
    # ArgoCD Plugins
      - package: ./dynamic-plugins/dist/roadiehq-backstage-plugin-argo-cd-backend-dynamic
        disabled: false
      - package: ./dynamic-plugins/dist/backstage-community-plugin-redhat-argocd
        disabled: false
      - package: ./dynamic-plugins/dist/roadiehq-scaffolder-backend-argocd-dynamic
        disabled: false

今回インストールするPluginは以下の4つです。

  • backstage-plugin-scaffolder-backend-module-github-dynamic: GitHubへのScaffolder機能を提供する
  • roadiehq-backstage-plugin-argo-cd-backend-dynamic: ArgoCDとのBackend連携を実現する
  • backstage-community-plugin-redhat-argocd: ArgoCDに関するユーザー用画面を提供する
  • roadiehq-scaffolder-backend-argocd-dynamic: ArgoCDへのScaffolder機能を提供する

app-configを変更する

app-config-rhdh.yaml に以下のような設定を追記します。

app-config-rhdh.yaml

kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
  namespace: rhdh
  annotations:
    rhdh.redhat.com/backstage-name: developer-hub
data:
  app-config-rhdh.yaml: |
    app:
    ...omit...
    backend:
    ...omit...
    auth:
    ...omit...
    integrations:
    ...omit...
    signInPage: github
    catalog:
    ...omit...
    enabled:
      kubernetes: true
      argocd: true       # ここを追記
    kubernetes:
    ...omit...
    # ここから下を追記
    argocd:
      appLocatorMethods:
      - instances:
        - name: main
          password: ${ARGOCD_PASSWORD}
          url: ${ARGOCD_INSTANCE_URL}
          username: ${ARGOCD_USERNAME}
        type: config
    proxy:
      '/argocd/api':
        target: ${ARGOCD_INSTANCE_URL}/api/v1/
        changeOrigin: true
        secure: false
        headers:
          Cookie:
            $env: ${ARGOCD_AUTH_TOKEN}

argocdセクションでは、連携するArgoCDの情報を記述します。見てもらうとわかるように、ArgoCDのURL、ユーザー、パスワードが必要になります。

proxyセクションとは、Developer Hubが外部サービス（ここではArgo CDのAPI）へアクセスするときのプロキシ設定を行う場所です。今回では、Argo CDのREST APIやgRPCエンドポイントに安全にリクエストを飛ばすために利用され、Cookie情報やArgoCDのAPI URLが求められます。

Secretを設定する

最後に、ArgoCD pluginの設定をapp-configに追記したので、必要な変数をSecretに設定していきます。

secrets-rhdh.yaml

apiVersion: v1
kind: Secret
metadata:
  name: secrets-rhdh
  namespace: rhdh
stringData:
  ...omit...
  ARGOCD_INSTANCE_URL: "https://<ArgoCDのURL>"
  ARGOCD_USERNAME: "admin"
  ARGOCD_PASSWORD: "<ArgoCDのadminユーザーのパスワード>"
  ARGOCD_AUTH_TOKEN: "argocd.token=ey....."

3つのファイルの反映

変更した3つのファイルをデプロイします。

oc apply -f app-config-rhdh.yaml -f secrets-rhdh.yaml -f dynamic-plugins-rhdh.yaml

これでArgoCDとの連携設定が完了しました。これでScaffolderの実行とArgoCD関連の画面生成ができるはずです。

Software Tempale機能を実行する

では今回の本題に入りましょう。実際にSoftware Template機能を使ってみます。

template.yamlとSkeleton Repositoryを準備

まずはtemplate.yamlとSkeleton Repositoryを準備します。おさらいですが、今回は以下のステップを実行します。

  1. 利用者はDeveloper Hubの画面で必要なパラメータを入力してTemplateを実行する
  2. fetch:template StepでSkeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入する
  3. publish:github Stepで新しいGitHubリポジトリにPushする
  4. argocd:create-resources StepでHello worldアプリ用のK8sマニフェストをデプロイするためのApplication CRを作成する
  5. Application CRが新しいGitHubリポジトリ上のK8sマニフェストを検知してアプリをデプロイする

ファイルがいくつか必要なので、今回はこちらのリポジトリにソースコードを公開しました。まずはこちらから自身の環境にForkしてください。

Fork後、template.yamlのspec.ownerの部分だけ書き換えてください。

template.yaml

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: helloworld
  title: Hello world app
  description: シンプルなHelloWorldアプリをデプロイするためのテンプレート

  tags:
    - recommended
spec:
  owner: user:default/skitamura7446  #ここを自分のDeveloper Hubユーザー名に書き換えてください。
  type: website

このリポジトリのディレクトリ構成は以下のようになっています。

.
├── README.md
├── manifest-skeleton
│   ├── argocd
│   │   └── application.yaml
│   ├── catalog-info.yaml
│   └── manifests
│       ├── deployment.yaml
│       ├── kustomization.yaml
│       ├── route.yaml
│       └── service.yaml
└── template.yaml
  • manifest-skeleton: このディレクトリ配下がSkeleton Repositoryとしてfetch:template Stepでコピーされます。
  • argocd: Developer Hubから実行するArgoCDのApplication CR が格納されています。
  • catalog-info.yaml: このテンプレート実行によって登録するComponent情報が記載されています。
  • manifests: Hello worldアプリをデプロイするためのK8sマニフェストが格納されています。ArgoCD Applicationはこのディレクトリ配下をデプロイしにいきます。
  • template.yaml: 今回のテンプレートです。

テンプレートをDeveloper Hubに登録する

template.yamlやSkeleton Repositoryの中身を見ていく前に、まず一旦このtemplate.yamlをDeveloper Hubに登録していきましょう。

前回の記事で画面上から手動で登録する手順を紹介しましたが、今回はapp-config-rhdh.yamlにこのファイルの読み込み設定を行い、自動でこのテンプレートを登録する状態にしてみます。

以下の部分を追記してみましょう。

app-config-rhdh.yaml

kind: ConfigMap
apiVersion: v1
metadata:
  name: app-config-rhdh
  namespace: rhdh
  annotations:
    rhdh.redhat.com/backstage-name: developer-hub
data:
  app-config-rhdh.yaml: |
    app:
    ...omit...
    backend:
    ...omit...
    auth:
    ...omit...
    integrations:
    ...omit...
    signInPage: github
    catalog:
      providers:
      ...omit...
      # ここから下を追記
      locations:
      - type: url
        target:  https://github.com/<GitHub Organization名>/helloworld-skeleton/blob/main/template.yaml # 先ほど作成→Pushしたtempalte.yamlを指定
        schedule:
            frequency: PT60S
            initialDelay: PT30S
            timeout: PT120S
      # ここまで

これを適用します。

oc apply -f app-config-rhdh.yaml

しばらくするとDeveloper Hubが立ち上がり、テンプレートが登録されていることを確認できます。

テンプレートを実行する

このままテンプレートの実行までしていきましょう。画面とtemplate.yamlを見比べながら理解を深めていきます。

この画面に表示されている情報は、template.yamlの以下の部分です。

template.yaml(抜粋)

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: helloworld
  title: Hello world app
  description: シンプルなHelloWorldアプリをデプロイするためのテンプレート
  tags:
    - recommended
spec:
  owner: user:default/<Developer Hubにログイン中のユーザー名>
  type: website
  • metadata.name: このテンプレートの名前です。画面には反映されませんが、URLのPathとして使われます。
  • metadata.title: このテンプレートのタイトルです。画面ではこちらがテンプレート名になります。
  • metadata.description: このテンプレートの説明です。こちらも画面で確認できます。
  • metadata.tags: このテンプレートを検索する際に活用できるキーワードを設定します。
  • spec.owner: このテンプレートの管理者の名前です。
  • type: このテンプレートの属性を定義できます。

次に"Choose"を選択して中身とtemplate.yamlを見比べてみましょう。

最初の画面は以下の通りです。

この画面を構成しているのはtemplate.yamlの以下の部分です。

template.yaml(抜粋)

  parameters:
    - title: 作成するComponentの情報
      required:
        - app_name
        - owner
      properties:
        app_name:
          title: アプリケーション名
          description: 作成するアプリ名を指定してください。
          type: string
          default: "helloworld"
        owner:
          title: オーナー
          type: string
          description: 作成するComponentのオーナーを選択してください。
          ui:field: OwnerPicker
          ui:options:
            catalogFilter:
              kind:
                - Group
                - User
  • title: Stepごとの入力画面のタイトルになります。
  • required: この入力画面で必須項目となるパラメータkeyを指定します。
  • properties.xxx : properties配下に入力項目を並べていきます。xxxの部分がパラメータkeyになります。
  • xxx.title: 画面に表示するパラメータ名です。
  • xxx.type: パラメータの型を定義します。
  • xxx.description: このパラメータの説明です。こちらは画面に表示されるため、パラメータの補足として利用します。
  • xxx.default: このパラメータのデフォルト値です。

上記までが一般的な記述内容になります。一方で、例えばすでにDeveloper Hubに登録済みのパラメータ(GroupやUser、Systemなど)を参照してプルダウン形式で選択させたい場合は、ui:field:とui:options:を活用します。

  • xxx.ui:field: EntityPicker OwnerPicker RepoUrlPickerの3種類から選択できます。それぞれパラメータの属性に応じて適切なものを選択します。詳細はこちらを参照下さい。
  • xxx.ui:field.OwnerPicker.catalogFilter : ここでプルダウンで表示させる値をフィルタリングしています。ownerの場合はDeveloper Hub内に登録してあるGroupとUserがここに表示されることになります。

次の画面は以下になります。

この画面を構成しているのはtemplate.yamlの以下の部分です。

template.yaml(抜粋)

    - title: GitHubリポジトリの情報
      required:
        - git_repo_name
        - git_host_url
        - git_owner_name
      properties:
        git_repo_name:
          title: GitHubリポジトリ名
          description: 生成するGitHubリポジトリ名を入力してください。
          type: string
          default: helloworld
        git_host_url:
          title: GitHub URL
          description: GitHubリポジトリのURLを入力してください。
          type: string
          default: github.com
        git_owner_name:
          title: GitHub Organization名
          description: GitHubリポジトリを生成するGitHub Organization名を入力してください。
          type: string
          default: rhdh-practice

ここは画面とyamlファイルの中身がある程度リンクしていることがわかります。

入力する値は自身の環境に合わせて適宜修正してください。（githubのURLやOrganization名など）

では実際に実行してみましょう。

実行すると画面のように各Stepが実行されます。

"Componentを開く"を選択すると、無事にComponentも登録されていることがわかります。

また、Links の App Repository を選択すると、テンプレート実行によって新規作成されたGitリポジトリにアクセスすることができます。

template.yamlとSkeleton Repositoryを読み解く

では、画面入力後から実行まで、なにが起こったのかを確認していきましょう。

template.yamlの中身をもう少し見てみると、以下のようにstepsから始まる記述があります。

template.yaml(抜粋)

  steps:
    - id: fetch
      name: Fetch skeleton
      action: fetch:template
      input:
        url: ./manifest-skeleton
        values:
          app_name: ${{ parameters.app_name }}
          owner: ${{ parameters.owner }}
          git_repo_name: ${{ parameters.git_repo_name }}
          git_host_url: ${{ parameters.git_host_url }}
          git_owner_name: ${{ parameters.git_owner_name }}
        targetPath: ./tenant

stepsでは、テンプレートの実行部分を記述します。このstepsはリスト形式で各処理を記述していき、その順番通りに実行されていきます。その実行される内容を指定しているのがactionになります。

たとえば、今回のテンプレートでは最初にfetch:templateというactionを実行します。 このfetch:templateでは、先述した通りSkeleton Repoからソースコードを取得し、ユーザーが入力したパラメータを代入します。

上記のコードを見てみると、app_name: ${{ parameters.app_name }}というように、parametersでユーザーから入力された値を変数に格納していることがわかります。今回では、app_nameやgit_repo_nameといった変数に対して、Developer Hubの画面で入力された値を代入していることになります。

ではこの格納された変数はどのようにskeletonファイルに反映されるのでしょうか？ ここでmanifest-skeleton/manifests配下にあるdeployment.yamlを見てみましょう。

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ${{ values.app_name }}
  name: ${{ values.app_name }}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ${{ values.app_name }}
  template:
    metadata:
      labels:
        app: ${{ values.app_name }}
    spec:
      containers:
      - image: quay.io/skitamur/hello-world:latest
        name: ${{ values.app_name }}
        ports:
        - containerPort: 3000
          protocol: TCP

これは、Hello worldアプリをPodとしてデプロイするためのdeploymentのyamlファイルです。

例えばこれのmetadata.nameを見てみましょう。値が${{ values.app_name }}となっています。このように、fetch:templateで渡された変数の値は、${{ values.app_name }}のように記述されたところに代入されていきます。

今回で言うと、Developer HubのTemplate実行画面の"アプリケーション名"に入力した値がdeployment.yamlのmetadata.nameに反映されることになります。

イメージとしては以下になります。

そのほかのパラメータについては以下のとおりです。

  • input.url: 取得するテンプレートの相対パスになります。このtemplate.yamlはhelloworld-skeletonリポジトリ直下にあるため、そこからの相対パスとして./manifest-skeletonを指定しています。
  • input.values: この値が変数に代入するパラメータになります。
  • input.targetPath: これはローカル（Developer Hun Pod内）のワークスペースを指定します。ディレクトリがなければ/tmp配下に作成されます。今回はtenantディレクトリにmanifest-skeleton配下のファイル群を一時的に格納します。

次のstepでは、変数を代入したファイル群を新しいGitリポジトリとしてPushするactionを実行しています。

template.yaml(抜粋)

    - id: publish
      name: Push to GitHub
      action: publish:github
      input:
        repoUrl: ${{ parameters.git_host_url }}?owner=${{ parameters.git_owner_name }}&repo=${{ parameters.git_repo_name }}
        repoVisibility: public
        sourcePath: ./tenant
        defaultBranch: develop
        protectDefaultBranch: false
  • input.repoUrl: Pushする先のGitHubのURLです。これでPushできるOrganizationは以前の記事で連携設定を行ったOrganizationに限られます。
  • input.repoVisibility: GitHubのリポジトリの公開設定です。PublicかPrivateを設定できます。
  • input.sourcePath: GitHubにPushするデータが格納されているパスを指定します。ここでは前のfetch:template actionでskeletonから取得＆変数代入を行った./tenantを指定します。
  • input.defaultBranch: Pushする際のデフォルトのBranchになります。今回はdevelopをデフォルトのブランチとしています。
  • input.protectDefaultBranch: GitHubはデフォルトブランチが保護されています。今回はfalseにしています。

イメージは以下の通りです。

その次はargoCDのApplication CRをデプロイするActionです。

template.yaml(抜粋)

    - id: argocd
      name: Deploy with ArgoCD
      action: argocd:create-resources
      input:
        appName: ${{ parameters.app_name }}-init
        argoInstance: main
        namespace: openshift-gitops
        repoUrl: https://${{ parameters.git_host_url }}/${{ parameters.git_owner_name }}/${{ parameters.git_repo_name }}.git
        path: 'argocd/'
  • input.appName: このactionによってデプロイするArgoCDのApplication名です。
  • input.argoInstance: これはapp-configで設定したArgoCD instanceのNameを記述します。今回はmainとなります。
  • input.namespace: Applicationのデプロイ先のNamespaceです。
  • input.repoUrl: GitOpsの参照先となるGitのURLです。
  • input.path: GitのURLにおけるサブディレクトリを指定します。

ここを読み解くと、新しく作成(Push)されたリポジトリのargocdディレクトリ配下のK8sマニフェストをターゲットとしてGitOpsが行われることが分かります。

ここで鋭い人は、「なんで直接manifests配下のK8sマニフェストを対象にしないの？」と思うかもしれません。

実際はそれでも動く時はありますが、このDeveloper Hubから実行可能なargocd:create-resources actionでは、作成されるApplication CRの設定がかなり制限されます。Application名やターゲットパス以外のパラメータはほぼ変更できず、全てデフォルト値でデプロイされてしまいます。

そこで、「Application CRからApplication CRをデプロイする」という手法を使うことで、アプリ自体のGitOpsをする際の設定を細かく行えるようにしています。この階層構造でのデプロイを一般的に"App of apps pattern"と言います。なお、細かい設定の例として、例えばCreateNamespace=trueやAutoSyncなどがあります。

ともあれこれによってアプリの自動デプロイまでが完了しました。

最後は、作成されたGitリポジトリ配下にあるcatalog-info.yamlをDeveloper Hubに登録するactionです。

template.yaml(抜粋)

    - id: register
      name: Register Catalog into Developer Hub
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps['publish'].output.repoContentsUrl }}
        catalogInfoPath: "/catalog-info.yaml"

このcatalog:registerでは、repoContentsUrlとcatalogInfoPathで指定されたファイルをDeveloper Hubに登録します。

catalog-info.yamlは前回の記事の内容も参考にしながら、以下のような内容になっています。

catalog-info.yaml

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name:  ${{ values.app_name }}
  description: Hello Worldサービスです
  labels:
    app: ${{ values.app_name }}
  links:
    - url: https://${{ values.git_host_url }}/${{ values.git_owner_name }}/${{ values.git_repo_name }}
      title: App Repository
      icon: github
  annotations:
    backstage.io/kubernetes-label-selector: 'app=${{ values.app_name }}'
    backstage.io/kubernetes-namespace: ${{ values.app_name }}
    argocd/app-selector: app.kubernetes.io/instance=${{ values.app_name }}-init
spec:
  type: website
  owner: ${{ values.owner }}
  lifecycle: production

一点新たにannotationsにargocd/app-selector: app.kubernetes.io/instance=${{ values.app_name }}-initを追加しています。これを記載することで、app.kubernetes.io/instance=${{ values.app_name }}-initのlabelを持つArgoCDのApplication情報をこのComponentに表示できるようになります。

Component画面を確認する

最後に今回作成されたアプリのComponent画面を確認してみましょう。

Topologyタブに移動すると、実際にPodが稼働していることが確認できます。

アイコン右上の"Open URL"にアクセスして、Hello world!が表示されることを確認しましょう。

また、新たに増えたCDタブに移動してみると、今回デプロイされたArgoCDの情報が確認できます。リンクを選択することでArgoCDの画面にも遷移できます。

おわりに

今回はSoftware Template機能の基本的な概念と、template.yamlやSkeleton Repositoryの記述方法、そして実行方法について解説しました。

次回はTechdocs機能について触れていきます。乞うご期待！

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。