.gitlab-ci.yml文件参数配置和使用

寒山李白

已于 2024-02-22 19:42:27 修改

阅读量2.5k

点赞数 41

分类专栏： # GitLab # Spring Boot 文章标签： gitlab ci/cd java docker kubernetes 运维容器

于 2024-02-05 17:59:11 首次发布

本文链接：https://blog.csdn.net/mo_sss/article/details/135863682

版权

GitLab 同时被 2 个专栏收录

30 篇文章 2 订阅

订阅专栏

Spring Boot

29 篇文章 6 订阅

订阅专栏

本文介绍了如何使用GitlabCI/CD进行Kubernetes(K8S)下的JAVA项目自动化部署，包括配置.gitlab-ci.yml文件、Maven打包、构建镜像、推送镜像以及部署流程。

摘要由CSDN通过智能技术生成

天行健，君子以自强不息；地势坤，君子以厚德载物。

每个人都有惰性，但不断学习是好好生活的根本，共勉！

文章均为学习整理笔记，分享记录为主，如有错误请指正，共同学习进步。

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: 173.33.0.224
  #harbor镜像仓库端口
  HARBOR_PORT: 8443
  #harbor仓库URL
  HARBOR_URL: $HARBOR_IP:$HARBOR_PORT
  #harbor镜像仓库账号
  HARBOR_USERNAME: admin
  #harbor镜像仓库密码
  HARBOR_PASSWORD: Harbor12345
  #Projectname 项目名称，用于存放镜像的项目文件夹名,k8s-demo必须提前在harbor仓库界面创建好
  PROJECT_FOLDER_NAME: k8s-demo
  #用于存放项目镜像的harbor镜像仓库项目地址
  IMAGE_HARBOR_REPOSITORY: $HARBOR_IP:$HARBOR_PORT/$PROJECT_FOLDER_NAME

  #构建的镜像名称定义
  #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: v20240208

  #本地jar包存放位置
  #PROJECT_JAR_DIR: $HOME/.m2/$CI_PROJECT_NAME-$CI_PROJECT_ID-$CI_COMMIT_REF_NAME
  #PROJECT_JAR_DIR: /k8s-dev-ops/jar/k8s-project
  #maven的依赖存放文件夹路径
  MAVEN_REPOSITORY_DIR: /maven_repo/.m2
  #本地镜像存储路径（容器内）
  #CI_IMAGE_DIR: /k8s-dev-ops/images
  #CI_IMAGE_DIR: /root/k8s-project/app.jar

  #用于存放部署java项目的yml文件
  #JAVA_DEPLOY_YML_DIR: /k8s-dev-ops/k8s-project-deploy-yml

#定义任务阶段，任务执行顺序会根据列举顺序执行，前一个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
  #任务引用的镜像，这里打包使用java的jdk镜像，注意，需要与dockerfile文件中的镜像中的jdk版本保持一致（即两个镜像可以不同但镜像中包含的jdk版本必须一致），不然打包编译和执行的java环境会不一样，导致报错
  #下面这个镜像是包含了jdk8的maven镜像
  image: adoptopenjdk/maven-openjdk8
  #部分使用maven本地仓库进行缓存，用于加快依赖的下载速度
#  cache:
#    paths:
#      - $MAVEN_REPOSITORY_DIR

  #任务执行选用的runner的标签，定义后会根据标签选用对应的runner执行任务，也可省略，会自动选取一个使用
  tags:
    - runner-01
  #指定此job只对master分支生效，不定义则对所有分支生效
  only:
    - master
  #执行脚本，maven打包，创建文件夹，将jar包复制到文件夹中
  script:
    #提示信息打印
    - echo '打包任务开始---->打jar包，将包从target文件夹中复制到当前目录'
#    - mvn clean compile
    #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
    #确保文件夹创建成功，查看一下
    - ls
    #打包之后jar包默认存放位置为target/目录下，可查看jar包
    - ls target
    - cp target/app.jar app.jar
    - ls
    #查看当前打包环境的java版本
    - java -version
    - javac -version
  #因为后续要用到这个任务打的包文件，后续配合dependencies在其他任务引用，不设置则会被后续任务开始阶段移除
  #指定该阶段构建打包后生成的jar包的路径，这样可以在构建后保存并在后续需要时下载
  artifacts:
    paths:
      - app.jar
#      - $MAVEN_REPOSITORY_DIR


