GitLab Kurulumu ve Kendi Kod Deposu Platformunuz

Bir yazılım ekibinin kod deposundan yola çıkıp ürünü canlıya alana kadar dokunduğu araçları düşünün: git barındırma, kod inceleme, hata takibi, otomatik testler, paket kayıtları, dağıtım (deployment) ve izleme. Çoğu ekip bunların her biri için ayrı bir servise abone olur, sonra da bu servisleri birbirine yamalamakla uğraşır. GitLab bu dağınıklığı ortadan kaldırmak için tasarlanmış bir platform: git deposunu, merge request tabanlı kod incelemesini, dahili bir CI/CD boru hattını ve DevOps yaşam döngüsünün büyük bölümünü tek bir kurulumun altında toplar. Üstelik Community Edition (CE) sürümü tamamen açık kaynak ve ücretsizdir; kendi sunucunuza kurup verilerinizin tamamına siz sahip olabilirsiniz.

Bu rehberde GitLab CE'yi kendi sunucunuza nasıl kuracağınızı, hangi donanım kaynaklarına ihtiyaç duyacağınızı, CI/CD boru hatlarını çalıştıran runner'ları nasıl yapılandıracağınızı ve GitLab'ın Gitea gibi hafif alternatiflere kıyasla nerede parladığını, nerede fazla geldiğini kıdemli bir sistem yöneticisinin gözünden anlatacağım. Amacım size sadece komutları dizmek değil; hangi kararın hangi sonucu doğuracağını, üretim ortamında nelere dikkat etmeniz gerektiğini de göstermek. Kurulum yapacağınız makineyi henüz seçmediyseniz, ilerleyen bölümlerdeki kaynak tablosu doğru sunucu veya VDS tercihini yapmanıza yardımcı olacak.

GitLab Nedir ve Ne İşe Yarar#

GitLab, temelinde bir git barındırma sunucusudur; yani kod depolarınızı merkezî bir yerde tutar ve ekip üyelerinin git push / git pull ile senkron çalışmasını sağlar. Ancak GitLab'ı GitHub'ın ya da basit bir git sunucusunun ötesine taşıyan şey, yazılım geliştirme sürecinin neredeyse tamamını tek çatı altında birleştirmesidir. GitLab bunu "tek uygulama" (single application) felsefesiyle yapar; her modül aynı veritabanını ve aynı yetki modelini paylaşır.

Pratikte bir GitLab kurulumu size şunları verir: sınırsız özel ve genel depo, satır satır yorum yapılabilen merge request akışı, dahili sorun takibi (issues) ve kanban tarzı panolar (boards), yerleşik bir CI/CD motoru, Docker imajlarını saklayabileceğiniz bir container registry, npm/Maven/PyPI gibi paket kayıtları, wiki sayfaları ve dağıtım ortamları yönetimi. Bunların hepsi tek bir arayüzden erişilebilir ve tek bir kullanıcı hesabıyla çalışır.

GitLab iki ana dağıtımda gelir. Community Edition (CE) MIT lisanslıdır, açık kaynaktır ve çoğu ekibin ihtiyacını karşılar. Enterprise Edition (EE) ise CE'nin üzerine ücretli katmanlar ekler (gelişmiş rol yönetimi, portföy planlaması, güvenlik taramaları vb.). İyi haber şu: EE paketini kurup lisans girmezseniz bile o kurulum tıpatıp CE gibi davranır; yani ileride Premium'a geçmeyi düşünüyorsanız baştan EE Omnibus paketini kurup ücretsiz özelliklerle kullanabilirsiniz. Bu rehberde biz CE üzerinden ilerleyeceğiz çünkü kendi altyapısını yöneten ekiplerin büyük çoğunluğu için fazlasıyla yeterlidir.

Kaynak Gereksinimleri ve Sunucu Seçimi#

GitLab'ın hakkını teslim etmek gerekir: güçlü olduğu kadar da kaynak açlığı yüksek bir uygulamadır. Tek bir Omnibus kurulumu içinde PostgreSQL, Redis, Nginx, Puma (uygulama sunucusu), Sidekiq (arka plan işleri) ve Gitaly (git deposu servisi) gibi bir sürü bileşen aynı anda çalışır. Bu yüzden "eski bir VPS'te dener geçerim" yaklaşımı sizi hüsrana uğratır; GitLab en az 4 GB RAM ile rahat nefes alır.

