今天给大家带来的主题分享是《Terraform从入门到实践：快速构建你的第一张业务网络》，首先由我来为大家分享如何入门和实践 Terraform，之后将由我的同事陆碧宇为大家分享如何使用Terraform快速构建第一张业务网络。

随着IaC理念的不断深入和发展，以Terraform为代表的IaC工具已成为云上资源运维的重要工具，也成为越来越多的客户在上云时的必备工具。

今天分享的内容会从以下四个方面展开。首先分享云上运维将会面临的挑战，以及通过IaC如何解决这些挑战；第二，详细向大家展示如何从零开始入门Terraform；第三，我们将重磅发布一款产品Terraform Explorer， 该产品一方面尽可能降低在阿里云上使用Terraform 的门槛，另一方面提升大家在云上使用Terraform的体验；最后向大家介绍Terraform在实际生产落地过程中的最佳实践。

IaC助力降低云上运维复杂度

首先看三个案例：

在今年暑假之前，有个游戏厂商推出了一款新游戏，在运行时要为每位玩家分配一台独立的windows云主机，在云主机启动时还要完成游戏的加载。当有大量的玩家使用这款游戏时，要求游戏平台能够快速完成windows云主机的创建，并且当游戏退出时还要完成windows云主机的快速释放，以免造成资源浪费。

二是打车业务。在节假日前，为应对流量的宏峰，需要提前完成资源扩容，包括ECS、数据库等。在节假日后，还需实时回收资源。

三是一般企业客户上阿里云前，都需对云上资源做POC验证，在此过程中需要使用新账号在多个云产品间创建大量的云资源。POC验证完成后，还需回收云资源。

通过这三个案例，我们发现无论是应用还是项目，无论在启动期间还是运行期间，都需要和阿里云产品进行互动，即对云资源进行管理和运维。随着云产品种类的不断增加，功能的不断丰富，云上运维的成本也在逐步增加。

面对运维复杂度不断提升的问题，现有的运维方式会面临诸多挑战。

以控制台为代表手动运维的方式，一方面它的效率较低，另一方面它的执行成功率不高，涉及人为操作，很难避免人为误操作带来的影响。

第二是以API集成方式所带来的自动化运维方式。虽然它的运维效率有所提高，但会出现另一个瓶颈，当使用云产品的种类足够多，功能不断丰富时，所需集成的API数量和复杂度也在逐步提升，对集成成本造成更大影响。

还有随着稳定性、安全性事件的频发，随着业务架构调整，资源的架构也要相应的调整。多账号、多region的部署架构也对现有的运维方式提出更高的要求。

在此背景下， IaC提供了一种很好的解决方案。

一方面，IaC可以将所有需要管理的资源以代码化的方式进行定义，通过对代码进行自动化操作来实现效率提升。同时借助自动化的流程，能够降低人为运维带来的不稳定因素。

其次，我们可在代码提交或编写的时候review，同时增加事前、事后的审计规则，对其进行有效管控，进而提升运维的安全性。

第三，IaC的理念是提供面向资源的编码引擎，屏蔽用户通过API和云产品之间交互的逻辑，无需担心所管理的资源背后集成了多少API、API的集成方式是什么样的、编排逻辑是什么。当需要对资源进行扩容、变更时，只需修改代码中的一个IaC片段，通过IaC的方式就可以实现资源的管理。

Terraform就是一种典型的IaC工具，以插件化的方式屏蔽了客户与云产品之间通过API交互的逻辑，这个插件在Terraform里叫做provider。阿里云提供了terraform-provider-alicloud标准官方插件。Terraform用户在管理云资源时，可按照声明式（Terraform HCL语言）的方式定义面向Terraform的IaC代码，并通过执行Terraform的命令完成对资源的自动化管理。完成资源的创建和管理后，Terraform会将所有实际创建出来的资源状态、属性保存在状态文件中，当下次需要对资源进行持续管理时，Terraform会对比状态文件和代码配置之间的不一致性，只有出现了不一致，再次执行Terraform命令才会将不一致消除，完成对资源的进一步管理。

