Konfiguration privater Netzwerke für GitHub-gehostete Runner in Ihrer Organisation

Erfahren Sie, wie Sie GitHub-gehostete Runner mit einem privaten Azure-Netzwerk in Ihrer Organisation verwenden.

Wer kann dieses Feature verwenden?

Organisationsbesitzer*innen für Organisationen in einem Unternehmen können private Azure-Netzwerke für GitHub-gehostete Runner auf Organisationsebene konfigurieren.

In diesem Artikel

Informationen zu privaten Azure-Netzwerken für GitHubgehostete Runner

Um GitHub-gehostete Runner mit Azure VNET zu verwenden, konfigurieren Sie zuerst Ihre Azure-Ressourcen. Erstellen Sie dann eine private Netzwerkkonfiguration in GitHub.

Die folgenden Vorgehensweisen begleiten Sie durch diese beiden Schritte.

Weitere Informationen zur Behebung häufiger Probleme bei der Nutzung von GitHub-gehosteten Runnern mit Azure VNET findest du unter Problembehandlung von Azure-Privatnetzwerkkonfigurationen für GitHub-gehostete Runner in Ihrer Organisation.

Hinweis

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 ihrer Azure-Ressourcen

Sie verwenden ein Skript, um die Konfiguration Ihrer Azure-Ressourcen zu automatisieren.

Voraussetzungen

  • Verwenden Sie ein Azure-Konto mit der Rolle „Mitwirkender“ für das Abonnement und der Rolle „Netzwerkmitwirkender“. Mit diesen Rollen können Sie den GitHub.Network-Ressourcenanbieter registrieren und das Subnetz delegieren. Weitere Informationen finden Sie in der Azure-Dokumentation unter In Azure integrierte Rollen.

  • Um die Subnetze ordnungsgemäß den richtigen Benutzer*innen zuzuordnen, müssen NetworkSettings-Ressourcen von Azure in denselben Abonnements erstellt werden, in denen virtuelle Netzwerke erstellt werden.

  • Um die Ressourcenverfügbarkeit/Datenresidenz sicherzustellen, müssen Ressourcen in derselben Azure-Region erstellt werden.

  • Ausgehender Netzwerkdatenverkehr aus dem Subnetz darf nicht der TLS-Abfangen unterliegen, da unsere Virtual Machines nicht für vertrauenswürdige Zwischenzertifikate konfiguriert werden, die Ihr Netzwerk für die Ausführung der Abfangen verwendet.

    Wenn Sie TLS-Abfangen verwenden müssen, können Sie Zwischenzertifikate über ein benutzerdefiniertes Image installieren. Weitere Informationen findest du unter Verwenden von benutzerdefinierten Bildern.

  • Wir empfehlen einige Ebenen der Netzwerkdatenverkehrskontrolle über Ihr Azure VNET und die Verwendung von DNS/domänenbasierten Steuerelementen. Die zuvor empfohlenen IP-Adressen werden am oder nach dem 1. Juli 2026 geschlossen.

DNS/Domain Control (empfohlen)

Wenn Sie den ausgehenden Zugriff Ihrer auf GitHub gehosteten Runner mit Azure-VNET mithilfe von DNS oder Domänen steuern, setzen Sie eine Reihe von Domänen für die Funktionalität von GitHub Actions auf die Zulassungsliste. Dies ist die empfohlene Vorgehensweise, da die Domänen auf dem GitHub Meta-Endpunkt veröffentlicht werden, der GitHub bei Änderungen der Netzwerkanforderungen auf dem neuesten Stand gehalten wird. Eine Aufschlüsselung der Domänen nach Funktion finden Sie im Abschnitt "Kommunikation" in Referenzen zu selbstgehosteten Runnern.

Sie finden die Domänen für die Zulassungsliste im GitHub Meta-Endpunkt unter https://api.github.com/meta. Weitere Informationen zum Metaendpunkt finden Sie unter REST-API-Endpunkte für Metadaten.

Es gibt drei Abschnitte auf dem Metaendpunkt, auf denen Sie eine Zulassungsliste basierend auf folgendem auswählen können:

  • domains.actions_inbound.full_domains: Eine äußerst spezifische Liste exakter Domänen, die für die Funktionalität von GitHub Actions erforderlich ist, ohne Platzhalter-Domänen.
  • domains.actions: Eine Domänenliste als Mittelweg, bei der einige GitHub-eigene Domänen durch Wildcards abgedeckt werden, andere Domänen jedoch explizit aufgeführt sind.
  • domains.actions_inbound.wildcard_domains: Eine Liste, die hauptsächlich aus Wildcard-Domänen besteht. Dies wird im Hinblick auf Domänenänderungen die stabilste Option sein.

