CodePipeline で CodeCommit/CodeBuild/CodeDeploy を繋げてデリバリプロセスを自動化してみた #reinvent

こんにちは、藤本です。

AWS re:Invent 2016 で CodeBuild がリリースされました。CodePipeline のビルドプロセスに CodeBuild を置くことができるようになりました。

CodeBuild に関しては以下の記事をご参照ください。

【速報】フルマネージドのビルドサービスCodeBuild爆誕 #reinvent

今回は CodeCommit、CodeBuild、CodeDeploy を CodePipeline で繋げて、デリバリプロセスの自動化を試してみました。

概要

昨今のシステム開発はユーザーの要望をより早く、より多く取り入れることを要求され、リリース頻度が増えてきたことに伴い、デリバリプロセスの自動化がデファクトスタンダードとなってきました。デリバリプロセスにはソースコード管理、ビルド、テスト、デプロイという 4つ主なフェーズがあります。下記は AWS Summit Tokyo 2016 のブレイクアウトセッションの DevOps on AWS: Deep Dive on Continuous Delivery and the AWS Developer Tools のスライドにある 1ページです。

AWS では Developer Tools というサービスのカテゴリで CodeCommit によるソースコード管理、CodeBuild によるコンパイル、ユニットテスト、CodeDeploy によるデプロイができ、それぞれのフェーズを CodePipeline で接続することができ、デリバリプロセスを自動化するサービス群を提供しています。

まだインテグレーションテストや、UI テストは外部サービスを利用することになるかと思います。

試してみた

今回は Django の Webアプリケーションを AWS の Developers Tools を利用して、EC2 インスタンスへデプロイすることを試してみました。

デリバリの流れとしては以下のようになります。

ポイントとしては以下になります。

• CodeCommit リポジトリへのプッシュをトリガとしたデリバリプロセスの開始
• CodeBuild によるユニットテスト
  • ユニットテストの結果によるリリース判断（ユニットテストがNGの場合は中断）
• CodeDeploy によるサーバ群に対するデプロイ

目次

• Step 1 : ソースコードの準備
• Step 2 : CodeCommit のリポジトリ作成
• Step 3 : CodeBuild のビルドプロジェクト作成
• Step 4 : CodeDeploy のアプリケーション作成
• Step 5 : CodePipeline のパイプライン作成
• Step 6 : CodeBuild の設定ファイル作成
• Step 7 : CodeDeploy の設定ファイル作成
• Step 8 : 動作確認（ソースコードのプッシュ）
• Step 9 : 動作確認（テストによるエラー発生時）

環境

• AWSリージョン : us-east-1 (東京リージョンは未リリース)
• Web サーバ
  • OS : Amazon Linux 2016.09
  • Web : Apache httpd（Django と WSGI による連携）
  • Application : Django

Step 1 : ソースコードの準備

Django のアプリケーションを適当に生成。ソースコードは Github にアップしました。

• s-fujimoto / django-fujimoto

Step 2 : CodeCommit のリポジトリ作成

CodeCommit のリポジトリ作成は下記記事をご参照ください。

• CodeCommit入門 – Code三兄弟を知る

Step 3 : CodeBuild のビルドプロジェクト作成

CodeBuild のビルドプロジェクト作成は下記記事をご参照ください。

• チュートリアルを通してCodeBuildを理解する #reinvent

Step 4 : CodeDeploy のアプリケーション作成

CodeDeploy のアプリケーション作成は下記記事をご参照ください。

• [新サービス] AWS CodeDeployを触ってみた #reinvent

Step 5 : CodePipeline のパイプライン作成

CodePipeline のパイプラインを作成し、Step : 2 〜 4 の CodeCommit -> CodeBuild -> CodeDeploy を繋げます。

CodePipeline のページから「Get Started」で作成を開始します。

Name

任意のプロジェクト名を入力します。

Source

利用するソースリポジトリを設定します。

Build

利用するビルドツールを設定します。

Beta（デプロイ）

利用するデプロイツールを設定します。

Service Role

CodePipeline が利用する IAM Role を設定します。

「Create role」から IAM Role を作成します。

Policy は自動生成してくれます。そのまま作成します。

作成した Role が自動で入力されます。

Review

設定内容を確認し、作成を開始します。

以上でパイプラインの作成が開始されます。

作成が完了すると、自動でパイプラインが起動します。

またデフォルトでは CodeDeploy は CodeBuild のアウトプットアーティファクトを利用します。今回、Django アプリケーションはビルドの必要がないため、CodeBuild でアウトプットアーティファクトを生成しません。CodeCommit のアーティファクトを CodeDeploy によってそのままデプロイします。その設定変更が必要です。

CodePipeline の Edit から設定変更します。Source の Output artifacts #1 の名前を事前に確認します。デフォルトの名前は MyApp です。

次に Beta を修正します。Input artifacts #1 に確認した名前（MyApp）を入力します。

Save pipeline changes で設定を保存します。

