jekins自动化部署
1. 部署中的痛点
为什么要用Jenkins？我说下我以前开发的痛点，在一些中小型企业，每次开发一个项目完成后，需要打包部署，可能没有专门的运维人员，只能开发人员去把项目打成一个exe包，可能这个项目已经上线了，需要把服务关，在部署到服务器上，将项目启动起来，这个时候可能某个用户正在操作某些功能上的东西，如果你隔三差五的部署一下，这样的话对用户的体验也不好，自己也是烦的很，总是打包拖到服务器上。希望小型企业工作人员学习一下，配置可能复杂，但是你配置好了之后，你只需要把代码提交到Git或者Svn上，自动构建部署，非常方便。
2. 什么是jenkins
Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具，起源于Hudson（Hudson是商用的），主要用于持续、自动的构建/测试软件项目、监控外部任务的运行（这个比较抽象，暂且写上，不做解释）。Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT，构建工具有Maven、Ant、Gradle。
3. jenkins的安装和配置
这个jenkins我们不会直接安装在 192.168.0.104 我们会在一个新的虚拟机上运行 192.168.0.102，我们会在下一节课中专门讲解
安装java
yum install java-1.8.0-openjdk* -ymac用户请参考： https://www.jianshu.com/p/8e82d74295
下载jenkins
ubuntu安装Debian Jenkins Packages
jenkins-2.284-1.1.noarch.rpm
https://mxshop-files.oss-cn-hangzhou.aliyuncs.com/jenkins-2.284-1.1.noarch.rpm
上传安装包并安装
rpm -ivh jenkins-2.284-1.1.noarch.rpm修改jenkins配置
vim /etc/sysconfig/jenkins
ubuntu中在/etc/default/jenkins中可以修改下面两个配置
JENKINS_USER="root" #这里改为root 会省去很多权限的麻烦
JENKINS_PORT="8088"启动jenkins
systemctl start jenkins关闭防火墙
使用命令“systemctl status firewalld.service”查看防火墙状态：
systemctl stop firewalld.service
systemctl disable firewalld.service
们先用下面的代码来查看有没有开放我们设置的jenkins的端口：
firewall-cmd --list-ports
如果发现没有jenkins的端口，则用
firewall-cmd --permanent --zone=public --add-port=8080/tcp
开启已经配置好的jenkins的端口，然后在重启防火墙，注意一定要重启防火墙！
systemctl reload firewalld在浏览器中访问输入 http://192.168.0.104:8088
需要我们输入密码，初始化密码可以通过下面命令查找到
看到下面内容：
复制出来输入到密码框即可
接下来进入插件安装提示页面
但是因为插件下载地址是官方地址，所以会很慢，我们要跳过安装后续自己安装，我们点击右侧的 “选择插件来安装”进入：
然后选择 “无”，进入新建用户页面
jenkins插件管理
jenkins本身功能简单，但是jenkins提供的插件机制使得jenkins可以开发很多插件来使得jenkins很强大。
但jenkins插件默认从国外官方地址下载，速度会很慢，所以需要在安装插件前将下载地址改为国内的下载地址
1. 修改插件下载地址
修改default.json文件
sed -i 's/https:\/\/updates.jenkins.io\/download/http:\/\/mirrors.tuna.tsinghua.edu.cn\/jenkins/g' /var/lib/jenkins/updates/default.json && sed -i 's/http:\/\/www.google.com/https:\/\/www.baidu.com/g' /var/lib/jenkins/updates/default.json进入 Manage Jenkins -》 Manage Plugin -> Advanced 最下面有 Update Site 设置为：https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
如下图所示：
重启一下jenkins，直接在浏览器中输入 http://192.168.0.104:8088/restart 重启
2. 安装常用插件
1.汉化
课程中常用的插件地址，Localization: Chinese (Simplified) | Jenkins plugin
部署到远程服务器并运行
安装Send build artifacts over SSH插件
这个插件是jenkins连接linux系统的时候使用。以下针对插件的每个属性进行说明。
构建服务后操作的一些参数
Name
SSH Server的Name属性就是你希望连接的服务器。
Source files
这里输入的是你希望传到服务器的文件夹和文件。路径是相对jenkins的workspace的项目名称的。例如项目名称是Test_Project的go项目，编译打包后的路径为Test_Project文件夹下的target，则Surce files填入target/*.go。
Remove prefix
如果Source files为target/*.jar，但是不想把target目录创建到服务器端，这个时候就可以在Remove prefix里填入target
Remote directory
这里指定文件将被拷贝到服务器的路径。
PS：被拷贝文件在服务器上的完整路径=登录服务器账号的默认路径+Remote directory。
Exec command
这里就是连接服务器之后需要执行的命令。
Jenkins Pipeline参数详解
插件名pipline
创建您的第一个Pipeline
pipeline模式相对style free门槛较高， 比较复杂的构建 ，以及构建过程很重要
Pipeline 是什么
Jenkins Pipeline 实际上是基于 Groovy 实现的 CI/CD 领域特定语言（DSL），主要分为两类，一类叫做 Declarative Pipeline，一类叫做 Scripted Pipeline。
Declarative Pipeline 体验上更接近于我们熟知的 travis CI 的 travis.yml，通过声明自己要做的事情来规范流程，形如：
pipeline {
agent any
stages {
stage('Build') {
steps {
//
}
}
stage('Test') {
steps {
//
}
}
stage('Deploy') {
steps {
//
}
}
}
}
而 Scripted Pipeline 则是旧版本中 Jenkins 支持的 Pipeline 模式，主要是写一些 groovy 的代码来制定流程：
可以从下面的链接中自动生成
node {
stage('Build') {
//
}
stage('Test') {
//
}
stage('Deploy') {
//
}
}
一般情况下声明式的流水线已经可以满足我们的需要，只有在复杂的情况下才会需要脚本式流水线的参与。
过去大家经常在 Jenkins 的界面上直接写脚本来实现自动化，但是现在更鼓励大家通过在项目中增加 Jenkinsfile 的方式把流水线固定下来，实现 Pipeline As Code，Jenkins 的 Pipeline 插件将会自动发现并执行它。
语法
Declarative Pipeline 最外层有个 pipeline 表明它是一个声明式流水线，下面会有 4 个主要的部分： agent，post，stages，steps，我会逐一介绍一下。
Agent
agent 主要用于描述整个 Pipeline 或者指定的 Stage 由什么规则来选择节点执行。Pipeline 级别的 agent 可以视为 Stage 级别的默认值，如果 stage 中没有指定，将会使用与 Pipeline 一致的规则。在最新的 Jenkins 版本中，可以支持指定任意节点(any)，不指定(none)，标签(label)，节点(node)，docker，dockerfile 和 kubernetes 等，具体的配置细节可以查看文档，下面是一个使用 docker 的样例：
agent {
docker {
image 'myregistry.com/node'
label 'my-defined-label'
registryUrl 'https://myregistry.com/'
registryCredentialsId 'myPredefinedCredentialsInJenkins'
args '-v /tmp:/tmp'
}
}Tips:
- 如果 Pipeline 选择了 none，那么 stage 必须要指定一个有效的 agent，否则无法执行
- Jenkins 总是会使用 master 来执行 scan multibranch 之类的操作，即使 master 配置了 0 executors
- agent 指定的是规则而不是具体的节点，如果 stage 各自配置了自己的 agent，需要注意是不是在同一个节点执行的
Stages && Stage
Stages 是 Pipeline 中最主要的组成部分，Jenkins 将会按照 Stages 中描述的顺序从上往下的执行。Stages 中可以包括任意多个 Stage，而 Stage 与 Stages 又能互相嵌套，除此以外还有 parallel 指令可以让内部的 Stage 并行运行。实际上可以把 Stage 当作最小单元，Stages 指定的是顺序运行，而 parallel 指定的是并行运行。
接下来的这个 case 很好的说明了这一点：
除了指定 Stage 之间的顺序关系之外，我们还可以通过 when 来指定某个 Stage 指定与否：比如要配置只有在 Master 分支上才执行 push，其他分支上都只运行 build
还能在 Stage 的级别设置 environment，这些就不展开了，文档里有更详细的描述。
Steps
steps 是 Pipeline 中最核心的部分，每个 Stage 都需要指定 Steps。Steps 内部可以执行一系列的操作，任意操作执行出错都会返回错误。完整的 Steps 操作列表可以参考 Pipeline Steps Reference，这里只说一些使用时需要注意的点。
- groovy 语法中有不同的字符串类型，其中 'abc' 是 Plain 字符串，不会转义 ${WROKSPACE} 这样的变量，而 "abc" 会做这样的转换。此外还有 ''' xxx ''' 支持跨行字符串，""" 同理。
- 调用函数的 () 可以省略，使得函数调用形如 updateGitlabCommitStatus name: 'build', state: 'success'，通过 , 来分割不同的参数，支持换行。
- 可以在声明式流水线中通过 script 来插入一段 groovy 脚本
Post
post 部分将会在 pipeline 的最后执行，经常用于一些测试完毕后的清理和通知操作。文档中给出了一系列的情况，比较常用的是 always，success 和 failure。
比如说下面的脚本将会在成功和失败的时候更新 gitlab 的状态，在失败的时候发送通知邮件：
每个状态其实都相当于于一个 steps，都能够执行一系列的操作，不同状态的执行顺序是事先规定好的，就是文档中列出的顺序。
Shared Libraries
同一个 Team 产出的不同项目往往会有着相似的流程，比如 golang 的大部分项目都会执行同样的命令。这就导致了人们经常需要在不同的项目间复制同样的流程，而 Shared Libraries 就解决了这个问题。通过在 Pipeline 中引入共享库，把常用的流程抽象出来变成一个的指令，简化了大量重复的操作。
在配置好 lib 之后，Jenkins 会在每个 Pipeline 启动前去检查 lib 是否更新并 pull 到本地，根据配置决定是否直接加载。
所有的 Shared Libraries 都要遵循相同的项目结构：
目前我们的使用比较低级，所以只用到了 vars 来存储全局的变量。
vars 下的每一个 foo.groovy 文件都是一个独立的 namespace，在 Pipeline 中可以以 foo.XXX 的形式来导入。比如我们有 vars/log.groovy：
那么 Jenkinsfile 中就可以这样调用：
大家可能已经注意到了，在 groovy 文件中，我们可以直接像在 steps 中一样调用已有的方法，比如 echo 和 sh 等。
我们也能在 groovy 文件中去引用 Java 的库并返回一个变量，比如：
这样就能够在 JenkinsFile 中去设置一个环境变量：
除了定义方法之外，我们还能让这个文件本身就能被调用，只需要定义一个 call 方法：
还能够定义一个新的 section，接受一个 Block：
这样可以让指定的 Body 在 windows 节点上调用：
常用技巧
发送邮件通知
主要使用 emailext，需要在 Jenkins 的配置界面事先配置好，可用的环境变量和参数可以参考文档 Email-ext plugin
结果同步到 gitlab
同样需要配置好 gitlab 插件，在 Pipeline 中指定 options：
然后就可以在 post 中根据不同的状态来更新 gitlab 了：
文档参考：Build status configuration
构建过程中可用的环境变量列表
Jenkins 会提供一个完整的列表，只需要访问 /env-vars.html/ 即可，别忘了需要使用 "${WORKSPACE}"
在 checkout 前执行自定义操作
在 Multibranch Pipeline 的默认流程中会在 checkout 之前和之后执行 git clean -fdx，如果在测试中以 root 权限创建了文件，那么 jenkins 会因为这个命令执行失败而报错。所以我们需要在 checkout 之前执行自定义的任务：
在 Jenkinsfile 中配置以跳过默认的 checkout 行为：
在每个 stage 中执行自定义的任务即可：
总结
Jenkins 作为使用最为广泛的 CI/CD 平台，网上流传着无数的脚本和攻略，在学习和开发的时候一定要从基本出发，了解内部原理，多看官方的文档，不要拿到一段代码就开始用，这样才能不会迷失在各式各样的脚本之中。
更重要的是要结合自己的业务需求，开发和定制属于自己的流程，不要被 Jenkins 的框架限制住。比如我们是否可以定义一个自己的 YAML 配置文件，然后根据 YAML 来生成 Pipeline，不需要业务自己写 Pipeline 脚本，规范使用，提前检查不合法的脚本，核心的模块共同升级，避免了一个流程小改动需要所有项目组同步更新。
6. 定时构建的语法
1.定时构建语法
定时字符串从左到右依次： 分 时 日 月 周
*号等同于H，表示任意一个合理的数
* * * * *
第一个*表示分钟，取值0~59，若其他值不做设定，则表示每个设定的分钟都会构建
5 * * * * ，表示每个小时的第5分钟都会构建一次
第二个*表示小时，取值0~23， 若其他值不做设定，则表示每个设定小时的每分钟都会构建
* 5 * * * ，表示在每天5点的时候，一小时内每一分钟都会构建一次
第三个*表示一个月的第几天，取值1~31，若其他值不做设定，则表示每个月的那一天每分钟都会构建一次
* * 5 * *，表示在每个月5号的时候，0点开始每分钟构建一次
第四个*表示第几月，取值1~12，若其他值不做设定，则表示每年的那个月每分钟都会构建一次
* * * 5 *，表示在每年的5月份，1号0点开始每分钟构建一次
第五个*表示一周中的第几天，取值0~7，其中0和7代表的都是周日，若其他值不做设定，则表示每周的那一天几每分钟都会构建一次
* * * * 5，表示每周五0点开始每分钟构建一次
2.构建实例
每天凌晨2:00跑一次
H 2 * * *
每隔5分钟构建一次
H/5 * * * *
每两小时构建一次
H H/2 * * *
每天中午12点定时构建一次
H 12 * * * 或0 12 * * *（0这种写法也被H替代了）
每天下午18点前定时构建一次
H 18 * * *
每15分钟构建一次
H/15 * * * * 或*/5 * * * *(这种方式已经被第一种替代了，jenkins也不推荐这种写法了)
周六到周日，18点-23点，三小时构建一次
H 18-23/3 * * 6-7