Aşağıdaki tablo kullanıcı sayısına göre kaba bir yönlendirme sunar. Bunlar minimumdan biraz üstte, konforlu değerlerdir:

Birkaç önemli not. Birincisi, swap alanı GitLab için hayat kurtarır; en azından 2 GB swap tanımlayın, çünkü kurulum ve güncelleme sırasında bellek tüketimi ani sıçramalar yapar. İkincisi, disk olarak mutlaka SSD/NVMe kullanın; git işlemleri ve CI iş akışları çok sayıda küçük dosya okuma-yazma yapar, dönen disk (HDD) performansı yerlerde sürünür. Üçüncüsü, RAM'i kısarsanız GitLab çalışır ama arayüz yavaşlar ve Sidekiq kuyrukları birikir.

Uzun vadede depo sayınız ve CI çıktılarınız büyüdükçe disk ihtiyacınız artacaktır. Bu yüzden diski kolayca genişletebileceğiniz bir sanal sunucu ya da VDS planı seçmek, fiziksel bir kutuya sıkışmaktan daha esnektir. Sunucunun işletim sistemi tarafındaki güncelleme, güvenlik yaması ve yedekleme yükünü kendiniz taşımak istemiyorsanız sunucu yönetimi hizmetini de değerlendirebilirsiniz. Kurulumdan önce diskin durumunu hızlıca kontrol etmek iyi bir alışkanlıktır:

# Bellek, swap ve disk durumunu kontrol et
free -h
df -h /
nproc            # kullanılabilir çekirdek sayısı

Omnibus ile GitLab CE Kurulumu#

GitLab'ı kurmanın en sağlıklı yolu Omnibus paketidir. Omnibus, GitLab'ın ihtiyaç duyduğu tüm bileşenleri (PostgreSQL, Redis, Nginx, Ruby çalışma zamanı vb.) tek bir .deb / .rpm paketine gömer. Yani sisteminizdeki mevcut PostgreSQL veya Nginx ile çakışmaz; her şey /opt/gitlab altında izole çalışır. Bu, elle bağımlılık derdine girmeden bakımı çok kolaylaştırır. (Docker ile kurmayı tercih edenler için konteyner mantığını Docker nedir başlangıç rehberimizde bulabilirsiniz; ancak üretimde Omnibus daha oturmuş bir yoldur.)

Ubuntu 22.04/24.04 üzerinde tipik bir kurulum şöyle ilerler. Önce bağımlılıkları ve postfix'i (bildirim e-postaları için) kurarız:

sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl

# Bildirim e-postaları için postfix (internet sitesi olarak yapılandır)
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y postfix

Ardından GitLab'ın resmi deposunu ekler ve paketi kurarız. Buradaki kritik nokta EXTERNAL_URL değişkenidir: bu, GitLab'ın kendini hangi adreste sunacağını belirler ve https:// yazarsanız Omnibus sizin için otomatik olarak Let's Encrypt sertifikası almaya çalışır.

# GitLab CE deposunu ekle
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

# EXTERNAL_URL ile kur (https yazınca Let's Encrypt devreye girer)
sudo EXTERNAL_URL="https://git.ornekalanadi.com" apt-get install -y gitlab-ce

Kurulum birkaç dakika sürer çünkü ilk reconfigure adımında tüm servisler ayağa kaldırılır. İşlem bitince GitLab'ın ana yapılandırma dosyası /etc/gitlab/gitlab.rb olacaktır. Bu dosyada bir değişiklik yaptığınızda değişikliğin uygulanması için mutlaka reconfigure çalıştırmanız gerekir:

# gitlab.rb dosyasını düzenledikten sonra her seferinde:
sudo gitlab-ctl reconfigure

# Servislerin durumunu gör
sudo gitlab-ctl status

# İlk root parolasını al (24 saat sonra bu dosya silinir)
sudo cat /etc/gitlab/initial_root_password

