前言：

在上一篇文章中，我们已经在K8S集群部署了Jenkins、Harbor和EFK。作为本系列最后一篇文章，将通过实际案例串联所有的基础软件服务，基于K8S做DevOps。

整体的业务流程如下图所示：

一、一机多Jenkins Slave

由于业务需要，我们的自动化测试需要基于windows做web功能测试，每一个测试任务独占一个windows用户桌面，所以我们首先要给Jenkins配置几个Windows的Slave Node.在我之前的post《持续集成CI实施指南三–jenkins集成测试》中详细讲解了给Jenkins添加Node的方法步骤。 本篇无需重复，但这里主要讲的是，如何在一台Windows服务器上搭建多个Jenkins Node，供多用户使用。

• 在目标机上建立多个用户，如下图所示：

  

• 用Administrator用户安装JDK

• 在Jenkins的节点管理建立三个Node，分别为WinTester01、WinTester02、WinTester03，配置如下

  

• 在目标机的Administrator，用IE打开Jenkins并进入节点管理，在WinTester01、WinTester02、WinTester03中分别点击“Launch”启动Slave

  

• 确认启动成功后，点击“File”下的“Install as service”

  

• 三个Slave都启动后，可以在服务管理器看到

  

• 除了Jenkins Slave1无需配置，Slave2和Slave3都需要右键进入属性，修改登录用户分别为JenkinsSlave2和JenkinsSlave3

  

通过上面的配置，可以在一台目标机部署三个用户对应三个Jenkins Slave以满足我们的业务需求。

二、 二次开发Jenkins 钉钉通知插件

在整个DevOps的业务流程图上，我们想使用钉钉作为通知方式，相比邮件而言，实时性和扩展性都很高。在2018年4月，Jenkins的钉钉通知插件有两款，分别是Dingding JSON Pusher和Dingding notification plugin，前者长期未更新，已经不能使用，后者可以在非Pipeline模式下使用，对于Pipeline则有一些问题。虽然目前，Dingding notification plugin已经更新到1.9版本并支持了Pipeline，但在当时，我们不得不在1.4版本的基础上做二次开发。

整体开发经过参考《Jenkins项目实战之-钉钉提醒插件二次开发举例》，总体来说还是比较简单：