阿里云作为Terraform重要的云服务提供商，目前已经支持了超过100多款云产品，800多个资源类型，同时也提供丰富的物料支持和能力上的建设，进一步降低用户在阿里云上使用Terraform的门槛。我们也提供了Cloud Shell、Explorer、AI助手等在线能力，进一步提升用户在阿里云上使用Terraform的体验。

Terraform入门：开启你的Terraform之旅

对Terraform基本了解之后，接下来我会向大家介绍如何从零入门Terraform。

Terraform的入门比较简单，它主要的工作流程分为四步：首先我们需要根据自身的业务架构编写面向Terraform的代码，完成后执行Terraform的init命令，完成代码所依赖的provider自动化下载。下载完后，执行预览命令实现对所定义代码的在线浏览。如果预览结果符合预期，即新增加的、修改的、删除的资源都是预期之内的，可执行Terraform apply命令完成对资源的自动化创建和管理。有了这样的工作流之后，我们梳理出用户使用Terraform的全旅程。入门用户或初级用户只需关心Terraform环境如何搭建，以及搭建好后代码如何编写，代码如何执行和调试。如需将Terraform更深一步应用到生产环境中，我们还需关心Terraform如何和业务集成，事前、事后的保障如何做，自动化流程如何搭建等更多的步骤。

首先是代码的编写阶段。

提到Terraform代码，首先想到的是如何从零开始编写一个相对标准、规范，且可维护性和可读性较高的代码。这需要结合Terraform的执行逻辑，Terraform在执行过程中要加载当前工作目录下所有以tf结尾的文件，将这些文件中所有的资源、参数定义编排到一起，以并发的方式来完成资源的自动化创建。有了这样的前提，我们会发现Terraform所有代码的定义不仅与顺序无关，而且与文件无关，我们可以按自身业务架构设计Terraform框架。在这个框架下，我们可以在不同的tf文件中编写不同的业务逻辑。比如我们variable.tf的文件中编写入参定义，outputs.tf里定义出参，main.tf定义所有资源、资源关系的逻辑代码。我们也可以对main.tf按照产品或者应用进行切分，比如ecs.tf、vpc.tf、oss.tf等。切分后，在相应的文件中编写好相应的逻辑代码，对资源做进一步的调整。

我们在编写过程中可能会遇到某些逻辑代码的重复性较高，比如创建网络，很多云产品，如ECS、RDS都需要网络环境，这时可以借助Terraform Module将重复性、复用性比较高的一些代码进行Module封装，通过上一层的调用逻辑来降低代码的复杂度。

完成基本的代码编写之后，我们还需要对它进行状态配置。默认情况下，Terraform 会生成一个本地的状态文件，但是我们更加推荐大家使用线上的状态文件，一方面它的安全性比较高，因为它保存在云端，同时有锁机制进行校验，支持团队协作，同一团队内不同的人在不同端编写的代码都可以放在同一个状态文件去管理。

完成代码编写之后需要对代码进行校验。我们通过一些基本的命令或者规则来校验所有写好的模板是否符合预期，进而提前发现问题。校验通过的代码可以提交或发布到Git、OSS、BitBucket等。

有了代码之后，接下来需要考虑如何能够快速的执行Terraform代码。

Terraform的代码的执行分为两步。第一步是需要有一个Terraform运行环境，第二步是执行Terraform命令。运行环境主要分为两部分，首先要安装Terraform，第二是对Terraform进行配置。Terraform是一个面向客户端的、二进制文件，安装流程比较简单，我们只需根据操作系统的版本下载相应的安装包。下载完成之后，解压到本地的可执行目录下就可以对它进行操作。第二是对它进行配置，主要是对它进行身份认证的配置。云产品的API在调用时都需要对这些API传入AK进行签名，进一步完成API调用。Terraform也是一样的，最终也是通过这些API完成资源操作，所以需要在Terraform中对它的访问凭证进行配置。配置完成之后，依次执行初始化、预览、运行命令，进而完成代码中所定义资源的自动化管理。在管理完成后，我们会发现只有在模板代码中定义的状态和状态文件中定义的状态不一致的时候，Terraform才会真正去执行和创建资源。正如左下角所展示的，代码中定义有4台ECS, 但实际状态文件中有3台。当运行Terraform命令时，会在现有状态文件基础上创建出来1台ECS。同样的，如果代码中定义只有2台ECS，实际状态有3台, 那么它就会在3台ECS基础上释放1台ECS，最终达到代码状态和状态文件状态的一致，这就是Terraform在运行过程中的机制。