İlk girişten hemen sonra iki şeyi yapın: root hesabının parolasını değiştirin ve Admin Area → Settings → Sign-up restrictions altından açık kayıtları kapatın. Aksi halde GitLab örneğiniz internete açıksa tanımadığınız kişiler hesap açabilir. Alan adınız yoksa veya yeni bir alan adı almak istiyorsanız domain kayıt sayfamızdan git. alt alan adı için uygun bir isim ayırtabilirsiniz. Sertifika tarafında Omnibus otomatik Let's Encrypt hallediyor olsa da, kurumsal bir yapıda organizasyon doğrulamalı bir SSL sertifikası tercih etmek isteyebilirsiniz.

Depo, Merge Request ve Kod İnceleme Akışı#

GitLab'ın kalbi elbette git depolarıdır. Arayüzden New project diyerek boş bir depo açtığınızda size klonlama adresleri verilir. SSH anahtarınızı Preferences → SSH Keys altına ekledikten sonra çalışmaya başlayabilirsiniz:

# Yeni bir depoyu SSH ile klonla
git clone [email protected]:ekip/proje.git
cd proje

# Bir özellik dalı aç, değişiklik yap ve gönder
git checkout -b ozellik/kullanici-profili
git add .
git commit -m "Kullanıcı profili sayfası eklendi"
git push -u origin ozellik/kullanici-profili

İşte burada GitLab'ın en sevilen özelliği devreye girer: Merge Request (MR). Bir özellik dalını main dalına birleştirmek istediğinizde doğrudan merge yapmak yerine bir MR açarsınız. MR, o dala ait tüm commit'leri, satır satır kod farklarını (diff), yapılan tartışmaları ve CI boru hattının sonuçlarını tek bir sayfada toplar. Ekip arkadaşlarınız kodun herhangi bir satırına yorum bırakabilir, değişiklik isteyebilir ve onay verebilir. GitHub'daki pull request'in karşılığıdır ve iş akışı neredeyse aynıdır.

Üretime giden main gibi dalları korumaya almak, disiplinli bir ekip için olmazsa olmazdır. Settings → Repository → Protected branches altından main dalına doğrudan push yapılmasını yasaklayıp yalnızca MR üzerinden ve belirli sayıda onaydan sonra birleştirmeye izin verebilirsiniz. Böylece hiç kimse gözden geçirilmemiş kodu doğrudan üretim dalına gönderemez. Bu yaklaşım, hata oranını ciddi biçimde düşürür ve kod tabanının kalitesini korur.

CI/CD Boru Hatlarını Anlamak: .gitlab-ci.yml#

GitLab'ı sıradan bir git sunucusundan ayıran en güçlü özellik, hiç kuşkusuz dahili CI/CD motorudur. Deponuzun köküne .gitlab-ci.yml adında bir dosya koyduğunuz anda, her push işleminde otomatik olarak bir boru hattı (pipeline) tetiklenir. Bu boru hattı, tanımladığınız aşamaları (stages) sırayla çalıştırır: kod derlenir, testler koşar, güvenlik taraması yapılır ve sonunda dağıtım gerçekleşir.

Boru hattının mantığı basittir: stages ile aşamaların sırasını tanımlarsınız, ardından her işi (job) bir aşamaya atarsınız. Aynı aşamadaki işler paralel, farklı aşamalardaki işler sıralı çalışır. Aşağıda tipik bir Node.js projesi için sade bir örnek var:

# .gitlab-ci.yml — üç aşamalı basit bir boru hattı
stages:
  - build
  - test
  - deploy

# Tüm işler bu Docker imajında koşar
default:
  image: node:20-alpine

kurulum_ve_derleme:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/          # Sonraki aşamalara taşınacak çıktı
    expire_in: 1 hour

birim_testleri:
  stage: test
  script:
    - npm ci
    - npm run test

canliya_al:
  stage: deploy
  script:
    - echo "Üretim sunucusuna dağıtım yapılıyor..."
    - ./scripts/deploy.sh
  only:
    - main             # Yalnızca main dalında çalışır
  environment:
    name: production

