基于云的基础设施代码化最佳实践

什么是基础设施？

我们在这个话题中讨论的基础设施主要有三类：

云服务器：云存储、DNS、CDN等都是基础设施。应用程序具备真正的业务价值，但应用程序跑的基础平台都是基础设施。云服务器包括应用程序服务器、数据库服务器和缓冲服务器，我们可以通过代码化把这个配置出来。

这种传统的基础设施管理具体存在着哪些问题？

第一，咨询审批流程长，响应不及时。 这个基础设施从一个开发开始申请，逐级批准，然后运维总监批准，最后走采购的流程，这种审批流程不但项目组等待非常耗时，而且等待的信息反馈适应不了大家的需求。

第二，手工进行服务器的安装和配置，可能速度比较慢，难于版本化。发布前大家都要加班，并且在服务器上装东西，登录服务器去手工的部署，出问题很难追溯。

第三，易出错，遗漏配项。忘了一步很可能服务器跑不起来，要加班处理。

基础设施会遇到一些问题

一是无法根据业务需求，随时动态增加环境；

二是云资源利用率低；这种静态的，手工的配置方式带来的后果是项目组一开始在立项的时候把基础设施申请好，而并不释放资源，比如说现在有四台服务器，不用也不会还给公司，为什么？之后要用再申请是非常麻烦的。现在云服务器并没有给我们带来资源动态的好处，导致资源利用率低，成本增加；

三是手工部署的步骤有文档，但是文档维护起来很繁琐，而且常常更新不及时。

所以静态的基础设施导致没办法用云时代新的思维来解决问题，我们还是停留在旧的申请虚拟机的方式。

为什么传统基础设施管理会遇到问题？

一，在倡导敏捷开发的时代，我们的产品要适应瞬息万变的市场，要求基础设施有更快的响应速度；

二，我们可以用这种敏捷的基础设施支撑持续的创新和实验。有的时候产品经理有一个想法，没有人知道推向市场会怎么样，因为开发、运维，公司里面的人员可能并不是这个产品的真正用户。要快速的推向市场，快速的试错，需要基础设施跟得上步伐；

三，对持续交付、DevOps要求团队对部署和运维有更高的自主性，构建一个APP，就负责运维这个APP；

四，技术的快速进步，使基础设施的配置不得不频繁变化，现在我们有更多的选择了。在快速变化过程中，要求基础设施既要灵活、也要安全，可靠。我们开发人员，一线的产品肯定是希望基础设施越来越好，但是企业，尤其是大型的组织，他们对安全、可靠、可审计和合规性的要求也是非常强的。

如何解决这些问题？基础设施即代码，我们是怎么应用的，有两个原则：

一、代码化基础设施。用代码的方式管理我们的基础设施，并且维护管理它的全生命周期，包括审计的要求。代码更自然的成了审计上面一个非常好的记录，我认为代码的变更可以追溯到人，追溯到项目组。代码化也解决了变本、追溯和变更历史的问题；

二、动态基础设施。动态的需求如果在快速变化，我们可以用动态的方式去快速的创建它。

刚刚引入自动化的时候，我们用的是Amazon，之前用这些东西做应用程序的发布，我们在想基础设施的管理是不是也可以用它来做？（更多相关信息）

首先定义软件包，然后配置服务器，把配置文件和安全设置应用到服务器上面去，最后把应用程序的外包发布到服务器上，我们用代码的方式进行自动化实现。

我们在基础设施创建的时候，可以写一些简单的代码，比如说创建一台虚拟的服务器，创建一个自带的EC2，给它指定一些参数，操作系统的镜像是什么样的等等，之后加在主机的集合里面，等配置之后可以持续往下面的脚本去部署，现在看一下脚本是怎么样运行的。

此时在云上创建一个云服务器，整个过程都是一个自动化的过程。当时我们在客户的组织内部做了一个培训，我写了一个完善的文档教大家怎么用这个程序，大家可以去看。

如何解决基础设施代码化的问题？

基础设施的生命周期管理分两个部分的，一个是构建，一个是配置。构建就是创建资源，但不配置。装程序，导入用户初始数据，我们认为是配置。在基础设施构建这一块，可能就会用到formation。

怎么样用现代的基础设施来构建现在的基础架构？这个是非常简单的演示，一个最简单的功能，这里面一个是创建，一个是更新基础设施，然后如何销毁基础设施；我们把基础设施分解成一个一个技术站，每一个项目组可能有一个或者更多的，一套基础设施分组，一个组就是一个function。

我找到的是一个官方的例子，一个经典的技术站。为了保证它的可用性，我们做了一个分区域的高可用部署，可以看到它现在调用API去实现，我相信所有的公有云都有这个API的接口，企业的私有云也有这样的API接口。这里面可以看到已经创建了一些安全组，然后逐渐创建我指定的所有的资源，创建之后会导入一些初始的数据，而且都是全部自动化的。

怎么样自动化？实际上代码也非常简单，首先定一些参数，比如数据库的名字，数据库里面的用户名，密码，还有一些服务器的大小，可以设置默认程序机构有几台服务器，可以动态扩容，但需要一个初始的值，后面是一些固定的企业码。

这里有一个Resources，之后会配置它的的特性，比如接在80端口上，有什么样的协议，我们定义了一组服务器，用自动扩容架构去创建了一个服务器，然后设置了一些updatepolicy的滚动发布的策略，还有一些具体服务器的配置。我们把代码写死在服务器里面，但实际上可以不用写死，可以指定在外部的文件里面。

最后给应用者一个新创建文件的访问地址，这样创建完之后就可以直接用了，相当于一键把整个应用程序的架构创建好了，而且是高扩展的。

Terrafom这个公司的服务发现，本地虚拟机的启动比较有意思。又拍云有一个云存储的服务，我在API上写一个拓展插件，非常容易，这样我可以把所有基础设施代码通过又拍云来创建。

为了适应新时代下快速的基础设施变更需求，基础设施即代码实践 应运而生，如果大家有兴趣的话，可以尝试阅读这本书（Infrastructure as Code）。

声明：本文来自「又拍云主办的Open Talk——DevOps与持续交付实践」的演讲内容整理。PPT、速记和现场演讲视频等参见“UPYUN Open Talk”官网。
嘉宾：刘梓懿，ThoughtWorks咨询师，专注于云计算和ThoughtWorks。
责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qianshuguangarch申请入群，备注姓名+公司+职位。