Apr 14

Docker3.0 过程总结 不指定

djangowang , 12:35 , 工作相关 » Docker , 评论(0) , 引用(0) , 阅读(382) , Via 本站原创 | |
作者:研究僧
文章地址:http://blog.puppeter.com/read.php?56

开篇
       我们在2015年中的时候就在做Docker1.0(琥珀 http://blog.puppeter.com/read.php?4),当时主要针对离线场景。到2016年初 Docker1.0(琥珀)已经小有规模,同时也解决了很多生产环境的问题,而得到大家的认可。在2016年3月份中心内部开始讨论要做在线Docker版本,而这只是需求并不是目标。所以我们从需求角度出发设定了目标,当时针对中间层(spp ,内部组建工具)业务进行了调研,设定目标是做在线业务的弹性伸缩,主要是通过Docker来解决资源的快速扭转,这样大家使用机器时一方面可以更方便地获得,另一方面可以减少人为参与上下线,将有限的人力用到更重要的工作中,使大家能快速学习与成长。
点击在新窗口中浏览此图片
  上面的这幅漫画很生动地描写了我们当时的心情(因为整个项目的难点不是技术,而是如何改变用户习惯与思路), 围绕这一小目标从2016.3.31发出第一封Docker邮件到目前已经有一年多了,经历了多次的PK,从技术选型、是否使用开源、人力的配备、项目的优先级等内部讨论,到为什么搞了这么久没有上量、Docker搞了这么多版本是否有意义、Docker的长期目标是什么、是否可以保持现有织云体验等外部质疑。我总感觉项目走在十字路口,选每条路可能都是对的,但每一条路都未必是捷径,总是在被挑战中。这里我不得不承认确实理想很丰满,现实很骨感,我们在谈理想时总想着要把我们的运营系统往前再走一小步,而落地到现实时,往往需要更多的时间、人力、每个人的情怀、领导的支持、需要顶住外界压力、寻找更多合作团队一起努力才能达到目标。 本邮件主要总结我们在项目运作中遇到的问题、对项目的疑问、我们的思路等。


0)如何开发一个项目
    因为我个人并不是专业的项目经理,所以项目开发的过程也是我学习的过程。我也在思考如何能把整个项目做的更好,能尽快达到短期小目标。前期我参考了软件工程的方法论需求分析、概要设计、详细设计、测试、维护和用户手册等,但感觉不是特别适用于互联网的项目管理。譬如软件工程中的详细设计基本拿到文档就可以开发写程序,而目前我们还做不到这样的详细设计,所以只能部分借鉴。后期我参考了《打造Facebook》一书其中的一章,个人感觉还是比较适用的,但在原有的基础上我也补充了一下本项目开发过程中的案例。
点击在新窗口中浏览此图片

1)描绘远景,设立目标
描绘远景,设置短期、中期和长期目标,这样在不同的时间需要的伙伴与切入点才一目了然。以下是我们项目的一个基本项目流程图(图2):
点击在新窗口中浏览此图片
图2 Docker项目流程图


2)头痛的需求分析
在收集想法,排查优先级的过程中我们也出现了一些问题。
前期我们会找很多业务运维与开发同事进行需求分析,分析的问题是用户从不同的角度结合自己业务来向我们提出需求,就导致了平台满足A用户就满足不了B用户的问题。
收集同事们的开发观点如下:
1. A开发,希望通过Docker能管理从开发->测试->上线到持续集成的整个流程。
2. B开发,希望能用开源工具譬如k8s来管理Docker,这样更符合业界玩法。
3. C开发,只要系统稳定能提供资源,使用什么都无所谓。
4. D开发......
收集同事们的运维观点如下:
1. A运维,希望保证与现网体验一致。
2. B运维,希望可以实现弹性伸缩,解决快速扭转设备及成本问题。
3. C运维,希望能实现弹性伸缩,解决人力参与问题。
4. D运维,因为其他BG都在搞混合部署,我们也不能落后,希望通过k8s把业务管理起来。
5. E运维 .....
以上是真实的前期需求分析,有意思的是这里有的问题是互斥的,具有代表的譬如A运维与B\C运维的需求,保持一致是保持完全一致还是部分一致莫衷一是。这种情况下,就还需要分析老系统为什么不能实现弹性伸缩,分析出老系统本身确实无法实现弹性伸缩,新系统又想要和老系统保持体验一致,这就是互斥的问题。上面只是我们遇到的一个问题,类似的情况还很多。这种感觉有点像做数独游戏(见图3),业务主要关注横向相加的结果,而我们还需从全局出发关注横向纵向的安排。所以分析下来有时会有点头痛,无法完全按照大家观点来开发又需要权衡大家的观点与意见,同时又要尽量反馈大家我们这样做的原因,所以有的时候系统开发出来,再找之前的用户时,会被吐槽并不是其想要的需求。

3) 总结版本控制的三个优点:
1. 方便总结与回顾。
记录每个版本的细节可以更好的回顾总结项目中遇到的问题、难点和后续优化空间等,为未来开发项目沉淀一些经验。
2. Deadline(截止时间)才是最大生产力。
每个版本都有版本的启动时间与截止时间且都由个人自己评估确定。我们工程师一般情况下每天或多或少会被一些紧急不重要的事打断,而项目在组内又有很多交集,如何确保合理安排项目时间交集部分减少不表要的等待时间管理,事物优先级排序就很重要,有了Deadline就是最大的生产力。
3. 版本一旦确定不接受其他任何需求。
特别在开发与外界交集比较多的项目过程中时间难以把控,只能是尽量的协调控制外部交集的时间点所以一旦需求确定,哪怕加一个很小的需求,项目之间有依赖关系都可能会导致项目的延期或项目质量的下降。关于时间评估这里有一个经验值,在开发与外界交集比较多的项目过程中,尽量是自己评估时间的1.5倍到2.5倍间,具体视情况而定。

