AWSでDockerを扱うサービスである、ECS（Elastic Container Service）のクラスターの目的と作成方法について。
##目次
- ECSのクラスターとは？
- クラスターを使ったサービスの流れ
- クラスターの作成
- ECSのクラスターテンプレートの選択
-
クラスターの設定
5. クラスター名（必須）
6. ネットワーキング（任意）
7. Tags（任意）
8. CloudWatch Container Insights（任意） -
サービスの作成
10. サービスを作成するクラスターの選択
11. 起動タイプの選択
12. タスク定義
13. サービス名
14. サービスタイプとは？
15. タスクの数
16. 最小ヘルス率と最大率
17. Blue/Greenデプロイタイプの場合
18. Deployment circuit breaker -
デプロイメントの設定
20. Blue/Green
21. ローリングアップデート
22. Deployment configuration
23. CodeDeployのサービスロール -
ネットワーク構成
24. VPCグループの設定
26. ロードバランサーの設定
27. ロードバランス用のコンテナを設定
28. ヘルスチェックパスの設定
29. ２つめのターゲットグループの作成
30. Auto Scaling - サービスの作成
- ELB（ロードバランサー）の修正
- ページの表示
##ECSのクラスターとは？ AWSの説明では、タスクリクエストを実行できる１つ以上のコンテナインスタンスのリージョングループ。
実用例だと、一つのプロジェクトに対し、一つのクラスターを作り、中にサービスとして、ステージング環境や開発環境をいれる。
各サービスの中にはタスクを作って、タスクの中で必要なコンテナを定義している。
**▼クラスター、サービス、タスク、コンテナの関係** 
ECSでクラスターを作成する場合は、単にクラスターを作成するだけでなく、サービスの作成、ロードバランサーの設定、デプロイ方法の指定も行う。
##クラスターを使ったサービスの流れ 複数のサービスを一つのロードバランサーで切り分ける場合のAWSの設定方法について。
###・サービスの構造
クラスターはプロジェクトを管理しやすくするためのグループといった位置付け。
その中にproductionやstagingといったサービスを作成する。
実際のサービスの根幹となるコンテナはタスクの中に定義する。このタスクをサービスの上に乗っける。
###・ネットワーキングの構造
ユーザーがFQDN（sub.example.com）を入力すると、該当するエイリアスコードからホストドメインにつなげる。
ホストドメインにはロードバランサーが設定されており、渡されたFQDNに結び付けられたコンテナにトラフィックを送る。
コンテナはリクエストに応じて、DBなど必要な別のコンテナと連携してレスポンスを返す。
###クラスターの作成
##1. ECSのクラスターテンプレートの選択
どの仮想サーバーでコンテナを起動するか選択する。
| タイプ | 内容 |
|---|---|
| ネットワーキングのみ | Fargate起動タイプを使用してタスクを実行する |
| EC2 Linux + ネットワーク | Linux コンテナを使用した EC2 起動タイプを使用してタスクのクラスターを起動する |
| EC2 Windows + ネットワーク | EC2 起動タイプと Windows コンテナを使用してタスクのクラスターを起動する |
Fargateは運用管理をAWSが行ってくれるメンテ・保守不要のサーバー（サーバーレス）
##2. クラスターの設定
サービスを起動するためのクラスターを作成する。クラスター自体の作成は超簡単。
###2-1. クラスター名（必須）
最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できる。
###2-2. ネットワーキング（任意） クラスター用に新しいVPC（Virtual Private Cloudの略。 仮想プライベートクラウド）を作成する場合はチェックを入れる。
**▼作成する場合** クラスター専用のVPCを作成する場合は、CIDRブロック、サブネットを設定（デフォルトでも可）する。
###2-3. Tags（任意） クラスターの説明をKV（key-value）形式で記載できる。
クラスタ作成後にTagsタブから確認できる。
###2-4. CloudWatch Container Insights（任意） チェックマークを入れるとCloudWatchと連携して、CPUやメモリの使用状況のログが確認できるようになる。
**▼ECSクラスターのCloudWatch例**
###2-5. クラスターの作成
右下の「作成」ボタンをクリックしてクラスターを作成する。
以上でクラスターの作成は完了。
##3. サービスの作成 作成したクラスターの中にサービスを作成していく。
サービスを作成するにはECSのタスク定義で、コンテナの起動時の設定が完了している必要がある。
###3-1. サービスを作成するクラスターの選択
作成したクラスターを選択する。
サービスタブの中で、左下の「作成」ボタンをクリックする。
###3-2. 起動タイプの選択
タスクを実行する仮想サーバ−の種類を選択する。選択しない場合はEC2がデフォルトとなる。
 |
