Registryは、他のRegistryとの間でPackをミラーリングできます。これにより、ある環境で作成されたPackを、別の環境に固定済みかつ検証済みの状態で出現させられます。これは「SDKを複製する」という目標です。ハブRegistryで検証した同じsearch-price@1.2.0ブラウザーToolとdaily-price-watch Flowが、オンプレミスのミラー、エアギャップ環境、またはウォームDRレプリカに、バイト単位で同一のまま届きます。複製はcontent-addressedなので、安全で、冪等で、増分的です。

​
Packをミラーリングする

1つのコマンドで、条件に一致するPackをソースRegistryから宛先へ移動します。 
browserflow registry mirror \
  --from https://hub.acme.dev \
  --to   ./on-prem-registry \
  --packs "@acme/*" \
  --mode pull            # pull | push | sync
--packsセレクターは名前パターンで一致します。そのため、"@acme/*"のようなglobは、@acme namespace内のすべてのPackを運びます。これには、daily-price-watchの背後にあるsearch-price@1.2.0 Toolを含む@acme/pricing Packも含まれます。各artifactはdigestで固定されているため、ミラーは宛先にまだ存在しないものだけを転送し、両側が一致した後に再実行しても何も起きません。 複製が移動するのは、Flowのエンジン側です。つまりPack、Flow、およびそれらのdigestです。これは任意のコントロールプレーンの一部であり、Flowの実行方法を変えることはありません（原則T6）。あるRegistry上のPackに対して検証されたFlowは、digestが同じであるため、ミラーされたコピーに対しても同一に再現されます。

​
モード

モード方向振る舞い
pullremoteからlocalへ条件に一致するPackをremoteからlocal Registryへ取得します。
pushlocalからremoteへlocalのPackをremoteへ公開します。
sync双方向新しいdigestが勝ち、conflictは表面化されます。同じname@versionの下に2つの異なるbodyがある場合はhard conflictであり、黙った上書きにはなりません。
scheduled上記のいずれかウォームミラーまたはDRレプリカのために、pull、push、syncのいずれかをcronで実行します。

​
syncとhard-conflictルール

syncは両方のRegistryを突き合わせます。特定のPackについては新しいdigestが勝ち、不一致は推測で解決されるのではなく表面化されます。明確に拒否される唯一のケースは、同じname@versionを名乗る2つの異なるbodyです。これはhard conflictであり、黙った上書きではありません。semverとdigestの不変性がそれを禁止します。公開済みのversionは不変のartifactであるため、同じ@acme/pricing@2.3.0が正当に2つの異なるdigestを持つことはできません。
digestが一致しないname@versionの衝突は、ミラーを停止し、conflictを報告します。replicatorは、1つの不変名の下にある2つの異なるbodyのどちらかを勝者として選ぶことはありません。上書きを強制するのではなく、新しいversionで再公開して解決してください。

​
スケジュールされたミラー

ウォームミラーまたは災害復旧レプリカのために、任意のモードをスケジュール実行します。スタンドアロンエンジンでは、これは小さな組み込みschedulerです。service tierではコントロールプレーンのschedulerなので、スケジュールされた各ミラーはコンソールだけの設定ではなく、宣言的でdigestを認識するrecordです。 
browserflow schedule registry-mirror --cron "*/15 * * * *"   # ウォームDRレプリカ
スケジューリングの詳細はコントロールプレーンにあります。cron駆動のjobがどのように記録され、検査可能になるかは、Schedulingを参照してください。

​
到着時に検証する

すべてのartifactがdigestを持つため、複製は到着時に検証されます。主張されたdigestにhashされないPackは、resolveまたは実行される前に拒否されます。検証は、実際に到着したバイト列に対して宛先で行われます。転送中の破損、切り詰め、改ざんが、後でFlowによってresolveされる可能性のあるRegistryに入り込むことはありません。
1

バイト列が到着する

設定したtransportを通じて、Packが宛先Registryへpull、push、またはsyncされます。
2

bodyを再hashする

宛先は受信したbodyのdigestを計算し、Packが主張するdigestと比較します。
3

受け入れるか拒否する

計算されたdigestが一致すれば、Packは受け入れられ、resolve可能になります。一致しなければ、Packは拒否され、実行可能になることはありません。部分的なinstallも、黙った受け入れもありません。
これは、daily-price-watchを環境間で再現可能にする保証と同じものです（原則T3）。ミラー上でresolveされるものは、ソースで公開されたものとまったく同じhashになります。

​
差し替え可能なtransport

バイト列がどのように移動するかは、それがどのように検証されるかとは独立しています。transportは差し替え可能であり、バイト列がどのように到着したかに関係なく、検証は同じです。
Transport用途
HTTPS registry到達可能な2つのRegistry間で使う、デフォルトのネットワーク接続されたミラーです。
OCI registry既存のcontainer registry infrastructureを再利用してPackをhostします。
Object storageS3、GCS、または互換性のあるblob storeを通じてミラーリングします。
File bundleエアギャップ向けの自己完結型でdigest検証済みのbundleです。接続ゼロの境界を越えて運ばれます。
file-bundle pathはエアギャップデプロイの基盤です。Packをbundleにexportし、境界が許可する任意の手段でそれを境界の向こうへ移動し、内側でinstallします。そこでは、HTTPS経由の場合とまったく同じように到着時の検証が実行されます。export/install lifecycleについては、Air-gapped & on-premを参照してください。 
# エアギャップpath: 同じ検証、異なるtransport
browserflow pack export @acme/pricing@2.3.0 --out pricing.pack   # digest検証済みbundle
# ...pricing.packを境界の向こうへ移動...
browserflow install ./pricing.pack                               # 到着時に検証済み
シークレットは、複製されるどのartifactにも含まれて移動しません。daily-price-watch Flowのwebhookはsecret.WEBHOOK_URL参照のままです。宛先環境は実行時に自身のシークレットプロバイダーから値を供給し、ミラーから供給することはありません。

​
署名: 完全性の上に真正性を重ねる

digestは完全性を与えます。bodyが主張されたものと正確に同じである、ということです。署名は真正性を追加します。つまり、それを誰が公開したかの証明です。この2つは組み合わせられます。
  • publisherはPackManifestに署名できます。
  • Registryは、ミラーを受け入れる前に、信頼されたキーによる有効な署名を要求できます。
  • 署名はdigestの上に置かれます。完全性はdigestから、真正性は署名から得られます。
productionに供給するRegistryでは署名を要求してください。そうするとミラーは、Packが主張されたdigestにhashされ（完全性）、かつ信頼されたキーによる有効な署名を持つ（真正性）場合にのみ、そのPackを受け入れます。そのため、転送中にバイト列を置ける攻撃者でも、未署名または改ざんされたPackをresolveさせることはできません。

エアギャップデプロイ

Flowとそれに固定されたPackをネットワーク分離環境へ運び、接続ゼロで結果を再現します。

Pack

Packがどのようにversion付けされ、digest固定され、resolveされるかを説明します。これらは複製が移動するartifactです。

デプロイ

FlowのPackをRegistryへ公開し、その後、必要なLauncher上でFlowを公開します。

Registryを複製する

2つのRegistry間でPackをミラーリングする手順を順を追って説明します。