[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
[アップデート] AWS CodePipeline で CodeBuild セットアップなしでコマンド実行が出来る新しいビルドアクション「Commands」を使ってみた

[アップデート] AWS CodePipeline で CodeBuild セットアップなしでコマンド実行が出来る新しいビルドアクション「Commands」を使ってみた

Clock Icon2024.10.05

いわさです。

先日 AWS CodePipeline のドキュメント更新履歴にて新しいアクションの登場を確認しました。

B572AD78-8160-4F61-A8D4-9E511E732F75.png

https://docs.aws.amazon.com/codepipeline/latest/userguide/history.html

従来の CodePipeline ではビルドステージで CodeBuild プロジェクトを実行することで Buildspec に定義した任意のコマンドを実行していました。
今回登場した新しいアクションを使うと CodeBuild の準備なしでコマンドを実行することが可能です。

実体としては AWS マネージドな CodeBuild が動いており、CodeBuild の利用料金も発生するとのことで、実際に実行して確認してみましたので紹介します。

アップデートアナウンス

アップデートアナウンスも出ていました。見落としてました。

https://aws.amazon.com/about-aws/whats-new/2024/10/aws-codepipeline-general-purpose-compute-action/

ビルドステージで「Commands」アクションを選択する

現在 CodePipeline パイプラインには V1 と V2 があるのですが、確認したところどちらのバージョンでも新しいアクションを使うことが出来ました。
ただ、V1 は現在は新規では作成出来ないようですね。

05CE0543-4BA5-4910-8692-265ABF242325.png

ビルドステージで次のように選択出来るようになってました。
デフォルトのビルドプロバイダーとして Commands が選択されており、これが新しいものですね。

5ACAE5D7-84D0-471E-8C21-9743500B9471.png

従来のビルドプロバイダーは Other build providers から選択する形です。

FD883CAD-B2C5-4859-942B-02D8188EDA9A.png

Commands を選択すると、シンプルにコマンドをパラメータとして設定出来る感じですね。
改行で複数コマンドの実行が可能です。

BFA01661-1A21-484C-86D5-97D6A8613438.png

実行してみる

前述のようにlsechoを設定して実行してみました。
実行ログを確認してみます。

3A7E2438-96B8-4BDF-A46E-BC82B702A218.png

設定したコマンドが順次実行されていますね。
そして、初期化部分のログを見てみると CodeBuild がオンデマンド実行されていることも確認出来ます。

ただし、CodeBuild のビルドプロジェクト一覧を確認してみてもプロジェクトが存在しません。
ユーザーマネージドではない部分で CodeBuild が内部的に実行されている。という感じでしょうか。

20C38D44-E6F6-4015-8974-BCDCF5A75720_1_105_c.jpeg

なお、コマンドアクションのリファレンスはこちらです。

https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-Commands.html

いくつか考慮事項があって、前述のとおり内部的に CodeBuild が使われており、同時ビルド制限の対象に含まれるという点や、実行される CodeBuild 環境はアカウントレベルで分離されるもので異なるアカウント間で再利用はされませんが、同一アカウント内だと再利用される可能性があるようです。
また、ビルドタイムアウトは 55 分固定みたいです。

なお、実行環境の情報を少し確認してみたところ、Amazon Linux 2023 がベースイメージとなっているようでした。

2D8A4990-FE94-4498-992F-1640FC8C6EA5_1_105_c.jpeg

サービスロールの権限に注意

先ほどコマンドアクションを新規パイプラインに設定した際にサービスロールを作成したと思います。
こちらの権限に注意してください。

ログ出力権限などいくつか不足しており、パイプライン設定によって次のようにアクションが失敗する場合があります。

47305811-0B72-4A9A-AB77-FA26EDC0D448.png

Action failed with status: FAILED. Service role does not have permissions to create Amazon Cloudwatch log streams. Add logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents permissions to your service role. Default log group is /aws/codepipeline/<pipeline-name>

サービスロールはパイプラインの設定メニューから確認出来るこちらのロールです。
CodeBuild 上で実行される際にこちらのロールを使ってセッション生成されているようなのでコマンドが必要な IAM ポリシーはこのサービスロールに設定してやる必要があります。

D4507BE1-EB2D-42AE-A726-992F32860E4E_1_105_c.jpeg

上記のサービスロールに EC2 の停止権限を設定し、EC2 を停止してみました。
実行には成功していますね。EC2 も停止されていました。

C322BDE6-0E00-41AD-A3F3-963E9899DDEB_4_5005_c.jpeg

CloudTrail の履歴を確認してみると該当サービスロールから生成されたセッションが使われているようだったので、挙動としては期待どおりです。

BC800E1B-84EB-4763-BE17-E41345C7D59B_1_105_c.jpeg

さいごに

本日は AWS CodePipeline で CodeBuild セットアップなしでコマンド実行が出来る新しいビルドアクション「Command」を使ってみました。

Buildspec を使ったアプリケーションビルド以外でシンプルなコマンドをパイプラインの一部に組み込みたいときがあると思うのですが、ビルドプロジェクトの準備や関連付けが不要なので使いやすそうですね。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.