#43 AWSでのCI/CD Codeなんちゃら系のサービスまとめ [後編]
Date
2021-04-28 21:39
Show Notes
AWS上でCI/CDを行うサービスを整理。後編。
前回のおさらい
前回の配信ではAWS上のCI/CD系サービスとして主にCodeCommit, CodeBuild周りを話した。
今回はCodeDeploy, CodePipelineあたりを中心に。
CodeDeploy
AWSにおけるCDの肝（とは言えないかも。対応サービスが限られるので限定的）となるサービス。
- フルマネージドなデプロイ自動化サービス
- デプロイ先としてEC2, オンプレミス, Lambda, ECSを選択可能
- Pull型のデプロイ
- Push型はデプロイする人がデプロイ先のサーバを把握する必要がある
- デプロイ自動化にはPull型が推奨される
- 様々なデプロイ方法を選択可能
- In-Place
- Blue/Green Deploy
- Canary Deploy
- Linear, All-at-once
- エラー時のロールバックも可能
- デプロイ設定を
appspec.yamlに記載してデプロイするパッケージ内に入れたりリポジトリに配置したり- ミドルウェアのインストールなどの前後処理
- 当該アプリケーションのデプロイ方法（EC2なら所定の場所にファイルを配置したり）
- CodeDeploy Agentというものをインストールすればオンプレミスへのデプロイも可能
- EC2, Lambda, ECSへのデプロイには課金なし
- オンプレミスは1つのインスタンスあたり$0.02。
CodePipeline
ここまでのCI/CD一連の流れをパイプラインとしてつなげて自動化する。
リリースプロセスをワークフローとして定義する。
- Approvalステージを挟むことでContinuous Deliveryに対応
- 複数のApprvalアクションを用意して、承認者のIAMポリシーを分けて付与することで承認者を複数設定することも可能。
（参考: CodePipeline で複数名の承認を必要とするパイプラインの実装方法）
- 複数のApprvalアクションを用意して、承認者のIAMポリシーを分けて付与することで承認者を複数設定することも可能。
- CodeBuild, CodeDeployなどだけではなく様々なプロバイダと連携が可能
- CloudFormation, AppConfigなどその他のAWSサービス
- GitHub, Jenkinsなどサードパーティ
- Lambda, StepFunctionsと連携するCustomアクション
- Build, Deployを並列で実行することも可能
- 通知機能はSNS経由
- パイプラインのコード管理はAWS CLIで
get-pipelineやupdate-pipelineを使って行う。 - 例えば
- GitHubのmergeからトリガ
- CodeBuildでbuild
- CodeBuildでUnit Test
- Staging環境にデプロイ
- Staging環境でIntegration Testや人手の確認
- リリース承認者に通知
- 承認者によるApproval
- 本番環境にデプロイ
- 費用はアクティブパイプライン（30日以上存在していて、月に1回以上実行されたパイプライン）につき$1.00/月
結局どう使っていくか
個人的な意見なので参考までに、だけど↓
- CodePipeline, CodeBuildはあらゆるケースに対応できそうなので導入してみると良いかも
- デプロイにもCodeDeploy使わず、CodeBuildでやれちゃう or せざるを得ないケースは多そう
- EC2, Lambda, ECS, オンプレミスへのdeployを高度化したいときにはCodeDeployの導入を検討し、マッチしそうであれば導入する
- 特に対象サービスでBlue/GreenやCanary Deploy, ロールバックを導入しやすいのはメリット
個人的にはCIよりCDの方が難易度が高い気がする。最初に適切なツールでしっかり設計すべし。
CDは構成管理がきちんとできているか、デプロイ先の環境が意図せず変更されていないか、ロールバックはきちんとできるか、Blue/GreenやCanaryのモニタリングはきちんとできているか…など考えることいっぱい。
でも開発スピードやアジリティを高めるためには必要なことなのでしっかり検討すべし。
参考となるBlackbelt
CodeなんちゃらのBlackbeltが充実しているので、見るべし。
