Ölçekte Açık Kaynak DevOps: GitLab'i Kendiniz Çalıştırmak

Kaynak kod, neredeyse her teknoloji şirketinin kritik olduğu konusunda hemfikir olduğu tek varlıktır. Aynı zamanda çoğunun sahibi olmadığı bir altyapıda, kendi seçmediği bir yargı bölgesinde ve dikkatle okumadığı bir sözleşmeyle tuttuğu varlıktır. Bu düzen çoğu zaman sorun çıkarmaz. Yine de alternatifin neye mal olduğunu bilmekte fayda var, çünkü GitLab on yılı aşkın süredir tüm geliştirme yaşam döngüsünü kendi sunucularınızda barındırmayı gerçekten uygulanabilir kılıyor.

Üstelik ücretsiz katmanı çoğu kişinin beklediğinden daha cömert, işletme yükü ise beklenenden daha ağır bir ürün. İkisini de bağlanmadan önce anlamak gerekir. Bu rehber bu yüzden GitLab self-managed'ın gerçekte ne olduğunu, ücretsiz katmanın size gerçekte ne verdiğini ve sıkıntının büyük kısmını oluşturan üç işletme sorununu ele alıyor.

GitLab nedir

Üzerine ek özellikler iliştirilmiş bir Git barındırma hizmeti değildir. Bir Rails uygulaması, PostgreSQL, Redis, depo depolaması için Gitaly, arka plan işleri için Sidekiq ve bir container registry; hepsi kaynak kontrolü, kod incelemesi, iş takibi, CI/CD, paket ve container registry'leri, güvenlik taraması ve dağıtımı kapsayan tek bir sistem olarak paketlenmiştir.

Bütün argüman bu genişliktir. GitHub, Actions, Dependabot, bir paket registry'si ve bir proje takip aracı bir araya geldiğinde parçalardan kurulmuş benzer bir özellik seti elde edersiniz; GitLab ise tek izin modeli ve tek veritabanı olan tek bir uygulamadır. Bu ya tam olarak istediğiniz şeydir ya da ihtiyacınızdan fazlası. Hangisi olduğu, yaşam döngüsünün ne kadarını gerçekten tek bir yerde yürütmeyi düşündüğünüze bağlıdır.

Önemli mimari gerçek, analitiğinizi Matomo ile kendiniz barındırırken, pazarlama otomasyonunuzu Mautic ile ya da ekip içi yazışmanızı Mattermost ile yürütürken geçerli olanla aynıdır: onu nereye koyarsanız orada çalışır. Depolarınız, CI günlükleriniz, artefaktlarınız, veritabanınız.

Lisans durumu, açıkça

Bu konu gerçekten kafa karıştırıcıdır ve kesin olmaya değer, çünkü karışıklık insanların beklediğinin tam tersi yönde işler.

İki kaynak dağıtımı vardır. Community Edition MIT lisanslıdır. Enterprise Edition ise deponun ee/ dizinini kapsayan, daha kısıtlayıcı kendi lisansına sahiptir. Buraya kadar alışılmış open core düzenine benziyor.

İnsanları şaşırtan kısım şu: Neredeyse herkesin kurduğu Linux paketi Enterprise Edition derlemesidir ve lisans anahtarı girilmediğinde Community Edition gibi davranarak Free katmanı olarak çalışır. Bilerek CE paketini seçmediyseniz MIT lisanslı dağıtımı çalıştırmıyorsunuz demektir. Pratikte bu nadiren önem taşır; ancak kendi sunucunuzda barındırma gerekçeniz veri kontrolü değil de katı bir açık kaynak politikasıysa çok önemlidir ve neredeyse hiç kimse bunu kontrol etmez.

Ticari katmanlar şunlardır: Free, yıllık faturalandırmayla kullanıcı başına aylık 29 dolar olan Premium ve fiyatı talebe göre belirlenen Ultimate. Premium gelişmiş CI/CD, daha iyi proje yönetimi ve öncelikli destek ekler. Ultimate ise güvenlik ve uyumluluk paketini ekler: uygulama güvenlik testleri, tedarik zinciri güvenliği, bağımlılık taraması. Her iki ücretli katman şu anda yapay zeka özellikleri için GitLab Credits içeriyor: Premium'da kullanıcı başına aylık 12 dolar, Ultimate'ta 24 dolar. GitLab'in fiyatlandırma sayfası bu dahil kredileri, GitLab'in takdirine bağlı olarak değişebilecek, sınırlı süreli bir promosyon teklifi olarak tanımlıyor.

