Skip to main content

Using larger runners

GitHub offers larger runners with more RAM and CPU.

大型运行器 功能目前对使用 GitHub Team 或 GitHub Enterprise Cloud 计划的组织和企业为 beta 版本,可能会更改。 若要请求访问 beta 版本,请访问注册页

Overview of 大型运行器s

In addition to the standard GitHub-hosted runners, GitHub also offers customers on GitHub Team and GitHub Enterprise Cloud plans a range of 大型运行器s with more RAM and CPU. These runners are hosted by GitHub and have the runner application and other tools preinstalled.

When 大型运行器s are enabled for your organization, a default runner group is automatically created for you with a set of four pre-configured 大型运行器s.

When you add a 大型运行器 to an organization, you are defining a type of machine from a selection of available hardware specifications and operating system images. GitHub will then create multiple instances of this runner that scale up and down to match the job demands of your organization, based on the autoscaling limits you define.

Machine specs for 大型运行器s

Size (vcpu)Memory (GB)Storage (SSD)
4 cores16 RAM150 GB
8 cores32 RAM300 GB
16 cores64 RAM600 GB
32 cores128 RAM1200 GB
64 cores256 RAM2040 GB

Architectural overview of 大型运行器s

The 大型运行器s are managed at the organization level, where they are arranged into groups that can contain multiple instances of the runner. They can also be created at the enterprise level and shared with organizations in the hierarchy. Once you've created a group, you can then add a runner to the group and update your workflows to target either the group name or the label assigned to the 大型运行器. You can also control which repositories are permitted to send jobs to the group for processing. For more information about groups, see "Controlling access to 大型运行器s."

In the following diagram, a class of hosted runner named ubuntu-20.04-16core has been defined with customized hardware and operating system configuration.

Diagram explaining 大型运行器

  1. Instances of this runner are automatically created and added to a group called grp-ubuntu-20.04-16core.
  2. The runners have been assigned the label ubuntu-20.04-16core.
  3. Workflow jobs use the ubuntu-20.04-16core label in their runs-on key to indicate the type of runner they need to execute the job.
  4. GitHub Actions checks the runner group to see if your repository is authorized to send jobs to the runner.
  5. The job runs on the next available instance of the ubuntu-20.04-16core runner.

Autoscaling 大型运行器s

Your 大型运行器s can be configured to automatically scale to suit your needs. When jobs are submitted for processing, more machines can be automatically provisioned to run the jobs, until reaching a pre-defined maximum limit. Each machine only handles one job at a time, so these settings effectively determine the number of jobs that can be run concurrently.

During the runner deployment process, you can configure the Max option, which allows you to control your costs by setting the maximum parallel number of machines that are created in this set. A higher value here can help avoid workflows being blocked due to parallelism.

Networking for 大型运行器s

By default, 大型运行器s receive a dynamic IP address that changes for each job run. Optionally, GitHub Enterprise Cloud customers can configure their 大型运行器s to receive a static IP address from GitHub's IP address pool. When enabled, instances of the 大型运行器 will receive an address from a range that is unique to the runner, allowing you to use this range to configure a firewall allowlist. You can use up to 10 static IP address ranges for the 大型运行器s created at the enterprise level. In addition, you can use up to 10 static IP address ranges for the 大型运行器s created at the organization level, for each organization in your enterprise.

Note: If runners are unused for more than 30 days, their IP address ranges are automatically removed and cannot be recovered.

Planning for 大型运行器s

Create a runner group

Runner groups are used to collect sets of virtual machines and create a security boundary around them. You can then decide which organizations or repositories are permitted to run jobs on those sets of machines. During the 大型运行器 deployment process, the runner can be added to an existing group, or otherwise it will join a default group. You can create a group by following the steps in "Controlling access to 大型运行器s."

Understanding billing

Note: The 大型运行器s do not use included entitlement minutes, and are not free for public repositories.

Compared to standard GitHub-hosted runners, 大型运行器s are billed differently. For more information, see "Per-minute rates".

Adding a 大型运行器 to an enterprise

You can add 大型运行器s to an enterprise, where they can be assigned to multiple organizations. The organization admins can then control which repositories can use the runners. To add a 大型运行器 to an enterprise, you must be an enterprise owner.

可以从可用选项列表中选择操作系统和硬件配置。 通过自动缩放部署此运行器的新实例时,它们会使用此处定义的相同操作系统和硬件配置。

