Question 1

zot garbage collection이 'failed to remove signature in metaDB' 오류와 함께 실패하고 blobs가 전혀 삭제되지 않는 이유는 무엇인가요?

Accepted Answer

zot v2.1.21에서는 orphaned cosign 서명에 대해 `metaDB.DeleteSignature`가 `image meta not found`를 반환하면 `cleanRepo`가 리포지토리 전체를 중단시킵니다. 이 orphan은 GC 패스 중 인메모리에서 생성됩니다: `removeUntaggedManifests`가 인메모리 인덱스에서 서명의 subject를 삭제한 후, `removeReferrersWithMissingSubject`가 metaDB에 기록된 적 없는 서명을 삭제하려 시도합니다. 중단이 `PutIndexContent`와 `deleteUnreferencedBlobs` 이전에 발생하므로 어떤 blob도 해제되지 않고 오류가 매 패스마다 재발합니다(증상: 스토리지가 전혀 줄어들지 않고 `zot_gc_deleted_total`에 시리즈가 없음). **우회 방법:** GC 정책에서 `deleteReferrers: false`를 설정하세요 — 이렇게 하면 실패하는 분기를 건너뛰고 패스가 blob 삭제까지 진행됩니다. **수정:** v2.1.22+로 업그레이드하세요(PR #4500에서 수정됨). 이 버전에서는 삭제 경로에서 누락된 signature/repo 메타 레코드가 로그로 기록되고 성공으로 처리되어 기존 `syncManifestRemoval` 동작과 일치하므로, GC가 계속 진행되어 blob을 해제합니다.

Question 2

TLS 인증서 갱신 후 zot sync가 "x509: certificate signed by unknown authority" 오류로 실패하는 이유는 무엇인가요?

Accepted Answer

zot v2.1.20에서 sync 확장은 ca.crt를 읽은 다음 tls.crt로 덮어씁니다. getCertificates()가 연결(concatenation) 대신 할당(assignment)을 사용하기 때문입니다:

regCert = string(buf) // 버그: ca.crt가 tls.crt로 덮어써짐

os.ReadDir가 ca.crt를 tls.crt보다 먼저 반환하므로, sync 클라이언트는 결국 현재 leaf 인증서만 신뢰하게 됩니다. 해당 leaf가 갱신될 때, 동일한 CA에 의해 갱신되더라도 검증이 실패합니다. HTTP 클라이언트도 한 번만 생성되므로, 프로세스가 재시작될 때까지 오래된 인증서 풀이 유지됩니다.

즉각적인 우회 방법: 인증서를 갱신한 후 sync를 수행하는 zot 인스턴스를 재시작하십시오. 예를 들어:

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

영구 수정: 대체하는 대신 모든 PEM 블록을 누적하십시오:

regCert += string(buf)

이렇게 하면 클라이언트가 ca.crt의 CA를 신뢰하게 되므로, 해당 CA에 의해 갱신된 leaf 인증서가 계속 검증됩니다. 재시작 없이 CA rotation을 지원하려면, 기존 TlsConfigWatcher 또는 이에 상응하는 파일 감시 메커니즘을 사용하여 certDir의 파일이 변경될 때 sync 클라이언트의 TLS 구성도 다시 빌드하십시오.

Question 3

익명 접근이 활성화된 상태에서 zot registry에 docker push를 시도할 때 '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

OIDC 콜백에서 401과 함께 발생하는 zot OpenID 로그인 오류 "signature algorithm not supported"를 해결하는 방법은?

Accepted Answer

OIDC 공급자가 RS256, ES256 또는 PS256 이외의 알고리즘(예: PS512)으로 ID 토큰에 서명하는 경우 zot v2.1.22에 영향을 미칩니다. 근본 원인: `pkg/api/authn.go`의 `NewRelyingPartyOIDC`가 허용되는 서명 알고리즘을 전혀 구성하지 않아, zitadel/oidc가 RS256/ES256/PS256만으로 폴백하고 그 이외의 모든 경우에 `ErrSignatureUnsupportedAlg`를 반환합니다. 수정(코드 변경): relying party 옵션에 `rp.WithSigningAlgsFromDiscovery()`를 추가하여 zot가 발급자가 공표한 `id_token_signing_alg_values_supported`를 정확히 수락하면서도 발급자의 JWKS에 대해 서명을 계속 검증하도록 합니다. 수정된 릴리스가 제공될 때까지의 우회 방법: ID 토큰을 RS256, ES256 또는 PS256으로 서명하도록 ID 공급자를 재구성하십시오.

Question 5

sync extension이 활성화되어 있을 때 zot registry 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

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트