概要
AWS Elastic BeanstalkとCodePipelineを連携させることで、コードのコミットから本番環境へのデプロイまでを自動化できます。本記事では、両サービスの統合機能を活用した継続的デプロイメント環境の構築手順と、実際の運用で役立つベストプラクティスを実例とともに解説します。
目次
1. はじめに
Elastic BeanstalkとCodePipelineの概要
AWS Elastic Beanstalkは、アプリケーションのデプロイと管理を簡素化するPlatform as a Service(PaaS)です。開発者はアプリケーションコードをアップロードするだけで、Elastic Beanstalkが自動的にキャパシティプロビジョニング、負荷分散、自動スケーリング、アプリケーションの正常性監視を処理します。
一方、AWS CodePipelineは、「コード変更のたびにコードを構築、テスト、デプロイする」継続的統合・継続的デリバリー(CI/CD)サービスです。
統合のメリットと適用場面
この2つのサービスを統合することで、以下のメリットが得られます:
- 自動化による効率化: 「自動化、一貫性、迅速な反復ループ、および多様性」からチームが恩恵を受けられます
- 迅速なフィードバック: コードの変更から本番環境への反映までの時間を大幅に短縮
- 人的エラーの削減: 手動デプロイによるミスを防止
- 一貫性のあるデプロイ: 環境間での設定の違いを最小化
この統合は、Webアプリケーションの継続的デプロイメントを実現したいチームや、DevOpsプラクティスを導入したい組織に特に適しています。
2. 事前準備
必要なAWSサービスとIAMロール
統合を始める前に、以下のサービスとリソースを準備する必要があります:
必要なAWSサービス:
- AWS Elastic Beanstalk(デプロイ先)
- AWS CodePipeline(CI/CDパイプライン)
- AWS CodeBuild(ビルドステージ、必要に応じて)
- GitHub、GitLab、またはS3(ソースコードリポジトリ)
注意: 2024年7月25日以降、AWS CodeCommitは新規顧客の受け入れを停止しています。本記事では、新規ユーザーでも利用可能なGitHubを主要なソースプロバイダーとして解説します。
必要なIAMロール:
- CodePipelineサービスロール: パイプラインの実行に必要な権限
- Elastic Beanstalkサービスロール: アプリケーションの実行環境管理
- CodeBuildサービスロール: ビルドプロセスの実行(CodeBuildを使用する場合)
CodePipelineのサービスロールには、最低限以下の権限が必要です:
- S3バケットへの読み書き権限
- Elastic Beanstalkアプリケーションへのデプロイ権限
- CloudWatchLogsへの書き込み権限
サンプルアプリケーションの用意
本記事では、Node.jsの簡単なWebアプリケーションを例に説明します。以下のファイル構成を想定しています:
my-app/
├── app.js
├── package.json
└── buildspec.yml(CodeBuildを使用する場合)
app.js
の例:
const express = require('express');
const app = express();
const port = process.env.PORT || 3000;
app.get('/', (req, res) => {
res.send('Hello World! This is deployed via CodePipeline!');
});
app.listen(port, () => {
console.log(`Server running on port ${port}`);
});
3. Elastic Beanstalk環境の構築
アプリケーション作成
- AWSマネジメントコンソールにアクセスし、Elastic Beanstalkサービスを選択
- **「アプリケーションの作成」**をクリック
-
アプリケーション名を入力(例:
my-web-app
) - プラットフォームを選択(例:Node.js)
- アプリケーションコードで「サンプルアプリケーション」を選択して初期作成
環境設定のポイント
環境タイプの選択:
- 単一インスタンス: 開発・テスト環境に適している、コスト効率が良い
- 負荷分散: 本番環境に推奨、高可用性と自動スケーリング
重要な設定項目:
設定項目 | 推奨値 | 理由 |
---|---|---|
インスタンスタイプ | t3.micro(開発)、t3.small(本番) | コストと性能のバランス |
ヘルスチェック | /health | アプリケーションの正常性監視 |
展開ポリシー | Rolling | ダウンタイムを最小化 |
環境変数 | NODE_ENV=production | アプリケーションの動作モード |
セキュリティ設定:
- VPCの設定(本番環境では必須)
- セキュリティグループの適切な設定
- HTTPSの有効化(SSL証明書の設定)
4. CodePipelineとの統合設定
パイプライン作成手順
- CodePipelineコンソールにアクセス
- **「パイプラインの作成」**をクリック
- パイプライン名を入力
- 新しいサービスロールを作成(または既存のロールを選択)
ソース、ビルド、デプロイステージの構成
ソースステージ設定:
- ソースプロバイダー: GitHub、GitLab、またはS3を選択
- リポジトリ: 対象のリポジトリを指定
-
ブランチ: デプロイ対象のブランチ(通常は
main
またはmaster
)
GitHubとの連携設定:
- GitHubアカウントとの接続を設定
- 対象のリポジトリを選択
- WebhookまたはPollingによる変更検知の設定
- アクセストークンの設定(必要に応じて)
ビルドステージ設定(オプション):
CodeBuildを使用する場合、buildspec.yml
を作成:
version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- npm install
build:
commands:
- echo Build started on `date`
- npm run build
post_build:
commands:
- echo Build completed on `date`
artifacts:
files:
- '**/*'
デプロイステージ設定:
- デプロイプロバイダー: AWS Elastic Beanstalkを選択
- アプリケーション名: 先ほど作成したElastic Beanstalkアプリケーション
- 環境名: デプロイ先の環境名
AWS公式ドキュメント(https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-Beanstalk.html )によると、「Elastic Beanstalk アクションを使用してアプリケーションコードをデプロイメント環境にデプロイします」。
統合時の注意点
アーティファクト形式の重要性:
「最終的には、CodeBuildを使用してElastic Beanstalkが使用するZIPファイルを生成する必要があります」。Elastic Beanstalkは特定の形式のアーティファクトを期待するため、正しい形式でのパッケージ化が必要です。
権限エラーの対策:
- CodePipelineサービスロールがElastic Beanstalkアプリケーションにアクセスできることを確認
- S3バケットへの適切な権限設定
- CloudWatchLogsへのアクセス権限
タイムアウト設定:
大きなアプリケーションの場合、デプロイに時間がかかる可能性があるため、適切なタイムアウト値を設定してください。
5. 動作確認と運用のポイント
デプロイテストの実行
パイプラインの設定完了後、以下の手順でテストを実行します:
- ソースコードの変更: リポジトリに小さな変更をコミット
- パイプラインの実行確認: CodePipelineコンソールでパイプラインが自動的に開始されることを確認
- 各ステージの監視: ソース取得、ビルド、デプロイの各ステージが正常に完了することを確認
- デプロイ結果の確認: Elastic Beanstalk環境のURLにアクセスし、変更が反映されていることを確認
監視とロールバック方法
CloudWatchでの監視:
- アプリケーションのパフォーマンスメトリクス
- エラーログの監視
- リソース使用状況の追跡
ロールバック手順:
- Elastic Beanstalkコンソールで「アプリケーションバージョン」を選択
- 以前の安定したバージョンを選択
- 「デプロイ」をクリックしてロールバックを実行
アラート設定:
- デプロイ失敗時の通知設定
- アプリケーションエラー率の閾値設定
- レスポンス時間の監視
コスト最適化のヒント
Elastic Beanstalk環境:
- 開発環境では単一インスタンス構成を選択
- 本番環境でもトラフィックに応じた適切なインスタンスタイプを選択
- 自動スケーリングの設定を適切に調整
CodePipeline:
- 不要なパイプラインの削除
- ビルド時間の最適化(キャッシュの活用)
- S3アーティファクトの適切なライフサイクル設定
AWS公式の料金情報(https://aws.amazon.com/codepipeline/pricing/)によると、CodePipelineは月額$1.00/パイプラインから利用可能で、Elastic Beanstalkは使用するEC2インスタンスの料金のみが発生します。
6. 終わりに
まとめ
本記事では、AWS Elastic BeanstalkとCodePipelineを統合した継続的デプロイメント環境の構築方法を解説しました。この統合により、以下の成果が得られます:
- 効率性の向上: 手動デプロイ作業の削減
- 品質の向上: 一貫性のあるデプロイプロセス
- 迅速な反復: 機能追加やバグ修正の迅速な本番反映
- 運用負荷の軽減: 自動化による運用タスクの削減
次のステップ
さらなる改善のために、以下の実装を検討してください:
- テストの自動化: CodeBuildでのユニットテストやインテグレーションテストの実行
- 複数環境への対応: 開発、ステージング、本番環境への段階的デプロイ
- 承認プロセス: 本番デプロイ前の手動承認ステップの追加
- 監視の強化: カスタムメトリクスやログ分析の実装
- セキュリティの強化: IAMロールの最小権限化やVPC設定の見直し
継続的改善を通じて、より堅牢で効率的なデプロイメント環境を構築していきましょう。
参考文献・参考サイト
- 「Set up a Continuous Deployment Pipeline using AWS CodePipeline」AWS Documentation, https://aws.amazon.com/getting-started/hands-on/continuous-deployment-pipeline/
- 「Elastic Beanstalk deploy action reference」AWS CodePipeline Documentation, https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-Beanstalk.html
- 「AWS Elastic Beanstalk sample for CodeBuild」AWS CodeBuild Documentation, https://docs.aws.amazon.com/codebuild/latest/userguide/sample-elastic-beanstalk.html
- 「How to migrate your AWS CodeCommit repository to another Git provider」AWS DevOps & Developer Productivity Blog, 2024年9月24日, https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/
- Vaibhavi Hole「End-to-End CI/CD with AWS: How to Use CodePipeline, CodeBuild, and Elastic Beanstalk」Medium, 2024年11月22日, https://medium.com/@Vaibhavihole31/end-to-end-ci-cd-with-aws-how-to-use-codepipeline-codebuild-and-elastic-beanstalk-bb6fb507a0e7
- Ben Tran「Setup Continuous Deployment Pipeline For AWS Elastic Beanstalk」Medium, 2024年6月13日, https://bentranz.medium.com/setup-continuous-deployment-pipeline-for-aws-elastic-beanstalk-5f8edb38d872