AWS CodeBuildを用いた継続的インテグレーション自動化(その2)

【連載】

AWSで実践! 基盤構築・デプロイ自動化

【第11回】AWS CodeBuildを用いた継続的インテグレーション自動化(その2)

[2019/09/05 08:00]川畑 光平 ブックマーク ブックマーク

開発ソフトウェア

前回は、AWSから提供されている「buildspec.yml」の挙動をローカル端末で確認できるCodeBuild Local環境を構築し、環境変数を一元管理するAWS Sysmtes Managerを設定して、buildspec.ymlを作成/検証しました。続く今回は、AWS CodeBuildを設定し、GitHubへのプッシュやプルリクエストに対して、CodeBuildを実行するよう設定します。

事前準備:セキュリティグループの作成

CodeBuild設定の事前準備として、CodeBuildが実行するビルド環境のコンテナイメージに適用するセキュリティグループを「VPC」サービスで作成しておきましょう。ビルドに必要なソフトウエアや、GitHubへソースコードを取得するための任意のアウトバウンド許可設定があれば、特にインバウンド許可は必要ありません。

セキュリティグループの作成

CodeBuildの設定

次に、AWSコンソールメニューから「CodeBuild」サービスを選択し、「プロジェクトの作成」ボタンを押下します。

「プロジェクトの作成」ボタンを押下

CodeBuildの主な設定項目は以下の通りです。

入力箇所 項目 説明
プロジェクトの設定 プロジェクト名 ビルドの単位でプロジェクト名を記載します
ビルドバッジ ビルドバッジはビルドステータスを個別定義・明示化するオプションです。詳細は ビルドバッジサンプル を参照してください
追加設定:タグ AWSサービスで使用するタグの名前と値を入力します
送信元 ソースプロバイダ ソースコードが格納されているプロバイダを提供します。AmazonS3、CodeCommit、Bitbucket、GitHub、GitHub Enterpriseから選択可能です。以降はGitHubを選択した場合の設定要領を記載します
レポジトリ パブリックレポジトリか特定のGitHubアカウントのレポジトリかを選択します。特定のGitHubアカウントは初回OAuth認証により接続します
GitHubレポジトリ GitHubアカウントのレポジトリを選択した場合、プルダウンでレポジトリを指定します
追加設定:Gitクローンの深さ コミットされた最新履歴からのバージョンの数を指定します。最新は「1」で、直前のコミットは「2」といった具合に続きます。全てはFULLです
追加設定:Gitサブモジュール Gitのサブモジュール機能(別の外部プロジェクト)を含む場合、「Gitサブモジュールを使用する」を選択します
プライマリリソースのウェブフックイベント ウェブフック レポジトリへのコードプッシュ時やプルリクエスト実行時にビルドを実行する場合、チェックします。詳細は次節にて詳述します
環境 環境イメージ ビルドを実行するコンテナイメージを指定します。デフォルトではUbuntuが使われます
ランタイム(マネージド型イメージの場合) ビルドコンテナの種別を選択します。Strandardのみ選択が可能です
イメージ(マネージド型イメージの場合) コンテナイメージのバージョンを選択します。2019年6月時点では、1.0もしくは2.0が選択可能です
サービスロール CodeBuildの実行に必要なポリシーをアタッチしたサービスロールを設定します。複数のビルドプロジェクトで関連付けが可能ですが、最大10のビルドプロジェクトまでしか関連付けができないので注意が必要です
追加設定:タイムアウト ビルド処理にかかるタイムアウト時間を設定します。デフォルトは1時間です
追加設定:キュータイムアウト ビルドをキューに入れてからタイムアウトするまでの時間を設定します
追加設定:証明書 GitHub Enterpriseなどで証明書をインストールしている場合にアクセス許可するための証明書を設定します
追加設定:コンピューティング ビルドするコンテナの処理スペックを選択します
追加設定:VPC ビルドコンテナからアクセスするVPCを設定します
追加設定:環境変数 コンテナイメージへ設定したい環境変数を設定します
Buildspec ビルド仕様 ビルド処理仕様としてbuildspec.ymlからコマンドを設定として入力するか選択します
buildspec名 デフォルトではソースコードのルートディレクトリにあるbuildspec.ymlが選択されますが、別の名前や場所を使用している場合に入力します
アーティファクト タイプ ビルド実行時に生成されるアプリケーションを出力する方式を選択します。S3か、コンテナイメージを作成する場合、「なし」を選択します
追加設定:暗号キー アーティファクトを暗号化する場合に使用されるAWS KMSカスタマーマスターキーを指定します
追加設定:キャッシュタイプ アーティファクトをキャッシュする場合に選択します。S3、もしくはローカルが選択可能です
ログ CloudWatch Logs CloudWatch Logsにビルド時の出力ログをアップロードするかどうかを選択します
グループ名 CloudWatch Logsのグループ名を指定します
ストリーム名 CloudWatch Logsのストリーム名を指定します

