Zenn
⛳

AWS CodePipelineの超詳細解説

2023/11/04に公開
AWS
#
CI/CD
#
DevOps
AWS 認定試験
tech

はじめに

この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧はこちら。

この記事ではCodePipelineとはどういうサービスで何ができるのかを超詳細にまとめています。

具体的には以下流れで説明します。

  • AWS CodePipelineとは
  • AWS CodePipelineにおけるアーティファクト
  • AWS CodePipelineの起動契機
  • AWS CodePipelineアクションタイプとの統合
  • AWS CodePipelineを起点とするイベント駆動
  • マルチアカウント、クロスアカウントでのAWS Codepipeline
  • AWS CodePipelineのベストプラクティス

AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

この記事を読んでほしい人

  • CodePipelineがどういうサービスか説明できるようになりたい人
  • CodePipelineを採用するときのベストプラクティスを説明できるようになりたい人
  • AWS Certified DevOps Engineer Professionalを目指している人

AWS CodePipelineとは

AWS CodePipelineとはCI/CDをオーケストレーションするためのビジュアルワークフローツールです。

ソース、ビルド、テスト、ビルド、承認に加えて呼び出しという合計6つのアクションが定義されており、それぞれのアクションごとに統合できるサービスが決まっています。

詳しくはAWS CodePipelineアクションタイプトの統合でまとめますので、まずはCI/CDのワークフローを作るためのものなんだ、という理解をしてください。

AWS CodePipelineにおけるアーティファクト

AWS CodePipelineではアーティファクトを各ステージごとに作成することが可能です。
作成されたアーティファクトはS3に保存され、次のステージに受け継がれます。

ただし、ビルドが不要でテストのみ実施するような場合はCodeBuildでアーティファクト不要です。
必要に応じて、次のステージに渡したいものをアーティファクトとしてS3に保存してください。

AWS CodePipelineの起動契機

AWS CodePipelineの起動契機は以下3つが存在します。

  1. EventBridgeを用いたイベント駆動
  2. Webhook
  3. ポーリング

しかし、現在のベストプラクティスはイベント駆動なので特別な要件がなければイベント駆動を採用しましょう。

試験でもCodePipelineの起動契機はイベント駆動とすべし、という内容でよく出題されます。

AWS CodePipelineアクションタイプとの統合

AWS CodePipelineとは、で記載した通りCodePipelineのアクションは全部で6つあります。
アクションタイプごとの統合先をここで紹介するのは冗長なのでそれはAWSのページに譲り、ここではプロジェクトでよく使うまたは試験でよく出るものだけをピックアップしてまとめます。

ただし、AWSのベストプラクティスはAWSのCodeシリーズを利用することです。
なので、既存の資材がない限り基本的にはCodeシリーズで組み立てることを検討しましょう。

ソース

  • CodeCommit
  • S3
  • ECR
  • など

使うことが多いのは圧倒的にCodeCommitとECRです。
S3でもオブジェクト管理できますが、特殊な要件がない限りバージョン管理が可能なCodeCommitの利用がベストプラクティスです。

ビルド

  • CodeBuild
  • Jenkins
  • など

ここも基本はCodeBuildを第一候補に考えましょう。
ただし、すでにJenkinsで組んでしまっているので移行コストが見合わない、という場合にはJenkinsを採用するという選択もありです。

試験向けの注意点としてはJenkinsはベストプラクティス外なので、CodeBuildへの移行が政界になるという点です。

テスト

  • CodeBuild
  • Jenkins
  • など

ビルドと同様なので詳細は割愛します。

デプロイ

  • CodeDeploy
  • CloudFormation
  • ECS
  • Elastic Beanstalk
  • OpsWorks Stacks
  • など

デプロイに関してはデプロイしたい内容によってベストプラクティスが変わります。
なので、自分が何をデプロイあるいはプロビジョニングしたいと思っているかを明確にしたうえで採用するソリューションを決めましょう。

例えばアプリケーションならCodeDeploy、デプロイではなくプロビジョニングであればCloudFormationといった具合です。

エンタープライズで使うことはほとんどありませんが、Elastic Beanstalkも統合できる点は覚えておくと試験対策になります。

CloudFormation

デプロイの中でCloudFormationだけもう少し掘り下げて説明します。

詳しく述べたいのは2点です。

まず1点目。
CloudFormationのデプロイではCloudFormationのStackSetsを実行することが可能です。
そのため、StackSetsを正しく作ればマルチリージョン、マルチアカウントへのプロビジョニングを1本のパイプラインで実現することが可能です。

ただし、注意すべき点があります。
それはCodePipelineは1つでよいが、アーティファクトを該当のリージョンに配置する必要があるということです。

