11.3K Views
July 23, 24
スライド概要
開発チームでIaCを導入したので、その効果について話しました
このスライドは 7/22 の ssmonline #43 で発表したスライドを、部編集したものです
https://ssmjp.connpass.com/event/324454/
版 公開 開発チーム、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 具体的には、自分たちでも以下ができるようになって開発速度を上げたい ○ ○ ○ 自分たちでサービスを立ち上げられる 自分たちで既存サービスの構成変更ができる 自分たちでいまサービスがどういう構成でどうなっているのかを管理できる
ことのおこり ● ● 「でも、自分たちでやって本番で事故るのが不安かも」 具体的になにが不安か? ○ ○ ○ ● 手作業やそれに付随するうっかりミスに対する不安 予期しない差分がありうる不安 結果が予測できない不安 これってTerraform(IaC)入れたらいいのでは 🤔 ○ チームに向けて軽くデモしたら、これならいけそう! だったので本格導入することに
Terraformとは ● TerraformはHashicorpが提供する構成管理ツール ○ ● 以下のセット ○ ○ ● ● https://www.terraform.io/ 各種サービスのSDKやAPIをhclで扱えるようにしたプロバイダー hclを解釈し、プロバイダーを使って各種クラウドへの反映や状態管理、差分検知を行う Terraform本体 ゲーム機がTerraform、ゲームソフトがプロバイダー、コントローラがhcl なにが嬉しいのか ○ ○ ○ ○ Terraformがいい感じにリソースを作成・変更・破壊してくれるので手作業不要 hclで書かれたコードからインフラを定義できるので、レビューができる いまのインフラ状態を管理してくれるので、コードを変更したらどうなるかが予測できる → インフラ継続運用のつらさを軽減してくれるツール
やりたいこと ● チームメンバーが、以下をできるようになる ○ ○ ○ ● 自分たちでインフラ含めてサービスを立ち上げられる 自分たちで既存サービスの構成変更ができる 自分たちでいまサービスがどういう構成でどうなっているのかを管理できる 上記を(できるだけ)安全安心にやってもらうために、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氏に聞く、テストを書き始めるための「はじめの一歩」
導入までにやったことまとめ ● 安全に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連携はいいぞ やり始めの時期にこう書くといい、こう書くのはつらい、という認識を揃えられた
課題
課題 ● 反映するまでエラーになるかわからないものがある ○ ○ ○ ● HCP Terraformに強い権限がある ○ ○ ● リソース間の依存関係とかクラウド側のバリデーションによるものとかとか…… VCS連携と相性が悪い 悩み中 やむなしではあるが…… OIDCを入れる、信頼関係をガチガチに書いているなどしているが、微妙 ■ 「今さら疑うものか! メンバーの善意を信じる!」 THE オレオレTerraform設計を標準として浸透させてしまった感 ○ ○ 初動をひとりでやったのでやむなしではある 私が死んだら代わりはいるのか? 引き継げるのか?
まとめ
まとめ ● ● ● 一人ですばやく導入して、みんなで長く運用するのがだいじ コードにしたらみんなインフラ書いてくれる、かも? これからやりたい人向け ○ ○ IaCの導入 ■ 小さく始める ■ させたくないことを明確にする、仕組みで防いでおく IaCの運用 ■ みんながすぐ使うことを期待しない ● じわじわと良さを伝えていく