上記に従って入力した後、「ビルドプロジェクトを作成する」ボタンを押下してください。なお、各項目の設定が必須かどうかはAWS公式サイトの「CodeBuildでビルドプロジェクトを作成する」に掲載されている表を参考にしてください。

プロジェクトの設定

送信元の設定

環境の設定

追加設定(タイムアウト、証明書、VPC)

追加設定(コンピューティングタイプ、環境変数)

Buildspec、アーティファクト

ログの設定

早速ビルドの実行と行きたいところですが、その前にビルド用のコンテナイメージがAWS Systems Manager ParameterStoreへアクセスするための権限設定を追加で実施する必要があります。

AWS Systems Manager Parameter Storeへのアクセス権限の付与

前回設定したAWS Systems Manager Parameter Storeで定義したデータを参照するには、CodeBuildの実行ロールにもアクセス権限を付与しておく必要があります(付与していない場合、実行エラーになります)。前節で作成されるサービスロールに、Systems Managerのアクセス権限を割り当てておきましょう。

AWSコンソールで、「IAM」サービスから「ロール」メニューを選択し、作成したポリシーに対して、以下のように「AmazonSSMFullAccess」のポリシーをアタッチしてください。

「AmazonSSMFullAccess」のポリシーをアタッチする

Buildの実行

アクセス権限の付与が完了したら、早速ビルドを実行してみましょう。「ビルドの開始」ボタンを押下し、buildspec.ymlに記載された各フェーズやログが出力されることを確認します。

各フェーズやログの出力を確認

また、buildspec.ymlに記載した通り、Mavenビルド中に実行したSonarScannerの実行結果も、以前の連載で設定していたSonarQubeServerへ送信されるようになります。Scannerの結果も合わせて確認し、QualityGateをパスしているかどうかチェックしましょう。

Scannerの結果を確認

なお、SonarQubeServerもWebhookにより解析が完了したタイミングで、別の外部サービス(SlackやTrelloなど)へ処理完了通知することも可能です。詳細はSonarQubeの公式サイトにある「Webhooks」や「API/Webhooks」を参照してください。

WebHook設定

ビルドが正常に実行したことを確認したら、次はプルリクエストや特定のブランチに対するプッシュを契機に上記のビルド処理が実行されるよう、CodeBuildやGitHubのWebhookの設定を行います。

今回は以下のように、Git Flowをベースとしたブランチを構成し、赤い吹き出しの箇所でCodeBuildによるビルド処理が実行されるように設定するものとします。

構成するブランチのイメージ

