在DevOps搭建全流程中,采用Jenkins的自由风格构建的项目,每个步骤流程都要通过不同的方式设置,并且构建过程中整体流程是不可见的,无法确认每个流程花费的时间,并且问题不方便定位问题。
Jenkins的Pipeline可以让项目的发布整体流程可视化,明确执行的阶段,可以快速的定位问题。并且整个项目的生命周期可以通过一个Jenkinsfile文件管理,而且Jenkinsfile文件是可以放在项目中维护。
所以Pipeline相对自由风格或者其他的项目风格更容易操作。
Jenkins流水线任务
- 新建流水线任务
- 一个简单的Hello Word模板
- 构建视图
Groovy脚本
- Groovy脚本基础配置结构
// 所有脚本命令包含在pipeline{}中
pipeline {
// 指定任务在哪个节点执行(Jenkins支持分布式)
agent any
// 配置全局环境,指定变量名=变量值信息
environment{
host = '111'
}
// 存放所有任务的合集
stages {
// 单个任务
stage('任务1') {
// 实现任务的具体流程
steps {
echo 'do something'
}
}
// ……
}
}
- 语法可生成
Jenkinsfile
Jenkinsfile方式需要将脚本内容编写到项目中的Jenkinsfile文件中,每次构建会自动拉取项目并且获取项目中Jenkinsfile文件对项目进行构建。其实也就是Groovy脚本,只不过是将其放在项目中维护了。
- 配置pipeline任务
- 准备个Jenkinsfile文件测试下
- 尝试构建(成功)
Jenkins流水线任务实现
此段落真正实现了整个任务的全流程,主要就是各个阶段的配置和脚本文件的编写。
拉取代码
-
选择参数化构建
-
利用流水线语法生成Checkout代码的脚本
-
修改Jenkinsfile
-
尝试构建(成功)
构建项目
- 流水线语法生成
- 修改Jenkinsfile文件
- 尝试构建(成功)
代码检测
- 流水线语法生成(略)
- 修改Jenkinsfile
- 尝试构建(成功)
制作镜像并推送
-
修改Jenkinsfile
-
尝试构建(成功)
通知目标服务器部署服务
-
脚本生成
-
修改Jenkinsfile文件
-
尝试构建
-
观察容器并测试接口
完整的Jenkinsfile
仅供参考
PS:对于引用了Jenkinsfile和Jenkins job中的的变量,注意单引号和双引号的替换。小心出现占位变量被直接输出为字符串的情况。
pipeline {
agent any
environment{
host = ''
}
stages {
stage('拉取gialab代码') {
steps {
checkout scmGit(branches: [[name: '${tag}']], extensions: [], userRemoteConfigs: [[url: 'http://192.168.1.190:8929/root/mytest.git']])
}
}
stage('构建项目') {
steps {
sh '/var/jenkins_home/maven/bin/mvn clean package -DskipTests'
}
}
stage('检测代码质量') {
steps {
sh '/var/jenkins_home/sonar-scanner/bin/sonar-scanner -Dsonar.sources=./ -Dsonar.projectname=${JOB_NAME} -Dsonar.projectKey=${JOB_NAME} -Dsonar.java.binaries=target/ -Dsonar.login=6caa523d0115fa5e89f5016e7b158d3a51ce116f'
}
}
stage('制作自定义镜像并发布Harbor') {
steps {
sh '''cp ./target/*.jar ./docker/
cd ./docker
docker build -t 192.168.1.190:80/mytest/test:$tag ./'''
sh '''docker login --username admin --password-stdin < ~/my_password.txt 192.168.1.190:80
docker push 192.168.1.190:80/mytest/test:$tag'''
}
}
stage('通知服务器发布') {
steps {
sshPublisher(publishers: [sshPublisherDesc(configName: '190', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: 'deploy.sh 192.168.1.190:80 mytest test $tag 9090', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: '', remoteDirectorySDF: false, removePrefix: '', sourceFiles: '')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: false)])
}
}
}
}
部署结果通知(钉钉)
友情链接:插件使用文档
实现
- 创建群并添加自定义机器人
- Jenkins下载对应插件
- 插件配置
- Jenkinsfile修改
目录结构post { success { dingtalk ( robot: 'Jenkins', type:'MARKDOWN', title: "success: ${JOB_NAME}", text: ["- 成功构建:${JOB_NAME}项目!\n- 版本:${tag}\n- 持续时间:${currentBuild.durationString}\n- 任务:#${JOB_NAME}"] ) } failure { dingtalk ( robot: 'Jenkins', type:'MARKDOWN', title: "fail: ${JOB_NAME}", text: ["- 失败构建:${JOB_NAME}项目!\n- 版本:${tag}\n- 持续时间:${currentBuild.durationString}\n- 任务:#${JOB_NAME}"] ) } }
- 测试
- 失败消息
- 成功消息
- 失败消息
小结
整合钉钉还是挺简单的,按照说明一步步配置即可,Jenkinsfile有错误的话也会在日志中得到体现,按照提示修正即可。
另外可以设置推送消息的类型,如:TEXT、LINK、MARKDOWN、ACTION_CARD。每个消息的显示和适用性各有不同。也可以设置@某人等,有兴趣的朋友可以去本章节开始的友情链接查看相关文档,里面有实例供参考。
Jenkins & k8s
-
k8s环境准备(略过)
-
各节点添加私库地址
-
验证登录
-
创建secret,用来访问harbor
-
准备部署文件
apiVersion: apps/v1 kind: Deployment metadata: namespace: devops name: pipeline labels: app: pipeline spec: replicas: 2 selector: matchLabels: app: pipeline template: metadata: labels: app: pipeline spec: containers: - name: pipeline image: 192.168.1.190:80/mytest/test:v3.0.0 imagePullPolicy: Always ports: - containerPort: 9090 imagePullSecrets: - name: myharbor --- apiVersion: v1 kind: Service metadata: namespace: devops labels: app: pipeline name: pipeline spec: selector: app: pipeline ports: - port: 9090 targetPort: 9090 nodePort: 32323 type: NodePort
-
部署文件放置Gitlab,方便维护
-
新增SSH配置 k8s master 节点连接
-
SSH密钥远程登录 k8s master (运行kubectl指令)
-
Jenkins容器内生成密钥对
-
将公钥传输至k8s master
-
尝试宿主机无密码登录master并运行命令
-
-
Jenkinsfile文件修改(流水线语法生成)
-
代码修改
-
tag版本变更
-
构建测试
- 钉钉
- k8s查看
- 接口测试
- 钉钉
总结
此次使用传统的Jenkins整合 k8s 来实现DevOps。总体来看:
- 较为复杂:需要一定的学习和经验来正确设置和维护。而且传统的Jenkins需要自行配置和管理Kubernetes集成,更是需要额外的工作量和配置。
- 灵活性更高:有插件生态系统的支持,这意味着你可以根据需要集成Kubernetes、Docker和其他DevOps工具,以构建完整的CI/CD流水线。
- 安全:存在时间较长,广泛应用于各种企业环境中,具有较高的稳定性和可靠性。
和KubeSphere平台提供的一体化的DevOps各有千秋。
需求决定一切,没有最好,只有合不合适。