Warnung

Erforderliche Domänen auf dem Metaendpunkt können geändert werden. GitHub stellt sicher, dass sich eine Domäne mindestens eine Woche lang auf dem Metaendpunkt befindet, bevor sie verwendet wird. Der Metaendpunkt stellt kein Datum der letzten Aktualisierung bereit, sodass Sie sich nicht auf einen Zeitstempel verlassen können, um Änderungen zu erkennen.

Wenn Sie beabsichtigen, die spezifischeren Domänenlisten zu verwenden, müssen Sie wöchentlich nach neuen Domänen suchen und Ihre Netzwerksteuerungssysteme entsprechend aktualisieren, oder Ihre GitHub Actions Aufträge können unbeabsichtigte Probleme haben. Da neue Domänen mindestens eine Woche veröffentlicht werden, bevor sie erforderlich sind, hinterlässt eine wöchentliche Überprüfung genügend Vorlaufzeit, um Änderungen anzuwenden, bevor sie wirksam werden. Die Kompromissliste, die einige GitHub Domain-Wildcards zulässt, wird deutlich stabiler sein, und die vollständige Wildcard-Liste dürfte sich kaum ändern.

Sie können jede Technologie Ihrer Wahl verwenden, um DNS/Domänensteuerung auf Ihrem Azure VNET durchzuführen. Dieser Leitfaden richtet sich an die minimal erforderlichen Domänen für grundlegende Funktionen; Möglicherweise müssen Sie Ihrem Zulassungslistensystem weitere Domänen für zusätzliche Szenarien hinzufügen.

IP-Adresssteuerelemente

Warnung

Die unten stehende IP-basierte .bicep-Vorlage ist Schließen und wird am oder nach dem 1. Juli 2026 entfernt. Es bleibt verfügbar, um die Migration zu DNS/domänenbasierten Steuerelementen zu unterstützen (siehe "DNS/Domain Control" weiter oben). Kunden, die diese IP-Liste hart codieren oder in Vorlagen verwenden (z. B. in Terraform), laufen Gefahr, dass der Datenverkehr unterbrochen wird, wenn sich die zugrunde liegenden Azure-IP-Bereiche ändern, da diese statische Liste nicht aktuell gehalten wird. Migrieren Sie zu den Metaendpunktdomänen, bevor diese Vorlage entfernt wird.

Hinweis

Um den geeigneten Subnetz-IP-Adressbereich zu ermitteln, empfehlen wir, einen Puffer von 30 % zur erwarteten maximalen Auftragsparallelität hinzuzufügen. Wenn die Runner deiner Netzwerkkonfiguration beispielsweise auf eine maximale Parallelität von 300 Jobs festgelegt sind, empfiehlt es sich, einen Subnetz-IP-Adressbereich zu verwenden, der mindestens 390 Runner aufnehmen kann. Dieser Puffer trägt dazu bei, sicherzustellen, dass Ihr Netzwerk unerwartete Steigerungen des VM-Bedarfs bewältigen kann, um die erforderliche Job-Parallelität zu unterstützen, ohne dass die IP-Adressen ausgehen.

Wenn Sie den ausgehenden Zugriff mithilfe von IP-Adressen während des Übergangszeitraums steuern, speichern Sie die folgende .bicep Datei. Nennen Sie die Datei actions-nsg-deployment.bicep.

Die von uns bereitgestellte Datei .bicep enthält die Mindestmenge an Regeln für die Verwendung von GitHub-gehosteten Runnern mit Azure-VNETs. Sie müssen unter Umständen Regeln für Ihren spezifischen Anwendungsfall hinzufügen.

Wenn Sie GitHub Enterprise-Cloud mit Datenresidenz im Abschnitt AllowOutBoundGitHub verwenden, müssen Sie auch die Ingress-IP-Bereiche für GHE.com angeben. Weitere Informationen findest du unter Netzwerkdetails für GHE.com.

Bicep
@description('NSG for outbound rules')
param location string
param nsgName string = 'actions_NSG'

