VPS’te GitLab ve Jira: Kaynak Planlama ve Güvenlik

Self-hosted DevOps araçlarını VPS’te barındırmak

Bir yazılım ekibinin kalbi artık sadece uygulama sunucusunda değil; kaynak kodunun tutulduğu Git sunucusunda, işlerin takip edildiği proje yönetim aracında ve CI/CD boru hatlarında atıyor. GitLab, Jira, Jenkins, SonarQube, container registry, artifact depoları… Tüm bu DevOps ekosistemini dış servislere yaymak yerine, kontrollü bir şekilde kendi VPS altyapınızda toplamak; veri yerleşimi, erişim politikaları ve şirket içi entegrasyonlar üzerinde daha fazla kontrol sağlayabilir. Ancak KVKK/GDPR uyumu ve güvenlik, yalnızca self-hosting tercihinden doğmaz; veri işleme süreçleri, sözleşmeler ve işletim kontrolleri de gerekir. Maliyet planına lisans, yedekleme ve bakım emeğini de katmalısınız.

Bu rehber GitLab Self-Managed ve mevcut lisansla kullanılan Jira Software Data Center için CPU, RAM, depolama, ağ, erişim ve kurtarma kararlarını ele alır. 4 Kasım 2026 kapsamı: Jira Server ve Bitbucket Server desteği 15 Şubat 2024’te bitti. Jira Software Data Center için yeni müşterilere satış 30 Mart 2026’da kapandı; mevcut müşteriler yeni abonelik ve kapasite artışlarını 30 Mart 2028’e kadar alabiliyor. Olağan yaşam sonu 28 Mart 2029; abonelik sona erince ürün salt okunur hâle geliyor. Özel uzatma ancak Atlassian’ın müşteri bazında kabul ettiği istisnalara bağlı. Atlassian’ın güncel takvimini ve sözleşmenizi esas alın; burada yeni, küçük bir ekip için Jira Data Center satın alma önerisi yapılmıyor. Mevcut uygun lisansı olmayan ekipler GitLab issue takibini, Jira Cloud’u veya başka bir aracın güncel self-hosted sürümünü değerlendirebilir.

Hangi DevOps araçlarını VPS’te self-host etmek mantıklı?

Önce hangi bileşenleri gerçekten kendi altyapınızda çalıştırmak istediğinizi netleştirelim. Tipik bir ekip için self-host edilen DevOps araçları şöyle görünebilir:

• Kaynak kod yönetimi: GitLab, Gitea; Atlassian tarafında güncel self-managed ürün Bitbucket Data Center. Bitbucket ve Bamboo Data Center, Jira’nın 2029 yaşam sonu kapsamı dışında ve Hybrid lisans yoluyla devam ediyor.
• Proje ve issue takibi: Uygun mevcut abonelikle Jira Software Data Center; ayrıca lisans ve sürüm koşulları doğrulanacak YouTrack, Redmine vb.
• CI/CD: GitLab CI, Jenkins, GitHub Actions runner’ları, diğer self-host runner’lar.
• Container/artefact: Docker registry, Maven/NPM/Composer repository, artifact depoları.
• Kalite ve güvenlik: SonarQube, SAST/DAST araçları, dependency check platformları.
• Gözlemlenebilirlik: Log ve metrik toplama, dashboard ve alarm sistemleri.

Bu listedeki her aracı aynı VPS’e yığmak zorunda değilsiniz. Örneğin GitLab ile ayrı bir runner VPS’iyle başlayabilir; uygun mevcut Jira lisansınız varsa Jira için ayrıca uygulama ve veritabanı kaynakları planlayabilirsiniz. Benzer kapasite planlama mantığı, yüksek trafikli web projeleri için de geçerli; örneğin WooCommerce, Laravel ve Node.js’de doğru VPS kaynaklarını seçme rehberinde kullandığımız yaklaşımın aynısını burada DevOps araçları için uygulayacağız.

Kaynak planlama

