AWSのCI/CDサービスを 試してみた！

CI/CD？

Continuous Integration? Deploy Commit Build Test Continuous Integration (継続的インテグレーション) ・ビルドやテストを頻繁に行い、ソフトウェアの 品質を高める ・問題を早期発見し、リリースまでの時間を短縮 する

Continuous Delivery? Continuous Delivery (継続的デリバリー) ・リリースプロセス全体を自動化 ・継続的インテグレーション(CI)を拡張した手法 Deploy Commit Build Test

+Continus Deployment (継続的デプロイメント) ・デプロイが明示的な承認なしで自動的に行われ る(Continus Deliveryとの違い) Deploy Commit Build Test Continuous Deployment

今回試すAWSサービス とその位置づけ

Code Commit AWS Code Build Test Deploy Code Build Code Pipeline Code Deploy 3rd party Github Bitbucket TravisCI CircleCI Jenkins

Build Test Deploy Code Build Code Pipeline Code Deploy TravisCI CircleCI Jenkins Code Commit Github Bitbucket Code AWS 3rd party

Code Deploy Deploy Code Commit Code Code Pipeline Github Bitbucket Code Build Saasサービス (サーバー必要無) TravisCI CircleCI Jenkins サーバー インストール型 Build Test AWS 3rd party

Code Build Build Test Code Commit Code Code Pipeline Github Bitbucket TravisCI CircleCI Jenkins Code Deploy Deploy AWS 3rd party

Bitbucket TravisCI CircleCI Code Pipeline AWS 3rd party Jenkins Code Build Test Deploy Code Commit Code Build Code Deploy Github CodePipelineは、各サービスを選 択・手順化する(詳しくは後述)

試してみる (CodePipelineの作成)

CodePipeline 承認 ソース ビルド テスト デプロイ 呼び出し の構成検討 Github CodeBuild Jenkins solano ci CodeBuild Device Form ghost-inspector Jenkins etc.. ECS CloudFormation CodeDeploy Elastic Beanstalk CodeCommit Lambda S3

S3 CodePipeline の構成検討 Github CodeBuild Jenkins solano ci CodeBuild Device Form ghost-inspector Jenkins etc.. ECS CloudFormation CodeDeploy Elastic Beanstalk CodeCommit Lambda 承認 ソース ビルド テスト デプロイ 呼び出し CodePipelineには6つのアク ションがある

S3 CodePipeline の構成 Github CodeBuild Jenkins solano ci CodeBuild Device Form ghost-inspector Jenkins etc.. ECS CloudFormation CodeDeploy Elastic Beanstalk CodeCommit Lambda 承認 ソース ビルド テスト デプロイ 呼び出し ソース テスト ビルド 承認 アクションを選択して、 手順(パイプライン)を作成する デプロイ

CodePipeline 承認 ビルド テスト デプロイ 呼び出し の構成検討 CodeBuild Jenkins solano ci CodeBuild Device Form ghost-inspector Jenkins etc.. ECS CloudFormation CodeDeploy Elastic Beanstalk Lambda ソース Github CodeCommit 各アクションに対して 様々なサービスを設定(連携)可能 S3

CodePipeline 承認 ソース テスト デプロイ 呼び出し の構成検討 Github CodeBuild Device Form ghost-inspector Jenkins etc.. ECS CloudFormation CodeDeploy Elastic Beanstalk CodeCommit Lambda S3 CodeBuild Jenkins solano ci ビルド 各アクションに対して 様々なサービスを設定(連携)可能

S3 CodeCommit CodePipeline 承認 呼び出し の構成 CodeBuild CodeBuild Device Form ECS CloudFormation CodeDeploy Elastic Beanstalk Lambda ソース Github Jenkins solano ci ghost-inspector etc.. ビルド テスト デプロイ Jenkins アクションによっては、 サードパーティ製のツールも組み込み可能

CodePipeline 承認 ソース ビルド テスト デプロイ 呼び出し の構成検討 Github CodeBuild Jenkins solano ci CodeBuild Device Form ghost-inspector Jenkins etc.. ECS CloudFormation CodeDeploy Elastic Beanstalk CodeCommit Lambda S3

