中小团队基于Docker的Devops实践

笔者所在的技术团队负责了数十个项目的开发和维护工做，每一个项目都至少有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将咱们这么多分散的步骤串成一个完整的流程，运维对这一部分应该很熟悉了，不过多介绍

关于持续集成更详细的介绍能够查看如下这篇文章

• 探秘varian：优雅的发布部署程序

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：可视化工具，方便的来搜索想要的数据，同事也作各类报表，一目了然

关于elk日志部分，我写有一个系列文章来介绍，这里摘录几篇感兴趣的点击查看

• ELK日志系统之通用应用程序日志接入方案
• Logstash读取Kafka数据写入HDFS详解
• ELK架构下利用Kafka Group实现Logstash的高可用

总结

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