パイプラインの構築(その3)

【連載】

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

【第15回】パイプラインの構築(その3)

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

開発ソフトウェア

本連載では、マイクロサービスアーキテクチャでの継続的デリバリ(CD:Continuous Delivery:CD)を以下のようなパイプラインで実装する方法について、解説を進めています。

本連載で実装を進めている継続的デリバリのパイプライン

前回は、ECSクラスタ上にバックエンドのマイクロサービスアプリケーションのコンテナイメージをデプロイするパイプラインを構築しました。続く今回は、本連載の第9回で実装したE2Eテストを実行するパイプラインを構築します。

E2Eテストとして、Seleniumを使用したテストコードを実行する

  1. CodeBuildがBFFアプリケーションソースプロジェクトにあるbuildspec_e2e.ymlに記載したビルド処理(テスト)を行うコンテナを実行します。
  2. ビルド処理の中で、GitHubからBFFのアプリケーションソースコードをクローンします。
  3. ビルド処理の中で、MavenビルドによりSeleniumを使ったE2Eテストを実行します。E2Eテストでは前回デプロイしたバックエンドアプリケーションの呼び出しを通してテスト実行されます。

E2Eテストとして、Seleniumを使用したテストコードを実行する

E2Eテストを実行するbuildspec.ymlの実装

今回作成するパイプラインは、前回のコンテナビルド時と同様、CodeBuildを起動してE2Eテストを実行します。CodeBuildで使用されているデフォルトのUbuntuをベースとしたビルド用コンテナイメージには、ChromeDriverがインストールされているので、それをそのまま利用します。

下記のようなディレクトリ構成で、E2Eテストを実行するbuildspec_e2e.ymlを作成しましょう。

[project-root]

├-[backend-for-frontend]
│ ├- src
│ │ ├- main …..
│ │ └- test …..
│ ├- build
│ │ ├- staging
│ │ | ├- buildspec_e2e.yml
│ │ │ └- buildspec.yml
│ │ …..
│ └- pom.xml
│ …..
└- pom.xml

作成する「buildspec_e2e.yml」は、以下の通りです。

version: 0.2
env:
  parameter-store:
    SERVICE_DNS: "SERVICE_DNS_STAGING"                                       # ...(A)
phases:
  install:
    runtime-versions:
      docker: 18                                                             # ...(B)
    commands:
      - apt-get update -y
      - apt-get -y install language-pack-ja-base language-pack-ja
  pre_build:
    commands:
      - /usr/sbin/update-locale LANG=ja_JP.UTF-8 LANGUAGE="ja_JP:ja"
      - export LC_ALL="ja_JP.UTF-8"
      - locale-gen ja_JP.UTF-8
      - dpkg-reconfigure locales                                             # ...(C)
  build:
    commands:
      - mvn -f common/pom.xml install                                        # ...(D)
      - mvn -P e2e-test -f backend-for-frontend/pom.xml test -Dspring.profiles.active="dev"
                                                                             # ...(E)
      - export ARTIFACT_FILENAME="test-evidence-"`date "+%Y%m%d_%H%M%S"`.zip # ...(F)
      - zip -r $ARTIFACT_FILENAME backend-for-frontend/test-evidence         # ...(G)
artifacts:
  files:
    - $ARTIFACT_FILENAME                                                     # ...(H)
項番 説明
A AWS Systems Manager Parameter Storeで設定したデータを環境変数に設定します。ダブルクォーテーションで囲まれた値がParameter Storeで定義した名称です。ここでは、ParamterStoreを通して、"SERVICE_DNS_STAGING"にアクセスするバックエンドサービスをパスルーティングするALBのDNSが設定されることになります
B Ubuntu Standard Image 2.0 以降を使用する場合は、buildspecファイルで「runtime-versions」を指定する必要があります。詳細については、「buildspecファイルのランタイムバージョンの指定」を参照してください
C コンテナイメージのデフォルトロケールをja_JPに変更します。ロケールがデフォルトのen_USだと、テスト実行時にSpringのMessageSourceで英語メッセージプロパティを選択し、テストケースによってはエラーとなるものがでてきます
D アプリケーションは共通ライブラリに依存しているため、ライブラリをビルドして.m2/配下にインストールするようにします
E Mavenプロファイル「e2e-test」を指定して、ゴールを"test"に設定して、Mavenビルドによるテストを実行します。プロファイルではE2Eテストにカテゴライズされたテスト(@Categoryアノテーションに特定のインタフェースが指定されたテストクラス)が実行されるよう、pom.xmlに設定してあります
F テスト実行結果をアーカイブ化するファイル名をタイムスタンプを使って環境変数として定義します
G テスト実行結果をZIPアーカイブ化します
H 作成したアーティファクト名を指定します。アーティファクトはS3へ転送されます

E2Eテストを実行するパイプラインの設定

パイプラインの設定に入る前に、E2Eテスト用のCodeBuildプロジェクトを作成します。第11回で説明したのと同じ要領で、CodeBuildサービスから「ビルドプロジェクトを作成する」ボタンを押下して、新規のCodeBuildプロジェクトを作成してください。ただし、設定の際は、以下の項目に留意が必要です。

