1. 配置dockerfile
在 Vue
项目根目录下创建一个 Dockerfile_backend_pc
,用于构建 Vue
应用的镜像。示例内容如下:
docker
# 镜像配置
# 使用官方Nginx镜像作为基础镜像
FROM nginx
# 删除默认配置文件
RUN rm /etc/nginx/conf.d/default.conf
# 将本地根目录的nginx配置文件【configs/default.conf】 文件夹放置在镜像中的/etc/nginx/conf.d/文件夹
ADD configs/default.conf /etc/nginx/conf.d/
# 将编译后的dist目录文件复制到nginx服务目录
COPY dist/ /usr/share/nginx/html/
注意,dockerfile配置文件的名字可以用DockerFile也可以是其他,但需要与jenkinsfile文件中的
docker build
创建镜像读取dockerfile的文件名保持一致在本项目中,
docker build
创建镜像的命令是sh "docker build -t ${DOCKER_IMAGE_FILE}:latest -f ./Dockerfile_${DOCKER_IMAGE_FILE} ."
其中,DOCKER_IMAGE_FILE
是配置好的环境变量,本项目指backend_pc
(后续会说明),因此,dockerfil
e文件名【Dockerfile_backend_pc
】与docker build
【./Dockerfile_${DOCKER_IMAGE_FILE}
】创建镜像的名字是保持一致的
2. 构建并推送 Docker 镜像
2.1 创建构建计划
在coding
下找到 持续集成 菜单,点击创建构建计划-自定义构建计划后,如下图所示:
填写好名称 ,选择对应项目代码仓库,即可以创建一个构建计划。
2.2 设置构建计划
点击构建计划的设置功能,可以更改配置:
2.2.1 设置Jenkins Pipeline
点击流程设置-文本编辑 ,jenkinsfile
文件配置如下:
jenkinsfile
pipeline {
agent any
stages {
stage('检出') {
steps {
checkout([
$class: 'GitSCM',// 使用 Git 插件进行检出操作
branches: [[name: GIT_BUILD_REF]],// 指定要检出的分支或提交,此处使用环境变量 GIT_BUILD_REF
userRemoteConfigs: [[
url: GIT_REPO_URL,// Git 仓库地址,此处使用环境变量 GIT_REPO_URL
credentialsId: CREDENTIALS_ID// 认证凭证ID,用于访问私有仓库
]]])
}
}
stage('构建') {
steps {
sh 'node -v'
sh 'npm config set registry http://mirrors.cloud.tencent.com/npm/'
sh 'npm install'
script {
env.build_time = sh(returnStdout: true, script: 'date +%Y-%m-%d_%H%M%S').trim()
if (env.BRANCH_NAME ==~ /.*master.*/ || env.BRANCH_NAME ==~ /.*release.*/) {
env.tag = 'rel'
sh 'npm run build'
} else {
env.tag = 'dev'
sh 'npm run test'
}
}
sh 'ls'
}
}
stage('构建镜像并推送到 CODING Docker 制品库') {
steps {
echo '构建镜像开始'
sh 'ls -a'
sh "docker build -t ${DOCKER_IMAGE_FILE}:latest -f ./Dockerfile_${DOCKER_IMAGE_FILE} ."
sh 'docker tag ${DOCKER_IMAGE_FILE}:latest ${DOCKER_IMAGE_FILE}:${tag}-${build_time}'
useCustomStepPlugin(key: 'SYSTEM:artifact_docker_push', version: 'latest', params: [repo:'backend_pc',image:'${DOCKER_IMAGE_FILE}:${tag}-${build_time}',properties:'[]'])
}
}
}
}
这段代码是一个 Jenkins Pipeline 的定义,用于自动化持续集成和部署流程。整个 Pipeline 包含以下三个阶段:
- 检出 (Checkout)
jenkinsfile
stage('检出') {
steps {
checkout([
$class: 'GitSCM', // 使用 Git 插件进行检出操作
branches: [[name: GIT_BUILD_REF]], // 指定要检出的分支或提交,此处使用环境变量 GIT_BUILD_REF
userRemoteConfigs: [[
url: GIT_REPO_URL, // Git 仓库地址,此处使用环境变量 GIT_REPO_URL
credentialsId: CREDENTIALS_ID // 认证凭证ID,用于访问私有仓库
]]
])
}
}
- 初始化一个名为"检出"的构建阶段。
- 在该阶段内执行
checkout
步骤,调用 Jenkins 的 Git 插件从指定的 Git 仓库中拉取代码。 branches
参数指定了要检出的分支名称,这里使用了环境变量GIT_BUILD_REF
,可以根据实际需要设置为具体的分支名或提交哈希。userRemoteConfigs
列表中的元素配置了远程仓库的URL和访问凭证。这里的 URL 通过环境变量GIT_REPO_URL
获取,而访问凭证 ID 是CREDENTIALS_ID
,它应该在 Jenkins 中预设好并指向能够访问该 Git 仓库的认证凭据。
- 构建 (Build)
jenkinsfile
stage('构建') {
steps {
sh 'node -v'
sh 'npm config set registry http://mirrors.cloud.tencent.com/npm/'
sh 'npm install'
script {
env.build_time = sh(returnStdout: true, script: 'date +%Y-%m-%d_%H%M%S').trim()
if (env.BRANCH_NAME ==~ /.*master.*/ || env.BRANCH_NAME ==~ /.*release.*/) {
env.tag = 'rel'
sh 'npm run build'
} else {
env.tag = 'dev'
sh 'npm run test'
}
}
sh 'ls'
}
}
-
sh 'node -v'
: 执行命令行指令检查 Node.js 的版本。 -
sh 'npm config set registry http://mirrors.cloud.tencent.com/npm/'
: 设置 npm 包管理器的默认注册表为腾讯云的镜像地址。 -
sh 'npm install'
: 在项目根目录下执行npm install
命令安装项目依赖。 -
使用 Groovy 的
script
块来定义一些环境变量和条件判断逻辑:env.build_time = sh(returnStdout: true, script: 'date +%Y-%m-%d_%H%M%S').trim()
:设置一个环境变量build_time
,其值为当前时间戳(格式化为年-月-日_时分秒)。- 根据不同的分支名称进行条件判断:
- 如果当前分支名包含 "master" 或 "release",则将环境变量
tag
设置为 "rel",并运行生产环境构建命令npm run build
。 - 否则,将环境变量
tag
设置为 "dev",并运行测试命令npm run test
。
- 如果当前分支名包含 "master" 或 "release",则将环境变量
-
sh 'ls'
: 执行ls
命令列出当前工作目录下的文件列表。
这个构建阶段的主要目的是根据不同的 Git 分支执行相应的构建或测试操作,并记录构建的时间戳。同时,它也确保了所有依赖项都已正确安装。
- 构建镜像并推送到 CODING Docker 制品库
jenkinsfile
stage('构建镜像并推送到 CODING Docker 制品库') {
steps {
echo '构建镜像开始'
sh 'ls -a'
sh "docker build -t ${DOCKER_IMAGE_FILE}:latest -f ./Dockerfile_${DOCKER_IMAGE_FILE} ."
sh 'docker tag ${DOCKER_IMAGE_FILE}:latest ${DOCKER_IMAGE_FILE}:${tag}-${build_time}'
useCustomStepPlugin(key: 'SYSTEM:artifact_docker_push', version: 'latest', params: [repo:'backend_pc',image:'${DOCKER_IMAGE_FILE}:${tag}-${build_time}',properties:'[]'])
}
}
在这个Jenkinsfile片段中,stage('构建镜像并推送到 CODING Docker 制品库')
阶段定义了构建Docker镜像并将其推送到CODING的Docker制品库的过程。以下是详细解释:
echo '构建镜像开始'
: 输出日志信息,表示开始构建镜像。sh 'ls -a'
: 执行shell命令列出当前工作目录下的所有文件和目录(包括隐藏文件)。sh "docker build -t ${DOCKER_IMAGE_FILE}:latest -f ./Dockerfile_${DOCKER_IMAGE_FILE} ."
: 使用指定的Dockerfile (./Dockerfile_${DOCKER_IMAGE_FILE}
) 构建Docker镜像,并打上标签${DOCKER_IMAGE_FILE}:latest
。sh 'docker tag ${DOCKER_IMAGE_FILE}:latest ${DOCKER_IMAGE_FILE}:${tag}-${build_time}'
: 给构建好的镜像添加一个新标签,该标签包含了构建时的特定版本号${tag}-${build_time}
。useCustomStepPlugin(key: 'SYSTEM:artifact_docker_push', version: 'latest', params: [repo:'byd_backend_pc',image:'${DOCKER_IMAGE_FILE}:${tag}-${build_time}',properties:'[]'])
: 这是一个自定义插件步骤,用于将构建好的Docker镜像推送到CODING的Docker制品库。参数说明:key
: 插件标识符。version
: 插件版本。params.repo
: 指定要推送至的仓库名称,在此案例中是backend_pc
。params.image
: 要推送的镜像完整名称,包含仓库名、镜像名以及标签,此处为${DOCKER_IMAGE_FILE}:${tag}-${build_time}
。
这里与 Dockerfile
片段相互作用,表示在 Docke
r 镜像构建过程中,将本地的 dist/
目录内容复制到镜像中的 /usr/share/nginx/html/
目录,这通常是用来配置 Nginx 服务器的静态网页内容目录。
请确保已正确设置环境变量 DOCKER_IMAGE_FILE
(再在变量与缓存里设置) 和 tag
(在构建阶段已配置),并且 Jenkins 服务器已安装并配置了与 CODING Docker
制品库交互所需的插件或凭证。同时,请核实 build_time
是否已经被正确地定义和赋值为本次构建的时间戳或其他唯一标识。
2.2.2 设置触发规则
有 更新时自动执行 、合并请求两种触发规则,本项目暂时选择合并请求:
2.2.3 变量与缓存
为了减少下次构建时间,可以为npm
开启缓存。同时,环境变量也可以设置。如下:
除了在 Jenkinsfile 中硬编码环境变量,还可以在构建计划的配置中进行设置。目前 CODING 支持添加以下四种类别的环境变量:字符串、单选、多选、CODING 凭据。您还可以将构建计划中的环境变量配置视为启动参数的默认值。(详情介绍可参考coding文档)
构建计划中的启动参数,优先级仅次于 Jenkinsfile 中配置的环境变量,可以在启动构建计划时,选择或填写对应的环境变量值。
注:本项目中,设置了
DOCKER_IMAGE_FILE
变量,值是backend_pc
3. 制品仓库设置
在 Coding 中,使用 Jenkinsfile 配置 Jenkins Pipeline 来构建和部署应用,并希望将构建产出的制品(Docker 镜像)推送到 Coding 的制品仓库(容器镜像仓库),可以按照以下步骤操作:
- 配置Jenkinsfile : 在 Jenkinsfile 中添加构建、登录Coding Registry以及推送镜像的步骤。Docker镜像名是
your-namespace/your-image
(自定义),并且你已经为Jenkins配置了访问Coding Registry所需的凭据。 - 创建并配置凭证 : 在 Jenkins 系统管理 -> 凭证管理中,创建一个具有 Coding 容器镜像仓库访问权限的凭证,ID 可以设置为
CODING_REGISTRY_CREDENTIALS
,然后在 Jenkinsfile 中通过withCredentials
步骤引用这个凭证。 - 执行Pipeline: 当 Jenkins 读取到 Jenkinsfile 并执行流水线时,它会自动构建 Docker 镜像,然后使用凭证登录 Coding 的 Registry,并将镜像推送到指定的命名空间下的镜像仓库。
- 关联与查看制品: 在完成上述流程后,构建产出的制品已经被成功关联到了 Coding 的制品仓库中。你可以在 Coding 控制台中查看和管理上传的镜像。
因此需要新建一个制品仓库【制品管理-创建制品仓库 】,如下:
在【制品管理-制品仓库-仓库管理】中,选中对应的制品仓库,可获取到对应的地址:
这里的制品仓库地址用于关联部署配置的Docker 镜像名字
4. 持续部署配置
4.1 关联制品仓库
可配置代码仓库、分支、文件路径
绑定制品的过程中,CODING 部署控制台使用了一个便捷的规则实现。首先在部署流程中定义了需要部署的Deploment,当部署阶段执行时,如果执行上下文中有如下的制品,最终被部署到集群中。因此,可以在项目中新增测试和正式环境的YAML文件,用于部署配置:
在根目录新建 configs/backend-test.yaml(测试)、configs/backend-rel.yaml(正式)
yaml
# k8s部署yaml,含svc与deployment
#指定api版本标签
apiVersion: apps/v1
#定义资源的类型/角色,deployment为副本控制器
#此处资源类型可以是Deployment、Job、Ingress、Service等
kind: Deployment
#定义资源的元数据信息,比如资源的名称、namespace、标签等信息
metadata:
name: nginx-deployment #定义资源的名称,在同一个namespace空间中必须是唯一的
namespace: testserver # 命名空间 需要自定义
#定义deployment资源需要的参数属性,诸如是否在容器失败时重新启动容器的属性
spec: # 期待运行状态
replicas: 2 # 部署实例数
selector: # 定义标签选择器
matchLabels: # 定义匹配标签
app: nginx-test #需与后面的.spec.template.metadata.labels定义的标签保持一致
#定义业务模板,如果有多个实例,所有实例的属性会按照模板的相关配置进行匹配
template:
metadata:
labels: #定义Pod实例将使用的标签,需与前面的.spec.selector.matchLabels定义的标签保持一致
app: nginx-test #需修改
spec:
#定义容器属性
containers:
- name: nginx-test-container #定义一个容器名,一个-name:定义一个容器
#定义容器使用的镜像以及版本 【制品仓库的名字】
image: docker-image-path #需要更改为项目制品仓库的名字
#定义容器对外的端口
ports:
- containerPort: 80
imagePullSecrets:
- name: bydserver
---
# 创建service服务对外提供访问并测试
apiVersion: v1
kind: Service
metadata:
name: service-name # 后端服务名字 自定义
namespace: testserver # 命名空间 需要自定义
spec:
selector:
app: nginx-test #需修改
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
配置完成后,在新建发布单时,可查看对应的配置项
4.2 ingress配置(可选)
在根目录新建 configs/backend-test-ingress.yaml(测试)、configs/backend-rel-ingress.yaml(正式)
yaml
# k8s ingress配置 (ALBk入口控制器)
# k8s 版本资源 : networking.k8s.io/v1 表示这是使用 Kubernetes v1 版本的网络资源 API。
apiVersion: networking.k8s.io/v1
# k8s资源对象
kind: Ingress
metadata:
# ALB相关的配置
annotations:
alb.ingress.kubernetes.io/ssl-redirect: "true" # 非https请求重定向到https
alb.ingress.kubernetes.io/healthcheck-enabled: "true" # 健康检查
alb.ingress.kubernetes.io/healthcheck-path: "/" # 路径
alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP" # 协议
alb.ingress.kubernetes.io/healthcheck-method: "HEAD" # 方法
alb.ingress.kubernetes.io/healthcheck-httpcode: "http_2xx" # http状态码
alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5" # 超时时间
alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2" # 检查间隔
alb.ingress.kubernetes.io/healthy-threshold-count: "3" # 健康阈值
alb.ingress.kubernetes.io/unhealthy-threshold-count: "3" # 不健康阈值
# ingress名称
name: ingress-name
# ingress所在的命名空间
namespace: testserver # 与Deloyment 命名空间保持一致
#定义ingres资源需要的参数属性
spec:
# ingress控制器的类名
ingressClassName: alb-name #需修改为实际的albName
rules:
# 匹配主机头为指定域名的请求
- host: test.com #项目域名
http:
paths:
# 设置一个前缀路由,所有根路径的请求都会被处理
- path: /
pathType: Prefix
backend:
service:
# 指定后端服务的名字
name: service-name
# 指定后端服务监听的端口号
port:
number: 80
tls:
- hosts:
- test.com #项目域名
持续更新...