resource actions_NSG 'Microsoft.Network/networkSecurityGroups@2017-06-01' = {
  name: nsgName
  location: location
  properties: {
    securityRules: [
      {
        name: 'AllowVnetOutBoundOverwrite'
        properties: {
          protocol: 'TCP'
          sourcePortRange: '*'
          destinationPortRange: '443'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: 'VirtualNetwork'
          access: 'Allow'
          priority: 200
          direction: 'Outbound'
          destinationAddressPrefixes: []
        }
      }
      {
        name: 'AllowOutBoundActions'
        properties: {
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '443'
          sourceAddressPrefix: '*'
          access: 'Allow'
          priority: 210
          direction: 'Outbound'
          destinationAddressPrefixes: [
            '4.175.114.51/32'
            '20.102.35.120/32'
            '4.175.114.43/32'
            '20.72.125.48/32'
            '20.19.5.100/32'
            '20.7.92.46/32'
            '20.232.252.48/32'
            '52.186.44.51/32'
            '20.22.98.201/32'
            '20.246.184.240/32'
            '20.96.133.71/32'
            '20.253.2.203/32'
            '20.102.39.220/32'
            '20.81.127.181/32'
            '52.148.30.208/32'
            '20.14.42.190/32'
            '20.85.159.192/32'
            '52.224.205.173/32'
            '20.118.176.156/32'
            '20.236.207.188/32'
            '20.242.161.191/32'
            '20.166.216.139/32'
            '20.253.126.26/32'
            '52.152.245.137/32'
            '40.118.236.116/32'
            '20.185.75.138/32'
            '20.96.226.211/32'
            '52.167.78.33/32'
            '20.105.13.142/32'
            '20.253.95.3/32'
            '20.221.96.90/32'
            '51.138.235.85/32'
            '52.186.47.208/32'
            '20.7.220.66/32'
            '20.75.4.210/32'
            '20.120.75.171/32'
            '20.98.183.48/32'
            '20.84.200.15/32'
            '20.14.235.135/32'
            '20.10.226.54/32'
            '20.22.166.15/32'
            '20.65.21.88/32'
            '20.102.36.236/32'
            '20.124.56.57/32'
            '20.94.100.174/32'
            '20.102.166.33/32'
            '20.31.193.160/32'
            '20.232.77.7/32'
            '20.102.38.122/32'
            '20.102.39.57/32'
            '20.85.108.33/32'
            '40.88.240.168/32'
            '20.69.187.19/32'
            '20.246.192.124/32'
            '20.4.161.108/32'
            '20.22.22.84/32'
            '20.1.250.47/32'
            '20.237.33.78/32'
            '20.242.179.206/32'
            '40.88.239.133/32'
            '20.121.247.125/32'
            '20.106.107.180/32'
            '20.22.118.40/32'
            '20.15.240.48/32'
            '20.84.218.150/32'
          ]
        }
      }
      {
        name: 'AllowOutBoundGitHub'
        properties: {
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '443'
          sourceAddressPrefix: '*'
          access: 'Allow'
          priority: 220
          direction: 'Outbound'
          destinationAddressPrefixes: [
            '140.82.112.0/20'
            '143.55.64.0/20'
            '185.199.108.0/22'
            '192.30.252.0/22'
            '20.175.192.146/32'
            '20.175.192.147/32'
            '20.175.192.149/32'
            '20.175.192.150/32'
            '20.199.39.227/32'
            '20.199.39.228/32'
            '20.199.39.231/32'
            '20.199.39.232/32'
            '20.200.245.241/32'
            '20.200.245.245/32'
            '20.200.245.246/32'
            '20.200.245.247/32'
            '20.200.245.248/32'
            '20.201.28.144/32'
            '20.201.28.148/32'
            '20.201.28.149/32'
            '20.201.28.151/32'
            '20.201.28.152/32'
            '20.205.243.160/32'
            '20.205.243.164/32'
            '20.205.243.165/32'
            '20.205.243.166/32'
            '20.205.243.168/32'
            '20.207.73.82/32'
            '20.207.73.83/32'
            '20.207.73.85/32'
            '20.207.73.86/32'
            '20.207.73.88/32'
            '20.217.135.1/32'
            '20.233.83.145/32'
            '20.233.83.146/32'
            '20.233.83.147/32'
            '20.233.83.149/32'
            '20.233.83.150/32'
            '20.248.137.48/32'
            '20.248.137.49/32'
            '20.248.137.50/32'
            '20.248.137.52/32'
            '20.248.137.55/32'
            '20.26.156.215/32'
            '20.26.156.216/32'
            '20.26.156.211/32'
            '20.27.177.113/32'
            '20.27.177.114/32'
            '20.27.177.116/32'
            '20.27.177.117/32'
            '20.27.177.118/32'
            '20.29.134.17/32'
            '20.29.134.18/32'
            '20.29.134.19/32'
            '20.29.134.23/32'
            '20.29.134.24/32'
            '20.87.245.0/32'
            '20.87.245.1/32'
            '20.87.245.4/32'
            '20.87.245.6/32'
            '20.87.245.7/32'
            '4.208.26.196/32'
            '4.208.26.197/32'
            '4.208.26.198/32'
            '4.208.26.199/32'
            '4.208.26.200/32'
            '4.225.11.196/32'
            '4.237.22.32/32'
          ]
        }
      }
      {
        name: 'AllowStorageOutbound'
        properties: {
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '443'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: 'Storage'
          access: 'Allow'
          priority: 230
          direction: 'Outbound'
          destinationAddressPrefixes: []
        }
      }
    ]
  }
}

