导航菜单
路很长,又很短
博主信息
昵   称:Cocodroid ->关于我
Q     Q:2531075716
博文数:356
阅读量:1746398
访问量:218312
至今:
×
云标签 标签球>>
云标签 - Su的技术博客
Tags : DevOps,架构发表时间: 2021-11-26 16:52:31

很高兴在这里跟大家做一次分享,我这次分享题目是全开源架构下DevOps的实践。在最近几年DevOps比较火比较流行,我在这两年里也是,有很多项目我们去学习DevOps,在项目里面实践DevOps,去总结了一些经验,借着今天这个机会跟大家分享一下,跟大家交流一下。

全开源架构下DevOps的实践全开源架构下DevOps的实践

首先简单快速来聊一下我对DevOps的理解可能我们今天的分享都会有这个环节,大体来聊一下我们对DevOps的理解。其实我也听过很多分享,也看过很多DevOps的书,大体上的框架都是一样的,但是可能各自的表达略有不同。

我对DevOps的理解是这样的,分几个环节,概念环节、流程环节、工具环节和目标环节。我们在DevOps理解上,首先是在概念方面,我们去做一件事的时候先要知道这件事是什么,为什么去做它,做它有什么意义,有什么好处。只有我们完全真正理解DevOps到底是什么的时候,我们去做的时候才会知道在哪里动手,知道怎么样做,知道自己在干什么,这样我们做的会产生一种极高的效率。

我们在理解的时候,首先在概念方面,DevOps是一种思想,是在我们软件开发生产实践过程中产生的一种思想,这种思想是经过我们漫长的开发过程来历练出来、提取出来的一种极致效率的,来解决我们在开发过程中遇到问题的这么一种新的思想,形成我们的方法论,最后通过实践来落地,最终我们的团队里形成一种DevOps文化。

我们在DevOps的实践过程中有个很重要的,就是在团队中形成DevOps文化,这种DevOps文化的形成要大于我们对DevOps工具的应用,因为工具可以变可以换,但是这种文化如果没有形成,空有工具产生不了很大的效果。

我们在流程上也是,DevOps对流程改造是巨大的,DevOps落地的情况下,我们对原来很多的流程过程都要进行改变,都要进行优化,冗余的要缩减,时间长的要压缩,不应该有的要删掉,缺失的要补上。

在流程里要涉及四个方面,开发、测试、运维,这是我们常常说的,另外一个是管理,管理很重要,管理是什么,让领导参与进来,参与到我们整个的DevOps流程制定,还有DevOps目标实现这个过程中,领导不能说我只负领导责任,别的具体都不管,一句话就完了,这不行。

这种在传统公司可能会出现为了管理而管理出现的情况,但是我们DevOps真正落地的创业公司、互联网公司没有这个事,所有的责任大家都要一起来扛,管理必须参加进去,如果管理没有参加进去,DevOps落地比较难。

我们有一系列的代码管理的工具,持续集成的,自动化测试或者部署的,有很多工具。最终我们要在实施DevOps之前想清楚一件事,我们为了什么来实施DevOps,把这个弄清楚了,可能我们的切入口就好办一些,我们就为了实现生产力的提高,快速交付,保证生产环境的稳定、安全,降低成本。这四个目标加在一起是非常难的。

全开源架构下DevOps的实践全开源架构下DevOps的实践

在组织方面,以我的实践来说,我在公司的DevOps团队组织方面,我建议按照我们传统里面理解的产品线这种方式来进行DevOps团队的组织,这样整个的效果会好一些,大家在一个团队里来共扛KPI,对于所有的质量都是共扛的。

但是我们在实践过程中,可能部门是不拆的,部门还有,开发、测试、运维还有,但是部门的人进行虚拟的划分,划分到一个产品线里。我的经验是产品线的考核占70%,30%的考核还是传统部门那些任务的考核,这个各公司有自己的实际情况,可以根据自己的实际情况来做一下。

我们在每个产品线里都有自己产品线项目的领导,大家都在一个船上了,这个产品成,大家都拿钱,败,大家都扣钱。

全开源架构下DevOps的实践全开源架构下DevOps的实践

成熟度模型,这个是给大家的一个参考,这里面的这些要求,我们通过成熟度模型,拿着成熟度模型来衡量我们公司目前处于的系统状态,系统是处于原始阶段还是在可优化阶段还是在某一个阶段。

在每个阶段,它在某一个环节里体现的现象是不一样的,比如在环境和部署阶段,在测试阶段,我有没有进行自动化测试,通过这一系列的考核来发现自己企业和公司的短板到底在哪里,我现在处于一个什么样的状态,这样我们才有一个切入的点。

如果你想直接一下落地整个DevOps的生产线是很难的,所以你必须要找一个点,我在哪一个点上发力突破,用我公司有限的人力和资源,把这个点做好,再做下一个点,这样以点带面,最终形成DevOps的落地。

