前提
本題
ECSクラスター
ECSを構成する部品の最も土台となる部分
このクラスターの上にサービスやタスク、コンテナがある。
クラスターはECS専用のEC2インスタンスで形成される。
ECSコンテナエージェントが入ったもの、これがECS専用のインスタンス。コンテナインスタンスとも呼ばれる。
EC2インスタンスが論理的な土台を形成し、この土台の上にサービスやタスクといった他のコンポーネントが配置される。
EC2インスタンスのタイプをLinuxタイプかWindowsタイプか選択することができる。
どちらにせよEC2インスタンスにはDockerデーモンやECSコンテナエージェントが導入されている。
EC2インスタンスとネットワークキング、これがクラスターの作成に必要。
EC2はVPCのサブネット内部で稼働する。
クラスターと同時に作成できる。
Fargeteの起動方法
EC2を使用せずにクラスターを形成する方法。
EC2の運用管理がなくなるのがメリット。
ECSサービスを使うにあたって、EC2タイプかFargateタイプか？という構造。
ecsInstanceRole
ECSのContainer AgentがECSのServiceに対してAPIを呼び出したりするため、EC2はECS Serviceに対する適切な権限を持っている必要がある。
また、ECRからDockerイメージを取得したり、クラウドウォッチログズにログを出力したりといった権限が含まれる。
タスク定義
TaskDefinition
Dockerコンテナを使用するのに必要なJSONファイルでコンテナの設計図。
Dockerコンテナは、このタスク定義の設計図通りに起動する。
基本的に一つのコンテナに対して一つのタスク定義を使用する。
複数のコンテナを定義することもできる。
タスク定義は様々なパラメーターを指定できる。
例えば、Dockerイメージの定義やCPUのメモリの必要数、起動タイプなど、ネットワークローキング、コマンドボリューム、IAMロールといった項目を設定できる。
ネットワーク
hostネットワークモード
コンテナとホスト両方とも同じポートで待ち受ける。
ホスト側のポートとコンテナ側のポート、同じポート番号で待ち受けるためタスク定義上は80を指定するのみ。
このため、一つのホストで同じポートを利用するタスクを複数起動することはできない。
bridgeネットワークモード
DockerファイルにEXPOSE80と記述し、コンテナを80番ポートで待ち受ける。
Docker runコマンド、オプション-p80:80
左側にホストの80番、右側にコンテナの80番ポートといった関連付けを行うことでアクセスできる。
同じポート番号で待ち受けることはできない。
awsvcpネットワークモード
デフォルトでEC2にアタッチされているENI
タスクごとにENIをアタッチする。
タスクがどのインスタンスでどのコンテナを実行しているか意識する必要がない。
ENIごとにセキュリティグループを紐づけられたり、タスクが独立したような感じ。
タスクが独自のENIを持つことによって、個別のENIを使ってタスクは通信するため、ネットワークパフォーマンスの向上が見込める。
また、VPCフローログズで観測可能、ロードバランサーはIPのターゲットとして登録可能。
※インスタンスタイプによってアタッチできるENIの数、上限がある。
コンテナの定義
配置戦略
タスクがEC2に配置するまで3つの条件、フィルターを通すことができる。
cluster constraints
タスクを実行するのに、EC２に十分なCPU、十分なメモリがあるか、使うポートは開いているか判断する。
placement constraints
絞り込みのフィルター。特定のAMIから構築されたインスタンスのみに絞り込みなどできる。
placement startegles
配置する優先順位のようなイメージ。
3つの方法がある。
１、Binpack
２、Spread
３、Random
１、Binpack
可能な限り一つのEC2に配置するパターン。
CPUかメモリをベースにする。
CPUまたはメモリの使用料をみて一つのインスタンスになるべくタスクを詰め込む。
２、Spread
指定された条件でバランスよく配置する。
AZにバランスよく配置。もしくはインスタンス、バランスよく配置する。