Çoğu ekip için hesabı değiştiren ve Mattermost'taki durumun tam tersi olan gerçek şu: self-managed kurulumda Free katmanın kullanıcı sınırı yoktur. Duyduğunuz beş kullanıcı sınırı yalnızca GitLab.com'daki özel gruplar için geçerlidir. Kendi sunucunuzdaki Free size sınırsız kullanıcı, kaynak kontrolü, CI/CD ve registry'ler verir; depolamayı ve runner'ları siz sağlarsınız. Yüz mühendisli bir kuruluş tamamen bunun üzerinde çalışabilir.

Vazgeçtikleriniz güvenlik taraması, uyumluluk raporlaması, gelişmiş onay kuralları ve destektir. Cyber Resilience Act kapsamındaysanız ve bağımlılık taramasıyla SBOM üretiminin ayrı araçlardan derlenmek yerine pipeline'larınıza yerleşik olmasını istiyorsanız, bu bir Ultimate konusudur. Diğer ekiplerin çoğu için Free bir deneme sürümü değildir. Kalıcı ve uygulanabilir bir çözümdür.

Kurulum

Küçük bir kurulum

GitLab göründüğünden ağırdır. Tek bir düğüm için belgelenen temel gereksinim 8 vCPU ve 16 GB RAM'dir ve çoğu üreticinin minimum değerlerinin aksine bu rakam iyimser değil, gerçekçidir. 8 GB'a sığdırılabilir ama farkı hissedersiniz. Swap kapalı olmalıdır, çünkü bu uygulamanın swap'e düşmesi bellek yetersizliğinden daha kötüdür.

Desteklenen tek veritabanı PostgreSQL'dir. Hangi sürüm olacağı GitLab sürümünüze bağlıdır: 17.x PostgreSQL 14.14 ile 16.x arasını, 18.x 16.5 ile 17.x arasını, 19.x ise 17.x ile 18.x arasını ister. Redis 7.2 önerilir, asgari sürüm 7.0'dır; Valkey 7.2 de yerine kullanılabilir. Yalnızca bağımsız (standalone) örnekler desteklenir; kümelenmiş ve sunucusuz Redis türleri desteklenmez.

Linux paketiyle kurun. Helm chart'ları, bir Operator, Docker imajları ve kaynaktan derleme yolu da var; ancak Linux paketi en olgun seçenektir ve GitLab.com'un kendisi de onun üzerinde çalışır. PostgreSQL, Redis ve Sidekiq'i birlikte getirir; yani tek bir makine ve tek bir yapılandırma dosyasıyla çalışan bir örneğe sahip olursunuz.

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

gitlab-ctl reconfigure komutunu çalıştırdığınızda bir örneğiniz olur. external_url değerini ilk seferde doğru ayarlayın, çünkü klonlama URL'lerine, webhook'lara ve registry adreslerine kalıcı olarak işlenir.

Üretim ortamı kurulumu

GitLab 1.000 ile 50.000 kullanıcı arasını kapsayan referans mimariler yayımlar. Hiçbirini uygulamayacak olsanız bile okumaya değerler, çünkü ilk önce hangi bileşenin darboğaz olacağını gösterirler.

En çok para kazandıran tavsiye GitLab'in kendisinden gelir ve karmaşıklığa karşı çıkar: 3.000 kullanıcının altında yüksek erişilebilirlik yerine sağlam bir yedekleme stratejisi önerirler. Belgeler bu konuda alışılmadık derecede açık sözlüdür; yedekleme yaklaşımının “does have a slower recovery time” (kurtarma süresinin daha uzun olduğunu) ama “means you have a much smaller architecture and less maintenance costs” (çok daha küçük bir mimari ve daha düşük bakım maliyeti anlamına geldiğini) belirtir. 3.000 kullanıcının üzerinde ya da bir kesintinin şirketi gerçekten durdurduğu durumlarda HA önerilen yol olur.

Bunu ciddiye alın. Düzgün yedeklenmiş ve geri yüklemesi test edilmiş tek bir düğüm, pratikte yarım anlaşılmış bir HA kümesinden daha güvenilirdir ve çok daha ucuzdur.

Artefaktları, yüklemeleri, LFS nesnelerini ve registry imajlarını en baştan nesne depolamaya taşıyın. Gerekçe her yerdekiyle aynı: düğümü durumsuz, yedekleri yönetilebilir ve taşımayı mümkün tutar.

Ters giden üç şey

Yukarıdaki her şey belgelerde var. Olaylara yol açanlar ise bunlar.

Yedeğiniz, onu çözen şeyi içermiyor

Bu makaledeki en önemli paragraf budur.

gitlab-backup create pek çok şeyi yakalar: veritabanı, depolar, LFS nesneleri, CI artefaktları ve iş günlükleri, registry imajları, wiki'ler, yüklemeler, Pages içeriği, Terraform durumu, snippet'ler. Yakalamadığı şey yapılandırma dizinidir, özellikle de /etc/gitlab/gitlab-secrets.json.

