前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >韩沛:腾讯云原生Devops实践之道

韩沛:腾讯云原生Devops实践之道

原创
作者头像
腾讯云开发者社区技术沙龙
修改2018-12-29 17:16:58
1.4K0
修改2018-12-29 17:16:58
举报
文章被收录于专栏:腾讯云技术沙龙

12月15日,由腾讯云主办的首届“腾讯腾讯云开发者社区开发者大会”在北京举行。本届大会以“新趋势•新技术•新应用”为主题,汇聚了超40位技术专家,共同探索人工智能、大数据、物联网、小程序、运维开发等热门技术的最新发展成果,吸引超过1000名开发者的参与。以下是DevOps分论坛的演讲内容,稍作整理,分享给大家。

Devops的理念在从十年之前提出,近两年又重新被提出来,有云计算发展的原因。另外在互联网本身创业的时候,会产生大中小各种公司,它的运维体系完全不同,根据公司本身的规模、业务场景完全不同。这时候Devops希望能够为各类运维场景解决释放生产力的理念,开始仅仅深入人心。特别是在云时代,有各种各样的大云厂商提供了基础架构直勾。所以人们对devops本身能带来什么,可能产生了比之前更多的思考,因为devops的价值是和云时代运维开发体系的发展方向是相契合的。

在人们重新把devops提到前台的时候,会发现devops之前被置疑的一些问题依然在那里。回溯一下,如果通过devops的体系架构,是否会重新定义之前开发、运营、测试的边界。我们希望通过devops实现自动化,实现自动化以后对运维的自动性和安全性如何做到保护。而且很多企业都有各种系统,如果你构建了新的系统是否会对这些系统产生冲击,如何兼容之前的系统。特别是大中型公司,他们的devops体系要涵盖多种体系,基本上是不可能的,这样相当于你特闷的系统一定要进行二次开发,怎么让各个业务团队熟悉掌握这套系统,并且适配他业务的devops流程,如果这个问题不解决,这个系统最终很难推动下去,这都是需要我们思考的。除了这个和人更相关的原因之外,其他都是与纯技术相关的。所以大家考虑devops的时候,必须要先解决这个问题,否则这个系统没有办法达成这样的目标。

虽然devops有这样那样的问题,但是有一点是不变的。目前国际上应该正在制定devops的标准,已经制订了一部分,但是这个标准可能在2019年的时候生成一个国际化的规范标准,但是是否有了这个标准,决定了devops所有的路径都是一样的?不是的。针对不同的公司、组织,不同的发展情况决定了devops实现的结构。举个例子,对腾讯来说,大家知道腾讯本身在国内是大型的互联网公司,他的业务非常繁多,而且属于比较成熟的经济结构,对于他来说他的devops路径一定不会和一个初创公司或者中型互联网公司一样,因为他们覆盖的场景和内部的组织架构非常不一样。我们认为一个真正的公司想实现devops,一定要考虑自己的基础情况。从自身的条件出发,制定一套符合devops标准的流程或者体系。这样其实对你来说,就是对你最好devops的一个东西。这些,也是以腾讯为出发点,在腾讯的内部,我们是怎么构建一个对内部业务更良好,对内部业务系统升级来说更平滑的一套系统。

在这里介绍一下Tencent Hub的背景。腾讯今年10月11日刚刚过了20岁生日。这个公司已经发展了20年,他从始开始的一个互联网的软件公司,变成了互联网公司;从最初很原始的,在物理环境里面维护自己的软件,到开始大规模的生产虚拟机来应对规模的增长、业务的细分,再到最后已经数不胜数的业务。比如说一个B机里面有近万个项目,开始用容器来进行交互,来叫做标准化,这个流程相当于是腾讯本身运维走过的多个阶段。现在腾讯内部开始大规模的容器化,但是还没有在容器之上进行编排,这个容器没有任何容器编排系统架构在里面,我们现在正在做的第四次,希望把容器的编排体系引用到我们的体系中。比如大家耳熟能详的K8S,我们内部是相当推崇K8S的,我们希望通过K8S能够把运维做的更好,在这样的背景下我们诞生了Tencent Hub这个产品。它是服务于本身腾讯内部业务和公有云上的用户,使用K8S来拓展的业务,所以他希望提供一站式的K8S平台。

通过这一年的发展,我们发现K8S的概念渐渐深入人心,特别是运维开发者,或者是一些关心基础设施的传统开发者,会对K8S的架构或者理念持有一种开放的心态,开始积极学习,或者引入公司的内部。这套东西他能带来之前传统运维对我们来说,能帮我们解决很复杂的东西,或者通过大量的人力解决这些东西。这个系统在设计的时候,主要功能会分成两个模块,第一个是托管服务,托管的是对所有K8S的业务会有相关制品的管理,包括容器的镜像,还有容器管理,然后K8S本身的编排软件,这些文件的托管,通过Tencent Hub的引擎,可以和腾讯内部其它的平台打通,最后通过我们的制品和其它的测试平台、代码检查、底层的运维平台打通之后,来维护运维环境里面的K8S服务,来实现升级或者是无干预的自动部署。这里有三种托管格式,每一种针对性非常强。制品文件,我们认为二进制文件是难免会存在的,包括二进制文件、配制文件,这些东西是一定会涵盖在你的系统架构里面,是必不可少的环境。然后容器镜像的托管,把集成在Tencent Hub里面,这也是Tencent Hub名字的来源。而Helm chart对业务来说有一定的门槛,我们希望通过某种编排手段,把它的应用做的更加抽象,而且最近推出了一个项目,专门推广各种各样的Tencent Hub文件,我们也集成了Tencent Hub的托管,TKE是一个更加原生的K8S平台,稍后会有我们另一个同事来讲解,我们希望通过Tencent Hub,把它放在定制化的产品中做,所以我们做了Tencent Hub功能,集成了Tencent Hub的托管服务。