在实际运行过程中还会遇到各种各样的问题。我梳理了两个常见的问题，一是权限问题，二是开通的问题，还有注意事项。

权限问题，一方面是配置Terraform的AK时，我们需要关注AK的权限问题。因为只有具备足够权限的AK才能实实在在地创建代码中所定义的资源。另一方面，当涉及云产品间的调用服务时，往往存在服务关联角色。我们需要在执行Terraform之前提前准备好角色，否则有可能引起最终Terraform执行失败的情况。

开通问题，阿里云上的某些产品在第一次使用时都需要开通。只有开通完成后才能对云产品进行资源操作。开通是一次性的，我们可以通过控制台手动开通，也可以通过自动化API和Terraform自动化开通。

最后是一些常见注意事项，比如运行超时、名称冲突、忘记销毁等。我重点强调一下资源的删除重建。我们都知道云上的产品/资源在完成创建之后，不是所有的资源属性都能够持续修改的，比如OSS bucket, 一旦bucket创建完成，它的名称是不能修改的，想要对它进行修改，要么创建一个新的资源，要么把当前资源先删掉，然后再创建一个新的。Terraform也是一样，当代码中所定义的一些资源在完成创建后，如果修改了不支持修改的资源属性，Terraform就会识别为这是一个要先删除再创建的资源，执行Terraform命令时也会先把原有的资源删除，然后创建新的。这是一个比较危险的动作，大家在真正去实践的时候，需要特别注意，或者根据自身的场景规避掉这些问题。

Terraform Explorer发布：阿里云上Terraform的最佳

接下来将重磅发布一款产品——Terraform Explorer，它有两个重要的功能，一是降低云上使用Terraform的门槛，二是以在线化的方式提升大家在云上Terraform的使用体验。

正如我们所了解到的，Terraform的使用过程分为三个阶段：代码编写、代码执行、状态管理。Terraform Explorer围绕这三个阶段进行建设。首先是代码编写，我们将所有Terraform支持的资源类型以表单的形式进行展示，当要定义某个资源代码，或编写某个资源模板的时候，只需通过表单的参数填写，就能自动生成Terraform模板。有了Terraform模板之后，我们还提供在线的Terraform运行环境，一键执行所有代码，并完成对代码中所定义资源的自动化创建。在创建完成之后，我们会自动托管状态文件，实现对代码中所定义资源的持续管理。除此之外，我们也借助AI的能力提供Terraform AI助手，您可以根据自身的业务需要输入您业务场景，然后会输出面向您的业务场景模板。

有了Terraform Explorer之后，Terraform用户旅程会变得非常简单。不需考虑Terraform Explorer环境如何搭建、如何配置、如何管理状态。我们只需要一个界面，通过表单填写就能够完成Terraform的一系列操作。接下来会有两个demo演示，第一个演示会向大家展示如何通过Terraform Explorer快速搭建一个web应用；第二个演示是如何通过AI自动生成Terraform模板。

Demo演示详见云栖大会-Terraform从入门到实践视频 34分30秒。

目前Terraform Explorer已经正式对外发布，AI助手目前还处于内测阶段，不久后将会发布，欢迎大家试用。

Terraform旅程落地最佳实践

最后将会向大家展示Terraform在落地过程中的一些最佳实践。

回到Terraform用户旅程，当Terraform应用到实际生产过程中时，我们要关心的不仅是环境和代码，还需关心Terraform如何和自身的业务集成，如何对它进行质量的保障、如何建设自动化运行的工作流。

我接下来会先会向大家介绍为什么我们要做质量保障。