Step 6 : CodeBuild の設定ファイル作成

CodeBuild の動作を定義する設定ファイルを作成します。CodeBuild の設定ファイルの内容は下記記事をご参照ください。

• チュートリアルを通してCodeBuildを理解する #reinvent

今回は CodeBuild で実施したいことはユニットテスト、必要なファイルのみを抽出するためのパッケージングです。

buildspec.yml

version: 0.1

phases:
  install:
    commands:
      - pip install -r requirements.txt
  build:
    commands:
      - python project/manage.py test app.tests

Step 7 : CodeDeploy の設定ファイル作成

CodeDeploy のデプロイ動作を定義する設定ファイルを作成します。CodeDeploy の設定ファイルの内容は下記記事をご参照ください。

• AWS CodeDeploy の AppSpec を読み解く

今回、CodeDeploy で実施したいことは依存ライブラリのインストール、DocumentRoot へのパッケージの展開、および展開後の Apache の再起動です。

appspec.yml

version: 0.0
os: linux
files:
  - source: project
    destination: /var/lib/project
  - source: requirements.txt
    destination: /tmp
permissions:
  - object: /var/lib/project
    owner: apache
    group: apache
hooks:
  AfterInstall:
    - location: scripts/after_install.sh
      timeout: 60
      runas: root
  ApplicationStart:
    - location: scripts/application_start.sh
      timeout: 10
      runas: root

以上で準備は完了です。今までは色々なサービス、ツールを利用している時は Github、Jenkins、Travis CI など色々なところにログインして設定が必要だったのが AWS だけで完結できるのは嬉しいですね。

Step 8 : 動作確認（ソースコードのプッシュ）

それでは、ソースコードをプッシュして、動作確認してみましょう。

$ git remote -v
origin  https://git-codecommit.us-east-1.amazonaws.com/v1/repos/django-fujimoto (fetch)
origin  https://git-codecommit.us-east-1.amazonaws.com/v1/repos/django-fujimoto (push)

$ git commit -m "django test"
[master 3ac8d5f] django test
 1 file changed, 1 insertion(+)

$ git push origin master
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 307 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote:
To https://git-codecommit.us-east-1.amazonaws.com/v1/repos/django-fujimoto
   829122a..3ac8d5f  master -> master

パイプラインを見てみましょう。

まず、Source がIn Progressとなり、CodeCommit リポジトリから S3 バケットへのソースアーティファクトの格納（デリバリの流れの図の②）を開始します。

しばらくすると、Source がSuccessとなり、Build がIn Progressとなり、ソースアーティファクトのユニットテスト（デリバリの流れの図の④、⑤）を開始します。

②が完了すると、CodePipeline用に作成された S3 バケットにアーティファクトがアップロードされます。

しばらくすると、Build がSuccessとなり、Beta がIn Progressとなり、ソースアーティファクトの EC2インスタンスへのデプロイ（デリバリの流れの図の⑧、⑨）を開始します。

CodeBuild のビルドヒストリーから各フェーズのビルド処理のステータス、および標準出力を確認することができます。

しばらくすると、Beta がSuccessとなり、プッシュしたソースコードが EC2インスタンスへデプロイされます。

ELB へアクセスし、HTTP レスポンスが返ってくるか確認してみましょう。

$ curl http://lb-000000000.us-east-1.elb.amazonaws.com/app/health
{"status": "ok"}

レスポンスが正常に返ってきました。

Step 9 : 動作確認（テストによるエラー発生時）

次に、ユニットテストがエラーになるようにテストコードを書き換え、リポジトリへプッシュします。

$ git diff
diff --git a/project/app/tests.py b/project/app/tests.py
index 6617de1..47b5ff0 100644
--- a/project/app/tests.py
+++ b/project/app/tests.py
@@ -9,4 +9,4 @@ class ViewsTest(TestCase):
     def test_health(self):
         response = self.client.get(reverse('app:health'))
         self.assertEqual(response.status_code, 200)
-        self.assertEqual(response.json()['status'], 'ok')
+        self.assertEqual(response.json()['status'], 'ng')

$ git commit -am "edit test code ng status"
[master 49073b6] edit test code ng status
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git push origin master
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 434 bytes | 0 bytes/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote:
To https://git-codecommit.us-east-1.amazonaws.com/v1/repos/django-fujimoto
   868be36..49073b6  master -> master

しばらくして見ると、Build がFailedになっていることを確認できます。また Beta（デプロイ）は最終実行時間が 2時間前なので、デプロイが実行されていないことがわかります。

まとめ

いかがでしたでしょうか？

AWS の各種サービスとのインテグレーションはさすがで、AWS 利用者であれば、お馴染みの UI でデリバリの自動化ができるのは嬉しいですね。ただ、CodeCommit vs Github、CodeBuild vs Travis CIや、Circle CIを比べた時に機能的に AWS のサービスには物足りなさを感じます。今後の機能追加に期待したいです。