[レポート]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と組み合わせて使うのは良いですね。