Terraform是一个开源工具，用于将基础设施作为代码进行管理。今年早些时候，我们展示了Terraform如何突破传统的"基础设施"定义的界限，使用户能够使用Terraform管理GitHub团队和权限。这篇文章通过编写我们自己的自定义扩展来管理Google日历上的事件，进一步探讨了Terraform的扩展。»为什么是地形？将基础设施作为代码进行管理的好处非常简单。通过将基础设施需求和依赖关系捕获为代码，用户可以编写、版本、自动化、审核、重用和发布更改。使用Terraform管理Google日历也有同样的好处。另外一个额外的好处是，大多数人都了解日历，而这种共享的基础知识为讨论如何使用自定义地形提供者扩展地形提供了共同的基础。虽然上一篇文章关注的是用户为什么会利用Terraform来管理GitHub，但本文关注的是用户如何使用自定义扩展扩展扩展Terraform。»核心与插件为了理解Terraform插件的重要性和可扩展性，理解Terraform的体系结构是很重要的。Terraform一直有一个插件系统，但是Terraform的早期版本非常有限。随着插件系统的最新版本，HashiCorp维护的第三方Terraform插件有了一个充满活力的生态系统。在编写我们自己的插件之前，我们需要更好地理解terraformcore如何与Terraform插件交互。Terraform的核心负责读取配置和构建依赖关系图。Terraform严重依赖现代图论来管理依赖关系和遵守顺序。"terraformcore"是GitHub上实际的Terraform项目。Terraform插件是外部的单个静态二进制文件。在规划和应用阶段，Terraform的核心通过RPC接口与这些插件进行通信。如果您不熟悉RPC，可以想象插件是一个服务器，terraformcore对该服务器进行API调用。Terraform有许多可插入的部分，但是最常见的插件类型是Terraform提供者插件。Terraform提供程序插件使用基本的CRUD（创建、读取、更新和删除）API实现资源，以便与第三方服务进行通信。上游api是第三方、外部服务或Terraform与之交互的api。需要注意的是terraformcore从不直接与这些api交互。相反，terraformcore要求Terraform提供程序插件执行一个操作，该插件与上游API通信。这提供了一个清晰的关注点分离-Terraform核心不需要知道任何关于API的细微差别，Terraform提供者插件不需要知道任何关于图论的知识。terraformcore和Terraform插件之间的通信对用户几乎是完全透明的。如果在活动计划或应用阶段检查进程输出（ps aux | grep terraform），您将看到提供程序插件的父进程和多个子进程。Terraform Core和Terraform Provider插件之间的典型交互如下：用户运行地形平面图terraformcore从磁盘加载所需的配置以及最后已知的资源状态Terraform Core开始刷新操作作为刷新的一部分，terraformcore指示在最后一个已知状态下激活的每个Terraform提供者插件对每个资源执行读取每个Terraform提供程序插件将这个结果返回给Terraform CoreTerraform Core计算上一个已知状态和当前状态之间的差异（如果有）terraformcore将这种差异作为Terraform计划操作的输出呈现给终端中的用户同样，需要注意的是，Terraform Provider插件本身只调用基本CRUD操作的上游api——它们完全不知道与配置加载、图论等相关的任何东西，因为Terraform插件提供程序和Terraform Core之间是分离的，提供程序所需的工作更简单，只是客户机库的抽象。这使得在没有深入的图论或基础设施知识的情况下创建提供者变得非常容易。最后一点要注意的是，Terraform插件通常使用一个外部客户端库，如上图所示。虽然不是不可能的，但我们强烈建议将Terraform Provider插件也作为上游API的客户端API库。现代的编码实践允许我们模块化以便重用，我们也应该在Terraform中遵循这些原则。如果您的提供者还需要一个客户端库，最好将这些关注点分离到单独的软件项目中。»编写Terraform提供程序插件像大多数软件项目一样，编写Terraform Provider插件的第一步就是研究。重要的是，您必须对构建Terraform提供程序插件的API有一个坚实的基础理解。此外，您应该确定一个API客户机库（或者自己编写），它是一个独立的软件项目，它管理着与Golang（Terraform插件编写语言）中API的身份验证和交互。理解API之后，您需要编写一些代码来配置提供程序。您可以将提供者视为上游API的抽象。提供者管理terraformcore和上游api之间的通信。提供程序可以有一个或多个资源。资源是提供程序的一个组件。例如，一个提供者可能是整个云（AWS、googlecloud、Azure等），但资源是该云的组件（AWS实例、Google云防火墙、Azure存储容器等）。需要一些样板代码才能开始。这段代码将二进制文件配置为一个插件，并为适当的插件api提供服务。它还注册提供程序，并包含上游依赖项，这些依赖项在创建插件API时做了大部分的艰苦工作。// main.go// ... 进口等。函数main（）{插件。服务(&plugin.ServeOpts插件{ProviderFunc:函数（）terraform.ResourceProvider{返回提供程序（）},})}函数提供程序（）*架构.提供程序{返回&架构.提供程序{资源映射：映射[字符串]*架构.资源{"googlecalendar_event"：resourceEvent（），},ConfigureFunc：提供程序配置，}}函数提供程序配置（d*架构.ResourceData)（接口{}，错误）{//托多返回零，零}首先，创建一个main函数。这是在调用二进制文件时执行的函数。这个函数调用Terraform的内置函数插件。服务调用，它将构建所有必需的插件api和服务器。我们只需返回我们的provider，它是在provider（）函数中定义的。函数的作用是：声明资源列表和可选的配置函数。资源列表只是映射到函数调用的字符串。在上面的示例中，我们将"googlecalendar_event"资源映射到resourceEvent（）函数调用。注意，我们还没有定义那个函数调用，所以这段代码不能编译。资源的名称应始终以provider作为前缀，在此映射中定义的资源名称将是用户在其Terraform配置文件中放置的资源名称，如下所示：资源"googlecalendar""我的活动"{# ...}接下来，编写代码来配置提供者。这在很大程度上取决于提供程序和所使用的API客户端库。由于这个Terraform提供商使用Google云的官方golangapi客户端库，我们不需要任何额外的选项，可以使用默认客户端。函数提供程序配置（d*架构.ResourceData)（接口{}，错误）{客户端，错误：=谷歌.DefaultClient(背景。背景(), 日历.CalendarScope)如果出错！=无{返回nil，err}calendarSvc，错误：=日历。新的（客户）如果出错！=无{返回nil，err}返回日历svc，无}客户端库将使用gcloud CLI、环境变量或凭据文件自动对本地用户进行身份验证。Terraform将所有这些责任委托给API客户机库，从而节省了构建和解析自己的配置对象的需要。此时，Terraform插件和提供者已经配置好，可以使用了。但是，代码仍然无法编译，因为我们还没有定义定义"googlecalendar_event"资源的resourceEvent（）函数。»编写资源回想一下，资源是提供者的一个组件。换句话说，资源属于一个提供者，它们拥有对底层客户机库的完全访问权，可以按照指示进行所需的API调用。资源通常在自己的文件中定义，因为大多数提供程序都有多个资源。这在不同的资源之间提供了清晰的分隔，并使代码保持整洁的组织。另外，作为某种标准的约定，资源文件被命名为resource_[thing]，其中"thing"是资源的名称。//资源_事件.开始函数资源事件（）*架构.资源{返回&架构.资源{创建：resourceEventCreate，阅读：资源事件阅读，更新：资源事件更新，删除：资源事件删除，架构：映射[字符串]*架构。架构{}}}函数资源事件创建（d*架构.ResourceData，元接口{}）错误{//托多返回零}函数资源事件读取（d*架构.ResourceData，元接口{}）错误{//托多返回零}函数资源事件更新（d*架构.ResourceData，元接口{}）错误{//托多返回零}函数资源事件删除（d*架构.ResourceData，元接口{}）错误{//托多返回零}希望现在可以非常清楚地看到Terraform资源真正实现了一个CRUDAPI—创建、读取、更新和删除。请注意，所有函数也返回一个错误对象。Terraform被构建来非常好地处理错误。只要您有一个良好的读取操作，那么您就可以在任何时候返回一个错误，terraformapply将优雅地处理t