|---|
###3-3. タスク定義
ECSのタスク定義で作成した項目を選択する。
タスク定義を内容を変更して複数作った場合は、使用する番号（リビジョン）を選択する。
 |
|---|
▼ECSのタスク定義
###3-4. サービス名 作成するサービスにつける名前を指定する。 クラスターを選択した時に、表示されるためわかりやすい名前にする。
 |
|---|
↓ 表示例
▼Point
クラスターの名前でどのプロジェクトかは判定可能なため、サービスの名前は各サービスの環境の名前をつけるとわかりやすい。
・クラスター名： test-app
・サービス名１： production
・サービス名2: staging
###3-5. サービスタイプとは？ **タスクが失敗したときの対応方法**を指定する。スケジュール戦略と呼ばれる。
サービスタイプ（スケジュール戦略）は①REPLICA戦略と②DAEMON戦略の２つがある。
Fagateを選択した場合は、REPLICA戦略のみとなる。（DAEMONはサポート外）
・REPLICA戦略
クラスター全体で必要数のタスクを配置して維持。
・DAEMON戦略
指定したすべてのタスク配置制約を満たすクラスター内のアクティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイ。
###3-6. タスクの数 サービスタイプがレプリカの時のみ選択する。
上で指定したタスク定義で起動したインスタンス（コンテナ）のうち、クラスターで実行状態を保つ数を指定する。
起動するコンテナが１つのみの場合は１となる。複数のコンテナを起動し、起動状態を保ち続ける場合は、その数を記載する。
なお、デーモンの場合は、クラスターのコンテナインスタンス数に自動的に設定。
###3-7. 最小ヘルス率と最大率 ローリングアップデートのみ選択可能なオプション。
実行中のサービスをローリング更新するときに、サービスが維持するタスクの数を割合で指定する。
####最小ヘルス率とは？
RUNNING状態に保つ必要のあるサービスのタスクの下限数を％で指定したもの。
例えば必要なタスクが４つのサービスで、最小ヘルス率を50％とした場合、スケジューラーが新しいタスクを実行する時に、２つのタスクを停止して、クラスターの容量を開放する。
最小ヘルス率はデフォルトで100％。
####最大率
最大ヘルス率の略。RUNNINGまたはPENDING状態で使用できるサービスタスクの上限数を指定できる。
例えば必要なタスクが４つのサービスで、最大率が200%の場合、スケジューラは4つの古いタスクを停止する前に、4つの新しいタスクを開始することができる。
最大ヘルス率のデフォルト値は 200% です。
####Blue/Greenデプロイタイプの場合
実行中のサービスの更新がBlue/Green (CODE_DEPLOY) の場合は、最小ヘルス率・最大ヘルス率の値はデフォルト値に設定される。
最小ヘルス率： 100%
最大ヘルス率： 200%
つまり、本番環境のサービスを改修してローンチするときに、既存のタスクは停止せず起動したままの状態で、新しいサービスを起動する。
この方法であれば、新しいサービスに問題があった場合にすぐに古いサービスに戻すことができる。容量は使うが安全な更新。
###3-8. Deployment circuit breaker ローリングアップデートのみ選択可能なオプション。
サービスの更新に失敗した場合に、自動で昔の正常だったサービスに戻してくれる便利機能。
 |
