上线发布是运维的日常工作,常见的发布方式有:
- 手动发布
- Jenkins 发布平台
- Gitlab CI
- …
除此之外还有需要开源软件,他们都有非常不错的发布管理功能。
面临的问题
作为运维人员,上线发布是必不可少的一环,一个正常的发布流程是怎么样的?
- 需求方提发布任务,走发布流程
- 供应方执行发布上线
环节看似简单,但是中间其实是有断层的。一般企业在走上线流程都是通过一些公共渠道,比如邮件、钉钉、飞书的流程,这些都很难和运维执行上线发布平台进行关联上,而且也不够直观。所以我们就需要解决以下几个问题:
- 流程和运维平台建立连接
- 从发起到结束形成闭环
为了选择 JIRA?
JIRA 优秀的项目管理,问题跟踪的工具,另外它的流程管理和看板模式也能够非常直观看到目前流程处在什么位置。另外它可以通过 webhook 和其他平台建立友好的连接,方便扩展。再者对于开发、测试、项目管理人员等来说 Jira 是他们日常的工具,使用熟练度非常高,降低了额外的学习成功。鉴于此,我们选择 JIRA 作为运维发布平台,争取做到一个平台做所有事。
方案设计
设计思路
充分利用 Jira、Gitlab 的 webhook 功能,以及 Jenkins 的灵活性。
- Jira 上更新状态触发 Jenkins 执行合并分支流水线
- Gitlab 上代码合并成功后触发 Jenkins 执行发布流水线
- 将发布结果通过钉钉等软件通知相应的人
整体思路相对简单,难点主要集中在 Jenkins 获取 Jira、Gitlab 的数据,所幸 Jenkins 的插件功能非常丰富,这里就使用 Generic Webhook Trigger
插件,可以很灵活地获取到触发软件地信息。
发布流程方案
然后整理出如下地发布流程。
涉及软件
软件 | 功能 |
---|---|
Jira | 发布流程管理 |
Jenkins | 执行各种流水线 |
Gitlab | 代码仓库 |
Kubernetes | 应用管理 |
Helm/kustomize | 包管理 |
钉钉 | 消息通知 |
trivy | 镜像扫描 |
镜像仓库 | 阿里云镜像仓库 |
PS:这里没有具体的软件部署
Jira 与 Jenkins 进行集成合并分支
Jenkins 配置
Jenkins 的配置主要有两部分,如下:
- 配置 Jenkins ShareLibrary 功能
- 编写 Jira 触发相应的 Jenkinsfile
(1)Jenkins 上配置 ShareLibarary
系统配置–> 系统配置–>Global Pipeline Libraries
(2)创建流水线,配置 Webhook 以及添加 Jenkinsfile
- 配置触发器
先配置一个变量和正则
再配置一个 Token 即可
- 配置流水线,添加对于的 Jenkinsfile
(3)Jenkinsfile 的主要逻辑如下
PS:下面仅列出大致的框架,并没有详细的代码
- 获取 Jira 的配置信息进行解析
- 根据不同信息执行不同的操作
- 合并分支主要是通过调 Gitlab 的 API 接口完成
#!groovy
@Library('lotbrick') _
def gitlab = new org.devops.gitlab()
def tool = new org.devops.tools()
def dingmes = new org.devops.sendDingTalk()
pipeline {
agent { node { label "master"}}
environment {
DINGTALKHOOK = "https://oapi.dingtalk.com/robot/send?access_token=xxxx"
}
stages{
stage("FileterData"){
steps{
script{
response = readJSON text: """${webHookData}"""
// println(response)
env.eventType = response["webhookEvent"]
if (eventType == "jira:issue_updated"){
// 获取状态值
env.jiraStatus = response['issue']['fields']['status']['name']
env.gitlabInfos = response['issue']['fields']['customfield_10219']
infos = "${gitlabInfos}".split("\r\n")
for (info in infos){
prName = "$info".split("/")[0]
// brName = "$info".split("/")[1]
brName = info - "${prName}/"
println(prName)
println(brName)
if (jiraStatus == "已发布(UAT)"){
println('进行合并PRE分支操作')
}else if (jiraStatus == "已发布(PROD)"){
println('进行合并PROD分支操作')
}else if (jiraStatus == "已完成"){
println('进行分支打Tag并删除原分支')
}else{
println("查无此项")
}
}
}
}
}
}
}
// 构建后的操作
post {
failure {
script{
println("failure:只有构建失败才会执行")
dingmes.SendDingTalk("分支合并失败 ❌")
}
}
aborted {
script{
println("aborted:只有取消构建才会执行")
dingmes.SendDingTalk("分支合并取消 ❌","暂停或中断")
}
}
}
}
以上 Jenkins 上配置基本完成。
Jira 上配置
Jira 上的主要配置如下:
- 建立工作流
- 工作流关联项目
- 配置项目触发 Webhook
建立工作流
将工作流关联项目组
配置 webhook
设置–> 系统–> 网络钩子
上面配置完成后,即完成 Jira 上配置,然后就可以在对应项目的看板上查看所以待发布的项目,如下:
然后进行拖拽或者点击发布按钮,即可改变状态,触发流水线进行相应的操作了。
Gitlab 与 Jenkins 集成发布系统
开发分支简要
这里主要使用的是功能分支开发模式,主要分为以下几个分支:
- DEV 分支:开发环境分支
- TEST 分支:测试环境分支
- UAT 分支:联调环境分支
- PRE 分支:预发布环境分支
- MASTER 分支:生产环境分支
代码合并路线是:DEV->TEST->UAT->PRE->MASTER
然后根据不同的分支判断执行不同环境的部署。
Jenkins 配置流水线
(1)配置 Webhook 插件参数
获取 Gitlab 分支
定义 gitlab push 条件,不是任何改动都需要触发流水线
定义过滤正则表达式
这样就只有 commit 的时候才会触发流水线。
(2)配置 Jenkinsfile
def labels = "slave-${UUID.randomUUID().toString()}"
// 引用共享库
@Library('jenkins_shareLibrary')
// 应用共享库中的方法
def tools = new org.devops.tools()
def branchName = ""
// 获取分支
if ("${gitlabWebhook}" == "gitlabPush"){
branchName = branch - "refs/heads/"
currentBuild.description = "构建者${userName} 分支${branchName}"
}
pipeline {
agent {
kubernetes {
label labels
yaml """
apiVersion: v1
kind: Pod
metadata:
labels:
some-label: some-label-value
spec:
volumes:
- name: docker-sock
hostPath:
path: /var/run/docker.sock
type: ''
- name: maven-cache
persistentVolumeClaim:
claimName: maven-cache-pvc
containers:
- name: jnlp
image: registry.cn-hangzhou.aliyuncs.com/rookieops/inbound-agent:4.3-4
- name: maven
image: registry.cn-hangzhou.aliyuncs.com/rookieops/maven:3.5.0-alpine
command:
- cat
tty: true
volumeMounts:
- name: maven-cache
mountPath: /root/.m2
- name: docker
image: registry.cn-hangzhou.aliyuncs.com/rookieops/docker:19.03.11
command:
- cat
tty: true
volumeMounts:
- name: docker-sock
mountPath: /var/run/docker.sock
- name: sonar-scanner
image: registry.cn-hangzhou.aliyuncs.com/rookieops/sonar-scanner:latest
command:
- cat
tty: true
- name: kustomize
image: registry.cn-hangzhou.aliyuncs.com/rookieops/kustomize:v3.8.1
command:
- cat
tty: true
- name: kubedog
image: registry.cn-hangzhou.aliyuncs.com/rookieops/kubedog:v0.5.0
command: ['cat']
tty: true
- name: trivy
image: registry.cn-hangzhou.aliyuncs.com/rookieops/trivy:v2
command: ['cat']
tty: true
volumeMounts:
- name: docker-sock
mountPath: /var/run/docker.sock
"""
}
}
environment {
auth = 'joker'
}
options {
timestamps() // 日志会有时间
skipDefaultCheckout() // 删除隐式checkout scm语句
disableConcurrentBuilds() //禁止并行
timeout(time:1, unit:'HOURS') //设置流水线超时时间
}
stages {
// 拉取代码
stage('GetCode') {
steps {
checkout([$class: 'GitSCM', branches: [[name: "${gitBranch}"]],
doGenerateSubmoduleConfigurations: false,
extensions: [],
submoduleCfg: [],
userRemoteConfigs: [[credentialsId: '83d2e934-75c9-48fe-9703-b48e2feff4d8', url: "${gitUrl}"]]])
}
}
// 单元测试和编译打包
stage('Build&Test') {
steps {
container('maven') {
script {
tools.PrintMes('编译打包', 'blue')
}
}
}
}
// 代码扫描
stage('CodeScanner') {
steps {
container('sonar-scanner') {
script {
tools.PrintMes('代码扫描', 'blue')
}
}
}
}
// 构建镜像
stage('BuildImage') {
steps {
container('docker') {
script {
tools.PrintMes('构建镜像', 'blue')
}
}
}
}
// 镜像扫描
stage('Vulnerability Scanner') {
steps {
container('trivy') {
script{
tools.PrintMes('镜像扫描', 'blue')
}
}
}
}
// 推送镜像
stage('Push Image') {
steps {
container('docker') {
script{
tools.PrintMes('推送镜像', 'blue')
}
}
}
}
// 部署
stage('Deploy DEV') {
when {
branchName 'dev'
}
steps {
container('kustomize'){
script{
tools.PrintMes('部署DEV环境','blue')
}
}
}
}
stage('Deploy TEST') {
when {
branchName 'test'
}
steps {
container('kustomize'){
script{
tools.PrintMes('部署TEST环境','blue')
}
}
}
}
stage('Deploy UAT') {
when {
branchName 'uat'
}
steps {
container('kustomize'){
script{
tools.PrintMes('部署UAT环境','blue')
}
}
}
}
stage('Deploy PRE') {
when {
branchName 'pre'
}
steps {
container('kustomize'){
script{
tools.PrintMes('部署PRE环境','blue')
}
}
}
}
stage('Deploy PROD') {
when {
branchName 'master'
}
steps {
container('kustomize'){
script{
tools.PrintMes('部署PROD环境','blue')
}
}
}
}
// 跟踪应用启动情况
stage('Check App Start') {
steps{
container('kubedog'){
script{
tools.PrintMes('跟踪应用启动', 'blue')
}
}
}
}
// 接口测试
stage('InterfaceTest') {
steps {
sh 'echo "接口测试"'
}
}
}
// 构建后的操作
post {
success {
script {
println('success:只有构建成功才会执行')
currentBuild.description += '\n构建成功!'
dingmes.SendDingTalk("构建成功 ✅")
}
}
failure {
script {
println('failure:只有构建失败才会执行')
currentBuild.description += '\n构建失败!'
dingmes.SendDingTalk("构建失败 ❌")
}
}
aborted {
script {
println('aborted:只有取消构建才会执行')
currentBuild.description += '\n构建取消!'
dingmes.SendDingTalk("构建失败 ❌","暂停或中断")
}
}
}
}
(3)在 Gitlab 上配置钩子
settings->webhook
到这里,Gitlab 和 Jenkins 集成就差不多完成了,后面就是具体的调试以及配置了。
写到最后
道路千万条,适合自己才最好。
上面是根据工作的实际情况做的运维发布,整体思路还有实现方式并不复杂,主要是充分利用各个软件地 webhook 能力,以及充分利用 Jenkins 灵活的插件功能,使得从创建发布计划和执行发布进行打通。
个人觉得还是有必要记录一下,也希望能帮助到有这方面需要的人。