Fehlerbehebung bei der Konfiguration privater Netzwerke für GitHub-gehostete Runner in Ihrem Unternehmen
Aktivieren der Erstellung von Netzwerkkonfigurationen für Organisationen in einem Unternehmen
Standardmäßig können Organisationen in einem Unternehmen keine neuen Netzwerkkonfigurationen erstellen und nur Netzwerkkonfigurationen auf Unternehmensebene erben. Unternehmensbesitzer*innen können eine Richtlinie festlegen, mit der Organisationen im Unternehmen Netzwerkkonfigurationen erstellen können, die unabhängig vom Unternehmen sind. Weitere Informationen findest du unter Konfigurieren von privaten Netzwerken mit von GitHub gehosteten Runnern in Ihrem Unternehmen.
Konfigurieren von Azure-Tessourcen vor einer Netzwerkkonfiguration in GitHub
Stellen Sie sicher, dass Ihre Azure-Ressourcen konfiguriert wurden, bevor Sie eine Netzwerkkonfiguration in GitHub hinzufügen.
Unterstützte Regionen
Der Dienst GitHub Actions unterstützt eine Teilmenge aller Regionen, die Azure bereitstellt. Dein Subnetz muss sich in einer der unterstützten Regionen befinden, damit Kommunikation zwischen GitHub Actions und deinem Subnetz möglich ist.
Note
Wenn du Datenresidenz auf GHE.com verwendest, werden andere Regionen unterstützt. Weitere Informationen finden Sie unter Netzwerkdetails für GHE.com.
Auf GitHub.com werden die folgenden Regionen unterstützt.
EastUsEastUs2WestUs2WestUs3CentralUsNorthCentralUsAustraliaEastJapanEastFranceCentralGermanyWestCentralNorthEuropeNorwayEastSwedenCentralSwitzerlandNorthUkSouthSoutheastAsiaKoreaCentral
Private Azure-Netzwerke unterstützen GPU-Runner in den folgenden Regionen.
EastUsWestUsNorthCentralUs
Private Azure-Netzwerke unterstützen arm64-Runner in den folgenden Regionen.
EastUsEastUs2WestUs2WestUs3NorthCentralUs
Wenn Ihre gewünschte Region nicht unterstützt wird, senden Sie bitte eine Anforderung an die Verfügbarkeit neuer Regionen in diesem GitHub-Formular. Sie können auch globales Peering virtueller Netzwerke verwenden, um virtuelle Netzwerke über Azure-Regionen hinweg zu verbinden. Weitere Informationen finden Sie unter Peering virtueller Netzwerke in der Azure-Dokumentation.
Runner konnte keine Verbindung mit dem Internet herstellen
GitHub-gehostete Runner müssen ausgehende Verbindungen mit GitHub sowie anderen erforderlichen URLs für GitHub Actions herstellen können.
Wenn GitHub Actions nicht mit den Runnern kommunizieren können, kann der Pool niemals Runner online bringen, sodass keine Aufträge angenommen werden. In diesem Fall verfügt der Pool über den folgenden Fehlercode.
VNetInjectionFailedToConnectToInternet
Um dies zu beheben, stelle sicher, dass du deine Azure-Ressourcen gemäß den Verfahren „Konfigurieren deiner Azure-Ressourcen“ konfiguriert hast.
Bereitstellungsbereich ist gesperrt
Sie können Sperren für das Azure-Abonnement oder die Ressourcengruppe hinzufügen, wodurch die Erstellung oder Löschung von NIC verhindert werden kann.
Sperren, die die Erstellung von NIC verhindern, nehmen keine Aufträge an, während Sperren, die die Löschung von NIC verhindern, entweder den Subnetz-Adressraum ausschöpfen (indem sie weiterhin NIC erstellen) oder lange Wartezeiten bis zur Zuweisung haben, da der Dienst die Bereitstellungsausnahmen erneut versucht.
In diesem Fall verfügt der Pool über den folgenden Fehlercode.
RunnerDeploymentScopeLocked
Um dies zu beheben, entfernen Sie die Sperre, oder wechseln Sie zu einem Subnetz ohne Sperre.
Bereitstellung blockiert durch Richtlinie
Sie können Richtlinien für deren Verwaltungsgruppe, Abonnement, Ressourcengruppe oder einzelne Ressourcen erstellen. Die am häufigsten verwendete Richtlinie erfordert, dass eine Ressource bestimmte Tags aufweist oder einen bestimmten Namen hat.
Die Richtlinie verhindert die Erstellung von NIC, d h., der Pool nimmt keine Aufträge an, da keine virtuellen Computer online gehen können.
In diesem Fall verfügt der Pool über den folgenden Fehlercode.
RunnerDeploymentBlockedByPolicy
Um dies zu beheben, entfernen Sie die Richtlinie, oder wechseln Sie zu einem Subnetz ohne Richtlinie.
Subnetz ist voll
Subnetze verfügen über eine begrenzte Anzahl an zu vergebenden IP-Adressen. Jeder Runner verbraucht eine IP-Adresse. Wenn der Dienst versucht, über die eingestellte maximale Anzahl der Runner hinweg hochzuskalieren, tritt ein Bereitstellungsfehler auf.
Das beeinträchtigt die Fähigkeit des Pools, zusätzliche Runner hinzuzufügen. Wenn die Warteschlangentiefe groß genug ist, kann es zu längeren Zuweisungszeiten (Queue-to-Assign, QTA) kommen. Aufträge werden zwar weiterhin verarbeitet, aber nicht mit der von Ihnen erwarteten Gleichzeitigkeit.
In diesem Fall verfügt der Pool über den folgenden Fehlercode.
VNetInjectionSubnetIsFull
Um das zu beheben, steigern Sie entweder die Größe des verwendeten Subnetzes, oder verringern Sie die maximale Anzahl der Runner des Pools, damit diese Ihrer Subnetzgröße entspricht.
Falsche NSG- oder Firewallregeln
Die Vorgehensweisen „Konfigurieren Ihrer Azure-Ressourcen“ nennen die erforderlichen Öffnungen. Möglicherweise gibt es jedoch komplexe Produktionsnetzwerke mit mehreren nachgeschalteten Proxys oder Firewalls.
Wenn Runner nicht online kommen, werden keine Aufträge angenommen. Ihr Setupprozess kann das Einrichten der Runner-Anwendung und die Kommunikation mit dem GitHub Actions-Dienst umfassen, um anzugeben, dass sie bereit ist, sowie das Abrufen und Installieren von Tools zur Missbrauchsbekämpfung. Wenn einer dieser Prozesse fehlschlägt, kann der Runner keine Aufträge annehmen.
Wenn diese Probleme auftreten, versuchen Sie, einen virtuellen Computer im selben Subnetz einzurichten, das Sie für private Netzwerke mit GitHub-gehosteten Runnern verwenden. Wenn Sie jedoch über einen Dienstzuordnungslink (SAL) verfügen, ist das nicht möglich.
Wenn Sie über einen Dienstzuordnungslink verfügen, versuchen Sie, ein ähnliches Subnetz im virtuellen Netzwerk einzurichten und einen virtuellen Computer in diesem Netzwerk zu platzieren. Versuchen Sie anschließend, darin einen selbst gehosteten Runner zu registrieren.
HTTP-Anforderungs-Payloadfehler beim Konfigurieren von Azure-Ressourcen
Stellen Sie beim Ausführen des Befehls zum Konfigurieren von Azure-Ressourcen sicher, dass Sie die richtige API-Version und die businessId-Eigenschaft verwenden. Wenn Sie eine andere Eigenschaft verwenden, gibt Ihr Befehl möglicherweise den folgenden Fehler zurück.
(HttpRequestPayloadAPISpecValidationFailed) HTTP request payload failed validation against API specification with one or more errors. Please see details for more information.
Wenn dieser Fehler auftritt, können Sie sich weitere Informationen anzeigen lassen, indem Sie den Befehl mit dem ---debug-Flag ausführen.