Kaynak ihtiyacını ekip sayısından önce seçilen sürüm, depo büyüklüğü, eklentiler, aktif kullanıcılar ve eşzamanlı işler belirler. Bu yazıdaki teknik örnekler GitLab 19.x ve Jira Software Data Center 11.3 kapsamındadır; kuracağınız yama sürümünün güvenlik duyurularını ve platform matrisini ayrıca kontrol edin. GitLab’ın güncel gereksinimleri tek düğüm için 8 vCPU ve 16 GB RAM tabanı verir; özel olarak ayarlanmış kısıtlı ortamlarda 8 GB RAM mümkün olsa da bunu Jira ile ortak üretim bütçesi saymayın. Disk hesabına uygulama/işletim sistemi, Git depoları, veritabanı, registry, loglar, geçici dosyalar ve yedekleri ayrı ekleyin. GitLab mümkünse swap’ın kapatılmasını, tutuluyorsa kullanmayacak kadar RAM ayrılmasını önerir. Aşağıdaki senaryolar ölçülmüş kapasite garantileri değildir.

Senaryo 1: Küçük ürün ekibi (5–10 geliştirici)

Bu senaryoda elinizde şu bileşenler olduğunu düşünelim:

• GitLab (kaynak kod, basic CI)
• 1–2 GitLab Runner (CI işleri)
• Uygun mevcut lisans varsa Jira Software Data Center (issue ve proje takibi)

Uygulama ile CI yükünü ayırmak için örnek yaklaşım:

• GitLab VPS’i: GitLab, kendisine ayrılmış PostgreSQL ve Redis/Valkey bileşenleri.
• Runner VPS’i: CI işleri için ayrı kaynak ve ağ sınırı.
• Jira: Mevcut lisans uygunsa ayrı uygulama VPS’i ve Jira’ya ayrılmış desteklenen veritabanı servisi.

Ölçüm öncesi planlama çerçevesi:

• GitLab: Tek düğüm tabanı 8 vCPU/16 GB RAM; örneğin 300–500 GB SSD/NVMe yalnızca depo ve saklama hesabıyla doğrulanacak bir disk bütçesidir.
• Jira: JVM heap’i, heap dışı bellek, işletim sistemi, eklentiler ve veritabanını ayrıca boyutlandırın. GitLab’ın RAM bütçesi Jira’yı içermez. Jira 11.3 için Java 21 ve desteklenen işletim sistemi/veritabanı gerekir.
• Runner: 4 vCPU/8 GB RAM ancak hafif işler için denenebilecek bir bütçe örneğidir; eşzamanlı job sayısı ölçülmeden kapasite sözü vermez.
• Lisans: Jira Software Data Center’ın taban lisans kademesi 500 kullanıcıdır; 5–10 kişilik ekip örneği ucuz bir başlangıç lisansı bulunduğu anlamına gelmez. Atlassian lisans kademeleri uygulama eklentisi maliyetini de etkiler.

Runner’ların CPU kullanımı, CI aşamalarında derleme, test, docker build gibi işlere bağlı olduğundan, burada sabit bir sayıdan çok eşzamanlı job sayısını hesaba katmalısınız. Örneğin ölçümlerde bir job’ın 1–1,5 vCPU kullandığını varsayarsak, aynı anda çalışan 3 job için toplam 3–4,5 vCPU gerekir; buna işletim sistemi ve diğer süreçler için pay eklenir. Pipeline sayısını job sayısıyla eşitlemeyin; RAM ve disk I/O ihtiyacını da ayrıca ölçün.

Senaryo 2: Orta ölçekli ekip (20–50 geliştirici)

20–50 geliştiricilik varsayımsal bir ekipte CI yoğunluğu artabilir; rolleri ayırma kararını kişi sayısı eşiğinden değil ölçülen gecikme ve kaynak rekabetinden verin. Örnek bileşenler:

