gitlab-ci相关部署踩坑及要点记录

最近在搞cicd相关的事情,在这个过程中遇到了一些疑惑,顺便记录下来,如果对正在有相同迷惑的同学有帮助的话,也是一件很好的事情。

准备工作:

  1. 安装gitlab,这个安装网上太多了,可以使用二进制的方式安装,也可以使用docker直接运行。
  2. 安装gitlab-runner,这个主要就是一个token和url的使用,一定要正确,还有与gitlab的版本对应也要注意一下,当然这个也是可以使用二进制的方式和直接使用docker运行的方式。
  3. docker安装,应为我是用的docker运行的gitlab-runner,而且在构建的过程中,也是用的golang的docker镜像进行打包的。

问题及注意点:

问题一:遇到了一个问题,构建速度非常慢,因为当时的项目不大,需要下载的依赖也不多,所以这是为啥?

解答:因为在gitlab-ci.yml文件中用到了artifacts,而这让job产物(可执行程序)上传到gitlab,而我们在gitlab-runner register的时候,url填的是一个公网地址,并且runner机器的外网带宽只有1M,所以很慢,后面将url换成了内网地址,直接起飞,url的更换是直接修改config.toml文件中的url配置,然后运行gitlab-runner restart即可。

问题二:部署的过程中,碰到permission denied这样的报错?

解答:使用root用户运行gitlab-runner即可,不过这个要注意gitlab.yml中的script,不要误操作,修改gitlab-runner运行用户的命令:gitlab-runner uninstall && gitlab-runner install --user root,如果不行的话,再gitlab-runner restart即可,如果用到宝塔面板的话,宝塔也用root用户运行项目。

问题三:因为部署的是golang的项目,所以不能每次部署的时候都去下载依赖,这样不科学,所以有什么办法可以解决这个问题呢:

解答:使用gitlab-ci都cache,具体配置如下:

复制代码
cache:
  key: ${CI_JOB_NAME}
  paths:
    - .mod_cache/

其中key是防止cache被覆盖,paths是要缓存的目录,缓存会以cache.zip的名字自动存储到宿主机上,下次这个job运行的时候,会先解压cache.zip,然后再去编译,这样对于有依赖的项目,速度会有一定的提升。

记录:

  1. when: manual 的作用,是该job运行的时候,必须要手动去点运行才会运行,可以用在部署到线上环境时的最后一道防线。
  2. when: on_success 是默认加上的,如果rules中的if条件满足的话,会自动加上。
  3. when: never 的意思是不会将这个job加入到流水线中,即该job不会执行。
  4. 可以通过gitlab-runner的tag去指定在哪台机器上执行流水线的job,在实际操作中,可以将打包、构建机器打上一个tag,然后测试环境、线上环境也打上对应的tag,这样在job执行的时候,如果需要区分部署到不同的环境,就可以通过tag,来让job在对应的环境机器上运行。
  5. 第4个点说的,通过tag区分环境,也可以直接在script中直接使用ssh的方式去进行部署到对应的环境。
  6. 打包阶段的image,可以直接指定版本,不需要用latest,因为用latest的话,每次都会去判断一下本地latest镜像与hub中的是否一样,这样也会提升一点速度。

最后贴一下,我使用的gitlab-ci.yml文件,仅供参考:

复制代码
stages:          # List of stages for jobs, and their order of execution
  - build
  - deploy

build-ad-job:       # This job runs in the build stage, which runs first.
  stage: build
  image: golang:1.21.6
  tags:
    - ytweb
  script:
    - echo "Compiling the code..."
    - go env -w GOMODCACHE=$(pwd)/.mod_cache/ GOPROXY=https://goproxy.cn,direct
    - make all
    - echo "Compile complete."
  cache:
    key: ${CI_JOB_NAME}
    paths:
      - .mod_cache/
  rules:
    - if: '$CI_COMMIT_BRANCH == "dev" || $CI_COMMIT_BRANCH == "main"'
  artifacts:
    paths:
      - bin/
      - configs/
      - ad.json
    expire_in: 1 day

deploy-ad-dev-job:
  stage: deploy
  tags:
    - testing
  rules:
    - if: '$CI_COMMIT_BRANCH == "dev"'
#      when: manual
  script:
    - echo "Deploying dev application..."
    - bash deploy.sh
    - echo "Application dev successfully deployed."

deploy-ad-prod-job:
  stage: deploy
  tags:
    - online
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
  script:
    - echo "Deploying prod application..."
    - bash deploy.sh
    - echo "Application prod successfully deployed."
相关推荐
鼎道开发者联盟9 小时前
鼎享会 | 从手工到自动化:OpenClaw改造GitLab内部协作流程的全过程
自动化·gitlab·openclaw
marsh020610 小时前
39 openclaw持续集成实践:自动化构建与部署流程
运维·ci/cd·ai·自动化·编程·技术
byoass10 小时前
企业云盘API集成指南:如何与CI/CD流水线打通
网络·安全·ci/cd·云计算
qq_4523962311 小时前
第十四篇:《持续集成中的UI自动化:Jenkins/GitHub Actions集成》
ui·ci/cd·自动化
开开心心就好12 小时前
支持批量添加水印的实用工具推荐
人工智能·游戏·ci/cd·docker·音视频·语音识别·媒体
魏波.12 小时前
Harness工程与传统CI/CD流水线的区别?
ci/cd·harness
测试那点事儿12 小时前
零基础接口自动化到 Jenkins 持续集成(导读)
ci/cd·自动化·jenkins
ℳ₯㎕ddzོꦿ࿐1 天前
告别手工发版:用 GitLab CI/CD 打通前后端自动化部署的“任督二脉”
ci/cd·自动化·gitlab
mascon1 天前
CI/CD 标准化(自动流水线)
ci/cd
ℳ₯㎕ddzོꦿ࿐1 天前
实战:在 Linux 系统用 Docker-Compose 优雅部署 GitLab 及防坑指南
linux·docker·gitlab