1. Rufe die databaseId für deine Organisation ab

Tipp

Dein Token erfordert mindestens read:org-Berechtigungen zum Ausführen einer erfolgreichen Abfrage.

Du kannst die folgende GraphQL-Abfrage verwenden, um deine Organisations-databaseId abzurufen. Du verwendest die Organisations-databaseId für den Wert der DATABASE_ID-Umgebungsvariablen im nächsten Schritt. Weitere Informationen über das Arbeiten mit GraphQL findest du unter Erstellen von Aufrufen mit GraphQL.

AbfragevariableBeschreibung
loginDer Login für Ihr Organisationskonto, den Sie erkennen können, indem Sie sich die URL Ihrer Organisation ansehen, https://github.com/organizations/ORGANIZATION_LOGIN.
query(
  $login: String!
){
  organization (login: $login)
  {
    login
    databaseId
  }
}
'
Variables
{
  "login": "ORGANIZATION_LOGIN"
}

Alternativ können Sie den folgenden Curl-Befehl verwenden, um Ihr databaseId zu finden.

Shell
curl -H "Authorization: Bearer BEARER_TOKEN" -X POST \
  -d '{ "query": "query($login: String!) { organization (login: $login) { login databaseId } }" ,
        "variables": {
          "login": "ORGANIZATION_LOGIN"
        }
      }' \
https://api.github.com/graphql

2. Verwenden Sie einen Skript zum Konfigurieren Ihrer Azure-Ressourcen

Verwenden Sie das folgende Skript, um ein Subnetz für ein privates Azure-Netzwerk einzurichten. Im Skript werden alle erforderlichen Ressourcen in derselben Ressourcengruppe erstellt.

Um das Skript zu verwenden, füllen Sie die Platzhalterumgebungsvariablenwerte mit den tatsächlichen Werten aus, und führen Sie das Skript aus einer Bash-Shell oder Windows-Subsystem für Linux aus.

Hinweis

  • Führen Sie den folgenden Skript im gleichen Verzeichnis aus, in dem Sie die Datei actions-nsg-deployment.bicep gespeichert haben.
  • Verwenden Sie beim Festlegen der Umgebungsvariablen YOUR_AZURE_LOCATION den Namen Ihrer Region. Dieser Wert unterscheidet sich von dem Anzeigenamen Ihrer Region. Um eine Liste der Namen und Anzeigenamen anzuzeigen, verwenden Sie az account list-locations -o table.
  • Wenn Sie die Netzwerkeinstellungsressource erstellen, wird eine Dienstzuordnungsverknüpfung auf das von Ihnen bereitgestellte Subnetz angewendet. Diese Verknüpfung verhindert das versehentliche Löschen des Subnetzes, während es von GitHub Actions verwendet wird.
  • Wenn Sie dieses Skript so anpassen, dass Netzwerkressourcen in vorhandenen Subnetzen verwendet werden, müssen Sie sicherstellen, dass die mit dem Subnetz verbundenen vorhandenen Netzwerkschnittstellen (NICs) gelöscht werden, bevor das Subnetz an den GitHub Actions-Dienst delegiert wird. Andernfalls kann der Dienst den Dienstzuordnungslink nicht auf das Subnetz anwenden.