S3 CodePipeline ソース ビルド テスト デプロイ 呼び出し の構成検討 Github CodeBuild Jenkins solano ci CodeBuild Device Form ghost-inspector Jenkins etc.. ECS CloudFormation CodeDeploy Elastic Beanstalk CodeCommit Lambda 承認 この後の手順を行うどうかを手動 で選択するプロセス 例えば、デプロイする？ Yes or No? のような感じ

S3 CodePipeline 承認 テスト 呼び出し の構成 Jenkins solano ci CodeBuild Device Form ghost-inspector Jenkins etc.. ECS CloudFormation Elastic Beanstalk CodeCommit Lambda 今回の試す構成 Github CodeBuild CodeDeploy ソース ビルド デプロイ ①Goのサンプルプロジェ クトをcommit＆push ③ビルドを実行して、バイナリへ ④ビルド結果をデプロイ EC2 ②「リポジトリへのpushを検知して CodePiplineのリリース始動

パイプラインを作る前に用意する設定 CodeBuild のプロジェクト作成 (一部) CodeDeploy のアプリケーション作成 (一部) ■ビルドで利用するコンテナの指定 ・AWS CodeBuildで管理されたイメージ ・Dockerイメージ ランタイム：golang:1.10 ■ デプロイグループの設定 ・Auto Scalingグループ ・Amazon EC2インスタンス ・オンプレミスインスタンス タグのキーが「env」で バリューが「qa」のＥＣ２に デプロイする設定にした OS :Ubuntu

ビルド デプロイ ソース Github CodeBuild CodeDeploy 作成後のＣｏｄｅPipeline

ソース 検知する「リポジトリ」と「ブラ ンチ」を設定 アクションの成果物。 「ソース」の場合、Github上のソース。

ビルド 「ソース」出力アーティファクトを 指定 アクションの成果物。 「ビルド」の場合、ビルド結果。 (ymlファイルで指定可能) ＣｏｄｅBuildに登録された プロジェクト名を指定

デプロイ ビルド結果を入力に設定 CodeDeployで設定したプ ロジェクトを指定 CodeDeployで設定した デプロイグループを指定

試してみる (アプリケーションの構成)

アプリケーションの構成 └─script |- start.sh └─ stop.sh codepipeline-demo |- buildspec.yml |- hello.go |- appspec.yml

試すアプリケーションの構成 └─script |- start.sh └─ stop.sh codepipeline-demo |- hello.go |- appspec.yml |- buildspec.yml CodeBuildのテストやビルド手順 を記載した設定ファイル

ビルドする際に実行す るコマンド 出力したいソースや、 ビルド結果を指定 ビルドする前に必要な ライブラリをインストー ルする ビルド前に実行するコマ ンド 環境変数の設定

試すアプリケーションの構成 └─script |- start.sh └─ stop.sh codepipeline-demo |- buildspec.yml |- hello.go |- appspec.yml CodeDeployのデプロイ手順を記 載した設定ファイル

デプロイ前に実行 デプロイ後に実行 デプロイするソース名と デプロイ先を定義

└─script |- start.sh └─ stop.sh 試すアプリケーションの構成 codepipeline-demo |- buildspec.yml |- appspec.yml |- hello.go Goのソースファイル、CodeBuildビル ドしてバイナリへ。 CodeDeployでバイナリをデプロイす る。

試すアプリケーションの構成 codepipeline-demo |- buildspec.yml |- hello.go |- appspec.yml └─ stop.sh └─script |- start.sh デプロイ後にアプリケーションを 起動するスクリプト

試すアプリケーションの構成 codepipeline-demo |- buildspec.yml |- hello.go |- appspec.yml └─ stop.sh └─script |- start.sh デプロイ前にアプリケーションを 停止するスクリプト

Demo

No content

料金

