http://devops.com/blogs/meet-infrastructure-code/

May 5, 2014 Posted By Chris Riley In Blogs, Doin' DevOps Tagged Devops, Infrastructure As Code, It, Operations, Programmable Infrastructure 0 Comments

也许你早就听说过“可编程的基础设施”(Programmable Infrastructure)或者“基础设施即代码”(Infrastructure as Code)这些新词儿了。不过,就算你之前没听说过,只要对DevOps感兴趣,你一定也会有兴趣了解它们。我这个人对大多数新名词都不感冒,但这次却不一样,这完全可以说是一个新概念。除了让技术宅觉得谈吐不俗之外,这些名词确实代表了一种看待应用构成的新思路。这个新名词很恰当地概括了过去几年人类文明进步所取得的一些成果。一般来说,我使用某个术语的目的只是为了让人知道自己没有跑题,比如我提到“Web”“云”之类的,仅仅是为了辅助我跟他人沟通。有时候我也会对某个术语感到奇怪,于是就会花时间去弄明白它的真正含义。但真正能让我觉得是颠覆三观的术语并不多见。“可编程的基础设施”和“基础设施即代码”就是。

enter image description here
“基础设施即代码”的形象展示

并不全新的术语

自动化并不是新鲜事物。从最早使用BAT文件到最近使用PowerShell脚本在我的基础设施中做事情,算起来已经很多年了。但当这种自动化与虚拟化相遇,当人们设计出了专门用来描述基础设施编排的语言,情况就不同了。这时候,我们说的不再是给某种技术换个包装,然后起个新名字。而是一个全新的概念,这个概念决定了谁来做什么事,怎么做,效率如何。那什么是“可编程的基础设施”呢?这个词跟“基础设施即代码”是一个意思。“可编程的基础设施”我最早是听Gartner的一位分析师说的,很可能也是那个人创造的,“基础设施即代码”则是在某一篇博客里看到的。后者使用的“某某即某某”的句式一直很流行,还带点神秘感。这两个词到底是什么意思呢,就是告别手工配置基础设施的时代,用自定义脚本来配置基础设施。当然不限于脚本,还可以把配置集成到应用代码中。这种做法很早之前就有,但一直有局限性。无论做什么,总有一些事不能自动化。可今天,我们有了Vagrant、Ansible、Docker、Chef和Puppet,它们可以单独起作用,也可以配合起来把原来手工能做的一切都自动化,包括基础设施层和操作系统层。即便是已经存在的基础设施,通过这些工具也一样可以再运行脚本,甚至可以在新创建的基础设施中运行原来的老BAT和ps1文件。这是基础设施编排的一种新思路。

开发人员全程可控

有人会说,这不就是配置管理吗。某种意义上说,它就是全自动化。但它跟配置管理有一个非常大的区别,那就是开发人员可以全权负责。过去,这种编排和自动化工作得交给系统管理员去干。今天,开发人员至少可以提建议了,甚至在很多情况下完全都可以自己动手了。这样一来,应用代码与底层基础设施之前的关系就更加紧密了,有时候根本就分不开了。今天的开发人员不光可以写应用代码,还可以写运行应用的基础设施。就拿Web开发领域来说吧,开发人员写一个deploy.php文件来自动配置运行应用的基础设施,这种事已经很常见了。这种脚本开始会创建VM,最后会向源代码仓库发送下载请求。我建议相关机构应该成立自己的小团队专门负责这些脚本的维护,因为开发人员应该花时间去改错和实现新功能。但无论如何,IT运维与开发都无法截然分开了。

到底有什么好处