Bash
#!/bin/bash

# This script creates the following resources in the specified subscription:
# - Resource group
# - Network Security Group rules
# - Virtual network (vnet) and subnet
# - Network Settings with specified subnet and GitHub Enterprisedatabase ID
#
# It also registers the `GitHub.Network` resource provider with the subscription,
# delegates the created subnet to the Actions service via the `GitHub.Network/NetworkSettings`
# resource type, and applies the NSG rules to the created subnet.

# stop on failure
set -e

#set environment
export AZURE_LOCATION=YOUR_AZURE_LOCATION
export SUBSCRIPTION_ID=YOUR_SUBSCRIPTION_ID
export RESOURCE_GROUP_NAME=YOUR_RESOURCE_GROUP_NAME
export VNET_NAME=YOUR_VNET_NAME
export SUBNET_NAME=YOUR_SUBNET_NAME
export NSG_NAME=YOUR_NSG_NAME
export NETWORK_SETTINGS_RESOURCE_NAME=YOUR_NETWORK_SETTINGS_RESOURCE_NAME
export DATABASE_ID=YOUR_DATABASE_ID
export API_VERSION=2024-04-02

# These are the default values. You can adjust your address and subnet prefixes.
export ADDRESS_PREFIX=10.0.0.0/16
export SUBNET_PREFIX=10.0.0.0/24

echo
echo login to Azure
. az login --output none

echo
echo set account context $SUBSCRIPTION_ID
. az account set --subscription $SUBSCRIPTION_ID

echo
echo Register resource provider GitHub.Network
. az provider register --namespace GitHub.Network

echo
echo Create resource group $RESOURCE_GROUP_NAME at $AZURE_LOCATION
. az group create --name $RESOURCE_GROUP_NAME --location $AZURE_LOCATION

echo
echo Create NSG rules deployed with 'actions-nsg-deployment.bicep' file
. az deployment group create --resource-group $RESOURCE_GROUP_NAME --template-file ./actions-nsg-deployment.bicep --parameters location=$AZURE_LOCATION nsgName=$NSG_NAME

echo
echo Create vnet $VNET_NAME and subnet $SUBNET_NAME
. az network vnet create --resource-group $RESOURCE_GROUP_NAME --name $VNET_NAME --address-prefix $ADDRESS_PREFIX --subnet-name $SUBNET_NAME --subnet-prefixes $SUBNET_PREFIX

echo
echo Delegate subnet to GitHub.Network/networkSettings and apply NSG rules
. az network vnet subnet update --resource-group $RESOURCE_GROUP_NAME --name $SUBNET_NAME --vnet-name $VNET_NAME --delegations GitHub.Network/networkSettings --network-security-group $NSG_NAME

echo
echo Create network settings resource $NETWORK_SETTINGS_RESOURCE_NAME
. az resource create --resource-group $RESOURCE_GROUP_NAME --name $NETWORK_SETTINGS_RESOURCE_NAME --resource-type GitHub.Network/networkSettings --properties "{ \"location\": \"$AZURE_LOCATION\", \"properties\" : { \"subnetId\": \"/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP_NAME/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME\", \"businessId\": \"$DATABASE_ID\" }}" --is-full-object --output table --query "{GitHubId:tags.GitHubId, name:name}" --api-version $API_VERSION

echo
echo To clean up and delete resources run the following command:
echo az group delete --resource-group $RESOURCE_GROUP_NAME

Das Skript gibt die vollständige Payload für die erstellte Ressource zurück. Der in der Payload für die erstellte Ressource zurückgegebene GitHubId-Hashwert ist die ID der Netzwerkeinstellungsressource, die Sie in den nächsten Schritten beim Konfigurieren der Netzwerkkonfiguration mit GitHub verwenden.

Erstellen einer Netzwerkkonfiguration für Ihre Organisation in GitHub

Nachdem du deine Azure-Ressourcen konfiguriert hast, kannst du ein virtuelles Azure-Netzwerk (VNET) für private Netzwerke verwenden. Erstelle hierzu eine Netzwerkkonfiguration auf Unternehmens- oder Organisationsebene. Anschließend kannst du diese Netzwerkkonfiguration Runnergruppen zuordnen.

