天行健，君子以自强不息；地势坤，君子以厚德载物。
每个人都有惰性，但不断学习是好好生活的根本，共勉！
文章均为学习整理笔记，分享记录为主，如有错误请指正，共同学习进步。
文章目录
- 一、介绍
- 二、配置
- 三、使用
K8S自动化部署JAVA项目（Gitlab CI/CD）请参考文章：K8S部署Java项目（Gitlab CI/CD自动化部署）
一、介绍
既然你用到了.gitlab-ci.yml文件，应该对Gitlab CI/CD有一定的了解，简单说一下
- Gitlab CI/CD是代码仓库的一个功能，用于项目的持续集成（Continuous Integration）、持续交付（Continuous Delivery）、持续部署（Continuous Deployment），是现在主流的devops工具
- 项目注册gitlab-runner工具后，只要更新代码，gitlab-runner工具就会执行.gitlab-ci.yml文件中的任务，实现CI/CD
- .gitlab-ci.yml文件必须位于项目根目录下
二、配置
关于.gitlab-ci.yml文件中的参数详解，请参考另一篇：.gitlab-ci.yml文件参数
也可参考官网文档（英文）：https://docs.gitlab.com/ee/ci/yaml/
如何配置？
以下为java项目（springboot）为例，配置该文件
.gitlab-ci.yml
#全局变量，自定义变量名和值，全局引用，方便修改
#系统变量与自定义变量的使用，以$开始的表示系统变量的引用，加${}的表示自定义变量的引用
variables:
#harbor镜像仓库IP
HARBOR_IP: 172.30.0.224
#harbor镜像仓库端口
HARBOR_PORT: 8443
#harbor仓库URL
HARBOR_URL: ${HARBOR_IP}:${HARBOR_PORT}
#harbor镜像仓库账号
HARBOR_USERNAME: admin
#harbor镜像仓库密码
HARBOR_PASSWORD: Harbor12345
#用于存放项目镜像的harbor镜像仓库项目地址
IMAGE_HARBOR_REPOSITORY: ${HARBOR_IP}:${HARBOR_PORT}/k8s-demo
#构建的镜像名称定义
#PROJECT_IMAGE_NAME: $CI_PROJECT_NAME-$CI_PROJECT_ID
PROJECT_IMAGE_NAME: k8s-springboot
#构建的镜像标签定义
#PROJECT_IMAGE_TAG: $DEPLOY_TIME_TAG-$CI_PIPELINE_ID-$CI_COMMIT_REF_NAME
PROJECT_IMAGE_TAG: v20240204
#本地jar包存放位置
#PROJECT_JAR_DIR: $HOME/.m2/$CI_PROJECT_NAME-$CI_PROJECT_ID-$CI_COMMIT_REF_NAME
PROJECT_JAR_DIR: /root/jar/k8s-project
#maven的依赖存放文件夹路径
MAVEN_REPOSITORY_DIR: /root/maven/.m2
#本地镜像存储路径（容器内）
CI_IMAGE_DIR: /root/images
#CI_IMAGE_DIR: /root/k8s-project/app.jar
#定义任务阶段，任务执行顺序会根据列举顺序执行，前一个stage不执行完或者报错，后面的stage不会开始，不同job相同stage的任务会并行执行
#package打包，build构建，deploy部署
stages:
- package
- build
- test
- deploy
#前置脚本，适用于全局，所有任务开始之前执行该脚本命令
before_script:
- echo: "project ci/cd task start"
#创建目录用于存储maven依赖，仅用于测试before脚本，暂时还没用到该文件夹
- mkdir -p ${MAVEN_REPOSITORY_DIR}
#任务部分，根据定义的stage顺序来执行任务
#如想跳过该任务，可在任务名称前加上英文句号"."，如.job1-package，执行时会跳过该任务
#打包项目
job1-package:
#任务阶段
stage: package
#任务引用的镜像
image: docker:latest
#任务执行选用的runner的标签，定义后会根据标签选用对应的runner执行任务
tags:
- runner-01
#指定此job只对master分支生效
only:
- master
#执行脚本，maven打包，创建文件夹，将jar包复制到文件夹中
script:
#提示信息打印
- echo: '打包任务开始---->清理之前的jar包，打包，将包复制到容器中'
#1项目打包，以下5个打包方式任选其一即可，可在package前加上clean来先清理
#- mvn package
#- mvn clean package
#2使用prod配置文件打包，-PprofileName表示激活指定的构建配置文件，-P后加配置文件名称
#- mvn package -Pprod
#3跳过测试打包，-Dmaven.test.skip=true表示跳过单元测试
- mvn clean package -Dmaven.test.skip=true
#4清空并打包，跳过单元测试
#- mvn clean package -Dmaven.test.skip=true
#5更新依赖并打包，强制更新snapshots和releases
#- mvn package -U
#删除jar包，此步已在部署环节执行，个人也觉得在构建镜像后删除比较合适，当然也可以在这里打包前检查并删除
#- rm -rf ${PROJECT_JAR_DIR}/app.jar
#创建文件夹存储打包文件
- mkdir -p ${PROJECT_JAR_DIR}
#将打包文件复制到指定文件夹中，这里需要注意，打包后的jar包文件名称需要在项目的pom.xml中配置指定，不然默认生成的jar会是项目名-版本号.jar的格式
- cp target/app.jar ${PROJECT_JAR_DIR}/app.jar
#因为后续要用到这个任务打的包，后续配合dependencies在其他任务引用
#artifacts:
#paths:
#- ${PROJECT_JAR_DIR}/*.jar
#任务部分，根据定义的stage顺序来执行任务
#构建镜像
job2-build:
#任务阶段
stage: build
#任务引用的镜像
image: docker:latest
#任务执行选用的runner的标签，定义后会根据标签选用对应的runner执行任务
tags:
- runner-01
#使用的docker服务，这里不是很清楚，但可以省略该部分，暂时不用它
#services:
#- 191.128.0.2:8443/test01/docker-hs:202401-dind
#局部前置脚本命令，仅作用于此任务部分，创建用于存储项目镜像的本地路径，前面我们定义了全局变量，这里创建目录
before_script:
- mkdir -p ${CI_IMAGE_DIR}
#执行脚本，列举jar包文件夹，构建镜像，打标签，推送镜像，删除镜像
script:
#提示信息打印
- echo '打包任务开始---->清理之前的jar包，打包，将包复制到容器中'
#列举当前jar包，查看是否已复制过来
- ls -l ${PROJECT_JAR_DIR}
#以下构建镜像部分会使用Dockerfile文件进行构建
#.表示将镜像打标签后存放在当前位置，也可以存到别的位置，写成别的文件夹路径即可
- docker build -t ${PROJECT_IMAGE_NAME}:${PROJECT_IMAGE_TAG} .
#如果Dockerfile文件在别的目录下，如./src/Dockerfile，可以用-f指定文件位置
#- docker build -t ${CI_IMAGE_DIR}:${PROJECT_IMAGE_TAG} -f ./src/Dockerfile .
#将镜像推送到仓库
- docker push ${PROJECT_IMAGE_NAME}:${PROJECT_IMAGE_TAG}
#列举镜像是否已生成
- docker images | ${PROJECT_IMAGE_NAME}
#也是打标签，同上，但是可以将之前的名称改为新名称，此命令用于将镜像打标签后上传到harbor镜像仓库
- docker -t ${PROJECT_IMAGE_NAME}:${PROJECT_IMAGE_TAG} ${IMAGE_HARBOR_REPOSITORY}/${PROJECT_IMAGE_NAME}:${PROJECT_IMAGE_TAG}
#将镜像推送到到harbor仓库
- docker push ${IMAGE_HARBOR_REPOSITORY}/${PROJECT_IMAGE_NAME}:${PROJECT_IMAGE_TAG}
#删除jar包
- rm -rf ${PROJECT_JAR_DIR}/app.jar
#删除打标签后用于推送到harbor仓库的的镜像
- docker rmi -f ${IMAGE_HARBOR_REPOSITORY}/${PROJECT_IMAGE_NAME}:${PROJECT_IMAGE_TAG}
#再删除原始构建的镜像
- docker rmi -f ${CI_IMAGE_DIR}:${PROJECT_IMAGE_TAG}
#任务部分，根据定义的stage顺序来执行任务
#测试
#在任务前加英文点.来忽略任务，流程会跳过该任务的执行
.job3-test:
#任务阶段
stage: test
#任务引用的镜像
image: 191.128.0.2:8443/k8s-demo:$CI_COMMIT_REF_NAME
#任务执行选用的runner的标签，定义后会根据标签选用对应的runner执行任务
tags:
- runner-01
#指定此job只对master分支生效
only:
- master
#执行脚本，部署服务
script:
- echo ${IMAGE_HARBOR_REPOSITORY}:$CI_COMMIT_REF_NAME
- kubectl apply -f /etc/k8s-demo.yaml
#任务部分，根据定义的stage顺序来执行任务
#
job4-deploy:
#任务阶段
stage: deploy
#任务引用的镜像，此处为项目部署所需要的项目镜像(前面build阶段构建的镜像)，从harbor上拉取，速度很快
image: ${IMAGE_HARBOR_REPOSITORY}/${PROJECT_IMAGE_NAME}:${PROJECT_IMAGE_TAG}
#任务执行选用的runner的标签，定义后会根据标签选用对应的runner执行任务
tags:
- runner-01
#指定此job只对master分支生效
only:
- master
#执行脚本，部署服务
script:
- echo '项目部署--->开始部署，缓存部署，pod部署，服务部署'
#部署java项目的yaml文件都放在/sb-p/sb-test文件夹下，需提前准备好
- kubectl apply -f /sb-p/sb-test/sb-pvc.yaml
- kubectl apply -f /sb-p/sb-test/sb-dplm.yaml
- kubectl apply -f /sb-p/sb-test/sb-svc.yaml
#配合artifacts参数使用，使用package阶段任务的打包环境
#dependencies:
#- package
三、使用
.gitlab-ci.yml文件的使用如下
先在gitlab配置runner，然后准备项目，当代码提交更新，runner会执行.gitlab-ci.yml文件脚本，会自动构建、部署项目
然后访问即可
具体项目如何基于Gitlab CI/CD实现自动化部署可参考文章：K8S部署Java项目（Gitlab CI/CD自动化部署）
感谢阅读，祝君暴富！
