一个都不能少: 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研发运维一体化的信息

​