Skip to main content

Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-03-26. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Configuration d’un cache de référentiel

Vous pouvez configurer un cache de référentiel pour GitHub Enterprise Server en créant une instance, en connectant le cache du référentiel à votre instance principale et en configurant la réplication des réseaux de référentiels vers le cache du référentiel.

À propos de la configuration de la mise en cache du référentiel

Vous pouvez configurer la mise en cache du dépôt en créant un type spécial de réplica appelé cache de dépôt. Ensuite, vous pouvez définir des stratégies d’emplacement de données qui régissent les réseaux de référentiel qui sont répliqués dans le cache du référentiel.

La mise en cache du référentiel n’est pas prise en charge avec le clustering.

DNS pour les caches de référentiel

L’instance principale et le cache de référentiel doivent avoir des noms DNS différents. Par exemple, si votre instance principale est à l’adresse github.example.com, vous pouvez décider de nommer un cache europe-ci.github.example.com ou github.asia.example.com.

Pour que vos machines CI récupèrent à partir du cache du référentiel au lieu de l’instance principale, vous pouvez utiliser le paramètre de configuration url.<base>.insteadOf de Git. Pour plus d’informations, consultez git-config dans la documentation Git.

Par exemple, le .gitconfig global pour la machine CI inclurait ces lignes.

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

Ensuite, quand on lui dit d’extraire https://github.example.com/myorg/myrepo, Git récupère depuis https://europe-ci.github.example.com/myorg/myrepo à la place.

Configuration d’un cache de référentiel

  1. Configurez une nouvelle instance GitHub Enterprise Server sur la plateforme de votre choix. Cette instance sera votre cache de référentiel. Pour plus d’informations, consultez « Configuration d’une instance GitHub Enterprise Server ».

  2. Définissez un mot de passe administrateur qui correspond au mot de passe de l’appliance principale et continuez.

  3. Cliquez sur Configurer comme réplica.

  4. Sous « Ajouter une nouvelle clé SSH », tapez votre clé SSH.

  5. Cliquez sur Ajouter une clé.

  6. Connectez-vous à l’adresse IP du cache du référentiel à l’aide de SSH.

    ssh -p 122 admin@REPLICA-IP
    
  7. Pour générer une paire de clés pour la réplication, utilisez la commande ghe-repl-setup avec l’adresse IP de l’appliance primaire et copiez la clé publique qu’elle renvoie.

    ghe-repl-setup PRIMARY_IP
    
  8. Pour ajouter la clé publique à la liste des clés autorisées sur l’appliance principale, recherchez https://PRIMARY-HOSTNAME/setup/settings et ajoutez à la liste la clé que vous avez copiée à partir du réplica.

  9. Pour vérifier la connexion à l’appliance principale et activer le mode réplica pour le cache du référentiel, réexécutez ghe-repl-setup.

    • Si le cache du référentiel est votre seul nœud supplémentaire, aucun argument n'est nécessaire.

      ghe-repl-setup PRIMARY-IP
      
    • Si vous configurez un cache de référentiel en plus d'un ou plusieurs réplicas existants, utilisez l'argument -a ou --add.

      ghe-repl-setup -a PRIMARY-IP
      
  10. Pour configurer le cache du référentiel, utilisez la commande ghe-repl-node et incluez les paramètres nécessaires.

    • Définissez un cache-location pour le cache du référentiel, en remplaçant CACHE-LOCATION par un identificateur alphanumérique, comme la région où le cache est déployé. La valeur CACHE-LOCATION ne doit pas être l’un des sous-domaines réservés pour une utilisation avec l’isolation de sous-domaine, comme assets ou media. Pour obtenir la liste des noms réservés, consultez « Activation de l’isolation de sous-domaine ».

    • Définissez un cache-domain pour le cache du référentiel, en remplaçant EXTERNAL-CACHE-DOMAIN par le nom d’hôte que les clients Git utiliseront pour accéder au cache du référentiel. Si vous ne spécifiez pas cache-domain, GitHub Enterprise Server ajoute le préfixe CACHE-LOCATION en tant que sous-domaine au nom d’hôte configuré pour votre instance. Pour plus d’informations, consultez « Configuration du nom d'hôte pour votre instance ».

    • Si vous ne l'avez pas encore fait, définissez le nom du centre de données sur l'appliance principale et sur tous les réplicas, en remplaçant DC-NAME par un nom de centre de données.

      ghe-repl-node --datacenter DC-NAME
      
    • De nouveaux caches tenteront d’effectuer un seed à partir d’un autre cache dans le même centre de données. Définissez un datacenter pour le cache du référentiel, en remplaçant REPLICA-DC-NAME par le nom du centre de données où vous déployez le nœud.

    ghe-repl-node --cache CACHE-LOCATION --cache-domain EXTERNAL-CACHE-DOMAIN --datacenter REPLICA-DC-NAME
    
  11. Pour démarrer la réplication des magasins de données, utilisez la commande ghe-repl-start.

    ghe-repl-start
    

    Avertissement : ghe-repl-start provoque une brève interruption sur le serveur principal, pendant laquelle les utilisateurs peuvent voir des erreurs de serveur interne. Pour fournir un message plus convivial, exécutez ghe-maintenance -s sur le nœud principal avant d’exécuter ghe-repl-start sur le nœud de réplica pour mettre l’appliance en mode maintenance. Une fois la réplication démarrée, désactivez le mode maintenance avec ghe-maintenance -u. La réplication Git ne progresse pas tant que le nœud principal est en mode maintenance.

  12. Pour vérifier l’état du canal de réplication de chaque magasin de données, utilisez la commande ghe-repl-status.

    ghe-repl-status
    
  13. Pour activer la réplication des réseaux de référentiel dans le cache du référentiel, définissez une stratégie d’emplacement des données. Pour plus d’informations, consultez « Stratégies d’emplacement des données ».

