クラウド事業部エンジニアの川勝です。
最近はサーバレスウェブアプリケーション開発をよく触っています。
サーバレスウェブアプリケーションではフロントエンド側はSPAで作成してS3にデプロイすることが多いのですが、今回はそのデプロイフローをAWS CDK+Bitbucket Pipelinesを使用して自動化してみました。
実装した知見をブログで残しておきたいと思います。
目次
はじめに
AWS CDKとは公式のページによると
AWS クラウド開発キット (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化およびプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。
と説明されています。
すごく簡単にいうとAWSにはCloudFormationというプロビジョニングをするためのサービスがありますが、そのCloudFormationのテンプレートを生成して実行してくれるツールです。
ポイントはCloudFormationのテンプレートはjsonまたはyaml形式で記述していたのですが、AWS CDKではプログラムで記述できるようになっています。
条件分岐などが簡単にできるのと、IDE等を使えば入力時に補完してくれるのでドキュメントを調べなくてもある程度予想がつけやすくなりました。
注意点として、AWS CDKは2019/07に一般提供が開始されましたが、githubのreleaseをみてもかなり頻繁にアップデートされています。
https://github.com/aws/aws-cdk/releases
ときには昨日アップデートしたら今日またリリースされてた、、ということもありました。
破壊的変更もまあまああるので今回記載した内容でパラメータやメソッドが変更される可能性は大いにありますのでご注意ください。
またAWS CDKのインストールや基本的なCLIコマンド説明は今回取り上げません。
githubのREADMEや、Developer Guideを参照してください。
目標
react.jsやvue.jsで作成したSPAアプリケーションをgit pushでデプロイしたい。
– AWSリソースへのデプロイはAWS CDK使う
– gitのhookにBitbucket Pipelinesを使う = Bitbucket PipelinesでjsのbuildをしてAWS CDKを実行する
CDK書いてみる
早速ですがCDKのプログラムソースです。
TypeScriptでcdk init して生成された bin/cdk.ts を編集しています。
1#!/usr/bin/env node
2import cdk = require('@aws-cdk/core');
3import { SampleAPPCdkStack } from '../lib/cdk-stack';
4
5// 各種環境変数を取得
6// deployEnvで動的にstackを切り替えるようにしています。
7const awsAccountID = process.env.AWS_ACCOUNT_ID || ''
8const awsRegion = process.env.AWS_DEFAULT_REGION || 'ap-northeast-1'
9const deployEnv = process.env.DEPLOY_ENV || 'staging'
10const suffix = deployEnv !== 'production' ? '-' + deployEnv : ''
11
12const app = new cdk.App();
13// SampleAPPCdkStackというクラスは使いまわして
14// 第2引数を `SampleAPPCdkStack${suffix}` としてsuffixで切り替わるようにしました
15new SampleAPPCdkStack(app, `SampleAPPCdkStack${suffix}`, { env: { account: awsAccountID, region: awsRegion }});
16上記で読み込んでいる実際の実際リソースを生成するクラスです。
lib/cdk-stack.ts を編集しています。
1import cdk = require('@aws-cdk/core');
2import cloudfront = require("@aws-cdk/aws-cloudfront");
3import iam = require('@aws-cdk/aws-iam');
4import s3 = require('@aws-cdk/aws-s3');
5import s3deploy = require('@aws-cdk/aws-s3-deployment');
6
7export class SampleAPPCdkStack extends cdk.Stack {
8
9 readonly deployEnv: string = process.env.DEPLOY_ENV || 'staging'
10 readonly ProjectName: string = process.env.PROJECT_NAME || ''
11 readonly CloudFrontReferer: string = process.env.AWS_CLOUD_FRONT_REFERER || ''
12 readonly CloudFrontCname: string = process.env.AWS_CLOUD_FRONT_CNAME || ''
13 readonly AcmCertArn: string = process.env.AWS_ACM_CERT_ARN || ''
14
15 constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
16 super(scope, id, props);
17
18 const websiteBucket = new s3.Bucket(this, this.ProjectName, {
19 websiteIndexDocument: 'index.html',
20 websiteErrorDocument: 'index.html'
21 });
22
23 new s3deploy.BucketDeployment(this, this.ProjectName + '-artifact', {
24 sources: [s3deploy.Source.asset('../dist')],
25 destinationBucket: websiteBucket
26 });
27
28 const policy = new iam.PolicyStatement({
29 effect: iam.Effect.ALLOW,
30 actions: ['s3:GetObject'],
31 principals: [new iam.Anyone()],
32 resources: [
33 websiteBucket.bucketArn + '/*'
34 ],
35 conditions: {
36 StringLike: { 'aws:Referer': this.CloudFrontReferer }
37 }
38 });
39 websiteBucket.addToResourcePolicy(policy);
40
41 const cloudFrontWebDistributionProps: cloudfront.CloudFrontWebDistributionProps = this.getProps(websiteBucket)
42 const distribution = new cloudfront.CloudFrontWebDistribution(this, this.ProjectName + '-cloudfront', cloudFrontWebDistributionProps);
43
44 new cdk.CfnOutput(this, 'CFTopURL', { value: `https://${distribution.domainName}/` })
45 new cdk.CfnOutput(this, 'URL', { value: `https://${this.CloudFrontCname}/` })
46 }
47
48 private getProps(websiteBucket: s3.Bucket): cloudfront.CloudFrontWebDistributionProps {
49 // CloudFrontの設定
50 return {
51 // 生のCloudFrontDomainだけでいい場合はaliasConfigurationは不要
52 aliasConfiguration: {
53 acmCertRef: this.AcmCertArn,
54 names: [this.CloudFrontCname]
55 },
56 defaultRootObject: '/index.html',
57 viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
58 httpVersion: cloudfront.HttpVersion.HTTP2,
59 // 日本が含まれる安い区分で
60 priceClass: cloudfront.PriceClass.PRICE_CLASS_200,
61 originConfigs: [
62 {
63 // s3のStaticWebhostingDomainを指定します。S3のbucketではない
64 customOriginSource: {
65 domainName: websiteBucket.bucketWebsiteDomainName,
66 originProtocolPolicy: cloudfront.OriginProtocolPolicy.HTTP_ONLY
67 },
68 behaviors: [
69 {
70 isDefaultBehavior: true,
71 compress: true,
72 // とりあえずネガティブキャッシュ。ここは必要に応じてちゃんとしておくのがよい
73 minTtl: cdk.Duration.seconds(0),
74 maxTtl: cdk.Duration.days(0),
75 defaultTtl: cdk.Duration.days(0)
76 }
77 ],
78 // s3に直アクセスできないようにrefererをつけます
79 originHeaders :{
80 Referer: this.CloudFrontReferer
81 }
82 }
83 ],
84 // SPAなのでとりあえず404は/index.htmlへ
85 errorConfigurations: [
86 {
87 errorCode: 404,
88 errorCachingMinTtl: 300,
89 responseCode: 200,
90 responsePagePath: '/index.html'
91 }
92 ]
93 }
94 }
95}ここでのポイントは、調べているとs3 deploymentをとりあえげられている記事は結構ありましたがCloudFrontを使用する場合にOAIの設定をされているパターンが多かったです。
404は/index.htmlにして返しているのでそれでもいいのですが、せっかくs3の静的ウェブホスティングを有効にしているのでそちらを活かせるようにCloudFront Refererを使用した制限を採用してみました。
違いは /hogehoge/index.html が/hogehoge/ でもちゃんとs3のリソースが見つかるようになります。
公式のブログでS3+CloudFrontを採用する場合の手法が取り上げられていますのでこちらも参考にしてください。
”Amazon S3 でホストされている静的ウェブサイトを提供するために CloudFront をどのように使用したらよいですか ?
あといくつか参考にしたサイトを見ているとCloudFrontのパラメータ名が変更になったりしていてちょっとハマったりしました。
ただTypeScriptだとエディタから宣言元とかみて調べるのが容易なので手元で解決できたのはよかったです。
CDK実行時に環境変数を渡す
コードかいて cdk deploy で基本的にOK なのですが、今回は環境変数で動作を変更するようになっていますので実行時に環境変数を渡さなければいけません。
以下を参考にしてrun-cdk.sh というシェルスクリプトにまとめました。
https://docs.aws.amazon.com/cdk/latest/guide/environments.html
1#!/bin/sh
2
3# .envに環境変数は書いていることが多いのでここで読み込んでexport
4. .env
5export PROJECT_NAME=${PROJECT_NAME}
6export DEPLOY_ENV=${DEPLOY_ENV}
7export AWS_ACCOUNT_ID=${AWS_ACCOUNT_ID}
8export AWS_DEPLOY_ROLE=${AWS_DEPLOY_ROLE}
9export AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
10export AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
11export AWS_DEFAULT_REGION=${AWS_DEFAULT_REGION}
12export AWS_CLOUD_FRONT_REFERER=${AWS_CLOUD_FRONT_REFERER}
13export AWS_CLOUD_FRONT_CNAME=${AWS_CLOUD_FRONT_CNAME}
14export AWS_ACM_CERT_ARN=${AWS_ACM_CERT_ARN}
15
16# ci実行時はrole指定と実行確認をしないようにするためのもの
17if [ $@ = "deploy-ci" ]; then
18 cmd="deploy --role-arn ${AWS_DEPLOY_ROLE} --require-approval never"
19else
20 cmd=$@
21fi
22
23echo "running deploy env: ${DEPLOY_ENV}"
24# 毎回yarn install && yarn buildしなくてもいいが、ciでも使用するのでここでまとめて実行
25cd cdk && \
26 yarn install && \
27 yarn build && \
28 yarn cdk ${cmd}もうちょっといい方法はありそうですね..
Bitbucket Pipelines
弊社ではソースコードの管理にBitbucketを使用していますので、CIはBitbucket Pipelinesを使用してみました。
(AWS CodeDeployはBitbucketから使えない…)
bitbucket-pipeline.yml
1image: node:12.16.1-alpine3.11
2
3pipelines:
4 tags:
5 "v*.*.*":
6 - step:
7 name: Build and release for production
8 deployment: production
9 script:
10 - apk add --no-cache make gettext
11 - envsubst < .env.template > .env
12 - yarn install && yarn build
13 - ./run-cdk.sh $@
14
15 "staging/v*.*.*":
16 - step:
17 name: Build and release for staging
18 deployment: staging
19 script:
20 - apk add --no-cache make gettext
21 - envsubst < .env.template > .env
22 - yarn install && yarn build
23 - ./run-cdk.sh $@フロントエンドのSPAはreact.jsとかvue.jsを想定しているのでnode.jsのdocker imageを使用。
git push でbranchに応じて実行することが多いと思いますが、デプロイ目的なのでtagのフォーマットで実行するようにしています。
ちょっとしたREADME.mdの変更だけでデプロイされちゃったりするのを避けたいというのがありました。
環境変数はBitbucket上で設定しておいて envsubst で用意していた.env.template に埋め込みして .env を生成しています。
envsubst便利です。
https://github.com/a8m/envsubst
あとは上記 bitbucket-pipeline.yml をcommitしてtag うってgit push! で自動デプロイされます！
…と思っていましたが最後の壁がありました。
AWS IAM
run-ckd.sh までさかのぼっていただくとデプロイコマンドはこうなっていました。
1cmd="deploy --role-arn ${AWS_DEPLOY_ROLE} --require-approval never"–role-arn, -r ARN of Role to use when invoking CloudFormation [文字列]
はい、こちらはCloudFormationを実行するroleを設定できるオプションになります。
したがって環境変数の AWS_ACCESS_KEY_ID, AWS_ACCESS_KEY_ID に設定しているIAM ユーザーのpolicyには
1{
2 "Version": "2012-10-17",
3 "Statement": [{
4 "Effect": "Allow",
5 "Action": [
6 "iam:GetRole",
7 "iam:PassRole"
8 ],
9 "Resource": "arn:aws:iam::<account-id>:role/sample-app-deploy-role"
10 }]
11}こんな感じでroleにアクセスできる権限があればいいと思っていました…
しかし実際はcdkを実行するには、CloudFormationとs3への権限が必要でした。
CloudFormationは実行する権限がいるのはよく考えたらわかるのですが、cdkではstackのeventの実行状況を表示してくれるので、そのあたりの権限も必要でした。
一個ずつ絞って設定していたらえらくドハマリしてしまうことに…
このあたりどのpolicyが必要なのかのドキュメントが見つからなかったので最終的に cloudformation:* にしてしまいましたが、今後の課題としてそのあたり把握しておきたいところです。
S3の権限に関してはソースコードを一時的に置くBucketにアップロードするのはCloudFormation実行前なので、IAMユーザーに権限が必要でした。
（これもPutObjectだけだとだめでs3:*に…）
今回はIAMユーザに上記policyをつけましたが、IAMユーザには本当にassume roleする権限だけ付与して、cdkを実行するrole、cloudformaitonを実行するroleとわけるとよりセキュアかと思います。
必要な権限がそろえば無事git push して自動デプロイが完成です！
まとめ
ここまで書いておいてなんですが、これくらいのフロントエンドアプリケーションだと AWS Amplify Consoleを使うのがおすすめですw
Bitbucketにも対応しています。
実は以前の以下記事ではそっち使っています。
AWS IoT Core にRaspberry Piから赤外線モーションセンサのログを送る その２ ~ブラウザで会議室の使用状況を確認できるようにする
ただCloudFrontの細かな設定はできないというのと、他のAWSリソース(API Gateway+LambdaでAPI側も作ってるとか)もまとめてデプロイしたいとかだとAWS CDKは使い勝手がいいと思います。
個人的に今の所サーバレスAPIはAWS SAM CLI、フロントエンドはAWS CDK でデプロイしているのですが、将来的にはCDKに統一していきたいなと思いました。（CDKでSAMのテンプレートも生成できたりします。）
また今回はTypeScriptを使用しましたが、他にもPython, C#, JAVAでも書けたり、その他の言語もサポート予定がありそうなので間口が広くていいと思いました。
以上川勝でした。