Providerを3本書いて思ったこと

これは terraform Advent Calendar 2020 - Qiita の12/8(火)の記事です。

TL;DR;

APIを操作するなら、独自スクリプトよりTerraformのCustom Providerを書こう！

課題・背景

Go書きたい！ という思いと、 OpenAPI(Swagger)分かる！ という自信から、APIに関するサーバかクライアントを書いていくかぁと考えました。
その中でAPIを操作すると言ったら、Terraformでしょってことになりました。

つまり、Go書きたい！ x OpenAPI(Swagger)分かる！ = Terraform Custom Provider 書く！！

なので、○○な課題や問題があってその解決のためにTerraformを使ったとかではありません。

それと、上記の思いの中で初めてTerraformを触ったので使い方にめちゃめちゃ詳しいとか言う訳でもありません。
何かのIaCをやるためのTFファイルを書いた行数よりも、Providerを書いた行数の方が多いです。

どうだったのか

その時にちょうど自分が使う社内ツールのAPIを題材に、1つ目のProviderを書いてみました。
内容は「Implement Create | Terraform - HashiCorp Learn」をやった程度です。

結果、 Terraform Custom Providerって簡単に書けるんだなぁ って感じと Terraformってめっちゃ便利じゃん って感じでした。

2〜3本目とProviderを書いてきて

こちらも懲りなく社内ツールのAPI向けにProviderを書きました。
こっちは元々独自のスクリプトでAPIを操作できていたのですが、起動オプションだったりが覚えられなくて、Providerで書き換えました。

結果、個人的に カレントディレクトリにTFファイルがあればAPIを操作できるので簡単で良い 感じでした。

まとめ

Providerを3本書いて思ったことは、独自スクリプトでAPIを操作するよりもTerraformProvider化することでメリットが多々あるぞ、と言うことです。

メリット

• 起動オプションが要らなくなる
• 設定ファイル(TF)が構造化されてわかりやすい
  • TFファイル自体もバージョン管理できる
• Terraformという仕様に従うので、 他の人も仕様を把握しやすい
• 仕様に従うとやれることが限られるので、 変な作り込みも減る
  • 実はここが大事だと思っていて、独自スクリプトで便利そうだと思い頑張って作った機能が実はあまり使われないなんてことがよくあるが、それを防止できる

デメリット

• 新規で作る場合はいいが、車輪の再開発になるのでコストと相談

余談

Terraformの 0.12 系を使っていたが、 0.13 系からProvider周りの変更が入り動かなくなったので早くどうにかしないといけない（この辺はこれが本業ではないので、疎かにしている）