背景：

紧跟Kubernetes中spinnaker的应用一。实现了简略的各种Triggers触发器，还有deploy Mainfest部署一个kubernetes的简略流水线。这里依据理论的环境想更深刻一下流水线步骤:参数化的构建，webhook的触发，邮件的发送,jenkins流水线的集成等等
首先明确一下pipeline是由多个stage组成的：

对于默认的stage能够参照官网：https://spinnaker.io/docs/reference/pipeline/stages/。环境次要是kubernetes环境这里重视于：

从一条 pipeline开始

创立application

创立利用 pipeline-test,Permissions权限给运维组读写执行权限（其余组权限看集体需要，这里仅用作演示）

创立流水线pipeline

创立pipeline流水线---Parameters-test1

Parameters-对于参数化构建

筹备前提：

参数化的构建是在Configuration步骤的

依照罕用的常规将Kubernetes中spinnaker的应用一中的流水线拿来做试验！

apiVersion: apps/v1kind: Deploymentmetadata:  labels:    k8s-app: nginxdemo  name: nginxdemo  namespace: devspec:  replicas: 1  selector:    matchLabels:      k8s-app: nginxdemo  template:    metadata:      labels:        k8s-app: nginxdemo      name: nginxdemo      namespace: dev    spec:      containers:        - image: 'harbor.xxxx.com/spinnaker/spinnaker-nginx-demo:1.2.4'          imagePullPolicy: Always          name: nginxdemo          ports:            - containerPort: 80              name: web              protocol: TCP      imagePullSecrets:        - name: harbor-layame

定义参数Parameters：

定义image参数,设置默认镜像tag为nginx:1.18.0

deploy Mainfest

这里的stage name是能够自定义名称的,间接设置stage name为公布利用：
Manifest Configuration

apiVersion: apps/v1kind: Deploymentmetadata:  labels:    k8s-app: nginxdemo  name: nginxdemo  namespace: devspec:  replicas: 1  selector:    matchLabels:      k8s-app: nginxdemo  template:    metadata:      labels:        k8s-app: nginxdemo      name: nginxdemo      namespace: dev    spec:      containers:        - image: '${ parameters.image }'          imagePullPolicy: Always          name: nginxdemo          ports:            - containerPort: 80              name: web              protocol: TCP

减少webhook stage 保留流水线

Payload 如下：当然了也能够本人更为细节的去欠缺！