|---|
＞https://aws.amazon.com/jp/blogs/news/announcing-amazon-ecs-deployment-circuit-breaker-jp/
Blue/Greenの場合は自動的にRollbackしてくれるため設定不要。
というか、ローリングアップデートの設定で、デフォルトの最小ヘルス率： 100%、最大ヘルス率： 200%、Deployment circuit breakerが有効でrollbackがオンになっているデプロイをBlue/Greenと呼ぶ。
##4. デプロイメントの設定 サービスを更新したときに、新しいサービスの起動方法を指定する。
###4-1. Blue/Green
ブルー・グリーンと呼ぶ。直近では主流のデプロイ方法。
サービスの更新を安全に行うために、既存のサーバーに手を加えるのではなく、既存のサーバーはそのまま維持しながら、新しいサーバーを起動するデプロイ方法。
新旧のサービスで状態を比較し、異常があればエラーとして報告してくれる。
また、新しいサービスが起動しない場合は、自動で旧のサービスに戻るため、サービスが落ちる心配がない。
Blueが古いサービス、Greenが新しいサービスを指している。
###4-2. ローリングアップデート
実行中のタスクを順々に停止して、順々に新しいサービスに切り替えていくデプロイ方法。
Blue/Greenよりも簡易的でスピーディな更新方法。
ただし、どれかのタスク更新で失敗した場合、更新済みのタスクと更新エラーのタスクが混在することになり、元に戻すのに手間がかかる。（このため、現在のトレンドはBlue/Green）
Deployment circuit breakerなど、より安全にサービスを更新する仕組みが用意されている。
ローリングアップデートの設定で、デフォルトの最小ヘルス率： 100%、最大ヘルス率： 200%、Deployment circuit breakerが有効でrollbackがオンになっているデプロイがBlue/Green。
###4-3. Deployment configuration デプロイ中にCodePlayが使用する条件を選択する。
旧サービスにアクセスしているトラフィックの何％ずつを新しいサービスに移行させるかの、％と経過時間を指定できる。
| 設定 | 内容 |
|---|---|
| CodeDeployDefault.ECSAllAtOnce | すべてのトラフィックを、新しいコンテナに一度に移行。 |
| CodeDeployDefault.ECSLinear10PercentEvery1Minutes | すべてのトラフィックが移行されるまで、1分ごとに10%を移行 |
| CodeDeployDefault.ECSLinear10PercentEvery3Minutes | すべてのトラフィックが移行されるまで、3分ごとに10%を移行 |
| CodeDeployDefault.ECSCanary10Percent5Minutes | |
| 最初にトラフィックの10%を移行。残りの90%は5分後にデプロイ | |
| CodeDeployDefault.ECSCanary10Percent15Minutes | 最初にトラフィックの10%を移行。残りの90%は15分後にデプロイ |
基本的にはCodeDeployDefault.ECSAllAtOnceを選択。
###4-4. CodeDeployのサービスロール CodeDeployがBlue/Greenで自動更新する際に、ユーザーに変わってAWSに許可を与えるためのIAMロール。
CodeDeploy IAMロール（ecsCodeDeployRole）として設定する。
＞https://docs.aws.amazon.com/AmazonECS/latest/developerguide/codedeploy_IAM_role.html
##5. ネットワーク構成 ###5-1. VPCグループの設定 タスク定義のネットワークグループがAWS VPCの場合に設定可能。
タスク定義のプラットフォームにFagateを選択している場合は、AWS VPCのため設定できる。
 |
|---|
・クラスターVPC
タスクやサービスのサブネットとセキュリティグループを表すオブジェクト。
・サブネット
タスクやサービスに関連づけるサブネットワーク。
 |
