AWSコンテナ設計・構築[本格]入門を読んだ

AWSコンテナ設計・構築[本格]入門 を読んだ

• コンテナオーケストレータとしてはKubernetesは馴染みがあったがECSはなにもわからない勢だったので、わかりたいモチベーションで本書を手にとった
• Terraformも何気に触れてこなかったので、その学習も兼ねて本書で扱うシステム構成をTerraformで構築していってみた

Terraform化で扱った構成図(Well-Architectedにはしきれていない..)
※以下は単位AZの図(構築するものはマルチAZ構成)

github repo: https://github.com/hrfmmr/sbcntr-resources/tree/terraform/terraform

書籍と異なる部分

• bastion
  • パブリックサブネットに踏み台サーバを置いている
    • 書籍ではVPC内で行う必要のある作業(Internal ALBへの疎通確認やDB seedingなど)は、Cloud9環境で行う内容となっていた
    • が、個人的には再現性犠牲にしてもローカルマシンから環境構築作業を行いたかったので、VPC内で行う作業用に踏み台EC2を建てる構成にした
• network
  • 書籍ではコンテナからのアウトバウンド通信はNATゲートウェイを介さずすべてVPCエンドポイントで解決していた
  • が、NATを置く構成にしてる
    • デプロイしたコンテナが意図通りに動作しないことがあった(frontend appからbackend appへの通信が通らないなど)ので、コンテナの中に入って調査したいことがあった
    • その過程でdns-utilsなどのパッケージインストールを行えるようにしたかったという理由(slimイメージだと何も入っていない)
    • 運用readyになったら不要になるやつ
• ecs
  • タスクロールにECS Exec用のロールを追加してる
    • 上述の「(Fargate)コンテナに入って調査」するためにECS Exec用のポリシーをアタッチしている
• secrets
  • 書籍ではAWS Secrets ManagerでRDS DBのcredentialsを設定していたが、AWS Systems Managerのパラメータストアで代用している
    • Secrets Managerを使う一方でシークレットの自動ローテーションをOFFにしていたので、なぜパラメータストアではなくSecrets Managerを選択しているのか気になった
    • AWSの公式FAQ をみると、両者のセキュリティモデルに違いはないとしていて、それぞれのユースケースとしてはライフサイクル管理要件ないならパラメータストア/あるならSecrets Managerをつかうという記載があった
• rds
  • DBはAmazon Auroraをつかう前提だったが、学習のためとはいえさすがにコスト嵩みそうなのが怖かったので、Aurora構成は断念した
  • 「ECSタスクからRDSにつながる」部分を最小で実現できさえすればひとまず良しとして、シングルAZのDBインスタンスを建てるのみの構成にした

感想戦

• AWS学習する上ではクラウド課金をいかに最小化するかが1つテーマとしてあり、今回Terraformでインクリメンタルに構築進めていくことでわりとリーズナブルに(トータル$8ほど)行えてよかった(小さくマイルストーン達成してはterraform destroyするの繰り返しで進めた。ありがとうdestroy)
• はじめてHCL(HashiCorp configuration language)を触ったが、何かと凝った設定ファイル書いているときに「YAMLでプログラミングがしたい」といった欲求が芽生えるときはわりとあって、そういった需要に痒いところに手が届くといった具合でロジック記述できて書き心地としてとても良かった。LSPサポートもあったし。(CloudFormationテンプレートよりよっぽどヒューマンリーダブル。アレに戻る気にはなれない..)

次

• 「他AWSリソースとはライフサイクルが異なる」意味でECRについてはTerraform管理下から外していたが、 これはECSリソースについてもいえそうなことで、おなじような課題意識から生まれたとされるECS専用デプロイツールとしてecspressoがあるので、次はTerraform+ecspressoでECS管理する構成を試してみたい