Spring Cloud与Docker的完美结合,运维能够不用拜菩萨啦

        运维号称背锅侠,系统升级出现问题、网络出现问题、系统宕机等都会被推到运维头上,就连各大网络公司平台一旦出现问题,也老是运维人员来背锅,包括前段时间阿里云故障,听说也是运维失误形成的!这些问题说明运维工做的复杂性、重要性以及危险性,稍有不慎就有可能“灾难降临”。我之前的一个运维同事常常说,每次升级的时候都胆战心惊,真应该请尊菩萨来拜拜,而我也未尝不是呢?曾经咱们每次升级都不是那么顺利,总会有不一样的问题出现,复杂的时候可能会折腾一宿。印象最深入的一次是由于运维升级的失偏差点让咱们整个技术团队集体“下课”:那天下午两点当时公司的老板要参加一个互联网大会来宣传咱们平台的新产品,而咱们因为系统还有一些问题须要临时升级,原本想着挺简单的一次升级,却在升级过程当中因为操做不当整个平台被所有宕掉,怎么都没法启动。当时脑子一片混乱、手脚发麻(由于我是技术负责人),却怎么也排查不出问题,我当时都想好了要引咎辞职,幸亏在大会开始前半个小时终于查到了缘由,顺利的恢复了系统的运行!此次事件给咱们全部人都上了一课,必定要重视运维,而且必定要作到全自动化运维,一键部署那种!可是因为当时咱们技术的局限性,运维人员也不是太专业,好的运维人员又请不起,咱们只能本身研究,本身一点点去完善。java

         后来我在搭建新的技术平台作技术选型时采用了spring cloud这种新型微服务架构,在研究这个框架时接触到了docker,在深刻了解spring cloud和docker的机制及运行特性后,我看到了一键式部署的曙光!说干就干,我立刻召集了我团队的另一个技术人员,咱们分工研究,并结合阿里云平台,最终完美实现了真正的一键部署!下面我主要介绍一下咱们的搭建思路,本文仅提供大体的解决方案,不去作深刻的理论探讨,因为做者水平有限、平台较小,因此不少问题可能没有考虑到或者没有作到更好,也欢迎你们共同探讨!git

        1、采用swarm集群spring

        因为多docker之间的相互访问只能在同一宿主机,而咱们在真正使用中确定不止一台宿主机,因此咱们采用了swarm集群!个人理解是swarm集群将多台宿主机装在一个大的主机盒子里,让docker认为swarm集群就是一台大的宿主机,从而实现只要在这个大的集群中全部的docker都可相互访问。固然,咱们宿主机所有采用的是阿里云的ECS,因此咱们也就理所应当的采用了阿里云的Swarm集群!docker

       2、将服务打包成镜像shell

       Docker通常采用“一个容器一个进程”的方式,而咱们每一个微服务也都是一个spring boot应用单进程,直接采用java -jar的形式便可运行应用,那么咱们只需将咱们的一个服务打包到一个镜像中便可。那你可能要问了,那不一样环境下配置文件不一样,岂不是不一样环境同一个服务要打多个镜像?非也,你可能忘了spring cloud是有专门的配置管理服务的,spring boot是能够读取docker中的环境变量的,而docker的启动是能够采用docker-compose来编排指定的,咱们放在后边讨论!咱们是采用maven来管理项目的,打包镜像这事是否也能够交给maven来作呢?是的,maven有专门提供docker打包的插件!每一个服务下面都有一个专门的docker目录,放置了Dockerfile及镜像中须要用到的文件,Dockerfile的内容就再也不专门讲解了,你能够根据本身项目状况来编写本身的Dockerfile!须要注意的是截图中的镜像版本号是一个动态的,每次升级可能都会进行改变,方便紧急的时候回退到某个版本。服务器

         3、配置Jenkins网络

        采用jenkins来进行统一的项目打包、镜像推送。其实我说的一键部署就是指Jenkins中的“当即构建”这一键!jenkins普通的打包编译配置就再也不讲了,主要就是下图中来真正实现这关键的一键的。经过下图shell操做后jenkins会将打好的镜像包推送到阿里云容器服务中的镜像库中。架构

        4、用docker-compose进行服务编排框架

       微服务通常都会有数个、数十个甚至数百个服务在运行,并且每一个服务有可能还会同时跑多个,咱们不可能手动进行启动运行,那么这时候咱们就须要进行服务编排了!运维

这里咱们指定了该服务启动时的运行环境、运行数量、数据卷映射(能够建立NAS数据卷作为通用数据存储)、指向的阿里云SLB等,结合着spring cloud的统一配置服务,咱们能够经过采用不一样的docker-compose编排来区分不一样环境

      5、建立应用

   在服务编排作好以后,就能够直接使用该服务编排去建立一个应用了,建立完成以后便可直接进行启动

启动中指定要使用的镜像版本,请关联第二步的镜像版本号

补充,第三步的时候并无真正的彻底作到一键部署,除了点击当即构建以外,还须要到阿里云容器服务的应用中点击从新部署,若是须要彻底实现一键部署,那就须要在应用中建立触发器,并完善到jenkins配置的脚本中便可

        6、部署到生产环境

        测试经过以后须要部署到生产环境,传统的部署方式要么是经过对测试经过的代码包进行拷贝,并对配置文件进行更改;要么就是经过svn/git中的版本控制从测试到生产的迁移,再进行jenkins的预生产环境测试,可是不管哪一种部署方式都很容易出问题:1、漏改、错改配置文件;2、代码合并/迁移过程当中产生新的问题;3、生产、测试服务器环境不一样,环境差别形成的问题。但docker镜像是一个单进程的应用,并且只要宿主机运行docker没问题,那么docker重的环境也不会出现任何问题,咱们将经过测试的应用从测试环境迁移到生产环境就很简单了,只用提供不一样的docker-compose服务编排,生产环境直接经过变动配置更改镜像版本号便可

        7、日志采集

        Docker容器没法进行存储,只要容器从新启动,那么全部在启动过程当中产生的数据都不复存在,如何存储日志呢?第四步中咱们作的数据卷映射就能够派上用场了,咱们采用的是一个网络NAS盘,将这块硬盘同时挂载到另一台单独的ECS服务器上就能够访问全部的日志文件了,这里我采用的是ELK来进行日志搜集,这里就再也不细讲了

  经过以上操做,咱们真正的实现了一键式部署,并且阿里云针对swarm集群提供了各类方式的数据监控,彻底能够知足你的要求!对于集群扩容也很简单,只用选择相应的集群,直接选择添加已有节点或扩容便可随时扩容,你须要作的就是点击下相应应用的从新部署便可。咱们如今有数十台服务器,并且没有运维人员,只安排了一个研发工程师来进行平常的升级部署,已经稳定运行了一年多。在平常的升级过程当中,除了偶尔的服务器硬件不足,历来没有再出现过因部署失误而产生的问题!

    再次强调以上方案仅供小公司运维参考,因为本人运维经验有限,可能会有不少考虑不足的地方,欢迎指正探讨,咱们只为系统更稳定!


如需获取更多精彩内容或者技术探讨,请扫码关注本人公众号!爱生活,爱代码,代码也是码,我是爱码三疯!

爱码三疯公众号:hlt0912_dyh