第二个大模块,Tencent Hub最核心的功能,就是devops引擎,我们实现了devops引擎,跟市面上限大家通用的不太一样。我们在设计的时候,几个devops的标准,我们是保持一致的。比如说我们的编排一定要做到通用,你可能是面对CD的某个场景,可能是构建,可能是测试,但是通用是一定的。所以我们内部的编排叫做workflow,是一个通用的编排软件。然后workflow里面的插件一定要做到通用,方便团队二次开发。我们本身是使用K8S比较成熟的团队,所以我们使用K8S来使这套系统做到更好的交互性和稳定性。

Workflow,是一个CACD流水线的东西,流水线的每一部分逻辑我们都stage,stage里面可以有多个逻辑,并行执行、串行执行都是可以的,区别在于我们的devops运营环境不是统一的。类似于(英文),你一定会选择一个stage环境,你选择了以后所有的软件都会在这个环境里面执行,它的好处是你执行的过程中,你的效率是稳定的,而且效率会相对比较高,但是它带来的问题是通用化的。首先你的各个逻辑之间必须是依赖于第一套环境的,这样很多东西无法无缝改造,我们这套设计的时候,我们的环境是维护在devops层级的。

整个Tencent Hub,我们除了会在UA上做到这种边际之外,我们在思考开发和运维的工作边界,开发人员未来是否会有自主权,或者运营人员可控的范围会更多,我们在做这个尝试,希望能给开发或者运维一种能够超越自己便捷的能力。比如说一个workflow是开发来做的,或者一个运维,除了发布流程,本身的发布工作之外,他可以制定发布里面的逻辑,甚至是以前开发可能完成的工作。

这个Job级别的上下文传递,传统的Tencent Hub里面运维环境是一致的.一旦启动起来,是需要重新配制的,它一定是一个静态的文件,或者一个固定目录的输出。我们做到了一点,可以做到一个每一个流程中可以感知到上一步的结果,而且每一步中可以做到人工干预。换句话说你可以对你的流水线中每个环节都制定一套系统,这个可能来自于上面其它结果的输出,或者来自于任何一个地方。而我们实现这种功能的原因,实现了两点,第一点执行环境的隔离,不是同一套执行环境,实现它的原理,使用了本身Tencent Hub的容器化设计,包括每一个逻辑独占一个逻辑,这样每一个流水线启动的时候,他会根据顺序逐步起动,因为容器本身保证了执行环境的统一性和标准性,本身任务执行的时候每个任务都有隔离的环境,并且容器的高统一性,可以不依赖于腾讯内部的saas。第二点复用,流水线里面的任何一个逻辑都是可以拿来复用,比如说传统的插件或者官方提供的插件,他有一定的成本,但是他也是这样的理念,我希望一个开元的插件来帮助有同样场景的人来使用这个功能,另外我们维护流水线的插件就像维护容器一样,任何一个工程师都可以维护这个插件,而且可以把自己的逻辑加入进去,这是标准。平滑的话,我们不依赖于之前的环境,而是希望他能够提供给我一个容器的环境,我可以把它提供到我这套系统里面。另外维护,通过整套系统的逻辑化,我们把这套系统基于Helm chart来运维和托管,来保证它的稳定性和可用性。

K8S,我们不仅是实现了简单的类似于(英文)东西,而且事实上我们还把整个系统的组建和工作流里面的组建进行了容器化,让它托管到K8S,更多的是我们用K8S实现了一个面对这种场景的CRD,这个CRD其实是DAG的(英文),workflow可能只是他的一种,我们现在通过workflow的场景提供了这个CRD,基于这个CRD我们会探索他在大数据、AI上面的场景是否能并行用。

Controller是我们的一个探索。关于Controller实际使用举一个例子,比如说从制品仓库到应用,中间可能会涉及到健康检查、功能测试,新旧版本进行了流量切换,新旧替换。这些步骤我们是通过DAG的形式,A到B到C之间,可能是A1执行完之后执行者B1,也有可能A1执行完之后直接执行C1,来实现这样一个应用的场景。但是事实上不仅如此,真正这套东西一切都可以workflow来做,这也是我们用了DNG的一个好处,而且它可以达到很标准的管理流程。包括你从CA过程,从代码检查一直到自动构建,构建完之后存到制品库,无论是内制的制品库还是第三方的(英文),都可以,然后再到CD的过程里面,包括人工干预的东西,都可以做在这里面。

这套东西做出来是否有真正的实践场景或者应用实验,其实是有的,我们通过Tencent Hub进行衔接,从原码一直到环境维护,之间devops的私有化部署方案,而且这个方案已经在两三家国有企业里面进行了推行。关于内部,因为我们的一些核心理念和腾讯云本身的发展是相匹配的,所以他的一些服务K8S,或者是这种兼容K8S的设计,是和腾讯本身现在的大量业务,运行在传统的环境或者devops环境里面,和K8S这个流程是相匹配的。所以在内部开始有很多业务,在上云的过程中,他们开始依赖于这套系统来做,包括覆盖了我们内部的多个业务,覆盖了腾讯云FT的各个行业,在给客户提供或者交互的时候,多个解决方案里面都有Tencent Hub,包括运营的环境还有内部的一些管理,今天另外一个主题,开发式平台,都会做成了打包式的解决方案。从外、从内,这个产品至少在腾讯内部,是我们探索的一个方向,而且是渐渐在开始使用。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档