DevOps系列(1)-总体架构

扯闲淡

在进入正式话题之前,先扯个淡,这算是第一篇我正式在博客上发布的随笔吧,之前也一直有想写点什么,将自己多年的工作经验分享出来,供大家参考点评,但是奈何一直对自己的文字功底不自信(其实也确实比较烂,上学期间,语文永远是拖后腿的),当然,最主要还是因为自己的懒惰,导致一直没有付出行动。

细算下来,到目前为止,我从事.Net开发已经差不多八年了,也算是一只见证了.Net从兴起到衰落(不知道这么说会不会被打)再到逐渐有复苏迹象的老鸟了。在这个过程中,带过团队,也担任过架构师(当时为了证明自己并非野路子,2018年还专门拿下了软考《系统架构设计师》认证)。在企业内部Wiki上也写过不少文章,做过不少技术分享,但毕竟是小群体,文章写得再烂(甚至只有提纲,或者只字片语,或者只有一张图),也可以通过沟通解释清楚,就算真的写错了,也会有很多补救措施,不会产生什么不良影响。而对外发布,对内容的完整性,严谨性以及文字组织能力的要求就要高得多,而这正是我不得不花精力填补的短板。

2020年注定是不平凡的一年,对于我们这些.Neter来说更是如此,我不确定能否通过文字完整的出自己的思想,但是我会尽力,希望我的文字不会带偏你的思路,当然,如果你能赞同我的观点,并能从中得到一点点启发,那将是我莫大的荣幸。

好了,闲淡扯完了,进入今天的正题吧!

总体架构

在这里,我准备结合自己的工作经历和个人理解,针对当前比较火热的DevOps话题出一个文章系列。但是,在这之前,有必要从整体上梳理一下思路,圈定一下范围,以保证整体思想的一致,并方便后续文章的展开。

这个系列并没有涵盖DevOps的全部内容,例如,没有包含服务的链路追踪、日志监控、健康检查等微服务相关的部分,也没有包括集群和容器的监控、管理、健康检查、报警等更偏向运维的部分,而是更多的聚焦在CI/CD上。微服务相关的部分后面可能单会独写一个系列详细探讨,而运维相关部分则不会过多涉及,即使是K8S容器编排也只会点到为止,因为这部分我自己接触的也比较少,不敢瞎写。

概览

DevOps系列(1)-总体架构

注意,这里的Jenkins并非部署了多套,而是在同一套Jenkins中根据部署环境的不同划分了多个分组,每个分组有各自不同的权限和功能。

流程说明

  1. 开发人员每次写完代码之后,Push到源代码仓库(企业中一定会有自己SVN或者Git等私有仓库,这是即使没有DevOps或CI/CD概念也会存在的最基本的基础设施,我后续会直接使用GitHub,因此不会单独介绍这部分内容),自动(或者定时轮询)触发Jenkins构建,完成Nuget包还原,静态代码审查,单元测试,上传报告到SonarQube服务器,如果构建失败,或者代码审查和单元测试报告不达标(实际工作中,由于各种原因,这个目标比较难以达到),则反馈开发修复,如果达标则构建镜像并发布到开发环境的Docker容器中;
  2. 开发人员功能开发完成,并通过开发环境容器测试通过后,将Dev分支合并到Master分支,并发送提测通知到测试人员;
  3. 测试人员(可以在分支合并的时候自动触发,或者定时轮询)构建Master分支,大体流程跟开发分支相同,不同点就是会发布到尽量贴近生产环境的Docker集群,同时将镜像Push到Harbor镜像仓库;
  4. 测试人员测试通过后,通知运维人员安排上线;
  5. 运维人员通过手动触发Jenkins的方式,先从Harbor上Pull对应版本的镜像,并逐步分阶段完成到生产环境Docker集群的部署。
  6. 剩下的就是生产环境α测试和β测试及一系列的监控了。

总结

DevOps更多体现的是一种思路和流程,可能每个团队做法都不一样,例如,有的团队可能在Dev分支上测试,而在Master分支上构建生产环境镜像;有的团队可能因为环境隔离的原因,不得不部署多套Jenkins环境等,但归根结底目的是一样的,就是达到全程自动化,减少人力劳动(不知道算不算自己砸自己饭碗)以及各种人力,环境等因素导致出错的概率。

后续的文章我会按照这个思路展开,如果存在考虑不周,或者可以改进的地方,希望各位大佬们能够及时指出,大家一起探讨,共同进步!

最后,希望.Net生态越来越好!