除了让配置管理高效可复用之外,基础设施即代码还带来了其他好处。首先,脚本本质上都可以作为应用基础设施的文档。这个附带的好处很有用。因为你已经投入时间和精力把脚本写好了,那么把它当成基础设施的网络关系图来看其实也挺好。有人可能并不满足于此,还会基于脚本生成外行都能看懂的内容、图表和文档。其次,因为一切肇始于脚本,那么所有部署都将源于同一个文件。自然地,每个部署都将具备相同的基础设施特性。这只是理论上,实践中我发现很多机构会在已有基础设施上运行脚本,或者在脚本自动运行后再手工修改配置文件,导致脚本丧失了作为追溯依据的价值。另外,脚本还是基础设施中立的。只要把脚本写好,就可以在任何云上运行,公有、私有、混合,都没问题。等到软件定义网络即SDN统治了全世界的路由器,现在90%的中立就会变成100%中立。这种中立性对云用户至关重要,可以避免被某家供应商锁定,也可以在多个云中运行以增加冗余。不仅如此,不同的用例还可以运行在特定的云上。比如,有一个用于集成测试的云,还有一个产品开发云,还有一个beta版本云,它们都相对独立。但由于脚本可复用,部署就不仅仅是复制资源和可运行代码了。部署还包含了基础设施。这样每一次部署,都会有一套新的基础设施和一套代码。这样就避免了交叉污染。QA就不必再回答“在我的电脑上可以运行”之类的问题了。增加了新功能的测试套件可以在全新的基础设施中运行。而在出现问题时,也能够取得部署、代码和基础设施的完整快照。与以往模糊的快照和对错误的文字描述相比,简单天壤之别。更吸引人的是,大多数公有云都提供有限或全功能的REST API,支持用户对自己的云进行编程。这样在把代码从Github下载到前端和数据库服务器之前,我只要向自己的产品云发送一个REST请求就可以启动它们。

面临的挑战

基础设施即代码或可编程的基础设施要想普及,还面临一些挑战。

  1. 微软的产品仍居垄断地位。Linux基础设施是最灵活的。虽然也可以对微软产品做一些定制,但能到40%就不错了。一方面是因为Windows天生封闭,另一方面也是没人愿意专门给它写工具。不过Azure PaaS则是另外一回事。如果你对可编程的基础设施感兴趣,又选择了微软的服务,愿意多花钱,那么将会面临新一轮的锁定,即使用VMware的VIX或者SCOM(System Center Operations Manager)。

  2. 多层应用会导致脚本极速复杂化。如果再加上网络和安全组件,那就更复杂了。如果你要面对联网VM,要考虑vLAN的设置和安全问题,那么用脚本来部署就会变得异常复杂。vLAN可以看成VM,但编排语言并没有成熟到支持这种抽象。在我看来,趋势是从应用系统架构中砍掉这种变数。

  3. 必须先想好基础设施工具的基础设施。这个问题很怪异,你得先想好不同的编排工具在哪里、如何运行,这也需要基础设施,或者需要基础设施规划。鸡生蛋,蛋生鸡……。有时候,在VM中安装监控程序和代理,确保VM的安全访问真的很烦人。这件事说起来很简单,就像新设立一个监督部门,或者在Azure或AWS中选择一款VM模板,没啥难的。但有时候开发团队就是缺少使用理想工具的条件。

  4. 很多工具仍然需要专业化。今天,可以选择的工具仍然需要投入大量时间去掌握,包括原理、语言的语法等。相应的时间和金钱对很多机构来说仍然是不小的障碍。

  5. 如果你的应用全部部署在PaaS上,或者有PaaS也有云和on-prem,那么统一的脚本就是个大难题,必须考虑多个脚本。多个脚本协同运行又是问题。

以上是今后两年我预期会出现重大变革的一些领域。我相信这些问题会越来越容易解决。到最后你都不会相信还有人要自己手工配置基础设施。记得我最初接触虚拟化的时候,很喜欢说“机器都变成文档了”。现在其实也可以说一切都是应用,也就是一组文件,这些文件要按照既定的顺序执行。最终,所谓应用代码与运行它的基础设施要分开的想法,将会被人抛到九霄云外。不知道“可编程的基础设施”或者“基础设施即代码”最终会不会演变成“一切应有尽有”。但有一点可以确定,那就是应用可以包含运行它的基础设施的思想促进了DevOps运动,同时也带来了人们想象不到的灵活性。