下面我们接着上一篇文章《A6.Springboot-LLama3.2服务自动化构建（三）——编写Pipeline构建仓库初始化脚本》继续往下分析，编写Pipeline构建脚本。

服务容器化构建的环境配置

1. 准备平台
   • 容器私有仓库Harbor的账号与密码，Harbor的安装与部署请参考我前面的文章《Harbor容器镜像私有仓库部署（For Liunx）》
2. 构建主机
   • 安装xmlstarlet、jq工具；

     #主要用于项目的pom.xml文件解析
     apt install xmlstarlet
     #主要用于harbor仓库检测镜像时返回json数据的解析
     apt install jq
     

   • Docker容器管理工具安装，这个可以参考我前面的文章《Liunx安装Docker容器化管理工具（记录篇）》
3. 部署主机
   • Docker容器管理工具安装，这个可以参考我前面的文章《Liunx安装Docker容器化管理工具（记录篇）》

构建前需要解决什么

• 本地LLama大模型服务地址，如何以容器部署时作为参数传入？
• 单工程服务和多工程服务如何合并成一个构建方案？
• 如何解决jenkins执行环境与shell脚本执行环境不一致问题？
• 构建成功后如何将容器上传到harbor镜像仓库中？

下面我们带着问题分析构建的过程：

1. 如何解决jenkins执行环境与shell脚本执行环境不一致问题？

在jenkins构建过程中由于平台用户环境与sh脚本执行环境不是同一个权限，为了解决这个问题网上有些解决方案说将当前用户添加到Admin Group当中，还有些通过安装SSH plugin登录到远程主机来执行来解决脚本调度过程中的权限问题。这里我们通过在Pipeline使用证书远程登录到相应的主机再执行相应逻辑：

def remote = [:]
remote.name = "${BUILD_HOST}"
remote.host = "${BUILD_HOST}"
remote.port = Integer.parseInt("${BUILD_PORT}")
remote.allowAnyHosts = true
withCredentials([sshUserPrivateKey(credentialsId: "${DEPLOY_HOST_CREDENTIALS_ID}", keyFileVariable: 'identity', usernameVariable: 'username')]) {
   
    remote.user = username
    remote.identityFile = identity
    sshCommand remote: remote, command: "/bin/bash 这里执行你的远程脚本"
}

2. 构建之前动态修改项目的环境变量

利用xmlstarlet动态修改项目pom.xml中的环境变量配置

<properties>
   <!--dev:开发环境；test:测试环境；pre:预发环境；prod:正式环境；-->
   <project.env.tag>dev</project.env.tag>
</properties>

