Registry は他のRegistryとの間でPackをミラーできるため、ある環境で作成したPackを、別の環境に固定済みかつ検証済みの状態で出現させられます。複製はcontent-addressedなので、安全で冪等かつ増分的です。ミラーを再実行しても不足しているものだけが転送され、すべてのアーティファクトは解決または実行される前にdigestと照合されます。 このページはタスク指向のウォークスルーです。ミラーリング、競合、署名の背景にある概念モデルについては、/service/replication を参照してください。 このページ全体では、@acme/pricing にパッケージ化され、ハブからオンプレミスRegistryへミラーされる daily-price-watch flow（ブラウザーTool search-price@1.2.0 → 変換 → シークレットWebhookへの条件付き http.post）を実行例として使います。

​
手順に沿って複製する

1

モードを選ぶ

2つのRegistry間でバイトをどのように流すかを決めます。
モード方向用途
pullremote → local一致するPackをリモートからローカルRegistryへ取得します。
pushlocal → remoteローカルPackをリモートへ公開します。
sync双方向newer-digest-winsで、競合を表面化します（後述）。
scheduled上記のいずれかをcronで実行ウォームミラーまたはDRレプリカ。
ハブからオンプレミスRegistryにシードする場合は、pull が自然な選択です。
2

browserflow registry mirrorを実行する

--from をソースに、--to を宛先に向け、--packs でPackを選択し、--mode を設定します。
browserflow registry mirror \
  --from https://hub.acme.dev \
  --to   ./on-prem-registry \
  --packs "@acme/*" \
  --mode pull
--packs のglobは、どのPackをミラーするかを選択します。ここでは @acme スコープ配下のすべてのPackで、daily-price-watch と search-price@1.2.0 の置き場所である @acme/pricing が含まれます。Transportは差し替え可能です。--from と --to には、HTTPS Registry、OCI Registry、オブジェクトストレージ、またはエアギャップ向けのファイルバンドルを指定できます。以下で説明する検証は、バイトがどのように届いたかにかかわらず同じです。
複製は冪等かつ増分的です。同じミラーをもう一度実行しても、宛先にまだ存在しないPackとバージョンだけが転送されるため、繰り返しても安全です。
3

到着時検証を理解する

すべてのアーティファクトがdigestを持つため、複製では到着時に検証します。主張されたdigestと一致するハッシュにならないPackは、解決または実行される前に拒否されます。
✓ @acme/pricing@2.3.0  sha256:7f3a…  verified
✗ @acme/pricing@2.4.0  digest mismatch — rejected
digest mismatchは警告ではなく、そのアーティファクトに対するハード失敗です。エンジンは、バイトが主張するdigestと一致しないPackを解決も実行もしません。これにより、ある環境で証明されたPackが別の環境で同一に再現されます。
4

競合に対処する

sync モードでは、ルールはnewer-digest-winsであり、競合は黙って解決されるのではなく表面化されます。自動解決されない唯一のケースは次のとおりです。
同じ name@version の下に2つの異なる本体がある場合は、ハード競合です。黙って上書きされることはありません。Semverとdigestの不変性がそれを禁じています。公開済みの @acme/pricing@2.3.0 は1つの不変なバイト集合なので、2つ目の異なる 2.3.0 がそれを置き換えることはできません。
これが発生した場合は、ソース側で解決します。既存バージョンの下で異なる本体を再ミラーしようとするのではなく、バージョンを上げます（変更後の本体を新しい @acme/pricing@2.3.1 として公開します）。
5

必要に応じて信頼済みキーの署名を要求する

完全性に加えて、真正性を要求できます。公開者は PackManifest に署名でき、Registryはミラーを受け入れる前に信頼済みキーによる有効な署名を要求できます。署名はdigestの上に置かれます。完全性はdigestから、真正性は署名から得られます。署名を要求するように設定された宛先は、digestとしては有効でも、未署名または信頼されていないキーで署名されたPackを拒否します。

​
宛先を検査して検証する

ミラー後、何が到着したかを確認し、完全性をローカルで再チェックします。 
browserflow registry ls --registry ./on-prem-registry          # ミラーされたPackとバージョンを一覧表示
browserflow registry verify --registry ./on-prem-registry       # 宛先でdigestを再検証
registry ls は現在存在するPackとバージョンを表示します（@acme/pricing@2.3.0 が見えるはずです）。registry verify は、保存済みアーティファクトを主張されたdigestに対して再ハッシュします。これは到着時に実行されるのと同じチェックを、オンデマンドで使えるものです。
すべてのミラーは特権操作であり、アクター、タイムスタンプ、関係するdigestとともに監査ログへ記録され、content-addressedなコンプライアンス証跡を提供します。/service/access-control を参照してください。

​
関連

複製の詳細

概念モデル: モード、競合ルール、Transport、署名。

エアギャップ環境へのデプロイ

検証済みファイルバンドルとして、ネットワーク境界を越えてPackを運びます。

Pack

ミラーするPackを作成し、バージョン付けし、署名し、公開します。