Maschinengrößen für größere Runner
Sie können für größere Runner aus mehreren Spezifikationen auswählen.
Allgemeine Spezifikationen größere Runner
| CPU | Arbeitsspeicher (RAM) | Speicher (SSD) | Aufbau | Betriebssystem |
|---|---|---|---|---|
| 5 | 14 GB | 14 GB | arm64 (M2) | macOS |
| 12 | 30 GB | 14 GB | x64 (Intel) | macOS |
| 2 | 8 GB | 75 GB | X64, arm64 | Ubuntu |
| 4 | 16 GB | 150 GB | X64, arm64 | Ubuntu, Windows |
| 8 | 32 GB | 300 GB | X64, arm64 | Ubuntu, Windows |
| 16 | 64 GB | 600 GB | X64, arm64 | Ubuntu, Windows |
| 32 | 128 GB | 1.200GB | X64, arm64 | Ubuntu, Windows |
| 64 | 208 GB | 2040 GB | arm64 | Ubuntu, Windows |
| 64 | 256 GB | 2040 GB | x64 | Ubuntu, Windows |
| 96 | 384 GB | 2040 GB | x64 | Ubuntu, Windows |
Hinweis
Der 4-vCPU-Windows-Runner funktioniert nur mit dem Windows Server 2025- oder mit dem Windows 11-Basis-Desktopimage.
Spezifikationen für GPU größere Runner
| CPU | GPU (Grafikprozessor) | GPU-Karte | Arbeitsspeicher (RAM) | GPU-Speicher (VRAM) | Speicher (SSD) | Betriebssystem |
|---|---|---|---|---|---|---|
| 4 | 1 | Tesla T4 | 28 GB | 16 GB | 176 GB | Ubuntu, Windows |
Runner-Bilder
Größerer Runnerwird auf virtuellen Computern (VMs) ausgeführt und GitHub während des VM-Erstellungsprozesses eine virtuelle Festplatte (VHD) auf diesem Computer installiert. Sie können aus verschiedenen VM-Images wählen, die Sie auf Ihren Runnern installieren möchten.
** GitHub-owned images:** Diese Images werden von GitHub verwaltet und stehen für Linux-Runner (x64 und arm64), Windows-Runner (x64 und arm64) und macOS-Runner (x64 und arm64) zur Verfügung. Weitere Informationen zu diesen Images sowie eine vollständige Liste der enthaltenen Tools für jedes Runner-Betriebssystem finden Sie im Repository GitHub ActionsRunner Images.
Partner Images: Partnerimages werden nicht von GitHub verwaltet und aus dem Azure Marketplace abgerufen. Im Folgenden findest du Informationen darüber, wo du weitere Informationen findest und wo du Probleme mit Partnerimages melden kannst.
- Windows 11 Basisabbild des Desktops
- NVIDIA GPU-optimierte VMI
- Data Science Virtual Machine – Windows 2019
Verfügbares macOS größere Runner und Beschriftungen
Die folgenden Computer sind für macOS größere Runnerverfügbar. Wenn Sie einen macOS-größerer Runner erstellen, ist der Runner-Name auch als Workflow-Label verfügbar, das Sie mit runs-on verwenden können.
| Läufergröße | Aufbau | Prozessor (CPU) | Arbeitsspeicher (RAM) | Speicher (SSD) | Workflow-Label |
|---|---|---|---|---|---|
| Groß | Intel | 12 | 30 GB | 14 GB | |
macos-latest-large, , macos-14-largemacos-15-large (neueste),macos-26-large | |||||
| X-Large | arm64 (M2) | 5 (+ 8 GPU-Hardwarebeschleunigung) | 14 GB | 14 GB | |
macos-latest-xlarge, , macos-14-xlargemacos-15-xlarge (neueste),macos-26-xlarge |
Einschränkungen für macOS größere Runner
- Alle Aktionen, die von GitHub bereitgestellt werden, sind mit arm64 GitHub-gehosteten Runnern kompatibel. Communityaktionen sind jedoch möglicherweise nicht mit arm64 kompatibel und müssen zur Laufzeit manuell installiert werden.
- Die geschachtelte Virtualisierung wird aufgrund der Einschränkung des Apples Virtualisierungs-Frameworks nicht unterstützt.
- Netzwerkfunktionen wie private Azure-Netzwerke und das Zuweisen statischer IPs sind derzeit für macOS größere Runner nicht verfügbar.
- Die arm64 macOS-Runner haben keine statische UUID/UDID zugewiesen, da Apple dieses Feature nicht unterstützt. Den Intel MacOS-Runnern wird jedoch eine statische UDID zugewiesen, insbesondere
4203018E-580F-C1B5-9525-B745CECA79EB. Wenn Sie den Build auf demselben Host erstellen und signieren, auf dem Sie ihn testen möchten, können Sie mit einem Entwicklungsbereitstellungsprofil signieren. Wenn Sie eine statische UDID benötigen, können Sie Intel-Runner verwenden und ihre UDID ihrem Apple-Entwicklerkonto hinzufügen.
Problembehandlung für größere Runner
Wenn Sie feststellen, dass die Aufträge, die auf Ihre größerer RunnerZielwerte abzielen, verzögert oder nicht ausgeführt werden, gibt es mehrere Faktoren, die dies verursachen können.
- Parallelitätseinstellungen: Möglicherweise hast du dein Parallelitätslimit erreicht. Wenn du weitere Aufträge parallel ausführen möchtest, kannst du deine Einstellungen für die automatische Skalierung auf eine größere Anzahl festlegen. Siehe Verwalten größerer Runner.
- Repositoryberechtigungen: Stellen Sie sicher, dass die entsprechenden Repositoryberechtigungen für Ihre größerer Runners aktiviert sind. Standardmäßig sind Unternehmensrunner nicht auf Repositoryebene verfügbar und müssen manuell von einemeiner Organisationsadministratorin aktiviert werden. Siehe Verwalten größerer Runner.
- Abrechnungsinformationen: Sie müssen eine gültige Kreditkarte hinterlegt haben, um größerer Runners zu verwenden. Nach dem Hinzufügen einer Kreditkarte zu Ihrem Konto kann es bis zu 10 Minuten dauern, bis die Nutzung Ihrer größerer RunnerKonten aktiviert wird. Siehe Verwalten deiner Zahlungs- und Abrechnungsinformationen.
- Ausgabenlimit: Ihr GitHub Actions Ausgabenlimit muss auf einen Wert festgelegt werden, der größer als 0 ist. Siehe Einrichten von Budgets zum Kontrollieren der Ausgaben für Produkte mit verbrauchseinheitenbasierter Abrechnung.
- **Fair-Use-Richtlinie:**GitHub verfügt über eine Fair-Use-Richtlinie, bei der Einzelvorgänge anhand mehrerer Faktoren gedrosselt werden, z. B. danach, wie viele Einzelvorgänge Sie ausführen oder wie viele Einzelvorgänge in der gesamten GitHub Actions ausgeführt werden.
- Auftragswarteschlange zum Zuweisen von Zeit: Auftragswarteschlange zum Zuweisen von Zeit bezieht sich auf die Zeit zwischen einer Auftragsanforderung und GitHub dem Zuweisen eines virtuellen Computers zum Ausführen des Auftrags. Standardmäßige GitHub-gehostete Runner, die die vorgegebenen YAML-Workflow-Labels verwenden (z. B.
ubuntu-latest), sind immer in einem „warmen“ Zustand. Bei größeren Runnern ist eine warme VM möglicherweise nicht bereit, einen Auftrag bei der ersten Anforderung aufzunehmen, da die Pools für diese Computer kleiner sind. Daher muss GitHub möglicherweise eine neue VM erstellen, wodurch sich die Wartezeit für die Zuweisung verlängert. Sobald ein Runner verwendet wird, sind VMs innerhalb von 5 Minuten für nachfolgende Workflowausführungen bereit. Wenn sie nicht innerhalb dieser Zeit erneut verwendet werden, bleibt eine Teilmenge dieser Computer warm, wodurch die Warteschlange zum Zuweisen der Zeit für zukünftige Workflowausführungen in den nächsten 24 Stunden reduziert wird. Je mehr Jobs Sie ausführen, desto mehr VMs verbleiben im warmen Pool.
Vernetzung für größere Runner
Standardmäßig erhalten größere Runner eine dynamische IP-Adresse, die sich bei jeder Auftragsausführung ändert. Optional können GitHub Enterprise Cloud Kunden ihr größere Runner so konfigurieren, dass es statische IP-Adressen aus dem IP-Adresspool von GitHub bezieht. Weitere Informationen finden Sie unter Informationen zu den IP-Adressen von GitHub.
Wenn diese Option aktiviert ist, empfangen Instanzen der größerer Runner IP-Adressen von bestimmten Bereichen, die für den Läufer eindeutig sind, sodass Sie die Bereiche verwenden können, um eine Firewall-Zulassungsliste zu konfigurieren. Jeder größerer Runner Pool ist ein Pool, der automatisch auf die konfigurierte maximale Parallelität skaliert wird, und alle Aufträge in diesem Pool verwenden denselben statischen IP-Adressbereich. Dies bedeutet, dass Sie keine zusätzlichen Runner erstellen müssen, um mehr gleichzeitige Jobs auszuführen. Sie können bis zu größerer Runner Pools mit statischen IP-Adressbereichen insgesamt über all Ihre größere Runner hinweg verwenden verwenden. Weitere Informationen finden Sie unter Verwalten größerer Runner.
Wenn Sie mehr als 10 größere Läuferpools mit statischen IP-Adressbereichen verwenden möchten, wenden Sie sich bitte an uns über das GitHub-Support-Portal.
Hinweis
Wenn Runner länger als 90 Tage nicht verwendet werden, werden ihre IP-Adressbereiche automatisch entfernt und können nicht wiederhergestellt werden.
