写下三个提供者的名字，然后思考了一番
这篇文章是来自2020年12月8日的”terraform Advent Calendar 2020 – Qiita”。
总结;
如果要操作API，就从编写Terraform的自定义提供者而不是独立脚本开始！
课题和背景
我想写Go代码！ 凭借我对OpenAPI（Swagger）的理解，以及对自己的自信，我考虑写一个与API相关的服务器或客户端。
当谈到操作API时，我决定使用Terraform。
换言之，我想要用Go语言编写一个Terraform自定义提供程序，因为我已经理解OpenAPI（Swagger）了！
所以，并不是因为遇到了一些○○的挑战和问题，才决定使用Terraform来解决。
另外，在上述的想法中，我第一次接触Terraform，并不意味着我非常熟悉它的使用方法。
与编写用于执行某种基础架构即代码的TF文件的行数相比，我编写Provider的行数更多。
怎么样了？
在那个时候，我恰好以我使用的公司内部工具的API为题材，尝试编写了第一个供应商。
实际上，我只是做了“实现创建 | Terraform – HashiCorp学习”这个内容的程度。
我对此有两种不同的解读：
1. 结果就是，写 Terraform 自定义提供者真的很简单呢，而且 Terraform 真的很方便啊。
2. 总的来说，我觉得写 Terraform 自定义提供者挺简单的，而且 Terraform 真的超级方便。
写出2到3个项目和供应商信息。
我也毫不气馁地为内部工具的API编写了Provider。
起初，我使用自己独特的脚本来操作API，但是由于无法记住启动选项之类的内容，所以我将其改写为了Provider。
结果，对我个人而言，如果当前目录中有TF文件，则可以通过API进行操作，这样就会感觉简单又好。
总结
写了3个Provider后的想法是，与其用自有的脚本来操作API，不如将其转化为Terraform Provider，这样会有许多好处。
优点
-
- 起動オプションが要らなくなる
-
- 設定ファイル(TF)が構造化されてわかりやすい
TFファイル自体もバージョン管理できる
Terraformという仕様に従うので、 他の人も仕様を把握しやすい
仕様に従うとやれることが限られるので、 変な作り込みも減る
実はここが大事だと思っていて、独自スクリプトで便利そうだと思い頑張って作った機能が実はあまり使われないなんてことがよくあるが、それを防止できる
缺点
- 新規で作る場合はいいが、車輪の再開発になるのでコストと相談
闲谈
我之前使用的是 Terraform 的 0.12 版本，但从0.13版本开始，有关 Provider 的改变导致无法运行，所以我必须尽快解决这个问题（由于这不是我的主要工作领域，所以我有些疏忽了）。
