--- title: "フィードを複製（レプリケーション）" order: 5 hidden: true ---

ProGet Enterpriseは、ローカルとグローバルの両方で、複数のProGetサーバー間でフィードを複製（レプリケーション）できます。

在宅勤務とグローバル化が進むにつれ、多拠点での開発が一般的になりました。大陸をまたいだ大規模な共同作業は、バージョン管理、ネットワークアクセス、ネットワーク速度が課題になります。

これを解決するのが、ProGet のフィードレプリケーション機能です。ProGet のフィードレプリケーション機能には、以下のメリットがあります。

- 部門間でのパッケージの共有
- ネットワークの遅延や帯域幅の制限を防ぐ。
- サイト固有のハードウェア障害によるアクセス制限を防ぐために、重要なサービスの可用性を維持。
- 時間、イベント、またはオンデマンドに基づいてレプリケーションのスケジュールを自動化。
- リポジトリをローカルネットワークの外にある ProGet の別のインスタンスに複製。
- 世界のどこにいても、異なるチームがパッケージを利用できるようにする。

マルチサイトレプリケーションを実行するには、フィードを、レプリケーションサーバとレプリケーションクライアントとして設定します。

## フィードレプリケーションの設定方法

フィードレプリケーションは、[Feed Management (フィード管理)] ページでフィードごとに構成され、フィードの管理権限が必要です。 フィードは、レプリケーションサーバー、レプリケーションクライアント、またはより高度なシナリオの両方として構成できます。

### ソースURL：

ソースURLはレプリケーションサーバに公開されたエンドポイントであり、レプリケーションクライアントの設定内で指定する必要があります。

### 同期トークン：

フィードをレプリケーションサーバーとして構成するには、同期トークンを追加/生成する必要があります。同期トークンは、レプリケーションクライアントがレプリケーションサーバーのURLとともに提供する必要があります。 同期トークンは、レプリケーションクライアントがフィードに接続できるようにするため、機密情報として扱う必要があります。

### レプリケーションクライアント

レプリケーションクライアントとは、他のProGetインスタンス内のレプリケーションサーバフィードへ接続できるように設定された ProGet フィードです。レプリケーションクライアントフィードには以下の機能があります。

- プル - ローカルフィードが、レプリケーションサーバフィードから（新しくプッシュされたパッケージや削除されたパッケージなどの）変更情報を読み込む
- プッシュ - ローカルフィードが、レプリケーションサーバフィードに対して変更情報を送信する
- ミラー - ローカルフィードが、レプリケーションサーバフィードに対してプッシュとプルの両方を行う

## レプリケーションサーバ

レプリケーションサーバとは、レプリケーションクライアントの接続とフィードステートでのレスポンスを許可する ProGet のフィードです。レプリケーションクライアントがフィードステートをプロセスすると、設定によって、パッケージのダウンロードやインストール、削除などができます。

### オプション：

- [Disabled (無効化)] - レプリケーションクライアントはフィードに接続できない

- [Allow external feeds to replicate from this feed (read-only) (外部のフィードからこのフィードの複製を許可する) (閲覧のみ)] - レプリケーションクライアントはフィードへの接続と変更のプルができるが、変更をプッシュすることはできない

- [Allow local feeds to be changed by external feeds (read/write) (外部のフィードからローカルフィードの変更を許可する) (閲覧/編集)] - レプリケーションクライアントはフィードへの接続や変更のプル、変更のプッシュを行うことができる

注釈：ProGetv.5.2 以前のバージョンでのレプリケーションサーバの設定は [Allow other feeds to replicate with this one (別のフィードからのこのフィードの複製を許可する)] から行ってください。

### 有効な構成

以下の表は有効な構成の詳細です。（列がクライアント構成、行がサーバ構成）

| 無効化 | プルのみ | プッシュのみ | ミラー
--- | --- | --- | --- | ---
無効 | - | 無効 | 無効 | 無効
閲覧のみ | - | 有効 | 無効 | 注意
閲覧/書き込み | - | 有効 | 有効 | 有効