Beachte, dass die Ersteinrichtung auf Unternehmensebene erfolgen muss, wenn du die mit Azure konfigurierten Netzwerkeinstellungen erstellst. Aus diesem Grund musst du beim Abrufen von databaseId das Unternehmensdatenfeld konfigurieren. Organisationen dürfen nur ihre eigenen Netzwerkkonfigurationen erstellen, nachdem das Unternehmen über die Unternehmensrichtlinie für gehostete Computenetzwerke eingerichtet und aktiviert wurde. Weitere Informationen zu Runnergruppen findest du unter Steuern des Zugriffs auf größere Runner.

Sobald die Netzwerkkonfiguration einer Runnergruppe zugeordnet ist, haben alle Runner in dieser Gruppe Zugriff auf das Azure-VNET, das mit der zugrunde liegenden Konfiguration verbunden wurde.

Voraussetzungen

Stellen Sie sicher, dass Ihre Azure-Ressourcen konfiguriert wurden, bevor Sie eine Netzwerkkonfiguration in GitHub hinzufügen. Weitere Informationen findest du unter Konfigurieren eines privaten Netzwerks für GitHub-Runner in Ihrem Unternehmen.

1. Füge eine neue Netzwerkkonfiguration für deine Organisation hinzu

  1. Klicke in der rechten oberen Ecke von GitHub auf dein Profilbild und dann auf Your organizations.

  2. Wählen Sie eine Organisation aus, indem Sie darauf klicken.

  3. Klicke unter dem Organisationsnamen auf Settings. Wenn die Registerkarte „Einstellungen“ nicht angezeigt wird, wähle im Dropdownmenü die Option Einstellungen aus.

    Screenshot der Registerkarten im Profil einer Organisation. Die Registerkarte „Einstellungen“ ist dunkelorange umrandet.

  4. Klicke in der linken Seitenleiste auf Gehostetes-Compute-Netzwerk.

  5. Klicke auf die Dropdownliste Neue Netzwerkkonfiguration. Klicken Sie dann auf Azure privates Netzwerk.

  6. Benennen Sie Ihre Netzwerkkonfiguration.

  7. Klicken Sie auf Azure Virtual Network hinzufügen.

  8. Geben Sie im Popupfenster die Ressourcen-ID der Netzwerkeinstellungen ein, die Sie abgerufen haben, wenn Sie Ihre Azure Ressourcen für private Netzwerke konfiguriert haben.

  9. Klicken Sie auf Azure Virtual Network hinzufügen.

2. Erstelle eine Runnergruppe für deine Organisation

Hinweis

Damit die Runnergruppe für Repositorys in deiner Organisationen zugänglich ist, müssen diese Repositorys einen Zugriff auf Organisationsebene für diese Runnergruppe besitzen. Weitere Informationen finden Sie unter Steuern des Zugriffs auf größere Runner.

  1. Erstelle eine neue Runnergruppe für deine Organisation. Weitere Informationen zum Erstellen einer Runnergruppe findest du unter Steuern des Zugriffs auf größere Runner.
  2. Wenn du eine Richtlinie für den Repositoryzugriff auswählen möchtest, wähle das Dropdownmenü Repositoryzugriff aus, und klicke auf eine Richtlinie. Sie können eine Runner-Gruppe so konfigurieren, dass sie für eine bestimmte Liste von Repositorys oder für alle Repositorys in der Organisation zugänglich ist.
  3. Verwenden Sie beim Konfigurieren Ihrer Läufergruppe unter "Netzwerkkonfigurationen" das Dropdownmenü, um die Netzwerkkonfiguration auszuwählen, die Sie für das Azure VNET erstellt haben.
  4. Klicke auf Gruppe erstellen, um die Gruppe zu erstellen und die Richtlinie anzuwenden.

3. Fügen Sie den GitHub-gehosteten Runner zur Runner-Gruppe der Organisation hinzu.

Hinweis

Wenn Sie Ihren GitHubgehosteten Läufer zu einer Läufergruppe hinzufügen, wählen Sie die Läufergruppe aus, die Sie in den vorherigen Verfahren erstellt haben.

  1. Fügen Sie den GitHub-gehosteten Runner zur Runner-Gruppe hinzu. Weitere Informationen finden Sie unter Verwalten größerer Runner.