• GitLab (yoğun kullanım, merge request review süreçleri)
• Mevcut lisansla Jira Software Data Center (çoklu proje, board ve raporlama)
• Container registry (CI çıktılarının saklandığı Docker registry)
• SonarQube veya benzeri kod kalite aracı

Bu noktada hem kaynak hem de güvenlik açısından aşağıdaki ayrım mantıklıdır:

• GitLab uygulaması: Rails/Sidekiq ve depo servisi Gitaly’nin kaynaklarını yük profiline göre planlayın.
• Veritabanları: GitLab ve Jira için ayrı PostgreSQL instance’ları, veritabanları, kullanıcılar ve yedekleme süreçleri kullanın; Jira’yı GitLab paketinin yönettiği PostgreSQL’e eklemeyin. GitLab 19.x matrisinde PostgreSQL 17–18; Jira 11.3 matrisinde PostgreSQL 16–17 bulunur. 17’nin ortak olması, ortak instance işletimini tek başına desteklenen mimari yapmaz. GitLab’ın yükseltme, extension ve şema işlemlerini Jira’dan bağımsız tutun.
• Jira uygulaması: Ayrı VPS; Jira 11.3 için MySQL 8.4 de desteklenen bir seçenektir, MariaDB/Percona değildir. Sürümün platform matrisi ve GitLab harici veritabanı kuralları belirleyicidir.
• CI ve kalıcı servisler: Runner’ları registry/SonarQube gibi kalıcı servislerden ayırın. GitLab Redis/Valkey servisini genel amaçlı ortak önbellek olarak kullanmayın.

Bu varsayımsal senaryo için doğrulanması gereken kaynak bütçesi:

• GitLab: 8 vCPU/16 GB RAM ve 300–500 GB depolama, başlangıçta ölçülecek tek düğüm bütçesi örneğidir; dağıtık kurulumda bileşen başına resmi boyutlandırmayı izleyin.
• Jira ve veritabanları: Her instance için CPU, RAM, bağlantı sayısı, disk gecikmesi ve yedek alanını ayrı ölçün; GitLab bütçesini paylaşılmış toplam kabul etmeyin.
• Runner: Varsayımsal 4–8 vCPU/8–16 GB RAM bütçesini iş başına tüketimle karşılaştırın. 4–6 eşzamanlı hafif iş bile ölçüm gerektirir; ağır derleme tek başına bu bütçeyi aşabilir.
• Registry/SonarQube: Saklama politikası, tarama/analiz yükü ve kendi sürüm gereksinimleriyle ayrıca boyutlandırın.

Özellikle veritabanı VPS’inin disk IOPS kapasitesi kritik. Yüksek yazma/okuma yoğunluğu, yanlış boyutlandırılmış bir diskte tüm sistemi yavaşlatabilir. Disk performansını değerlendirme konusunda NVMe VPS hosting rehberine de başvurabilirsiniz.

Senaryo 3: Büyüyen SaaS ekibi (50+ geliştirici, çoklu proje)

Bu ölçekte artık tek VPS’ler yerine çoklu VPS ve gerektiğinde dedicated sunucular düşünmek mantıklı hale gelir. Burada mantık, “her rol için ayrı kaynak havuzu” yaklaşımıdır:

• GitLab yüksek erişilebilirlik: Uygulama düğümü çoğaltmak ve PostgreSQL replikasyonu kurmak tek başına yeterli değildir. 3K referans mimarisi Premium/Ultimate kapsamındadır; yük dengeleyiciler, Rails/Sidekiq, PostgreSQL/Patroni/PgBouncer, Redis/Sentinel, Gitaly/Praefect, Praefect için ayrı veritabanı ve object storage rollerini birlikte ele alır. Praefect veritabanında tam HA için üçüncü taraf PostgreSQL çözümü gerekir. Her kritik servisin failover ve depolama erişimini tasarlayın. Tek düğümlü 1K referansı HA sağlamaz.
• Jira kümesi: Data Center lisansı, aynı Jira sürümündeki düğümler, ayrı local home’lar, erişilebilir shared home, Jira’ya ait ortak desteklenen veritabanı ve session affinity/WebSocket desteği olan yük dengeleyici gerekir. Bu, GitLab ile veritabanı paylaşımı değildir. Jira küme kurulum koşullarını izleyin.
• CI filosu: İş güven düzeyine göre ayrılmış runner’lar; otomatik ölçekleme ancak seçilen executor ve altyapı entegrasyonu destekliyorsa.
• İzleme: Uygulama, replikasyon, kuyruk, depolama ve ağ hataları için ayrı sinyaller ve denenmiş kurtarma adımları.

