kubernetes Sonar Qube DevOps概念及搭建全过程（Jenkins、Harbor、SonarQube、K8s）

DevOps入门及过程搭建

在如今互联网的格局下，抢占市场变得尤为重要，因此敏捷开发越来越被大家所推崇。于是，慢慢的有了DevOps这个概念，大致意思是开发-运维一体化。

1 DevOps概念

1.1 基本概念

可以看到上图是一个无穷大的一个符号，Dev对应开发，Ops对应运维。

DevOps的方式可以让公司能够更快地应对更新和市场发展变化，开发可以快速交付，部署也更加稳定。核心就在于简化Dev和Ops团队之间的流程，使整体软件开发过程更快速。

1.2 流程

DevOps的开发过程及常用工具：整体的软件开发流程包括：

PLAN：开发团队根据客户的目标制定开发计划CODE：根据PLAN开始编码过程，需要将不同版本的代码存储在一个库中。BUILD：编码完成后，需要将代码构建并且运行。TEST：成功构建项目后，需要测试代码是否存在BUG或错误。DEPLOY：代码经过手动测试和自动化测试后，认定代码已经准备好部署并且交给运维团队。OPERATE：运维团队将代码部署到生产环境中。MONITOR：项目部署上线后，需要持续的监控产品。INTEGRATE：然后将监控阶段收到的反馈发送回PLAN阶段，整体反复的流程就是DevOps的核心，即持续集成、持续部署。

总的来说就是：

Code阶段（编码）：Git+GitLabBuild阶段（构建）：Maven或GradleOperate（运行）：DockerIntegrate（集成）：Jenkins

CI/CD(持续集成)：操作Jenkins，编写对应脚本文件Code review（代码质量检测）：Jenkins集成Sonar Qube自定义镜像：HarborJenkins流水线操作WebHook：通知操作，如：钉钉机器人通知 K8S编排：更加方便我们管理容器

2 搭建DevOps环境

本项目全部采用docker安装，如果服务器上没有docker环境的，参考:https://editor.csdn.net/md/?articleId=127816970安装即可。

也可以参考本文档的2.2 Docker 章节

2.1 GitLab

在项目的Code（编码）阶段，我们需要将不同版本的代码存储到一个仓库中，常见的版本控制工具就是SVN或者Git，这里我们采用Git作为版本控制工具，GitLab作为远程仓库。

git的安装：参考官网，无脑下一步即可

官网地址：https://git-scm.com/

GitLab安装：

查看docker上gitlab的镜像,并拉取

# 查看镜像

docker search gitlab

# 拉取镜像

docker pull gitlab/gitlab-ce

准备docker-compose.yml文件

文档中的external_url等参考自己服务器上的ip

version: '3.1'

services:

gitlab:

image: 'gitlab/gitlab-ce:latest'

container_name: gitlab

restart: always

environment:

GITLAB_OMNIBUS_CONFIG: |

external_url 'http://192.168.11.11:8929'

gitlab_rails['gitlab_shell_ssh_port'] = 2224

ports:

- '8929:8929'

- '2224:2224'

volumes:

- './config:/etc/gitlab'

- './logs:/var/log/gitlab'

- './data:/var/opt/gitlab'

启动容器，并访问

# 启动容器

docker-compose up -d

访问：http://192.168.11.11:8929即可。效果： 4. 查看初始的用户名和密码

docker exec -it gitlab cat /etc/gitlab/initial_root_password

5. 登录并修改密码

以root身份登录gitlab，首次登录需要修改密码

然后我们就可以像GitHub、Gitee一样操作GitLab了

2.2 Docker

构建Java项目的工具一般有两种选择，一个是Maven，一个是Gradle。

这里我们选择Maven作为项目的编译工具。具体安装Maven流程不做阐述，但是需要确保配置好Maven仓库私服以及JDK编译版本。

部署过程，会采用Docker进行部署，暂时只安装Docker即可，后续还需安装Kubenetes

2.2.1 Docker安装

①准备测试环境&生产环境

②下载Docker依赖组件

yum -y install yum-utils device-mapper-persistent-data lvm2

③设置下载Docker的镜像源为阿里云

yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

④安装docker服务

yum -y install docker-ce

⑤设置docker开机自启

# 启动Docker服务

systemctl start docker

# 设置开机自动启动

systemctl enable docker

⑥测试安装成功

docker version

2.2.2 Docker-compose安装

下载Docker/Compose：https://github.com/docker/compose 将下载好的docker-compose-Linux-x86_64文件移动到Linux操作系统：…… 设置docker-compose-Linux-x86_64文件权限，并移动到$PATH目录中

# 设置文件权限

chmod a+x docker-compose-Linux-x86_64

# 移动到/usr/bin目录下，并重命名为docker-compose

mv docker-compose-Linux-x86_64 /usr/bin/docker-compose

2.3 Jenkins

2.3.1 介绍

在DevOps中持续集成和持续部署是很重要的一个环节，类似的工具也有很多，其中Jenkins是一个开源的持续集成平台。 Jenkins涉及到将编写完毕的代码发布到测试环境和生产环境的任务，并且还涉及到了构建项目等任务。

Jenkins需要大量的插件保证工作，安装成本较高，下面会基于Docker搭建Jenkins。

Jenkins是一个开源项目，基于Java开发的大多数互联网公司都是采永Jenkins配合GitLab、Docker、K8s作为DevOps的核心工具Jenkins官方提供了大量的插件库，用于完成自动化的CI/CD过程。