CodePipline ■1 か月あたり 1 つ無料 ■1 つのアクティブなパイプラインにつき 1 か月あたり 1 USD が課金 ⇒ 1か月使わなければ、課金なし！

CodeBuild https://aws.amazon.com/jp/codebuild/pricing/ ■ケース ・インスタンスタイプ build.general1.small(メモリ3G,vCPU2) ・1ヶ月でビルド100回。ビルドに5分かかった場合 ■料金 ビルド時間 = 100回のビルド * 5分 = 500 分 ビルド時間 – 無料枠のビルド時間 = 500(分) – 100(分) = 400(分) ビルドの月額 = 400分 * 0.005 USD = 2USD

CodeDeploy https://aws.amazon.com/jp/codedeploy/pricing/ EC2/LambdaへのCodeDeployは、無料！

従量課金制であることの強み ■他のSaas系のサービスとの差別化 CircleCIやTravisCIはコンテナ単位の課金 https://qiita.com/tomlla/items/5e107578eda573e8d02b (上記のサービスの料金体系) ※CricleCIは、2コンテナ50$(それ以上は、1コンテナ当たり50$) ■利用しないときはお金が発生しない ■大量に利用時は、スケールアウトが可能 1分あたり最低 $0.05 からスタート ビルドリクエストに対して、 コンテナの数が少ないと未処理ビルドリクエストが増える CircleCIやTravisCIは、コンテナ単位の課金

メリット/デメリット

メリット ■自前のサーバーを用意する必要なし(vs Jenkins) ■ビルド毎にランタイムの設定が可能 お互い干渉しない(vs Jenkins) ■AWSのサービスなので、社内申請のハードルが 低い ■従量課金制。使わないとお金がかからない！ ■従量課金制だが、ハードに使っても安いくらいの 料金体系？(私感)

デメリット ■クラウドサービスなので、課金が発生 ■管理画面が見辛い(慣れの問題・・) ■連携できるGitサービスが少ない (現在だと、Github、CodeCommitのみ) ■CodeBuildやCodePipelineにあった、yml の書き方を学ぶひつようがある

試した感想

割とネット上に情報があった ■この手CIツールは乱立しているせいか、そこまで ネット上に記事がないと思っていた ■AWS公式やDevelopers.IOに良い記事があった

■一通り成功するCI手順をymlに落とし込むのに時間 がかかった yml作成に一苦労 ■コンテナで上で実行されるので、環境情報やフォ ルダ構成が自分の環境と同じとは限らない ⇒根気強く「ls」や「pwd」を使って、実行結果を確 認、トラブルシュートしよう ■一回できてしまえば、後は楽なCIライフが待って いる

■依存ライブラリやツールのインストールをコンテ ナ上で、毎回実行することになる ⇒ 実行するコンテナイメージを工夫する等チューニ ングする必要あり CodeBuildの実行時間に不安

結局どれを使う？ ・どれくらいの頻度でCI/CDを行うか？ ・どんなテストやビルドを実現したいか？ それがそのCIツールで実現可能か？ 以下の観点で検討するのが良い

参考情報

・CD(継続的デリバリー) http://cloudbees.techmatrix.jp/devops/cd ・Continuous integration vs. continuous delivery vs. continuous deployment https://www.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd ・ AWS のサービスを活用して CI/CD #akibaaws https://speakerdeck.com/shinjifujimoto/cd-number-akibaaws?slide=10 ・AKIBA.aws で「AWS のサービスを活用して CI/CD」というタイトルで話しました https://dev.classmethod.jp/cloud/aws/aws-service-cicd-in-akibaaws/ ・AWS Black Belt Online Seminar AWS上のJenkins活用方法 https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online- seminar-awsjenkins ・AWS CodeBuild のビルド仕様に関するリファレンス https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-spec-ref.html ・チュートリアルを通してCodeBuildを理解する #reinvent https://dev.classmethod.jp/cloud/aws/understanding-codebuild/ ・ CodePipeline – 特集カテゴリー – https://dev.classmethod.jp/referencecat/aws-codepipeline/

ご静聴ありがとうございました。