Jenkins

如何使用 使用Kubernetes插件时，我们需要做三件事情： 根据官方文档，在Jenkins上加入kubernetes配置。 在Jenkinsfile中加入kubernetes agent的申明。 指定容器执行你的业务脚本。 关于第2点，kubernetes agent的申明又有两种方式。一种是脚本式的，代码样例如下： podTemplate(containers: […]) { node(POD_LABEL) { stage('Run shell') { container('mycontainer') { sh 'echo hello world' }}}} 一种是申明式，代码样例如下： pipeline { stages { stage('Run maven') { agent { kubernetes { yaml """ apiVersion: v1 kind: Pod metadata: labels: app: jenkins-agent spec: containers: - name: maven image: maven:alpine command: - cat tty: true - name: busybox image: busybox command: - cat tty: true """ }} steps { container('maven') { sh 'mvn -version' }}}}} 笔者推荐使用申明式。yaml配置部分看起来并不优雅，这是另一个话题。咱们今后再讲。 ...

Jenkins 共享库是除了 Jenkins 插件外，另一种扩展 Jenkins 流水线的技术。通过它，可以定义轻松的自定义步骤，还可以对现有的流水线逻辑进行一定程度的抽象与封装。至于如何写及如何使用它，读者朋友可以移步附录中的官方文档。 对共享库进行单元测试的原因 但是如何对它进行单元测试呢？共享库越来越大时，你不得不考虑的问题。因为如果你不在早期就开始单元测试，共享库后期可能就会发展成如下图所示的“艺术品”——能工作，但是脆弱到没有人敢动。 [图片来自网络，侵权必删] 这就是代码越写越慢的原因之一。后人要不断地填前人有意无意挖的坑。 共享库单元测试搭建 共享库官方文档介绍的代码仓库结构 (root) +- src # Groovy source files | +- org | +- foo | +- Bar.groovy # for org.foo.Bar class +- vars | +- foo.groovy # for global 'foo' variable | +- foo.txt # help for 'foo' variable +- resources # resource files (external libraries only) | +- org | +- foo | +- bar.json # static helper data for org.foo.Bar 以上是共享库官方文档介绍的代码仓库结构。整个代码库可以分成两部分：src 目录部分和 vars 目录部分。它们的测试脚手架的搭建是不一样的。 ...

本文要点： 设计一条 Springboot 最基本的流水线：包括构建、制品上传、部署。 使用 Docker 容器运行构建逻辑。 自动化整个实验环境：包括 Jenkins 的配置，Jenkins slave 的配置等。 1. 代码仓库安排 本次实验涉及以下多个代码仓库： % tree -L 1 ├── 1-cd-platform # 实验环境相关代码 ├── 1-env-conf # 环境配置代码-实现配置独立 └── 1-springboot # Springboot 应用的代码及其部署代码 1-springboot 的目录结构如下： % cd 1-springboot % tree -L 1 ├── Jenkinsfile # 流水线代码 ├── README.md ├── deploy # 部署代码 ├── pom.xml └── src # 业务代码 所有代码，均放在 GitHub: https://github.com/cd-in-practice 2. 实验环境准备 笔者使用 Docker Compose + Vagrant 进行实验。环境包括以下几个系统： Jenkins * 1 Jenkins master，全自动安装插件、默认用户名密码：admin/admin。 Jenkins agent * 2 Jenkins agent 运行在 Docker 容器中，共启动两个。 Artifactory * 1 一个商业版的制品库。笔者申请了一个 30 天的商业版。 使用 Vagrant 是为了启动虚拟机，用于部署 Springboot 应用。如果你的开发机器无法使用 Vagrant，使用 VirtualBox 也可以达到同样的效果。但是有一点需要注意，那就是网络。如果在虚拟机中要访问 Docker 容器内提供的服务，需要在 DNS 上或者 hosts 上做相应的调整。所有的虚拟机的镜像使用 Centos7。 ...

