この記事は「Opt Technologies Advent Calendar 2017」2日目となります。
はじめに
こんにちは、mshibuyaです。
今回は以前よりあたためていた「変更管理パイプライン」の導入に向け、AWS CodePipeline/CodeBuildを触る機会がありましたので内容をご紹介したいと思います。
変更管理パイプラインとは
オライリー社より出ている「Infrastructure as Code」12章に出てくる概念で、雑にいうとインフラコードのデプロイパイプラインです。
ソースとなるコードリポジトリへコミットされたインフラコードの変更に対し、流れるように
- 自動化されたテスト
- 自動化されたデプロイ
- 変更内容のチェックおよび承認
などを組み合わせ、動作環境への反映までを行うフローをつくることで、本番環境への変更の反映をスムーズに行える仕組みとなります。
これを活用することで、
- 変更のデリバリーの省力化
- 手作業によるインフラ変更の防止（自動化されたパイプラインに乗せる方が楽になれば、皆そうするようになる）
- デプロイ作業の均質化（手作業によるミスの防止）
- トレーサビリティの向上
など、様々なメリットを享受できるようになります。いいですねー
試した内容
ここでは実現可能性の検証ということで、次のようなパイプラインを作成しました。
- GitHubリポジトリの変更を検知
- CodeBuildによりCloudFormation Template JSONを生成
- 得られたTemplate JSONによりCloudFormation Stack更新
はまりどころ
CodePipelineからCloudFormationスタック更新をしようとして、次のようなエラーに遭遇しました
Template exceeds maximum length of 51200 bytes
CloudFormationでは通常テンプレートの上限サイズが51,200bytesとなっており、S3にテンプレートを一度アップロードして渡すことによりその制約を回避し460,800bytesまでのサイズが扱えるのですが、CodePipelineからはS3にアップロードしての渡し方が行えないとのこと。
https://forums.aws.amazon.com/thread.jspa?messageID=785905&tstart=0
これ普通に困りますね…なんとかして欲しいです。上記スレッドで提案されている回避策は「CodeBuildからS3にアップロードしてCloudFormation適用する」みたいな感じで…まぁ、確かにそれで動くでしょうけど。。。
今後
わりとイメージしていた通りのことが出来る見通しは立ったので、次は実際にステージング環境での運用をはじめたいなーと思っております。
進展があったらまたご報告したいです！