• 修改”src/main/java/com/ztbsuper/dingtalk/DingTalkNotifier.java”，钉钉的消息API类型有文本、link、markdown、card等，我们这里把通知接口改成文本类型

  public class DingTalkNotifier extends Notifier implements SimpleBuildStep {    private String accessToken;    private String message;    private String imageUrl;    private String messageUrl;    @DataBoundConstructor    public DingTalkNotifier(String accessToken, String message, String imageUrl, String messageUrl) {        this.accessToken = accessToken; //钉钉的accesstoken        this.message = message;    //消息主体        this.imageUrl = imageUrl;  //缩略图        this.messageUrl = messageUrl;  //消息的链接来源，一般是jenkins的build url    }    public String getAccessToken() {        return accessToken;    }    public String getMessage() {        return message;    }    public String getImageUrl() {        return imageUrl;    }    public String getMessageUrl() {        return messageUrl;    }    @Override    public void perform(@Nonnull Run, ?> run, @Nonnull FilePath filePath, @Nonnull Launcher launcher, @Nonnull TaskListener taskListener) throws InterruptedException, IOException {        String buildInfo = run.getFullDisplayName();        if (!StringUtils.isBlank(message)) {            sendMessage(LinkMessage.builder()                    .title(buildInfo)                    .picUrl(imageUrl)                    .text(message)                    .messageUrl(messageUrl)                    .build());        }    }    private void sendMessage(DingMessage message) {        DingTalkClient dingTalkClient = DingTalkClient.getInstance();        try {            dingTalkClient.sendMessage(accessToken, message);        } catch (IOException e) {            e.printStackTrace();        }    }    @Override    public BuildStepMonitor getRequiredMonitorService() {        return BuildStepMonitor.NONE;    }    @Symbol("dingTalk")    @Extension    public static final class DescriptorImpl extends BuildStepDescriptor {        @Override        public boolean isApplicable(Class extends AbstractProject> aClass) {            return true;        }        @Nonnull        @Override        public String getDisplayName() {            return Messages.DingTalkNotifier_DescriptorImpl_DisplayName();        }    }}

• 用maven打包

  maven需要安装java环境，为了方便，我直接run一个maven的docker image，编译完成后把hpi文件send出来

• 在jenkins的插件管理页面上传hpi文件

  

• 在钉钉群中开启自定义机器人

  

• 找到accesstoken

  

• 在jenkins pipeline中可以使用以下命令发送信息到钉钉群

  dingTalk accessToken:"2fccafaexxxx",message:"信息",imageUrl:"图片地址",messageUrl:"消息链接"

三、 DevOps解决方案

针对每一个软件项目增加部署目录，目录结构如下：

• _deploy

• deployment.yaml

• Dockerfile

• other files

• deployment.yaml

• Dockerfile

• other files

• master

• test

master和test文件夹用于区分测试环境与生产环境的部署配置

Dockerfile和other files用于生成应用或服务的镜像

如前端vue和nodejs项目的Dockerfile：

# 前端项目运行环境的Image，从Harbor获取FROM xxx/xxx/frontend:1.0.0 RUN mkdir -p /workspace/build && mkdir -p /workspace/runCOPY . /workspace/build# 编译，生成执行文件，并删除源文件RUN cd /workspace/build/frontend && \    cnpm install && \    npm run test && \    cp -r /workspace/build/app/* /workspace/run && \    rm -rf /workspace/build && \    cd /workspace/run && \    cnpm install # 运行项目，用npm run test或run prod区分测试和生产环境CMD cd /workspace/run && npm run test

又如dotnet core项目的Dockerfile：

# dotnet项目编译环境的Image，从Harbor获取FROM xxx/xxx/aspnetcore-build:2 AS builderWORKDIR /appCOPY . .# 编译RUN cd /app/xxxRUN pwd && ls -al && dotnet restoreRUN dotnet publish -c Release -o publish# dotnet项目运行环境的Image，从Harbor获取FROM xxx/xxx/aspnetcore:2WORKDIR /publishCOPY --from=builder /app/xxx/publish .# 重命名配置文件，中缀test、prod用于区分测试环境和生产环境RUN mv appsettings.test.json appsettings.json# 运行ENTRYPOINT ["dotnet", "xxx.dll"]

deployent.yaml用于执行应用或服务在k8s上的部署

由于deployment有很多配置项可以抽离成公共配置，所以deployment的配置有很多占位变量，占位变量用两个#中间加变量名表示，如下所示：

apiVersion: v1  kind: Namespace  metadata:      name: #namespace#      labels:        name: #namespace#  ---apiVersion: v1data:  .dockerconfigjson: xxxxxxxxxxxxxxxxxxxxxxkind: Secretmetadata:  name: regcred  namespace: #namespace#  type: kubernetes.io/dockerconfigjson---apiVersion: extensions/v1beta1kind: Deploymentmetadata:  name: #app#-deploy  namespace: #namespace#   labels:    app: #app#-deployspec:  replicas: #replicas#  strategy:    type: Recreate  template:    metadata:      labels:        app: #app#    spec:      containers:      - image:  #image#          name: #app#        ports:        - containerPort: #port#          name: #app#        securityContext:          privileged: #privileged#        volumeMounts:        - name: log-volume          mountPath: #log#      - image:  #filebeatImage#          name: filebeat        args: [          "-c", "/etc/filebeat.yml"        ]        securityContext:          runAsUser: 0        volumeMounts:        - name: config          mountPath: /etc/filebeat.yml          readOnly: true          subPath: filebeat.yml        - name: log-volume          mountPath: /var/log/container/      volumes:      - name: config        configMap:          defaultMode: 0600          name: filebeat-config      - name: log-volume        emptyDir: {}      imagePullSecrets:      - name: regcred---apiVersion: v1kind: ConfigMapmetadata:  name: filebeat-config  namespace: #namespace#  labels:    app: filebeatdata:  filebeat.yml: |-    filebeat.inputs:    - type: log      enabled: true      paths:        - /var/log/container/*.log    output.elasticsearch:      hosts: ["#es#"]    tags: ["#namespace#-#app#"]---apiVersion: v1kind: Servicemetadata:  name: #app#-service  namespace: #namespace#   labels:    app: #app#-servicespec:  ports:    - port: 80      targetPort: #port#      selector:    app: #app#---apiVersion: extensions/v1beta1kind: Ingressmetadata:  name: #app#-ingress  namespace: #namespace#    annotations:      nginx.ingress.kubernetes.io/proxy-body-size: "0"      nginx.ingress.kubernetes.io/rewrite-target: /spec:  rules:  - host: #host#      http:      paths:      - path: #urlPath#        backend:          serviceName: #app#-service          servicePort: 80

其中几个关键变量的解释如下：

• dockerconfigjson：因为所有的镜像需要从Harbor获取，而Harbor的镜像如果设置为私有权限，就需要提供身份验证，这里的dockerconfigjson就是Harbor的身份信息。生成dockerconfigjson的方法如下：

• 进入K8S任何一个节点，删除” ~/.docker/config.json ” 文件

• 使用命令” docker login harbor地址”登录harbor

• 通过命令” cat ~/.docker/config.json “可以看到harbor的身份验证信息

• 使用命令” cat /root/.docker/config.json | base64 -w 0 “对信息编码，将生成后的编码填写到deployment.yaml的dockerconfigjson节点即可

• namespace：同一个项目的不同k8s组件应置于同一个namespace，所以namespace可统一配置，在我们的项目实践中，生产环境的namespace为” 项目名 “，测试环境的namespace为” 项目名-test “

• app：应用或服务名称

• image：应用或服务的镜像地址

• replicas：副本数量

• port：应用或服务的Pod开放端口

• log：应用或服务的日志路径，在本系列的第二篇文章中，提到我们的日志方案是给每个应用或服务配一个filebeat，放在同一Pod中，这里只需告知应用或服务的日志的绝对路径，filebeat就能将日志传递到ES中，日志的tag命名方式为” namespace-app”

• host：在本系列的第一篇文章中，讲了使用nginx ingress做服务暴露与负载。这里的host就是给nginx ingress设置的域名，端口默认都是80，如果需要https，则在外层使用阿里云SLB转发

• urlPath：很多情况下，如微服务，需要通过相同的域名，不同的一级目录将请求分发到不同的后台，在nginx中，就是location的配置与反向代理，比如host的配置是确定了域名aaa.bbb.com，而urlPath的配置是确定aaa.bbb.com/user/getuser将会被转发到用户服务podIP:podPort/getuser中

以上所有的占位变量都是在Pipeline Script中赋值，关于Jenkins Pipeline的相关内容介绍这里不再多讲，还是去看官方文档靠谱。我们这里将k8s的部署文件deployment.yaml与Jenkinsfile结合，即可做到一个deployment.yaml能适配所有项目，一个Pipeline Script模板能适配所有项目，针对不同的项目，只需在Pipeline Script中给占位变量赋值，大大降低了配置复杂度。下面是一个项目的Jenkins配置示例：

对于一个项目，我们只需配置Trigger和Pipeline，上图“Do not allow concurrent builds ”也是通过Pipeline的配置生成的。Pipeline Script示例如下：

pipeline {    // 指定项目在label为jnlp-agent的节点上构建，也就是Jenkins Slave in Pod    agent { label 'jnlp-agent' }     // 对应Do not allow concurrent builds     options {        disableConcurrentBuilds()    }    environment {         // ------ 以下内容，每个项目可能均有不同，按需修改 ------         //author：用于钉钉通知        author="张三"        // branch: 分支，一般是test、 master，对应git从哪个分支拉取代码，也对应究竟执行_deploy文件夹下的test配置还是master配置        branch = "test"        // namespace: myproject-test, myproject，命名空间一般是项目名称，测试环境加test        namespace = "myproject-test"        // hostname：对应deployment中的host        host = "test.aaa.bbb.com"        // appname：对应deployment中的app        app = "myserver"        // port：对应deployment中的port        port= "80"        // replicas：对应deployment中的replicas        replicas = 2        //git repo path：git的地址        git="git@git.aaa.bbb.com/xxx.git"         //log：对应deployment中的log        log="/publish/logs/"        // ------ 以下内容，一般所有的项目都一样，不经常修改 ------        // harbor inner address        repoHost = "192.168.0.1:23280"        // harbor的账号密码信息，在jenkins中配置用户名/密码形式的认证信息，命名成harbor即可        harborCreds = credentials('harbor')        // filebeat的镜像地址        filebeatImage="${repoHost}/common/filebeat:6.3.1"        // es的内网访问地址        es="elasticsearch-logging.kube-system:9200"    }    // ------ 以下内容无需修改 ------    stages {         // 开始构建前清空工作目录         stage ("CleanWS"){             steps {                script {                    try{                       deleteDir()                    }catch(err){                        echo "${err}"                        sh 'exit 1'                    }                }              }          }        // 拉取        stage ("CheckOut"){             steps {                script {                    try{                      checkout([$class: 'GitSCM', branches: [[name: "*/${branch}"]], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'gitlab', url: "${git}"]]])                    }catch(err){                        echo "${err}"                        sh 'exit 1'                    }                }              }          }       // 构建        stage ("Build"){             steps {                script {                    try{                        // 登录 harbor                         sh "docker login -u ${harborCreds_USR} -p ${harborCreds_PSW} ${repoHost}"                        sh "date +%Y%m%d%H%m%S > timestamp"                        // 镜像tag用时间戳代表                        tag = readFile('timestamp').replace("\n", "").replace("\r", "")                        repoPath = "${repoHost}/${namespace}/${app}:${tag}"                        // 根据分支，进入_deploy下对应的不同文件夹，通过dockerfile打包镜像                        sh "cp _deploy/${branch}/* ./"                        sh "docker login -u ${harborCreds_USR} -p ${harborCreds_PSW} ${repoHost}"                        sh "docker build -t ${repoPath}  ."                    }catch(err){                        echo "${err}"                        sh 'exit 1'                    }                }              }          }        // 镜像推送到harbor        stage ("Push"){            steps {                script {                    try{                        sh "docker push ${repoPath}"                    }catch(err){                        echo "${err}"                        sh 'exit 1'                    }                }               }        }        // 使用pipeline script中复制的变量替换deployment.yaml中的占位变量，执行deployment.yaml进行部署        stage ("Deploy"){            steps {                script {                    try{                        sh "sed -i 's|#namespace#|${namespace}|g' deployment.yaml"                        sh "sed -i 's|#app#|${app}|g' deployment.yaml"                        sh "sed -i 's|#image#|${repoPath}|g' deployment.yaml"                        sh "sed -i 's|#port#|${port}|g' deployment.yaml"                        sh "sed -i 's|#host#|${host}|g' deployment.yaml"                        sh "sed -i 's|#replicas#|${replicas}|g' deployment.yaml"                        sh "sed -i 's|#log#|${log}|g' deployment.yaml"                        sh "sed -i 's|#filebeatImage#|${filebeatImage}|g' deployment.yaml"                        sh "sed -i 's|#es#|${es}|g' deployment.yaml"                        sh "sed -i 's|#redisImage#|${redisImage}|g' deployment.yaml"                        sh "cat deployment.yaml"                        sh "kubectl apply -f deployment.yaml"                       }catch(err){                        echo "${err}"                        sh 'exit 1'                    }                }            }        }    }    post {        // 使用钉钉插件进行通知        always {            script {                   def msg = "【${author}】你把服务器搞挂了，老詹喊你回家改BUG！"                def imageUrl = "https://www.iconsdb.com/icons/preview/red/x-mark-3-xxl-2.png"                if (currentBuild.currentResult=="SUCCESS"){                    imageUrl= "http://icons.iconarchive.com/icons/paomedia/small-n-flat/1024/sign-check-icon-2.png"                    msg ="【${author}】发布成功，干得不错！"                }                dingTalk accessToken:"xxxx",message:"${msg}",imageUrl:"${imageUrl}",messageUrl:"${BUILD_URL}"            }        }    }}

发布完成后，可以参考《持续集成CI实施指南三–jenkins集成测试》，做持续测试，测试结果也可通过钉钉通知。最后我们利用自建的运维平台，监控阿里云ECS状态、K8S各组件状态、监控ES中的日志并做异常抓取和报警。形成一整套DevOps模式。

综上，对于每个项目，我们只需维护Dockerfile，并在Jenkins创建持续集成项目时，填写项目所需的参数变量。进阶情况下，也可定制性的修改deployment文件与pipeline script，满足不同的业务需要。至此，完结，撒花！