Jenkins主要工作：

拉取GitLab上的代码并进行构建根据流程可以选择发布到测试环境或是生产环境

GitLab上的代码经过大量测试后，确定发型版本，再发布到生产环境

CI/CD概念：

CI过程：JenKins将代码拉取、构建、制作镜像交给测试人员

持续集成：让软件代码可以持续的集成到主干上，并自动构建和测试 CD过程：通过Jenkins将打好标签的发行版本代码进行拉取、构建、制作镜像后交给运维人员部署

持续交付：让经过持续集成的代码可以进行手动部署持续部署：让可以持续交付的代码随时随地的自动化部署

2.3.2 Jenkins安装

拉取镜像

docker pull jenkins/jenkins

编写对应的docker-compose.yml

version: "3.1"

services:

jenkins:

image: jenkins/jenkins

container_name: jenkins

ports:

- 8080:8080

- 50000:50000

volumes:

- ./data/:/var/jenkins_home/

设置数据卷data目录的权限，否则会包没有对应权限

chmod -R a+w data/

设置Jenkins的下载地址

重新启动Jenkins容器后，由于Jenkins需要下载大量内容，但是由于默认下载地址下载速度较慢，需要重新设置下载地址为国内镜像站

# 修改数据卷中的hudson.model.UpdateCenter.xml文件

default

https://updates.jenkins.io/update-center.json

# 将下载地址替换为http://mirror.esuni.jp/jenkins/updates/update-center.json

default

http://mirror.esuni.jp/jenkins/updates/update-center.json

# 清华大学的插件源也可以https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json

再次重启Jenkins容器，访问JenKins 查看JenKins登录密码，并登录JenKins然后安装对应插件

docker exec -it jenkins cat /var/jenkins_home/secrets/initialAdminPassword

输入管理员密码 - 选择插件来安装 - 选择对应的插件进行安装

推荐安装： ①Git Parameter ②Publish Over SSH

然后等待插件安装成功进入首页。（可能会出现下载失败的插件，重新下载即可） 7. 创建管理员用户，设置Jenkins URL

2.3.3 Jenkins实现拉取-构建-发布

准备好GitLab仓库中的项目，并且通过Jenkins配置实现当前项目的DevOps流程。（Idea创建之后推送到远程即可）

构建Maven工程发布到GitlLab、Gitee、GitHub均可点击Jenkins左侧新建任务（选择自由风格的项目）配置源码拉取地址点击立即构建，查看构建日志配置Maven构建代码

代码拉取到Jenkins本地后，需要在Jenkins中对代码进行构建，这里需要Maven的环境，而Maven需要Java的环境，接下来需要在Jenkins中安装JDK和Maven，并且配置到Jenkins服务。

准备jdk、maven压缩包，通过数据卷映射到Jenkins容器内部解压压缩包，并配置Maven的settings.xml

alimaven

aliyun maven

http://maven.aliyun.com/nexus/content/groups/public/

central

jdk-1.8

true

1.8

Jenkins配置JDK&Maven并保存 maven配置同理配置Jenkins任务构建代码立即构建测试，查看target下的jar包

配置Publish发布&远程操作

jar包构建好后，就可以根据情况发布到测试或者生产环境，此处需要用到之前下载好的插件Publish Over SSH

配置Publish Over SSH连接测试环境、生产环境配置任务构建后的操作，发布jar包到目标服务

立即构建任务，并去目标服务查看

2.3.4 CI/CD操作

基于Jenkins拉取GitLab的SpringBoot代码进行构建发布到测试环境实现持续集成基于Jenkins拉取GitLab指定发行版本的SpringBoot进行构建发布到生产环境实现CD（持续部署）

为了让程序代码可以自动推送到测试环境基于Docker服务运行，需要添加Docker配置和脚本文件让程序可以在集成到主干的同时运行起来。

①持续集成

添加Dockerfile文件添加docker-compose.yml文件追加Jenkins构建后操作脚本命令发布到GitLab后由Jenkins立即构建并推送到目标服务器测试部署到目标服务器程序 ②持续交付、部署

程序代码在经过多次集成操作到达最终可以交付，持续交付整体流程和持续集成类似，不过需要选取指定的发行版本

下载Git Parameter插件设置项目参数化构建在GitLab上给项目添加tag版本任务构建时，采用Shell方式构建，拉取指定tag版本基于Parameter构建任务，任务发布到目标服务器

2.4 Sonar Qube

2.4.1 Sonar Qube介绍与安装

Sonar Qube是一个开源的代码分析平台，支持Java、Python、PHP、JavaScript、CSS等25种以上的语言，可以检测出重复代码、代码漏洞、代码规范和安全性漏洞的问题。

Sonar Qube可以与多种软件整合进行代码扫描，比如：Maven、Gradle、Git、Jenkins等，并且会将代码检测结果推送回Sonar Qube，进而在系统提供的UI界面上显示出来。

安装过程：

Sonar Qube在7.9版本中已经放弃了对MySQL的支持，并且建议在商业环境中采用PostgreSQL，那么安装Sonar Qube时需要依赖PostgreSQL。

①拉取PostgreSQL镜像

docker pull postgres

docker pull sonarqube:8.9.3-community

②编写docker-compose.yml

更易管理

version: "3.1"

services:

db:

image: postgres

container_name: db

ports:

- 5432:5432

networks:

- sonarnet

environment:

POSTGRES_USER: sonar

POSTGRES_PASSWORD: sonar

