我的devops实践经验分享一二

前言

随着系统越来越大,开发人员、站点、服务器越来越多,微服务化推进,......等等原因,实现自动化的devops越来越有必要。 当然,真实的原因是,在团队组建之初就预见到了这些问题,所以从一开始就决定这一块要自动化。 带来的实质好处也是显而易见的,人力成本的节省、规范化的流程、可追溯的发布历史、解脱双手(重复性劳动)、避免人为操作产生的错误等等。

感概一下

1.目前市面上的成套的产品要么贵的要死,要么不支持本地部署,要么就还是一个demo级别的东西,最重要的还是每个公司或者产品都有自己的一些特殊环境或者业务再里面。不一定都适合。反正是比较难找到好用的,而且是成套的产品来。期待一个devops界的SAP,而且还要便宜! 2.几个老大哥产品还是做得很牛逼!比如jira,confluence,jenkins,sonar。官方文档非常完善,网上教程多。接口完备。不像某些产品,看上去高大上,一用起来就是各种坑 3.懂开发的运维觉逼是牛逼的程序员!(^_^) 4.人真的非常重要,不然流程什么的,呵呵,都是个屁......

大概的样子

当然,目前这套工具还有很多不完善的地方,随着不停的使用,或者变化的需求来进一步变化。

gitlab

开源的git仓库,主要有几个用途 1.源代码管理 分支管理规则可以参考gitflow,或者规定一个合适自己的就好,微服务化后,一个站点或者说一个项目参与的开发人员只有有限的几个人。用了简单的方法,master作为发布用分支,每次迭代开发使用新分支,上线前合并到master;线上简单的fix则直接在master分支上提交。 2.配置文件管理 放在gitlab上,主要是为了方便管理,以及追溯修改历史。当然,我们有自己的配置中心,能走配置中心的都尽量走配置中心,只有必须是文件配置管理的才放在gitlab上。 3.发布脚本管理 jenkins需要使用到的发布脚本。根据环境、源代码语言、部署方式等有所不同

jira

jira敏捷开发管理工具,管理需求、研发迭代等。在加上他们家公司的wiki做知识库管理基本稳了。 jira用下来发现还是相当强大!各种自定义可配置。页面、字段、流程等等全可配置。有http open api可以直接调用修改信息、触发流程等

使用的发布流程也比较简单。开发创建发布任务,然后提交给测试,测试在jira上操作发布到测试环境,准线上环境,线上环境进行测试等。准线上环境测试完后要发布到线上需要让具有leader权限的人进行一次审核,一方面是让leader知道有什么东西上线了,另一方面也是安全控制的一些原因(比如说节假日前夕最好是不在做更新等,要做更新就得报备,不然出问题节假日就得嗝屁)。

截图是比较历史的版本了,最近在jira里面找了一个进度条插件,然后把构建发布的实时进度直接反馈到jira的页面上。这样就不用再打开发布系统查看发布进度了,进一步提高使用体验。

发布流程工作流,根据自身的情况设计的

发布系统

这一块,是我们自己开发的一个简单系统。主要作用是衔接各个开源工具的使用。作为一个粘合剂系统使之分散的各个子工具能链接为一个整体。 虽然,jira里面有jenkins插件,jenkins里面有jira的插件,但是组件对各个系统都有版本要求,然后组件使用上也蛮不方便的,最后也有一些需求要解决起来相当麻烦,所以才有了自己的发布系统。 功能还是比较简单,一个前端小伙弄弄页面什么的1个礼拜就完事了,关键还是把当下的各种新技术都秀了一波,虽然页面挺丑的。几个系统的接口调用自己研究写一写也就几天就完事了。 主要完成的几个功能 1.发布配置管理 站点或者系统的开发语言,部署的目标系统,要部署那些主机,是不是docker容器方式,docker要部署几个示例,部署方式并发、串行发布,要走那一个nginx,绑定的域名,绑定的端口等等信息。 在新的系统或者站点发布的时候由运维和研发协调填写,后期则由运维来维护,比如扩缩容等

2.接收jira的发布任务操作通知,并通知到某一个Jenkins去执行,sonar进行静态代码检查等 3.接收jenkins构建部署反馈过来的进度 4.展示构建部署进度

5.一部分CMDB系统的功能,主机管理(ip,名称,用户名,密码)之类的。方便。 至于为什么不用世面上已有的CMDB系统,也实属无赖,要么要钱,要么好麻烦、要么没接口。索行自己简单做一个。能满足功能即可。 因为涉及到主机的账号密码之类的,所以密码都是公钥加密存储在系统上。 而密码的使用方有2个,一个是jenkins在部署的时候新机器在创建SSH免密登录的时候要用一次,还有就是远程管理工具要用,所以对密码的使用单独写了个小组件用私钥解密获得密码,然后把发布系统和小组件单独管理

jenkins

jenkins绝对可以说是这套工具里面的大佬了,可以说一切都是围着他在转。 接收发布系统发过来的构建请求,拉取代码,编译,拉取配置文件,打包成部署包,上传ftp,发布到私有docker仓库,部署等等。 还要区分系统环境,开发语言(windows、linux、nodejs、.net core)单独处理等。 1.参数化构建过程。比如要构建的分支名称之类的 2.源代码配置。git源代码地址,gitlab固定的代码只读账号,通过SSH进行代码的拉取。 3.调用构建脚本。jenkins内的执行命令大约如下面所示

#!/bin/bash -l
cd /opt/deployscript # 进入构建脚本目录
git pull #拉取最新的构建脚本
#调用构建脚本
#workspace,build_number,jobname,project_name,git_commit,git_branch,env,jira_id,userid
sh /opt/deployscript/${JOB_NAME}/${env}/deploy.sh "${WORKSPACE}" "${BUILD_NUMBER}" "${JOB_NAME}" "${PROJECT_NAME}" "${GIT_COMMIT}" "${selected_branch}" "${env}" "${JIRA_ISSUE_ID}" "${BUILD_USER_ID}"