Bu tip yükler için NVMe depolamalı VPS ve gerektiğinde dedicated sunucu kombinasyonu bir tasarım seçeneğidir; seçilen planın depolama türü ve kaynak sınırları doğrulanmalıdır. Karar noktasında, Dedicated sunucu mu VPS mi, hangisi işinize daha uygun? yazısında anlattığımız yaklaşımı DevOps yüklerinize de birebir uygulayabilirsiniz.

Disk kapasitesi planlama ve IOPS ihtiyacını değerlendirme

GitLab ve Jira için disk planlarken sadece “şu an kaç GB repo var?” sorusunu değil, aşağıdakileri de düşünmelisiniz:

• Ortalama repo boyutu ve büyüme hızı
• Binary dosyalar, attachment’ler (Jira issue ekleri, GitLab LFS dosyaları)
• Container registry ve artefact depolarının büyüme trendi
• Yerelde tutulacak yedeklerin alan ihtiyacı; snapshot kullanılıyorsa nerede saklandığı ve hangi kotadan tükettiği

Basitleştirilmiş bir bütçe örneğinde, bir tam yerel yedek ve canlı veri kadar büyüme payı varsayılırsa bugünkü canlı veri boyutunun 3 katı alan ayrılır: 1x canlı veri, 1x yedek, 1x büyüme payı. Bu genel bir yeterlilik kuralı değildir; saklama süresi, yedek sayısı, loglar ve geçici CI dosyaları hesabı değiştirebilir. Yerel yedeğe ek olarak sunucudan bağımsız bir kopya planlayın. IOPS ihtiyacını GB hesabından değil, temsilî CI ve veritabanı yükü altında I/O gecikmesi ve disk kullanım ölçümlerinden değerlendirin. Uzun vadede object storage gibi çözümlere geçerken, medya ve artefact verisini dışarı taşımak da mümkün; bu yaklaşımı object storage ile medya offload stratejisi yazımızda detaylı anlattık, aynı mantığı container image ve artefact’lar için değerlendirirken seçilen registry veya depo yazılımının desteklediği depolama entegrasyonunu doğrulamalısınız.

Mimari tasarım: Hepsi tek VPS’te mi, yoksa rollere göre ayrılmış VPS’lerde mi?

İş sadece “kaç vCPU, kaç GB RAM” meselesi değil; bu kaynakları nasıl böldüğünüz de en az o kadar önemli. İki temel yaklaşım var:

• Monolit VPS: Tüm DevOps araçları tek güçlü VPS’te.
• Rollere göre ayrılmış VPS’ler: Uygulama, veritabanı, CI runner, registry ve monitoring için ayrı sunucular.

Monolit VPS: Ne zaman mantıklı?

Tek makine kaynak ve arıza alanını paylaşır. GitLab ile Jira’yı birlikte değerlendirme ortamında denemek mümkündür; bu rehber üretimde Jira uygulamasını ayrı host’a yerleştirir. Tek host’u değerlendirirken:

• Mevcut Jira lisansını ve her iki sürümün gereksinimlerini kontrol edin.
• CPU, RAM ve I/O tepe yüklerini toplayın; kişi sayısı veya günlük pipeline sayısı tek başına yeterli değildir.
• CI işlerini ayrı host’ta çalıştırın; bakım kesintisini ve tek host kaybını kabul edebildiğinizi doğrulayın.
• Veritabanı servisleri, dizinler, kimlik bilgileri ve yedekler uygulama bazında ayrı kalsın.

