CICD实现方法之二--Gitlab+Jenkins+K8S

Posted 2020-12-22

承接上篇文章：
上周发布了新的博客文章，CI实现方法之--Gitlab+Drone，有幸被51cto推荐到首页，在上次的文章中做了CI相说明与测试操作，在生产环境为了提高生产力，增加容错，避免人为误操作等，出现了CICD，对于CICD在此文章中再说明一次
随着DevOps的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery） 、持续部署（Continuous Deployment） 的新方法。

此次比之前增加了jenkins与k8s，k8s自不必多说，看官们应该都清楚，这里主要说明jenkins。

Jenkins是一款使用java语言开发的开源的自动化服务器。通过界面或者jenkinsfile告诉它执行什么任务，何时执行。理论上，我们可以让它执行任何任务，但是通常只应用于持续集成和持续交付。

一、测试前提条件

1. 实验环境说明
   测试主机：阿里云主机
   操作系统：CentOS 7.7
   测试主机配置：2C，8G

主机名	公网IP	内网IP	ROLE	PORT
node1	39.104.17.55	172.16.0.101	k8s-master	6443
node2	39.104.61.142	172.16.0.100	k8s-node1
node3	39.104.70.121	172.16.0.99	k8s-node2
node4	39.104.88.120	172.16.0.93	gitlab	80
node5	39.104.93.96	172.16.0.94	jenkins	8080
node6	39.104.70.51	172.16.0.98	harbor	80

1.1. 测试应用架构

此应用是一个应用商城，采用了微服务的概念，可以看出每一个模块都采用了适合的开发语言及数据库。

1.2. CICD测试流程说明

2.测试前准备
此文中不再介绍gitlab、Harbor与k8s安装部署与配置过程，如需要了解gitlab、Harbor相关请参考
https://blog.51cto.com/tonegu/2497290
k8s安装部署网上有很多，可以参考
https://blog.51cto.com/robinzs/2497365
2.1. 从代码仓库clone front-end项目
本地gitlab代码仓库创建front-end项目，并上传至内部gitlab代码仓库

任意主机操作：

yum –y install git
git clone https://gitee.com/guxu_9808/front-end.gits
cd front-end
git remote rm origin
git remote add origin http://39.104.88.120/root/front-end.git
git push origin master

2.2. harbor中创建front-ent项目

2.3. 部署sock-shap
在kubenetes集群中有kubectl命令节点执行以下命令：

git clone https://gitee.com/guxu_9808/microservices-demo.git
kubectl create namespace  sock-shop
kubectl apply -f microservices-demo/deploy/kubernetes/manifests/.

检查sock-shap部署结果，部署采用nodeport，所以用kubenetes集群任意worker节点IP访问
http://node_ip:30001

3.安装部署说明
3.1. 部署jenkins

docker run -itd --name jenkins -u root -p 50000:50000  -p 8080:8080 -v /var/jenkins_home:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock  jenkins/jenkins:lts

注：

1. 安装过程中选择jenkins推荐插件
2. 部署成功后会提示取得密码方法

3.2.部署完成
登录后如图：

4.配置说明
4.1. Jenkins配置
4.1.1. gitlab插件安装
Jenkins-->系统管理-->插件管理

可选插件-->过滤-->gitlab

4.1.2. gitlab插件配置
Jenkins-->系统管理-->系统配置

Jenkins-->配置-->gitlab-->点击添加



Gitlab api token取得方法
登录到gitlab后，按下图操作

完成后会生成token，将申请成功的token填入jenkins中。
4.1.3. gitlab插件测试
选择生成的gitlab api token，点击Test Connection，回显“Success”，表示连接成功。

4.1.4. Jenkins-CI对接Kubernetes
配置Jenkins URL，这里我们没有配置api-server地址和证书key，连接kubernetes，所以默认会去读取放在JENKINS_HOME的.kube/目录的kubeconfig文件，用于连接集群。如果通过安装包的方式安装的Jenkins HOME在/var/lib/jenkins/目录，我这里是通过容器方式启动，将kubeconfig文件直接放~/.kube/目录。
1) 复制kubernetes集群kubeconfig文件内容
2) 保存到Jenkins服务所在宿主机的config文件中
3) 复制粘贴到Jenkins容器内的~/.kube/config文件中

docker exec -it jenkins mkdir /root/.kube/
docker cp config  jenkins:/root/.kube/config

4) 在集群对应项目下创建secret

cd .kube
kubectl create secret kubeconfig --from-file=config
注：此步为jenkins Pipeline准备工作

5) Jenkins创建一个cloud，名称kubernetes

6) 测试cloud

4.1.7. 添加Harbor凭证
1) 按下图数字顺序点击

2) 添加凭据

4.2. 创建Jenkins流水线任务
4.2.1. 创建项目test-demo