4. Optional können Sie die Netzwerkkonfigurationen verwalten

  1. Klicke in der rechten oberen Ecke von GitHub auf dein Profilbild und dann auf Your organizations.

  2. Wählen Sie eine Organisation aus, indem Sie darauf klicken.

  3. Klicke unter dem Organisationsnamen auf Settings. Wenn die Registerkarte „Einstellungen“ nicht angezeigt wird, wähle im Dropdownmenü die Option Einstellungen aus.

    Screenshot der Registerkarten im Profil einer Organisation. Die Registerkarte „Einstellungen“ ist dunkelorange umrandet.

  4. Klicke in der linken Seitenleiste auf Gehostetes-Compute-Netzwerk.

  5. Um eine Netzwerkkonfiguration zu bearbeiten, klicken Sie rechts neben der Netzwerkkonfiguration auf . Klicken Sie dann auf „Konfiguration bearbeiten“.

  6. Um eine Netzwerkkonfiguration zu deaktivieren, klicken Sie rechts neben der Netzwerkkonfiguration auf . Klicken Sie dann auf „Deaktivieren“.

  7. Um eine Netzwerkkonfiguration zu löschen, klicken Sie rechts neben der Netzwerkkonfiguration auf . Klicken Sie dann auf Löschen.

5. Fügen Sie optional ein Failovernetzwerk zu einer Netzwerkkonfiguration hinzu.

Hinweis

Das VNET-Failover befindet sich in Öffentliche Vorschau und unterliegt Änderungen.

Sie können ein Failovernetzwerk für Ihre Netzwerkkonfiguration konfigurieren. Ein Failovernetzwerk ist ein sekundäres Virtuelles Azure-Netzwerk-Subnetz, das sich in einer anderen Azure-Region als Ihrem primären Subnetz befinden kann. Wenn Ihr primäres Subnetz aufgrund eines regionalen Ausfalls oder einer anderen Unterbrechung nicht verfügbar ist, können Sie das Failovernetzwerk aktivieren, um den Läuferdatenverkehr über das sekundäre Subnetz weiterzuleiten und die Kontinuität für Ihre GitHub Actions Workflows aufrechtzuerhalten.

Wichtige Punkte zum VNET-Failover:

  • Das Failoversubnetz kann sich in einer anderen Azure-Region als dem primären Subnetz befinden.
  • Der Wechsel zwischen primären und Failoversubnetzen ist ein manueller Prozess. Sie aktivieren oder deaktivieren das Failovernetzwerk nach Eigenem Ermessen.
  • Sowohl die primären als auch die Failoversubnetze müssen mit den erforderlichen Azure-Ressourcen (VNET/Subnetz, Netzwerkeinstellungen usw.) konfiguriert werden, bevor Sie Failover verwenden können.
  • Das Failoversubnetz muss sich in einer unterstützten Region befinden.

Stellen Sie vor dem Hinzufügen eines Failovernetzwerks sicher, dass Sie die Azure-Ressourcen (VNET, Subnetz, Netzwerksicherheitsgruppe und Netzwerkeinstellungsressource) für das sekundäre Subnetz konfiguriert haben, indem Sie die oben beschriebenen Verfahren "Konfigurieren Ihrer Azure-Ressourcen" ausführen. Das Failoversubnetz kann sich in einer anderen Azure-Region als Ihrem primären Subnetz befinden.

  1. Klicke in der rechten oberen Ecke von GitHub auf dein Profilbild und dann auf Your organizations.

  2. Wählen Sie eine Organisation aus, indem Sie darauf klicken.

  3. Klicke unter dem Organisationsnamen auf Settings. Wenn die Registerkarte „Einstellungen“ nicht angezeigt wird, wähle im Dropdownmenü die Option Einstellungen aus.

    Screenshot der Registerkarten im Profil einer Organisation. Die Registerkarte „Einstellungen“ ist dunkelorange umrandet.

  4. Klicke in der linken Seitenleiste auf Gehostetes-Compute-Netzwerk.

  5. Klicken Sie auf das Bearbeitungssymbol () neben der Netzwerkkonfiguration, der Sie ein Failovernetzwerk hinzufügen möchten. Klicken Sie dann auf „Konfiguration bearbeiten“.

  6. Klicken Sie auf "Failovernetzwerk hinzufügen".

  7. Geben Sie im Popupfenster die Ressourcen-ID der Netzwerkeinstellungen für Ihr sekundäres Azure-Subnetz (Failover) ein.

  8. Klicken Sie auf Azure Virtual Network hinzufügen.

  9. Nun werden zwei Subnetze in der Netzwerkkonfiguration aufgeführt: die primäre und das Failover, die entsprechend bezeichnet werden.