sonarqube:

image: sonarqube:8.9.3-community

container_name: sonarqube

depends_on:

- db

ports:

- "9000:9000"

networks:

- sonarnet

environment:

SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar

SONAR_JDBC_USERNAME: sonar

SONAR_JDBC_PASSWORD: sonar

networks:

sonarnet:

driver: bridge

③设置sysctl.conf文件信息，并启动容器

设置vm.max_map_count=262144，至少是这个数

# 执行命令进行刷新

sysctl -p

# 启动容器

docker-compose up -d

重新启动需要一定时间，可以查看容器日志，如果看到如下内容代表启动成功

④访问Sonar Qube首页

登录成功之后，会要求我们修改默认密码

首页图片：

安装中文插件

安装成功后需要重启，若安装失败，重新点击install即可

2.4.2 Sonar Qube基本使用

Sonar Qube的使用方式很多，Maven可以整合，也可以采用sonar-scanner的方式，再查看Sonar Qube的检测效果

①Maven实现代码检测

修改配置文件信息

修改本地Maven的settings.xml文件，配置Sonar Qube信息

sonar

true

admin

123456789

http://192.168.11.11:9000

在代码所在位置的cmd执行命令mvn sonar:sonar 检测结果：

②Sonar-scanner实现代码检测

下载对应版本

下载Sonar-scanner：https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/下载4.6.x版本即可，要求Linux版本

解压并配置sonar服务端信息

下载下来的Sonar-scanner是zip压缩包，因此需要在linux上安装unzip插件

# 安装unzip解压插件

yum -y install unzip

# 解压压缩包

unzip sonar-scanner-cli/sonar-scanner-cli-4.6.0.2311-linux.zip

配置sonarQube服务端地址，修改conf下的sonar-scanner.properties

执行命令检测代码

# 在项目所在目录执行以下命令

~/sonar-scanner/bin/sonar-scanner -Dsonar.sources=./ -Dsonar.projectname=demo -Dsonar.projectKey=java -Dsonar.java.binaries=target/

查看SonarQube界面检测结果

③Jenkins集成Sonar Qube

Jenkins集成Sonar Qube实现代码扫描需要下载整合插件

Jenkins安装插件【系统管理-插件管理】安装SonarQube Scanner插件 Jenkins配置Sonar Qube

在SonarQube中开启Sonar Qube的权限验证在Sonar Qube中生成一个令牌，获取Sonar Qube的令牌

在Jenkins中配置Sonar Qube信息

Dashboard - 系统配置

在Jenkins中配置Sonar-scanner

将Sonar-scanner添加到Jenkins数据卷中并全局配置

配置任务的Sonar-scanner

构建任务

Jenkins界面： SonarQube界面：

2.5 Harbor（镜像仓库）

2.5.1 Harbor介绍与安装

介绍

前面我们在部署时，主要流程如下：

Jenkins推送jar包到服务器通过脚本命令让目标服务器对当前jar进行部署

但是这种方式在项目比较多的时候，每个服务器都需要将jar包制作成自定义镜像，然后再通过docker进行启动，重复操作较多，降低部署效率。

Harbor：私有的Docker镜像仓库。我们可以让Jenkins统一将项目打包并制作成Docker镜像发布到Harbor仓库中。然后我们只需要通知目标服务，让目标服务统一去Harbor仓库上拉取镜像并在本地部署即可。

安装（通过原生的方式安装）

下载Harbor安装包 https://github.com/goharbor/harbor/releases/download/v2.3.4/harbor-offline-installer-v2.3.4.tgz传送到linux上并解压

# 通过xftp或其他方式将压缩包传送到linux上

# 解压

tar -zxvf harbor-offline-installer-v2.3.4.tgz -C /usr/local/

修改Harbor配置文件

设置harbor地址，注释https，查看密码

# 备份原有配置

cp harbor.yml.tmpl harbor.yml

4. 启动Harbor并登录Harbor

# 启动Harbor

./install.sh

首页信息：

2.5.2 Harbor基础使用

Harbor作为镜像仓库，主要的交互方式就是将镜像上传到Harbor，以及从Harbor上下载拉取指定版本的镜像。

在传输镜像前，可以先使用Harbor提供的权限管理，将项目设置为私有项目，并对不同用户设置不同角色，从而更方便管理镜像。

①添加用户构建项目

创建用户

系统管理-用户管理-创建用户

构建项目（设置为私有）给项目追加用户

②发布镜像到Harbor

修改镜像名称

名称要求：harbor地址/项目名/镜像名:版本

修改daemon.json，支持Docker仓库，并重启Docker 设置登录仓库信息

docker login -u 用户名 -p 密码 Harbor地址

推送镜像到Harbor

③从Harbor中拉取镜像

跟传统方式一样，不过需要先配置/etc/docker/daemon.json文件

{

"registry-mirrors": ["https://pee6w651.mirror.aliyuncs.com"],

"insecure-registries": ["192.168.11.11:80"]

}

拉取镜像：

拓展：Jenkins容器使用宿主机Docker并编写构建脚本

构建镜像和发布镜像到harbor都需要使用到docker命令。而在Jenkins容器内部安装Docker官方推荐直接采用宿主机带的Docker即可。

①设置Jenkins容器使用宿主机Docker

设置宿主机docker.sock权限

sudo chown root:root /var/run/docker.sock

sudo chmod o+rw /var/run/docker.sock

添加数据卷

version: "3.1"

services:

jenkins:

image: jenkins/jenkins

