目的
IaCをterraformで進めており、AWS protonがterraformを活用した自己管理型プロビジョニング(自前のgithub actionでプロビジョニング)を提供しているので、活用することにした。
proton×terraform×githubaction間の連携がかなり複雑で公式の説明も概要レベルだったので、シーケンス図として整理した。
参考
-
自己管理型プロビジョニングについて
https://aws.amazon.com/jp/blogs/news/aws-proton-self-managed-provisioning/ -
サンプルコード
-
AWSのサービスがHCLで記載されたサンプルコード
https://github.com/aws-samples/aws-proton-terraform-sample-templates -
自己管理型プロビジョニングとして実行するgithub actionのサンプルコード
https://github.com/aws-samples/aws-proton-terraform-github-actions-sample -
構築したAWS環境で動作するサンプルアプリケーションコード
https://github.com/aws-samples/aws-proton-sample-services
-
proton×terraform×githubaction間の連携について(全体図)
- AWS公式で公開されている概要図はこちら
-
詳細化したシーケンス図がこちら
-
protonから操作してテストアプリケーションの稼働が確認できるまでに主に５stepに分かれます。
(以下の数字は上記シーケンス図左端の丸番と一致しています。)
1. protonに環境テンプレートとサービステンプレートを登録
2. 環境テンプレートから環境をプロビジョニング
3. サービステンプレートのうちサービスインスタンスをプロビジョニング
4-前半. サービステンプレートのうちパイプラインをプロビジョニング
4-後半. アプリケーションを最終版に更新 -
環境、サービスをプロビジョニングしたあとのaws-proton-terraform-github-actions-sampleの状態
~/aws-proton-terraform-github-actions-sample ├── env_config.json ├── pipeline #パイプライン構築時に自動作成 │ └── pipeline │ ├── config.tf │ ├── data.tf │ ├── locals.tf │ ├── main.tf ＃ecr、codepipeline、、、 │ ├── outputs.tf │ ├── proton.auto.tfvars.json │ └── proton.pipeline.variables.tf ├── testenv-fargate #環境構築時に自動作成 │ ├── config.tf │ ├── data.tf │ ├── locals.tf │ ├── main.tf ＃VPC │ ├── outputs.tf │ ├── pipeline-test-fargate #サービスインスタンス構築時に自動作成 │ │ ├── config.tf │ │ ├── data.tf │ │ ├── locals.tf │ │ ├── main.tf ＃ECS、ALB │ │ ├── outputs.tf │ │ ├── proton.auto.tfvars.json │ │ └── proton.service_instance.variables.tf │ ├── proton.auto.tfvars.json │ └── proton.environment.variables.tf
事前準備
aws-proton-terraform-github-actions-sampleが機能するためにgithubの認証やS3バケットの構築が必要。
cloudformationで用意されているため、aws-proton-terraform-github-actions-sampleのREADMeを参照。
https://github.com/aws-samples/aws-proton-terraform-github-actions-sample/blob/main/README.md
proton×terraform×githubaction間の連携について(詳細)
1. protonに環境テンプレートとサービステンプレートを登録
- 複数のサービスが含まれるテンプレートリポジトリの場合はディレクトリ名と一致させる必要がある。
- ディレクトリ名に誤りがあるとリポジトリ同期の際にエラーとなる。
- 同期させておくとテンプレートリポジトリを更新した際にproton側でもバージョンアップしてくれる。
2. 環境テンプレートから環境をプロビジョニング
- 環境テンプレートから環境名を指定して作成。
-
環境の詳細の環境名はenv_config.jsonの記載と合わせる必要がある。
https://github.com/aws-samples/aws-proton-terraform-github-actions-sample/blob/main/env_config.json - 環境構築の際に選択するRepository nameはgithub actionが含まれるリポジトリを選択。
- 作成を開始するとaws-proton-terraform-github-actions-sampleに対してaws-connector-for-githubからPRが作成される。
- PRが作成される際、環境テンプレートで登録していたterraformのコードと、
proton.auto.tfvars.json、proton.service_instance.variables.tf、deployment-metadata.jsonが作成される。-
proton.auto.tfvars.json：schemaファイルで定義した入力項目が反映され、teraformの変数に渡される。 -
proton.service_instance.variables.tf：terraformの変数定義。 -
deployment-metadata.json：protonのデプロイバージョンを管理するファイル
-
- デフォルトのgithub actionではPR作成された際は
terraform planまでが実行される。 - PRをmergeすることで
terraform applyが実行され実際の環境が構築される。
3. サービステンプレートのうちサービスインスタンスをプロビジョニング
- サービステンプレートからサービス名を指定して作成。
- サービス作成の際はアプリケーションコードが格納されたリポジトリを選択する。
- サービス名、サービスインスタンス名は本来任意の名称で問題ない。
デフォルトのgithub actionのworkflowファイルの分岐に問題があるようで、サービス名はpipelineにしないと機能しない。ここは後ほど各々でメンテナンスする必要がある。
- サービスインスタンスの構築フローも環境構築時と同様。PR作成時にterraformの変数ファイルが自動作成され、PRが作成される。mergeすることでapplyが実施される。
- protonのサービスとはサービスインスタンスとパイプラインをまとめた名称となっているため、この段階ではパイプラインは構築されずサービスインスタンスのみ作成される。ECSなどもここで構築されるが、nginxのpublicイメージが呼び出されており、welcome画面が表示される状態となる。
- サービスインスタンスの構築が完了すると自動的にproton側からパイプラインの構築がスタートする。
4-前半. サービステンプレートのうちパイプラインをプロビジョニング
- パイプラインの構築も先述と同様PR作成時にterraformの変数ファイルが自動作成され、PRが作成される。
- コードシリーズの構築の場合、コードパイプラインが作成され、予め選択していたアプリケーションリポジトリからソースを同期する。
4-後半. アプリケーションを最終版に更新
- コードシリーズは構築後初回のパイプラインが実行され、コードデプロイの最終処理でprotonのAPIが実行される。そこで具体的なアプリケーションのイメージタグで
proton.service_instance.variables.tfが更新され再度PRが作成される。 - コードデプロイから呼び出されたproton APIはwait処理を実行するためPRがmerge/applyされるまでinprogressとなる。
まとめ
AWS proton×terraformを使った環境構築のフローをまとめました。
記載を省略してしまった箇所もあるため随時更新していきたいと思います。
最終的に、自分が管理する環境ではawsのコードシリーズを使わずにgithub action内で完結できる用にworkflowを作成しました。(proton APIを活用して)
次回はgithub actionで作成したworkflowについて記載します。