全开源架构下DevOps的实践全开源架构下DevOps的实践

我们引入DevOps以后,其实我们要来跟以前比较,要考量要评估,也就是说我们在引入DevOps以后,看看我们历史的趋势。

我们在第一个,在瀑布流开发的时候,我们只看重点,我们看在瀑布流的时候,我们看时间占比是47%,一个软件整个组织过程中所有的时间,开发的时间只占了47%,其他时间都干吗了?设计占了25%,测试占了15%,我的部署占了13%,我们在瀑布流的时候,这种大的规划细化,整个开发时间占比比较少,开发人员始终在等着前面产品经理、项目经理、架构师等等。

我要把这些事都弄清楚了,都考虑了再开发,结果开发以后,经过很长时间的开发,N多功能一起来进行集成测试的时候,发现各种各样的问题,这样导致我们开发的节奏比较慢。

后来我们通过敏捷的实施,小步快跑,通过每一个周期,这种周期变快了,有问题能快速解决。但是Scrum有一个问题,没有考虑交付的问题,只有开发,形成一些迭代周期,只考虑开发了,后面交付以前一直被我们忽视。

所以当我们时代变到我们现在云计算时代了,基础设施的部署上线能力已经很快了。我们到敏捷的时候,对于环境部署还有交付这些的要求变得非常高。所以我们迫切需要一个新的理论来解决这个问题,我们通过DevOps的实施,将我们原来敏捷里没有解决的这些问题,把它解决掉,部署的问题。

全开源架构下DevOps的实践全开源架构下DevOps的实践

总结一下整个软件的发展过程,从瀑布流到敏捷到DevOps,应用架构是从大而全的架构到SOV的架构再到现在微服务的架构。在运维技术的方面,通过原来的命令行、脚本到后来我们用Python进行大规模的运维工具的开发,到现在我们进行平台化的开发。

全开源架构下DevOps的实践全开源架构下DevOps的实践

我们现在在实施DevOps的时候,要解决一系列的问题,基础设施的问题,中间件应用还有服务的问题,把所有一切的在四重环境。我们的研发测试、生产环境上全部自动化,让它run起来,只有在需要我们控制和暂停的地方才暂停,其他的全部可查询、可回滚。

全开源架构下DevOps的实践全开源架构下DevOps的实践

我们对DevOps进行了一个定义,我们通过这个定义来分析我们公司在哪块来做这件事,我们的定义是这样的,我们公司现在源码管理做得好不好,我们的持续集成做没做,我们有没有自动化测试环节,我们来持续部署。

我去年给一个很大的国家机构做了一次DevOps的咨询,我去的时候他们在做什么,他们在测试环境到生产环境去上线的时候用U盘拷,把这个包拷过来,交给那个工程师,他再插到哪个服务器上。

他们这样的环节特别多,每到一个环节里去都要很长时间才能把环境运行起来。经常出错,每一次升级的时候都非常困难,二三十个工程师或者是更多的工程师,靠到晚上多少点,然后第二天早晨熬到几点。后来我们经过一系列的变革,我们所有的升级全都是在白天做,没有问题。

全开源架构下DevOps的实践全开源架构下DevOps的实践

我们到源码管理这块来考量什么问题,就是我们的源码管理够不够先进,我们有没有源码管理,如果没有我们马上要上源码管理了,现在仍然有公司用文件夹来管理。

我们在源码管理里,我们在DevOps里,我们推荐用GIT的生态体系来管理我们的源码。这里也涉及整个团队Git的学习,构建Git的私有库,通过Gitlab。还有Gitflow、CR,整个过程run起来以后,每一个环节都是很流畅的,而且这个环节是我们历练出来以后它必须的环节。

剩下的我们代码管理用什么流程的管理,这个很重要,用Git以后会发现什么问题,Git过于灵活,到底用什么流程来控制我的代码。我们主要有三种方式,githubflow是最简单的是,直接开一个主干,开一个Master,我把Master克隆到本地,我在开发功能的时候,我创建一个功能的分支。从Master创建克隆到本地,开一个分支,开发完了推上去。如果再有人需要,再把它默认到本地,再合并到自己分支里去。这种比较适合大家都对Git比较熟,整个团队里面对Git用得还不错,几个人的效率也比较高,所以没有必要搞那么多花样去限制自己的效率。但是稍微大点的团队可能又要考虑了,这种有点不太合适了。

下面我们考虑Gitlabflow,在刚才那个基础上,建了几个分支,建了Master分支、预生产分支和生产分支,每次开发完之后,到预生产环境,他把它放到预生产那,如果到生产,再把它默认到生产那。是为了解决什么问题。

