開発チーム、TerraformでAWS始めました - 公開版

版 公開 開発チーム、Terraformで AWS始めました HCP Terraformはいいぞ

おまえ誰？ ● 某社ソフトウェアエンジニア 某プロダクト開発チーム所属 ex. SRE ○ ○ ● 好きなもの archlinux neovim Rust ○ ○ ○ ● 趣味 バイク ギター(最近始めました) 自宅サーバ・自宅kubernetesクラスタ ○ ○ ○ ● 犬派

今日の話 ● どんなことを話すのか ○ ○ Webアプリ開発チームで継続的にIaCをやっていくために準備したこと ■ あるいはマネジメントコンソール操作への恐怖を加速させた話 しばらく運用して感じたやってよかったこと・課題感

今日の目次 1. なぜ開発チームでIaCを導入したのか 2. 導入するまでにやったこと 3. 導入してからのこと a. b. c. 変わったこと やってよかったこと 出てきた課題 4. まとめ

なぜ開発チームでIaCを導入したのか

ことのおこり ● ● xx年間利益を生み出してきた黄金の技術的負債たちに感謝しながら、 日々返済に取り組んでいる弊アプリ開発チーム アプリケーションやデータベースのリファクタももちろんながら、 そもそものアーキテクチャの見直しも実施

ことのおこり ● インフラ、自分たちでやれるようになると速いのでは疑惑が浮上 🤔 ○ ○ ● これまではインフラチームにおまかせしていた ちょっと違うけど、You build it, You run it. のマインドを持とう! というハナシ ■ https://queue.acm.org/detail.cfm?id=1142065 具体的には、自分たちでも以下ができるようになって開発速度を上げたい ○ ○ ○ 自分たちでサービスを立ち上げられる 自分たちで既存サービスの構成変更ができる 自分たちでいまサービスがどういう構成でどうなっているのかを管理できる

• https://queue.acm.org/detail.cfm?id=1142065

ことのおこり ● ● 「でも、自分たちでやって本番で事故るのが不安かも」 具体的になにが不安か？ ○ ○ ○ ● 手作業やそれに付随するうっかりミスに対する不安 予期しない差分がありうる不安 結果が予測できない不安 これってTerraform(IaC)入れたらいいのでは 🤔 ○ チームに向けて軽くデモしたら、これならいけそう! だったので本格導入することに

Terraformとは ● TerraformはHashicorpが提供する構成管理ツール ○ ● 以下のセット ○ ○ ● ● https://www.terraform.io/ 各種サービスのSDKやAPIをhclで扱えるようにしたプロバイダー hclを解釈し、プロバイダーを使って各種クラウドへの反映や状態管理、差分検知を行う Terraform本体 ゲーム機がTerraform、ゲームソフトがプロバイダー、コントローラがhcl なにが嬉しいのか ○ ○ ○ ○ Terraformがいい感じにリソースを作成・変更・破壊してくれるので手作業不要 hclで書かれたコードからインフラを定義できるので、レビューができる いまのインフラ状態を管理してくれるので、コードを変更したらどうなるかが予測できる → インフラ継続運用のつらさを軽減してくれるツール

• https://www.terraform.io/

やりたいこと ● チームメンバーが、以下をできるようになる ○ ○ ○ ● 自分たちでインフラ含めてサービスを立ち上げられる 自分たちで既存サービスの構成変更ができる 自分たちでいまサービスがどういう構成でどうなっているのかを管理できる 上記を(できるだけ)安全安心にやってもらうために、IaCを導入する

導入するまでにやったこと

IaCは導入簡単、 継続運用がむずかしい (n敗)

どうやったら継続運用できるかを 考えるのがだいじ

IaCを運用していくうえで やらないでほしいことを考えた

やらないでほしいこと = IaCのメリットが消滅すること

IaCのある世界でやってほしくないことはなんだ ● 運用の前提や本番環境、やる気などが崩壊するのでやってほしくないこと ○ ○ ○ ● IaCがあるのにも関わらず手作業 レビューを通さず手元から適用 うっかり適用先アカウントや環境を間違える IaC運用断念

どう防ぐか？

大事にした考え方 (インターネットで見た話なんですが、どこで見たのか思い出せず引用断念) ● できることはやっていい ○ ○ ● やらかした人だけではなくできる状態にしている人も悪い ○ ○ ● 手作業できる状態になっているなら手作業していい ミスできる状態になっているならミスしていい sudoersに追加しておいて「なんでsudoしたんですか!」と怒るのは筋違い 同じように、 ■ 手作業してほしくないなら仕組みでさせない ■ ミスしてほしくないなら仕組みでさせない(むずかしいけど) 「やらないでね!」と言うことは、なんの対策でもない

IaCのある世界でやってほしくないことはなんだ ● 運用の前提や本番環境、やる気などが崩壊するのでやってほしくないこと ○ ○ ○ ● IaCがあるのにも関わらず手作業 レビューを通さず手元から適用 うっかり適用先アカウントや環境を間違える IaC運用断念 「できる」のがよくない! 「できる」のがよくない! とはいえTerraformをやってもらうためには 個人に強い権限が必要なので、できてしまう

できない状態するなにかがあれば……!

それ、だいたい HCP Terraform でできるよ

HCP Terraform(旧 Terraform Cloud)とは Terraformの実行サービス。 ● ● ● ● Terraformのリモート実行(クラウドゲーミングみたいな) GitHubなどVCSとの連携(CI/CD) 実行履歴の管理 構成変更反映のレビュー・承認機能 などを提供するすごいやつ。500リソース(data除く)まで無料!