背景 了解到行业内有些团队是基于 Jenkins 开发 DevOps 平台。而基于 Jenkins 实现的 DevOps 平台，就不得不考虑凭证的管理问题。 本文就此问题进行讨论，尝试找出相对合理的管理凭证的方案。 一开始我们想到的方案可能是这样的：用户在 DevOps 平台增加凭证后，DevOps 再将凭证同步到 Jenkins 上。Jenkins 任务在使用凭证时，使用的是存储在 Jenkins 上的凭证，而不是 DevOps 平台上的。 但是，仔细想想，这样做会存在以下问题： Jenkins 与 DevOps 平台之间的凭证数据会存在不一致问题。 存在一定的安全隐患。通过 Jenkins 脚本命令行很容易就把所有密码的明文拿到。哪天 Jenkins 被注入了，所有的凭证一下子就被扒走。 无法实现 Jenkins 高可用，因为凭证存在 Jenkins master 机器上。 那么，有没有更好的办法呢？ 期望实现的目标 先定我们觉得更合理的目标，然后讨论如何实现。以下是笔者觉得合理的目标： 用户还是在 DevOps 管理自己的凭证。但是 DevOps 不需要将自己凭证同步到 Jenkins 上。Jenkins 任务在使用凭证时，从 DevOps 上取。 实现方式 Jenkins 有一个 Credentials Binding Plugin 插件，在 Jenkins pipeline 中的用法如下： withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) { sh ''' curl -u "$USERPASS" https://private.server/ > output ''' } withCredentials 方法做的事情就是从 Jenkins 的凭证列表中取出 id 为 mylogin 的凭证，并将值赋到变量名为 USERPASS 的变量中。接下来，你就可以在闭包中使用该变量了。 ...

手工安装 Jenkins 插件的方法 通常，我们有两种方法安装 Jenkins 插件。第一种方法是到 Jenkins 插件管理页面搜索插件，然后安装。第二种方法是上传 Jenkins 插件的 hpi 文件安装。这两种方法能满足大多数人的需求。 第一种方法，如下图所示： 第二种方法，如下图所示： 但是对于需要保证 Jenkins 稳定或在 Jenkins 上进行二次开发的同学来说，以上方法是无法满足需求的。 第一种方法是无法指定插件的版本。第二种方式必须自己找到该插件的依赖树，一个个依赖的安装。是的，手工上传插件的这种方法，Jenkins 是不会自动下载依赖的。 自动安装插件的方法 那么，有什么方法能做到即指定插件的版本，又能自动下载它的依赖呢？ 幸运的是，Jenkins 的 Docker 镜像的代码仓库里的 install-plugins.sh 脚本已经实现。只不过需要我们拿过来小小修改才能使用。笔者修改后创建了相应的代码仓库：jenkins-install-plugins-shell 。链接在文章末尾。 以下是 jenkins-install-plugins-shell 的使用方法： 将代码 clone 到 JENKINS_HOME 目录中。 cd $JENKINS_HOME git clone https://github.com/zacker330/jenkins-install-plugins-shell.git cd jenkins-install-plugins-shell 在 plugins.txt 中加入希望安装的插件 在 jenkins-install-plugins-shell 目录中，有一个 plugins.txt 文件，在文件中写入希望安装的插件及版本号。例如： ansible:1.0 powershell:1.3 执行安装 # Jenkins War 的路径，用于分析 export JENKINS_WAR_PATH=<Jenkins war文件的路径> chmod +x install-plugins.sh jenkins-support ./install-plugins.sh < plugins.txt 重启 Jenkins install-plugins 本质上做的事情就只是将插件从云端下载到 JENKINS_HOME 下的 plugins 目录中。要使安装的插件生效，还需要重启 Jenkins。 关于 Jenkins 插件的名称 Jenkins 插件有两个名称。一个叫 display name，一个叫 short name。比如 Ansible 插件的 disply name 为 Ansible plugin，short name 为 ansible。 ...

本文介绍如何使用 Jenkins + Ansible 实现对 Nginx 的自动化部署。最终达到的效果有如下几点： 只要你将 Nginx 的配置推送到 GitHub 中，Jenkins 就会自动执行部署，然后目标服务器的 Nginx 配置自动生效。这个过程是幂等（idempotent）的，只要代码不变，执行多少遍，最终效果不变。 如果目标机器没有安装 Nginx，则会自动安装 Nginx。 自动设置服务器防火墙规则。 1. 实验环境介绍 本次实验使用 Docker Compose 搭建 Jenkins 及 Jenkins agent。使用 Vagrant 启动一台虚拟机，用于部署 Nginx。使用 Vagrant 是可选的，读者可以使用 VirtualBox 启动一个虚拟机。使用 Vagrant 完全是为了自动化搭建实验环境。 以下是整个实验环境的架构图： 注意，图中的 5123 <-> 80 代表将宿主机的 5123 端口请求转发到虚拟机中的 80 端口。 Vagrant：虚拟机管理工具，通过它，我们可以使用文本来定义、管理虚拟机。 Ansible：自动化运维工具 Docker Compose：它是一个用于定义和运行多容器 Docker 应用程序的工具。可以使用YAML文件来配置应用程序的服务。 2. 启动实验环境 克隆代码并进入文件夹 git clone https://github.com/zacker330/jenkins-ansible-nginx.git cd jenkins-ansible-nginx 构建 Jenkins agent 的镜像 需要自定义 Jenkins agent 镜像有两个原因： ...