GitLab için verilen 8 vCPU/16 GB RAM tabanına Jira’yı ekleyip aynı toplamın yeterli olacağını varsaymayın. Jira’nın resmî küme rehberi uygulama sunucularında ek uygulama çalıştırılmamasını önerir. Bileşenleri sonradan ayırabilmek için verilerin yerini, ağ bağımlılıklarını, yedek ve geri yükleme adımlarını belgeleyin. Container kullanımı bu kaynak ve arıza ortaklığını kaldırmaz.

Rollere göre ayrılmış mimari: Neden daha sağlıklı?

Gerçek hayatta tıkanma noktaları genellikle:

• CI runner’lar CPU ve disk I/O’yu sömürürken GitLab arayüzünün yavaşlaması
• Jira raporlarının ortak veritabanı sunucusunun CPU, RAM veya disk I/O kaynaklarını yoğun kullanarak GitLab performansını etkilemesi
• Container registry disk tüketiminin kontrolsüz büyümesi

Bu etkileri azaltmak için uygulama, veritabanı ve CI rollerini ayırabilirsiniz:

• Uygulama host’ları: GitLab ve Jira için ayrı bütçeler ve mümkünse ayrı VPS’ler.
• Veritabanı servisleri: Uygulama başına ayrı instance; GitLab Redis/Valkey bileşeni için de ayrılmış kaynak.
• Runner host’ları: Üretim veritabanlarına doğrudan erişimi olmayan CI işçileri.

Runner eklemek çekirdek host’taki CPU/RAM rekabetini azaltır; artan işler GitLab API’sini, registry’yi, depolamayı ve ağı yine yükler. Bu servisleri de izleyerek ölçekleyin.

Container ve Docker kullanımı

Resmî Docker imajları kurulumun tekrar üretilebilirliğini kolaylaştırır. CPU/RAM sınırları açıkça ayarlanır; varsayılan olarak kaynak sınırı yoktur. Container’lar host çekirdeğini paylaşır ve güvenilmeyen CI koduna karşı tek başına yeterli sınır değildir. Kalıcı volume’lar, veritabanı migration’ları ve sürüm uyumluluğu nedeniyle eski imaja dönmek tam bir rollback sayılmaz; uygulamanın desteklenen yükseltme ve geri yükleme yolunu izleyin. Bu konuyu adım adım anlattığımız Docker ile VPS’te izole uygulama barındırma rehberinde anlattığımız prensipleri, DevOps araçlarınıza birebir uygulayabilirsiniz.

DevOps altyapısında erişim ve güvenlik

Kaynak kodu, erişim anahtarlarını ve CI/CD yetkilerini barındıran platformun ele geçirilmesi diğer sistemleri de etkileyebilir. Host, ağ, uygulama ve kimlik katmanlarını birlikte ele alın. GitLab ve Jira içinde güçlü kimlik doğrulama ve yöneticiler için iki faktörlü doğrulama planlayın; sürümünüzün, kimlik sağlayıcınızın ve eklentilerinizin desteklediği SSO/MFA özelliklerini doğrulayın ve kurtarma erişimini belgeleyin. Proje ve grup rollerini en az yetkiyle tanımlayın; herkese Owner/Admin yetkisi vermeyin.

Ağ katmanı: Firewall, sadece gerekli portlar ve yönetim ağı

İlk kural basit: Gereksiz her port kapalı olacak. En temel açılımlar:

• Web erişimi: HTTPS 443; HTTP 80 ancak yönlendirme veya seçilen sertifika doğrulama yöntemi gerektiriyorsa.
• Yönetim SSH’ı: VPN veya yönetici IP’leriyle sınırlandırın. Git-over-SSH geliştirici erişimi ayrı bir ihtiyaçtır; yalnızca yönetici listesiyle kısıtlayıp Git erişimini kesmeyin. Ayrı endpoint/port veya GitLab’ın uygulama yetkilerini planlayın.
• Veritabanı: Yalnız ilgili uygulama düğümleri ve kontrollü yedek/yönetim süreçleri erişsin. Runner’lara üretim veritabanı erişimi açmayın.