Bu dosya sayesinde her merge request'te testler otomatik koşar; testler geçmeden MR'ın yeşil ışık almaması sağlanabilir. only: main ile dağıtım işini yalnızca main dalına birleştirildiğinde tetiklersiniz; böylece özellik dalları test edilir ama üretime gitmez. artifacts bloğu bir aşamada üretilen dosyaları (örneğin derlenmiş dist/ klasörünü) sonraki aşamalara taşır. Değişkenleri (veritabanı parolası, API anahtarı gibi) ise dosyaya yazmak yerine Settings → CI/CD → Variables altında maskeli olarak saklarsınız; böylece hassas bilgiler depo geçmişine sızmaz.

GitLab Runner Kurulumu ve Yapılandırması#

CI/CD boru hatları kendi başlarına çalışmaz; onları gerçekten koşturan şey GitLab Runner adı verilen ajanlardır. Runner, GitLab sunucusundan "çalıştırılacak bir işim var mı?" diye sorar, iş varsa alır, çalıştırır ve sonucu geri bildirir. Runner'ı GitLab'ın kurulu olduğu makineye de kurabilirsiniz, ama üretimde ayrı bir makineye kurmak çok daha sağlıklıdır; çünkü ağır CI işleri GitLab sunucusunun kaynaklarını tüketip arayüzü yavaşlatmasın istersiniz.

Runner'ı kurmak için önce paketi yükler, sonra GitLab örneğinize kaydedersiniz. Kayıt sırasında GitLab arayüzünden aldığınız bir registration token kullanılır (Admin Area → CI/CD → Runners):

# GitLab Runner deposunu ekle ve kur
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt-get install -y gitlab-runner

# Runner'ı GitLab örneğine kaydet (Docker executor önerilir)
sudo gitlab-runner register \
  --non-interactive \
  --url "https://git.ornekalanadi.com" \
  --token "GRAT-xxxxxxxxxxxxxxxxxxxx" \
  --executor "docker" \
  --docker-image "alpine:latest" \
  --description "birincil-docker-runner"

Buradaki en önemli karar executor seçimidir; runner'ın işleri nasıl çalıştıracağını belirler. En çok tercih edileni docker executor'dır: her iş temiz, izole bir konteynerde koşar, iş bitince konteyner silinir. Böylece bir işin ortamı diğerini kirletmez ve "bende çalışıyordu" sorunları büyük ölçüde ortadan kalkar. Executor seçeneklerini kısaca karşılaştıralım:

