Jenkins on 翟志军 Jack Zhai

Jenkins kubernetes插件的原理

Mon, 26 Feb 2024 00:00:00 +0000

如何使用

使用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 共享库进行单元测试

Sat, 25 May 2019 00:00:00 +0000

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 目录部分。它们的测试脚手架的搭建是不一样的。

使用 Jenkins + Ansible 实现 Springboot 自动化部署101

Wed, 15 May 2019 00:00:00 +0000

本文要点：

设计一条 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 平台应该如何设计凭证管理

Tue, 07 May 2019 00:00:00 +0000

一种基于 Jenkins 的 DevOps 平台建设思路

Jenkins 自动安装插件

Sat, 27 Apr 2019 00:00:00 +0000

手工安装 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

Mon, 22 Apr 2019 00:00:00 +0000

本文介绍如何使用 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 镜像有两个原因：

你觉得能通过共享 JENKINS_HOME 目录实现 Jenkins master 的高可用吗？

Mon, 15 Apr 2019 00:00:00 +0000

审校：王冬辉，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。然后就算完成任务了。

使用 Zabbix 监控 Jenkins

Wed, 10 Apr 2019 00:00:00 +0000

本文假设读者已经了解 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。

Electron 应用的流水线设计

Sun, 10 Mar 2019 00:00:00 +0000

面向读者：需要了解 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任务的技巧

Sat, 23 Feb 2019 00:00:00 +0000

通过脚本命令行批量修改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）等危险操作。