还可以定义标识运行器的标签,即工作流如何能够将作业发送到运行器进行处理(使用 runs-on)。 新运行器会自动分配给默认组,也可以在运行器创建过程中选择运行器必须加入的组。 此外,可以在注册运行器后修改运行器组成员身份。 有关详细信息,请参阅“控制对 大型运行器 的访问”。

  1. 在 GitHub.com 的右上角,单击你的个人资料照片,然后单击“你的企业”。 GitHub Enterprise Cloud 上个人资料照片下拉菜单中的“你的企业”

  2. 在企业列表中,单击您想要查看的企业。 企业列表中的企业名称

  3. 在企业边栏中,单击 “策略”。 企业帐户边栏中的“策略”选项卡

  4. 在“ 策略”下,单击“操作”。

  5. 单击“运行器”选项卡。

  6. 单击“新建运行器”,然后单击“ 新建 GitHub 托管的运行器” 。

  7. 完成配置新运行器所需的详细信息:

    • 名称:输入新运行器的名称。 为了便于识别,这应指示其硬件和操作配置,例如 ubuntu-20.04-16core
    • 运行器映像:从可用选项中选择操作系统。 选择操作系统后,便能够选择特定版本。
    • 运行器大小:从可用选项下拉列表中选择硬件配置。
    • 自动缩放:选择可随时处于活动状态的最大运行器数。
    • 运行器组:选择运行器所属的组。 此组会托管运行器的多个实例,因为它们会纵向扩展和缩减以满足需求。
    • 网络:仅适用于 GitHub Enterprise Cloud:选择是否将静态 IP 地址范围分配给 大型运行器 的实例。 总共最多可以使用 10 个静态 IP 地址。
  8. 单击“创建运行器”。

  9. To allow organizations to access your 大型运行器s, you specify the list of organizations that can use it. For more information, see "Managing access to your runners."

Adding a 大型运行器 to an organization

You can add a 大型运行器 to an organization, where the organization admins can control which repositories can use it.

可以从可用选项列表中选择操作系统和硬件配置。 通过自动缩放部署此运行器的新实例时,它们会使用此处定义的相同操作系统和硬件配置。

还可以定义标识运行器的标签,即工作流如何能够将作业发送到运行器进行处理(使用 runs-on)。 新运行器会自动分配给默认组,也可以在运行器创建过程中选择运行器必须加入的组。 此外,可以在注册运行器后修改运行器组成员身份。 有关详细信息,请参阅“控制对 大型运行器 的访问”。

  1. On GitHub.com, navigate to the main page of the organization.

  2. 在组织名称下,单击“设置”。 组织设置按钮

  3. In the left sidebar, click Actions, then click Runners.

  4. 单击“新建运行器”,然后单击“ 新建 GitHub 托管的运行器” 。

  5. 完成配置新运行器所需的详细信息:

    • 名称:输入新运行器的名称。 为了便于识别,这应指示其硬件和操作配置,例如 ubuntu-20.04-16core
    • 运行器映像:从可用选项中选择操作系统。 选择操作系统后,便能够选择特定版本。
    • 运行器大小:从可用选项下拉列表中选择硬件配置。
    • 自动缩放:选择可随时处于活动状态的最大运行器数。
    • 运行器组:选择运行器所属的组。 此组会托管运行器的多个实例,因为它们会纵向扩展和缩减以满足需求。
    • 网络:仅适用于 GitHub Enterprise Cloud:选择是否将静态 IP 地址范围分配给 大型运行器 的实例。 总共最多可以使用 10 个静态 IP 地址。
  6. 单击“创建运行器”。

  7. To allow repositories to access your 大型运行器s, add them to the list of repositories that can use it. For more information, see "Managing access to your runners."

Running jobs on your runner

Once your runner type has been defined, you can update your workflow YAML files to send jobs to your newly created runner instances for processing. You can use runner groups or labels to define where your jobs run.

Only owner or administrator accounts can see the runner settings. Non-administrative users can contact the organization administrator to find out which runners are enabled. Your organization administrator can create new runners and runner groups, as well as configure permissions to specify which repositories can access a runner group.

Using groups to control where jobs are run