Docker executor kullanacaksanız runner makinesinde Docker'ın kurulu olması gerekir; konteyner temellerini Docker başlangıç rehberimizde bulabilirsiniz. Kayıt tamamlandıktan sonra sudo gitlab-runner status ile ajanın çalıştığını doğrulayın. Artık GitLab arayüzünde bir boru hattı tetiklendiğinde işlerin bu runner tarafından alınıp koşulduğunu göreceksiniz. İhtiyaca göre birden fazla runner ekleyip tags ile belirli işleri belirli runner'lara yönlendirebilirsiniz (örneğin gpu etiketli işler yalnızca GPU'lu makinede koşsun).

Yedekleme, Bakım ve Güvenlik#

Kendi GitLab sunucunuzu işletmenin bedeli, bakımını da üstlenmenizdir. En kritik konu düzenli yedeklemedir. GitLab, depoları, veritabanını ve yüklenen dosyaları tek komutla yedekleyen dahili bir araçla gelir. Ancak dikkat: bu yedek dosyası uygulama verisini içerir ama /etc/gitlab altındaki gizli anahtarları ve yapılandırmayı içermez; onları ayrıca yedeklemeniz gerekir, aksi halde geri yükleme sırasında şifreli veriler açılamaz.

# Uygulama verisini yedekle (depolar, DB, yüklemeler)
sudo gitlab-backup create

# Kritik: yapılandırma ve gizli anahtarları ayrıca yedekle
sudo cp -r /etc/gitlab /yedek/gitlab-config-$(date +%F)

# Otomatik günlük yedek için crontab örneği (her gece 02:00)
# 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1

Yedeklerin yalnızca sunucuda durması yeterli değildir; sunucunun kendisi çökerse yedek de gider. Bu yüzden yedekleri farklı bir konuma (harici bir depolama alanına veya ayrı bir sunucuya) kopyalamak şarttır. Bu süreci elle takip etmek istemiyorsanız düzenli ve dış konuma alınan yedekleme hizmetimiz sizi olası bir veri kaybından korur. GitLab'ı yeni bir sunucuya taşımanız gerekirse (donanım yükseltme, sağlayıcı değişikliği vb.) site taşıma ekibimiz bu geçişte yardımcı olabilir.

Güvenlik tarafında birkaç temel kural: SSH erişimini anahtar tabanlı yapın ve parola girişini kapatın, GitLab'ın önüne bir güvenlik duvarı koyup yalnızca 80/443 (ve gerekiyorsa SSH) portlarını açın, root hesabında iki adımlı doğrulamayı (2FA) mutlaka etkinleştirin. GitLab'ı sürekli güncel tutun; güvenlik yamaları düzenli çıkar ve sudo apt-get update && sudo apt-get install gitlab-ce ile yükseltme yaparsınız (büyük sürüm atlamalarında ara sürümlerden geçmeniz gerektiğini unutmayın). Kurumsal bir kurulumda kaba kuvvet ve bot trafiğine karşı bir WAF katmanı ve hacim tabanlı saldırılara karşı DDoS koruma devreye almak, örneğinizi internete açtığınızda kendinizi çok daha rahat hissettirir.

GitLab mı Gitea mı: Doğru Aracı Seçmek#

GitLab güçlüdür ama bu güç her ekip için doğru tercih olduğu anlamına gelmez. Eğer tek ihtiyacınız birkaç geliştiricinin özel depolarını barındırmaksa ve ağır bir CI/CD altyapısına gereksiniminiz yoksa, GitLab fazla gelebilir; o zaman Gitea gibi hafif bir alternatif çok daha mantıklıdır. Gitea, Go dilinde yazılmış, tek bir ikili dosyayla çalışan, 512 MB RAM'li bir sunucuda bile rahat nefes alan minimalist bir git barındırma çözümüdür. Ayrıntılı karşılaştırma için Gitea nedir yazımıza göz atmanızı öneririm.

İki platformu somut kriterlerle karşılaştıralım:

Kural olarak şunu söyleyebilirim: eğer CI/CD boru hatları, ortam yönetimi, güvenlik taramaları ve entegre bir DevOps yaşam döngüsü işinizin merkezindeyse GitLab'ın sunduğu bütünlük paha biçilmezdir ve harcadığı kaynağa değer. Ama amacınız yalnızca kodu güvenle saklamak, birkaç kişiyle inceleme yapmak ve arada bir basit bir betik koşturmaksa, Gitea'nın sadeliği ve düşük maliyeti sizi çok daha az yorar. İkisini birden denemek de mümkündür; her ikisi de App Center mantığında kolayca kurulabilen, kendi kendine barındırılan (self-hosted) çözümlerdir.

Sıkça Sorulan Sorular#

GitLab CE ile EE arasındaki fark nedir?#

Community Edition tamamen açık kaynak ve ücretsizdir; git barındırma, merge request, CI/CD, container registry gibi çekirdek özelliklerin hepsini içerir ve çoğu ekibin ihtiyacını fazlasıyla karşılar. Enterprise Edition ise bunların üzerine ücretli katmanlar (gelişmiş rol yönetimi, portföy planlaması, otomatik güvenlik taramaları, öncelikli destek) ekler. İlginç olan, EE paketini kurup lisans girmezseniz kurulumun aynen CE gibi davranmasıdır; bu yüzden ileride Premium'a geçme ihtimaliniz varsa baştan EE Omnibus paketini ücretsiz özelliklerle kullanmak akıllıcadır.

Kurulum için ne kadar RAM gerekir?#

GitLab, kaynak açlığı yüksek bir uygulamadır ve en az 4 GB RAM ile rahat çalışır. Tek bir Omnibus kurulumunun içinde PostgreSQL, Redis, Nginx, Puma, Sidekiq ve Gitaly gibi çok sayıda servis aynı anda koştuğu için daha az bellekle çalıştırmaya kalkarsanız arayüz yavaşlar ve arka plan iş kuyrukları birikir. Buna ek olarak en az 2 GB swap alanı tanımlamak, kurulum ve güncelleme sırasındaki ani bellek sıçramalarında sizi kurtarır. 20 kişilik bir ekibin üzerine çıkıyorsanız 8 GB RAM'e geçmeniz konforlu olur.

GitLab Runner'ı aynı sunucuya kurabilir miyim?#

Teknik olarak evet, runner'ı GitLab'ın kurulu olduğu makineye de kurabilirsiniz. Ancak üretim ortamında bunu önermiyorum; çünkü ağır CI/CD işleri (derleme, test, Docker imajı oluşturma) sunucunun CPU ve belleğini tüketip GitLab arayüzünü ve git işlemlerini yavaşlatır. Doğru yaklaşım, runner'ı ayrı bir makineye kurmak ve mümkünse Docker executor kullanarak her işi izole bir konteynerde çalıştırmaktır. Böylece CI yükü GitLab sunucusundan tamamen ayrışır ve iki sistem birbirini etkilemez.

Verilerimi nasıl yedeklerim?#

GitLab, depoları, veritabanını ve yüklenen dosyaları tek komutla yedekleyen gitlab-backup create aracıyla gelir. Ancak bu yedek dosyası uygulama verisini içerir, /etc/gitlab altındaki gizli anahtarları ve yapılandırmayı içermez; bu yüzden o dizini ayrıca yedeklemeniz şarttır, aksi halde geri yükleme sırasında şifreli veriler açılamaz. Yedeklerin yalnızca sunucuda durması da yetmez; sunucu çökerse yedek de gider. Bu nedenle yedekleri düzenli olarak harici bir konuma kopyalamalı, ideal olarak bu işi otomatik bir cron göreviyle veya harici bir yedekleme hizmetiyle yürütmelisiniz.

GitLab yerine Gitea kullanmalı mıyım?#

Bu tamamen ihtiyacınıza bağlıdır. Eğer CI/CD boru hatları, ortam yönetimi, kapsamlı paket kayıtları ve entegre bir DevOps yaşam döngüsü işinizin merkezindeyse GitLab'ın sunduğu bütünlük paha biçilmezdir. Ama tek ihtiyacınız birkaç geliştiricinin depolarını güvenle barındırmak, sade kod incelemesi yapmak ve düşük kaynaklı bir sunucuda çalışmaksa, Go diliyle yazılmış ve 512 MB RAM'de bile rahat koşan Gitea sizi çok daha az yorar ve çok daha az maliyet çıkarır. Kararsızsanız her ikisini de deneyip ekibinizin çalışma tarzına hangisinin oturduğuna bakabilirsiniz.

Kapanış#

GitLab, kod deposundan üretime kadar uzanan yazılım geliştirme sürecinin tamamını tek bir platformda toplayan, olgun ve güçlü bir DevOps çözümüdür. Omnibus paketiyle kurulumu düşündüğünüzden daha kolaydır; asıl işiniz, doğru kaynağa sahip bir sunucu seçmek, runner'ları düzgün yapılandırmak ve yedekleme ile güvenliği ihmal etmemektir. Bu üç ayağı sağlam kurarsanız, kendi verilerinize tam hâkim, dışa bağımlı olmayan bir geliştirme altyapısına kavuşursunuz. İhtiyacınız daha sadeyse Gitea'nın hafifliği de her zaman elinizin altında.

Kendi GitLab veya Gitea sunucunuzu ayağa kaldırmaya hazırsanız, ilk adım doğru altyapıyı seçmektir. Yüksek performanslı VDS ve sanal sunucu planlarımız GitLab'ın kaynak ihtiyacını rahatça karşılar; kurulum, güncelleme ve güvenlik yükünü bize bırakmak isterseniz sunucu yönetimi hizmetimizle ilgilenebilir, veri güvenliğiniz için yedekleme çözümümüzü ekleyebilirsiniz. Ekibinizin kod deposunu bugün kendi sunucunuza taşıyın; kontrol tamamen sizde olsun.