HCP Terraformでどうできなくするか ● IaCがあるのにも関わらず手作業 ○ ● レビューを通さず手元から適用 ○ ○ ● 個人アカウントにはマネジメントコンソールやCLIで直接操作できる強い権限を渡さない ■ 認証情報はIAMロールをOIDCで使うようにする リモート実行機能を強制する VCS連携機能を使う ■ 有効にすると、反映は手元からはできなくなる ■ VCSのレビュー経由してね! 的なアラートが出る うっかり適用先アカウントや環境を間違える ○ VCS連携機能を使う ■ アカウント情報や環境と、VCSのリリースブランチを1:1で紐づける

だいたい HCP Terraform でヨシ!

IaCのある世界でやってほしくないことはなんだ ● 運用の前提や本番環境、やる気などが崩壊するのでやってほしくないこと ○ ○ ○ ● IaCがあるのにも関わらず手作業 レビューを通さず手元から適用 うっかり適用先アカウントや環境を間違える IaC運用断念

運用断念を防ぐ方法はあるのか？

魔法のような方法はない!

IaC運用断念を防ぐ ● IaCはアプリケーション開発のユニットテストと同じだと考える ○ ○ ○ 極論なくてもいい ある状態を知ると、ない状態には戻れない ■ あるメリットがわかるまでに時間と経験が必要 継続的にメンテしないと崩壊する

IaC運用断念を防ぐ ● 浸透させかたもユニットテストと同じ ○ ○ ○ 触ってみないとわからないので、知る・触る機会が必要 ■ 勉強会 ■ 実際にやってみる会 完璧じゃなくてもいい、できるところからやるというゆるい気持ちが大事 ■ 最初から全部綺麗に管理する必要はない ■ 少しずつできるひと、管理する範囲を広げていく 逆に最初からガチガチにやると、お前とIaCやるの息苦しいよって言われちゃう t-wada氏に聞く、テストを書き始めるための「はじめの一歩」

• https://levtech.jp/media/article/interview/detail_480/

導入までにやったことまとめ ● 安全にIaCを使ってもらうために ○ ○ ● やられたら困ることを洗い出す HCP Terraform(旧 Terraform Cloud)の導入 ■ やってほしくないことはなるべくできないように設定する 継続してもらうために ○ ○ IaCやそれに関連する知識の勉強会開催 小さいプロジェクトで触ってみてもらう ■ ペアプロ・モブプロをやりながら

導入してからのこと

変わったこと

変化 ● 「インフラ周りのチケットやってみたいひといます〜？」の呼び掛けに ちらほら手が上がるようになる ○ ● 「いまこういうアーキテクチャなんですけど、変えたほうがパフォーマンス 安定しません？」みたいな話が出てくるようになる ○ ● ● インフラ周りの仕事が「設計考えてコード書いてレビュー受けてマージする」、という いつものアプリケーション開発と同じフローに落としこまれたから？ 「なんかいけるかもなんでちょっとやってみますね」、も出てくるようになる 「せっかくなんでECS Execできるようにしときましたわ」、みたいな改善が されるようになる → Terraformを通して、みんなAWSと仲良くなった!

変化 ● メンバーがとあるサービスをひとりで定義して本番リリースした ○ ● すばらしい 「マネジメントコンソール操作するの怖いっすね」とみんな言い出した ○ ○ とてもうれしい もっと恐れてほしい

やりたいこと(おさらい) ● チームメンバーが、以下をできるようになる ○ ○ ○ ○ ● 自分たちでインフラ含めてサービスを立ち上げられる ← できた! 自分たちで既存サービスの構成変更ができる ← できつつある 既存の構成を理解する 自分たちでいまサービスがどういう構成でどうなっているのかを管理できる ← できつつある 上記を(できるだけ)安全安心にやってもらうために、IaCを導入する ○ ↑できた!

やってよかったこと

やってよかったこと ● 導入したあとはできるかぎり併走した ○ ○ ● 仕組み作ったからあとよろしく! では定着しない ■ IaCを荒廃させないためには一緒にやっていく姿勢がだいじ やったこと ■ 勉強会 ■ 社内ドキュメント/Qiitaに記事を書く ● 複数環境にデプロイすることを考慮したterraformディレクトリ設計 ● Local Valueとfor_eachを使ってリソース定義を楽したい ■ ペアプロ・モブプロ HCP Terraformを入れてGitHub連携した ○ ○ 単純にPRレビューしやすくなった ■ レビューのときに「これ差分どんなんだろ pullしてplanして……」は虚無かった ■ HCP TerraformのVCS連携はいいぞ やり始めの時期にこう書くといい、こう書くのはつらい、という認識を揃えられた

• https://qiita.com/_kei_s/items/d0239966727e3889a7ee
• https://qiita.com/_kei_s/items/2f1690d61d325e46a57b

課題

課題 ● 反映するまでエラーになるかわからないものがある ○ ○ ○ ● HCP Terraformに強い権限がある ○ ○ ● リソース間の依存関係とかクラウド側のバリデーションによるものとかとか…… VCS連携と相性が悪い 悩み中 やむなしではあるが…… OIDCを入れる、信頼関係をガチガチに書いているなどしているが、微妙 ■ 「今さら疑うものか! メンバーの善意を信じる!」 THE オレオレTerraform設計を標準として浸透させてしまった感 ○ ○ 初動をひとりでやったのでやむなしではある 私が死んだら代わりはいるのか？ 引き継げるのか？

まとめ

まとめ ● ● ● 一人ですばやく導入して、みんなで長く運用するのがだいじ コードにしたらみんなインフラ書いてくれる、かも？ これからやりたい人向け ○ ○ IaCの導入 ■ 小さく始める ■ させたくないことを明確にする、仕組みで防いでおく IaCの運用 ■ みんながすぐ使うことを期待しない ● じわじわと良さを伝えていく