Güvenlik duvarını doğru kurgulamak için ufw, firewalld veya doğrudan iptables/nftables kullanabilirsiniz. Docker kullanıyorsanız yayımlanan container portları beklediğiniz ufw/firewalld filtrelemesini atlayabilir; yalnızca host kurallarına güvenmeyin. Port yayımlama ve Docker ağ kurallarını birlikte inceleyin; veritabanı gibi iç servisleri genel erişime yayımlamayın ve erişim sınırlarını izinli ve izinsiz ağlardan sınayın. Detaylı kurulum ve iyi pratikler için VPS sunucularda güvenlik duvarı yapılandırma rehberine göz atmanızı öneririm.

SSH erişimi ve yetki yönetimi

DevOps araçlarını yöneten ekip genellikle sistem yöneticileri ve lead geliştiricilerden oluşur. Bu kişilere SSH erişimi verilirken:

• Önce ayrı yönetici hesabında anahtarla yeni bağlantıyı, sudo erişimini ve kurtarma konsolunu doğrulayın; mevcut oturumu açık tutun.
• Ardından yönetim SSH’ında parola ve doğrudan root girişini kapatın; yapılandırmayı doğrulayıp yeni oturumla tekrar deneyin.
• Her yönetici için ayrı hesap kullanın ve sudo yetkisini ihtiyaçla sınırlayın.

Çoklu proje ve ekipler için kullanıcı, grup ve sudo mimarisini nasıl tasarlayacağınızı, Linux VPS’te kullanıcı, grup ve sudo mimarisi yazımızda ayrıntılı anlattık. DevOps VPS’leriniz için de birebir aynı yaklaşımı kullanabilirsiniz.

HTTPS, TLS ve güvenlik başlıkları

HTTPS’in kurulumla kendiliğinden güvenli biçimde açıldığını varsaymayın. GitLab dış URL’si, Jira base URL/connector ayarları, reverse proxy ve sertifika yenilemesi birlikte yapılandırılmalıdır:

• Web ve HTTP üzerinden Git erişiminde geçerli SSL sertifikası kullanın; Git-over-SSH kendi SSH doğrulamasını kullanır.
• Reverse proxy’de TLS 1.2/1.3, doğru forwarded başlıkları ve uygulamanın proxy ayarlarını doğrulayın. HSTS’i kalıcı HTTPS hazır olduğunda açın; includeSubDomains kapsamına girecek tüm host’ları kontrol edin.
• CSP ve diğer başlıkları körlemesine eklemeyin: uygulamanın kendi politikası, SSO, eklentiler ve gömülü içeriklerle uyumu staging’de deneyin.

HTTP güvenlik başlıklarını (HSTS, CSP, X-Frame-Options vb.) nasıl kurmanız gerektiğini ayrıntılı biçimde anlattığımız HTTP güvenlik başlıkları rehberi, GitLab ve Jira gibi panelleri internete açarken elinizin altında olması gereken bir kontrol listesi sunuyor.

Secrets ve erişim anahtarları yönetimi

Token ve özel anahtarları Git deposuna, imaj katmanlarına veya iş loglarına düz metin olarak koymayın. Bir sırrı environment variable ile geçirmek onu kendiliğinden güvenli yapmaz; sırrı alan job kodu onu dışarı gönderebilir.

• Secrets manager veya şifreli kasa kullanın; erişimi uygulama/job ve ortam bazında daraltın.
• CI değişkenlerini maskeleyin ve uygun korumalı branch/tag kapsamına bağlayın; masked/protected değişkenler kötü niyetli job’a karşı garanti değildir. Fork ve pipeline değişikliklerini sırlar verilmeden önce inceleyin.
• Shell executor’ı yalnız güvenilen işler için kullanın. Ayrıcalıklı Docker/DinD veya host Docker socket erişimini sıradan izolasyon saymayın; gerekliyse ayrılmış, geçici host ve sıkı ağ sınırı kullanın.
• Anahtarları süreli tutun, sızıntıda iptal edip yenileyin; log ve yedek erişimini de sınırlandırın.

