Question 1

zot のガベージコレクションが 'failed to remove signature in metaDB' で失敗し、blob が一切削除されないのはなぜですか？

Accepted Answer

zot v2.1.21では、孤立したcosign署名に対して`metaDB.DeleteSignature`が`image meta not found`を返すと、`cleanRepo`がリポジトリ全体の処理を中断します。この孤立はGCパス中にインメモリ上で作られます：`removeUntaggedManifests`が署名のサブジェクトをインメモリインデックスから削除し、その後`removeReferrersWithMissingSubject`がmetaDBに記録されていない署名を削除しようとします。中断は`PutIndexContent`と`deleteUnreferencedBlobs`より前に発生するため、blobは一切解放されず、エラーはパスのたびに再発します（症状：ストレージがまったく縮小せず、`zot_gc_deleted_total`にシリーズが存在しない）。**回避策：** GCポリシーで`deleteReferrers: false`を設定します — これにより失敗するブランチがスキップされ、パスがblob削除に到達できるようになります。**修正：** v2.1.22以降にアップグレードします（PR #4500で修正済み）。このバージョンでは、削除パスで署名/repoメタレコードが見つからない場合にログ出力され成功として扱われ、既存の`syncManifestRemoval`の動作と一致するため、GCが継続してblobを解放します。

Question 2

TLS証明書の更新後、zot sync が "x509: certificate signed by unknown authority" で失敗するのはなぜですか？

Accepted Answer

zot v2.1.20 では、同期拡張機能は ca.crt を読み取った後、それを tls.crt で置き換えます。これは getCertificates() が連結ではなく代入を使用しているためです:

regCert = string(buf) // バグ: ca.crt が tls.crt で上書きされる

os.ReadDir は ca.crt を tls.crt より先に返すため、同期クライアントは現在のリーフ証明書のみを信頼するようになります。そのリーフが更新されると、同じ CA による更新であっても、検証は失敗します。また、HTTP クライアントは一度しか作成されないため、プロセスが再起動するまで古い証明書プールが保持されます。

即時の回避策: 証明書を更新した後、同期を実行している zot インスタンスを再起動します。たとえば:

kubectl rollout restart deployment/<zot-sync-client>

恒久的な修正: 置き換えるのではなく、すべての PEM ブロックを蓄積します:

regCert += string(buf)

これにより、クライアントは ca.crt の CA を信頼するようになり、その CA によって更新されたリーフ証明書が引き続き検証に通ります。再起動なしで CA ローテーションをサポートするには、certDir 内のファイルが変更されたときに、既存の TlsConfigWatcher または同等のファイル監視メカニズムを使用して、同期クライアントの TLS 設定も再構築します。

Question 3

匿名アクセスが有効になっているのに、docker push to zot registryが'unauthorized: authentication required'で失敗するのはなぜですか？

Accepted Answer

これはzot v2.1.10以前における既知のバグで、匿名読み取りアクセス（anonymousPolicy: ["read"]）を有効にするとDocker CLIがプッシュ時の認証に失敗する原因となります。この問題はPR #3868および#3992で修正されました。zot v2.1.11以降にアップグレードしてください。一時的な回避策：匿名アクセスを無効にするか、不足している認証ヘッダーを追加するリバースプロキシ（例：zot-docker-proxy）を使用してください。

Question 4

zotのOpenIDログインでOIDCコールバック時に401とともに発生するエラー"signature algorithm not supported"を修正する方法

Accepted Answer

zot v2.1.22 は、OIDC プロバイダーが RS256、ES256、PS256 以外のアルゴリズム（例：PS512）で ID トークンに署名する場合に影響を受けます。根本原因: `pkg/api/authn.go` 内の `NewRelyingPartyOIDC` が受け入れ可能な署名アルゴリズムを一切設定していないため、zitadel/oidc は RS256/ES256/PS256 のみにフォールバックし、それ以外のアルゴリズムに対しては `ErrSignatureUnsupportedAlg` を返します。修正（コード変更）: Relying Party のオプションに `rp.WithSigningAlgsFromDiscovery()` を追加し、zot が issuer が公開している `id_token_signing_alg_values_supported` をそのまま受け入れるようにします。署名は引き続き issuer の JWKS に対して検証されます。修正版が利用可能になるまでの回避策: ID トークンの署名に RS256、ES256、または PS256 を使用するようにアイデンティティプロバイダーを再設定してください。

Question 5

sync拡張機能が有効になっている場合に、zotレジストリ v2.1.22でdocker pushが503 Service Unavailableで失敗するのはなぜですか？

Accepted Answer

zot v2.1.22 では、`content` プレフィックスを指定せずにオンデマンドミラーリング(例:Docker Hub)のために sync 拡張機能を有効にしている場合、プッシュ中に BuildKit が各マニフェストダイジェストに対して行う HEAD リクエストが、アップストリームレジストリからの同名リポジトリのオンデマンドプルもトリガーします。アップストリームが認証エラー(クリーンな 404 ではなく 401 unauthorized)を返した場合、zot はこのハードな sync 失敗を不透明な HTTP 503 にマッピングします(この動作は PR #4507 で導入され、#4480 を修正したものです)。回避策:1) zot v2.1.21 にダウングレードする。2) zot の config.json から `sync` ブロックを削除または無効化する。3) sync 設定に `content` プレフィックスを追加して、オンデマンド sync が特定のリポジトリパスにのみ適用されるようにし、プッシュの HEAD リクエストがアップストリームのプルをトリガーしないようにします。

zot

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト