自动化实践-尖兵案例

以下是视频转写全文，供参考：

Hello， 大家好，欢迎回到阿里云开放平台自动化专栏Auto Talk。本期我们带来的是自动化之尖兵案例，我是天凯，来自阿里云开放平台。在开始之前，我们先回顾一下我们为什么要做基础设施自动化以及什么是基础设施自动化？首先我抛出两个最核心的概念。第一个就是基础设施自动化其实是把我们的业务逻辑，我们重复在做的事情，通过一系列的工具变成代码逻辑。能够让机器帮我们更高效、更标准地去执行的一种过程。第二个观点是说在这个过程中，其实对于工具的选择是千花百样的。不管是通过API，通过SDK，通过云控制API，亦或者通过Terraform ROS都是可以的，最终只要是组织能够在适合自己的技术栈、适合自己的解决方案上，能够通过IaC去落地，能够提高效率，那就是一个比较完美的方案。这个其实是IaC的一个全景图。但是今天我们既然讲的是尖兵案例，我们其实就抛开了一些与组织、协同、流程包括版本管理，代码管理这些东西。我们先聚焦到今天我作为一个独立的运维工程师，我作为一个独立的SRE。我今天能不能够通过自动化的工具去解决我个人的一些问题，然后后续我们会有专门的视频会讲如何去解决组织的问题。所以今天我们在红框中所标识出来的就是通过一系列的IaC的代码，通过一个Terraform的工具，我们以Terraform为例，去看一下我们在日常运营过程中常见的一些场景。

谈到技术场景我相信大家在日常过程中都会面临不同的挑战。我们之所以叫做尖兵效率，是因为我们希望能够为每一个独自撑起一片蓝天的SRE或者运维工程师提供更好的技术支撑。然后帮助他们在日常的工作中变得更有效率、更标准，并能够释放自己的时间，做一些有趣的事情。

那谈到场景，我这边说一些典型的场景。第一个就是产品开通。大家也知道阿里云其实在您创建一个新的账号时候，如果想要购买一个服务，前面还有一步，那就是产品开通。有的产品需要您通过开通之后，才能正式购买和使用这个产品。这些场景映射到我们组织内部，可能会有一些项目的新建，员工的入职等场景。他们不得不一步步手动开通。这件事情其实是很容易做到自动化的，后面有例子展开来讲。

第二个就是访问控制。访问控制其实谈到了一个员工的权限期限，以及他如何通过权限的自动化配置，让以不同角色的员工（如运维、业务、运营等）在进入到我们的组织之后，都能够获得相应的自动化的权限的授权。然后第三、第四步就是云基础设施。我们能否快速构建和生产出这样的一套基础设施，也是我们自动化的一个主要目标。第五步，其实是Dev Ops的一个理念。在基础设施部署完成之后，我的Dev Ops能否协同工作，将我的应用也部署到基础设施上。从而实现从基础设施层到应用层的一系列的自动化的转型，并进一步提高我的交付和变更效率。

我们接下来看看第一个场景，即新账号去开通服务。这个场景的定义是指在组织内部，我们往往会有一些需要在阿里云上开通新的账号的情况。其实我们前面也提到了，需要开通服务才能购买相应的阿里云的服务，对吧？例如，典型的新员工入职，新业务上线、新部门成立等情况，都可能会产生一个新的账号。

在我们运维团队把账号交给业务团队之前，这些账号有没有做好这个基本的准备。不需要业务团队去开通或者关注这个账号的前置的一些预处理的过程，而是直接应用到业务当中去。我们解决的目标是，今天如果我是一个运维的同学，我希望通过自动化的手段，自动化的方式把这些东西代码化。我不需要去控制台一个一个点，每一个账号点几十次，那其实也是很枯燥，也是很低效的事情。而且在这个过程中，其实特别容易多开权限或者多开通服务，漏开通服务包括错开通服务，这种情况其实就会造成多次的返工，效率会进一步的下降。

这边我们一起来看一个例子。其实Terraform这个工具还是蛮好用的。它为阿里云的客户在批量开通新账号的时候，做好了一个预先的储备，就是这个Terraform的 Module。大家可以在Terraform的automation的这个gate仓库里面找到这个。并且通过简单的仓库扩容的方式，把这个代码扩容到你自己本地，基本上不需要做太多的更改，大家可以简单看一下。

好，那我现在先把代码拉下来。拉下来之后我们可以一起来看一下。在example里面其实有一个main outputs对吧？还有一个variable，variable里面其实就包含了我一系列要开通的这些服务的变量。那是否开通呢？我只需要去注释，比如像现在我演示的，比如果我不需要开通这两个，那我就把它注释掉。如果剩下的都是on的状态，那我就认为它是需要开通的，所以我就把它留下来作为我账号的一个开通基线。这样的话当我每一个新账号创建的时候，我都会去运行这个脚本，然后把这些PM的服务能够自动化地创建出来。

这个里面因为我们是demo环境，所以用到了一个AK，那AK的这些我们需要把它复制过来。但是值得强调的是，今天我们只是做demo的演示，在真正的应用和生产过程当中，我们是强烈不建议我们的客户把AK明文放到这个文件里面去保存。您可以选择通过本地缓存的方式，通过一些runtime环境的方式，或者通过AK托管的方式，更有效地保护AK，并且进行日常的密钥轮转。那我们今天继续进入到一个init环节。因为在这个init过程中，其实我也犯了一个小错误，就是provider的这个文件没有保存，所以会报一个找不到文件的错误。那我这边先快进一下。保存之后，我再去执行的时候会报一个错误。因为我上面的这个provider文件，其实是没有保存的，那当我保存之后，再去执行这个文件。

然后大家就可以看到这个预览的结果。因为Terraform支持plan和apply两种指令，所以您在预览的时候就能看到它大概会为您开通哪些服务的状态。好，接下来我进行apply指令，让它真正为我现在这个账号开通这些服务，然后大家可以看到这个服务就已经按照正式的状态开通了。这样的话就等于说我们整个过程其实很简单，以一种轻量化的方式实现了。

第二个场景，就是大家最常见的通过自动化快速去创建云上的一个基础设施。大家也知道在云时代，其实我们基础设施的交互效率是越来越快的。尤其是像互联网业务，游戏业务，我们的一些特殊业务形态对于运维交付时间的要求也是越来越高了。因为市场的反应速度也越来越快了。

在这个场景中，业务团队为运维团队提出了一个要求，即每两周要创建一套这样的环境，然后在使用完成之后，测试完毕后，可能会尽快释放。接着在下一个两周，又会重新创建这套环境。频繁的删除和配置对运维的团队来说，如果没有自动化的支持，其实是一个非常痛苦的事情。再加上多个业务团队同时发起这个申请，就会变成一个非常糟糕的运维工作体验。他们希望不仅能够快速交付，而且整体的时间和基线的准确度也能够有同样的提升。

作为一个运维同学，如果你来负责，那你应该怎么办呢？在这个场景中，我们希望他能够对日常的系统架构进行梳理。比如说我们常用的应用服务ECS，开公网的SLB，VPC安全组，以及进行压力测试的弹性伸缩，它能够将这些转变为自动化的代码。接下来我们一起来看一下代码。

好在这个场景中，其实运维团队为业务团队提供了一套代码，其中包括了一个VPC，一台v switch，然后一个安全组，并为安全组配置一个相应的入网策略。然后开了一个公网ip，并且释放8080端口去部署这个应用系统。在这一步，其实我的这个相对环境已经配置了一半了。然后同样的我去配置弹性伸缩组的配置，并且把它的规则配置出来。然后在结束之后，我在ESS上面去部署一个hello world应用。这边我们可以看一下，我先执行Terraform的init的一个指令。在把Terraform整个环境初始化完成之后，我让Terraform去帮我构建出这套基础设施。他在预览里面会告诉我说，我会创建九个资源，那九个资源分别是什么？

好，当我敲下指令之后，也许我就可以去打一杯咖啡，打一杯热水，等待这个脚本执行完成。大家可以看到它其实已经按照上下游的顺序，依赖顺序开始创建VPC，开始创建安全组，开始创建我的公网的SLB。并且把ESS拉起来，然后相应的规则配置起来。并且能够把我的hard world应用程序部署到这一基础设施上，其实已经大概实现了我们刚才说的那个应用发布自动化的简化场景。但是在实际的业务过程当中，我们基本上都是先从基础设施自动化，基础设施管理这些场景入手。好，等待创建完之后大家可以看到我输出了一个公网的IP那这个公网的IP其实就是我部署hello world应用的这个IP。为了节省时间，中间我也简单跳一下，因为启动服务器需要一段时间，中间只是在刷新这个过程。

好，然后我们假设今天我们的这个应用已经部署到了服务器上，大家可以看到hello world应用已经部署出来了。针对这个场景，我的运维团队就可以把这些基础设施，这些meta data交付给我们的应用团队去做日常的应用的使用。在这个时候，如果未来我们的想去构建自己的CMDB，想去构建自己的多云的管理平台，那么这些资源的meta data其实都是非常基础且重要的数据，接下来就是这个场景的结束。

我业务团队可能测试了2个小时之后说我这套环境不要了。需要运维团队尽快释放，帮组织节省这个成本。在这个过程中，我运维团队只需要再敲一个destroy命令。业务团队申请单中，他们申请创建的这些资源就会原封不动地按照我们的整体的删除逻辑全部被destroy掉。这样就还原了这个资源的整个的生产和生命周期。好，然后我们看到等它删除完成。

SLB安全组为vswitch，应该是最后一个资源。等待删除完成之后，我们可以再去网站上访问一下，看看我们刚才的hello world应用是否还能够正常访问。好，大家可以看到刚才我们创建了九个资源，现在我们要删除这九个资源。同样，我回到我的控制台，可以发现整体控制台上已经开始转圈了，它的服务已经不存在了，这个IP也不存在了，所以才会出现这样的情况。那好，接着我们进一步往下看。

第三个资源，就是云上资源基线化的这个单机管理。为什么是单机管理呢？其实对应的是我们所谓的今天的这个主题。我们首先是服务好开发者或者运维的这个个体。在存量资源导入的问题上，其实是一个很痛的场景。因为我们开始做IaC并接入工具去做自动化管理之前，肯定我相信很多组织云上都是有资源的。它并不是说先把IaC这一套搭起来，然后再去做业务，往往是业务先行。所以在把云上资源做代码逆向，或者说把它的这个IaC的代码统一的管理起来，这件事情就变得很重要。

这个事情的解决的目标，就是一个运维同学对于云上已经存在资源进行一些导入。然后在他本地进行一个完整的生命周期管理。接下来我们再看一下这个demo，在demo 2里面其实就是我们上一个场景所演示的那九个资源那一套环境，我就把它重新构建出来。

在demo 3里面，我们假设demo2里面构建出的九个资源，其实是历史上已经存在的这些控制台的资源。在这个过程中，我对控制台的资源进行了相应的导入的配置。这个导入其实也很简单，我只需要定义这个资源是什么，资源类型是什么，资源ID是什么。然后再执行指令，它就可以帮我生成Terraform的代码，并生成资源的tfstate，也就是资源的meta data。一旦这两个对应起来，我就可以进入到一个良性循环，进一步管理我的基础设施，并与现有基础设施的整个的基线进行对齐。

这个指令其实是在项目3中，基于我们对一系列的资源和资源ID的配置，进行了一些import的导入，这里其实是有一些不对应的情况，是少数比较罕见的情况。就是说它可能线上是0，那它的范围是4到60，那我们就把20到60，这样我们就把this size简单做一个修改，跟我们所需要的环境对齐就可以了。好，那这边大家可以看到有九个资源需要去import，那我在执行Terraform apply之后，它就会正常地去import进来，然后跟我现有的这个基线对齐。现在demo 2和demo 3两个项目中的TSC的文件其实已经对齐了。这个时候你不管在哪个项目都可以进行整体的自动化的基线管理。所以这其实对于我们日常运维来说，一旦把这个基线建立起来，我们的运维效率包括准确性、标准度都会有很大范围的提升。好，到这个演示为止，以上基本上就是本期分享的全部内容了。如果您有任何疑问或者关于云上自动化的想法，欢迎扫描屏幕下方的二维码加入钉群与我们交流，期待联系，我们下期再见。