审校：王冬辉，linuxsuren Jenkins master 的高可用是个老大难的问题。和很多人一样，笔者也想过两个 Jenkins master 共享同一个 JENKINS_HOME 的方案。了解 Jenkins 原理的人，都会觉得这个方案不可行。但是真的不可行吗？ 由于工作原因，笔者需要亲自验证以上猜想。 JENKINS_HOME 介绍 Jenkins 所有状态数据都存放文件系统的目录中，这个目录被称为 JENKINS_HOME 目录。 实验环境介绍 笔者通过 Docker compose 启动两个独立的 Jenkins master，分别为 jenkins-a 和 jenkins-b。它们共用同一个 JENKINS_HOME 目录。相应的代码仓库的链接放在文章底部。 将代码克隆到本地后，进入仓库，执行 docker-compose up -d 即可启动实验环境。启动完成，在浏览器中输入 http://localhost:7088 可访问 jenkins-a，jenkins-b 的地址是 http://localhost:7089 。但是你会发现它们启动后的界面显示是不一样的。 jenkins-b 的界面如下图所示： 而 jenkins-a 的界面如下图所示： 这时，将 jenkins-a 日志中的解锁密码（Unlock password）输入到 jenkins-b 的页面中，会得到报错信息： ERROR: The password entered is incorrect, please check the file for the correct password 这时，再次 jenkins-b 日志中的解锁密码（Unlock password）输入到表单中即可进入下一步。接下来就是按照提示一步步完成了。在 jenkins-b 安装步骤的最后一步，我们设置了管理员的用户名密码：admin/admin。然后就算完成任务了。 ...

本文假设读者已经了解 Jenkins 基本概念及插件安装，Zabbix 基础概念。基于 Zabbix 3.4，Jenkins 2.8 做实验 笔者最近的工作涉及到使用 Zabbix 监控 Jenkins。在谷歌上搜索到的文章非常少，能操作的就更少了。所以决定写一篇文章介绍如何使用 Zabbix 监控 Jenkins。 下图为整体架构图： 整体并不复杂，大体步骤如下： 在 Jenkins 上安装 Metrics 插件，使 Jenkins 暴露 metrics api。 配置 Zabbix server 及 agent 以实现监控及告警 为方便读者实验，笔者将自己做实验的代码上传到了 GitHub，链接在文章末尾。使用的是 Docker Compose 技术（方便一次性启动所有的系统）。 接下来，我们详细介绍 Metrics插件及如何实现 Zabbix 监控 Jenkins。 1. 使 Jenkins 暴露 metrics api 安装 Metrics 插件，在系统配置中，会多出“Metrics”的配置，如下图： 配置项不复杂。我们需要点击“Generate…”生成一个 Access Key（生成后，记得要保存）。这个 Key 用于身份校验，后面我们会用到。 保存后，我们在浏览器中输入URL：http://localhost:8080/metrics/<刚生成的 Access Key> 验证 Jenkins 是否已经暴露 metrics。如果看到如下图，就说明可以进行下一步了。 1.1 Metrics 插件介绍 Metrics 插件是基于 dropwizard/metrics 实现。它通过4个接口暴露指标数据：/metrics，/ping，/threads，/healthcheck。 ...

