运维咖啡吧

追求技术的道路上,我从不曾停下脚步

中小团队基于Docker的devops实践

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

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

实现方法

先来看下流程图:

image

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

软件和工具

代码管理

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

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

持续集成

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

Docker化

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

监控报警

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

日志系统

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

总结

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