企业项目管理、ORK、研发管理与敏捷开发工具平台

网站首页 > 精选文章 正文

Gitlab runner（gitlab runner多台服务器部署）

wudianyun 2025-01-29 18:24:14 精选文章 24 ℃

简介

GitLab Runner是一个开源的应用程序，它可以在GitLab CI/CD系统中运行作业。GitLab Runner可以在不同的操作系统和平台上运行，支持多种编程语言和构建工具。它可以在单个主机上运行多个实例，也可以在多个主机上分布式运行，以提高作业的执行效率。

执行器

GitLab Runner支持多种Executor，可以根据不同的需求选择合适的Executor来执行作业。以下是一些常用的Executor：

1. Shell Executor：Shell Executor是GitLab Runner的默认Executor，它使用本地Shell来执行作业。Shell Executor适用于简单的构建和测试任务，但对于复杂的任务和需要使用Docker等容器技术的任务，Shell Executor的功能较为有限。

2. Docker Executor：Docker Executor使用Docker容器来执行作业，它可以在Docker容器中创建作业执行环境，并且可以使用Docker镜像来实现快速环境部署。Docker Executor适用于需要使用Docker容器技术的任务，例如构建和部署Docker镜像等。

3. Kubernetes Executor：Kubernetes Executor使用Kubernetes集群来执行作业，它可以在Kubernetes集群中创建作业执行环境，并且可以使用Kubernetes Pod来实现快速环境部署。Kubernetes Executor适用于需要使用Kubernetes集群技术的任务，例如构建和部署Kubernetes应用程序等。

4. SSH Executor：SSH Executor使用SSH协议来远程执行作业，它可以在远程服务器上创建作业执行环境，并且可以使用远程服务器上的资源来实现作业的执行。SSH Executor适用于需要在远程服务器上执行任务的情况，例如远程部署和测试等。

除了以上常用的Executor，GitLab Runner还支持其他一些Executor，如Parallels Executor、VirtualBox Executor等。通过选择合适的Executor，我们可以更好地利用GitLab Runner来实现自动化构建、测试和部署功能。

服务相关命令

  1. 注册Runner：sudo gitlab-runner register
  2. 启动Runner：sudo gitlab-runner start
  3. 停止Runner：sudo gitlab-runner stop
  4. 重启Runner：sudo gitlab-runner restart
  5. 查看Runner状态：sudo gitlab-runner status
  6. 查看所有Runner：sudo gitlab-runner list
  7. 删除Runner：sudo gitlab-runner unregister --name "runner_name"

类型

GitLab Runner支持以下几种类型：

1. Shared Runner：Shared Runner是由GitLab社区提供的公共Runner，可供所有GitLab项目使用。Shared Runner通常由GitLab社区维护，用户无需自己搭建和维护Runner环境，但可能会受到其他用户的影响和限制。

2. Specific Runner：Specific Runner是用户自己搭建和维护的Runner，只能由指定的项目使用。Specific Runner通常由用户自己在自己的服务器或云平台上搭建和维护，可以根据自己的需求和资源来配置Runner环境。

3. Group Runner：Group Runner是由GitLab项目组内的多个项目共享的Runner，可以在多个项目之间共享资源和配置，提高资源利用率和管理效率。

4. Parent/Child Runner：Parent/Child Runner是一种层次结构的Runner，可以通过继承和覆盖的方式来实现Runner的管理和配置。Parent Runner可以定义通用配置和资源，Child Runner可以继承和覆盖Parent Runner的配置和资源，实现更细粒度的Runner配置和管理。

通过选择合适的Runner类型，我们可以更好地利用GitLab Runner来实现自动化构建、测试和部署功能。在选择Runner类型时，需要根据项目的需求、环境要求、资源限制等因素进行综合考虑，选择最合适的Runner类型来执行作业。

流水线任务

GitLab中的流水线（Pipeline）是一种自动化工具，它可以将代码从源代码管理工具中的存储库自动构建、测试和部署到目标环境中。流水线任务（Pipeline Job）是流水线中的一个步骤，它可以完成一个特定的任务，例如构建、测试、打包、部署等。

在GitLab中，您可以通过编写.gitlab-ci.yml文件来定义流水线任务。.gitlab-ci.yml文件是一个YAML格式的文件，其中包含了一系列的流水线任务定义。每个流水线任务包含了一些特定的功能和配置，例如脚本、环境变量、依赖关系等。当GitLab检测到代码提交时，它会自动运行.gitlab-ci.yml文件中定义的流水线任务，以自动化执行构建、测试和部署流程。

