jenkins配置优化的思考
本帖最后由 测试积点老人 于 2018-12-27 14:53 编辑背景随着项目拆的分散了之后 运维工作越来越依赖jenkins。但是随着而来的问题是什么呢？？？jenkins的job越来越多 带来的隐患也越来越大。如果一旦某天jenkins挂了或者数据发生了丢失 绝对会对整个研发流程带来相当大的负担。根据墨菲定律 【会出错的事总会出错】那么对于jenkins的备份以及保护也是应该要做的。
分析如上所说 我们也安装了backup组件 Jenkins迁移神器：使用ThinBackup插件备份和还原Jenkins但是备份是否就万无一失呢？jenkins任务的痛点莫非只是在备份上么？？？目前jenkins至少存在以下几个问题
[*]没有角色 对于权限划分不明
[*]备份机制
[*]初次配置job比较麻烦
方案
[*]事实上jenkins提供了ldap的组件 我们目前所有开发测试使用的是jira的crowd进行授权 目前jenkins也提供了对应的插件https://wiki.jenkins.io/display/JENKINS/Crowd+2+Plugin
[*]备份目前使用Jenkins迁移神器：使用ThinBackup插件备份和还原Jenkins 不过需要额外注意最好异机器备份 以防万一
[*]jenkins升级之后目前提供了pipeline机制 彻底总结了以前大量的gui配置方式。gui对于单个任务确实很方便不过对于实施微服务化的团队来说比较痛苦 那么这个时候脚本就是比较关键的呢。同时如果脚本化了jenkins的任务 那么运维的工作也变得更加直接了
pipelineJenkins 2.0 的精髓是 Pipeline as Code，是帮助 Jenkins 实现 CI 到 CD 转变的重要角色。什么是 Pipeline，简单来说，就是一套运行于 Jenkins 上的工作流框架，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂发布流程。Pipeline 的实现方式是一套 Groovy DSL，任何发布流程都可以表述为一段 Groovy 脚本，并且 Jenkins 支持从代码库直接读取脚本，从而实现了 Pipeline as Code 的理念。
Pipeline 的几个基本概念：
[*]Stage: 阶段，一个 Pipeline 可以划分为若干个 Stage，每个 Stage 代表一组操作。注意，Stage 是一个逻辑分组的概念，可以跨多个 Node。
[*]Node: 节点，一个 Node 就是一个 Jenkins 节点，或者是 Master，或者是 Agent，是执行 Step 的具体运行期环境。
[*]Step: 步骤，Step 是最基本的操作单元，小到创建一个目录，大到构建一个 Docker 镜像，由各类 Jenkins Plugin 提供。
job 执行 pipeline 定义，可以有两种方式，一种直接在 job 填写 pipeline script 来执行,
一种是使用 pipeline script from SCM。
[*]pipeline script：直接在 Script 输入框里面输入 pipeline script 语句即可，参考说明可以点击输入框下边的 Pipeline Syntax，里面有很多示例操作说明，非常好用。
[*]pipeline script from SCM：需要配置 SCM 代码存储 Git 地址或 SVN 地址，指定 script 文件所在路径，每次构建 job 会自动去指定的目录执行 script 文件。
关于Pipeline Syntax 我们可以找到许多例子说明 比如
生成的dsl如下checkout([$class: 'SubversionSCM', additionalCredentials: [], excludedCommitMessages: '', excludedRegions: '', excludedRevprop: '', excludedUsers: '', filterChangelog: false, ignoreDirPropChanges: false, includedRegions: '', locations: [], quietOperation: true, workspaceUpdater: [$class: 'UpdateUpdater']])
这样运维同学 甚至开发同学完全可以将对应的jenkins的脚本管理起来利用
支持分享
页:
[1]
