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

AWS Summit Tokyo 2015
109件のシェア(ちょっぴり話題の記事)

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

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

IMG_1886

レポート

Introduction

 多くのシステムの場合、EC2/ELB/RDS/S3の4つを組み合わせて構築する
  Webアーキテクチャ
 一方で、デプロイの自動化まで考えられているシステムはまだ多くない
  デプロイの自動化がなぜ必要なのか?はこのセッションの対象としない
 本セッションでは、どうやってデプロイを自動化するか?を紹介する
  Elastic BeanstalkOpsWorksCodeDeployCluodFormation
 デプロイのフェーズと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と組み合わせて使うのは良いですね。

AWS Cloud Roadshow 2017 福岡