中小团队基于Docker的devops实践 - 掘金

标签: | 发表时间:2019-10-03 16:29 | 作者:
出处:https://juejin.im

笔者所在的技术团队负责了数十个项目的开发和维护工作,每个项目都至少有dev、qa、hidden、product四个环境,数百台机器,在各个系统之间疲于奔命,解决各种琐碎的问题,如何从这些琐碎的事情中解放出来?devops成了我们不二的选择。

文章是基于目前的环境和团队规模做的devops实践总结,方案简单易懂,容易落地且效果显著。

实现方法

先来看下流程图:



工程师本地开发,开发完成后提交代码到代码仓库,[自动]触发jenkins进行持续集成与部署,部署完成会收到结果邮件。项目运行过程中可通过日志系统查看程序日志,有异常会触发监控系统发送报警。从编码到上线后结果反馈都可以工程师自主完成,形成完整闭环,运维则负责提供完整流程的工具链及协助异常情况的处理,工作量减少了,效率却高了。

  • 自动触发jenkins部署通过svn和git的hooks来实现,是否自动触发根据项目内部沟通决定,我们目前没有自动触发,原因是QA在测试的过程中不希望被自动触发的部署打断,不过也可以方便的在jenkins上手动触发执行
  • jenkins从svn拉代码 --> 编译 --> JS/CSS合并压缩 --> 其他初始化操作 --> 生成最终线上运行的代码包,通过Dockerfile打包成镜像上传到docker hub,然后触发kubernetes滚动更新
  • 镜像包含了基础镜像+项目代码,基础镜像就是根据项目运营环境打包的一个最小化的运行环境(不包含项目代码),根据项目依赖的技术栈不同我们打包了很多不通类型的基础镜像,例如包含nginx服务的基础镜像,包含jdk+tomcat的基础镜像
  • 如果发现程序上线出错或有bug短时间内无法解决,可通过jenkins快速回滚到上一镜像版本,十分方便
  • 如果发现流量突然增高,可以通过kubernetes快速调整容器副本数量

软件和工具

  • 代码管理:svn,git
  • 持续集成:jenkins,shell,python
  • Docker化:docker,harbor,kubernetes
  • 监控报警:zabbix,prometheus
  • 日志系统:filebeat,kafka,logstash,elasticsearch,kibana

代码管理

大部分项目还是通过svn来管理的,这里以svn为例说明,每个项目有3条代码线,dev、trunk、releases

  • dev: 本地开发,开发好一个功能或task就可以提交到dev分支,同时可部署到dev环境进行自测
  • trunk:当一个大的功能开发完成计划上线前合并代码到trunk分支,QA部署到trunk环境进行详细测试
  • releases:QA测试通过,项目即将上线,则将代码合并到releases分支,部署hidden环境(仿真环境,所有配置、代码等与线上保持一致)再次回归,回归通过,则上线product正式环境

有些项目是基于版本发布的,那么在代码合并到releases之后会通过branch/tag打个tag部署到hidden测试

持续集成

这一步主要工作是按照需求把源代码打包为最终线上跑的项目工程,大部分工作都有shell、python编写的脚本来完成,例如去svn拉代码、编译源代码、对静态资源文件合并压缩等等操作。利用jenkins将我们这么多分散的步骤串成一个完整的流程,运维对这一部分应该很熟悉了,不过多介绍

Docker化

Docker是我们整个方案中很重要的一块,可以方便的进行部署,所有环境使用同一Docker镜像也保证了环境的统一,大大减少了开发环境运行正常,线上运行报错的情况出现,同时可根据项目负载情况实时调整资源占用,节约成本。

  • Dockerfile:通过编写dockerfile来打包镜像
  • harbor:充当docker hub镜像仓库的作用,有web界面和api接口,方便集成
  • kubernetes:kubernetes(k8s)将一个一个的Docker实例给整合成了集群,方便镜像下发、升级、回滚、增加或删除副本数量,同时也提供了ingress外网访问方式,这一块比较重,不过我们也没有用到太高级的功能,只是上边提到的一些基础功能,无需对k8s进行二次开发或定制,只是部署好了使用,对运维来说技术难度不大。

监控报警

监控报警在整个运维过程中非常重要,能未雨绸缪,减少故障的发生,加快故障的解决。这一块也是运维的基础不过多介绍了

  • zabbix:宿主机统一通过zabbix进行监控报警
  • prometheus:Docker容器的运行情况通过prometheus进行监控报警(目前还未完成)

日志系统

