GitLab Container Registry, GitLab projeleriyle entegre çalışan container image deposudur. CI/CD pipeline’ı image üretir, registry’ye gönderir ve Kubernetes ya da başka bir çalışma ortamı bu image’ı çekerek dağıtım yapar.
Karar genellikle iki seçenek arasında verilir: GitLab’ın yerleşik registry’si yeterli mi, yoksa Harbor gibi bağımsız bir registry mi gerekir? Bu seçim yalnızca özellik listesine göre değil; erişim modeli, depolama büyümesi, imaj güvenliği ve işletme kapasitesi birlikte değerlendirilerek yapılmalıdır.
GitLab Registry neyi iyi çözer?
GitLab Registry’nin en güçlü yanı GitLab projesine yakın olmasıdır:
- Image, kaynak kodun bulunduğu proje bağlamında saklanır.
- Pipeline ile build/push/pull akışı doğal şekilde bağlanır.
- Proje ve grup erişim modeli registry kullanımına da yansır.
- GitLab arayüzünden image ve tag görünürlüğü sağlanır.
- Küçük ve orta ölçekli ekipler ayrı registry işletmeden başlayabilir.
Bu yaklaşım, “her şey GitLab içinde kalsın” diyen ekipler için pratiktir. Ancak registry kullanımı büyüdükçe GitLab sunucusunun storage ve bakım tasarımının parçası haline gelir.
Self-managed kurulumda sorumluluklar
GitLab.com kullanırken altyapının önemli bölümü servis sağlayıcıdadır. Self-managed GitLab’da ise registry sizin ortamınızda çalışır. Bu durumda şu başlıklar canlıya çıkmadan netleşmelidir:
- Container Registry instance üzerinde etkin mi?
- Image storage local disk mi, object storage mı?
- Repository, artifact ve registry storage birbirinden ayrılıyor mu?
- Eski tag’ler için temizlik politikası var mı?
- Yedek ve geri dönüş testi registry image’larını da kapsıyor mu?
- Çok mimarili image, imza gösterimi veya metadata database gerektiren özellikler kullanılacak mı?
- Registry trafiği için TLS, proxy ve rate limit kararları verildi mi?
Registry storage plansız bırakılırsa disk dolması yalnızca image push işlemini değil, GitLab’ın genel sağlığını da etkileyebilir.
Temizlik politikası neden satın alma konusudur?
Container image’lar hızlı büyür: her merge request, her branch ve her release yeni tag üretebilir. “latest” kullanımı tek başına temiz bir release modeli sağlamaz. Pratik bir politika şunları içermelidir:
- Release tag’leri korunur.
- Branch ve merge request tag’leri belirli süreden sonra silinir.
- Son başarılı build’lerden belirli sayı tutulur.
- Production’da çalışan image asla otomatik silinmez.
- Kritik base image’lar ve imzalı image’lar ayrı tutulur.
Bu politika teknik olduğu kadar yönetişim konusudur: Hangi image’ın silinebileceğine geliştirme, güvenlik ve operasyon ekipleri birlikte karar vermelidir.
GitLab Registry vs Harbor
| Karar alanı | GitLab Registry | Harbor |
|---|---|---|
| Başlangıç | GitLab kullanan ekip için daha hızlı | Ayrı kurulum ve operasyon ister |
| Erişim modeli | GitLab proje/grup yapısına yakın | Bağımsız registry ve proje modeli |
| Çoklu platform | GitLab merkezli akışlarda yeterli olabilir | Çoklu cluster, çoklu CI/CD ve merkezi registry için güçlü |
| Güvenlik/yönetişim | Plan ve yapılandırmaya bağlı | İmzalama, replikasyon ve policy odaklı kullanımda güçlü |
| Operasyon | GitLab operasyonunun parçası | Ayrı servis olarak yönetilir |
Harbor daha gelişmiş göründüğü için her durumda seçilmemelidir. Eğer tüm akış GitLab içinde kalıyor ve bağımsız registry yönetişimi gerekmiyorsa GitLab Registry daha yalın olabilir. Ancak birden fazla cluster, birden fazla Git platformu veya merkezi image yönetişimi varsa Harbor değerlendirilmelidir.
Güvenlik taraması ayrı karardır
Registry image saklar; image güvenliği için ayrıca scanning, imzalama, base image standardı ve deploy policy gerekir. GitLab tarafında Container Scanning gibi özellikler plan ve yapılandırmaya göre değerlendirilir. Bu özellikleri GitLab Registry ile karıştırmamak gerekir.
Somut kontroller:
- Base image kaynağı standart mı?
- Kritik CVE bulunduğunda deploy duracak mı?
- Image digest ile deploy yapılıyor mu?
- Production image’ları kim silebilir?
- Registry erişimi robot token ve insan kullanıcılar için ayrıldı mı?
Resmi kaynaklar
- GitLab’ın yerleşik registry dokümanı: GitLab Container Registry
- Plan ve özellik karşılaştırması: GitLab Pricing
- Bağımsız registry alternatifi için Harbor documentation
Mono ne zaman yardımcı olur?
- GitLab Registry / Harbor karar analizi
- Self-managed registry storage ve object storage tasarımı
- Tag ve cleanup policy standardı
- Container Scanning ve image imzalama değerlendirmesi
- Kubernetes pull secret ve deploy akışı tasarımı
- Registry yedekleme ve geri dönüş testi
