ecsとasgを使ってオートスケールするサービスをterraformで構築する

　GWの自己研鑽最終日です。前回試したCapacity Providerを用いたコンテナインスタンスのAutoScaleとECSサービスのAutoScaleをterraformでやってみました。

• すでにterraformを書いている人たちがいたので、まずはそれをリファレンスと照らし合わせながら読んで理解するところから始めた
• Thirosue/terraform-sample
• waneal/terraform-test-ecs-capacity-auto-scaling
• terraformを書いた
• ググると二種類のAutoScaleのどちらかをterraform化したものは出てくるのだが、どちらもやっているのは見当たらなかったので書いてみた
• terraformのファイルのprefixに番号をつけておくと、何から作っていったのかがわかりやすくていいかもと思った
• vpcまわりをterraformで書くのは初めてだった
• assume roleは雰囲気しか理解してなかったが、何をするものなのかが分かった
• 負荷をかけたり、かけなかったりして、スケールイン・スケールアウトされる様子を確認した
• サービスのオートスケールに連動して、タスクが利用するコンテナインスタンスもオートスケールするのは地味に感動した

ecsとasgを使ってオートスケールするサービスを立ち上げる

  GWの自己研鑽４日目のメモです。

AWS ECS（EC2起動）でのAuto Scalingまわりの調査＆検証をしました。

• サービスの Auto Scaling
• 公式ドキュメントを読んだ
• ECSはサービスのリソース使用率（CPUやメモリの使用量）メトリクスをcloudwatchに発行している
• このメトリクスを利用して自動的にサービスのスケールイン・スケールアウトをすることができる
• ターゲット追跡スケーリングをやってみた
• コンテナインスタンスの auto scaling
• EC2起動の場合はサービスをホストしているコンテナインスタンスのauto scalingも考慮する必要がある。
• 公式ドキュメントを読んだ
• Capacity Providerというものを使うといいらしい
• Capacity Provider = クラスタ中のタスクが利用するインフラを管理するやつ
• target capacity（0~100）を定義するとその値をターゲット追跡してくれるらしい
• 例えば100と設定するとクラスタ内にあるコンテナインスタンスのサービス使用率が100に近くなるようにscale-out/scale-inが行われる
• Capacity Provider Strategy = どのCapacity Providerを使ってタスクのインフラを管理するかを決める戦略
• クラスタは複数のCapacity Providerを持つことができるので、サービスを作るときにどの戦略でいくか選ぶ
• 最低でもX個のタスクはCapacity Provider Aを使う（base値）、全体のうちY%のタスクはCapacity Provider Bを使う（weight値）というような戦略を作ることができる
• Default Capacity Provider Strategy = デフォルトのCapacity Provider Strategy
• サービス起動時にCapacity Provider Strategyを指定しなかった場合に使われる戦略。
• クラスタごとに決めることができる
• Classmethodの記事を参考に実際に動かしてみた

ビルドしたamiを使ってecsクラスタを起動する(EC2起動)

 AWSのお勉強の続きです。

前回ECS Optimized AMIをベースに作ったカスタムAMIをクラスタとして起動して、ECSを動かしました。

• EC2起動のECSのgetting-startedをやってみる
• ECSコンテナインスタンス = ECSコンテナエージェントを実行していて、ECSクラスタに登録されているインスタンスのこと
• ECSコンテナインスタンスには Amazon ECS コンテナインスタンス IAM ロールが必要
• まず空のECSクラスタを作成する
• クラスタテンプレート「EC2 Linux + ネットワーキング」から作成しようとすると、最新のECS Optimized AMI以外は利用できないっぽい
• 次にECSコンテナインスタンスを起動する
• 起動したECSコンテナインスタンスをクラスタに登録する
• バインドマウントでEC2インスタンスのライフサイクルに関連づけたデータをマウントする
• アプリもちょっと変更する
• fargate実行の場合はawslogsドライバーでcloudwatchにログストリームを送っていたが、ec2実行の場合はサーバにログインしてdocker logsすればログが見れる
• シンプルにシステム運用する場合はfargate実行、社内に標準環境や共通のミドルウェア基盤などがある場合はAMIを作ってec2実行、という使い分けになりそう

packer&ansibleを使ってamiをビルドする

 GWの自己研鑽の続きです。

職場ではAMIの作成まわりは別のチームの人が担当しているので、自分でpackerを使うのは初めてでした。初歩的なことをやってみただけですが、雰囲気だけでも掴めて良かったです。

• 公式サイトの aws-get-started をやってみた
• 新しいバージョンではHCLが使えるらしい
• 作成したリソースを削除し忘れないように注意！
• サービス - EC2 - AMI から登録解除
• サービス - EC2 - スナップショットから関連するスナップショットを削除
• HCLを書くための環境を整える
• IntelliJ に HCL プラグインを入れる
• ECSをEC2起動するために使うカスタムAMIを作成する
• Amazon Linux2 の ECS Optimized AMI をベースに作ることにした
• 対象のAMI名は以下のコマンドで探せるっぽい
• aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended --region ap-northeast-1
• ansible provisioner の設定を追加する
• ansible-local を使うとリモートホスト上で直接 ansible を実行できる
• ansible-local を使うためにはリモートホスト上に ansible をインストールしておく必要がある
• とりあえず ECS から mount するようのログディレクトリを追加してみた
• 今日の進捗