面向读者：需要了解 Jenkins 流水线的基本语法。 Electron 是由 Github 开发，用 HTML，CSS 和 JavaScript 来构建跨平台桌面应用程序的一个开源库。 本文将介绍 Electron 桌面应用的流水线的设计。 但是如何介绍呢？倒是个大问题。笔者尝试直接贴代码，在代码注释中讲解。这是一次尝试，希望得到你的反馈。 完整代码 pipeline { // 我们决定每一个阶段指定 agent，所以， // 流水线的 agent 设置为 none，这样不会占用 agent agent none // 指定整条流水线的环境变量 environment { APP_VERSION = "" APP_NAME = "electron-webpack-quick-start" } stages { stage("生成版本号"){ agent {label "linux" } steps{ script{ APP_VERSION = generateVersion("1.0.0") echo "version is ${APP_VERSION}" }} } stage('并行构建') { // 快速失败，只要其中一个平台构建失败， // 整次构建算失败 failFast true // parallel 闭包内的阶段将并行执行 parallel { stage('Windows平台下构建') { agent {label "windows && nodejs" } steps { echo "${APP_VERSION}" } } stage('Linux平台下构建') { agent {label "linux && nodejs" } // 不同平台可能存在不同的环境变量 // environment 支持阶段级的环境变量 environment{ SUFFIX = "tar.xz" APP_PLATFORM = "linux" ARTIFACT_PATH = "dist/${APP_NAME}-${APP_PLATFORM}-${APP_VERSION}.${SUFFIX}" } steps { script{ // Jenkins nodejs 插件提供的 nodejs 包装器 // 包装器内可以执行 npm 命令。 // nodejs10.15.2 是在 Jenkins 的全局工具配置中添加的 NodeJS 安装器 nodejs(nodeJSInstallationName: 'nodejs10.15.2') { // 执行具体的构建命令 sh "npm install yarn" sh "yarn version --new-version ${APP_VERSION}" sh "yarn install" sh "yarn dist --linux deb ${SUFFIX}" // 上传制品 uploadArtifact("${APP_NAME}", "${APP_VERSION}", "${ARTIFACT_PATH}") }}} // 将括号合并是为了让代码看起来紧凑，提升阅读体验。下同。 } stage('Mac平台下构建') { agent {label "mac && nodejs" } stages { stage('mac 下阶段1') { steps { echo "staging 1" } } stage('mac 下阶段2') { steps { echo "staging 2" } } } } } } stage("其它阶段，读者可根据情况自行添加"){ agent {label "linux"} steps{ echo "发布" } } } post { always { cleanWs() } } // 清理工作空间 } def generateVersion(def ver){ def gitCommitId = env.GIT_COMMIT.take(7) return "${ver}-${gitCommitId}.${env.BUILD_NUMBER}" } def uploadArtifact(def appName, def appVersion, def artifactPath){ echo "根据参数将制品上传到制品库中，待测试" } 代码补充说明 因为 Electron 是跨平台的，我们需要将构建过程分别放到 Windows、Linux、Mac 各平台下执行。所以，不同平台的构建任务需要执行在不同的 agent 上。我们通过在 stage 内定义 agent 实现。如在“Mac平台下构建”的阶段中，agent {label "mac && nodejs" } 指定了只有 label 同时包括了 mac 和 nodejs 的 agent 才能执行构建。 ...

通过脚本命令行批量修改Jenkins任务 最近，笔者所在团队的 Jenkins 所在的服务器经常报硬盘空间不足。经查发现很多任务没有设置“丢弃旧的构建”。通知所有的团队检查自己的 Jenkins 任务有没有设置丢弃旧的构建，有些不现实。 一开始想到的是使用 Jenkins 的 API 来实现批量修改所有的 Jenkins 任务。笔者对这个解决方案不满意，经 Google 发现有同学和我遇到了同样的问题。他使用的更“技巧”的方式：在 Jenkins 脚本命令行中，通过执行 Groovy 代码操作 Jenkins 任务。 总的来说，就两步： 进入菜单：系统管理 –> 脚本命令行 在输入框中，粘贴如下代码： import jenkins.model.Jenkins import hudson.model.Job import jenkins.model.BuildDiscarderProperty import hudson.tasks.LogRotator // 遍历所有的任务 Jenkins.instance.allItems(Job).each { job -> if ( job.isBuildable() && job.supportsLogRotator() && job.getProperty(BuildDiscarderProperty) == null) { println " \"${job.fullDisplayName}\" 处理中" job.addProperty(new BuildDiscarderProperty(new LogRotator (2, 10, 2, 10))) println "$job.name 已更新" } } return; /** LogRotator构造参数分别为： daysToKeep: If not -1, history is only kept up to this days. numToKeep: If not -1, only this number of build logs are kept. artifactDaysToKeep: If not -1 nor null, artifacts are only kept up to this days. artifactNumToKeep: If not -1 nor null, only this number of builds have their artifacts kept. **/ 脚本命令行介绍 脚本命令行（Jenkins Script Console），它是 Jenkins 的一个特性，允许你在 Jenkins master 和 Jenkins agent 的运行时环境执行任意的 Groovy 脚本。这意味着，我们可以在脚本命令行中做任何的事情，包括关闭 Jenkins，执行操作系统命令 rm -rf /（所以不能使用 root 用户运行 Jenkins agent）等危险操作。 ...