我的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工具的接口的，奈何目前运维在用的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次，这还是在刚起步阶段。可想而知，确实是生产力工具