一个都不能少: DevOps的3大核心基础架构

DevOps的涵盖面非常广，因为这个概念的火热，又有很多文章和技术都在把DevOps的帽子扣在自己头上，让很多人迷惑不解。其实，DevOps的知识体系如果从顶层上来分解，只有2块：方法论和工具链。方法论这块，因为DevOps的很多理念脱胎于敏捷，所以你所能了解到的各种敏捷理念，实践和方法都可以作为DevOps知识体系的一部分，关于这部分后续我单独写一篇文章来谈。今天想要和大家聊聊的关于DevOps工具链这块内容。

前段时间看到有人整理了一个这样的DevOps工具链周期表，说实话，上学的时候就最烦背元素周期表了，看着这个玩意儿我只是想吐（声明：不是说这个玩意儿不好哈，挺好的东西，就是戳中了吐点而已）。

人类不善于记忆复杂的数据和零散的知识，所以需要简化简化再简化，一图解千言：

简而言之，实现DevOps工具链你只需要3个核心基础架构：

– SCM 配置管理系统

– Automation 自动化系统

– Cloud 云（或者说可伸缩的，自服务的，虚拟化系统）

SCM 配置管理系统

配置管理是DevOps最底层的基础设施，无论是Configuration As Code 还是 Infrastructure As Code 强调的都是用管理代码的方式来管理环境，将环境版本化对于无论快速创建，还是可稳定的重复创建这些DevOps的基本要求来说都是最重要的基础。

在周期表的左侧第二列所列出的就是各种可供选择的配置管理系统，如：GIT, SVN, Mercurial, GitHub, Bitbucket 等。对于实施DevOps来说，选择哪种SCM的一个重要考虑点就是后续的Automation和Cloud这两个环节中的其它工具对这些工具的集成情况如何。作为这两年的明星Git来说，这一切都不是问题，当然是最好的选择。

SCM中所放置的内容又可以再分成2个层次，分别为

AppCode：就是你的应用代码
EnvCode：就是环境相关的代码，这部分内容又可以进一步细化成环境配置(Config)和配置数据(ConfigData)。
- 环境配置：是那些针对当前应用基本上固定的环境配置
- 环境数据：是那些需要在部署的同时根据情况调整的数据，如：配置文件，开发／测试／生产环境的地址等等。

Automation 自动化系统

自动化在DevOps中的作用不用多说了，这部分的主线一般由各种类型的Build系统来实现，如：Jekins, Team City, Travis CI, CC等等。但仅仅有这些还不够，为了能够完成应用从开发环境到生产环境的迁移，我们还必须处理如编译，自动化测试，依赖恢复，容器构建，打包，编排等很多操作，所以还需要配置如：Junit, Xunit, FitNesse, Selenium, NuGet, NPM，JMeter等许多其它的工具来实现；但这些工具都只是在自动化系统中实现某一部分的功能，一般都是由Build系统来驱动，并依赖于SCM中所提供的各种代码来实现的。

在我的那张图中，所有这些内容最终会汇总到一个叫做MOF的节点，作为后续进入环境的起点。MOF是DMTF这个标准化组织提出的一个工具和厂商无关的描述性语言，当前已经被很多厂商所接受并正在工具中逐步实现，DMTF的厂商列表可以在这里查到：

http://www.dmtf.org/cn/about/list

说实话，各种DevOps部署工具的标准化做的非常不好，基本上你使用了某种工具就被绑定了，虽然DMTF提出了这个标准一段时间了，一些主流的工具对它的支持仍然有限，如：Puppet 和 Chef等。对于用户来说，熟悉了某种工具也不太愿意更换其它的，所以对于DMTF的前景我是持怀疑态度的。这是一场博弈，对于用户来说，有标准总比没有好，多了解一些总是好事。

Cloud云

虚拟化和云计算的出现应该是催生DevOps的重要因素，没有云所提供的弹性，自服务等特性，很多DevOps的理念只能停留在纸面上。

对于实施DevOps来说，我们需要了解的就是各种云所提供的API，因为无论是自动化系统还是前面的SCM的产出最终都需要调用这些API来完成最终应用部署。

这部分的内容很多，就不展开了。

写这篇文章的原因很简单，就是觉得东西太多，需要梳理，其中如有不妥之处，还望各位多多指正。希望这篇文章至少能帮大家找到了解DevOps工具链的入手之处，形成自己的知识体系，逐步扩展。

请关注微信公众号【devopshub】，获取更多关于DevOps研发运维一体化的信息