pipeline {
  environment {
    registry = "172.16.0.98"
    project_name = "/front-end"
    app_name = "/front-end"
    registryCredential = ‘harbor‘
  }
  agent {
    kubernetes {
      defaultContainer ‘jnlp-slave:3.27-1-alpine‘
      yaml """
apiVersion: v1
kind: Pod
metadata:
  labels:
    some-label: some-label-value
spec:
  containers:
  - name: jnlp
    image: ‘jnlp-slave:3.27-1-alpine‘
    args: [‘$(JENKINS_SECRET)‘, ‘$(JENKINS_NAME)‘]

  - name : docker
    image: docker:19.03.2
    tty: true
    volumeMounts:
    - name: repo-docker-sock
      mountPath: /var/run/docker.sock
  - name: kubectl
    image: jenkins-tools:v1.0
    tty: true
    volumeMounts:
    - mountPath: "/root/.kube"
      name: "volume-0"
      readOnly: false
  volumes:
  - name: "volume-0"
    secret:
      secretName: "kubeconfig"
  - name: repo-docker-sock
    hostPath:
     path: /var/run/docker.sock
"""
    }
  }
  stages {
    stage(‘clone code‘) {
     steps {
            git credentialsId: ‘9371d980-6bc2-47aa-a47f-04cf78871e7a‘, url: ‘http://114.215.25.58/root/front-end.git‘
    }
   }
    stage(‘image build ‘) {
      steps {
        container(‘docker‘) {
         script {
          docker.withRegistry( ‘http:// 172.16.0.98‘, registryCredential ) {
             def dockerImage=docker.build registry + project_name + app_name  +":$BUILD_NUMBER"
             dockerImage.push()
         }
        }
      }
    }
  }
   stage(‘deploy app ‘) {
      steps {
         container(‘kubectl‘) {
          sh ‘sed  -i "s/image: .*front-end:.*/image: 172.16.0.98\/front-end\/front-end:$BUILD_ID/g" front-end-dep.yaml‘
          sh ‘kubectl apply -f front-end-dep.yaml‘
     }
    }
  }
 }
}

4.2.3. 获取Pipeline中git credentialsId



注：生成流水线脚本替换Pipeline中git credentialsId常量。
4.2.4.1. jenkins 构建触发器配置
编辑jenkins项目test-demo，勾选配置使用Build when a change is pushed to GitLab. GitLab CI Service URL: http://XXXXXXXXXXXXXXXXXXXXXXX 当代码有更新的时候触发，通过GitLab CI

保存：http://39.104.93.96:8080/project/test-demo，需要在配置gitlab，webhook时使用到。
4.2.4.2. gitlab webhook配置
打开gitlab对应项目下，配置webhook回掉地址，填入jenkins对应项目地址
gitlab对应的项目设置页

**注：默认触发器是push事件时，触发webhook，需要注意的是因为我们这里的Jenkins配置了用户名和密码所以 url需要在原来基础上添加用户名和密码其他不变 格式为http://username:password@39.104.93.96:8080/project/test-demo
补充：
GitHub Hook 触发器
Jenkins有一个GitHub插件，可在收到有关推送更改和拉取请求的通知后触发构建。通过GitHub Webhooks，当事件触发时，GitHub会通过HTTP POST发送到Jenkins webhook的配置URL。收到POST后，Jenkins将简单地对SCM进行内部轮询。
你可以在GitHub上手动配置Jenkins Hook的URL，或者Jenkins本身可以根据配置管理项目的Hook。对于托管模式，你还必须配置对GitHub的身份验证，如果你在GitHub中启用了双重身份验证，Jenkins将无法进行身份验证。
GitHub Webhooks的使用要求Jenkins必须可从互联网访问。该插件的文档还提到了hook网址是所有仓库独一无二的，但没有提及对发送方所需要的任何一种认证。使用此功能之前，应先评估文档中列出的其他安全隐患。
4.2.4.3. gitlab webhook配置测试

4.2.4.4. 触发jenkins前准备
修改front-end项目前端logo，然后git push到代码仓库，触发Jenkins进行cicd操作，修改front-end/public/navbar.html的<img src="img/logo.png"为新的图片XXXXX.png，然后将代码提交触发cicd重新打开前端看见logo变了。

1.在项目所在主机将XXXX.png放到已clone之宿主机目录/root/front-end/public/img/下
2.执行命令

git add .
git commit –m "test0"
git push

4.2.4.5. 触发jenkins后自动执行

---

做好记录是做为IT从业人员必须具备的要素，此次测试完成了一次完整的CICD，gitlab项目代码改变后通过jenkins自动执行build,build images将镜像上传至Harbor，Kubernetes部署替代原有pod。
想了解更多关于k8s，云平台信息可以关注我的微博，会定时更新新的技术及测试案例哦。