Bu konuda daha ileri seviyede bir yaklaşımı VPS’te secrets yönetimi rehberinde anlattık; orada anlattığımız prensipleri GitLab, Jira ve CI boru hatlarınıza uyarlarken yetki sınırlarını ve sırların job’a hangi koşullarda verildiğini ayrıca değerlendirin.

Yedekleme ve felaket kurtarma

DevOps altyapısında kaybetmeyi göze alamayacağınız iki temel veri tipi var:

• Git reposu ve issue’lar (GitLab + Jira verileri)
• CI/CD konfigürasyonları, pipeline tanımları, secrets referansları

Yedek planınızı kurgularken şu başlıkları netleştirin:

• Hedefler: Kabul edilebilir veri kaybını (RPO) ve kesinti süresini (RTO) belirleyip yedek sıklığı, saklama ve geri yükleme planını bunlardan türetin.
• GitLab: Uygulamanın desteklenen tutarlı yedek prosedürünü izleyin. Standart arşiv yapılandırmayı/secrets dosyasını, Redis’i ve haricî object storage içeriğini tam olarak kapsamaz. Config/secrets ve TLS/SSH anahtarlarını korumalı ayrı kopyalayın; object storage/registry verisini ayrıca yedekleyin. Standart komutun tutarlılığı için bekleyen/çalışan arka plan işlerini resmî prosedüre göre boşaltın.
• Jira: Veritabanı ile home/shared home’u aynı kurtarma noktasına uygun yedekleyin; seçilen arama motoru ve eklentilerin ihtiyaçlarını ekleyin. Snapshot veya canlı dizine rsync tek başına uygulama tutarlılığını kanıtlamaz.
• Kopyalar: 3-2-1 yaklaşımıyla host’tan bağımsız, erişimi ayrılmış ve şifrelenmiş dış kopya tutun. Farklı bölge ve saklama özelliklerini seçilen hizmette doğrulayın.
• Geri yükleme: İzole ortamda repo, issue/ek, giriş ve entegrasyonları sınayın; GitLab yedeği tam aynı sürüm ve CE/EE türünü gerektirir. Ölçülen süreyi RTO ile karşılaştırın.

Bu konuyu uygulamaya dökmek için, 3-2-1 yedekleme stratejisi yazımızı DevOps ortamınıza uyarlayabilirsiniz.

Operasyon tarafı: Otomasyon, CI/CD ve izleme

Self-host DevOps platformunun en büyük avantajlarından biri, yapılandırma üzerinde daha fazla kontrol. Bu kontrolü her adımı elle yaparak değil, olabildiğince otomasyonla kullanmak gerekiyor.

Altyapıyı kodla yönetmek: Terraform ve Ansible

GitLab ve Jira gibi kritik sistemlerde, aynı ortamı tekrar kurabilmek (disaster anında veya staging ortamı için) çok değerlidir. Bunun için:

• Sağlayıcı desteklenen API/provider sunuyorsa VPS, ağ ve güvenlik kurallarını Terraform benzeri araçlarla tanımlayın; sunmuyorsa provisioning adımını ayrıca belgeleyin
• Sunucu içi konfigürasyonları (Nginx, PostgreSQL, GitLab/Jira config) Ansible playbook’larıyla yönetin

Bu yaklaşımı pratik örneklerle anlattığımız Terraform ve Ansible ile VPS otomasyonu yazımız, provisioning ile uygulama yapılandırmasının sorumluluklarını ayırmak için bir başlangıçtır; state, sırlar ve kalıcı verilerin kurtarılması ayrıca planlanır.

