Metadata ve artifact veri katmanları

Veri ayrımı

Kullanıcı, yetki, repository/artifact metadata'sı, lifecycle, task, scan projection'ı, audit ve operasyon kayıtları PostgreSQL'de tutulur. Artifact dosyaları ile özgün SBOM byte'ları seçilen storage component'inde kalır; özgün SBOM'a erişim ayrı ViewRawSbom yetkisi ve audit kanıtı gerektirir.

Operasyon gereksinimi

İki veri katmanı için tutarlı fakat ayrı backup, restore, kapasite, sağlık ve erişim planı gerekir.

Tutarlılık modeli

PostgreSQL artifact'ın sahiplik, durum, checksum, boyut ve storage reference kaydını tutar; filesystem veya S3 ise byte içeriğini taşır. Bu iki katman aynı recovery noktasında uzlaştırılmadığında eksik metadata, orphan object veya indirilemeyen artifact oluşabilir.

PostgreSQL planı

Hedef ortam veritabanı sürümü, TLS, credential kaynağı, Flyway migration yetkisi, connection pool bütçesi, backup aralığı ve restore testini belgelemelidir. Replica sayısı arttıkça pool değerleri pod başına çarpılarak yönetim ve bakım bağlantıları için headroom bırakılmalıdır.

• Chart veritabanını kurmaz; dışarıdan yönetilen PostgreSQL ve önceden oluşturulmuş Secret bekler.
• Flyway migration durumu startup/health kanıtında kontrol edilmeli; uygulama rollout'u başarısız migration üzerinde trafik almamalıdır.
• Audit, Package Usage, Operation ve Outbound log tabloları aylık UTC partition kullanır; retention her tablo için ayrı yönetilir ve partition bakımı ortak PostgreSQL lease'i altında çalışır.

Storage planı

S3 için bucket, region, endpoint/path-style davranışı, credential rotasyonu, object lifecycle ve kapasite alarmı; filesystem için ortak mount, RWX semantiği, inode/alan takibi, permission ve archive dizini açıkça belirlenmelidir.

• Uygulama replica'larının aynı object key için aynı byte içeriğini görmesi
• Health/readiness kontrolünün hedef storage ve PostgreSQL kesintisini görünür kılması
• Büyük paket boyutu için ingress, temporary disk ve storage limitlerinin birlikte doğrulanması
• Cleanup archive ve storage transferi için kaynak/hedef kapasite ile geri dönüş sahipliği
• S3'e geçişte hedef component testi, ürünün storage-transfer akışı ve örnek paket okuması tamamlanmadan eski filesystem bağımlılığının kaldırılmaması

Support log storage sınırı

Artifact storage'dan ayrı olarak chart, varsayılan 20 GiB RWX support-log claim'i tanımlar. Her pod kendi dizinine yazar ve Support bundle görünür replica loglarını birleştirir. S3 artifact kurulumu da eksiksiz çoklu-replica bundle için bu küçük ortak claim'e ihtiyaç duyar; emptyDir kullanımı pod değişiminde kalıcılık ve birleştirme sağlamaz.

Backup ve restore sınırı

Kamuya açık, PostgreSQL, artifact storage ve ham SBOM verisini koordine eden tamamlanmış bir runbook henüz yoktur. Üretim onayı öncesinde kurum; yazmaları nasıl donduracağını, snapshot sırasını, secret/KMS erişimini, restore uzlaştırmasını ve örnek checksum doğrulamasını tarihli testle kanıtlamalıdır.

Kurtarma kabul ölçütleri

Restore sonrasında repository ve artifact sayıları, metadata durumu, storage reference, checksum ve örnek native-client indirmeleri uzlaştırılmalıdır. Task/audit geçmişinin erişilebilirliği ve yeni publish/scan/cleanup işlemlerinin çalışması ayrıca doğrulanmalıdır.

Kod ve canlı uygulama doğrulaması — 3 Ağustos 2026

Güncel 943c2c6 kaynak kodunda Flyway, JDBC session, PostgreSQL log partition'ları, gerçek write/delete yapan storage readiness probe'u, Local/S3 backend'leri, storage transferi ve support bundle uygulamaları incelendi; health/storage/lease/partition/support ve kimlik-proxy servislerini kapsayan hedefli backend suite'i 31/31 geçti. Canlı kubaba.s3t.co ortamında overall, readiness, liveness, database, migrations ve storage UP döndü; Local ve S3 component'leri ACTIVE/UP görüntülendi. Bu kanıt çalışan veri ve yönetim yüzeyini doğrular; koordineli backup/restore, boş ortama recovery, replica'lar arası checksum veya kapasite testini kanıtlamaz. Sayfa Değerlendirme rehberi olarak kalır.