Walgit tamamen object storage üzerinde çalışan, veritabanı veya lider düğümü olmayan bir Git sunucusu

Rust ile yazılmış open-source bir Git sunucusu olan Walgit, Hacker News ana sayfasında alışılmadık bir dağıtım modeliyle ortaya çıktı: tek bir binary çalıştırıp S3 uyumlu veya Google Cloud Storage bucket'ına yöneltiyorsunuz ve elinizde veritabanı olmayan, lider seçimi olmayan ve önemli hiçbir yerel durum barındırmayan çalışan bir Git host oluyor. Projenin README'sine göre bir dağıtım, kısa bir TOML dosyası artı tek bir süreçten ibaret; yeni bir repository adına push yapmak o repository'yi oluşturuyor ve aynı bucket'a bakan diğer instance'lar hiçbir koordinasyona gerek olmadan özdeş içerik hizmet veriyor. Tüm instance'ları kapatmanın maliyeti yalnızca ısınmış cache'ler.

Gerçek kaynak olarak write-ahead log

README, tasarımı Cursor'ın "Git at any scale" başlıklı yazısında anlatılan — Continuity adı verilen — bir mimariye borçlu olduğunu belirtiyor; burada bu mimari, instance'ların hizmet verdikleri repository'lerden daha küçük olabilmesi için uyarlanmış. Temel hamle, object storage'daki bir write-ahead log'u (WAL) repository'nin yetkili kaydı yapmak ve diskteki her kopyayı cache olarak ele almaktır.

Bir push, değiştirilemez (immutable) bir nesne olarak yüklenir ve yalnızca küçük bir manifest dosyası compare-and-swap işlemiyle yeniden yazıldığında görünür olur. O anlık takas işleminin kendisi tutarlılık mekanizmasının tamamıdır — seçim yok, quorum yok, primary yok — ve bu, yarışan yazıcıları imkânsız kılar: hangi instance'ın takası önce gerçekleşirse o kazanır; 412 conflict gören kaybedense yeniden okur, güncellemek istediği ref'leri yeniden doğrular ve tekrar dener. Tek bir instance'a gelen eşzamanlı push'lar tek bir takasta gruplanarak commit edilir.

Okumalar manifest'in koşullu bir GET'iyle başlar. 304 Not Modified, yerel kopyanın güncel olduğu anlamına gelir; 200 ise yeni log kayıtlarının uygulanacağını gösterir ve uygulamanın derinliği isteğin ihtiyacına göre değişir — ref listelemeleri packfile'ları tamamen atlayabilirken, tam materializasyon yalnızca repack işlemlerine ayrılmıştır. Compaction, süreli bir lease tutan hangi instance ise onun tarafından bir kez yapılır ve sonuçlar log'a yayımlanır; böylece diğer kopyalar kendileri repack yapmak yerine sıkıştırılmış pack'leri indirir.

Makineden büyük repository'lere hizmet vermek

Walgit'in Continuity'ye ekledikleri küçük donanımdaki monorepo'ları hedefliyor. HTTP range istekleri üzerine kurulu bir uzak okuyucu, packfile'ları asla diskine sığmayacak bir repository'nin ref'lerini ve web sayfalarını bir instance'a hizmet verebilmesini sağlıyor; bir de "history pack", büyük blob'lar bucket'ta kalırken commit ve tree nesnelerini yerel tutuyor. Clone trafiği neredeyse tamamen sunucudan ayrılıyor: bundle-uri desteği, takvim dilimlerine göre bundle'lar kesiyor — haftalık bir full artı zincirleme günlük ve saatlik bundle'lar — ve bunları bucket veya bir CDN statik dosyalar olarak hizmet veriyor; böylece yeni bir clone bundle'ları indiriyor ve sunucudan yalnızca kalan kısmını istiyor.

Binary'de neler var

Özellik listesi; filtreler, shallow fetch'ler, atomic push'lar, push option'lar ve hem SHA-1 hem SHA-256 repository'ler dahil smart HTTP v0/v2 fetch ve push'u kapsıyor. Nesneleri bucket'ta saklanan Git LFS, React tabanlı bir gezinme arayüzü, bağımlılıksız JavaScript SDK'lı read-mostly bir JSON API, repository başına push politikaları (korumalı ref'ler, gruplar, yalnızca fast-forward kuralları, bypass listeleri) ve WAL'ı izleyip kalıcı bir cursor ile ref olaylarını tam bir kez teslim eden bir webhook köprüsü mevcut. Kimlik doğrulama statik token'ları veya herhangi bir OpenID Connect issuer'ı destekliyor; desteklenen depolamalar arasında AWS S3, MinIO, Cloudflare R2, Ceph ve GCS var. Bir bakım döngüsü her geçişte istenen durumu yapılandırmadan ve WAL'dan türetiyor ve en önemli bekleyen işin sınırlı bir birimini gerçekleştiriyor; README, eksik artefaktların özdeş şekilde yeniden inşa edildiğini söylüyor, yani bir kesinti onarılacak bir şey bırakmıyor.

Neden önemli

README, altta yatan ekonomiyi şöyle çerçeveliyor: Git hosting'in zahmetli olmasının nedeni, packfile'ların her şeyi boyut için değil sıralı okuma için optimize edilmiş büyük binary blob'lara sıkıştırması; böylece her işlem gigabaytlar boyunca dağınık okumalara dönüşüyor — bu bir laptop'un page cache'i için sorun değil ama ağ dosya sistemi üzerinden felaket. GitHub'ın Spokes tasarımı bunu, gerçek repository'leri yerel NVMe'de tutup packfile düzeyinde çoğaltarak çözmüş; bunun bedelini sabit bir kopya kümesi arasında koordine edilen commit'ler ve repository'leri makinelere eşleyen bir veritabanıyla ödüyor.

Walgit'in bahsi, ucuz object storage'daki bir compare-and-swap manifest'in bu koordinasyon katmanının yerini alabileceği ve instance'ları atılabilir kılp bucket'ı, tam köken bilgisiyle birlikte kayıt sistemi yapabileceği yönünde — her push ve repack log'da duruyor ve repository herhangi bir noktaya yeniden oynatılabiliyor. Stateful bir filo olmadan self-hosted Git hosting isteyenler için bu, maliyet yapısını değiştiriyor; bedeli ise tüm tasarımın dayandığı CAS semantiği ve erişilebilirlik için object store'a bağımlı olmak.