Skip to main content

Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-07-09. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Konfigurieren eines Repository-Caches

Du kannst einen Repositorycache für GitHub Enterprise Server konfigurieren, indem du eine neue Instanz erstellst, den Repositorycache mit deiner primären Instanz verknüpfst und die Replikation von Repositorynetzwerken in den Repositorycache konfigurierst.

Informationen zur Konfiguration für die Zwischenspeicherung von Repositorys

Du kannst die Zwischenspeicherung von Repositorys konfigurieren, indem du einen speziellen Replikattyp erstellst, der als Repositorycache bezeichnet wird. Anschließend kannst du Richtlinien für Datenspeicherorte festlegen, die steuern, welche Repositorynetzwerke im Repositorycache repliziert werden.

Das Zwischenspeichern von Repositorys wird mit Clustering nicht unterstützt.

DNS für Repository-Caches

Der primäre Instanz- und Repository-Cache sollte über verschiedene DNS-Namen verfügen. Wenn zum Beispiel deine primäre Instanz bei github.example.com vorhanden ist, könntest du deinen Cache europe-ci.github.example.com oder github.asia.example.com nennen.

Damit deine CI-Computer aus dem Repositorycache statt aus der primären Instanz abgerufen werden können, kannst du die Konfigurationseinstellung url.<base>.insteadOf von Git verwenden. Weitere Informationen findest du in der Git-Dokumentation unter git-config.

Beispielsweise würde der globale .gitconfig für die CI-Maschine diese Zeilen enthalten.

[url "https://europe-ci.github.example.com/"]
    insteadOf = https://github.example.com/

Wenn zum Abrufen https://github.example.com/myorg/myrepo aufgefordert wird, wird Git stattdessen von https://europe-ci.github.example.com/myorg/myrepo fetchen.

Konfigurieren eines Repository-Caches

  1. Richte eine neue GitHub Enterprise Server-Instanz auf deiner gewünschten Plattform ein. Diese Instanz ist dein Repositorycache. Weitere Informationen findest du unter GitHub Enterprise Server-Instanz einrichten.

  2. Lege ein Administratorpasswort fest, das dem Passwort auf der primären Appliance entspricht, und setze den Vorgang fort.

  3. Klicken Sie auf Als Replikat konfigurieren.

  4. Gib unter „Add new SSH key“ (Neuen SSH-Schlüssel hinzufügen) deinen SSH-Schlüssel ein.

  5. Klicke auf Schlüssel hinzufügen.

  6. Verbinden zur IP-Adresse des Repository-Caches mithilfe von SSH.

    ssh -p 122 admin@REPLICA-IP
    
  7. Führe zum Generieren eines Schlüsselpaars zur Replikation den Befehl ghe-repl-setup mit der IP-Adresse der primären Appliance aus, und kopiere den zurückgegebenen öffentlichen Schlüssel.

    ghe-repl-setup PRIMARY_IP
    
  8. Um den öffentlichen Schlüssel der Liste autorisierter Schlüssel auf der primären Appliance hinzuzufügen, navigiere zu https://PRIMARY-HOSTNAME/setup/settings, und füge der Liste den Schlüssel hinzu, den du vom Replikat kopiert hast.

  9. Führe ghe-repl-setup erneut aus, um die Verbindung mit dem primären Replikat zu überprüfen und den Replikatmodus für den Repositorycache zu aktivieren.

    • Wenn der Repositorycache dein einziger zusätzlicher Knoten ist, sind keine Argumente erforderlich.

      ghe-repl-setup PRIMARY-IP
      
    • Wenn du zusätzlich zu einem oder mehreren vorhandenen Replikaten einen Repositorycache konfigurierst, verwende das -a- oder--add-Argument.

      ghe-repl-setup -a PRIMARY-IP
      
  10. Verwende zum Konfigurieren des Repositorycache den Befehl ghe-repl-node, und füge die erforderlichen Parameter ein.

    • Lege einen cache-location Für den Repository-Cache fest, indem du CACHE-LOCATION durch einen alphanumerischen Bezeichner so wie den Bereich, in dem der Cache bereitgestellt wird ersetzt. Der CACHE-LOCATION-Wert darf keine der für die Verwendung mit Unterdomänenisolation reservierten Unterdomänen sein, z. B. assets oder media. Eine Liste der reservierten Namen findest du unter Subdomain-Isolation aktivieren.

    • Lege cache-domain für den Repositorycache fest, und ersetze EXTERNAL-CACHE-DOMAIN durch den Hostnamen, den Git-Clients für den Zugriff auf den Repositorycache verwenden. Wenn du cache-domain nicht angibst, stellt GitHub Enterprise Server dem für deine Instanz konfigurierten Hostnamen den CACHE-LOCATION-Wert als Unterdomäne voran. Weitere Informationen findest du unter Konfigurieren des Hostnamens für deine Instanz.

    • Falls noch nicht geschehen, lege den Namen des Rechenzentrums auf die primäre und sonstige Replikatappliances fest, und ersetze DC-NAME durch einen Rechenzentrumsnamen.

      ghe-repl-node --datacenter DC-NAME
      
    • Neue Caches versuchen, aus einem anderen Cache im selben Rechenzentrum zu seeden. Lege datacenter für den Repositorycache fest, und ersetze REPLICA-DC-NAME durch den Namen des Rechenzentrums, in dem du den Knoten bereitstellst.

    ghe-repl-node --cache CACHE-LOCATION --cache-domain EXTERNAL-CACHE-DOMAIN --datacenter REPLICA-DC-NAME
    
  11. Um die Replikation der Datenspeicher zu starten, verwende den Befehl ghe-repl-start.

    ghe-repl-start
    

    Warnung: ghe-repl-start verursacht einen kurzen Ausfall des primären Servers. Währenddessen wird Benutzern möglicherweise ein interner Serverfehler angezeigt. Um eine benutzerfreundlichere Meldung bereitzustellen, führe ghe-maintenance -s auf dem primären Knoten aus, bevor du ghe-repl-start auf dem Replikatknoten ausführest, um die Appliance in den Wartungsmodus zu versetzen. Nachdem die Replikation gestartet wurde, deaktiviere den Wartungsmodus mit ghe-maintenance -u. Die Git-Replikation wird nicht fortgesetzt, während sich der primäre Knoten im Wartungsmodus befindet.

  12. Führe den Befehl ghe-repl-status aus, um den Status des Replikationskanals jedes Datenspeichers zu überprüfen.

    ghe-repl-status
    
  13. Um die Replikation von Repository-Netzwerken auf den Repository-Cache zu aktivieren, lege eine Richtlinie für Datenspeicherorte fest. Weitere Informationen findest du unter Richtlinie für Datenspeicherorte.

