Amazon Elastic Beanstalkについて勉強
AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
Amazon Elastic Beanstalk
Webアプリケーションの定番構成の構築・WEBアプリケーションデプロイの自動化サービス（定番構成：ELB--複数EC2--RDSのようなよくある構成テンプレートを指す）
プロビジョニング（用意）した環境に対し、ユーザは自分で作成したアプリケーションをアップロードするだけで簡単にでデプロイできる。
- 早く簡単にアプリケーションをデプロイするサービス
- インフラストラクチャの準備＆運営からアプリケーションスタック管理までを自動化できる
- AutoScalingが自動でついてくるのでよりコストを抑えながらスケーラビリティを確保できる
- Java,PHP,RUBY,Python,Node.js,.NET,Docker,Goに対応してWEBアプリケーションを展開できる。
- Apache,Nginx,Passenger,IISなど使い慣れたサーバーがすでにインストールされている
- コードをアップロードすればキャパシティのプロビジョニング、ロードバランシング、AutoScalingからアプリケーションのヘルモニタリングまでデプロイを自動化できる
特徴としては
プロビジョニング＋WEBアプリケーションをデプロイできるのはBeanstalkだけ。
Dockerに対応している
という点。
構成要素
アプリケーションという単位にバージョン・環境設定がコードとして保持。環境にバージョンが展開される。
アプリケーション
トップレベルの論理単位でバージョンや環境や環境設定が含まれている入れ物。このアプリケーション単位で設定していく
バージョン
いわゆるソースコード。Githubにアップロードしたコードを、デプロイ担当者のローカルのダウンロードする。そしてそれをBeanstalkにアップロードする。
アップロードした場合S3にもアップロードされる。（S3上で過去バージョンを管理できる）
異なる環境/バージョンを展開可能。バージョンリポジトリに保持。
環境
各環境（ウェブサーバ/ワーカー）に応じて構築されるインフラ環境。バージョン（ソースコード）をデプロイ。
環境タイプ
大きく二つが存在するAutoScaling構成
「ELB＋AutoScaling」や「SQS＋AutoScaling」といった高い可用性と伸縮自在性を兼ね備えた構成。
WEBアプリケーションのデプロイを何回か実施しなければならないときあなどにそれを容易にすることや、タスク時間の長いワークロードの展開に利用する。
ウェブサーバー環境
「ELB＋AutoScaling」でスケーラブルな構成をコード化して、バージョンとすることで、スケーラブルな同じウェブアプリケーションを実行できる
単一のコンテナのDockerコンテナを実行可能だったり、複数コンテナはECSを利用した環境実行が可能だったりとDockerを使用できるのも特徴。
ホストマネージャがデプロイや監視を自動で実施する。
環境ごとにDNS名称を付与する。
ワーカー環境
SQS＋AutoScalingでスケーラブルなバッチ処理ワークを実現
定期的なタスク実効基盤の作成。毎日深夜1時に動作するバックアップ処理
ワーカーホスト内でWEBアプリケーションを動作させ、ワークロードの時間がかかわる処理を実行させる。
シングルインスタンス構成
EC2の1台構成などが可能。安価で環境構築が可能。
環境設定
その環境に関連するリソースの動作を定義する設定パラメータ。永続データの格納場所はS3やRDSなどの外部サービスを利用
デプロイの選択肢
プロビジョニングした環境へのソースコードのデプロイは以下のように調整が可能
①1度に1台ずつ
②1度に全体の25パーセントずつ
③1度に全部
All at once
複数のプロビジョニングされた環境すべてに対し、バージョンをデプロイする。Rolling
※バッチタイプが固定、バッチサイズが2台の場合。①複数のプロビジョニングされた環境に対し、まずそのうちの2台だけデプロイする。（残りのものはまだデプロイしない）
②その後残りのものもデプロイしていく。
→いったん現行のものを残しておく形。
Rolling with additional batch
※バッチタイプが固定、バッチサイズが2台の場合。①複数のプロビジョニングされた環境とは別に、2台を新規にプロビジョニングしてそこにデプロイする。
②もともとあったプロビジョニングされた環境に対し、その後残りのものもデプロイしていく。
③既定の数未満のものは削除する
Immutable
①複数のプロビジョニングされた環境とは別に、2台を新規にプロビジョニングしてそこにデプロイする。③もともとあったプロビジョニングされた環境の既定の数未満のものは削除する
OPSWorks
ChefまたはPuppetを使用してプリケーションを設定および運用するための設定管理サービス。
インフラ設定を細かく設定してデプロイしたいという場合にはOpsWorksを選択する
種類は3つ。
- OpsWorkスタック
- OpsWorks for Chef Automation
- OpsWorks for Puppet Enterprise
Chefについて
様々形式のインフラへのサーバやアプリケーションの展開を容易にする環境自動化フレームワークRecipe（レシピ）という単位で環境設定を保持して任意のインフラ展開。CloudFormationと似ていえる。
利点は、ChefとPuppetはオープンソースで使用できる機能。使用するには専用のサーバーが必要だが、それをマネージド型で提供するのがOpsWorks。
OpsWorkスタック
スタックとアプリケーションの作成及び管理のための、シンプルで柔軟な方法を提供するAWSのオリジナルサービスChefやPuppetを使用しないものになる。
- スタック/レイヤー/インスタンス/アプリケーションと呼ばれるコンポーネントによりモデル化を実施する
- コードで構成管理やオートスケーリングが可能
- Linux/Windowsサーバをサポート
- ライフサイクルイベントによるタスクの自動化が可能
- OpsWorksえーじぇんとがChef ClientのローカルモードでRecipeを実行する。
- スタックがOpsWorksのトップエンティティである全インスタンスの構成情報をJSON形式で管理している
- AWS OpsWorksスタックではChefサーバーは不要
OpsWorks for Chef Automation
Chefサーバーを作成し、継続デプロイメント及びコンプライアンスチェックのための完全マネージド型サーバーサービス。- Chef Automationとは、ChefのcookbookやRecipeを利用してインフラ管理を自動化するサービス。
- インフラ及びアプリの継続的なデリバリーパイプラインを構成することが可能
- リソースはChefサーバから構成内容のアップデートを取得する
- オペレーション/コンプライアンス/ワークフローイベントを可視化することが可能
- AWSでChefサーバを構築することができ、Chef Automate APIやChef DKなどのツールを利用することができる
OpsWorks for Puppet Enterprise
フルマネージド型Puppetマスターにより、アプリケーションのテスト・展開・運用を自動化する。- Puppetマスターはインフラ内のノードを管理し、ノード情報を保存し、Puppetモジュールの中央リポジトリとして機能する
- PuppetマスターはソフトウェアおよびOSの設定、パッケージのインストール、データベース設定、変更管理、ポリシー適用、モニタリングおよび品質保証などのタスクを処理する全スタックを自動化することができる
- モジュールはインフラストラクチャの設定方法に関する手順が格納されたPuppetコードの再利用及び共有が可能とするユニット
- Puppetを使用して、EC2インスタンスやオンプレミスデバイスにあるノードの設定、デプロイ、管理方法を自動化できる
CloudFormation
EC2やELBなどのAWSリソースの環境構築を、設定ファイル（テンプレート）をもとに自動化できるサービス。CloudFormation単体ではプロビジョニングの未実施する。（デプロイする方法については後述）
特徴
- テンプレートを自由に作成できるため、自分好みのシステム構成を自動的に構築可能
- テンプレートには起動すべきリソースの情報をJSONやYAMLフォーマットのテキスト形式で記述
- 追加料金はなし
- プロビジョニングされたリソースの変更・削除が可能
- クロスリージョンとクロスアカウントで管理（リージョンやアカウントがまたがっていても使用可能）
- 直接サポートされていないリソースや機能を利用する場合、カスタムリソースでスタック作成の一部に独自ロジックを組み込む
- AWSリソースの構築を効率化したい
- 開発・テスト・本番環境で利用するインフラを標準化したい
- 毎回同じリソースやプロビジョニング設定を正確に利用したい
- ソフトウェアと同じように環境攻勢を管理したい
同じ環境を確実に設定したい場合はCloudFormation、環境単位で変えたいみたいな場合はOpsWorksのイメージ。
構成
テンプレート
JSON/YAMLでリソースとパラメータを定義する。
テンプレートの記載の中で必須はResourcesのみ。
- AWSRemplateFormatVersion：テンプレートのバージョン。
- Description：テンプレート自体の説明文。
- Metadata：テンプレートに関する追加情報。
- Parameters：実行時にユーザに入力を求めるパラメータ（KeyPair名称・DB名称など）。リソースを参照する際の関数を記載する。
- Mappings：キーと値のマッピング。複雑な参照関数を持ちたいときに使用する
- Confitions：条件名と条件判断内容。Resourcesセクションなどでリソース作成時に利用。どういったときに咲く際させるのかのような条件を記載
- Transform：サーバレスアプリケーションや定型コンテンツ挿入などのマクロを指定。サーバレスアプリのSAMバージョンを記述
- Resources：AmazonEC2やRDSなど、スタックを構成するリソースとプロパティ。どういうタイプを必要なのかCIDR設定内容など。リソース間の参照関係も記載できる
- Outputs：スタック構成後にCloudFormationから出力させる値（DNS名やEIPの値など）
スタック
AWSリソースの集合を指す。管理単位。
スタック単位でリソースを管理可能。
スタックを削除すると紐づいたリソースも削除される。
リソースの構築順はテンプレートのResourcesに記載した依存関係からCloudFormationが自動で決定する仕組み。
スタックセットを使用することで複数のAWSアカウントと複数のリージョンに対してスタックを作成できる
リソースの作成・変更・削除
作成
テンプレートに定義された構成でスタックを自動作成並列でリソースを作成し、依存関係がある場合は自動解決してくれる
変更
スタックに前回のテンプレートとの差分を適用することで冪等性を担保する（差分チェックがドリフトという機能）リソース変更時は無停止変更・再起動・再作成のいずれかが発生する
Change Set（変更セット）を作ることで差分の内容を事前に確認できる
変更セット：スタックの更新を行うときに、スタックを変更したことによる影響をチェックする機能
ドリフト：テンプレートによって展開したAWSリソースの展開後に何か個別で対応した場合の差分を検出するチェック機能
削除
依存会計を解決しつつ、リソースをすべて削除する。データストアはスナップショットを取得・保持が可能
スタックとリソースの保護
スタックやリソースが誤って変更・削除されないようにするための対応。- CloudFormation自体へのアクセス権限をセットする：IAMポリシー
- スタックの削除保護：スタックの削除保護機能の有効することでスタック自体の削除保護をする。。スタックポリシー（JSONファイル）でスタックの機能別で保護要否を分けられる。
- リソースの削保護：リソースのDeletionPolicyを設定
CloudFormationのスタック間でリソースを参照
Resource import 機能を使用すると、スタック間でリソースを移動、またはリファクタリングできます。
まず、移動するリソースに Retain 削除ポリシーを追加して、ソーススタックからリソースを削除してターゲットスタックにインポートするときにリソースが保持されるようにする必要があります。
スタック間でのリソースの移動 - AWS CloudFormation