container_name: jenkins

ports:

- 8080:8080

- 50000:50000

volumes:

- ./data/:/var/jenkins_home/

- /usr/bin/docker:/usr/bin/docker

- /var/run/docker.sock:/var/run/docker.sock

- /etc/docker/daemon.json:/etc/docker/daemon.json

②添加构建操作 ③编写构建脚本

部署项目需要通过Publish Over SSH插件，让目标服务器执行命令。为了方便一次性实现拉取镜像和启动的命令，推荐采用脚本文件的方式。添加脚本文件到目标服务器，再通过Publish Over SSH插件让目标服务器执行脚本即可。

编写脚本文件,添加到目标服务器

deploy.sh:

harbor_url=$1

harbor_project_name=$2

project_name=$3

tag=$4

port=$5

imageName=$harbor_url/$harbor_project_name/$project_name:$tag

containerId=`docker ps -a | grep ${project_name} | awk '{print $1}'`

if [ "$containerId" != "" ] ; then

docker stop $containerId

docker rm $containerId

echo "Delete Container Success"

imageId=`docker images | grep ${project_name} | awk '{print $3}'`

if [ "$imageId" != "" ] ; then

docker rmi -f $imageId

echo "Delete Image Success"

docker login -u DevOps -p P@ssw0rd $harbor_url

docker pull $imageName

docker run -d -p $port:$port --name $project_name $imageName

echo "Start Container Success"

echo $project_name

设置文件权限为可执行：

chmod a+x deploy.sh

④配置构建后操作

2.6 Jenkins流水线（pipeline）、自动化脚本

2.6.1 Jenkins流水线任务介绍

之前采用的都是Jenkins的自由风格，每个流程都要通过不同的方式设置，并且构建过程中整体流程时不可见的，无法确认每个流程花费的时间，同时不方便问题的定位。

Jenkins的Pipeline可以让项目的发布整体流程可视化，明确执行的阶段，快速定位问题。让整个项目的生命周期可以通过一个Jenkinsfile文件管理，而且Jenkinsfile文件是可以放在项目中维护。

①构建Jenkins流水线任务

构建任务生成Groovy脚本构建后查看视图 ②Groovy脚本

Groovy脚本基本语法

// 所有脚本命令包含在pipeline{}中