6. Optional können Sie das Failovernetzwerk aktivieren oder deaktivieren.

Nachdem Sie ein Failovernetzwerk hinzugefügt haben, können Sie es aktivieren, um den Datenverkehr über das sekundäre Subnetz weiterzuleiten oder zu deaktivieren, um zum primären Subnetz zurückzukehren.

  1. Klicke in der rechten oberen Ecke von GitHub auf dein Profilbild und dann auf Your organizations.

  2. Wählen Sie eine Organisation aus, indem Sie darauf klicken.

  3. Klicke unter dem Organisationsnamen auf Settings. Wenn die Registerkarte „Einstellungen“ nicht angezeigt wird, wähle im Dropdownmenü die Option Einstellungen aus.

    Screenshot der Registerkarten im Profil einer Organisation. Die Registerkarte „Einstellungen“ ist dunkelorange umrandet.

  4. Klicke in der linken Seitenleiste auf Gehostetes-Compute-Netzwerk.

  5. Klicken Sie neben der Netzwerkkonfiguration auf das Bearbeitungssymbol (). Klicken Sie dann auf „Konfiguration bearbeiten“.

  6. Um zum Failovernetzwerk zu wechseln, klicken Sie auf Failover-VNET aktivieren. Der Runner-Traffic wird über das Failover-Subnetz weitergeleitet.

  7. Um zum primären Netzwerk zurückzukehren, klicken Sie auf Failover-VNET deaktivieren. Der Runner-Datenverkehr kehrt zum primären Subnetz zurück.

Hinweis

Wenn GitHub das Failover während eines regionalen Ausfalls automatisch aktiviert wird, werden Sie über das Protokollereignis und durch eine E-Mail benachrichtigt. Sie müssen das Failover manuell deaktivieren, um zum primären Subnetz zurückzukehren, wenn der Ausfall aufgelöst wird.

Löschen eines Subnetzes

Wenn Sie die Netzwerkeinstellungsressource erstellen, wird eine Dienstzuordnungsverknüpfung auf das von Ihnen bereitgestellte Subnetz angewendet. Diese Verknüpfung verhindert das versehentliche Löschen des Subnetzes, während es von GitHub Actions verwendet wird.

Um das Subnetz zu löschen, muss diese Dienstzuordnungsverknüpfung zuerst entfernt werden. Die Dienstzuordnungsverknüpfung wird automatisch sicher entfernt, sobald die Netzwerkeinstellungsressource gelöscht wird.

Um die Netzwerkeinstellungsressource zu löschen, muss die Netzwerkkonfiguration, die sie verwendet, zuerst gelöscht werden.

  1. Navigieren Sie zu Ihrem Unternehmen. Beispielsweise auf der Seite Unternehmen in GitHub.com.

  2. Klicken Sie oben auf der Seite auf "Einstellungen".

  3. Klicke in der linken Seitenleiste auf Gehostetes-Compute-Netzwerk.

  4. Öffnen Sie die Netzwerkkonfiguration, die das zu löschende Subnetz verwendet.

  5. Überprüfen Sie die Liste der Runner-Gruppen mithilfe der Netzwerkkonfiguration.

  6. Klicken Sie rechts oben auf die Schaltfläche „“. Klicken Sie dann auf Konfiguration löschen.

  7. Um die Netzwerkeinstellungsressource zu löschen und den Dienstzuordnungslink zu entfernen, verwenden Sie ihre eigenen Eingaben mit folgenden Befehlen mit der Azure CLI. Weitere Informationen finden Sie in der Dokumentation der Azure-Befehlszeilenschnittstelle (Command-Line Interface, CLI).

    Bash
    az account set --subscription $SUBSCRIPTION_ID
az resource delete -g $RESOURCE_GROUP_NAME --name $NETWORK_SETTINGS_RESOURCE_NAME --resource-type 'GitHub.Network/networkSettings' --api-version $API_VERSION

  8. Löschen Sie das Subnetz in Azure. Weitere Informationen finden Sie unter Löschen eines Subnetzes auf Microsoft Learn.