elk日志系统真是运维的福音,用了都说好,从此再也不用听开发给你说“xx,帮我拉下线上的日志”。我们使用的架构为filebeat/rsyslog --> kafka --> logstash --> elasticsearch --> kibana

  • filebeat/rsyslog:client端通过filebeat或者rsyslog来收集日志,filebeat是一个go开发的程序,部署起来非常方便,跟Docker简直绝配,我们Docker基础镜像里都默认起了一个filebeat服务初始化了配置文件,后边整合项目代码的时候不需要额外配置;使用rsyslog的好处是大部分系统自带了rsyslog服务,不需要额外安装一个程序来收集日志,但是rsyslog要传数据到kafka需要用到omkafka模块,omkafka对rsyslog版本有要求,大部分系统需要升级rsyslog版本很麻烦,就放弃了
  • kafka:kafka就是为处理日志类数据而生,我们采用3台机器做kafka集群,同时1个topic对应多个group,避免单点
  • logstash:作为为从kafka取数据,过滤之后写入elasticsearch。还在想为啥介绍kafka的时候说明1个topic对应多个group?主要是为了一个group对应一个logstash index,解决掉logstash这里的单点
  • elasticsearch:存储过滤之后的数据,同样采用了3个节点的集群,避免单点
  • kibana:可视化工具,方便的来搜索想要的数据,同事也做各种报表,一目了然

总结

  1. 支持:要获得各方的支持,项目已经成功了一半,没有啥事一顿烧烤解决不了的,如果有就两顿
  2. 规范:众多的项目,庞大的系统,必须要有规范,规范是自动化的基础
  3. 文档:实施的详细过程、如何使用、怎么维护要保留有详细文档
  4. 培训:对于jenkins、elk非运维使用的工具要对使用者有相应的培训分享,当然运维内部也要分享项目的种种细节

扫码关注公众号查看更多原创文章

相关 [团队 docker devops] 推荐:

中小团队基于Docker的devops实践 - 掘金

- -
笔者所在的技术团队负责了数十个项目的开发和维护工作,每个项目都至少有dev、qa、hidden、product四个环境,数百台机器,在各个系统之间疲于奔命,解决各种琐碎的问题,如何从这些琐碎的事情中解放出来. devops成了我们不二的选择. 文章是基于目前的环境和团队规模做的devops实践总结,方案简单易懂,容易落地且效果显著.

你的团队里没有DevOps文化?

- Quantum - LinuxEden开源社区-Linux伊甸园
本文是从 Do you have a DevOps Culture. 全球很多的系统负责人和程序开发者都在 撰写 、 聚会 和 讨论 关于DevOps的事:如何能更加有效的协作、让我们更快的创造商业价值. 阅读全文 | 邮件推荐 | 评论回复.

【外刊IT评论网】你的团队里没有DevOps文化?

- iVane - 外刊IT评论
本文是从 Do you have a DevOps Culture. 全球很多的系统负责人和程序开发者都在撰写、聚会 和 讨论关于DevOps的事:如何能更加有效的协作、让我们更快的创造商业价值. DevOps的目标是摒弃传统的深根于开发和实施过程中那种单打独斗的思考方式. 那么,你如何能辨别你的团队是否已具有DevOps文化了呢.

阿里为全面践行DevOps,分拆整个应用运维团队

- - 运维派
在2016年12月的Velocity China2016,阿里巴巴平台架构部研究员林昊(花名毕玄)发表了题为《阿里应用运维体系演变》主题演讲,其中透露了一个大新闻:. 阿里为全面践行 DevOps 思想,并进行组织结构调整:将以前的应用运维团队全部打散,并合并到各BU的软件开发团队中去. 这一举措,听起来颇有大将风范.

不同技术团队的配合问题及DevOps(不错的文章,来自infoq)

- wangdei - BlogJava-首页技术区
在IT企业里产品从创意到交付给用户,从整体上看是由技术部门负责,但如果深入到技术部门,会发现由不同的技术团队负责不同的部分或者阶段. 一般会分产品团队、开发团队、测试团队以及运维团队,在互联网公司里,运维团队一般还分基础运维和产品运维两个团队,基础运维负责基础设施(包括机架、网络、硬件)和操作系统的安装,为整体公司的所有产品提供基础设施的运维服务.

Docker & Flatpak

- - IT瘾-dev
目前最流行的技术莫过于Docker,Docker和Docker衍生的东西用到了很多很酷的技术,目前deepin应用软件发布转变成flatpak,这些看似风牛马不相及的技术方案,实际都使用了一个共同的底层技术——Namespace,假如没有namespace支持,这些技术实现都将成为空中楼阁. 一句话总结,无论是Docker、sysmted-nspawn还是flatpak,都是在namespace基础上,针对不同的场景,生出的不同的解决方案.

DevOps 实战

- -
DevOps 的 3 个支柱. 第 1 步:寻找合适的试点项目. 第 3 步:快速建立初期成功. 第 4 步:快速展示和持续改进. 第一阶段:每次提交触发完整的流水线. 第二阶段:每次流水线触发自动化测试. 第三阶段:出了问题可以在第一时间修复. 第二步:定义指标并达成一致. 第三步:建立自动化执行和检查能力.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

『DevOps 最佳实践』 — DevOps 实践

- -
Culture – 文化:公司各个角色一起担当业务变化,实现有效协作和沟通;. Automation – 自动化:在价值链中尽量除去手工步骤;. Lean – 精益:运用精益原则更频繁地交付价值;. Metrics – 度量:度量并使用数据来优化交付周期;. Sharing – 分享:分享成功和失败的经验来相互学习.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.