Bu dosya veritabanı şifreleme anahtarını tutar. Belgeler sonucunu açıkça söyler: “If you lose it, then the GitLab application will not be able to decrypt any encrypted values in the database.” (Bu dosyayı kaybederseniz GitLab uygulaması veritabanındaki şifrelenmiş hiçbir değeri çözemez.) Bu da CI/CD değişkenleri, token'lar, iki faktörlü kimlik doğrulama sırları ve entegrasyon kimlik bilgileri demektir. Elinizde, kendi sırlarını okuyamayan bir örneğe geri yüklenen bir yedek olur.

Kapsam dışında kalanlar ayrıca şunlardır: /etc/gitlab/gitlab.rb, TLS anahtarları ve sertifikaları, SSH host anahtarları ve nesne depolama yapılandırılmışsa nesne depolamanın içeriği. Sonuncusu, mimari açıdan doğru olanı yapıp ardından yedeğin bunu da kapsadığını varsayanları yakalar.

Bu yüzden /etc/gitlab dizinini ayrıca yedekleyin ve arşivin anahtarı olduğu için arşivin yanından başka bir yerde saklayın. Ardından her şeyi boş bir makineye geri yükleyip oturum açabildiğinizi ve bir CI değişkenini okuyabildiğinizi doğrulayın. Test edilmemiş bir geri yükleme yedek değildir; GitLab söz konusu olduğunda test edilmemiş bir geri yükleme genellikle bozuk bir geri yüklemedir.

Tek hamlede yükseltemezsiniz

GitLab'in zorunlu yükseltme durakları vardır ve bu bir tavsiye değildir. Bunları atlayamazsınız. 17.5'ten beri duraklar öngörülebilir: x.2, x.5, x.8 ve x.11 sürümlerine denk gelir. Dolayısıyla 18.0'dan 19.2'ye yükseltmek, önce 18.2, 18.5, 18.8 ve 18.11'de durmak anlamına gelir. 19.0 bir durak değildir, bu yüzden 18.11'den doğrudan 19.2'ye geçersiniz.

Her durak, bir sonrakine geçmeden önce tamamen bitmesi gereken arka plan geçişleri (background migrations) içerir. Geçişler hâlâ çalışırken sonraki yükseltmeye başlamak, örneklerin ancak destek ekibinin yardımıyla çözülebilecek durumlara düşmesinin yoludur. Büyük bir örnekte bu geçişler saatler sürebilir.

Bunun iki pratik sonucu var. Düzenli olarak yükseltin, çünkü bir yıl ertelenmiş yükseltme, art arda yapılacak yükseltmelerle geçen bir hafta sonu demektir. Ve hedef minor sürümün ilk değil, her zaman en son yama sürümünü alın; belgeler bunu açıkça belirtir. GitLab sırayı sizin için hesaplayan bir yükseltme yolu aracı sunar ve kendiniz akıl yürütmek yerine onu kullanmaya değer.

Asıl maliyet runner'larda

GitLab sunucusu CI işlerinizi çalıştırmaz. GitLab Runner, sizin sağladığınız altyapı üzerinde kurduğunuz, yapılandırdığınız ve parasını ödediğiniz ayrı bir bileşendir. Self-managed Free hiç işlem dakikası içermez, çünkü verilecek dahil bir işlem kapasitesi yoktur: makineleri siz getirirsiniz.

Bu genellikle iyi bir anlaşmadır; ciddi hacimlerde özel bir runner, barındırılan CI hizmetlerinden dakika başına daha ucuzdur ve bir derlemenin ihtiyaç duyduğu donanımı istediğiniz gibi bağlayabilirsiniz. Ama bu gerçek bir altyapı işidir. Executor'lar (shell, Docker ya da Kubernetes), runner'ların sabahın üçünde boşta beklememesi için otomatik ölçekleme ve dört dakikalık bir pipeline ile on dört dakikalık bir pipeline arasındaki farkı yaratan önbellekleme hakkında kararlar vereceksiniz.

Runner filosunu ayrı bir bütçe kalemi olarak planlayın. Kendi sunucusunda barındırmanın maliyetini yalnızca GitLab düğümüne bakarak modelleyen ekipler bunu büyük farkla eksik hesaplar, sonra açığı bekleyen işlerden oluşan bir kuyruk olarak fark eder.

GitHub'dan geçiş

GitHub içe aktarıcısı iyidir, çoğu üreticinin geçiş araçlarından belirgin biçimde daha iyidir. Depo verilerini, dalları, LFS nesnelerini, yorumları, incelemeleri ve tartışma yanıtlarıyla birlikte issue'ları ve pull request'leri, wiki sayfalarını, sürümleri ve ekleri, etiketleri, kilometre taşlarını, dal koruma kurallarını ve rol eşlemesiyle birlikte katkıda bulunanları aktarır.