在此示例中,Ubuntu 16 核心运行器已添加到名为 ubuntu-runners 的组中。 runs-on 键将作业发送到 ubuntu-runners 组中的任何可用运行器:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: 
      group: ubuntu-runners
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Using labels to control where jobs are run

In this example, a runner group is populated with Ubuntu 16-core runners, which have also been assigned the label ubuntu-20.04-16core. The runs-on key sends the job to any available runner with a matching label:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      labels: ubuntu-20.04-16core
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Using labels and groups to control where jobs are run

组合组和标签时,运行器必须满足这两项要求才能运行作业。

在此示例中,名为 ubuntu-runners 的运行器组使用 Ubuntu 16 核心运行器(分配了标签 ubuntu-20.04-16core)进行填充。 runs-on 键将 grouplabels 组合在一起,以便将作业路由到具有匹配标签的组内的任何可用运行器:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      group: ubuntu-runners
      labels: ubuntu-20.04-16core
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Using multiple labels

You can specify multiple labels that need to be matched for a job to run on a runner. A runner will need to match all labels to be eligible to run the job.

In this example, a runner will need to match all three of the labels to run the job:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      labels: [ ubuntu-20.04-16core, gpu, qa ]
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

对运行器组使用唯一名称

GitHub Actions 要求运行器组名称在组织级别必须唯一。 这意味着组织将无法再创建与企业中的运行器组同名的运行器组。 此外,用户将在与企业中的组共享相同名称的任何运行器组上看到警告横幅,建议重命名组织组。

为了避免混淆,如果组织和企业中存在重复的运行器组,工作流将失败。 若要解决此问题,可以重命名组织或企业中的某个运行器组,也可以更新工作流文件以向运行器组名称添加前缀:

  • org/organization/
  • ent/enterprise/

示例:使用前缀区分运行器组

例如,如果组织中有一个名为 my-group 的运行器组,企业中有另一个名为 my-group 的运行器组,则可以更新工作流文件以使用 org/my-groupent/my-group 来区分这两者。

使用 org/

runs-on:
  group: org/my-group
  labels: [ self-hosted, label-1 ]

使用 ent/

runs-on:
  group: ent/my-group
  labels: [ self-hosted, label-1 ]

Managing access to your runners

Note: Before your workflows can send jobs to 大型运行器s, you must first configure permissions for the runner group. See the following sections for more information.

Runner groups are used to control which repositories can run jobs on your 大型运行器s. You must grant access to the group from each level of the management hierarchy, depending on where you've defined the 大型运行器:

  • Runners at the enterprise level: Configure the runner group to grant access to all the required organizations. In addition, for each organization, you must configure the group to specify which repositories are allowed access.
  • Runners at the organization level: Configure the runner group by specifying which repositories are allowed access.

For example, the following diagram has a runner group named grp-ubuntu-20.04-16core at the enterprise level. Before the repository named octo-repo can use the runners in the group, you must first configure the group at the enterprise level to allow access from the octo-org organization; you must then configure the group at the organization level to allow access from octo-repo:

Diagram explaining 大型运行器 groups

Allowing repositories to access a runner group

This procedure demonstrates how to configure group permissions at the enterprise and organization levels:

  1. Navigate to where your runner groups are located:

    • In an organization: navigate to the main page and click Settings.

    • If using an enterprise-level group:

      1. 在 GitHub.com 的右上角,单击你的个人资料照片,然后单击“你的企业”。 GitHub Enterprise Cloud 上个人资料照片下拉菜单中的“你的企业”

      2. 在企业列表中,单击您想要查看的企业。 企业列表中的企业名称

  2. Navigate to the "Runner groups" settings:

    • In an organization:

      1. In the left sidebar, click Actions, then click Runner groups.
    • If using an enterprise-level group:

      1. 在企业边栏中,单击 “策略”。 企业帐户边栏中的“策略”选项卡
      2. 在“ 策略”下,单击“操作”。
      3. 单击“运行器组”选项卡。
  3. 在组列表中,单击要配置的运行器组。

  • For runner groups in an enterprise: under Organization access, modify which organizations can access the runner group.
  • For runner groups in an organization: under Repository access, modify which repositories can access the runner group.

Warning:

If you are using a Fixed IP range, we recommend that you only use 大型运行器s with private repositories. Forks of your repository can potentially run dangerous code on your 大型运行器 by creating a pull request that executes the code in a workflow.

For more information, see "Controlling access to 大型运行器s."