Skip to main content

Using larger runners

GitHub offers larger runners with more RAM and CPU.

La característica ejecutor más grande está actualmente en versión beta para organizaciones y empresas que usan los planes GitHub Team o GitHub Enterprise Cloud y está sujeto a cambios. Para solicitar acceso a la versión beta, visita la página de registro.

Overview of ejecutor más grandes

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

When ejecutor más grandes are enabled for your organization, a default runner group is automatically created for you with a set of four pre-configured ejecutor más grandes.

When you add a ejecutor más grande 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 ejecutor más grandes

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 ejecutor más grandes

The ejecutor más grandes 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 ejecutor más grande. 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 ejecutor más grandes."

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 ejecutor más grande

  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 ejecutor más grandes

Your ejecutor más grandes 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 ejecutor más grandes

By default, ejecutor más grandes receive a dynamic IP address that changes for each job run. Optionally, GitHub Enterprise Cloud customers can configure their ejecutor más grandes to receive a static IP address from GitHub's IP address pool. When enabled, instances of the ejecutor más grande 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 in total across all your ejecutor más grandes.

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

Planning for ejecutor más grandes

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 ejecutor más grande 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 ejecutor más grandes."

Understanding billing

Note: The ejecutor más grandes do not use included entitlement minutes, and are not free for public repositories.

Compared to standard GitHub-hosted runners, ejecutor más grandes are billed differently. For more information, see "Per-minute rates".

Adding a ejecutor más grande to an enterprise

You can add ejecutor más grandes 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 ejecutor más grande to an enterprise, you must be an enterprise owner.

Puedes elegir un sistema operativo y una configuración de hardware en la lista de opciones disponibles. Cuando se implementan nuevas instancias de este ejecutor mediante el escalado automático, usarán el mismo sistema operativo y la misma configuración de hardware que has definido aquí.

También puedes definir las etiquetas que identifican al ejecutor, que es la forma en que los flujos de trabajo podrán enviar trabajos a los ejecutores para su procesamiento (mediante runs-on). Los nuevos ejecutores se asignan automáticamente al grupo predeterminado o puedes elegir qué grupo deben unirse los ejecutores durante el proceso de creación del ejecutor. Además, puedes modificar los miembros del grupo del ejecutor después de que lo hayas registrado. Para obtener más información, consulta "Controlar el acceso a ejecutor más grande".

  1. En la barra lateral de la empresa, haz clic en Directivas. Pestaña Directivas en la barra lateral de la cuenta de empresa

  2. En " Directivas", haz clic en Acciones.

  3. Haz clic en la pestaña Ejecutores.

  4. Haz clic en Nuevo ejecutor y, después, en Nuevo ejecutor hospedado en GitHub .

  5. Completa los detalles necesarios para configurar el nuevo ejecutor:

    • Nombre: escribe un nombre para el nuevo ejecutor. Para facilitar la identificación, esto debe indicar su configuración de hardware y funcionamiento, como ubuntu-20.04-16core.
    • Imagen del ejecutor: elije un sistema operativo de las opciones disponibles. Una vez que hayas seleccionado un sistema operativo, podrás elegir una versión específica.
    • Tamaño del ejecutor: elije una configuración de hardware en la lista desplegable de opciones disponibles.
    • Escalado automático: elije el número máximo de ejecutores que pueden estar activos en cualquier momento.
    • Grupo de ejecutores: elije el grupo del que serás miembro el ejecutor. Este grupo hospedará varias instancias del ejecutor, ya que se escalan y reducen verticalmente para satisfacer la demanda.
    • Redes: solo para GitHub Enterprise Cloud: elije si se asignará un intervalo de direcciones IP estáticas a instancias de ejecutor más grande. Puedes usar hasta 10 direcciones IP estáticas en total.
  6. Haz clic en Crear ejecutor.

  7. To allow organizations to access your ejecutor más grandes, you specify the list of organizations that can use it. For more information, see "Managing access to your runners."

