Amazon Web Services(AWS)のCodePipelineチームは、開発者やDevOpsエンジニアの運用オーバーヘッドを簡素化し、EC2へのデプロイメントプロセスを効率化し、CodePipelineアクションを導入してEC2インスタンスに直接デプロイできるようにしました。>
*なぜそれがあなたにとって重要なのですか? *
以前はEC2インスタンスにデプロイしたい場合は、CodeDeployとAppSpecファイルを使ってデプロイを設定する必要がありました。 このアップデート以降、CODEDEPLOYリソースとAPPSPECファイルの管理は不要になりました。
*今日これを試してみたので、デプロイメントパイプラインを90%簡素化し、複雑なプロセスやスクリプトをすべて取り除く方法をお見せします!! *
建築

前提条件
- Linuxインスタンスタイプのみをサポートします
- 最大対応フリートサイズは500インスタンスです。
- パイプラインV2のみ対応
- SSMエージェントはインストールされている必要があります
舞台裏
このアクションは、インスタンス内でSSMを用いてスクリプトを実行する送信コマンドを実行します。
ApacheでEC2インスタンスを作成する
**注意:**インスタンスを作成する場合は、「AmazonSSMManagedInstanceCore」「AmazonS3ReadOnlyAccess」でロールを作成し、ec2インスタンスにアタッチする必要があります。
- SSMエージェントをインスタンスに手動で追加する(ユーザーデータを使うか、既存インスタンスにログインしてコマンドを実行する)。
- 既存のインスタンスを使用している場合は、SSMエージェントを追加した後にインスタンスを再起動する必要があります。
ブログの簡潔さのために、ApacheのウェブサーバーでEC2を作成しました。

須藤
おいしいアップデート -y
Yum install httpd -y
Service httpd start
chkconfig httpd on
Echo「Codepipeline EC2デプロイメント」> /var/www/html/index.html

Ec2展開アクションでパイプラインを作成
- ここではタグを使ってインスタンスを選択する必要があります;私はインスタンスを識別するために名前タグを使っています。
- 次に、ec2インスタンスでデプロイしたいターゲットディレクトリを提供する必要があります。
- 最後に、デプロイフェーズ後に実行される実行可能なスクリプトファイルへのパス。
**注意:**パイプラインが作成されたら、エラーを避けるためにパイプラインのサービスロールを編集し、以下の権限を追加する必要があります。
{
「効果」:「許可」
「アクション」:[
「ssm:キャンセルコマンド」
「ssm:DescribeInstanceInformation」
「ssm:ListCommandInvocations」
「ssm:SendCommand」
],
「リソース」:「*」
}
パイプラインを走らせろ
私はソースをGitHubとして使い、コード開始接続を使っており、コードはこのリポジトリに存在しています。
注意:AWSのガイドにはec2インスタンスロールに「AWSSystemsManagerDefaultEC2InstanceManagementRoleeployAction」を追加する方法が書かれていましたが、私の環境ではその権限は必要ありませんでした


このアクションのためのいくつかの高度なオプション
- 並列展開するインスタンス数や割合を指定することができます。
- タスクが失敗した後にタスクを停止するためのインスタンス数やパーセンテージで指定できます。
- ロードバランサーを指定すれば、そのインスタンスのデプロイメント時にTOIのトラフィックをブロックできます。
開発者、DevOpsの視点から
- このアップデートにより、CodeDeployリソースの管理をせずにEC2上でエンドツーエンドのAWSネイティブ継続展開が可能になりました。
- これは、ビジネスの問題やアプリケーションに集中したい開発者やDevOpsエンジニアにとって、複雑な展開プロセスにこだわらずゲームチェンジャーとなるでしょう。
- もちろん、AWSが役割に必要な権限を追加できれば、この簡素化体験はさらに100%にまで拡張できます。
これを読んで、このアクションに移行してデプロイプロセスを簡素化したいですか?
*私は毎日、Linkedin*やXでDevOps、Kubernetes、GenAIに関する素晴らしいAWSの最新情報をシェアしています。ぜひそちらをフォローして、あなたの生活をより楽にします。