AWSにおけるパイプラインのベストプラクティスパターン整理
はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧はこちら。
この記事ではAWSにおけるパイプラインのベストプラクティスパターンを整理しています。
具体的には以下2点をまとめた上で、AWSにおけるパイプラインのベストプラクティスパターンを整理します。
- AWSにおけるCI/CDのテクノロジースタック
- プロビジョニング有無、デプロイ有無ごとの使用サービス整理
AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。
この記事を読んでほしい人
- AWSでCI/CDの実現方法を網羅的に整理したい人
- これからAWSでCI/CDを実装したいのでパターンごとにパイプラインのベストプラクティスをおさえたい人
- AWS Certified DevOps Engineer Professionalを目指している人
AWSにおけるCI/CDのテクノロジースタック
まずは、AWSにおけるCI/CDのテクノロジースタックを整理して、これから紹介する技術の全体像を抑えましょう。
全体像を整理すると以下になります。
さらに詳細を見たい方は別記事にまとめたのでこちらをご覧ください。
プロビジョニング有無、デプロイ有無ごとの使用サービス整理
AWSでCI/CDを実現する際にはプロビジョニング有無とデプロイ有無によって組み合わせるサービスが異なります。
そこで、一目でわかるまとめを作成しましたのでご覧ください。
それぞれのパターンで何が必要かの詳細は以下に整理します。
アプリケーションのデプロイがある場合
アプリケーションのデプロイがある場合にはリポジトリとしてのCodeCommit、ビルドのためのCodeBuildとデプロイのためのCodeDeploy、オーケストレーションのためのCodePipelineが必要です。
リソースのプロビジョニングもある場合にはこれに加えて、次に説明するリソース群が必要になります。
リソースのプロビジョニングがある場合
必ず必要なのはリポジトリとしてのCodeCommit、オーケストレーションのためのCodePipeline、リソースをコード化するためのCloudFormationです。
なお、ここではIaaSだけではなくPaaSやSaaSなども含めてCloudFormationで定義されるAWSリソースの構築が必要な場合をプロビジョニングがある場合と定義します。
また、上記以外のリソースが必要かどうかはプロビジョニングリソースがEC2か否かによって変わります。
プロビジョニングリソースがEC2の場合
EC2をプロビジョニングする場合にはCodeCommit、CodePipeline、CloudFormatioinに加えてAMIを作成するためのEC2 Image Builderが必要になります。
プロビジョニングリソースがEC2以外の場合
EC2と異なりAMIが無いぶん、EC2 Image Builderは不要で追加のリソースは不要です。
AWSにおけるパイプラインのベストプラクティスパターン
大前提として、デプロイとプロビジョニングのパイプラインは分けることをおすすめします。
やろうと思えば、パイプラインを長く続けてプロビジョニングにした後にデプロイすることは可能です。
しかし、たいていの場合はプロビジョニングが必要な頻度とデプロイが必要な頻度は一致しません。
例えば、アプリケーションを更新するたびにCloudFormationで定義したLambdaのパラメータを変更したりすることはあまり多くありません。
そのため、デプロイとプロビジョニングは別のパイプラインとすることが推奨です。
例外として、テストのたびに環境を構築して削除する運用をしている場合は一本のパイプラインでプロビジョニング、デプロイ、テスト、環境削除を行ってもよいと思います。
デプロイのベストプラクティスパターン
EC2へのデプロイ
EC2へのデプロイの場合、CodeCommitへのソースコードプッシュを契機にCodeBuildがアプリケーションのビルドとテストを実施、変更内容を承認してデプロイするという流れをCodePipelineがオーケストレーションするというシンプルな流れです。
ここに書いたのはアプリケーションのデプロイのみの場合です。
AMIを更新する場合のパターンはEC2のプロビジョニングに記載します。
ECSへのデプロイ
ECSへのデプロイの場合、CodeCommitへのソースコードプッシュを契機にCodeBuildがDockerイメージの作成とテスト、ECS Taskとappspec.ymlの作成を実施します。その後、変更内容を承認してデプロイするという流れをCodePipelineがオーケストレーションするという流れになります。
デプロイする際にはトラフィックの切り替えをいくつかのパターンで制御できますが詳細はCodePipelineの記事で別途まとめます。
Lambdaへのデプロイ
Lambdaへのデプロイの場合、CodeCommitへのソースコードプッシュを契機にCodeBuildが新しいLambda関数の作成とテスト、appspec.ymlの作成を実施します。その後、変更内容を承認してデプロイするという流れをCodePipelineがオーケストレーションするという流れになります。
ECS同様、デプロイする際にはトラフィックの切り替えをいくつかのパターンで制御できますが詳細はCodePipelineの記事で別途まとめます。
プロビジョニングのベストプラクティスパターン
EC2のプロビジョニング
EC2のプロビジョニングはアプリケーションのビルド後にAMIをビルドする必要があるので登場するサービスが少し多くなります。
ここではCloudFormationとCodePipelineの統合を利用してAutoScaling内のEC2をローリングアップデートする図にしています。
EC2以外のプロビジョニング
EC2以外のプロビジョニングはCloudFormationを実行するだけなのでシンプルです。
プロビジョニングパイプラインのベストプラクティスは以下に図示した通りCloudFormationのChange Setを作成し、作成されたChange Setを確認、承認して、実行するという流れです。
まとめ
今回は以下2点をまとめた上で、AWSにおけるパイプラインのベストプラクティスパターンを整理しました。
- AWSにおけるCI/CDのテクノロジースタック
- プロビジョニング有無、デプロイ有無ごとの使用サービス整理
次回からはテクノロジースタックで紹介した各サービスの詳細を解説していきます。
Discussion