jenkins的构建脚本

重中之重了,所有的驱动都在这个脚本里面了。分环境、分开发语言单独编写的构建或部署脚本。 为什么每一个站点都有一个脚本的原因则是总有那么一些站点是那么的特殊和优秀,当然觉得多数系统都可以走一个公共的构建脚本。 脚本有不少要调用其他系统接口的,我则直接用.net core 写了一个控制台应用,专门负责这个事情,毕竟写shell不是专业的。 具体的构建脚本就不贴上来了。 脚本执行步骤(net core 测试环境脚本):在每一个部署完成或者出错的时候都把进度反馈到发布系统上。 1.源代码在jenkins配置里面已经帮忙拉取好了。所以脚本不用拉代码了。 2.编译。比如dotnet publish -c Release -r linux-x64 -o “输出路径” 3.编译输出内容打包 4.上传到ftp。 5.拉取配置文件。 6.将输入内容和配置文件,等打成压缩包 6.拉取部署配置。要部署到那些机器,部署要并发还是要串行等 7.检查机器是否已经完成SSH免密配置了,没有配置则拉取密码配置好。 8.并行或者串行进行发布操作 9.SSH到目标机器,上传压缩包,部署脚本 10.执行部署脚本(解压,停掉原来的服务,启动新的服务,检查是否启动成功等)

sonar静态代码检查

在发布系统中接收到jira的发布请求后,拉取站点的配置,如果是需要进行sonar检查则把请求发送给sonar的jenkins。 目前我们配置的是发布到产线的时候才做sonar的静态代码检查,然后再sonar系统里面配置了。 后面看需要,是否要对sonar的结果进行邮件。打算这样做。每周出一份代码质量报告,统计一周内已上线的项目和上一周相比错误,漏洞,坏味道,覆盖了等数据的变化。弄个定时任务,sonar 2个接口获取一下数据,存储对比结果,发个邮件就完事了。

简单总结一下

文章随便写写,很多东西交代的不清楚,还有很多东西压根就没有说。比如说堡垒机集成,日志、host监控集成等等等。我不会说实在是我太懒了,打字好累啊! 总之,欢迎交流!!虽然实现的不完整,但是还是适合目前自身的需求的。合适的才是最好的嘛

感谢开源界大佬的贡献,虽然我还没钱捐款。让社区有那么多那么多好用的产品。 感谢前人已经种好的大树,很凉快!

整套工具搭建完成,如果真的算时间估计也就不到一个月,当然真实情况是零零散散的,东戳戳,西戳戳。好在做这个事情之前有一个简单的规划,没有走弯路,虽然再找国产产品的路上耗费了一些时间

从开始使用开始,3个月不到就发了不下2000次,这还是在刚起步阶段。可想而知,确实是生产力工具

我的博客即将同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=v8yg6z6vosmk

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

Autodesk基于Mesos的通用事件系统架构

【编者按】本文由Autodesk Cloud软件架构师Olivier Paugam撰写,解释了如何集合Mesos、Kafka、RabbitMQ、Akka、Spl...

2185
来自专栏WeTest质量开放平台团队的专栏

浅谈服务器性能测试的全生命周期——从测试、结果分析到优化策略

服务器性能测试是一项非常重要而且必要的工作,本文是作者Micheal在对服务器进行性能测试的过程中不断摸索出来的一些实用策略,通过定位问题,分析原因以及解决问题...

2674
来自专栏Android群英传

推送,从入门到放弃

1842
来自专栏杨建荣的学习笔记

运维平台的建设思考-元数据管理(r7笔记第57天)

之前也写过一篇比较基本的文章,也算是自己对运维平台的一个基本思考。运维平台的建设思考(r6笔记第20天) 当然想法简单,而且缺乏实践,但是朝着这个方向迈进是没有...

4625
来自专栏Java进阶架构师

【架构技术专题】什么是架构设计的五个核心指标?如何设计?(4)

性能就是核心要素之一,不然我为什么架构设计?随随便便一个lowlow的系统上线就好了。所以性能优化是很多小公司卖不去过的坎。这么说吧,当然优化网站性能的手段也非...

2714
来自专栏JAVA高级架构

多研究些架构,少谈些框架(3)-- 微服务和事件驱动

接上篇,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性 事务...

4004
来自专栏微信小程序开发

开发小程序被问到最频繁的问题(下)

连胜老师在自己的微信小程序开发群里,也经常帮人解答问题,在这里整理一下最频繁被问到的小程序问题。本篇是《开发小程序被问到最频繁的问题(上)》的续篇。 9、用户不...

1.1K9
来自专栏跨界架构师

做了「负载均衡」就可以随便加机器了吗?这三招来帮你!

        这篇是《分布式关注点系列》中「负载均衡」相关的内容最后一发了,后续也会继续讲「高可用」相关的其它主题,主要是限流、降级、熔断之类的吧,具体还没定...

1445
来自专栏搜云库

分布式和集群区别?什么是云计算平台?分布式的应用场景?

分布式是指将一个业务拆分不同的子业务,分布在不同的机器上执行,集群是指多台服务器集中在一起,实现同一业务,可以视为一台计算机,一个云计算平台,就是通过一套软件系...

1.1K10
来自专栏JAVA技术zhai

大话微服务架构的故障隔离及容错处理机制

8、限流器和负载开关(Rate Limiters and Load Shedders)

2812

扫码关注云+社区

领取腾讯云代金券