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

承接上篇文章：
上周发布了新的博客文章，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

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，云平台信息可以关注我的微博，会定时更新新的技术及测试案例哦。