上図に示した構成では、masterブランチをベースにdevelopブランチを作成し、developブランチから、featureブランチを作成しています。Git Flowのブランチモデルに従って、機能開発を各々featureブランチに対して行う想定とし、「feature/*****」となるブランチに対してプッシュが行われたタイミングで、ビルド/テストを実行するように設定します。

これにより、自らの開発対象であるfeatureブランチはもちろんですが、並行して行われるほかのfeatureブランチの変更についても、プルリクエスト(PullRequest:PR)されたdevelopブランチ経由で取り込んで、ビルド/テストが問題なく実行終了するかどうかを確認しながら開発を進めることができるようになります。なお、developブランチに対するPRによるビルド処理は、次回以降に解説します。

引き続き、GitHub上でブランチを作成して、ローカル端末へフェッチしていきます。住所系とメール系の機能を拡充するためのfeature/addressとfeature/emailを作成します。

feature/addressとfeature/emailを作成

ブランチ作成後は、ローカルへフェッチして、ブランチをチェックアウトし、feature/addressブランチへ切り替えましょう。以下はターミナルコマンドなどで実行する例です。

> git fetch
> git checkout -b feature/address origin/feature/address

続いて、住所系機能のベースモジュールを追加で実装しましょう。コミットしてプッシュする前に、CodeBuildで以下の通り、「feature/xxxxxxブランチにプッシュが行われた場合、ビルドを実行する設定」を行います。

それにはまず「CodeBuild」サービスから、「ビルドプロジェクト」メニューを選択し、前節で作成したプロジェクトを選択します。開かれた画面で「ビルドの詳細」タブにある「プライマリソースのウェブフックイベント」の「編集」ボタンを押下します。

ビルドを実行する設定

「送信元」の変更はしませんが、プライマリソースのウェブフックイベントを以下の通り設定します。

  • 「コードの変更がこのレポジトリにプッシュされるたびに再構築する」にチェック
  • 「イベントタイプ」には「プッシュ」を設定
  • 「これらの条件でビルドを開始する」において、「HEAD_REF」オプションに、正規表現「^refs/heads/feature/.*」を設定

「プライマリソースのウェブフックイベント」を設定

上記の手順は、Backend、BFFなどCodeBuildを作成しているプロダクト単位に設定を行います。なお、設定の詳細については、AWS公式サイトの「CodeBuildのGitHubプルリクエストとウェブフックフィルタのサンプル」も適宜参照してください。

設定完了後、GitHubのfeature/addressブランチに対してプッシュした後、CodeBuildが実行されることを確認します。

GitHubのfeature/addressブランチに対してプッシュ

CodeBuildが実行されることを確認

マイクロサービスにおける継続的インテグレーションのまとめ

以上、ここまでの連載で、ECSコンテナ、RDSを使ったSonarQubeServerによる静的チェック環境の構築から、SpringBootを使ったマイクロサービスにおける各種テストコードの実装、GitHubへプッシュされたソースコードに対するCodeBuildを使ったビルド/テスト、SonarScannerによる静的チェック結果の可視化といった一連の継続的インテグレーション自動化の仕組みを解説してきました。

今回は触れていませんが、より上位のオプションとして、SonarQubeServer Developer Editionを使えば、静的チェックの結果をレビューコメントとしてGitHubへ反映することも可能です(なお、ComunityEditionでもGitへ連携するプラグインはありますが、現時点で既に非推奨となっているため、本連載では除外しています)。

SonarQubeServerではALB、ECS、RDSを使用して環境構築することにより、自動バックアップなどの保守性や耐障害性も高まります。また、クラウドをベースとしたCodeBuildでマシンリソースを気にすることなく、静的解析、ビルド/テスト実行を自動化し、迅速に問題検出しながら、複数人での開発をスピーティかつ効率的に進めていくことができます。 マイクロサービスアーキテクチャをベースとしたアプリケーション開発では、そのアジリティを高めるために、こうしたクラウドの利点をフル活用した、継続的インテグレーションの自動化環境が求められます。

ただし、今回、SpringBootをベースとしたWebアプリケーションで実装したSeleiumベースのE2Eテストは、バックエンドのマイクロサービスが起動している必要があるため、ビルド時には実行しないように設定しています。本来であれば、E2Eテストを含め、以下のようなプロセスでプロダクション環境へのリリースを検討します。

  1. バックエンドのマイクロサービスのコンテナイメージのビルド、DockerHubへのプッシュ
  2. マイクロサービスコンテナイメージをプロダクションとほぼ同等のステージング環境へデプロイ
  3. Webアプリケーション(BFF)のE2Eテストとして、Seleniumテストコード実行
  4. Webアプリケーション(BFF)のコンテナイメージのビルド、DockerHubへのプッシュ
  5. Webアプリケーション(BFF)のステージング環境へデプロイ
  6. パフォーマンステストやセキュリティテスト、受入などのその他テスト後の管理者によるリリース承認
  7. ステージング環境でテスト済みのコンテナイメージをリリース用にタグ付け、DockerHubへのプッシュ
  8. プロダクション環境へリリース

次回以降では、AWS CodePipelineを使って、上記をパイプライン的に自動化する仕組みを構築/解説していきます。

著者紹介


川畑 光平(KAWABATA Kohei) - NTTデータ 課長代理

金融機関システム業務アプリケーション開発・システム基盤担当を経て、現在はソフトウェア開発自動化関連の研究開発・推進に従事。

Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなどさまざまな開発プロジェクト支援にも携わる。2019 APN AWS Top Engineers & Ambassadors選出。

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

一覧はこちら

連載目次

もっと知りたい!こちらもオススメ

【連載】Kubernetes入門 [5] Kubernetesのリソースタイプを体系的に学ぶ - Workloads

【連載】Kubernetes入門 [5] Kubernetesのリソースタイプを体系的に学ぶ - Workloads

Workloadsは前回紹介したPod/ReplicaSet/Deploymentなど、Kubernetesを構成する基本的なリソースです。今回は、その他のWorkloadsリソースを紹介します。

関連リンク

この記事に興味を持ったら"いいね!"を Click
Facebook で IT Search+ の人気記事をお届けします

会員登録(無料)

注目の特集/連載
[解説動画] Googleアナリティクス分析&活用講座 - Webサイト改善の正しい考え方
[解説動画] 個人の業務効率化術 - 短時間集中はこうして作る
知りたい! カナコさん 皆で話そうAIのコト
教えてカナコさん! これならわかるAI入門
対話システムをつくろう! Python超入門
Kubernetes入門
AWSで作るクラウドネイティブアプリケーションの基本
PowerShell Core入門
徹底研究! ハイブリッドクラウド
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ
セキュリティアワード特設ページ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

ページの先頭に戻る