Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Terraform ですべてを管理するのに疲れた😭

Terraform ですべてを管理するのに疲れた😭

社内LTなのでちょいちょい雑です

4bcb32bcb73d1ead993a6ad55b189e9e?s=128

Hasegawa Takuya

December 14, 2021
Tweet

Transcript

  1. Terraform ですべてを管理す るのは疲れた😭
 SRG 長谷川


  2. 6年間
 手入れがされてない
 サービスがあった。
 
 ※ Disってるわけではない󰢃


  3. それはいつしか
 こっちの持ち物になった


  4. そのコンポーネントは
 日々重要度を増していた...


  5. 自己紹介
 • 長谷川 拓也
 ◦ 2018年度新卒入社
 ◦ メディア系サービスの横断組織 
 ◦

    サービスリライアビリティグループ(SRG)所属 
 ◦ 合同会社HCloud の社長でもある 
 
 • 好きなこと(もの)
 ◦ 色々
 
 

  6. 現在の状況
 • AWS を利用
 • 使ってるサービスはたった2つ
 • EC2
 ◦ m1.small

    もいる
 ◦ 全台に Elasitc IP が付与されている 
 • Classic Load Balancer
 ◦ Classic !!!

  7. CentOS6 で... Chef で... munin/nagios で...
 • この EC2 たちの問題点


    • EC2 は m1.small
 • OS は CentOS 6
 • Chef は個人的に嫌いだし
 • アプリログをどこかに送ってるわけでもなく
 • 監視は munin と nagios
 • 運用管理を楽にして、監視も Datadog に一元管理したい

  8. どのサービスを利用するか
 • Fargate vs ECS on EC2
 ◦ ECS on

    EC2 のメリットは今回は無い 
 ◦ EC2 の管理したくない >< 
 • Fargate vs App Runner
 ◦ App Runner は VPC 内のリソースにアクセスできない 
 ▪ ref: https://github.com/aws/apprunner-roadmap/issues/1 
 = Fargate に決定!

  9. で、Chef はどうする?
 • コンテナ化にするから Chef は不要になる
 • かといって IaC 環境がないのは心理的安全性に欠ける


    • Terraform or Pulumi or CDK
 ◦ 最初は Terraform を書いていた 
 ▪ 既存のコードのコピペができて楽だった 
 ▪ でもこのコードを環境ごとに追加していくのは辛い 
 ◦ Pulumi は個人的に好きだけどこのためだけにゼロから書くのは辛い 
 ◦ CDK もゼロから書くのは辛い 

  10. で、Chef はどうする?
 • コンテナ化にするから Chef は不要になる
 • かといって IaC 環境がないのは心理的安全性に欠ける


    • Terraform or Pulumi or CDK
 ◦ 最初は Terraform を書いていた 
 ▪ 既存のコードのコピペができて楽だった 
 ▪ でもこのコードを環境ごとに追加していくのは辛い
 ◦ Pulumi は個人的に好きだけどこのためだけにゼロから書くのは辛い 
 ◦ CDK もゼロから書くのは辛い 

  11. Terraform Workspace
 • やりたいことは dev, stg, prd と分けて管理したい
 • Terraform

    Workspace でできるんじゃないかと思った
 • がそのような使い方(分離の度合いが強い)は非推奨とされている
 
 
 
 ref: https://www.terraform.io/docs/language/state/workspaces.html
 

  12. IaC のこと考えるの疲れた😭


  13. AWS Copilot
 • What’s AWS Copilit
 AWS App Runner、Amazon ECS、AWS

    Fargate を活用したプロダクションレディなコ ンテナアプリケーションのビルド、 リリース、運用をかんたんに実現しよう。
 GitHub: https://github.com/aws/copilot-cli
 Document: https://aws.github.io/copilot-cli/
 • やりたいことはだいたいできそう!

  14. 1. Dockerfile を用意する
 - EXPOSE は必須
 - ENV JAVA_OPTS=”” は


    Copilot から変数を注入する
 - 1.3-labs からヒアドキュメントが
 利用できるようになったの便利

  15. 2. copilot init
 • 各質問に答えていくとマニフェストが作成されます


  16. 3. copilot env init
 • dev, stg ごとの環境を用意する
 • すでにネットワーク周りはあるので

    --import を利用する

  17. 4. copilot deploy
 - deploy コマンドがやること
 - Dockerfile からイメージの作成 


    - ECR にプッシュ
 - CFn にパッケージング 
 - ECS タスク定義、Job, Service の作成・更新 

  18. 5. マニフェストをいじる
 - init を行うと copilot/service-test/manifest.yml が作成される
 - copilot はこれを元にリソースを変更したりする


  19. マニフェスト http


  20. マニフェスト image


  21. マニフェスト リソース


  22. マニフェスト 値の上書き
 • 例 メインコンテナのメモリ量を指定


  23. マニフェスト 環境ごとに
 • sbx と prd で別の値を使う
 • 最上位のキーから指定しないと適用されない
 •

    サイドカーパターンももちろん可能
 ◦ メインコンテナが
 これらのサイドカーに依存することも可能 

  24. まとめ
 • Terraform x AWS Copilot の組み合わせで IaC に対するコスト削減
 ◦

    Fargate 周りは Copilit と割り切る 
 ◦ SecurityGroup や EC2, RDS は Terraform と分ける 
 • AWS Copilot でデプロイ管理もできるため、CI/CD との親和性が高い
 • かゆいところにも手が届く。Copilot に対するデメリットはない
 • どんな場合にこの組み合わせがオススメか
 ◦ 多くの場合にメリットがあると思う 
 ▪ すでに Terraform でガチガチならあえてやる必要性もない