pipeline {

// 指定任务在哪个节点执行（Jenkins支持分布式）

agent any

// 配置全局环境，指定变量名=变量值信息

environment{

host = '192.168.11.11'

}

// 存放所有任务的合集

stages {

// 单个任务

stage('任务1') {

// 实现任务的具体流程

steps {

echo 'do something'

}

// 单个任务

stage('任务2') {

// 实现任务的具体流程

steps {

echo 'do something'

}

// ……

}

编写例子测试查看效果 Ps：涉及到特定脚本，Jenkins给予了充足的提示，可以自动生成命令 ③JenkinsFile实现

Jenkinsfile方式需要将脚本内容编写到项目中的Jenkinsfile文件中，每次构建会自动拉取并且获取项目中的Jenkinsfile文件来对项目进行构建

配置pipeline 准备Jenkinsfile 测试效果

2.6.2 Jenkins流水线任务实现

参数化构建

添加参数化构建，方便选择不同的项目版本

2. 拉取Git代码

通过流水线语法生成Checkout代码的脚本

将*/master更改为标签${tag}

pipeline {

agent any

stages {

stage('拉取Git代码') {

steps {

checkout([$class: 'GitSCM', branches: [[name: '${tag}']], extensions: [], userRemoteConfigs: [[url: 'http://49.233.115.171:8929/root/test.git']]])

}

构建代码

通过脚本执行mvn的构建命令

pipeline {

agent any

stages {

stage('拉取Git代码') {

steps {

checkout([$class: 'GitSCM', branches: [[name: '${tag}']], extensions: [], userRemoteConfigs: [[url: 'http://49.233.115.171:8929/root/test.git']]])

}

stage('构建代码') {

steps {

sh '/var/jenkins_home/maven/bin/mvn clean package -DskipTests'

}

代码质量检测

通过脚本执行sonar-scanner命令即可

pipeline {

agent any

stages {

stage('拉取Git代码') {

steps {

checkout([$class: 'GitSCM', branches: [[name: '${tag}']], extensions: [], userRemoteConfigs: [[url: 'http://49.233.115.171:8929/root/test.git']]])

}

stage('构建代码') {

steps {

sh '/var/jenkins_home/maven/bin/mvn clean package -DskipTests'

}

stage('检测代码质量') {

steps {

sh '/var/jenkins_home/sonar-scanner/bin/sonar-scanner -Dsonar.sources=./ -Dsonar.projectname=${JOB_NAME} -Dsonar.projectKey=${JOB_NAME} -Dsonar.java.binaries=target/ -Dsonar.login=31388be45653876c1f51ec02f0d478e2d9d0e1fa'

}

制作自定义镜像并发布

生成自定义镜像脚本

pipeline {

agent any

environment{

harborHost = '192.168.11.11:80'

harborRepo = 'repository'

harborUser = 'DevOps'

harborPasswd = 'P@ssw0rd'

}

// 存放所有任务的合集

stages {

stage('拉取Git代码') {

steps {

checkout([$class: 'GitSCM', branches: [[name: '${tag}']], extensions: [], userRemoteConfigs: [[url: 'http://49.233.115.171:8929/root/test.git']]])

}

stage('构建代码') {

steps {

sh '/var/jenkins_home/maven/bin/mvn clean package -DskipTests'

}

stage('检测代码质量') {

steps {

}

stage('制作自定义镜像并发布Harbor') {

steps {

sh '''cp ./target/*.jar ./docker/

cd ./docker

docker build -t ${JOB_NAME}:${tag} ./'''

sh '''docker login -u ${harborUser} -p ${harborPasswd} ${harborHost}

docker tag ${JOB_NAME}:${tag} ${harborHost}/${harborRepo}/${JOB_NAME}:${tag}

docker push ${harborHost}/${harborRepo}/${JOB_NAME}:${tag}'''

}

生成Publish Over SSH脚本

pipeline {

agent any

environment{

harborHost = '192.168.11.11:80'

harborRepo = 'repository'

harborUser = 'DevOps'

harborPasswd = 'P@ssw0rd'

}

// 存放所有任务的合集

stages {

stage('拉取Git代码') {

steps {

checkout([$class: 'GitSCM', branches: [[name: '${tag}']], extensions: [], userRemoteConfigs: [[url: 'http://49.233.115.171:8929/root/test.git']]])

}

stage('构建代码') {

steps {

sh '/var/jenkins_home/maven/bin/mvn clean package -DskipTests'

}

}docker

stage('检测代码质量') {

steps {

}

stage('制作自定义镜像并发布Harbor') {

steps {

sh '''cp ./target/*.jar ./docker/

cd ./docker

docker build -t ${JOB_NAME}:${tag} ./'''

sh '''docker login -u ${harborUser} -p ${harborPasswd} ${harborHost}

docker tag ${JOB_NAME}:${tag} ${harborHost}/${harborRepo}/${JOB_NAME}:${tag}

docker push ${harborHost}/${harborRepo}/${JOB_NAME}:${tag}'''

}

stage('目标服务器拉取镜像并运行') {

steps {

sshPublisher(publishers: [sshPublisherDesc(configName: 'testEnvironment', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: "/usr/bin/deploy.sh $harborHost $harborRepo $JOB_NAME $tag $port ", execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: '', remoteDirectorySDF: false, removePrefix: '', sourceFiles: '')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: false)])

}

Ps：由于采用变量，记得使用双引号

2.6.3 Jenkins流水线整合钉钉

在程序部署成功之后，可以通过钉钉的机器人及时向开发人员发送部署的最终结果通知

步骤：Jenkins安装插件 - 钉钉创建群组并构建机器人 - Jenkins配置系统添加钉钉通知 - 任务中追加钉钉流水线配置

安装插件钉钉内部创建群组并构建机器人最终获取到Webhook信息：

https://oapi.dingtalk.com/robot/send?access_token=kej4ehkj34gjhg34jh5bh5jb34hj53b4

Jenkins系统配置添加钉钉通知任务线中追加流水线配置

pipeline {

agent any

environment {

sonarLogin = '2bab7bf7d5af25e2c2ca2f178af2c3c55c64d5d8'

harborUser = 'admin'

harborPassword = 'Harbor12345'

harborHost = '192.168.11.12:8888'

harborRepo = 'repository'

}

stages {

stage('拉取Git代码'){

steps {

checkout([$class: 'GitSCM', branches: [[name: '$tag']], extensions: [], userRemoteConfigs: [[url: 'http://49.233.115.171:8929/root/lsx.git']]])

}

stage('Maven构建代码'){

steps {

sh '/var/jenkins_home/maven/bin/mvn clean package -DskipTests'

}

stage('SonarQube检测代码'){

steps {

sh '/var/jenkins_home/sonar-scanner/bin/sonar-scanner -Dsonar.sources=./ -Dsonar.projectname=${JOB_NAME} -Dsonar.projectKey=${JOB_NAME} -Dsonar.java.binaries=target/ -Dsonar.login=${sonarLogin}'

}

stage('制作自定义镜像'){

steps {

sh '''cd docker

mv ../target/*.jar ./

docker build -t ${JOB_NAME}:$tag .

'''

}

stage('推送自定义镜像'){

steps {

sh '''docker login -u ${harborUser} -p ${harborPassword} ${harborHost}

docker tag ${JOB_NAME}:$tag ${harborHost}/${harborRepo}/${JOB_NAME}:$tag

docker push ${harborHost}/${harborRepo}/${JOB_NAME}:$tag'''

}

stage('通知目标服务器'){

steps {

sshPublisher(publishers: [sshPublisherDesc(configName: 'centos-docker', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: "/usr/bin/deploy.sh $harborHost $harborRepo $JOB_NAME $tag $port", execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: '', remoteDirectorySDF: false, removePrefix: '', sourceFiles: '')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: false)])

}

post {

success {

dingtalk (

robot: 'Jenkins-DingDing',

type:'MARKDOWN',

title: "success: ${JOB_NAME}",

text: ["- 成功构建:${JOB_NAME}项目!\n- 版本:${tag}\n- 持续时间:${currentBuild.durationString}\n- 任务:#${JOB_NAME}"]

)

}

failure {

dingtalk (

robot: 'Jenkins-DingDing',

type:'MARKDOWN',

title: "fail: ${JOB_NAME}",

text: ["- 失败构建:${JOB_NAME}项目!\n- 版本:${tag}\n- 持续时间:${currentBuild.durationString}\n- 任务:#${JOB_NAME}"]

)

}

查看效果

2.7 Kubernetes

2.7.1 介绍及安装

Kubernetes又称为k8s，是一个开源的，用于管理云平台中多个主机上的容器。目的是让容器化部署更加简单、高效。

①k8s主要作用：

服务发现和负载均衡（DNS名称或自己IP地址公开容器）存储编排（类似Docker的数据卷）自动部署和回滚（可以按照你的需求调整容器状态）自动完成装箱计算（允许你设置每个容器的资源，CPU、内存等）自我修复（可以重启失败的容器、替换容器、检查容器状况等）密钥与配置管理（允许存储和管理敏感信息，可以在不重建容器的情况下完成部署和更新密钥）

②k8s的架构

k8s搭建至少需要两个节点，一个Master负责管理，一个Slave搭建在工作服务器上负责分配

各个组件的基本功能

API Server：k8s通讯的核心组件，负责k8s内部交互及接收发送指令的组件controller-manage：资源调度，根据集群情况分配资源etcd：key-value数据库，存储集群的状态信息scheduler：负责调度每个工作节点cloud-controller-manage：负责调度其他云服务产品kubelet：管理Pods上面的容器kube-proxy：负责处理其他Slave或客户端的请求Pod：运行的容器

③k8s安装

本文采用https://kuboard.cn/提供的方式安装K8s，安装单Master节点

要求：至少使用Centos7.8版本至少2台2核4G服务器

准备好服务器之后开始安装：

1. 重新设置hostname，不允许为localhost

# 修改 hostname，名字不允许使用下划线、小数点、大写字母，不能叫master

hostnamectl set-hostname your-new-host-name

# 查看修改结果

hostnamectl status

# 设置 hostname 解析

echo "127.0.0.1 $(hostname)" >> /etc/hosts

要求2台服务器之间可以相互通讯

2. 安装kuboard软件

# 阿里云 docker hub 镜像

export REGISTRY_MIRROR=https://registry.cn-hangzhou.aliyuncs.com

curl -sSL https://kuboard.cn/install-script/v1.19.x/install_kubelet.sh | sh -s 1.19.5

3. 初始化Master节点

关于初始化时用到的环境变量

APISERVER_NAME 不能是 master 的 hostname APISERVER_NAME 必须全为小写字母、数字、小数点，不能包含减号 POD_SUBNET 所使用的网段不能与 master节点/worker节点所在的网段重叠。该字段的取值为一个 CIDR 值，如果您对 CIDR 这个概念还不熟悉，请仍然执行 export POD_SUBNET=10.100.0.0/16 命令，不做修改设置ip，域名，网段并执行初始化操作

# 只在 master 节点执行

# 替换 x.x.x.x 为 master 节点实际 IP（请使用内网 IP）

# export 命令只在当前 shell 会话中有效，开启新的 shell 窗口后，如果要继续安装过程，请重新执行此处的 export 命令

export MASTER_IP=192.168.11.32

# 替换 apiserver.demo 为您想要的 dnsName

export APISERVER_NAME=apiserver.demo

# Kubernetes 容器组所在的网段，该网段安装完成后，由 kubernetes 创建，事先并不存在于您的物理网络中

export POD_SUBNET=10.100.0.1/16

echo "${MASTER_IP} ${APISERVER_NAME}" >> /etc/hosts

curl -sSL https://kuboard.cn/install-script/v1.19.x/init_master.sh | sh -s 1.19.5

检查Master启动状态

# 只在 master 节点执行

# 执行如下命令，等待 3-10 分钟，直到所有的容器组处于 Running 状态

watch kubectl get pod -n kube-system -o wide

# 查看 master 节点初始化结果

kubectl get nodes -o wide

Ps：如果出现NotReady的情况执行（最新版本的BUG，1.19一般没有）

docker pull quay.io/coreos/flannel:v0.10.0-amd64

mkdir -p /etc/cni/net.d/

cat < /etc/cni/net.d/10-flannel.conf

{"name":"cbr0","type":"flannel","delegate": {"isDefaultGateway": true}}

EOF

mkdir /usr/share/oci-umount/oci-umount.d -p

mkdir /run/flannel/

cat < /run/flannel/subnet.env

FLANNEL_NETWORK=172.100.0.0/16

FLANNEL_SUBNET=172.100.1.0/24

FLANNEL_MTU=1450

FLANNEL_IPMASQ=true

EOF

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml

安装网络服务插件

export POD_SUBNET=10.100.0.0/16

kubectl apply -f https://kuboard.cn/install-script/v1.22.x/calico-operator.yaml

wget https://kuboard.cn/install-script/v1.22.x/calico-custom-resources.yaml

sed -i "s#192.168.0.0/16#${POD_SUBNET}#" calico-custom-resources.yaml

kubectl apply -f calico-custom-resources.yaml

4. 初始化worker节点

获取join命令参数，在Master节点执行

# 只在 master 节点执行

kubeadm token create --print-join-command

在worker节点初始化

# 只在 worker 节点执行

# 替换 x.x.x.x 为 master 节点的内网 IP

export MASTER_IP=192.168.11.32

# 替换 apiserver.demo 为初始化 master 节点时所使用的 APISERVER_NAME

export APISERVER_NAME=apiserver.demo

echo "${MASTER_IP} ${APISERVER_NAME}" >> /etc/hosts

# 替换为 master 节点上 kubeadm token create 命令的输出

kubeadm join apiserver.demo:6443 --token vwfilu.3nhndohc5gn1jv9k --discovery-token-ca-cert-hash sha256:22ff15cabfe87ab48a7db39b3bbf986fee92ec92eb8efc7fe9b0abe2175ff0c2

5. 检查最终运行结果

在Master节点运行

# 只在 master 节点执行

kubectl get nodes -o wide

Ps：如果出现NotReady的情况执行（最新版本的BUG，1.19一般没有）

docker pull quay.io/coreos/flannel:v0.10.0-amd64

mkdir -p /etc/cni/net.d/

cat < /etc/cni/net.d/10-flannel.conf

{"name":"cbr0","type":"flannel","delegate": {"isDefaultGateway": true}}

EOF

mkdir /usr/share/oci-umount/oci-umount.d -p

mkdir /run/flannel/

cat < /run/flannel/subnet.env

FLANNEL_NETWORK=172.100.0.0/16

FLANNEL_SUBNET=172.100.1.0/24

FLANNEL_MTU=1450

FLANNEL_IPMASQ=true

EOF

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml

获取节点信息

kubectl get nodes

6. 安装Kuboard管理k8s集群

安装Kuboard

kubectl apply -f https://addons.kuboard.cn/kuboard/kuboard-v3.yaml

# 您也可以使用下面的指令，唯一的区别是，该指令使用华为云的镜像仓库替代 docker hub 分发 Kuboard 所需要的镜像

# kubectl apply -f https://addons.kuboard.cn/kuboard/kuboard-v3-swr.yaml

查看启动情况

watch kubectl get pods -n kuboard

在浏览器中打开链接 http://your-node-ip-address:30080输入初始用户名和密码，并登录

用户名： admin密码： Kuboard123

2.7.2 k8s操作

首先k8s在运行我们的资源时，关联到了哪些内容呢？

资源的构建方式：

采用kubectl的命令方式yaml文件方式

①namespace

命名空间：对k8s中运行的资源进行隔离，但是网络是互通的。类似于docker的容器，可以将多个资源配置到一个namespace中。而namespace可以对不同环境进行资源隔离，默认情况下k8s提供了default命名空间。

命令方式：

# 查看现有的全部命名空间

kubectl get ns

# 构建命名空间

kubectl create ns 命名空间名称

# 删除现有命名空间，并且会删除空间下的全部资源

kubectl delete ns 命名空间名称

yaml文件方式（构建源时，设置命名空间）

apiVersion: v1

kind: Namespace

metadata:

②Pod

k8s中运行的一组容器，Pod是k8s的最小单位。但是对于Docker而言，Pod中会运行多个Docker容器

命令方式

# 查看所有运行的pod

kubectl get pods -A

# 查看指定Namespace下的Pod

kubectl get pod [-n 命名空间] #（默认default）

# 创建Pod

kubectl run pod名称 --image=镜像名称

# 查看Pod详细信息

kubectl describe pod pod名称

# 删除pod

kubectl delete pod pod名称 [-n 命名空间] #（默认default）

# 查看pod输出的日志

kubectl logs -f pod名称

# 进去pod容器内部

kubectl exec -it pod名称 -- bash

# 查看kubernetes给Pod分配的ip信息，并且通过ip和容器的端口，可以直接访问

kubectl get pod -owide

yaml方式（推荐）

apiVersion: v1

kind: Pod

metadata:

labels:

run: 运行的pod名称

namespace: 命名空间

spec:

containers:

- image: 镜像名称

# 启动Pod：kubectl apply -f yaml文件名称

# 删除Pod：kubectl delete -f yaml文件名称

Pod中运行多个容器

apiVersion: v1

kind: Pod

metadata:

labels:

run: 运行的pod名称

namespace: 命名空间

spec:

containers:

- image: 镜像名称

- image: 镜像名称

…………

Kuboard效果：

③Deployment

部署时，可以通过Deployment管理和编排Pod

命令方式

# 基于Deployment启动容器

kubectl create deployment deployment名称 --image=镜像名称

# 用deployment启动的容器会在被删除后自动再次创建，达到故障漂移的效果

# 需要使用deploy的方式删除deploy

# 查看现在的deployment

kubectl get deployment

# 删除deployment

kubectl delete deployment deployment名称

# 基于Deployment启动容器并设置Pod集群数

kubectl create deployment deployment名称 --image=镜像名称 --replicas 集群个数

配置文件方式

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: nginx

spec:

replicas: 3

selector:

matchLabels:

app: nginx

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx

ports:

- containerPort: 80

正常使用kubectl运行yaml即可

弹性伸缩功能：

# 基于scale实现弹性伸缩

kubectl scale deploy/Deployment名称 --replicas 集群个数

# 或者修改yaml文件

kubectl edit deploy Deployment名称

灰度发布： Deploy可以在部署新版本数据时，成功启动一个Pod，才会下线一个老版本Pod

kubectl set image deployment/Deployment名称容器名=镜像:版本

④service

可以将多个Pod整合为一个Service，让客户端通过这一个Service访问到这一组Pod，并且可以实现负载均衡

ClusterIP方式：

ClusterIP是集群内部Pod之间的访问方式

命令实现效果

# 通过生成service映射一个Deployment下的所有pod中的某一个端口的容器

kubectl expose deployment Deployment名称 --port=Service端口号 --target-port=Pod内容器端口

之后通过kubectl get service查看Service提供的ip，即可访问也可以通过Deployment名称.namespace名称.svc作为域名访问

NodePort方式

ClusterIP方式只能在Pod内部实现访问，但是一般需要对外暴露网关，所以需要NodePort的方式将Pod对外暴露访问

命令实现方式：

# 通过生成service映射一个Deployment下的所有pod中的某一个端口的容器

kubectl expose deployment Deployment名称 --port=Service端口号 --target-port=Pod内容器端口 --type=NodePort

Service通过yaml方式实现：

apiVersion: v1

kind: Service

metadata:

labels

app: nginx

spec:

selector:

app: nginx

ports:

- port: 8888

protocol: TCP

targetPort: 80

通过apply启动就可以创建Service

测试：通过Deployment部署，通过Service部署

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: nginx-deployment

spec:

replicas: 2

selector:

matchLabels:

app: nginx-deployment

template:

metadata:

labels:

app: nginx-deployment

spec:

containers:

- name: nginx-deployment

image: nginx

ports:

- containerPort: 80

---

apiVersion: v1

kind: Service

metadata:

labels:

app: nginx-service

spec:

selector:

app: nginx-deployment

ports:

- port: 8888

protocol: TCP

targetPort: 80

type: NodePort

可以查看到暴露信息：

⑤Ingress（入口）

k8s推荐将Ingress作为所有Service的入口，提供统一的入口，避免多个服务之间需要记录大量的IP或域名（IP可能变化，域名太多记录不方便）

Ingress底层就是一个Nginx，可以直接在kuboard上点击安装

因为副本数默认为1，但是k8s整体集群就2个节点，所以显示下面即为安装成功

可以将Ingress接收到的请求转发到不同的Service中

推荐使用yaml文件方式

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

spec:

ingressClassName: ingress

rules:

- host: nginx.mashibing.com

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 8888

Kuboard安装的Ingress有admission的校验配置，需要先删除配置再启动

找到指定的ingress的校验信息，删除即可

# 查看校验webhook的配置

kubectl get -A ValidatingWebhookConfiguration

# 删除指定的校验

kubectl delete ValidatingWebhookConfiguration ingress-nginx-admission-my-ingress-controller

配置本地hosts文件：下面就可以访问在Service中暴露的Nginx信息：

2.8 Jenkins集成K8s

2.8.1 准备部署的yaml文件

apiVersion: apps/v1

kind: Deployment

metadata:

namespace: test

labels:

app: pipeline

spec:

replicas: 2

selector:

matchLabels:

app: pipeline

template:

metadata:

labels:

app: pipeline

spec:

containers:

- name: pipeline

image: 192.168.11.102:80/repo/pipeline:v4.0.0

imagePullPolicy: Always

ports:

- containerPort: 8080

---

apiVersion: v1

kind: Service

metadata:

namespace: test

labels:

app: pipeline

spec:

selector:

app: pipeline

ports:

- port: 8081

targetPort: 8080

type: NodePort

---

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

namespace: test

spec:

ingressClassName: ingress

rules:

- host: mashibing.pipeline.com

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 8081

2.8.2 Harbor私服配置

在尝试用kubernetes的yml文件启动pipeline服务时，会出现Kubernetes无法拉取镜像的问题，这里需要在kubernetes所在的Linux中配置Harbor服务信息，并且保证Kubernetes可以拉取Harbor上的镜像

设置Master和Worker的私服地址信息在Kuboard上设置私服密文信息

将上图复制好的指定执行，测试结果如下：

2.8.3 测试使用效果

执行kubectl命令，基于yml启动服务，并且基于部署后服务的提示信息以及Ingress的设置，直接访问

2.8.4 Jenkins远程调用

将pipeline.yml配置到GitLab中配置Jenkins目标服务器，可以将yml文件传输到k8s的Master上

修改Jenkinsfile，重新设置流水线任务脚本，并测试效果设置Jenkins无密码登录k8s-master

将Jenkins中公钥信息复制到k8s-master的~/.ssh/authorized_keysz中，保证远程连接无密码

5. 设置执行kubectl的脚本到Jenkinsfile 查看效果：

可以查看到yml文件是由变化的，这样k8s就会重新加载

Ps：这种方式更适应与CD操作，将项目将基于某个版本部署到指定的目标服务器

2.9 基于GitLab的WebHooks

实现一个自动化的CI（开发人员push代码到Git仓库之后，Jenkins会自动构建项目，将最新的提交点代码构建并进行打包部署）。这里区别于上面的CD，CD需要基于某个版本进行部署，而这里每次都是将最新的提交点集成到主干上并测试。

2.9.1 WebHooks通知

开启Jenkins自动构建设置GitLab的Webhooks 关闭Jenkins的GitLab认证再次测试

拓展：实现滚动更新

因为pipeline没有改变时，每次不会重新加载，这样会导致Pod中的容器不会动态更新，这里需要使用kubectl的rollout restart命令滚动更新

参考文章

评论可见，请评论后查看内容，谢谢！！！

您阅读本篇文章共花了：

金钥匙

kubernetes Sonar Qube DevOps概念及搭建全过程（Jenkins、Harbor、SonarQube、K8s）

【Kubernetes 企业项目实战】06、基于 Jenkins+K8s 构建 DevOps 自动化运维管理平台（中）

kubernetes DevOps基础设施配置之jenkins对接K8S

发表评论取消回复

金钥匙

kubernetes Sonar Qube DevOps概念及搭建全过程（Jenkins、Harbor、SonarQube、K8s）

【Kubernetes 企业项目实战】06、基于 Jenkins+K8s 构建 DevOps 自动化运维管理平台（中）

kubernetes DevOps基础设施配置之jenkins对接K8S

相关文章

发表评论取消回复