{  "msgtype": "text",  "text": {    "content": "流水线 ${execution['name']}运行中, 运行用户 ${execution['trigger']['user']}"  }

集群中操作

确保dev namespace存在（这里将存在的deployments删除，不便比照！）

run流水线并验证部署后果

pipelines界面Start Manual Execution 抉择Parameters-test1流水线image应用默认的nginx:1.18.0, Run

OK 后果如下：流水线状态SUCCEEDED，微信webhook收到告诉，dev namespace下deployments部署胜利。

减少parameters replicas参数

为什么抉择relicas正本数做例子呢？为了强调参数化部署非字符串的的数值时要将值tolnt

  replicas: '${#toInt(parameters.replicas)}'

Manifest Configuration如下：

apiVersion: apps/v1kind: Deploymentmetadata:  labels:    k8s-app: nginxdemo  name: nginxdemo  namespace: devspec:  replicas: '${#toInt(parameters.replicas)}'  selector:    matchLabels:      k8s-app: nginxdemo  template:    metadata:      labels:        k8s-app: nginxdemo      name: nginxdemo      namespace: dev    spec:      containers:        - image: '${ parameters.image }'          imagePullPolicy: Always          name: nginxdemo          ports:            - containerPort: 80              name: web              protocol: TCP

running 流水线。这里为了跟上次辨别replicas我手动输出了2！

验证后果如下：

流水线回滚

长期回滚（疏忽没有找到）

泽阳大佬的课程下面有长期回滚的形式：

然而1.26.6版本貌似排版变了我找了一圈没有找到长期回滚还是间接整主动回滚了！

配置回滚

先说一下流水线中的stage

Configuration 默认的是不计算在内的。公布利用是第一个增加的那他的id为0， 部署告诉是第二个stage 他的id是1， Manual Judgment是第三个建设的他的id是2， Undo Rollout是最初增加的他的id是3。
这个中央貌似有点很绕。stage是从0开始的，依照创立stage的程序来的。

创立Manual Judgment stage

人工判断stage 。减少rollback done选项。done约定俗成是实现，rollback是回滚。作为下一步Undo Rollout触发的条件！

Manual Judgment 回滚 stage 抉择

强调一下Manual Judgment的id是2。所以这里的stages是2 ，一下表达式的含意是流水线stages2中judgmentInput 是rollback。

${ execution['stages'][2].context.judgmentInput == "rollback" }

运行流水线验证：

曾经验证过了.....具体集群中pod的image就不截图了。这里最须要留神的的表达式的应用！

欠缺一下线上的流水线：

拿jenkins中spinnaker-nginx-demo pipeline 来搞。先说一下本人要实现的：
嗯gitlab触发jenkins打包镜像（这里从新定义镜像tag用工夫）。而后将参数流传给spinnaker触发！

git仓库以及jenkins配置：

参照jenkins Trigger 触发器，当然了这里批改了一点参数化构建减少Dynimic Parameter(如何没有本人百度找插件)参数。定义名字data（能够本人定义名称，集体习惯就用data了）！
Default Value Script如下：

return new Date().format('yyyyMMddHHmm')

jenkins的流水线

就将镜像的tag批改为了data其实

//Docker 镜像仓库信息registryServer = "harbor.xxxxx.com"projectName = "${JOB_NAME}".split('-')[0]repoName = "${JOB_NAME}"imageName = "${registryServer}/${projectName}/${repoName}"//pipelinepipeline{    agent { node { label "build01"}}  //设置构建触发器    triggers {          GenericTrigger( causeString: 'Generic Cause',                         genericVariables: [[defaultValue: '', key: 'branchName', regexpFilter: '', value: '$.ref']],                                 printContributedVariables: true,                         printPostContent: true,                         regexpFilterExpression: '',                         regexpFilterText: '',                         silentResponse: true,                         token: 'spinnaker-nginx-demo')    }    stages{        stage("CheckOut"){            steps{                script{                              srcUrl = "https://gitlab.xxxx.com/zhangpeng/spinnaker-nginx-demo.git"                              branchName = branchName - "refs/heads/"                              currentBuild.description = "Trigger by ${branchName}"                    println("${branchName}")                    checkout([$class: 'GitSCM',                               branches: [[name: "${branchName}"]],                               doGenerateSubmoduleConfigurations: false,                               extensions: [],                               submoduleCfg: [],                               userRemoteConfigs: [[credentialsId: 'gitlab-admin-user',                                                   url: "${srcUrl}"]]])                }            }        }        stage("Push Image "){            steps{                script{                    withCredentials([usernamePassword(credentialsId: 'harbor-admin-user', passwordVariable: 'password', usernameVariable: 'username')]) {                        sh """                           sed -i -- "s/VER/${branchName}/g" app/index.html                           docker login -u ${username} -p ${password} ${registryServer}                           docker build -t ${imageName}:${data}  .                           docker push ${imageName}:${data}                           docker rmi ${imageName}:${data}                        """                    }                }            }        }        stage("Trigger File"){            steps {                script{                    sh """                        echo IMAGE=${imageName}:${data} >trigger.properties                        echo ACTION=DEPLOY >> trigger.properties                        cat trigger.properties                    """                    archiveArtifacts allowEmptyArchive: true, artifacts: 'trigger.properties', followSymlinks: false                }            }        }    }}

view 一下trigger.properties

spinnaker中的pipeline设置

创立pipeline

在pipline-test利用（applications），中创立spinnaker-nginx-demo pipeline，这里我间接copy了Parameters-test1的流水线

Configuration中Automated Triggers 配置

jenkins 触发器并增加Property File（jenkins中的制品）trigger.properties（留神别多复制了空格）

留神：Parameters配置下删除了image参数然而保留了replicas参数。主动触发默认参数仍是2 ，故前面的正本数量是2。

Deploy (Manifest) Configuration（公布利用 stage批改）

image: "${trigger['properties']['IMAGE']}"

Undo Rollout (Manifest)回滚利用的配置

git文件批改文件触发 and jenkins联动

jenkins构建版本79

登陆spinnakerweb验证

先抉择一下done

就是上面这样的跳过了回滚的stage

验证镜像

rollback回滚验证

再触发一次抉择rollback

这里spinnaker显示jenkins构建80略慢.......

流水线webhook的信息

当然这里也能够把动作，构建参数个性化自定义一下？这里只是抛砖引玉简略的跑通。后续有好玩的能够更输出分享

后记

流水线stage在管道工具中的的id，这个中央肯定要留神一下
非字符串参数的toInt
参数中偷懒复制名词的时候的空格
还一样比拟坑的....我重装了一遍spinnaker练手。设置内部redis的时候配置文件携程了redis.yaml所以始终没有失效....找了良久的问题最初才发现，yaml vs yml切记。
只学习简略实用的性能，简单的就不去钻研了。深入研究请参考泽阳老师大佬的spinnaker课程。特地鸣谢泽阳大佬。jenkins spinnaker课程都是跟大佬的步调来的！泽阳大佬的devops云学堂。