この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本日のアップデートで、CodeBuild において一時停止および、AWS Systems Manager セッションマネージャー（以下、セッションマネージャー）でのビルドコンテナへのログインがサポートされました！
何がうれしいのか
これまで CodeBuild でビルド実行中のコンテナにログインする手段は提供されていなかったため、例えばビルドがうまく走らない場合のデバッグを行うには、CloudWatch Logs などのログに一旦出力したうえで探る必要がありました。
状態確認のためのコマンドを buildspec.yml に追加して、再ビルドして、ログを確認しようとしたけど「思てたんとちがーう！」内容しか表示されていなかったので、また buildspec.yml を更新して・・・そんな経験ないでしょうか？
今回のアップデートによってビルド処理を一時停止し、セッションマネージャーを使ってビルドコンテナにログインすることが可能となりましたので、インタラクティブにコマンドを実行してデバッグ作業を進めることが出来ます。もう、何度も何度も buildspec.yml を更新して、再ビルドを繰り返す必要はありません！
これでデバッグ作業はかなり捗るのではなないでしょうか！
前提条件
セッションマネージャーでの接続には、以下の前提条件を満たす必要があります。
- SSM エージェントがインストールされており、SSM エージェント ContainerMode が有効になっていること
- CodeBuild のマネージド Linux イメージは対応済み
- カスタムイメージを利用の場合、SSM エージェントのインストールおよび、amazon-ssm-agent.json ファイルを
/etc/amazon/ssm/にコピーして ContainerMode を有効にします
- CodeBuild サービスのロールには、次の SSM ポリシーが必要ですが、ビルドのセッション接続を有効にすると自動的にアタッチされますので、ユーザー側での対応は特に必要ありません。
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}注意点
CodeBuild はビルドを開始してから終了するまでの時間で、分あたりの課金が発生します。小さなコンピューティングタイプではそれほど気にならないかもしれませんが、大きめのコンピューティングリソースを使用する場合は、一時停止している時間に気をつけましょう。（以下、執筆時点の東京リージョン料金です）
| コンピューティングインスタンスタイプ | メモリ | vCPU | Linux のビルド 1 分あたり |
|---|---|---|---|
| general1.small | 3 GB | 2 | 0.005USD |
| general1.medium | 7 GB | 4 | 0.01USD |
| arm1.large | 16 GiB | 8 | 0.02USD |
| general1.large | 15 GB | 8 | 0.02USD |
| general1.2xlarge | 144 GiB | 72 | 0.25USD |
| gpu1.large | 244 GiB | 32 | 0.90USD |
やってみる
それでは動作確認してみます。
ビルドプロジェクトの作成
東京リージョンに検証用のビルドプロジェクトを作成します。今回はマネージド型のビルドイメージを使用しています。
Buildspec に codebuild-breakpoint を挿入することで、ビルドを一時停止させるブレイクポイントを指定します。
buildspec.yml
phases:
pre_build:
commands:
- echo Entered the pre_build phase...
- echo "Hello World" > /tmp/hello-world
- codebuild-breakpointビルドの開始
作成したビルドプロジェクトを選択し、[ビルドの開始]をクリックします。セッション接続を有効にするには、[高度なビルドの上書き]を表示してください。
すると[環境]セクションに セッション接続の有効化 という項目が増えていますので、これにチェックを入れます。セッション接続の有効化 されていない場合、codebuild-breakpoint および codebuild-resume コマンドは無視されます。
[ビルドの開始]をクリックします。ビルド内では echo を実行しているだけなので、通常であれば直ぐにビルドが完了しますが、codebuild-breakpoint によって処理が一時停止されていますので、実行中のままであることが判ります。
IAM ロールのポリシーを確認すると、前提条件となる SSM ポリシーが自動的に追加されていることが確認できました。
IAM ロールに個別ポリシーをアタッチするのではなく、ポリシーそのものに追加されているようです。このようにポリシーのバージョンも更新されていました。
それでは、この状態でセッションマネージャーによる接続確認をしてみます。
セッションマネージャーの開始
ビルドステータスの右下にある AWS セッションマネージャー のリンクをクリックします。
すると、セッションマネージャーの画面が起動し、ビルドコンテナに接続されます。ビルド処理のなかで実行していた echo "Hello World" > /tmp/hello-world によって生成されたファイルの内容が確認できました。
ちなみに、AWS Systems Manager セッションマネージャーの管理コンソールの[セッションの開始]にはビルドコンテナは表示されていなかったので、AWS コンソールからの場合はビルドステータスのリンクから接続する必要があるようです。
ビルドの再開
ビルドコンテナーの調査が終了したら、コンテナーシェルから codebuild-resume コマンドを発行し ます。
sh-4.2# codebuild-resumeすると後続処理が流れます。ビルドステータスも 実行中 から 成功 に変わり、セッションマネージャのリンクも消えたことが確認できました。
検証は以上です！
さいごに
これまで CodeBuild のデバッグは「ログに出力させないことには何もわからん！」状態だったかと思いますが、このアップデートでインタラクティブにコマンド実行しながら確認できるようになりますので、めちゃめちゃデバッグ作業が捗ることは間違いないでしょう！
CodeBuild でのデバッグに辛みを感じてた方にとっては神アップデートですね！どんどん使って行きましょう。
以上！大阪オフィスの丸毛（@marumo1981）でした！
3
