这篇讲流水线任务该在容器里跑，还是直接在构建机上跑。看完你可以在 YAML 里写清 `runner.mode`：`DOCKER` 按任务镜像起一个容器来执行，`NATIVE` 直接在运行器所在的机器上执行，再把标签和运行器接入时的模式对上，任务才会落到要去的环境。

运行器（Runner）是装在构建机上、替平台领取并执行任务的程序。容器是按任务镜像临时拉起的隔离环境；宿主机是运行器进程所在的那台机器本身。任务在 YAML 里叫 Job，是一组按顺序执行的步骤。流水线和运行器在团队版和企业版中提供；社区版没有 **CI/CD** 菜单，本文的操作不适用。

还没有对应模式的运行器时，先登录 AngusGit，侧栏进入 **CI/CD → 运行器**，点 **新增 Runner**。**控制面地址** 改成构建机访问得到的地址，名称例如 `build-linux-01`，点 **生成令牌**（1 小时内有效，只显示一次）。要 `DOCKER` 时，页签选 **Docker 一键拉起**，标签填 `linux,docker`。要 `NATIVE` 时，页签选 **Zip 安装**，标签不要带 `docker`，机器上先装好 JDK 21。把命令复制到构建机执行，列表里变成 **空闲** 再写 YAML。换模式不能只改标签，要按这个入口用另一种页签再接一台。

## 1. 两种方式有什么不同

| 对比维度 | DOCKER | NATIVE |
| --- | --- | --- |
| 命令在哪执行 | 运行器为这个任务启动的容器里 | 构建机上，运行器进程所在的环境 |
| JDK、Node.js 等工具从哪来 | YAML 里 `image` 指定的镜像 | 构建机上提前装好的 |
| 工作目录 | 容器里的 `/workspace` | 运行器安装目录下的 `data/workspaces` |
| 每次环境是否一样 | 一样，每个任务都从同一个镜像开始 | 取决于机器当前已装的软件与全局状态 |
| 构建机要准备什么 | 装好 Docker | 装好构建要用的全部工具与 JDK 21 |
| 换工具版本 | 改 YAML 里的 `image` | 到每台构建机上升级 |

两种方式下，工作目录都会在任务结束后清理，不会留给下一个任务。

