[レポート]AWS Elastic Beanstalk, AWS OpsWorks, AWS CodeDeploy, AWS CloudFormation を使った自動デプロイ #AWSSummit

AWS Summit Tokyo 2015のTA-05: Tech Deep Dive by Amazon:「AWS Elastic Beanstalk, AWS OpsWorks, AWS CodeDeploy, AWS CloudFormation を使った自動デプロイ」のレポートです。

スピーカーはAmazon Data Services Japanの舟崎健治氏です。

レポート

Introduction

多くのシステムの場合、EC2/ELB/RDS/S3の4つを組み合わせて構築する Webアーキテクチャ 一方で、デプロイの自動化まで考えられているシステムはまだ多くない デプロイの自動化がなぜ必要なのか？はこのセッションの対象としない 本セッションでは、どうやってデプロイを自動化するか？を紹介する Elastic Beanstalk、OpsWorks、CodeDeploy、CluodFormation デプロイのフェーズとAWS提供サービスの関係性 Code = CodeCommit Build - Test = CodePipeline Deploy = CodeDeploy Provision = CloudFormation Monitor = CloudWatch Deploy - Provision - Monitor = Beanstalk, OpsWorks

4つのサービス

AWS Elastic Beanstalk

定番構成の構築、アプリケーションデプロイの自動化サービス 定番構成(=ELB,EC2,RDS)を簡単に構築出来る 必要なミドルウェアがインストールされた状態で起動する 環境構築が自動化、あとは作成したコードをデプロイするだけでシステムが動く

AWS OpsWorks

多様なアーキテクチャに対応したデプロイ・管理サービス スタックという塊の中にLBレイヤー、Webレイヤー、DBレイヤーのような形でレイヤーを複数配置する レイヤーを構築する手順をChefレシピで設定 レシピを実行するタイミングをライフサイクルとして管理

AWS CodeDeploy

アプリケーションデプロイに特化したサービス EC2にエージェントをインストールする エージェントは定期的にコードを確認し、最新のコードをデプロイ StagingとProvisionなど、Tagでグループ分けが出来る。 一回のデプロイで適用する対象を指定出来る。

AWS CloudFormation

JSONで定義したテンプレートを元にクラウドをオーケストレーションするサービス OSの設定を細かく指定することが出来る

各種サービスのデプロイの違いを構築の流れの中で説明

構成イメージ→ELB、EC2、 RDS。静的ファイルはS3。Githubをコードリポジトリとして利用。 注意事項→デプロイサービスのベストはない。要件によって変わる。その選択をしてもらうためのセッションです。

AWS Elastic Beanstalk

プロビジョニング→Environmentを作るとEC2インスタンスが起動する デプロイ→GithubのリポジトリからAppをダウンロード、Zip or Warファイルにしてアップロードする Gitのアーカイブコマンドでzipアーカイブファイルが作れる 以前はgit aws pushが使えたが今はeb deployで行う アップロードしたファイルはS3にも配置される 順次バッチ処理でのデプロイ 一度に全部、一度に一台ずつ、一度に全体の25%ずつ、などの調整が可能 BlueとGreenでEnvironmentを丸ごと別に作るとELBのpre-warmingなど面倒臭いこともある 順次バッチでEC2インスタンスを徐々に最新バージョンにデプロイすることでELBはそのまま使える 環境のカスタマイズ Configuration File→動作中のコンテナのカスタマイズが出来る Rolling Update→EC2インスタンスの置き換えが伴う作業を一部ずつ実行できる →今動いているEC2インスタンスへの変更ではなく、EC2インスタンスの置き換え →Auto Scalingグループに入っているEC2インスタンスへの捜査 →内部的にはCloudFormation Templateを使用

AWS OpsWorks

レイヤーを作成→EC2インスタンスを追加→EC2インスタンスを起動 →OpsWorksエージェントがインストール →エージェントがChefレシピを実行 →アプリケーションをダウンロードして展開 OpsWorksエージェントが定期的にレシピをpollingしている デプロイJSONを使って構成情報を取得出来る→JSONデータをChefレシピから取得 OpsWorksのライフサイクルイベント setup,configure,deploy,undeploy,shutdown ライフサイクルイベントによる自動デプロイ 環境のカスタマイズ githubなどにchefのレシピを入れておき、レシピを書き換えてメンテナンスする

AWS CodeDeploy

デプロイに特化したサービス、EC2インスタンスのプロビジョニング機能は無い EC2インスタンスにCodeDeployエージェントをインストール EC2インスタンスにタグ付け Deployment Groupにデプロイ→CodeDeployエージェントがpolling どれをデプロイするか(Revision) どうやってデプロイするか(Deployment Configuration) どこにデプロイするか(Deployment Group) AWS CloudFormationとCodeDeployの連携 プロビジョニングをCloudFormationで、デプロイをCodeDeployで行う

AWS CloudFormation

プロビジョニングにフォーカスしたサービス、だが、 Templateの中で、EC2インスタンスのデプロイまで定義可能 継続的なデプロイを行う場合には他のデプロイサービスを使うほうが便利 環境のカスタマイズ→Update Stack(更新)が可能

各種サービスの機能比較

CodeDeployにはプロビジョニングがない CloudFormationのデプロイはcfn-initで実行、継続的というより最初の一回で実行 環境のカスタマイズはそれぞれ可能

まとめ

デプロイ&マネージメントサービスを活用することで簡単にデプロイ可能 サービスによって手順が違うので、サービスに合わせて最適なものを選択し活用してほしい

さいごに

使い分け、というのはまさにその通りだと思います。弊社ではCloudFormationを活用することが多くありますが、CodeDeployと組み合わせて使うのは良いですね。