CI/CD’den VPS’e uygulama dağıtımı

Bu bölüm GitLab/Jira platformunun yükseltilmesini değil, CI ile derlenen kendi uygulamalarınızın VPS’e dağıtımını ele alır:

• Blue-Green/canary ile kesintiyi azaltmak için sağlık kontrolleri, oturumlar, kuyruklar ve geriye uyumlu veritabanı değişikliklerini birlikte tasarlayın.
• rsync, sürüm dizinleri/sembolik bağlantılar ve systemd bir uygulama dağıtım akışının parçaları olabilir; bunlar kendi başına kesintisiz yayın garantisi vermez.
• GitLab/Jira yükseltmelerinde seçilen sürümün desteklenen yükseltme yolunu, gerekli ara sürümleri ve yedekten dönüş planını izleyin.

Bu konuda pratik bir yol haritasını, GitHub Actions ile VPS’e otomatik deploy yazımızda anlattık; GitHub Actions yerine GitLab CI veya başka bir CI aracı kullansanız bile erişim, secrets, executor ve dağıtım adımlarını kullandığınız CI sistemine uyarlamanız gerekir.

İzleme, log ve alarm

GitLab ve Jira gibi araçlar yavaşladığında, geliştirici ekibin verimliliği anında düşer. Bu yüzden:

• CPU, RAM, disk I/O ve ağ kullanımını metrik bazlı izleyin
• Uygulama loglarını merkezi bir yerde toplayın (ör. Loki, ELK, benzeri çözümler)
• Uptime ve response time için harici bir izleme aracıyla endpoint’leri takip edin

Temel metrikleri ve araçları tanıttığımız VPS kaynak kullanımı izleme rehberi, DevOps VPS’leriniz için hangi sinyallere bakmanız gerektiğini netleştirmenize yardımcı olacaktır.

DCHost üzerinde self-hosted DevOps için pratik yol haritası

Toparlayalım; GitLab, Jira ve diğer DevOps araçlarını DCHost VPS altyapısında self-host etmek istiyorsanız, adım adım şöyle ilerleyebilirsiniz:

1. Ekip profilini çıkarın: Geliştirici sayısı, günlük commit/pipeline sayısı, repo boyutları.
2. Mimariyi seçin: Mevcut Jira lisansı ve geçiş takvimini doğrulayın; uygulama, veritabanı ve runner rollerini yük ve arıza hedefleriyle ayırın.
3. Kaynakları boyutlandırın: GitLab/Jira için CPU/RAM’i, veritabanı için IOPS’i ciddiye alın; NVMe diskleri tercih edin.
4. Güvenlik temelini kurun: Firewall, SSH anahtarları, TLS/SSL, kullanıcı ve sudo mimarisi.
5. Yedek ve DR planı oluşturun: 3-2-1 kuralı, periyodik restore testleri, farklı lokasyonda saklanan yedekler.
6. Otomasyon ve izleme ekleyin: Desteklenen API/provider varsa Terraform; yapılandırma için Ansible, Prometheus/Grafana veya benzeri ile metrik ve alarm.

DCHost’un VPS, dedicated veya colocation seçeneklerini değerlendirirken tahsis edilen kaynakları, depolama türünü/gecikmesini, ağ sınırlarını, yedek ve destek kapsamını güncel hizmet koşullarından doğrulayın. Uygulama lisansı, GitLab/Jira işletimi ve felaket kurtarma sorumluluğunu altyapı hizmetiyle karıştırmayın. Temsilî pilot yükü ölçmek, büyüme kararını somutlaştırır.

Önce araç ve sürüm listenizi, mevcut lisansları, eşzamanlı işleri ve saklama gereksinimini çıkarın. GitLab’ın tabanına Jira, veritabanı ve CI bütçelerini ayrı ekleyin; pilot ölçümleri ve kurtarma hedefleriyle VPS/dedicated seçimini yapın. Jira için 2029 geçişini uzun vadeli planın parçası tutun.