以下是一个示例.gitlab-ci.yml文件，其中包含了三个流水线任务：Build、Test和Deploy：

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - echo "Building the application..."
    - mvn clean install

test:
  stage: test
  script:
    - echo "Running tests..."
    - mvn test

deploy:
  stage: deploy
  script:
    - echo "Deploying the application..."
    - ssh user@server "cd /var/www/myapp && git pull && npm install && pm2 restart myapp"

在这个示例中，我们定义了三个流水线任务：Build、Test和Deploy。这些任务被分组到不同的阶段（stage）中，以便定义它们的执行顺序。在build阶段中，我们使用Maven构建应用程序；在test阶段中，我们运行测试；在deploy阶段中，我们使用SSH连接到远程服务器，并更新代码、安装依赖项并重启应用程序。

通过定义.gitlab-ci.yml文件并定义流水线任务，我们可以实现自动化的构建、测试和部署流程，提高软件交付的效率和质量。

常用关键字

以下是.gitlab-ci.yml文件中常用的关键字的总结：

  1. 流程控制类关键字：
  • stages：定义流水线任务执行的阶段。
  • jobs：定义流水线任务的具体执行步骤。
  • only和except：定义流水线任务执行的触发条件，例如只有在特定分支提交代码时才会触发任务执行。
  • when：定义任务执行的条件，例如只有在前面的任务执行成功时才会执行当前任务。
  • allow_failure：定义任务执行失败时是否继续执行后续任务。
  • dependencies：定义任务执行所依赖的其他任务。
  • trigger：定义任务执行时需要触发的另一个流水线。
  • manual：定义任务是否需要手动触发执行。
  1. 环境和依赖类关键字：
  • image：定义流水线任务使用的Docker镜像。
  • services：定义任务执行需要启动的服务，例如数据库服务、消息队列服务等。
  • variables：定义流水线任务中使用的环境变量，可以在任务执行时访问这些变量。
  • before_script和after_script：定义任务执行前和执行后需要运行的脚本。
  • script：定义任务的执行脚本，可以是任何可以在流水线运行的命令或脚本。
  • artifacts：定义任务执行后生成的输出文件或结果，可以将这些输出文件上传到GitLab服务器或存储在特定位置。
  • cache：定义任务执行时需要缓存的文件或目录，以加速任务执行速度。
  1. 其他关键字：
  • include：引入其他.gitlab-ci.yml文件中的配置信息。
  • tags：定义流水线任务所使用的GitLab Runner标签。
  • timeout：定义任务执行的超时时间。
  • retry：定义任务执行失败时的重试次数。
  • interruptible：定义任务执行是否可以被中断。
  • hooks：定义流水线任务执行时的钩子操作，例如在任务执行成功或失败时发送通知。

这些关键字可以根据需要组合使用，实现各种复杂的流水线任务和应用场景，提高软件交付的效率和质量。

gitlab-ci.yml 简单示例

以下是一个简单的示例，其中使用了一些常用的关键字：

stages:
  - build
  - test
  - deploy

variables:
  DATABASE_URL: "postgres://user:password@localhost/mydb"
  IMAGE_TAG: "$CI_COMMIT_REF_NAME-$CI_COMMIT_SHA"

before_script:
  - npm install

build:
  stage: build
  script:
    - npm run build
    - docker build -t my_app:$IMAGE_TAG .
  artifacts:
    paths:
      - dist/
      - Dockerfile

test:
  stage: test
  script:
    - run_unit_tests
    - run_integration_tests_with_database
  only:
    - master
  allow_failure: true

deploy:
  stage: deploy
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push my_app:$IMAGE_TAG
    - deploy_to_production
  when: manual
  dependencies:
    - test
  tags:
    - production

cache:
  paths:
    - node_modules/

在这个示例中，定义了三个阶段（build、test和deploy）。在variables中定义了两个环境变量，DATABASE_URL和IMAGE_TAG，分别用于测试阶段需要使用的数据库连接和构建Docker镜像时使用的标签。在before_script中定义了任务执行前需要运行的命令，这里是安装npm包。

在build任务中，使用了script关键字定义了任务的执行脚本，先运行npm的build命令，然后使用Docker构建镜像，并将构建产生的文件和Dockerfile保存为artifacts。

在test任务中，使用了多个关键字。only定义了任务只有在master分支上提交代码时才会执行；allow_failure定义了任务执行失败时不会终止整个流水线的执行。

