詳細検索
↑↓移動
↵選択
ESC閉じる

追加のCodeBuildプロジェクトにさよならを告げよう:AWS CodePipelineの新しいコマンドアクションの解説

アバター
著者: Jatin Mehrotra10/25/2024
タグ cloud-infra mid-career
追加のCodeBuildプロジェクトにさよならを告げよう:AWS CodePipelineの新しいコマンドアクションの解説
Englishから翻訳 • 原文を読む

*これまでは、AWS CLIコマンド、サードパーティのCLIコマンドを実行したい、あるいは単にAPIを呼び出したい場合は、 CodeBuildプロジェクトを作成し、適切なコマンドでプロジェクトを設定し、パイプラインにCodeBuildアクションを追加してプロジェクトを実行する必要がありました。*

明らかに、ユーザーはCodePipelineとCodeBuildの2つのコンポーネントを扱い、もちろん両方の内部構造を学ばなければならず、

このブログでは 、CodePipelineのコマンドアクション、すなわち「Codepipelineの新しいアップデート」について説明しています。これにより、 パイプライン実行の一部としてシェルコマンドを簡単に実行できます。

コマンドアクションを使うと、AWS CLI、サードパーティのツール、またはシェルコマンドを実行できます。

最後には、本当にcodeBuildは必要ないのか、コマンドアクションだけでは不十分な場合にcodeBuildを使える場合も議論します。

動機

前提条件

  • CodePipeline、CodeBuildの基本的な動作(このブログでは主にアップデートに焦点を当てます)
  • テラフォーミルの根本的な知識
  • AWSのコアおよび運用の理解

CodePipeline コマンドアクションの理解

  • 基本的には「仮想の計算インスタンスでシェルコマンドを実行することを可能にする」という意味です。
  • 実行されると、設定したコマンドはそれぞれ別のコンテナで実行されます。
  • パイプライン内の過去のステップで必要とされたファイルやデータ(入力アーティファクト)はこの環境で利用可能です。一番良いのは、別のCodeBuildプロジェクトを立ち上げる必要がないことです。

コマンドアクションの舞台裏で何が起こるか

  • コードビルドは今も使用されています !!

まずCodeBuildプロジェクトを作成し、その後CodePipelineにアクションとして追加するという一連のプロセスが、このアクションによって抽象化されてしまっただけです。

  • CodeBuildリソースに依存しているため、コマンドアクションでトリガーされたビルドは、ビルドのタイムアウト55分や同時建設数を含むCodeBuildアカウントのビルド制限にカウントされます。
  • 注:CommandsアクションはCodeBuild管理のオンデマンドEC2計算を実行し、Amazon Linux 2023標準の5.0イメージを使用しています。

コマンドアクションに関するいくつかの注意点:

  • マルチライン形式を除くすべてのコマンド形式がサポートされています。
  • コマンドアクションはクロスアカウントやクロスリージョンアクションにはサポートされていません。
  • CodePipelineがアクションを実行すると、パイプライン名を使ってロググループを作成するため、コマンドアクションには以下の権限が必要です:
logs:CreateLogGroup
logs:CreateLogStream
ログ:PutLogEvents(記録用件)を
  • 孤立したビルド環境がアカウントレベルで使用されるため、インスタンスが別のパイプライン実行のために再利用されることがあります。

コマンドアクションの仕組みを見てみよう!!

  • AWSアカウント内でTerraformリソースを作成するシンプルなCDパイプラインを作成します
  • このパイプラインの基本的な前提は、私の 前回のブログとまったく同じです。
Upload terraform zip to s3 -> CodePipeline is trigger -> コマンドアクション runs terraform apply

ステップ1:Terraformバックエンドとソースを保存するためのS3バケットを作成する

  • terraform zipを保存するための「バージョン管理」されたs3バケットを作成(ソースアーティファクト)
  • このバケットへのアップロードはパイプラインをトリガーします
  • terraformのバックエンドを保存するために、別の「バージョン付き」S3バケットを作成すること。

ステップ2:パイプライン作成

  • このブログをシンプルに保つために、すべてデフォルトにします。
  • 注:私はdocsによるとコマンドアクションの権限があるので、新しいサービスロールを使用しています。既存ロールを使用している場合は、先ほど述べた権限を手動で追加する必要があります。