#其中project_dir为项目根目录，jenkins脚本配置中传入
$(xmlstarlet ed --inplace -N ns=http://maven.apache.org/POM/4.0.0 -u "/ns:project/ns:properties/ns:project.env.tag" -v "$env" "$project_dir/pom.xml")

只要替换pom.xml中配置的值，在application.yml我们就可以通过@project.env.tag@方式来获取；

spring:
  profiles:
    active: @project.env.tag@

3. 在通过容器打包时避免不了会产生比较多的不可用的镜像资源，这些资源要是不及时删除掉时会导致服务器磁盘暴满，导致资源浪费。此时我们在构建之前也要执行不可用的镜像清除操作；

docker image prune -a --force

4. 本地LLama大模型服务地址，如何以容器部署时作为参数传入？

有时我们在部署某些docker容器时直接传入一些环境变量来达到相应参数的赋值。那么在我们开发的服务当中，如果打包成docker镜像也实现两样的效果应该怎么去配置呢，继续往下看阐述具体的步骤。

在Springboot服务配置文件application.yml中添加自定义配置（这里以llama主机地址为例）

llama:
  service:
    host: ${LLAMA_HOST:@llama.host@}

根据结构原理分析打包镜像后，我们只要在docker run之后添加-e LLAMA_HOST=xxx变量即可实现将参数值赋值到程序内部对应的配置中。

5. 单工程服务和多工程服务如何合并成一个构建方案？

配置jenkins服务构建时，我们希望无论是单工程形式还是多工程模块服务形式，脚本构建的过程是同一段打包逻辑。基于这一点考虑，是否只要将要打包的服务名放入一个数组中，然后循环依次构建对应的服务，这样无论是父工程方式还是单工程方式就不受影响了。

在项目中新建servers.sh来定义要构建的服务集合

#!/bin/bash
declare -a service_array
service_array=("ey-gateway" "ey-device")

在脚本中偏历service_array依次构建服务

#导入项目定义的数组，project_dir为项目根目录
source "${project_dir}/servers.sh"
for service in "${service_array[@]}"; do
    #移除每个服务对应的前缀作为构建服务名
    last_element=$(echo "$service" | cut -d'-' -f2-)
    #这里处理每个服务的构建逻辑
done

6. 服务构建重复性校验

当项目在迭代的过程开发人员每提交一个小版本以及测试工程师需要功能测试、单元测试和集成测试等，每个小间段都需要进行打包，构建次数会非常频繁。大部分情况测试人员需要构建项目时，往往是项目配置或代码逻辑没做任何改动的，难道jenkins在构建服务镜像时每次都需要重新构建会不会显得资源有点浪费（或者说是无意义构建）。那么有没有办法解决呢，即开发人员提交更改后执行打包才重新构建，如果没有做任何更改或项目版本号没有发生任务变量执行打包不重新构建延用原有的镜像。下面我们来看一下具体的实现部分：

首先需要创建校验签名文件，用于记录上一次构建的镜像签名值、版本号、镜像服务名等信息；在下次构建时作为比较的相关维度

#在上一步for循环前定义签名文件存储路径，以便之后的信息写入
#organization：组织机构名称，主要在harbor镜像仓库中用于区分不同公司或不同项目构建的服务，该参数值由jenkins平台端传入
build_sign_file=".${organization}_build_sign_config.ini"
for service in "${service_array[@]}"; do
    #这里处理每个服务的构建逻辑
done

取出当前服务的md5与上一次签名进行比较是否一致，如果不一致则进行构建动作，否则进行下一个条件判断

#通过服务的几个指标，计算出服务md5值：服务根目录下所有文件、服务iml后缀文件、如果存在HELP.md如果发生改变、如果存在mvn后缀文件且有发生改变、如果存在mvnw文件且有发生改变，根据这些指标重新计算md5值并写入到md5sums.txt文件中
find "$service" -type f -print0 | grep -vFz "$project_dir/$service/$service.iml" | grep -vFz "$project_dir/$service/HELP.md" | grep -vFz "$project_dir/$service/.mvn" | grep -vFz "$project_dir/$service/mvnw" | xargs -0 md5sum >md5sums.txt

#取出md5sums.txt文件中的md5值
current_md5=$(awk '{print $1}' md5sums.txt | sort | md5sum)

#将md5去掉连接符，作为当前要构建的服务签名值
current_environment_md5=$(tr -d ' -' <<<"$current_md5")

#当前我们得到签名值后，将md5sums.txt临时文件移除
rm -rf md5sums.txt

#如果首次执行或本地签名缓存文件不存在需要创建它
if [[ ! -f "$user_dir/${build_sign_file}" ]]; then
    touch "$user_dir/${build_sign_file}"
fi

#从签名文件中取出上一次构建对应服务的签名值,其中JENKINS_DEPLOY_HOME为环境变量值，即脚本根目录
#$user_dir/${build_sign_file}：表示将签名文件存储在用户目录下
#${service}_${env}_md5：以服务名称+环境+md5作为key存储
#其中kvs.py为python实现的操作本地文件的key=value类型的文件数据
old_environment_md5=$(python3 "${JENKINS_DEPLOY_HOME}/kvs.py" "take" "$user_dir/${build_sign_file}" "${service}_${env}_md5")

根据服务从harbor镜像仓库中查找一下看是否存在，如果不存在则进行构建动作，否则进行下一个条件判断