Adding a ejecutor más grande to an organization

You can add a ejecutor más grande to an organization, where the organization admins can control which repositories can use it.

Puedes elegir un sistema operativo y una configuración de hardware en la lista de opciones disponibles. Cuando se implementan nuevas instancias de este ejecutor mediante el escalado automático, usarán el mismo sistema operativo y la misma configuración de hardware que has definido aquí.

También puedes definir las etiquetas que identifican al ejecutor, que es la forma en que los flujos de trabajo podrán enviar trabajos a los ejecutores para su procesamiento (mediante runs-on). Los nuevos ejecutores se asignan automáticamente al grupo predeterminado o puedes elegir qué grupo deben unirse los ejecutores durante el proceso de creación del ejecutor. Además, puedes modificar los miembros del grupo del ejecutor después de que lo hayas registrado. Para obtener más información, consulta "Controlar el acceso a ejecutor más grande".

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

  2. Debajo del nombre de la organización, haga clic en Settings. Botón de configuración de la organización

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

  4. Haz clic en Nuevo ejecutor y, después, en Nuevo ejecutor hospedado en GitHub .

  5. Completa los detalles necesarios para configurar el nuevo ejecutor:

    • Nombre: escribe un nombre para el nuevo ejecutor. Para facilitar la identificación, esto debe indicar su configuración de hardware y funcionamiento, como ubuntu-20.04-16core.
    • Imagen del ejecutor: elije un sistema operativo de las opciones disponibles. Una vez que hayas seleccionado un sistema operativo, podrás elegir una versión específica.
    • Tamaño del ejecutor: elije una configuración de hardware en la lista desplegable de opciones disponibles.
    • Escalado automático: elije el número máximo de ejecutores que pueden estar activos en cualquier momento.
    • Grupo de ejecutores: elije el grupo del que serás miembro el ejecutor. Este grupo hospedará varias instancias del ejecutor, ya que se escalan y reducen verticalmente para satisfacer la demanda.
    • Redes: solo para GitHub Enterprise Cloud: elije si se asignará un intervalo de direcciones IP estáticas a instancias de ejecutor más grande. Puedes usar hasta 10 direcciones IP estáticas en total.
  6. Haz clic en Crear ejecutor.

  7. To allow repositories to access your ejecutor más grandes, 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

En este ejemplo, se han agregado ejecutores de 16 núcleos de Ubuntu a un grupo denominado ubuntu-runners. La clave runs-on envía el trabajo a cualquier ejecutor disponible del grupo 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

Al combinar grupos y etiquetas, el ejecutor debe cumplir ambos requisitos para poder ejecutar el trabajo.

En este ejemplo, un grupo de ejecutores denominado ubuntu-runners se rellena con ejecutores de 16 núcleos de Ubuntu, a los que también se ha asignado la etiqueta ubuntu-20.04-16core. La clave runs-on combina group y labels para que el trabajo se enrute a cualquier ejecutor disponible dentro del grupo que también tenga una etiqueta coincidente:

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

Managing access to your runners

Note: Before your workflows can send jobs to ejecutor más grandes, 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 ejecutor más grandes. You must grant access to the group from each level of the management hierarchy, depending on where you've defined the ejecutor más grande:

  • 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 ejecutor más grande groups

Allowing repositories to access a runner group

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

  1. Navega a la página principal del repositorio u organización en donde se ubican tus grupos de ejecutores.
  2. Haga clic en Configuración.
  3. In the left sidebar, click Actions, then click Runner groups.
  4. En la lista de grupos, haz clic en el grupo de ejecutores que te gustaría configurar.
  • 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 ejecutor más grandes with private repositories. Forks of your repository can potentially run dangerous code on your ejecutor más grande by creating a pull request that executes the code in a workflow.

For more information, see "Controlling access to ejecutor más grandes."