Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

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 Einrichten einer GitHub Enterprise Server-Instanz.

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

  3. Klicke auf Als Replikat konfigurieren. Installationsoptionen mit einem Link zum Konfigurieren deiner neuen Instanz als Replikat

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

  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
    1. 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.
  7. 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.

    $ ghe-repl-setup PRIMARY-IP
  8. 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 Aktivieren der Unterdomänenisolation.
    • 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 eines Hosznamens“.
    • 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
  9. 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.

    11. Führe den Befehl `ghe-repl-status` aus, um den Status des Replikationskanals jedes Datenspeichers zu überprüfen.
    $ ghe-repl-status
  10. 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 zum Repository-Zugriff findest du unter „Repository-Rollen 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.