4) 是否采用开源工具
我们现在采用了自研的方式来管理我们的Docker容器,但在开发的过程中也不断有同学推荐开源的工具,譬如messos\swarm和k8s等这些工具都非常优秀且有着庞大的用户人群和市场空间,我了解到的很多创业公司都有在应用,个人觉得这些工具的设计思路非常先进有很多借鉴的意义,更重要的是他就像一种行业的协议,特别在与其他公司交流时虽然公司的业务不同,但用了相同的协议这样交流起来更顺畅同时收益也更大。个人并不排斥开源工具甚至更推荐用谈理想没有问题,但现实把这些工具在内部落地就很困难,总结原因有以下两点:
1. 因为部门大、产品多、产品历史背景长、复杂接口调用、高于一切的安全管控和与老运营系统兼容等,在落地的过程中都需要考虑周全,而开源工具内部落地遇到这些问题不免需要进行二次的开发能力、这种能力不是一个人而是一个组都需要具备的,特别在海量运维场景下不同产品有自己的业务特性,开源组件未必满足业务特性,导致异常查找成本会很高。还有在看到其他的部门在使开源工具为符合内部业务情况下进行大量二次开发,当业界升级工具时又需要持续迭代等头痛问题。
2. 引入开源工具譬如k8s需要开启NAT功能而内部系统都是定制的为了安全关闭了部分功能的情况下又要打开,又要保障系统安全这两个问题是需要慎重思考与权衡的。
所以按短期目标来看,我们还是使用了自研的方式来管理我们的Docker容器,长期看开源工具已经在我们的蓝图中。

5)  原生Docker思路在内部应用未必是对的
Docker 官方文档强调(build - ship - run) 其中:
build: 构建镜像,把整体环境软件依赖包和操作系统用户态构建成镜像,更新配置通过版本区分镜像。而构建镜像方式又分为两种:
           1. 直接将软件包安装到已经生成的Docker中来打包构建;
           2. 通过Dcokerfile来构建镜像
           这两种方式我们都有应用,其中1对应Docker2.0 ,2 对应Docker3.0
ship: 通过docker register 来分发构建好的镜像。
run : 只要kernel支持,上层使用标准的协议镜像,就可以运行在各种环境下,迁移非常方便。
问题出在升级镜像版本时需要重启镜像,这种方式有优势也有缺点,看在什么场景下:
优点:
1.在并行开发环境下,通常最头痛的问题就是环境不一致引发的线上故障。 而在Docker场景下开发只需要关注镜像版本,运维只要关注资源利用率,OD分离互补干扰,解决资源利用率同时也解决环境的问题;
2.现网环境一致实现标准化,有了标准化就可以实现自动化;
3.镜像生命周期短,每次更新版本镜像需要重启镜像,如果程序质量有问题,譬如运行时间长oom ,进程不释放fd 导致磁盘满情况都能很好的解决。
缺点:
海量运维场景下,线上环境频繁的变更,Docker生命周期短频繁重启不现实。当然Docker在这方面也是有考虑的,譬如分层文件系统的引入,但分层文件系统有128层限制,且目前测试情况看到40多层性能出现下降,而负责的业务在部分场景下可能1小时内发布频率就超过128层限制,所以这种方案是有问题的。
在开始我一直认为推动我们的系统往前走一小步,让频繁变更的业务适应Docker比较短的生命周期是正确的,但实践证明海量运维场景下Docker原生思路中的优点在我们验证下是不可以的,因为业务分层运维、配置频繁变更、运维的生态系统不完善都是问题。 或许在不久的将来,整体运维观念改变,运维架构上有更方便的调度系统与服务发现功能的背景下,使用Docker原生思路才是对的。

6)规范”如果没有工具的辅助就相当没有规范
我们为什么要制定规范,因为规范是标准化的前题,而自动化又是基于标准化基础之上,所以我们要制定规范。但问题来了有规范就一定可以实现标准化自动化? 这个真的不一定。生活中法律是一种规范,如果一个美女穿着很暴露的衣服走在夜晚12点后的街道小巷,即便有法律这种规范遇到色狼的风险也是很高的,如何避免呢? 提高法律的惩罚力度? 我觉得会有点效果但治标不治本,这时美女要尽量不穿着暴露的衣服,尽量不要在夜晚12点后出门,即便出门也不要走街道小巷,才会大大降低遇色狼的风险概率。做系统与架构也一样,通过规范来让系统标准化收效不大,规范与法律相比并没有更多的处罚力度,这就直接导致了规范不到位,标准化没有里程碑,自动化遥遥无期。
我曾想借鉴一下业界譬如某阿是否也遇到过我们目前面临的问题,他们是如何解决的?是否可以借鉴。一次机会听某阿朋友分享容器其中也提到了规范,某阿一直想试着梳理规范流程因为某阿也分很多bg(business group)不同bg运营的业务不同人也不同导致规范也不同,在一个公司体系下业务有可能会被轮换,不同业务轮转到不同的规范下又要保持业务正常运行短期只能加人,长期需要梳理规范,分享的嘉宾也说曾多年试图将这里的规范梳理统一但是发现比较难,推动成本也比较高,所以这里container(集装箱)是解决的方案之一,试想一下集装箱的发明正式把很多不标准的东西变成了标准尺寸,这样在码头才可以通过工具自动的搬运这些集装箱提升人们的效率。而先有了规范再通过工具去约定,这样才能达到我们预期的效果。


待续。。。。。。。。。。。
发表评论

昵称

网址

电邮

打开HTML 打开UBB 打开表情 隐藏 记住我 [登入] [注册]