【第22期】观点:IT 行业加班,到底有没有价值?

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

原创 2016年05月31日 22:17:05

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研发运维一体化的信息

qrcode_for_gh_b7c158df1fd1_430

版权声明:本文为博主原创文章,未经博主允许不得转载。 举报

相关文章推荐

划分用户故事(user-story)的原则

在敏捷开发过程中是通过用户故事来将需求具体化成可以进行迭代开发的一个个现实的可见的开发任务。因此在敏捷软件的开发过程中,用户故事的划分对于迭代和开发起着举足轻重的作用。 用户故事从其名字来看是站在用...
  • rxr1st
  • rxr1st
  • 2012-05-02 21:53
  • 11980

微软VS2010专业Scrum开发人员认证 - VS2010 Professional Scrum Developer

微软MSDN PSD 官方首页:http://msdn.microsoft.com/en-us/vstudio/ff433643.aspx微软在今年4月发布了全新的开发人员工具和团队协作平台Visua...
  • ups216
  • ups216
  • 2010-07-14 17:14
  • 3334

程序员升职加薪指南!还缺一个“证”!

CSDN出品,立即查看!

微软北京.NET俱乐部2010年6月26日活动 - Scrum模式不适合中国?

每一次讲述Scrum的内容的过程都是非常享受的过程,Scrum不同于一般的技术,他涉及了很多文化,工作习惯,项目管理,沟通技巧的内容,当然很多的东西并不是Scrum自己的内容,但是在任何的开发公司中要...

用户故事地图(User Story Mapping)之初体验

北京这几日的天儿真是好的出奇,白天风和日丽,晚上繁星漫天;在这样一个周六的下午,小编参加了一次北京敏捷社区(微信号:Agile1001)组织的活动:《用户故事地图User Story Mapping ...
  • ups216
  • ups216
  • 2016-01-11 11:26
  • 6627

面朝敏捷,春暖花开

面朝敏捷,春暖花开 从今天起,做一头敏捷的猪 编码、重构,单元测试 从今天起,关心测试和CI 我有一个团队,面朝敏捷,春暖花开 从今天起,和每一头猪结对 告诉他们我的体会 ...

创建用户故事地图(User Story Mapping)的8个步骤

[小编]上周六了解了用户故事地图后,小编又查阅了一些资料,找到了以下这篇关于如何组织用户故事地图规划的文章,分享给大家。也希望大家如果有好的实践,也可以留言一起交流。 原文地址:http://w...
  • ups216
  • ups216
  • 2016-01-12 10:15
  • 1339

这个错误,每个ScrumMaster都犯过

让自己从一名管理者变成一名协助者不是一件容易的事情,最困难的是克服我们内心的不安全感:“如果我不管他们,工作做不完怎么办?最后还得我来收拾!”其实有的时候,放手才是解决问题的办法,当然,放手的前提是由...

谈谈个人对持续集成CI的理解

持续集成 Continuous Integration作为极限编程的其中一个实践而出现的。但是其自身所体现出的价值却已经超出极限编程了。 目前在我们的项目中所采用的CI已经逐渐的从最开始的抵...

Scrum Master 面试题 – 你必须知道的22个Scrum基础知识

测试一下你是否是个合格的Scrum Master,以下的22个问题基本上涵盖了Scrum所涉及的内容,如果你能够正确回答出所有问题,那么你已经具备了作为一名Scrum Master的基本素质。
  • ups216
  • ups216
  • 2015-11-27 16:24
  • 1425

如何将用户故事细化为开发任务

原文出处:http://www.softwareandi.com/2011/11/how-to-break-user-story-into-tasks.html   将用户故事细化分解成开发任务是Sc...
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)