ステップ3:ソースステージを選択する

  • ステップ1で使用したS3バケットを選択する
  • 「S3オブジェクトキー」の名前に注目:『tf.zip』。
  • もちろん、どんな名前でも選べます

ステップ4:ビルドステージの追加/コマンドの追加

  • これは私たちのパイプラインで最も重要なステップです。このブログの要点です。
  • この次のコマンドでは、私は3つのことをしています
    • TerraformリソースをデプロイするためのTerraformコマンドをインストールすること。Amazon Linux 2023はdnfパッケージマネージャーを使用しているため、dnfパッケージマネージャーの使用に注意してください。
    • Terraform init と apply を使った
    • awsコマンドを使ってアカウント内のすべてのs3バケットをリストアップしました。
sudo dnf install -y yum-utils shadow-utils
sudo dnf config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
sudo DNF -y install terraform
Terraformのバージョン
terraform init -no-color -input=false
Terraform apply -auto-approve -no-color -input=false
AWS S3 LS

注意:コマンドの間に空白を入れないでください。長さ制約でエラーが出ます

ステップ5:展開スキップとレビュー

  • 最終段階では、スキップ、デプロイ、ステージ、レビューを行います。

ほら、Codebuildを知らず、関与もせずに(少なくとも自分で)CDパイプラインを作ったことになります*

本当にうまくいったのか?

  • テラフォームコードのzipを作成

バックエンド用のオプションステップ
テラフォーム {
  バックエンド「S3」{
    bucket = "codepipeline-command-action-backend-jatin"
    リージョン = 「US-East-1」
    key = "terraform-deployment.tfstate"
  }
}

リソース「aws_s3_bucket」「デプロイバケット」{
  bucket = "codepipeline-command-action-backend-1-jatin"

  タグ = {
    プロジェクト = 「CI CD デプロイテスト用」
    環境 = 「開発」
  }
}

リソース「aws_s3_bucket」「デプロイバケット-2」 {
  bucket = "CodePipeline-command-action-backend-2-jatin"

  タグ = {
    プロジェクト = 「CI CD デプロイテスト用」
    環境 = 「開発」
  }
}

ジップ -R tf.zip main.tf

  • また 、Codepipeline内で動作するTerraformがTerraformの状態をs3バケットにアップロードできるようにするため、ServiceRoleに手動で権限「(AmazonS3FullAccess)」を追加する必要があります。これはTerraformのバックエンド設定を使ったためです。

  • Zipファイルをs3バケットにアップロード。

  • ブログの現時点では、CodePipelineによって作成されたサービスロールにバグがあります。コマンドアクションの権限がありません。

  • 前述の権限を手動で追加してください。ブログの目的上、役割に「CloudWatchLogsFullAccess」ポリシーを付けます

  • このステップは任意です。また、terraformのバックエンド設定を使ったので、s3バケットにterraformの状態をアップロードできる権限も追加しました。

CodePipelineのログとs3バケットを確認してください

  • Terraformがアカウント内にバケットやリストバケットを作成できたことは明確に確認できます。

DevOpsアーキテクトの視点から

コマンドアクションを使うと、CodeBuildアクションに触れたり扱ったりする必要がなく、CI/CDパイプラインの作成に集中できます。しかし、抽象化には本当に十分でしょうか?

  • ドキュメントによると、CodePipelineコマンドアクションは「CodeBuild管理のオンデマンドEC2コンピュート」を実行しているため、メモリ、vCPU、ディスク容量の制限が明らかに分かっていない
  • CodeBuildを使用する場合、 ビルド中に最適化された柔軟性 を自由に選択でき、 Lambdaを計算してより速いビルドや展開を実現します。
  • 明らかに、この「コマンドアクション」の抽象化は、柔軟性、コスト削減、CodeBuild学習に余裕がある時間と、シンプルさ、簡単さ、時間の節約とのトレードオフです。
  • コストの観点から、この抽象化は「安価な」CI CDパイプラインと混同しないでください。コマンドアクションを実行するとAWS CodeBuildでは別途料金が発生します。

コミュニティはこのアップデートをパイプラインでどのように活用し、効率化にどう役立つと考えていますか?

ご質問やコメントを残して、CI CDパイプラインの取り組みを楽にしましょう。いつでも LinkedInや Xから私に連絡してください。

もっと見る

Related Articles