![[アップデート] AWS CodePipeline がデプロイプロバイダーに「EC2」をサポートし CodeDeploy を使わなくても直接デプロイできるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-7cdd08196c0c75239e41fd834b427547/b64ab4252df175f1536fe199afbab2a3/aws-codepipeline)
[アップデート] AWS CodePipeline がデプロイプロバイダーに「EC2」をサポートし CodeDeploy を使わなくても直接デプロイできるようになりました
2025.02.22いわさです。
今朝のアップデートで AWS CodePipeline に新しいデプロイアクションプロバイダー「EC2」が追加されました。
EC2 にデプロイするとなると、CodeDeploy エージェントをセットアップして AppSpec を書いて...みたいなのが必要だったのですが、CodePipeline から直接デプロイできるようになります。
仕組みとしては SSM エージェント経由でコマンドを実行させる形になるので、外部からデプロイするためにインバウンドポートの解放なども不要です。
今回こちらを試してみたので使い方などを紹介します。
デプロイアクションの仕様
実際にパイプラインを構成しようとすると、次のアクションが選択できます。
こちらのアクションリファレンスが以下です。
いくつか前提条件があります。
- パイプライン V2 のみサポート
- Linuxインスタンスのみサポート
- SSM エージェントがインストールされている必要がある
- フリートサイズは 500 インスタンスまで
本日時点では Linux インスタンスのみですね。Windows は引き続き CodeDeploy エージェントを使うことになりそうです。
ただ、仕組みとしては SSM 経由で CodePipeline が SendCommand をして、インスタンス上でアーティファクト内のデプロイスクリプトを実行する形なので Windows でもできるような気もします。今後サポートされそうな。
フリートサイズの制限についてですが、タグを指定して複数台のインスタンスを対象にデプロイ操作を行うことができます。
試してみる
パブリックサブネットに Apache な EC2 を配置してドキュメントルートのコンテンツを更新してみます。
事前に新規 EC2 を手動で作成し、次のようなコマンドを実行済みです。
sh-5.2$ sudo su
[root@ip-172-31-47-165 bin]# yum update -y
[root@ip-172-31-47-165 bin]# yum install httpd -y
[root@ip-172-31-47-165 bin]# service httpd start
[root@ip-172-31-47-165 bin]# chkconfig httpd on
[root@ip-172-31-47-165 bin]# echo "hoge" > /var/www/html/index.html
外部から IP アドレスで HTTP アクセスしてみると Apache が配信するコンテンツが確認できます。こいつを更新してみましょう。
% curl http://54.199.145.91/
hoge
最近 CodePipeline はテンプレートから簡単にパイプラインが作成できるようになったのですが[1]、今回のデプロイアクションはまだテンプレートから提供されていないようです。
なのでカスタムパイプラインから開始します。
カスタムパイプラインを選択
コードやビルド、テストフェーズは任意で進めてもらって、ポイントはデプロイフェーズです。
ここでデプロイプロバイダーに「Amazon EC2」を選択します。
デプロイプロバイダーに「Amazon EC2」を選択。許可アクションに関する注意書きが
そうすると注意書きが表示されるのですが、このアクションを使用するには、AWSCodePipelineServiceRole に以下のアクセス許可を手動で追加する必要があるようです。新規作成ロールの場合は自動でやってくれよという気もちょっとしますが仕方ない。
- ssm:CancelCommand
- ssm:DescribeInstanceInformation
- ssm:ListCommandInvocations
- ssm:SendCommand
ちなみにこちらの対応をしていないとデプロイ時に次のエラーが発生して失敗します。
デプロイ失敗
まず最初に必要なのは対象 EC2 の指定です。前提としてタグで指定する必要があります。
タグでターゲットを指定
そして各インスタンスでどのようなデプロイ操作を行うのか設定していくのですが、ターゲットディレクトリと PostScript の指定が必要です。
アーティファクトのターゲットディレクトリを指定。PostScriptが必須
そう、アーティファクトをデプロイして終わりではなくて PostScript で何かしらのコマンド実行を行うので、まぁ CodeDeploy の AppSpec みたいなものだと思ってもらうのが良いと思います。
今回はソースリポジトリに次のようなスクリプトを設置しました。
今回は割愛しますがいくつかデプロイオプションがあります。
一括デプロイする数や割合、ロードバランサーのトラフィック周りですね。CodeDeploy の基本設定に近い感じだろうか。
デプロイオプションがいくつかある
デプロイしてみました。コンテンツが更新されているか見てみましょう。
デプロイ成功
% curl http://54.199.145.91/
fuga
良いですね。うまく動いていました。
なお、チュートリアルドキュメントではAWSSystemsManagerDefaultEC2InstanceManagementRoleeployActionというマネージドポリシーを EC2 インスタンスプロファイルのロールにアタッチするように指示があります。[2]
ドキュメントのマネージドポリシーに関する言及
しかし、こちらは私の環境では確認が出来ませんでした。
また、EC2 からは CodeDeploy のアーティファクトバケットへのアクセス権限が追加で必要ということ以外は追加の権限について言及されておらず、このマネージドポリシーの詳細アクションについては触れられていませんでした。何か必要なのかな...
さいごに
本日は AWS CodePipeline がデプロイアクションプロバイダーに「EC2」をサポートし CodeDeploy を使わなくてもデプロイできるようになったので試してみました。
まさに CodeDeploy を代替するような動きが出来そうです。最近の CodePipeline の進化がすごい。
今度 EC2 を対象とするパイプラインを構築する際にはこちらの機能を採用してみます。
