Fehlerbehebung bei der Konfiguration privater Netzwerke für Runner, die von GitHub in Ihrem Unternehmen gehostet werden
Möglichkeit zur Erstellung von Netzwerkkonfigurationen für Organisationen im Unternehmensumfeld
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 finden Sie unter Konfigurieren eines privaten Netzwerks für GitHub-Runner in Ihrem Unternehmen.
Konfigurieren von Azure-Ressourcen vor dem Erstellen einer Netzwerkkonfiguration in GitHub
Stellen Sie sicher, dass Ihre Azure-Ressourcen konfiguriert wurden , bevor Sie eine Netzwerkkonfiguration hinzufügen.GitHub
Unterstützte Regionen
Der GitHub Actions Dienst unterstützt eine Teilmenge aller Regionen, die Azure bereitstellt. Um die Kommunikation zwischen dem GitHub Actions Dienst und Ihrem Subnetz zu erleichtern, muss sich Ihr Subnetz in einer der unterstützten Regionen befinden.
Hinweis
Wenn Sie Datenresidenz auf GHE.com verwenden, sind die unterstützten Regionen unterschiedlich. Weitere Informationen findest du unter Netzwerkdetails für GHE.com.
Die folgenden Regionen werden auf GitHub.com unterstützt.
AustraliaEastBrazilSouthCanadaCentralCanadaEastCentralUsEastAsiaEastUsEastUs2FranceCentralGermanyWestCentralJapanWestKoreaCentralNorthCentralUsNorthEuropeNorwayEastSouthCentralUsSoutheastAsiaSouthIndiaSwedenCentralSwitzerlandNorthUkSouthUkWestWestUsWestUs2WestUs3
Private Azure-Netzwerke unterstützen GPU-Runner in den folgenden Regionen.
EastUsNorthCentralUsSouthCentralUsWestUs
Private Azure-Netzwerke unterstützen arm64-Runner in den folgenden Regionen.
CentralUsEastUsEastUs2NorthCentralUsSouthCentralUsWestUsWestUs2WestUs3
Wir werden in Kürze einen Prozess starten, um Unterstützung für neue Regionen anzufordern. 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 in der Lage sein, ausgehende Verbindungen zu GitHub herzustellen, um andere erforderliche URLs für GitHub Actions zu erreichen.
Wenn GitHub Actions nicht mit den Runners kommunizieren kann, wird der Pool niemals in der Lage sein, Runners online zu bringen, und folglich werden keine Aufträge angenommen. 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 beeinflusst die Fähigkeit des Pools, zusätzliche Läufer 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.
Subnetz kann nicht gelöscht werden
In einigen Fällen kann ein Subnetz nicht gelöscht werden, da ein Service Association Link (SAL) auf das Subnetz angewendet wurde. Weitere Informationen finden Sie unter Konfiguration privater Netzwerke für GitHub-gehostete Runner in Ihrer Organisation.
Wenn du die Netzwerkeinstellungsressource identifizieren musst, die dem Subnetz zugeordnet ist, kannst du den folgenden curl-Befehl ausführen.
Informationen zum Abrufen eines Azure Entra-Tokens findest du in der Azure-Dokumentation. Verwende dasselbe api-version-Element, das du zum Erstellen der Ressource verwendet hast.
curl --request GET \
--url "https://management.azure.com/subscriptions/{subscriptionId}/providers/GitHub.Network/NetworkSettings?api-version={api-version}&subnetId={subnetId}" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer {entra_token}"
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 es den Runnern nicht gelingt, online zu kommen, werden keine Jobs angenommen. Ihr Setup-Prozess kann das Einrichten der Runner-Anwendung und die Kommunikation mit dem GitHub Actions Dienst umfassen, um zu signalisieren, dass alles bereit ist, sowie das Abrufen und Installieren von Missbrauchsschutz-Tools. Wenn einer dieser Prozesse fehlschlägt, kann der Runner keine Aufträge annehmen.
Wenn diese Probleme auftreten, versuchen Sie, eine virtuelle Maschine im selben Subnetz einzurichten, das Sie für private Netzwerke mit GitHubgehosteten Runnern verwenden. Wenn Sie jedoch über einen Dienstzuordnungslink (SAL) verfügen, ist das nicht möglich.
Wenn Sie über einen SAL verfügen, versuchen Sie, ein ähnliches Subnetz im virtuellen Netzwerk einzurichten und eine virtuelle Maschine in diesem Netzwerk zu platzieren. Versuchen Sie anschließend, darauf 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.
Netzwerkeinstellungen, die auf der falschen Ebene konfiguriert sind
Wenn Netzwerkeinstellungen mithilfe der databaseId einer Organisation anstelle der databaseId eines Unternehmens konfiguriert wurden, tritt ein Fehler auf. Die Fehlermeldung gibt an, dass ein privates Netzwerk nicht mit der bereitgestellten Ressourcen-ID hergestellt werden kann, da es bereits einem anderen Unternehmen oder einer anderen Organisation zugeordnet ist. Um dies zu beheben, löschen Sie die vorhandenen Netzwerkeinstellungen und erstellen Sie sie mit der UnternehmensdatabaseId neu.
Das Failover-Netzwerk schaltet den Datenverkehr nicht um.
Hinweis
Das VNET-Failover befindet sich in öffentliche Vorschau und unterliegt Änderungen. Der Wechsel zwischen primären und Failovernetzwerken ist ein schrittweiser Prozess. Während des Übergangs können Dienste gleichzeitig auf beiden Netzwerken laufen. Basierend auf Tests dauert der vollständige Übergang ungefähr 15 Minuten. Stellen Sie sicher, dass beide Subnetze während dieses Zeitraums zugänglich bleiben.
Wenn das Aktivieren des Failover-Netzwerks den Runner-Datenverkehr nicht umleitet, überprüfen Sie Folgendes:
- Stellen Sie sicher, dass die Azure-Ressourcen des Failovers (VNET/Subnetz, NSG/Firewall, Netzwerkeinstellungen) ordnungsgemäß konfiguriert sind. Befolgen Sie die gleichen Verfahren zum Konfigurieren Ihrer Azure-Ressourcen, die für Ihr primäres Subnetz verwendet werden.
- Vergewissern Sie sich, dass das Failovernetzwerk der richtigen Netzwerkkonfiguration hinzugefügt wurde und dass die Konfiguration der entsprechenden Läufergruppe zugeordnet ist.
Failover-Subnetz nicht erreichbar
Wenn Läufer nach dem Aktivieren des Failovernetzwerks keine Verbindung herstellen können, liegt das Problem wahrscheinlich bei den Azure-Ressourcen, die für das Failoversubnetz konfiguriert sind.
- Stellen Sie sicher, dass das Failoversubnetz über die richtigen NSG- oder Firewallregeln verfügt, die den anforderungen entsprechen, die in den AUTOTITLE-Verfahren aufgeführt sind.
- Stellen Sie sicher, dass das Failover-Subnetz über ausreichenden IP-Adressraum für die erwartete Parallelität des Runners verfügt.
Nach dem von GitHub initiierten Failover kann nicht zurück zur primären Konfiguration gewechselt werden.
- Navigieren Sie zu Ihrer Netzwerkkonfiguration in den Einstellungen für gehostete Computenetzwerke .
- Klicken Sie neben der Netzwerkkonfiguration auf das Bearbeitungssymbol. Klicken Sie dann auf „Konfiguration bearbeiten“.
- Klicken Sie auf "Failover-VNET deaktivieren", um den Runner-Datenverkehr wieder auf das primäre Subnetz zu leiten.
Wenn Sie das Failover nicht deaktivieren können, stellen Sie sicher, dass die Azure-Ressourcen des primären Subnetzes fehlerfrei und zugänglich sind. Überprüfen Sie, ob in der Azure-Region des primären Subnetzes keine laufenden Ausfälle vorhanden sind.