Belgelenmiş eksikler için önceden plan yapmak gerekir. Organizasyonlar ve gruplar aktarılmaz; yani grup yapısını devralmak yerine siz tasarlarsınız ve bu genellikle bir iyileştirmedir. GitHub Actions iş akışları GitLab CI biçimine dönüştürülmez. 2017 öncesine ait pull request yorumları, GitHub API kısıtlamaları nedeniyle ayrı başlıklar olarak aktarılır; yaklaşık 30.000'den fazla yorumu olan depolar için alternatif yorum aktarma yönteminin etkinleştirilmesi gerekir.

GitHub hem issue'lar hem pull request'ler için # kullandığından, GitLab ise bunları birbirinden ayırdığından bazı çapraz başvurular çözümlenmez. Hiçbir şey kaybolmaz, ancak eski tartışmalardaki bağlantılar yanlış öğeyi gösterebilir.

CI yapılandırmasının yeniden yazılmasını asıl proje olarak planlayın, çünkü öyledir. Geri kalan her şey çalıştırıp kontrol edebileceğiniz bir içe aktarma işidir.

Avrupa boyutu

Avrupa'da faaliyet gösteren şirketler için maliyetin ötesinde bir uyumluluk boyutu vardır. Kaynak kod, derleme pipeline'ları ve artefaktlar bir teknoloji şirketinin elindeki en hassas varlıklar arasındadır ve bunların nerede durduğu, giderek sizin yanıtlamayı seçtiğiniz değil size sorulan bir soru hâline geliyor.

Kendi sunucunuzda barındırmak bunları sizin kontrol ettiğiniz bir sınırın içine yerleştirir. Bu da GDPR kapsamındaki aktarım analizini ve NIS2 tedarik zinciri sorularını tek hamlede basitleştirir; Cloud and AI Development Act'in dayandığı egemenlik argümanı da budur.

Daha keskin bağlantı Cyber Resilience Act ile kurulur. AB pazarına yazılım sunuyorsanız bağımlılık envanterlerine, güvenlik açığı yönetimine ve koordineli bir açıklama sürecine ihtiyacınız olacak. Bu yükümlülükler bir belgede değil, derleme pipeline'ınızda karşılanır. Pipeline'ın, registry'nin ve taramanın kendi işlettiğiniz tek bir sistemde olması, kanıtları üretmeyi dört farklı tedarikçiden derlemeye kıyasla çok daha az zahmetli hâle getirir.

Uğraşmaya değmediği durumlar

Yirmiden az mühendisiniz varsa, düzenleyici bir baskı yoksa ve kodun nerede durduğu konusunda güçlü bir tercihiniz yoksa SaaS kullanın. GitLab.com da GitHub da mükemmeldir ve işletme işi abonelikten daha pahalıya gelir.

Kuruluşunuz GitHub ekosisteminin derinliklerindeyse neler kaybedeceğinizi dürüstçe hesaplayın. Actions, marketplace ve platformun işe aldığınız her adayın aşina olduğu bir araç olması gerçek varlıklardır; cevap otomatik olarak GitLab'in kazanması değildir.

Ve örneğin sahipliğini kimse üstlenmeyecekse hiç başlamayın. GitLab, yamalarını uygulayan, runner filosunu izleyen ve geri yüklemeyi test eden bir sahibi ödüllendirir. O kişi olmadan, en değerli varlığınızı tutan yamasız bir makineye dönüşür; bu da kaçmaya çalıştığınız SaaS'tan daha kötüdür.

Destek almak

Avrupa'da çalışan şirketler için kendi sunucularında barındırılan geliştirme altyapısını kuruyor ve işletiyoruz; kimsenin sevmediği kısımlar da buna dahil: zorunlu duraklar boyunca yükseltme sıraları, düzgün otomatik ölçeklenen runner filoları, nesne depolama geçişleri ve gerçekten geri yüklenmiş yedekleme düzenleri.

Dürüstçe boyutlandırılmış bir GitLab örneği, CI yapılandırmasını daha önce yeniden yazmış birinin planladığı bir GitHub geçişi ya da mevcut yedeğinizin gerçek bir arızayla karşılaştığında ayakta kalıp kalmayacağının incelenmesini istiyorsanız office@c9group.dev adresine yazın. Altyapı çalışmalarımız hakkında daha fazlası AWS maliyet optimizasyonu sayfasında.

Kendi sunucunuzda eksiksiz bir yığın kuruyorsanız aynı mantık analitik, pazarlama otomasyonu ve ekip içi yazışma için de geçerlidir.

---

Yayımlanma: 8 Ağustos 2026 · Güncelleme: 10 Ekim 2026 Kategoriler: DevOps, Açık Kaynak, Gizlilik