入力箇所 項目 説明
プライマリリソースのウェブフックイベント ウェブフック レポジトリへのコードプッシュ時やプルリクエスト実行時にビルドを実行する場合チェックします。パイプラインから起動されるため、ここではチェックしません
環境 特権付与 dockerコマンドなどを実行する場合、チェックが必要です。今回のE2Eテストではチェックは不要です
サービスロール CodeBuildの実行に必要なポリシーをアタッチしたサービスロールを設定します。複数のビルドプロジェクトで関連付けが可能ですが、最大10のビルドプロジェクトまでしか関連付けができないので注意が必要です。なお、サービスロールを新規作成する場合は作成後にSystemsManagerのアクセス権限を付与します
追加設定:VPC バックエンドサービス向けのALBのセキュリティグループ設定によりますが、アクセスが許可されたVPCを設定します
追加設定:サブネット バックエンドサービス向けのALBのセキュリティグループ設定によりますが、アクセスが許可されたサブネットを設定します
追加設定:環境変数 コンテナイメージへ設定したい環境変数を設定します。作成したBFFアプリケーションのプロジェクトではテスト用の application.yml にChromeDriverのパスを示す環境変数CHROME_DRIVER_PATHを必要としています。CodeBuildのデフォルトのコンテナイメージのドライバーのパスは/usr/bin/chromedriverにあるので環境変数として設定してください
Buildspec buildspec名 デフォルトではソースコードのルートディレクトリにあるbuildspec.ymlが選択されますが、別の名前や場所を使用している場合に入力します。ここでは、前節で作成した「backend-for-frontend/build/staging/buildspec_e2e.yml」を指定します
アーティファクト タイプ ビルド実行時に生成されるアプリケーションを出力する方式を選択します。今回テスト証跡をS3へ出力するものとします
バケット名 アーティファクトを出力するバケット名を設定します
名前 必要に応じてアーティファクト名称を設定します
セマンティックバージョンの有効化 buildspec.ymlで指定されたアーティファクト名を使用する場合にチェックします
パス アーティファクトを出力するバケット内のフォルダを設定します
名前空間のタイプ アーティファクトの出力でビルドIDでディレクトリを作成する場合に設定します
アーティファクトのパッケージ化 アーティファクトをZIP圧縮する場合に設定します。今回はbuildspec.yml内で圧縮処理をかけているので設定不要です
アーティファクトの暗号化の解除 アーティファクトを暗号化して送信する場合、出力時に暗号化を解除するか設定します

CodeBuildの実行に必要なポリシーをアタッチしたサービスロールを設定

コンテナイメージへ設定したい環境変数を設定

アーティファクトの設定

プロジェクトを作成したら、CodeBuildからSystemsManagerParameterStoreに環境変数のアクセスができるよう、サービスロールに権限を付与しておきます。

サービスロールに権限を付与

続いて、E2Eテストを実行するパイプラインを作成します。

CodePipelineサービス・メニューで、これまで作成してきたパイプラインを選択して「編集する」ボタンを押下し、末端の「ステージを追加する」ボタンを選択します。

パイプラインの作成

任意のステージ名を入力します。

任意のステージ名を入力

ステージが作成されたら、「アクションを追加する」ボタンを押下し、以下の要領でアクションを設定し、「完了」ボタンを押下します。

  • アクション名:任意のアクション名を追加します。
  • アクションプロバイダー:「AWS CodeBuild」を選択します。
  • リージョン:ステージング環境があるリージョンを選択します。
  • 入力アーティファクト:1番目のパイプラインで出力アーティファクトとなっている「- SourceArtifact」を選択します。なお、これはGitHubからチェックアウトしたソースコードプロジェクトで実体はS3にZIPアーカイブされて保存されています。
  • プロジェクト名:先ほど作成したプロジェクトを入力します。
  • 出力アーティファクト:出力アーティファクト名を入力します。buildspec.ymlでは、最終的にテストの画面イメージをZIPアーカイブ化して出力しています。

アクションを設定

設定完了後、「変更をリリースする」ボタンを押下し、パイプラインを起動して、E2Eテストが実行されるかどうかを確認します。

E2Eテストの実行を確認

これで、E2Eテスト用のパイプラインが作成されました。今回はCodeBuildから提供されているデフォルトのUbuntuのビルドイメージを使ってChromeでのE2Eテストを実行しましたが、他のブラウザやWindowsOSのテストが必要な場合は、このパイプラインの中で、別のコンテナイメージを使用したテストコンテナを作成し、並行してテストパイプライン処理を構成すると良いでしょう。これは、マシンリソースを気にすることなく、並列でテストを並走可能なのはCodeBuildならではのメリットです。

次回は、BFFアプリケーションのコンテナイメージをビルドしてDockerHubへプッシュするパイプラインを構築します。

著者紹介


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

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

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

本連載の内容に対するご意見・ご質問は Facebook まで。

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

一覧はこちら

連載目次

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

若手CTOが導く! テックカンパニー化に向けたDMM.comのエンジニア評価制度改革

若手CTOが導く! テックカンパニー化に向けたDMM.comのエンジニア評価制度改革

動画配信、オンラインゲームから太陽光発電まで、40以上のさまざまな事業を手がけるDMM.com。同社は昨年、技術志向のテックカンパニーへと変革していくため、「当たり前を作り続ける」というDMM TECH VISIONを公開した。

関連リンク

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

会員登録(無料)

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

一覧はこちら

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

一覧はこちら

ページの先頭に戻る