無効な構成は、クライアントと [Diagnostic Center (診断センター)] によってそれぞれの実行ログに記録されます。

# アーキテクチャの例

## フルレプリケーションとミラーリング

単純な例としては、複数の ProGet インストレーションに対して単一のフィードを完全にミラーリングする方法があります。以下の例では、ロサンゼルスが「ハブ」として設定され、東京とクリーブランドの両方がロサンゼルスのフィードをレプリケーション（複製）するように構成されています。

####

位置 | クライアント | サーバ
--- | --- | ---
Tokyo | [Mirror external feed (Los Angeles) (外部フィードをミラーリングする) (ロサンゼルス)] | [Disabled (無効化)]
Los Angeles | [Disabled (無効化)] | [Allow local feeds to be changed by external feeds (外部フィードによるローカルフィードの変更を許可する)]
Cleveland | [Mirror external feed (Los Angeles) (外部フィードをミラーリングする) (ロサンゼルス)] | [Disabled (無効化)]

この設定を完了させるには、それぞれの都市を以下のように構成してください：

この設定は、3 つのインストレーション内のパッケージプッシュや削除の情報を他のインストレーション全てにプロパゲーションします。

この構成を行うには、本番環境に対応するために 3 つのProGetエンタープライズライセンスが必要です。また、インスタンスをテストするためには追加のライセンスが必要です。さらに詳しい高可用性テスト環境の利点については、無料版のProGetからProGetエンタープライズへの移行についてのブログ（リンク先英語）をご覧ください。

## パーシャルレプリケーション

さらに複雑な例では、インストレーションがレプリケーションクライアントとサーバの両方として機能するように設定する方法があります。

以下の例では、ニューヨークが世界中にある複数のProGetサーバのハブとして機能しています。ニューヨークはロサンゼルスのフィードを完全にミラーリングするように設定されていますが、東京、マイアミ、ベルリンにあるProGetインストレーションはニューヨークからの変更をプルするようにのみ設定されています。このように設定すれば、東京、マイアミ、ベルリンの変更がニューヨークやロサンゼルスに適応されるのを防げます。

この設定を完了させるには、それぞれの都市を以下のように構成してください：

####

位置 | クライアント | サーバ
--- | --- | ---
Los Angeles | [Disabled (無効化)] | [Allow local feeds to be changed by external feeds (外部フィードによるローカルフィードの変更を許可する)]
New York | [Mirror external feed (Los Angeles) (外部フィードをミラーリングする) (ロサンゼルス)] | [Allow external feeds to replicate from this feed (外部フィードのこのフィードからのレプリケーションを許可する)]
Tokyo | [Only apply external changes to local feed (New York) (外部の変更のみをローカルフィードに適用する) (ニューヨーク)] | [Disabled (無効化)]
Miami | [Only apply external changes to local feed (New York) (外部の変更のみをローカルフィードに適用する) (ニューヨーク)] | [Disabled (無効化)]
Berlin | [Only apply external changes to local feed (New York) (外部の変更のみをローカルフィードに適用する) (ニューヨーク)] | [Disabled (無効化)]

上記の構成は以下の動作を起こします：

- ロサンゼルスとニューヨークのフィードは完全にミラーリングされ、プッシュや削除情報はお互いにプロパゲーションされる
- 東京、マイアミ、ベルリンのフィードはニューヨーク（または拡張によってロサンゼルス）からのプッシュや削除情報を定期的にプルする
- 東京、マイアミ、ベルリンのフィードに対してのプッシュや削除はニューヨーク（または拡張によってロサンゼルス）に適用されない
- ニューヨークで削除された特定のパッケージは、パッケージの種類・名前・バージョンが一致していれば（もともと東京やマイアミ、ベルリンで作成されたものでなくても）東京、マイアミ、ベルリンでも削除される

