はじめに
こんにちは。ACS事業部の安藤、青木です。
Platform Engineering KAIGI 2024 の弊社ブースにて、先日リリースしたPlaTTのコンテンツの一つとしてPlaTT Software Templateのデモを展示・紹介させていただきました。
当日は非常に大勢の方に、ブースへお立ち寄りいただき、Software Templateのメリットやユースケースをお話させていただきました。
セッションの合間という短い時間でご覧いただいた方もいらっしゃる中で、多くのご質問やご反応をいただきました。
どんなアーキテクチャなのか気になった方もいらっしゃるかと思いますので、簡単ですが紹介させていただきます。
なお、PlaTTについては以下の記事をご参考ください。
PlaTT Software Templateの紹介
PlaTT Software Templateは、主に以下要素を組み合わせた、いわゆるゴールデンパスを毎月お届けするサブスク形式のサービスです。
- インフラやアプリのコードやそれをデプロイするCI/CDパイプラインを盛り込んだベーステンプレート
- 任意のパラメータでリポジトリに展開する機能
ベーステンプレートのアーキテクチャ構成
今回の Platform Engineering KAIGI 2024 でご紹介した PlaTT Software Template のデモは、これも弊社のサービスコンテンツの一つであるContainer Starter Kitをベースにしています。
システム構成はざっくりと以下のような形です。
実は図を作った時期からいくつかアーキテクチャを変更していたりしますが、全体像は概ね変わっていません。
概要は以下のようになります。
| サービス | 役割 |
|---|---|
| Azure Kubernetes Service (AKS) | Webアプリや周辺サービスとの連携 |
| Azure Container Registry (ACR) | AKSで利用するコンテナイメージをホスト |
| Azure CosmosDB | Webアプリのコンテンツ格納 |
| Azure Key Vault | 証明書やサービス連携等のセキュアな情報格納 |
| Azure Log Analytics | ログ収集とアラート発報 |
Kubernetes
フロント・アプリ
AKSのDeploymentのコンテナとして作っています。
今回アプリはあまりリッチには作らず、PythonのFlaskでWebを提供しつつアプリの機能（と言ってもDBへのCRUDぐらいですが）を持たせました。
よりしっかりとした構成にするなら、フロントとアプリ、BFFなどのコンテナを分割したり、Webをホストするのに前段にAzure Application GatewayやCDNサービスを配置するのが良さそうですね。
また、Webアクセスのエンドポイントを作成するIngressには、AKSの拡張機能である Application Routingの仕組みを利用しています。
Application Routingについてはこちらもご参考ください。
techblog.ap-com.co.jp
シークレット・証明書
シークレット情報は Secrets Store CSI Driver を利用してAzure Key Vaultに格納された情報をPodにマウントさせて環境変数として利用しました。
SecretProviderClass用のマニフェストにはテナントIDやマネージドIDの情報を埋め込むことになるので、汎用性を持たせるためにHelmの形式でインストールさせました。
learn.microsoft.com
Azure構成 (Terraform)
上記の構成をAzureレベルではTerraformで作成しました。
事前に作成していた各リソース向けのTerraformモジュールを持っており、対象のリソースを作成するのに加えて基本的には
- Private Endpointを作成してリソース間はVnet内でアクセス
- Managed IDとRBACを利用して必要なリソースのみアクセス許可
- 診断設定で各種ログを保存
という設定を入れています。
また、Terraformのリモートステートの格納先としてはHCP Terraformを採用しました。
もちろん各クラウドのストレージサービスで代用することも可能です。
GitHub Actions
GitHub Actionsのワークフローは大枠2つに分けており、
AKSのリソースを作成するインフラ用のパイプラインと、アプリのコンテナイメージをデプロイするアプリ用のパイプラインに分かれています。
- インフラ
- tflintや trivy (tfsec) で構文・セキュリティチェック
- Terraform Plan/Apply
- AKSのApp Routingを設定
- アプリ
- Terraform OutputでTerraformで作成されたリソース情報を取得して
$GITHUB_OUTPUTに保持 - ACRのビルドジョブでコンテナイメージをビルドして格納
- AKSにSecret Provider ClassをHelmでインストール
- AKSにアプリをデプロイ
- Terraform OutputでTerraformで作成されたリソース情報を取得して
ライフサイクルがそれぞれ別々なので本来は別のレポジトリに分けてそれぞれ別の担当者がCI/CDをする、という形になることが多いと思いますが、
今回はデモとして1ボタンでインフラからアプリまでデプロイしてしまえるように、 GitHub Actionのworkflow_runトリガーでアプリのパイプラインを動かすようにしました。
また、アプリパイプラインの最初に前段のインフラパイプラインで作成されたリソース情報を取得するためにTerraform initをしてからTerraform Outputを実行していますが、
実際は命名規則等に従ってリソース名を決定できたり、Client IDのようなランダムに付与されるIDは作成後のGitHubのSecretに設定することで省略できるでしょう。
PlaTT Software Template について
では、こちらの章ではPlaTT Software Template について紹介します。
上記に説明のあったコンテナスターターキットをTemplateとして実装し、PlaTT上でCatalog Componentとして払い出すことができるようになっています。
開発者はセルフサービスで簡単に開発環境を用意することができ、さらに日々の開発業務のために必要な情報を一つのポータル画面で確認することができます。 通常であれば必要なインフラ環境、CIパイプラインなどの整備を一から実装するような手間はなく、認知負荷の大きな軽減が期待できます。
Templateの利用から自動デプロイまで
では、実際にこのTemplateを使用した開発環境の用意手順についてみてみましょう。
※こちらに記載の内容はあくまでもデモ版であり、製品版として提供する際は仕様が異なる可能性があります。
また、画像の一部をマスキングしています。
こちらがPlaTTのSoftware Template画面です。
さっそくTemplateを選択します。
次に、TemplateによるCatalog Component作成のために必要な情報を入力していきます。
こちらの画面では、Templateを使用して開発者が環境を払い出す際に必要な固有の情報を入力してもらうようにあらかじめカスタマイズされています。
ここでは、Catalogについての情報や、各種リソースの作成時に必要な認証情報などを入力してもらうように構成されています。
入力が終わったら、[NEXT]をクリックします。
続いて、リソースを払い出すリポジトリの情報を入力する画面が表示されます。
ここでは、リポジトリの種類としてGitHubのリポジトリがデフォルトで選択されており、Organizationと新規に払い出されるリポジトリの名前を入力します。
リポジトリ名は既存のものと被らなければ何でも良いです。入力後、[Review]をクリックします。
こちらが作成前のレビュー画面です。
これまで入力してきた内容に問題がなければ、[CREATE]をクリックして作成を開始します。
作成が開始されると、以下の処理が行われます。
- Templateとして管理しているソースコードをダウンロードし、入力値として受け取った値を反映
- 入力値として受け取った値をもとにGitHubリポジトリを新規作成し、そのリポジトリにソースコードをpushする
- Catalog Componentの新たなエンティティとして、PlaTTに登録する
GitHubリポジトリにソースコードが配置されると、GitHub Actionsにより自動デプロイ処理が開始されます。
自動デプロイ完了後、提供されるドメインにWebブラウザからアクセスすることで、サンプルアプリケーションにアクセスすることができます。
このように、開発者はTemplateを選択し、いくつか必要な情報を入力するだけで開発環境が用意されるということがよくわかると思います。
Templateから払い出した開発環境を見てみよう
それでは、払い出した開発環境がPlaTTからどのように見えるのかを見てみましょう。
[Catalog]をクリックし、先ほど作成したCatalog名を選択します。
こちらが新規に払い出されたのダッシュボード画面です。
TechDocsなどの開発のベストプラクティスをまとめたドキュメントだけではなく、GitHubリポジトリ上のGitHub ActionsワークフローやIssueやPull Requestの情報など、通常GitHub上で管理する開発環境についての様々な情報をポータル上で確認することができます。
以下が、その一例です。
- GitHubリポジトリのIssue一覧
- GitHub Dependabotのアラート状態
- GitHub Deploymentsのデプロイ実行履歴
- GitHub Actionsのワークフロー実行履歴
- GitHubのPull Requestの状態
- GitHub Insights
また、このTemplateで用意される開発環境はKubernetesリソースのステータスを自動的に検知できるように設定されており、AKSクラスタにログインせずにポータル上でKubernetesリソースのステータス確認が可能となっています。
おわりに
いかがでしたか？
最後に改めて、PlaTT Software Templateのポイントをまとめます。
①必要に応じて、簡単に開発環境をデプロイできる
②一つのポータルで開発環境の必要な情報を把握することができる
この記事を通して、PlaTT Software Templateを通じて開発者がどのようにして開発環境を用意し、快適な開発作業を行うことができるかをご理解いただければ幸いです。
最後に、Platform、Platform Teamで利用するサービスPlaTTをご提供しております。
もし、ご興味ありましたら、是非お問い合わせいただけますと幸いです。
また、Azure・AKSなどのクラウドネイティブ技術を活用した内製化のご支援もしております。ご相談等ありましたらぜひご連絡ください。
