-
Jenkins 管理插件 BlueOcean 配置和使用
-
BlueOcean 是什么?
- 为了适应 Jenkins Pipeline 和 Freestyle jobs 任务,Jenkins 推出了 BlueOcean UI,其目的就是让程序员执行任务时,降低工作流程的复杂度和提升工作流程的清晰度
- 它具有如下特征:
1、清晰的可视化:对 CI/CD pipelines, 可以快速直观的观察项目 pipeline 状态。
2、pipeline 可编辑:引导用户通过直观的、可视化的过程来创建 Pipeline,从而使 Pipeline 的创建变得平易近人。
3、pipeline 精确度:通过 UI 直接介入 pipeline 的中间问题。 - 安装 BlueOcean 插件
主页—>系统管理→插件管理→可选插件—>过滤 BlueOcean→直接安装 安装完成后重启 jenkins
-
Jenkins 实现 k8s 应用按照指定版本回滚
- 回到首页:
新建一个任务------>输入一个任务名称处输入 jenkins-variable-test-deploy-rollout------>流水线------>确定------>在 Pipeline script 处输入如下内容
node('testhan') {
stage('git clone') {
git url: "https://gitee.com/gaofei0428/jenkins-rollout.git"
sh "ls -al"
sh "pwd"
}
stage('select env') {
def envInput = input(
id: 'envInput',
message: 'Choose a deploy environment',
parameters: [
[
$class: 'ChoiceParameterDefinition',
choices: "devlopment\nqatest\nproduction",
name: 'Env'
]
]
)
echo "This is a deploy step to ${envInput}"
sh "sed -i 's/<namespace>/${envInput}/' getVersion.sh"
sh "sed -i 's/<namespace>/${envInput}/' rollout.sh"
sh "bash getVersion.sh"
// env.WORKSPACE = pwd()
// def version = readFile "${env.WORKSPACE}/version.csv"
// println version
}
stage('select version') {
env.WORKSPACE = pwd()
def version = readFile "${env.WORKSPACE}/version.csv"
println version
def userInput = input(id: 'userInput',
message: '选择回滚版本',
parameters: [
[
$class: 'ChoiceParameterDefinition',
choices: "$version\n",
name: 'Version'
]
]
)
sh "sed -i 's/<version>/${userInput}/' rollout.sh"
}
stage('rollout deploy') {
sh "bash rollout.sh"
}
} - 点击应用->保存-立即构建
-
什么是 Tekton?
- Tekton 是一个功能强大且灵活的 Kubernetes 原生开源框架,是谷歌开源的,功能强大且灵活,开源社区也正在快速的迭代和发展壮大,主要用于创建持续集成和交付(CI/CD)系统。通过抽象底层实现细节,用户可以跨多云平台和本地系统进行构建、测试和部署。另外,基于 kubernetes CRD 定义的pipeline 流水线也是 Tekton 最重要的特征。
- 扩展:CRD 是什么?
- CRD 全称是 CustomResourceDefinition:在 Kubernetes 中一切都可视为资源,Kubernetes 1.7 之后增加了对 CRD 自定义资源二次开发能力来扩展 Kubernetes API,通过 CRD 我们可以向 Kubernetes API 中增加新资源类型,而不需要修改 Kubernetes 源码来创建自定义的 API server,该功能大大提高了 Kubernetes 的扩展能力。
- 当你创建一个新的 CustomResourceDefinition (CRD)时,Kubernetes API 服务器将为你指定的每个版本创建一个新的 RESTful 资源路径,我们可以根据该 api 路径来创建一些我们自己定义的类型资源。
- CRD 可以是命名空间的,也可以是集群范围的,由 CRD 的作用域(scpoe)字段中所指定的,与现有的内置对象一样,删除名称空间将删除该名称空间中的所有自定义对象。customresourcedefinition 本身没有名称空间,所有名称空间都可以使用。
-
为什么要用 k8s 原生的 CI-CD 工具 Tekton?
- 持续集成是云原生应用的支柱技术之一,因此在交付基于云原生的一些支撑产品的时候,CICD 是非常好的方案。为了满足这种需要,自然而然会想到对 Jenkins(X)或者 Gitlab 进行集成,也有创业公司出来的一些小工具比如 Argo Rollout。Tekton 是一款 k8s 原生的应用发布框架,主要用来构建CI/CD 系统。它原本是 knative 项目里面一个叫做 build-pipeline 的子项目,用来作为 knativebuild 的下一代引擎。然而,随着 k8s 社区里各种各样的需求涌入,这个子项目慢慢成长为一个通用的框架,能够提供灵活强大的能力去做基于 k8s 的构建发布。Tekton 其实只提供 Pipeline 这个一个功能,Pipeline 会被直接映射成 K8s Pod 等 API 资源。而比如应用发布过程的控制,灰度和上线策略,都是我们自己编写 K8s Controller 来实现的,也就意味着 Tekton 不会在 K8s 上盖一个”大帽子“,比如我们想看发布状态、日志等是直接通过 K8s 查看这个 Pipeline 对应的 Pod 的状态和日志,不需要再面对另外一个 API。
-
Tekton 功能:
1.Kubernetes 原生的 Tekton 的所有配置都是使用 CRD 方式进行编写存储的,非常易于检索和使用。
2.配置和流程分离: Tekton 的 Pipeline 和配置可以分开编写,使用名称进行引用。
3.轻量级核心的 Pipeline 非常轻便:适合作为组件进行集成,另外也有周边的 Dashboard、Trigger、CLI 等工具,能够进一步挖掘其潜力。
4.可复用、组合的 Pipeline 构建方式:非常适合在集成过程中对 Pipeline 进行定制。 -
使用 Tekton 自动化发布应用流程
这里的流程大致是:
1、用户把需要部署的应用先按照一套标准的应用定义写成 YAML 文件(类似 Helm Chart);
2、用户把应用定义 YAML 推送到 Git 仓库里;
3、Tekton CD (一个 K8s Operator) 会监听到相应的改动,根据不同条件生成不同的 TektonPipelines;
Tekton CD 的操作具体分为以下几种情况:
1、如果 Git 改动里有一个应用 YAML 且该应用不存在,那么将渲染和生成 Tekton Pipelines 用来创建应用。
2、如果 Git 改动里有一个应用 YAML 且该应用存在,那么将渲染和生成 Tekton Pipelines 用来升级应用。这里我们会根据应用定义 YAML 里的策略来做升级,比如做金丝雀发布、灰度升级。
3、如果 Git 改动里有一个应用 YAML 且该应用存在且标记了“被删除”,那么将渲染和生成Tekton Pipelines 用来删除应用。确认应用被删除后,我们才从 Git 里删除这个应用的 YAML。 -
安装 Tekton
-
#编写安装 tekton 资源清单文件
#kubectl apply -f release.yaml
找到下面这些东西,说明创建 crd 成功了
pipelineresources.tekton.dev
pipelineruns.tekton.dev
pipelines.tekton.dev
taskruns.tekton.dev
tasks.tekton.dev
看到下面说明 apiversion 创建成功了
-
Tekton 概念
-
Tekton 为 Kubernetes 提供了多种 CRD 资源对象,可用于定义我们的流水线,主要有以下几个CRD 资源对象:
1)Task:表示执行命令的一系列步骤,task 里可以定义一系列的 steps,例如编译代码、构建镜像、推送镜像等,每个 step 实际由一个 Pod 里的容器执行。
2)TaskRun:task 只是定义了一个模版,taskRun 才真正代表了一次实际的运行,当然你也可以自己手动创建一个 taskRun,taskRun 创建出来之后,就会自动触发 task 描述的构建任务。
3)Pipeline:一组任务,表示一个或多个 task、PipelineResource 以及各种定义参数的集合。
4)PipelineRun:类似 task 和 taskRun 的关系,pipelineRun 也表示某一次实际运行的pipeline,下发一个 pipelineRun CRD 实例到 Kubernetes 后,同样也会触发一次 pipeline 的构建。
5)PipelineResource:表示 pipeline 输入资源,比如 github 上的源码,或者 pipeline 输出资源,例如一个容器镜像或者构建生成的 jar 包等。
-
测试 Tekton 构建 CI/CD 流水线
-
测试一个简单的 golang 程序。
-
应用程序代码,测试及 dockerfile 文件可在如下地址获取:https://github.com/luckylucky421/tekton-demo
-
clone 应用程序代码进行测试,创建一个 task 任务
vim task-test.yaml
#上面内容解释说明:
resources 定义了我们的任务中定义的步骤中需要输入的内容,这里我们的步骤需要 Clone 一个Git 仓库作为 go test 命令的输入。Tekton 内置了一种 git 资源类型,它会自动将代码仓库 Clone 到 /workspace/$input_name 目录中,由于我们这里输入被命名成 repo,所以代码会被 Clone 到 /workspace/repo 目录下面。然后下面的 steps 就是来定义执行运行测试命令的步骤,这里我们直接在代码的根目录中运行 go test 命令即可,需要注意的是命令和参数需要分别定义 -
创建 pipelineresource 资源对象
-
通过上面步骤我们定义了一个 Task 任务,但是该任务并不会立即执行,我们必须创建一个TaskRun 引用它并提供所有必需输入的数据才行。这里我们就需要将 git 代码库作为输入,我们必须先创建一个 PipelineResource 对象来定义输入信息,创建一个名为 pipelineresource.yaml 的资源清单文件,内容如下所示:
vim pipelineresource.yaml
-
创建 taskrun 任务
vim taskrun.yaml
#上面资源清单文件解释说明
这里通过 taskRef 引用上面定义的 Task 和 git 仓库作为输入,resourceRef 也是引用上面定义的PipelineResource 资源对象。
#创建后,我们可以通过查看 TaskRun 资源对象的状态来查看构建状态当任务执行完成后, Pod 就会变成 Completed 状态了:
可以通过 kubectl describe 命令来查看任务运行的过程,首先就是通过 initContainer 中的一个 busybox 镜像将代码 Clone 下来,然后使用任务中定义的镜像来执行命令。当任务执行完成后,Pod 就会变成 Completed 状态了,可以查看容器的日志信息来了解任务的执行结果信息:
#通过上面可以看到我们的测试已经通过了(Successfully )。
-
总结:我们已经在 Kubernetes 集群上成功安装了 Tekton,定义了一个 Task,并通过 YAML 清单和创建 TaskRun 对其进行了测试。
-
自定义 CRD 资源
-
通过 crd 资源创建自定义资源,即自定义一个 Restful API:
vim crontab-crd.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
-
Yaml 文件注解:
metadata.name 是用户自定义资源中自己自定义的一个名字。一般我们建议使用“顶级域名.xxx.APIGroup”这样的格式,名称必须与下面的 spec.Group 字段匹配,格式为: <plural>.<group>spec 用于指定该 CRD 的 group、version。比如在创建 Pod 或者 Deployment 时,它的group 可能为 apps/v1 或者 apps/v1beta1 之类,这里我们也同样需要去定义 CRD 的 group。
group: stable.example.com #组名称
versions:
- name: v1
#指定组下的版本
served: true
#每个版本都可以通过服务标志启用/禁用
storage: true
#必须将一个且只有一个版本标记为存储版本。
scope: Namespaced
#指定 crd 资源作用范围在命名空间或集群
names 指的是它的 kind 是什么,比如 Deployment 的 kind 就是 Deployment,Pod 的
kind 就是 Pod,这里的 kind 被定义为了 CronTab
plural 字段就是一个昵称,比如当一些字段或者一些资源的名字比较长时,可以用该字段自定义一
些昵称来简化它的长度;
singular: crontab
# 在 CLI(shell 界面输入的参数)上用作别名并用于显示的单数名称
shortNames:
- ct
# 短名称允许短字符串匹配 CLI 上的资源,就是能通过 kubectl 在查看资源的时候使用该资源的简
名称来获取。 - 创建自定义资源的对象
- 根据 crd 对象资源创建出来的 RESTful API,来创建 crontab 类型资源对象
vim my-crontab.yaml
提示:可以看到对应类型资源已经创建成功;以上示例只是单纯的 crd 的使用示例,没有任何实质的作用。