在deploy任务中，使用了多个关键字。when定义了任务需要手动触发执行；dependencies定义了任务的执行依赖；tags定义了任务需要在带有production标签的Runner上执行。

最后，在cache中定义了需要缓存的文件和目录，这里是node_modules目录。

这个示例只是一个简单的例子，实际使用中还需要根据具体需求进行调整和扩展。

gitlab-ci.yml 关键字使用

以下是GitLab CI/CD中所有可用的关键字及其描述和示例：

image: 指定任务运行时所使用的Docker镜像。示例：

image: node:14

services: 指定任务运行时所使用的服务。示例：

services:
  - postgres:latest

stages: 指定流水线中的阶段。示例：

stages:
  - build
  - test
  - deploy

variables: 定义流水线中使用的环境变量。示例：

variables:
  DATABASE_URL: postgres://user:password@localhost/mydb

before_script: 定义任务执行前需要运行的命令。示例：

before_script:
  - npm install

after_script: 定义任务执行后需要运行的命令。示例：

after_script:
  - cleanup

cache: 定义需要缓存的文件和目录。示例：

cache:
  paths:
    - node_modules/

artifacts: 定义任务执行后需要保存的文件和目录。示例：

artifacts:
  paths:
    - dist/
    - Dockerfile

script: 定义任务的执行脚本。示例：

script:
  - npm run build
  - docker build -t my_app:$IMAGE_TAG .

only: 定义任务只有在满足特定条件时才会执行。示例：

only:
  - master

except: 定义任务不会执行的条件。示例：

except:
  - tags

when: 定义任务的执行条件。示例：

when: manual

allow_failure: 定义任务执行失败时是否会终止整个流水线的执行。示例：

allow_failure: true

dependencies: 定义任务的执行依赖。示例：

dependencies:
  - build

timeout: 定义任务执行的超时时间。示例：

timeout: 5m

retry: 定义任务执行失败时的重试次数。示例：

retry: 3

parallel: 定义任务并发执行的数量。示例：

parallel: 3

trigger: 定义触发另一个流水线的条件和参数。示例：

trigger:
  include:
    - local: path/to/another/ci.yml
  strategy: depend

rules: 定义任务的执行规则。示例：

rules:
  - if: '$CI_COMMIT_BRANCH =~ /^feature\//'
    when: manual
  - if: '$CI_COMMIT_BRANCH == "master"'
    when: never

extends: 定义扩展配置。示例：

extends:
  - .common-config

include: 引入其他的YAML文件。示例：

include:
  - remote: 'https://example.com/path/to/another.yml'
  - local: '/path/to/local.yml'

rules:variables: 定义任务的执行规则，根据变量的值来判断是否执行任务。示例：

rules:
  - if: '$CI_COMMIT_BRANCH == "master"'
    variables:
      GIT_STRATEGY: fetch

rules:changes: 定义任务的执行规则，根据代码改动来判断是否执行任务。示例：

rules:
  - changes:
      - '*.js'
    script:
      - eslint

rules:exists: 定义任务的执行规则，根据指定的文件或目录是否存在来判断是否执行任务。示例：

rules:
  - exists:
      - package-lock.json
    script:
      - npm ci

rules:if: 定义任务的执行规则，使用CI/CD系统提供的变量和用户自定义变量来判断是否执行任务。示例：

rules:
  - if: '$CI_COMMIT_BRANCH =~ /^feature\//'
    script:
      - npm test

rules:when: 定义任务的执行规则，根据前置任务的执行状态来判断是否执行任务。示例：

rules:
  - when: on_success
    changes:
      - 'src/**'
    script:
      - npm run build

trigger:include: 定义触发另一个流水线的条件和参数。示例：

trigger:
  include:
    - artifact: my-artifact
      job: deploy

trigger:strategy: 定义触发另一个流水线的策略。示例：

trigger:
  include:
    - local: path/to/another/ci.yml
  strategy: depend

trigger:variables: 定义触发另一个流水线的参数。示例：

trigger:
  include:
    - local: path/to/another/ci.yml
  variables:
    ENVIRONMENT: production

rules:manual: 定义任务的执行规则，使任务成为手动触发。示例：

rules:
  - if: '$CI_COMMIT_BRANCH == "master"'
    when: manual
    script:
      - deploy

这些关键字可以根据实际需求进行组合使用，以实现更加复杂的CI/CD流程。

Tags：

猜你喜欢

最近发表
标签列表