AWS Summit 2015 - Day1 - 自動デプロイ
- Elastic Beanstalk, Opsworks, CodeDeploy, CloudFormation
AWS 舟崎さん
どう使い分けたらいいか、どう組み合わせるか
Intro
- EC2 / ELB / RDS / S3 を組み合わせる事が非常に多い
設計としては多いが、デプロイを自動化する点まで考えられていることは少ない
- デプロイの自動化がなぜ必要か、はこのセッションの対象ではない。その前提で話す。
デプロイを考える際のフェーズ
- コーディング
- ビルド
- テスト
- デプロイ
- プロビジョン(リソース生成)
- モニタリング
Code Commit
Code Pipeline
- コードをデプロイする際の処理・ワークフローを自動化させる
- まだAWSとしてリリースされてない
Elastic Beanstalk / OpsWorks
- Deploy / Provision / Monitor
- Code Deploy
- Deploy のみ
- CloudFormation
- Provisionのみ
- Cloud Watch
- 監視
Elastic Beanstalk
- 定番構成の構築・アプリデプロイの自動化サービス
Opsworks
- 多様なアーキテクチャをサポートするデプロイ・管理サービス
- chefのレシピを使ってデプロイや運用タスクを自動化可能
- ライフサイクルイベントに従った動的な構成の変更
- 継続的な構成管理
Code Deploy
- アプリケーションのデプロイに特化
- agentをインストールして管理。オンプレミスも管理可能
- グループ内に一度にデプロイしたり1台ずつデプロイしたり、といった処理が可能
CloudFormation
Wordpressをデプロイする手法
wordpressのデプロイを題材に、4つのサービスを比較
- コンフィグも自動生成したり。
構成イメージ
どれがベストか、という話をするわけではない。
- 自分達の要件に合うかを検討する材料にしてください。
Beanstalk
起動の流れ
- ElasticBeanstalkがインスタンスを起動
- 中にHost Managerが入っていて、それが通信
GitHubと連携
- 順次バッチ処理でのデプロイ
- 一度に(1台/25%/全部)にデプロイ
- というのを調整できる
- Blue Green Deploy なんかもあり(今回は違う)
- 一度に(1台/25%/全部)にデプロイ
- 環境のカスタマイズ
- AMIを作りなおさなくても、Elastic Beanstalk Configuration fileで動作中のコンテナをカスタマイズできる
- 環境設定のRolling Update
- インスタンスの置換えを伴う操作を一部ずつ実行
- 裏ではCloudFormationのupdate policyという機能で実現してる
OpsWorks
起動の流れ
OpsWorksに指示を出すと、Agentがポーリングに合わせてAppを取得
- デプロイJSON を書いておけば、それをchefのレシピの中から呼び出せる
レシピの実行タイミングについて
Cookbookの更新
- リポジトリにPush
- カスタムCookbookの適用を指示
- ポーリングのタイミングで適用される
Code Deploy
サーバは起動しないので、自分でエージェントを入れる
- 入れたら、グループにインスタンスを追加
Depoyの流れ
- 環境のカスタマイズ
- appspec.ymlのなかに、hooksを設定できる
- shellscriptの実行が可能
- CloudFormation都の連携
CloudFormation
- CloudFormation template(JSON)の中にプロビジョニングとデプロイの内容を書いておく
- 頻繁にデプロイしないのであれば、CloudFormationでやってしまうのがいい
- 頻繁にやるなら、プロビジョニングだけを担当させる方がいい
まとめ
- それぞれ簡単にできるが、手順が異なる
- 要件に合わせて活用してください