对照当前实例更容易看懂。打开 [CI/CD → 运行器](https://git.anguskit.com/cicd/compute)，里面已经有两台：`priv-1` 是 DOCKER，标签 `linux`、`docker`；`dev-1` 是 NATIVE，标签 `linux`、`native`、`dev`。两台执行器都是 SHELL，并发占用都是 0/2。

![DOCKER 的 priv-1 用镜像起容器，NATIVE 的 dev-1 直接在构建机上跑](https://developer.qcloudimg.com/http-save/yehe-1099973/101ffcf64578b535caf381577a73c466.svg)

![运行器列表：dev-1 是 NATIVE，priv-1 是 DOCKER，状态都是空闲](https://developer.qcloudimg.com/http-save/yehe-1099973/8fe2559605e2dc72d9c1a55d28c81dc4.png)

## 2. YAML 里怎么写

### DOCKER 任务

```yaml
pipeline:
  build:
    runner:
      mode: DOCKER
      image: repo.anguskit.com/docker-public/angus-ci-maven:21
      labels: ["linux", "docker"]
    steps:
      - name: Build
        run: mvn -B -ntp clean package -DskipTests
```

`mode: DOCKER` 时一定要写 `image`，否则校验会给出警告。镜像里要有这个任务用到的全部命令，例如上面的 `mvn`。

### NATIVE 任务

```yaml
pipeline:
  sign:
    runner:
      mode: NATIVE
      labels: ["linux", "codesign"]
    steps:
      - name: Sign
        run: ./scripts/sign-release.sh
```

NATIVE 任务不写 `image`。`labels` 里不要写 `docker`，再加一个能标识这类机器的标签，例如上面的 `codesign`，表示「装了签名证书的那台机器」。

`mode` 只能写大写的 `DOCKER` 或 `NATIVE`，写成小写会校验失败。

### 不写 mode 会怎样

不写 `mode` 时，AngusGit 不按模式筛选运行器，任何一台标签匹配的运行器都可能领走这个任务；任务也不会进容器，而是直接在运行器所在的环境里执行。同一份 YAML 落到不同机器上，结果就可能不一样，因此每个任务都写清 `mode`。

## 3. 运行器怎么配

任务的 `mode` 定好之后，还要有对应模式的运行器来接。运行器只能是其中一种模式，并且在第一次接入时就定下来：标签里带 `docker` 的是 DOCKER 运行器，不带的是 NATIVE 运行器。

| 想要的运行器 | 接入方式 | 标签 |
| --- | --- | --- |
| DOCKER | **Docker 一键拉起** 或 **一键安装脚本** | 默认 `linux,docker`，可以再加别的 |
| NATIVE | **Zip 安装**，机器上装好 JDK 21 | 不能带 `docker`，例如 `linux,codesign` |

Docker 方式接入的运行器本身也跑在容器里。它通过挂载进来的 `/var/run/docker.sock`，在宿主机的 Docker 上为每个任务启动新的容器。

接入完成后再到 **编辑运行器** 里加上或去掉 `docker` 标签，改的只是标签，模式不会跟着变。要换模式，就按开头用另一种页签重新接入一台。

## 4. 怎么选

没有特殊约束时，默认用 DOCKER。构建环境写在 YAML 里，谁来看都知道这次构建用的是哪个版本的 JDK。换版本只改一行，每台构建机都不用动。新加一台构建机，装好 Docker、接入运行器就能用。

**这些情况用 NATIVE：**

- 构建要用到这台机器独有的东西，例如签名证书、加密狗、GPU，或者 Windows、macOS 专用的工具链。
- 构建工具没法或者不方便做成镜像。
- 机器上不能装 Docker。

**两种可以混用。** 一个流水线里，编译和测试用 DOCKER，最后的签名用 NATIVE，每个任务各写各的 `runner`。AngusGit 会按任务分别挑运行器，前提是两种运行器都有在线的。

![编译和测试走 DOCKER 的 priv-1，签名走 NATIVE](https://developer.qcloudimg.com/http-save/yehe-1099973/9efcef99680d3ce157ab84a19489486c.svg)

## 5. 用 NATIVE 时要多留意的地方

NATIVE 任务和构建机共用同一个环境，下面几件事要提前约定：

- **工具版本统一。** 几台 NATIVE 构建机上的 JDK、Node.js 版本要一致，否则同一份代码在不同机器上的构建结果可能不同。
- **不要在构建脚本里改全局环境。** 例如 `npm install -g`、修改 `~/.m2/settings.xml`，会影响这台机器上之后的所有任务。
- **并发要保守。** 几个 NATIVE 任务同时跑在一台机器上时，会争用同一份全局缓存和同一批端口。**最大并发 Job 数** 不要设得太高。

## 常见问题

**DOCKER 任务的镜像从哪里拉？**

从运行器所在的宿主机上的 Docker 去拉。构建机访问不到镜像地址时，任务会拉取失败。内网环境下，把常用镜像推到内网的镜像仓库，YAML 里写内网地址。

**一台机器能同时提供两种模式吗？**

能，在上面装两个运行器：一个用 Docker 方式接入，一个用 Zip 方式接入且不带 `docker` 标签。名称要区分开，例如 `build-01-docker` 和 `build-01-native`。

**能根据负载自动增加运行器吗？**

目前不能。运行器是固定接入的，需要更多算力时，手动再接入一台，或者调大已有运行器的 **最大并发 Job 数**。

**任务一直等待中，提示执行模式不匹配，怎么办？**

说明没有在线的运行器和这个任务的 `mode` 一致。打开这次运行，任务旁的等待原因会写成「没有匹配执行模式 DOCKER 的 Runner」或「没有匹配执行模式 NATIVE 的 Runner」。按开头用对应页签再接一台，列表里变成 **空闲** 后再看这次运行。

## 小结

AngusGit 流水线的任务，要么在运行器启动的 Docker 容器里执行，要么直接在构建机上执行。DOCKER 方式的工具来自 `image`，每次环境都一样，是默认的选择。NATIVE 方式用构建机上装好的工具，适合需要机器上特有资源的任务。每个任务都写清 `runner.mode` 和 `labels`。DOCKER 任务交给带 `docker` 标签的运行器，NATIVE 任务交给不带 `docker` 标签、用 Zip 方式接入的运行器。运行器的模式在接入时就定了，之后改标签不会改变模式。

> **结论：** 常规构建用 `runner.mode: DOCKER` 配合镜像保证环境一致，由带 `docker` 标签的运行器执行；需要本机特有硬件或证书时用 `runner.mode: NATIVE`，由不带 `docker` 标签的 Zip 运行器执行。

## 参考文章

- [AngusGit 手册：运行器管理](https://www.anguskit.com/zh/docs/git/manual/12-runner-management)
- [AngusGit 手册：流水线进阶](https://www.anguskit.com/zh/docs/git/manual/11-pipeline-advanced)
- [流水线运行器怎么接到构建机：在那台机器上执行接入命令](https://www.anguskit.com/zh/blog/connect-pipeline-runner-to-build-machine)
- [运行器不接任务：标签、在线和并发对不上](https://www.anguskit.com/zh/blog/pipeline-runner-not-picking-up-jobs)

这篇讲流水线任务该在容器里跑，还是直接在构建机上跑。看完你可以在 YAML 里写清 runner.mode：DOCKER 按任务镜像起一个容器来执行，NATIVE 直接在运行器所在的机器上执行，再把标签和运行器接入时的模式对上，任务才会落到要去的环境。

CICD流水线任务在哪跑：Docker 容器还是宿主机

流水线的每个任务，可以在运行器启动的 Docker 容器里执行，也可以直接在构建机上执行。两种方式的工具从哪来、工作目录在哪、每次环境是否干净、对机器有什么要求都不一样。把 YAML 里的 runner.mode、标签和运行器接入方式对上，任务才会落到想要的地方。

运维

开发工具

云计算

AngusGit流水线任务执行方式对比：DOCKER模式通过镜像保证环境一致，适合常规构建；NATIVE模式直接使用构建机环境，适合需要特定硬件或证书的场景。配置runner.mode时需匹配对应标签，DOCKER需带docker标签并指定image，NATIVE不带docker标签且需预装JDK21。默认推荐DOCKER模式，特殊需求选NATIVE。

代码解释

Windows

容器

Docker

Linux

MacOS

让每一个 Agent，都跑在云上

codesign

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AngusGit流水线任务执行方式对比：DOCKER模式通过镜像保证环境一致，适合常规构建；NATIVE模式直接使用构建机环境，适合需要特定硬件或证书的场景。配置runner.mode时需匹配对应标签，DOCKER需带docker标签并指定image，NATIVE不带docker标签且需预装JDK21。默认推荐DOCK...

CICD流水线任务在哪跑：Docker 容器还是宿主机-腾讯云开发者社区-腾讯云

CICD流水线任务在哪跑：Docker 容器还是宿主机

CICD流水线任务在哪跑：Docker 容器还是宿主机

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