わかりやすく説明するために以下の図をご覧ください。

実行しているパイプラインは1本ですが、アーティファクトだけ2つのリージョンに配置されていることがわかると思います。

これを忘れると、パイプラインが存在しないリージョンで実行失敗するので気を付けましょう。

次に2点目。
AWS CodePipelineでCloudFormationを実行する場合には、実行の仕方をCREATE_UPDETEとDELETE_ONLYから選択できます。

CREATE_UPDATEは新規作成あるいは既存スタックの更新が行われます。
DELETE_ONLYは存在するスタックの削除が行われます。

開発環境を試験後削除しているプロジェクトではDELETE_ONLYが活躍するので採用を検討してみてください。

承認

  • 手動

承認は必ず手動で行う必要があるので選択肢は手動だけです。
後述するイベント駆動を組み合わせるとモバイルへのプッシュ通知を飛ばして、承認する、というOpsが可能になります。

呼び出し

  • Lambda
  • StepFunctions

呼び出しできる先はLambdaかStepFunctionsのみです。
ここでいう呼び出し、とはInvokeのことでEventBridgeを挟まず直接CodePipelineから呼び出せるという意味です。

直接の呼び出しはできませんが、EventBridgeを用いたイベント駆動でSNSなどに連携することは可能なので混乱しないように注意しましょう。

AWS CodePipelineを起点とするイベント駆動

CodePipelineで発生したイベントを検知してEventBridgeでイベント駆動させることが可能です。
CodePipelineのベストプラクティスとして、パイプライン中の失敗イベントを検知してEventBridgeを用いた通知の発砲、があります。

これはCI/CDが高速なサイクルでビルドとテストを繰り返すことが背景にあるベストプラクティスです。

高速にサイクルを回すためには、人間がマネジメントコンソールに張り付くのはアンチパターンです。ステータスが変更されたら自動で通知が飛んでくるようにすることで、パイプラインを起動した後は通知が来るまでほかのやるべきことをやれるようにする、というのがベストプラクティスになります。

マルチアカウント、クロスアカウントでのAWS Codepipeline

マルチアカウント、マルチリージョンについてはCloudFormationのところで詳しく書いているのでここでは注意点を1つだけ簡単に記載します。

それはアーティファクトを該当アカウントあるいはリージョンに置く必要があるのはCloudFormationに限らない、という点です。

詳細はAWS CodePipelineアクションタイプとの統合の中にあるCloudFormationのところを読んでください。

AWS CodePipelineのベストプラクティス

ここまで、AWS CodePipelineの詳細を説明してきましたが、最後にAWS CodePipelineでパイプラインを構築する際の3つベストプラクティスを説明します。
これは基本原則に近いものなので守ることをおすすめします。
また、試験でもよく聞かれるところです。

3つのベストプラクティスは以下になります。

  1. 1つのAWS CodePipelineに1つのAWS CodeDeploy。並行でデプロイしたければAWS CodeDeployのデプロイメントグループで対応する。

並行でデプロイしたいからと言って複数のAWS CodePipelineを構築することはアンチパターンです。
同じパイプラインを複数作ることは実行時にアカウントのAPIスロットリングに引っ掛かりやすくなるというだけではなく、同じパイプラインが複数存在することによる管理不全など様々な問題を引き起こすので絶対にやめましょう。

  1. 1つのステージで並行アクションを実行したければRunOrderパラメータを変更する。

AWS CodeDeployの場合にはデプロイメントグループを利用することで並行実行が可能になります。
しかし、AWS CodeDeployを使う場合以外にもビルドとテストを2種類のビルドを並行したい場合などへ移行実行したい場面はあると思います。

その時には各実行ステージのRunOrderパラメータを2以上の値に設定してパイプラインを構築しましょう。

アンチパターンは1つ目の時と同じなので割愛します。

  1. 本番環境にデプロイする前にプレデプロイを実行し、承認を経て本番環境にデプロイする。

これは言わずもがななので詳細は割愛します。
が、安定した本番環境の維持運用のためにはとても大事なことですよ。

まとめ

この記事ではCodePipelineとはどういうサービスで何ができるのかを超詳細にまとめました。

  • AWS CodePipelineとは
  • AWS CodePipelineにおけるアーティファクト
  • AWS CodePipelineの起動契機
  • AWS CodePipelineアクションタイプとの統合
  • AWS CodePipelineを起点とするイベント駆動
  • マルチアカウント、クロスアカウントでのAWS Codepipeline
  • AWS CodePipelineのベストプラクティス

次回はCodeBuildについて超詳細解説を行います。

Discussion