Stratégies d’emplacement des données

Vous pouvez contrôler la localité des données en configurant des stratégies d’emplacement des données pour vos référentiels avec la commande spokesctl cache-policy. Les stratégies d’emplacement des données déterminent quels réseaux de référentiel sont répliqués sur quels caches de référentiel. Par défaut, aucun réseau de référentiels ne sera répliqué sur tous les caches de référentiel jusqu’à ce qu’une stratégie d’emplacement des données soit configurée.

Les stratégies d’emplacement des données affectent uniquement le contenu Git. Le contenu de la base de données, comme les problèmes et les commentaires de demande de tirage, sera répliqué sur tous les nœuds, quelle que soit la stratégie.

Remarque : Les stratégies d’emplacement des données ne sont pas identiques au contrôle d’accès. Vous devez utiliser des rôles de référentiel pour contrôler quels utilisateurs peuvent accéder à un référentiel. Pour plus d’informations sur les rôles de dépôt, consultez « Rôles de dépôt pour une organisation ».

Vous pouvez configurer une stratégie pour répliquer tous les réseaux avec l’indicateur --default. Par exemple, cette commande crée une stratégie pour répliquer une copie unique de chaque réseau de référentiels dans l’ensemble de caches de référentiel dont le cache_location est « kansas ».

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

Pour configurer la réplication pour un réseau de référentiels, spécifiez le référentiel qui est la racine du réseau. Un réseau de référentiels inclut un référentiel et toutes les duplications du référentiel. Vous ne pouvez pas répliquer une partie d’un réseau sans répliquer l’ensemble du réseau.

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

Vous pouvez remplacer une stratégie qui réplique tous les réseaux et exclut des réseaux spécifiques en spécifiant un nombre de réplicas égal à zéro pour le réseau. Par exemple, cette commande spécifie que tout cache de référentiel à l’emplacement « kansas » ne peut contenir aucune copie de ce réseau.

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

Les nombres de réplicas supérieurs à 1 dans un emplacement de cache donné ne sont pas pris en charge.