この構成を行うには、本番環境に対応する 5 つのProGetエンタープライズライセンスが必要です。また、インスタンスをテストするためには追加のライセンスが必要です。さらに詳しい高可用性テスト環境の利点については無料版のProGetからProGetエンタープライズへの移行についてのブログ記事（リンク先英語）をご覧ください。

# ベストプラクティス

過去のお問い合わせ内容に基づき、以下のガイドラインをおすすめしています：

- ◯：レプリケーションに関わる全てのProGetインストレーションが全く同じProGetのバージョン（最低限、同じマイナーバージョン（例：5.5.x））で稼働していること
- ◯：可能であれば読み取り専用のレプリケーションではなく、外部フィード用コネクタの使用
- ✕：ProGetの同じインスタンス内で、別フィードのレプリケーション　を設定する
- ✕： レプリケーションクライアントとサーバーがお互いを指定するようなインスタンスを2つ構成する
- ✕：独自レプリケーションを提供するパッケージストアをすでに利用しており、さらに可用性を目的としてレプリケーションを使用すること。例）地域をまたいだレプリケーションを提供しているAWSパッケージストアを利用している場合など
- ✕：レプリケーションサーバを「このフィードがローカルフィードによって変更されることを許可する」ように設定し、信頼されていないパーティに同期トークンを配布の上、フィード内容（感染したパッケージやマルウェアなどを含む可能性がある）へのフルアクセスを有効にすること

# トラブルシューティング

レプリケーション関連のエラー要因で最も多いのが、レプリケーションに関わるサーバクラスタのそれぞれに ProGet エンタープライズ（もしくは体験版）が必要という条件を満たしていないことです。この場合、エラーが生成され、レプリケーションは実行されません。

## レプリケーションステータス・概要

レプリケーションが構成されたフィードの一覧は、[Administration (管理)] ＞ [Replication Overview (レプリケーション概要)] からご覧ください。

## ロッジング

レプリケーションクライアントのログは [Executions (実行)] ページから見られます。 [Administration (管理)] ＞[Executions (実行)] に移動し、[Feed Replication (フィードレプリケーション)] のフィルタをかけて表示してください。

### サーバ

レプリケーションサーバのログは [Diagnostic Center (診断センター)] から閲覧できます。[Administration (管理)] ＞ [Diagnostic Center (診断センター)] ＞ [View Log Messages (ログメッセージを閲覧する)] から、[Feed Replication (フィードレプリケーション)] のフィルタをかけると、エラーメッセージがある場合は表示されます。

デフォルトの設定では、レプリケーションサーバのエラーのみが記録されるのでご注意ください。成功した接続の記録を有効にするには、[Advanced Settings (詳細設定)] のページに移動し、Diagnostics.MinimumLogLevel を 0 に設定してください。こうすると、デバッグメッセージが有効になります。 また、設定を反映させるにはウェブアプリケーションを再起動する必要があります。0 に設定するのは一時的にし、その後デフォルトの値である20に戻すことをおすすめしています。

## クライアントとサーバのオプションがない場合

レプリケーションクライアント/サーバの区別は ProGet v5.2 から加わった要素であり、 それ以前のバージョンはどちらか片方しか構成できません。Replicate from external feed (外部のフィードからレプリケーションする)と [allow other feeds to replicate with this one (他のフィードがこのフィードをレプリケーションすることを許可する)] のオプションが、クライアントとサーバそれぞれと同じ役割を果たしています。

## Docker

DockerフィードレプリケーションはProGet 5.2.5以降から対応しており、

- 公開の日付とダウンロード数は同期されない
- blobとマニフェストは全て同期されるので、リテンションのルールはそれぞれの同期から設定する必要がある
- 削除記録（墓石を意味するtumbstoneと呼ばれることもある）は Docker フィードに記録されないので、イメージはフィードレプリケーションでしか追加できず、消去することはできない。タグがないイメージを削除するには、リテンションのルールを設定する必要がある