GitLab Yeni Sunucuya Nasıl Taşınır?

GitLab migration neden dosya kopyalamaktan ibaret değildir?

Self-managed GitLab; repository verisiyle birlikte veritabanı, yapılandırma, secret, artifact, LFS, package, Container Registry ve CI/CD bileşenlerinden oluşur.

Taşıma planı yalnız görünür repository'leri kapsarsa kullanıcılar giriş yapabilse bile pipeline, Registry, webhook veya Runner akışları eksik kalabilir.

• Git repository ve wiki verileri
• PostgreSQL veritabanı
• LFS, artifact, upload ve package verileri
• Container Registry
• Runner kayıtları ve yürütme kapasitesi
• Secret, SSH anahtarı, TLS ve dış entegrasyonlar

Güvenli biçimde toplanabilecek mevcut durum bilgileri

İlk adım değişiklik yapmak değil, kaynak ortamın sürümünü ve sağlık durumunu kaydetmektir. Aşağıdaki kontroller salt okunur envanter amacıyla kullanılabilir.

Çıktılar erişim bilgisi ve iç adresler içerebileceğinden paylaşılmadan önce hassas alanlar temizlenmelidir.

sudo gitlab-rake gitlab:env:info
sudo gitlab-rake gitlab:check SANITIZE=true
sudo gitlab-ctl status
df -h

• GitLab sürümü ve kurulum tipi
• İşletim sistemi ve hedef kaynak kapasitesi
• Başarısız veya devre dışı GitLab bileşenleri
• Veri büyüklüğü ve büyüme payı
• Kaynak ortamda taşıma öncesinden gelen hatalar

Sürüm geçiş yolu neden önceden belirlenmelidir?

Kaynak ve hedef GitLab sürümleri rastgele seçilemez. Bazı yükseltmeler zorunlu ara sürümler ve arka plan migration işlemleri gerektirir.

Kaynak sürüm, Edition, paketleme yöntemi ve hedef işletim sistemi doğrulanmadan restore denemesi yapmak kesintiyi uzatabilir. Kesin yükseltme patikası, çalışma tarihinde GitLab'ın güncel dokümantasyonuna göre belirlenmelidir.

• Kaynak ve hedef aynı Edition mı?
• Zorunlu upgrade stop noktaları var mı?
• Background migration işlemleri tamamlandı mı?
• Hedef işletim sistemi ve mimari destekleniyor mu?
• PostgreSQL ve Registry uyumluluğu doğrulandı mı?

Kesinti, DNS ve son senkronizasyon planı

Değişen repository, issue, pipeline ve Registry verileri nedeniyle taşıma anında yazma trafiğinin nasıl durdurulacağı tanımlanmalıdır.

Bakım penceresi; son yedek/senkronizasyon, DNS veya load balancer geçişi, kullanıcı doğrulaması ve gerektiğinde geri dönüş için ayrı süreler içermelidir.

• Kullanıcılara duyurulacak salt-okunur veya bakım aralığı
• DNS TTL ve reverse proxy davranışı
• Son veri değişikliğinin nasıl sınırlandırılacağı
• Runner'ların yanlış ortama job almamasının sağlanması
• Başarısız geçişte kaynak ortamın hangi koşulda yeniden açılacağı

Taşıma sonrası yalnız giriş ekranını kontrol etmek yeterli değildir

Başarılı login, migration'ın tamamlandığını kanıtlamaz. Temsilî projelerde clone/push, pipeline, artifact, LFS, Registry ve webhook akışları doğrulanmalıdır.

Kabul kriterleri çalışmadan önce yazılı olmalı; test sahipleri ve beklenen sonuçlar belirlenmelidir.

• Kullanıcı, grup ve proje yetkileri
• SSH ve HTTPS clone/push
• Runner ve pipeline yürütme
• LFS, artifact ve package indirme
• Container Registry push/pull
• Webhook, e-posta, LDAP/SAML ve diğer entegrasyonlar
• Yedekleme ve izleme görevleri

Hangi noktadan sonrası ortama özel yürütülmelidir?

Backup üretme, restore, secret aktarımı, sürüm yükseltme, Registry veri geçişi ve cutover adımları veri kaybı veya uzun kesinti riski taşır. Bu nedenle genel bir komut listesinin production ortamında doğrudan uygulanması güvenli değildir.

Atlas Infrastructure; kaynak envanteri, sürüm geçiş yolu, prova, yazılı cutover/rollback planı ve taşıma sonrası doğrulamayı ortama göre hazırlar.

• Kritik veya sürekli kullanılan GitLab ortamı
• Büyük Registry, LFS veya artifact hacmi
• Birden fazla Runner ve deployment hedefi
• LDAP/SAML, object storage veya harici PostgreSQL kullanımı
• Kısa bakım penceresi ya da geri dönüş zorunluluğu