比如说我们发一个苹果,你在底下都测试好了,但是苹果想要上线需要很长时间,你上不去,你又不能老在测试环境呆着,所以你要建一个生产分支,把它放那,因为我已经开发完了,它在生产分支上堆着,堆了好几个生产分支的版本,是因为审核没有过。

Git flow是一个比较严格的Git的流程。Master只放线上生产的代码,所有的开发都从Dev的分支上开发,如果出现bug,现场修bug,再合并回去。整个Gitlab也是被业界最为接受的一个开发过程。像Jira、SourceTree这些都内置了对于Gitlab的支持。

全开源架构下DevOps的实践全开源架构下DevOps的实践

我们对自动化测试的要求是,我们从传统上不怎么做单测,接口测做,转换到我们做TDD,做单元,必须做单元测试,接口测,最小化的UI测,等到UI测的时候其实没有问题了,后端的BUG都已经处理完了。我们整个的单元测的要求覆盖率是要求达到70%。剩下我们还要做到一些代码的style的控制。

我画了一个简单的图,持续部署。对于整个的运维环境里,现在在我们生产里面,底层所有的账号是通过LDAP打通的,所有的运营环境没有暴露在公网上的,运维系统变得越来越重要,运维系统被黑,整个生产系统就被黑了。这是持续部署简单的逻辑图。

我们的工作通过DevOps组织起来之后,最终我们形成一个循环,我们始终在这种周而复始的循环中进行我们的管理和工作。我们让这个循环run的平滑流畅,整个过程中我们工程师会亲送一些。我们这些运维工程师要去承担更大的任务,去开发公司的一些基础性运维管理的平台,让我整个公司系统运行得更加强壮。

谷歌的SRE,SRE的要求是什么,一个运营工程师应该50%的时间是在自己的日常任务中的,50%的时间是在写代码、在维护自己的运维平台的,这是一种理想的状态。做不到这样的状态,我们也不能把100%的时间都放在处理故障上,这种团队是没有成长的,这种团队整个的气氛也会很差,工作压力太大,大家都在一种恶性的环境中来工作。所以我们作为工程师,为自己也好,为别人也好,要把环境改变,让自己的工作环境变得良好。

全开源架构下DevOps的实践全开源架构下DevOps的实践

DevOps一个发布流大概是这样的,我们在GOPS上还会发布一个更强壮的版本。我们开发工程师把代码提交上来以后,出发生产build,通过Maven,包括单元测,没有问题都通过以后,我们可以对测试团队进行提测,通过冒烟,那些基本的测试要做一下,但是不会所有的都回归。

到我的预发布环境,再到我的正式发布,通过灰度的方式来逐步将线上的集群把它发布,是这么一个流程。所以我们整个的过程做了很大的简化,这里面有很多的工具和来控制我们的过程。

这是我用到的工具,这里面大家很多都耳熟能详。我们用Git来做版本管理,SaltStack来做开发的PC端的版本管理,用Jenkins做编译和持续集成,用ansible、Puppet来做配置管理、环境管理,用JMeter做压力测试,底层可能是公有云、私有云,日志用ELK,我们用Docker来做持续集成的小平台等等。

这是Gitlab的一个截图,整个项目里有746个库,有371个开发人员,这是当时我在这个项目的时候,37个团队,这里面每天各种任务或者push,这都是上万次的任务。

这是Jenkins的界面,我们有几十个产品、APP等等,这是个整合测试,我们将JMeter整合到Jenkins这边来了。

全开源架构下DevOps的实践全开源架构下DevOps的实践

DNS系统有个泛域名是指到Nginx上去的,每当提交一次项目,会直接发个邮件给相关的开发和测试人员那边去,测试人员通过域名就可以访问这个项目,进行相关的测试,这是我们自己写的一个容器平台。

CMDB每个公司应该都是需要的,我在不同的公司做了不少这样的项目,但是没有一个能够开源的,为什么,因为和系统耦合度过高。

今年春节的时候我闲着在家没事,写了一个开源的CMDB,功能大部分都有,但是如果自己用的话,根据我这个基准大家可以调一下,如果有公司没有CMDB,可以把这个用下去,因为你好多基础的工作可以不用做了,包括一些基础信息的配置。

这是一个导航界面,我做这个是要把我们说话的平台做一个入口,这个很简单。

这是一个CMDB的界面,这里面我们CMDB的基础功能都有,也会有自动录入的功能,我们有一个脚本直接在目标机器上执行之下,它就会把信息自动上报到CMDB里,有直接来导入的API的接口。

我还写了一个任务编排,当然这个任务编排还没写完,目前只支持推送任务。我和ansible来进行一个结合,我把CMDB里面的信息,我在这可以做一个下拉的选择,我在选择安装什么样的,一点执行直接就推到目标机器上去了。也做审核,所有的任务都在后台的日志打出来了。还有个shell的执行,和这个类似。

这是开源的,叫做AdminSet,在github上已经公开了。

...阅读原文
推荐文章