GitLab Runner Huixinfu365迁移与部署流程

GitLab Runner Huixinfu365迁移与部署流程

此文档旨在详细说明在 GitLab Runner 上执行的完整迁移与部署流程，涵盖从 Runner 重新注册到部署过程中的各个细节，确保无缝迁移并解决常见的编译与部署问题。

因npm私有仓库缺失无法安装依赖!!!
仓库分支尽量减少冲突以及删除分支的操作,防止runner异常新建空间,ruo重建空间请重新操作此文档!!!

---

1. 取消原有注册

• 在迁移前，首先取消当前 GitLab Runner 的注册。

gitlab-runner unregister --all-runners

---

2. 重新注册 GitLab Runner

• 在重新注册 GitLab Runner 时，为其分配以下标签：
  • huixinfu365-test-deploy
  • huixinfu365-pd-deploy
• 确保标签名称与以下一致：
  • huixinfu365-pd
  • huixinfu365-test

每次注册时执行以下命令：

gitlab-runner register

注册命令行输入示例：

1. 路径： 输入 GitLab 实例的 URL：

   Please enter the GitLab instance URL: https://gitlab.example.com/
   

2. Token： 输入注册令牌：

   Please enter the GitLab CI registration token: <your-registration-token>
   

3. 主机名： 输入描述：

   Please enter a description for the runner: huixinfu365-test-deploy
   

4. 标签： 输入标签名称：

   Please enter the runner's tags (comma separated): huixinfu365-test-deploy
   

5. 执行器： 选择执行器（此处选择 shell）：

   Please enter the executor: shell
   

---

3. 提交代码并进行全量编译

• 提交代码后，若遇到 Cannot find module '@XXX' 错误，请继续执行后续步骤。

---

4. Runner 会重新生成编译空间

• 编译空间会在 /home/gitlab-runner/builds 目录下自动创建。每次编译会生成一个新的目录，例如：
  • /home/gitlab-runner/builds/<new-build-id>

---

5. 执行依赖包同步脚本

在重新生成的编译空间中，需要将旧版本的依赖包同步到新的编译空间。以下是优化后的 sync.sh 脚本，用于从源目录将依赖包同步到目标目录。

优化后的 sync.sh 脚本：

#!/bin/bash

# 定义源路径、目标路径和查找目录（node_modules_dir 的父目录）
from="/data/buidls-home-bak/bb7c6a67/0/fuli/huixinfu365/packages"
to="/home/gitlab-runner/builds/bbe5c6bb/0/fuli/huixinfu365/packages"
search_dir="node_modules"  # 查找的目录名称

# 查找所有的 node_modules_dir 目录
find "$from" -type d -name "$search_dir" | while read node_modules_dir; do
    # 打印查找到的目录
    echo "Found directory: $node_modules_dir"

    # 计算相对路径：去掉 $from 部分，保留从 packages 目录开始的路径
    relative_path="${node_modules_dir#$from/}"
    echo "Relative path: $relative_path"

    # 计算目标路径
    target_dir="$to/$relative_path"
    echo "Target path: $target_dir"

    # 获取目标路径的父目录并创建它（如果不存在）
    mkdir -p "$(dirname "$target_dir")"
    echo "Created target directory: $(dirname "$target_dir")"

    # 使用 rsync 同步并覆盖 node_modules 目录
    echo "Running rsync..."
    rsync -av --delete "$node_modules_dir/" "$target_dir/"

    # 输出 rsync 执行结果
    if [ $? -eq 0 ]; then
        echo "rsync completed successfully"
    else
        echo "rsync failed"
    fi
done

说明：

1. 查找 node_modules 目录：脚本使用 find 命令递归查找源路径中的所有 node_modules 目录。
2. 相对路径计算：将查找到的 node_modules 目录与源路径进行比较，去除 $from 部分，保留相对路径。
3. 目录同步：通过 rsync 命令将依赖包从源路径同步到目标路径，确保新的编译空间包含所有必需的依赖包。
4. 创建目标目录：使用 mkdir -p 命令确保目标路径中不存在的目录被自动创建。
5. 权限设置（可选）：如果需要，使用 chmod 设置目标目录的权限：

   chmod -R 777 "$target_dir"
   

6. 错误处理：通过 if [ $? -eq 0 ] 判断 rsync 是否执行成功，并根据结果输出相应信息。

---

6. 重新提交代码并进行编译

• 完成依赖包同步后，重新提交代码并启动编译。如果遇到 Cannot find module '@XXX' 错误，可能是依赖包没有正确同步，需重新执行 sync.sh 脚本。

---

7. 编译过程中常见问题与排查

1. Warning: failed to remove packages/_libr
   • 解决方法：为目标目录设置更高的权限：

     chmod 777 /home/gitlab-runner/builds/<new-build-id>/0/fuli/huixinfu365/packages/_libr
     

2. Cannot find module '@XXX' 错误
   • 解决方法：再次执行步骤 5 以确保依赖包完全同步。

---

8. 部署过程

• 编译完成后，若部署过程中出现 Cannot find module '@XXX' 错误，请手动将依赖包复制到部署目录：

  cp -r /data/原空间/bb7c6a67/0/fuli/huixinfu365/packages/具体目录 /node_modules /home/gitlab-runner/builds/新空间/0/fuli/huixinfu365/packages/具体目录
  

---

9. 重新编译并解决 CDN 传输问题

1. 修改 CDN 上传脚本：如果在部署过程中出现 CDN 传输失败的错误，修改 /home/gitlab-runner/fe_cdn_upload.sh 中的服务器 IP 配置。
2. 配置免密登录：
   • 打印当前用户并配置当前用户的免密登录权限，以便顺利部署。

---

10. 编译与部署失败排查

1. 修改 Docker 更新脚本：若编译过程中触发部署失败，检查并修改 /usr/local/sbin/fe_docker_update 中的 IP 配置。
2. 检查 Docker 镜像：在 GitLab Runner 上，使用以下命令查看是否生成 Docker 镜像：

   docker images
   

3. 检查部署服务器 Docker 状态：使用以下命令检查部署服务器上的 Docker 容器是否启动：

   docker ps
   

---

11. 前端 CDN 相关注意事项

• CDN 推送：当前端首次使用 .npm 仓库时，需要手动创建并推送依赖包至 CDN 服务器：

  npm publish
  

---

总结

1. 编译空间管理：每次 GitLab Runner 执行时，会在 /home/gitlab-runner/builds 中生成新的编译空间。
2. 依赖包同步：通过 sync.sh 脚本将旧版本的依赖包同步到新生成的编译空间，确保编译环境一致性。
3. 问题排查与解决：文档提供了常见问题（如缺少依赖、权限问题）及其解决方案，确保编译和部署过程无阻。
4. 部署优化：在部署时解决 CDN 上传和 Docker 容器相关的问题，确保最终部署成功。

此文档为 GitLab Runner 的迁移和部署流程提供了详细步骤，便于团队成员执行并解决常见问题。