我的devops实践经验分享一二-白红宇

我的devops实践经验分享一二

阅读量：5008 次

发布时间：2019-06-12

本文共 3754 字，大约阅读时间需要 12 分钟。

前言

随着系统越来越大，开发人员、站点、服务器越来越多，微服务化推进，......等等原因，实现自动化的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 -lcd /opt/deployscript # 进入构建脚本目录git pull #拉取最新的构建脚本#调用构建脚本#workspace,build_number,jobname,project_name,git_commit,git_branch,env,jira_id,useridsh /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}"