注: リポジトリ キャッシュは現在ベータ版であり、変更される可能性があります。
リポジトリ キャッシュの構成について
リポジトリ キャッシュと呼ばれる特殊な種類のレプリカを作成することで、リポジトリ キャッシュを構成できます。次に、リポジトリ キャッシュにレプリケートされるリポジトリ ネットワークを管理するデータの� �所ポリシーを設定できます。
クラスタリングでは、リポジトリ キャッシュはサポートされていません。
リポジトリ キャッシュの DNS
プライマリ インスタンスとリポジトリ キャッシュの DNS 名は異なっている必要があります。 たとえば、プライマリ インスタンスが github.example.com
にある� �合は、キャッシュ名は europe-ci.github.example.com
や github.asia.example.com
に決定できます。
CI マシンで、プライマリ インスタンスではなくリポジトリ キャッシュからフェッチするには、Git の url.<base>.insteadOf
構成設定を使用できます。 詳細については、Git ドキュメントにある「git-config
」を参照してく� さい。
たとえば、CI マシンのグローバル .gitconfig
には、次の行が含まれます。
[url "https://europe-ci.github.example.com/"]
insteadOf = https://github.example.com/
次に、https://github.example.com/myorg/myrepo
をフェッチするように Git に要求すると、代わりに https://europe-ci.github.example.com/myorg/myrepo
からフェッチされます。
リポジトリ キャッシュの構成
-
に SSH でアクセスします。 インスタンスが複数のノードで構成されている� �合は (高可用性や geo レプリケーションが構成されている� �合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する� �合は、任意のノードに SSH 接続できます。 SSH 接続について詳しくは、「管理シェル (SSH) にアクセスする」をご覧く� さい。
$ ssh -p 122 admin@HOSTNAME
-
リポジトリのキャッシュを有効にするには、次のコマンドを実行します。
$ ghe-config cluster.cache-enabled true
-
新しい GitHub Enterprise Server インスタンスを希望するプラットフォー� にセットアップします。 このインスタンスがリポジトリ キャッシュになります。 詳細については、「GitHub Enterprise Server インスタンスをセットアップする」を参照してく� さい。
-
プライマリアプライアンス上のパスワードと一致する管理者パスワードを設定して続行します。
-
[レプリカとして構成] をクリックします。
-
"Add new SSH key(新しいSSH鍵の追� )"の下でSSH鍵を入力してく� さい。
-
[キーの追� ] をクリックします。
-
SSH を使用して、リポジトリ キャッシュの IP アドレスに接続します。
$ ssh -p 122 admin@REPLICA-IP
-
キャッシュ レプリカで、リポジトリ キャッシュの機能フラグを有効にします。
$ ghe-config cluster.cache-enabled true ``` 7. レプリケーション用のキーの組を生成するには、プライマリ アプライアンスの IP アドレスを指定して `ghe-repl-setup` コマンドを使用し、それが返す公開キーをコピーします。 <pre><code class="hljs language-shell">$ ghe-repl-setup <em>PRIMARY IP</em></code></pre> 1. プライマリ アプライアンスの承認されたキーのリストに公開キーを追� するには、`https://PRIMARY-HOSTNAME/setup/settings` を参照して、レプリカからコピーしたキーをリストに追� します。
-
プライマリへの接続を確認し、リポジトリ キャッシュに対してレプリカ モードを有効にするには、
ghe-repl-setup
をもう一度実行します。$ ghe-repl-setup PRIMARY-IP
-
CACHE-LOCATION を、キャッシュがデプロイされているリージョンなどの英数字識別子に置き換えて、リポジトリ キャッシュに対して
cache-location
を設定します。 また、このキャッシュのデータセンター名も設定します。新しいキャッシュでは、同じデータセンター内の別のキャッシュからシード処理を試みます。$ ghe-repl-node --cache CACHE-LOCATION --datacenter REPLICA-DC-NAME
-
データ ストアのレプリケーションを開始するには、
ghe-repl-start
コマンドを使います。$ ghe-repl-start
警告:
ghe-repl-start
を実行すると、プライマリ サーバーを短時間使えなくなり、その間、ユーザーには内部サーバー エラーが表示されることがあります。 もっとわかりやすいメッセージを表示するには、ghe-repl-start
をレプリカ ノードで実行する前にプライマリ ノード上でghe-maintenance -s
を実行し、アプライアンスをメンテナンス モードにします。 レプリケーションを開始したら、ghe-maintenance -u
を使ってメンテナンス モードを無効にします。 プライマリ ノードがメンテナンス モードの間、Git レプリケーションは進行しません。$ ghe-repl-status
-
リポジトリ キャッシュへのリポジトリ ネットワークのレプリケーションを有効にするには、データの� �所ポリシーを設定します。 詳細については、「データの� �所ポリシー」を参照してく� さい。
データの� �所ポリシー
spokesctl cache-policy
コマンドでリポジトリのデータの� �所ポリシーを構成して、データの局所性を制御できます。 データの� �所ポリシーによって、どのリポジトリ ネットワークがどのリポジトリ キャッシュにレプリケートされているかが決まります。 既定では、データの� �所ポリシーが構成されるまで、どのリポジトリ キャッシュにもリポジトリ ネットワークはレプリケートされません。
データの� �所ポリシーは、Git コンテンツにのみ影響します。 Issue や pull request コメントなどのデータベース内のコンテンツは、ポリシーに関係なくすべてのノードにレプリケートされます。
注: データの� �所ポリシーは、アクセス制御と同じではありません。 リポジトリにアクセスできるユーザーを制御するには、リポジトリ ロールを使用する必要があります。 リポジトリ ロールの詳細については、「Organization のリポジトリ ロール」を参照してく� さい。
--default
フラグを使用して、すべてのネットワークをレプリケートするようにポリシーを構成できます。 たとえば、次のコマンドでは、すべてのリポジトリ ネットワークの 1 つのコピーを、cache_location
が "kansas" であるリポジトリ キャッシュのセットにレプリケートするポリシーが作成されます。
$ ghe-spokesctl cache-policy set --default 1 kansas
リポジトリ ネットワークのレプリケーションを構成するには、ネットワークのルートであるリポジトリを指定します。 リポジトリ ネットワークには、リポジトリとリポジトリのすべてのフォークが含まれます。 ネットワーク全体をレプリケートしないと、ネットワークの一部をレプリケートすることはできません。
$ ghe-spokesctl cache-policy set <owner/repository> 1 kansas
ネットワークのレプリカ数を 0 に指定すると、すべてのネットワークをレプリケートし、特定のネットワークを除外するポリシーをオーバーライドできます。 たとえば、次のコマンドでは、� �所 "kansas" 内のリポジトリ キャッシュに、そのネットワークのコピーを含めることができないことが指定されます。
$ ghe-spokesctl cache-policy set <owner/repository> 0 kansas
特定のキャッシュの� �所で、1 より大きいレプリカ数はサポートされていません。