Richtlinie für Datenspeicherorte

Du kannst die Datenlokalität steuern, indem du Richtlinien für Datenspeicherorte für deine Repositorys mit dem spokesctl cache-policy-Befehl konfigurierst. Richtlinien für Datenspeicherorte bestimmen, welche Repository-Netzwerke repliziert werden, auf denen Repository-Caches repliziert werden. Standardmäßig werden keine Repository-Netzwerke in allen Repository-Caches repliziert, bis eine Richtlinie für Datenspeicherorte konfiguriert ist.

Richtlinien für Datenspeicherorte wirken sich nur auf Git-Inhalte aus. Inhalte in der Datenbank, so wie Issues und Pull Request-Kommentare, werden unabhängig von der Richtlinie auf alle Knoten repliziert.

Hinweis: Richtlinien für Datenspeicherorte sind nicht mit der Zugriffssteuerung identisch. Du musst Repositoryrollen verwenden, um zu steuern, welche Benutzer*innen auf ein Repository zugreifen können. Weitere Informationen zu Repositoryrollen findest du unter Repositoryrollen für eine Organisation.

Du kannst eine Richtlinie so konfigurieren, dass alle Netzwerke mit dem --default-Flag repliziert werden. Dieser Befehl erstellt zum Beispiel eine Richtlinie, um eine einzelne Kopie jedes Repository-Netzwerks in den Satz von Repository-Caches zu replizieren, deren cache_location „Kansas" lautet.

ghe-spokesctl cache-policy set --default 1 kansas

Um die Replikation für ein Repositorynetzwerk zu konfigurieren, gib das Repository an, das das Stammverzeichnis des Netzwerks ist. Ein Repository-Netzwerk enthält ein Repository und alle Forks des Repositorys. Du kannst keinen Teil eines Netzwerks replizieren, ohne das gesamte Netzwerk zu replizieren.

ghe-spokesctl cache-policy set <owner/repository> 1 kansas

Du kannst eine Richtlinie außer Kraft setzen, die alle Netzwerke repliziert und bestimmte Netzwerke ausschließen, indem du als Anzahl der Replikate Null für das Netzwerk angibst. Dieser Befehl gibt zum Beispiel an, dass ein Repository-Cache am Speicherort „Kansas" keine Kopien dieses Netzwerks enthalten kann.

ghe-spokesctl cache-policy set <owner/repository> 0 kansas

Anzahlen der Replikate, die größer als einer in einem bestimmten Cache-Speicherort sind, werden nicht unterstützt.