#任务部分，根据定义的stage顺序来执行任务
#构建镜像
job2-build:
  #任务阶段
  stage: build
  #任务引用的镜像，构建镜像时会使用Dockerfile文件中的内容，包含镜像配置，故该job中无需镜像配置
  image: docker:stable
  services:
    - docker:24.0.7-dind
  #任务执行选用的runner的标签，定义后会根据标签选用对应的runner执行任务
  tags:
    - runner-01
  #使用的docker服务，这里不是很清楚，但可以省略该部分，暂时不用它
  #services:
    #- 191.128.0.2:8443/test01/docker-hs:202401-dind
  #局部前置脚本命令，仅作用于此任务部分
  before_script:
    - echo "开始构建镜像--->"

  #执行脚本，列举jar包文件夹，构建镜像，打标签，推送镜像，删除镜像
  script:
    #提示信息打印
    - echo '打标签---推送镜像---删除镜像'
    #首先查看当前目录位置，此时查看到的内容就是app.jar中的文件内容，当前位置为/k8s-dev-ops/jar/k8s-project，也就是Dockerfile中WORKDIR定义的值
    - ls
    #以下构建镜像部分会使用Dockerfile文件进行构建
    #.表示将镜像打标签后存放在当前位置，也可以存到别的位置，写成别的文件夹路径即可
    #- docker build -t $PROJECT_IMAGE_NAME:$PROJECT_IMAGE_TAG .
    #如果Dockerfile文件在别的目录下，如./src/Dockerfile，可以用-f指定文件位置
    #- docker build -t $PROJECT_IMAGE_NAME:$PROJECT_IMAGE_TAG -f ./src/Dockerfile .
    #列举镜像是否已生成
    #- docker images | $PROJECT_IMAGE_TAG
    #将镜像推送到仓库，最后加点. 表示推送到当前位置，不加则会被默认推送到dockerhub官网仓库中
    #- docker push $PROJECT_IMAGE_NAME:$PROJECT_IMAGE_TAG
    #列举镜像是否已生成
    #- docker images | $PROJECT_IMAGE_TAG
    #也是打标签，同上，但是可以将之前的名称改为新名称，此命令用于将镜像打标签后上传到harbor镜像仓库
    #- docker -t  $PROJECT_IMAGE_NAME:$PROJECT_IMAGE_TAG $IMAGE_HARBOR_REPOSITORY/$PROJECT_IMAGE_NAME:$PROJECT_IMAGE_TAG
    #首先登录harbor镜像仓库，否则在推送的时候会爆未授权的错误
    #- docker login harbor_url --username admin --password Harbor12345
    - docker login 173.33.0.224:8443 -u admin -p Harbor12345
    #这里可以直接构建镜像，省略前面的步骤，注意，最后的点不要忘记
    - docker build -t $IMAGE_HARBOR_REPOSITORY/$PROJECT_IMAGE_NAME:$PROJECT_IMAGE_TAG .
    #查看镜像是否生成到本地
    - docker images | grep $PROJECT_IMAGE_TAG
    #将镜像推送到到harbor仓库，注意，这里的仓库项目名必须是提前在harbor中创建好的项目名，如果没有创建则会推送失败
    - docker push $IMAGE_HARBOR_REPOSITORY/$PROJECT_IMAGE_NAME:$PROJECT_IMAGE_TAG
    #查看
    - ls
    #删除本地镜像
    - docker rmi -f $IMAGE_HARBOR_REPOSITORY/$PROJECT_IMAGE_NAME:$PROJECT_IMAGE_TAG
  #配合artifacts参数使用，使用package阶段任务的打包环境
  dependencies:
    - job1-package

#任务部分，根据定义的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 "测试"

#任务部分，根据定义的stage顺序来执行任务
#！！！！！注意，这里不能使用kubectl命令，因为gitlab-runner不是集群节点，无法使用，
#部署操作在主节点服务器中进行
.job4-deploy:
  #任务阶段
  stage: deploy
  #任务引用的镜像，这里也不需要配置镜像，部署时会使用yml文件中的镜像配置拉取
  #image: $IMAGE_HARBOR_REPOSITORY/$PROJECT_IMAGE_NAME:$PROJECT_IMAGE_TAG
  #任务执行选用的runner的标签，定义后会根据标签选用对应的runner执行任务
  tags:
    - runner-01
  #指定此job只对master分支生效
  only:
    - master
  #执行脚本，部署服务
  script:
    - echo '项目部署--->开始部署，缓存部署，pod部署，服务部署'
    #查看kubectl版本是否安装
    - kubectl version
    #查看环境变量是否配置了kubectl对应的变量
    - echo $PATH
    #创建目录用于存放yml文件
    #- mkdir -p $JAVA_DEPLOY_YML_DIR
    #查看文件夹是否创建
    - ls k8s-deploy
    #将用于部署的yml文件复制到/k8s-dev-ops/k8s-project-deploy-yml文件夹中
    #- cp k8s-deploy $JAVA_DEPLOY_YML_DIR
    #查看yml文件是否已复制过来
    #- ls $JAVA_DEPLOY_YML_DIR
    #使用kubectl命令执行部署yml文件
    #- kubectl apply -f $JAVA_DEPLOY_YML_DIR/sb-pvc.yaml
    #- kubectl apply -f $JAVA_DEPLOY_YML_DIR/sb-dplm.yaml
    #- kubectl apply -f $JAVA_DEPLOY_YML_DIR/sb-svc.yaml
    #部署
    #- kubectl apply -f k8s-deploy/sb-pvc.yaml
    #- kubectl apply -f k8s-deploy/sb-dplm.yaml
    #- kubectl apply -f k8s-deploy/sb-svc.yaml
  #配合artifacts参数使用，使用package阶段任务的打包环境
  #dependencies:
    #- package

三、使用

.gitlab-ci.yml文件的使用如下
先在gitlab配置runner，然后准备项目，当代码提交更新，runner会执行.gitlab-ci.yml文件脚本，会自动打包、构建镜像并推送到镜像仓库，然后第一次部署需要到主节点执行kubectl命令部署，后续只要更新代码，就会自动更新镜像，并自动部署
然后访问即可
具体项目如何基于Gitlab CI/CD实现自动化部署可参考文章：K8S部署Java项目（Gitlab CI/CD自动化部署）

感谢阅读，祝君暴富！