流水线使用浅谈

使用总结

通过前面的分享，我已经在自己的环境中安装了gitlab-runner和jenkins，我以前用的是脚本全自动部署，所有操作都是由shell执行器完成，并没有涉及docker执行器。然后今天我就分享下，对于gitlab-runner执行器的一点认识。

jenkins和gitlab-ci

有读者有疑惑，为什么先用gitlab-ci而不是jenkins，我这里就来简单对比下，gitlab的流水线和jenkins的流水线。

  1. 安装和配置:
  • GitLab CI:作为GitLab的一部分,安装简单,配置也较简单。
  • Jenkins:独立工具,安装和配置较复杂,需要配置各种插件和环境。
  1. 使用难度:
  • GitLab CI:配置简单,YAML格式的配置文件,易上手,学习曲线平稳。
  • Jenkins:功能强大,但配置繁琐,需要编程来实现较复杂的任务,学习曲线较陡。
  1. 与源码管理的结合:
  • GitLab CI:原生集成了Git,非常易于与GitLab仓库结合,可以自动检测仓库更改并运行流水线。
  • Jenkins:可以结合各种源码管理工具,但需要手动配置触发器来检测更改。
  1. 可扩展性:
  • GitLab CI:可以安装GitLab Runner来扩展,支持与Kubernetes集成,较易于水平扩展。
  • Jenkins:本身支持分布式部署,有大量插件可以连接不同环境,扩展性高但复杂。
  1. 预置环境和资产:
  • GitLab CI:没有预置的环境或资产,每次运行流水线时会创建独立环境。
  • Jenkins:有丰富的预置环境、凭证、缓存等资产,可以重复使用,但也增加了管理难度。

那么到底如何选择： GitLab CI简单易用,但功能略少,扩展和管理也相对简单。适用于中小型项目。 Jenkins功能强大,但较复杂,需要投入更多时间去管理与扩展。适用于大型项目。 两者可以很好地结合使用,例如使用GitLab CI进行 daily build,使用Jenkins进行发布管理。

总之个人开发者或者小团队来讲可以选择gitlab的流水线足够使用，而规模大一点就根据实际选择gitlab或者jenkins流水线，结合使用。

gitlab-runner执行器

就是一种程序，它可以在GitLab CI/CD中执行构建、测试和部署等任务。它可以在不同的操作系统上运行，如Linux、Windows和macOS等。

执行器列表已经锁定，不再发展或接受新执行器，以下为执行器种类：

SSH
Shell
Parallels
VirtualBox
Docker
Docker Autoscaler (alpha)
Docker Machine (auto-scaling)
Kubernetes
Instance (alpha)
Custom

目前一般使用ssh、hell和docker以及k8s，简单来说就是执行远程命令、脚本、以及镜像操作和部署到k8s的作用。 对于这些具体的介绍可以直接上官网查看：

https://docs.gitlab.cn/runner/executors/#i-am-not-sure

怎么选择

注册的时候，要选择那些执行器呢，就得根据你的流水线里面任务用到了那些，如果只是shell脚本那就选shell，如果用到了docker操作那就选docker。

注册的时候默认只能选择一种执行器类型，但是在.gitlab-ci.yml文件中,我们可以为不同的job指定不同的执行器。所以,我们可以在同一个CI/CD流水线中,使用shell执行器构建应用,使用docker执行器部署应用。

build:
  stage: build
  script:
    - npm install
    - npm run build 
deploy:
  stage: deploy
  image: nginx:stable-alpine
  script:
    - mv /dist /usr/share/nginx/html 
  only:
    - test
  • build job使用shell执行器,通过npm构建Vue应用。
  • deploy job使用docker执行器,部署dist目录到Nginx容器中。 所以,注册GitLab Runner时,执行器类型的选择并不影响我们在.gitlab-ci.yml文件中为不同job指定不同的执行器。我们可以通过为job指定:
  • script使用shell执行器
  • image使用docker执行器

疑问

  1. 那么同一个项目中需要注册两个gitlab-runner吗？

可以注册两个，也可以一个项目用一个runner。但注册多个GitLab Runner有个好处，就是这样可以避免资源竞争和冲突，保证项目的稳定性和可靠性。

注册额外的Runner类型通常出于以下目的:

  1. 隔离执行环境。例如注册shell Runner用于构建,docker Runner用于部署,以隔离构建环境和生产环境。

  2. 并行处理更多job。如果一个Runner的job队列太长,可以注册更多Runner来提高CI流水线的处理能力。

  3. 不同机器资源。例如在服务器上注册docker Runner,在个人电脑上注册shell Runner。

  4. 那为什么注册的时候还要选择执行器类型？注册GitLab Runner时让我们选择执行器类型,似乎与一个Runner可以处理不同执行器类型的job相矛盾。 这主要出于两个原因:

    1. 默认执行器。虽然一个Runner可以处理不同执行器类型的job,但是在注册时选择的执行器类型会成为该Runner的默认执行器。也就是,如果一个job未指定image或script,该Runner会使用默认执行器来运行。

    2. 优化环境。选择不同的执行器类型,可以为该Runner优化不同类型job的运行环境。例如:

      • 选择shell,该Runner会默认安装GIT、OpenSSH、Build Essentials等,方便处理script类型的job。
      • 选择docker,该Runner会默认支持Docker命令,方便pull和run各种镜像,以处理image类型的job。
CI/CD