随着时间的推移，以及架构的调整，多多少少都会存在一些代码腐烂的问题。Terraform代码也一样，随着资源架构的不断调整，资源参数的不断变更，Terraform代码也会逐渐趋于腐烂状态。针对这种情况，我们需要去建立一些机制来避免或减轻腐烂状态。这里提供了三种方案：

第一，提供静态检查机制。我们可以通过设置一些静态检查规则，或者依赖第三方工具实现对Terraform的自动检查，帮助我们在提交之前就能完成对代码的检查。

第二，建立一些测试机制。这分为两部分，一是手动测试机制，我们需要在编写完成或提交之前通过Terraform命令对他们进行稳定性测试，测试通过的代码才会被提交。

提交之后我们还需要借助CI、CD自动化测试工作流对它的代码进行规则性的校验，只有测试通过的代码才能被合并到master分支，进而发布。发布之后，我们需要端到端的测试工具对它进行持续的回归测试，这样才能确保这些基础代码出现问题的时候尽可能早的发现。

有了代码之后，如何将这些代码应用到真实的环境中？任何一个代码一般都会有三个环境：开发、测试、生产。同一套代码如何应用到三个环境中呢？这里提供两种方案。

一是workspace，这是Terraform自带的功能，也就是一份代码通过不同的workspace将三个环境进行隔离。通过这种隔离，一方面能够最大化的利用Terraform代码，但也有一个小缺陷是三个环境用workspace隔离只能放到一个状态文件里，即三个环境状态是耦合在一起的，当其中一个环境的状态出现损坏时，会对其他两个环境的状态造成损坏，此时要结合实际的使用场景进行控制。

二是通过目录划分对三个环境进行隔离。通过目录划分可以为每个目录配置独有的状态文件，实现三个环境的完全隔离。它的问题是三个环境放在三个目录功能下，会有大量的重复性代码。针对这个问题，我们推荐通过Module对这些重复性较高的代码进行封装。在上层业务或三个环境中通过Module调用实现资源的自动化管理，同时代码的复杂度不会太高。

最后向大家去分享当我们通过Terraform对基础设施进行实际的生产并应用到资源生产环境中时，还要考虑这些基础设施的稳定性怎么持续保障。这需要我们从全链路上看如何持续性的保障所有基础设施的质量。我提供了三种方式和手段。

这些基础设施是通过Terraform生产的，首先以代码工程视角去规避所有代码中潜在的逻辑性问题，比如增加提前审计规则、端到端的测试、版本控制等手段。

在代码完成稳定性控制后，我们在操作代码的过程中还要进一步控制，这涉及两方面。一方面是我们要借助自动化执行的手段尽可能规避人工运维的操作。另一方面是我们要对一些非预期的问题，比如状态变更、参数重建这类问题，通过一些机制对他进行有效的控制。以防当自动化执行时，因为参数变更，导致基础设施发生一些不可预估的问题。

当基础设施创建完成之后，还需从平台侧对这些资源进行持续的稳定性保障。这里面涉及到三个问题。第一是统一入口，通过Terraform创建的资源，一定要控制管理入口。既然已经使用Terraform管理这部分资源，就不要再使用其他的入口对它进行管理。同一资源通过不同的入口管理，一定会出现不一致，而这个不一致一定会损害Terraform具体的执行状态。第二是我们要对代码所定义资源进行权限控制。同一个代码我们需要对它进行最小粒度、最精细化的权限控制，避免权限过大对其他的基础设施造成更多的影响。第三是通过在线可观测能力对线上的基础设施做一些可观测，提前发现各种潜在问题，能够最小化的控制爆炸半径。

最后，Terraform随着云厂商持续的投入，以及对更多云产品进行更深入的集成，已经成为云上自动化运维的一个重要工具。随着Terraform生态的不断发展，也演变出了如Crossplane、Pulumi、CDKTF等更多的IaC工具，我希望大家能借助这些IaC工具解决云上运维的问题，降低云上运维的复杂度，真真切切的能够帮助大家解决日常的问题。