|---|
・セキュリティグループ
タスクやサービスに関連づけるセキュリティグループ。
デフォルトは新規で自動割り当て。既存のセキュリティーグループから選ぶことも可能。
・パブリックIPの自動割り当て
ENI（Elastic Network Interface）がパブリックIPアドレスを受け取るかどうか。
EnableかDisableで選択する。
##5-2. ロードバランサーの設定 タスク間のトラフィックを分散させる。事前にEC2コンソールでロードバランサーを作成しておく必要がある。
ロードバランサーはApplication Load Balancer（HTTPやHTTPSを振り分ける）か、Network Load Balancer（超高性能タイプ）から選択できる。
###ロードバランサーとRoute53のエイリアスレコード
ロードバランサーでタスク内のコンテナにアクセスするために、Route53のエイリアスレコードを作成しておく。
ネットワーキングの流れは、
リクエスト
↓
ロードバランサ
↓
コンテナ
となる。
##5-3. ロードバランサー用のコンテナを設定 
指定したタスクの中で定義したコンテナが選択できる。（コンテナが１つの場合は選択肢は１つ）
↓ 追加ボタンをクリック
・プロダクションリスナーポート
HTTP（80）かHTTPS(443)を選択。
指定したロードバランサーで設定してあるリスナーを選ぶ。
**▼ロードバランサーのリスナーの例** 
▼80番ポートの設定例
ここでは、80番ポートにアクセスした場合、443番にリダイレクトする指定になっている。このため、プロダクションリスナーポートは443を選択。
・テストリスナー
ロードバランサーでルーティングする前に飛び先のアプリケーションをテストする。
不要の場合はチェックを外す。
###5-3. ロードバランス用のコンテナを設定 ロードバランサーでトラフィックを接続するための、コンテナにターゲットグループを作成する。
▼ターゲットグループの名前
既存、または新規作成する。
▼ターゲットグループのプロトコル
コンテナの開放ポートに繋ぐ。80番を開けている場合はHTTPにする。
▼パスパターン
ロードバランサーのIF文で、〇〇のパスならの部分に当たる。
スラッシュ以下のパスしか入力できないため、FQDN（サブドメ）を入力したい場合は、ここはダミーを設定しておき、別途ロードバランサーで設定する。
▼評価順
if文を処理をかけていく順番。番号が小さい条件から検証していく。
###5-4. ヘルスチェックパスの設定 ヘルスチェックを実行するパスを設定する。 ロードバランサーで（ELBコンソール）で設定する。
###5-5. ２つめのターゲットグループの作成 デプロイの方法で**Blue/Greenを選択した場合は、ターゲットグループを２つ入力する必要がある**。
新しいGreenのターゲットグループ２にアクセスしたときにエラーが発生した場合、Blueのターゲットグループ１にトラフィックを戻すため。
▼パスパターン
選択不可。ターゲットグループ１のパスパターンを継承する。
###5-6. Auto Scaling
CloudWatchでアラームがでた場合に、オートスケーリングするかどうか。
Auto Scallingする場合は、最小・最大タスク数などを選ぶ。
###6. サービスの作成
作成ボタンを押すと、５つのサービスが一気に作成される。
- ロードバランサーのターゲットグループ１
- ロードバランサーのルール
- ロードバランサーのターゲットグループ２
- サービスの作成
- Blue/Green デプロイメント（CodeDeploy）
※注意
それぞれが別々のサービス上に作成されるため、ミスがあった場合は、全てを削除する必要がある。
↓ サービスを表示
以上でクラスターの作成が完了。
##7. ELB（ロードバランサー）の修正
5-3のロードバランス用のコンテナを設定ではFQDNを入力することができずダミーを入力したため、ELBコンソールから入力内容を修正する。
ELB（ロードバランサー）から指定のロードバランサーを選択し、ルールを表示する。
先ほどダミーで登録したルーティングが追加されている。
上の鉛筆マークをクリックしてこれを編集する。
FQDNを入力したいため、ホストヘッダーを選択する。
修正が完了したら、右上の「更新」をクリックして完了。
##ロードバランサーの注意点 バランサーはユーザーとサービスを繋ぐためとても重要。
間違って既存のルーティングを変更したり削除してしまうと、サービスにアクセスできなくなってしまうため注意が必要。
Route53とバランサーはサービスの根幹で、他のサービスともつながっている場合も多いため注意すること。
##8. ページの表示 以上で**AWS上での設定が完了**。
クラスターで該当のプロジェクトを確認したときに、RUNNINGになっていればOK。指定したURLを入力すればページを開くことができる。
ページはイメージの中で定義したルーティングやビューに従う。
ページが表示されない場合は、ヘルスチェックでサーバーが動いているか確認するなどの方法がある。（別途設定が必要）
**▼ヘルスチェックの例** 
以上。