Kendi Git sunucunuz.
Depo, organizasyon şemasıdır.

Git'i kendi başınıza barındırma konusundaki neredeyse her tartışma kaynak kod hakkındadır, oysa kaynak kod en az önemli olan kısımdır. Çoğu sıradandır, büyük bir bölümü açık kaynak kütüphanelerin üzerine ince bir katmandır ve yarın sızdırılsaydı pratik zarar genellikle gerçek bir hasardan çok mahcubiyet olurdu. İşte bu yüzden "kodum gizli değil" sözü eksiksiz bir yanıt gibi görünür — ve işte tam da bu yüzden değildir.

İlginç olan kısım, kodun etrafındakidir. Bir depo, çalışmanın tarihli, kime ait olduğu belli, yüksek çözünürlüklü bir kaydıdır: ne zaman uyuduğunuzu anlatan commit zaman damgaları, kiminle çalıştığınızı anlatan ortak yazar satırları, kimsenin duyurmadığı ürünleri anlatan dal adları, neyin ne kadar bozuk olduğunu anlatan bir sorun izleyici ve tüm projenin tarihini veren bir ilk commit. Yüz depoyu bu şekilde okuduğunuzda artık yazılım okumuyorsunuzdur — bir şirketi, onun yol haritasını, çalışan sayısını ve derdini okuyorsunuzdur.

Bir platformda, bu kayıt anlamlı hiçbir şekilde size ait değildir. Kontrol etmediğiniz bir altyapı üzerinde, doğruladığınız bir kimliğe bağlı bir hesabın altında, yasal sürecinin ona ulaşabildiği bir yargı alanında, kapsamı değiştirilebilir bir belgeyle belirlenen sistemler tarafından taranarak durur. Bunların hiçbiri kimsenin kötü niyetli olmasını gerektirmez: bu sadece izleyiciyi kiralamanın ne anlama geldiğidir. Dört düzenleme, ve her birinin gerçekte neyi ele verdiği:

Üçüncü satır, bunu zaten çözdüğünü düşünen ekipleri yakalayan satırdır. Doğrulanmış bir şirket hesabı altında kurumsal bir kartla kiralanan bir makinede kendi kurduğunuz bir forge, uygulamayı platformdan çıkarmış ama kimliği tam olarak olduğu yerde bırakmıştır. Bu, kontrolde gerçek bir kazanç ve ifşada hiçbir kazanç değildir.

Ve dördüncü satır kendi bedelini açıkça ortaya koyar, çünkü bu kılavuzun geri kalanı büyük ölçüde onu ödemekle ilgilidir. Kendi kendine barındırmanın başarısızlık biçimi gözetim değil, kayıptır. Bir platform, hiç düşünmediğiniz yedekleri tutar. Sunucunuz ise yalnızca sizin yapılandırdığınız yedekleri tutar. Adım 06, sonda yer alan isteğe bağlı bir rötuş değildir — diğer beşini güvenli kılan adımdır.

Önce sunucuyu sipariş edin. Panelde: Sipariş → VPS → Sentinel, imaj Debian 12, geçmişin yaşamasını istediğiniz hangi kaledeyse orada — Helsinki, Stockholm, Oslo veya Reykjavík. Hesabı açmak için e-posta adresi gerekmez ve fatura Monero, Bitcoin, Lightning veya desteklenen başka herhangi bir varlıkla ödenir. Bu, çoğu iş yükünden daha fazla burada önem taşır: bir forge, tüm değer önerisi çalışmanızın kaydının bir isme bağlı olmaması olan tek hizmettir.

Ardından ilk saat sıkılaştırma kontrol listesini uygulayın — taşınmış bir portta yalnızca anahtarla SSH, gözetimsiz güncellemeler, varsayılan olarak reddeden bir güvenlik duvarı — çünkü aşağıdaki her şey, zaten başkasına ait olmayan bir sunucu olduğunu varsayar.

Sunucuya bir host adı yönlendirin — bir A kaydı ve IPv6 üzerinden erişilebilir olmasını istiyorsanız bir AAAA kaydı — ve başlamadan önce bunun yayılmasını bekleyin, çünkü ters proxy ilk açılışında o isim için bir sertifika almaya çalışacaktır ve başarısız bir doğrulama kafa karıştırıcı bir başlangıç olur. Ardından henüz hiçbir şey dinlemiyorken güvenlik duvarı kurallarını yazın.

İki-SSH sorunu. Bir forge, Git için SSH konuşur ve sunucunuz zaten yönetim için SSH konuşur. İkisi de 22 numaralı portu birden sahiplenemez ve bunları karıştırmak, insanların Git'i de anlamak zorunda olan bir yönetim daemon'uyla sonuçlanmasının yoludur. Onları ayrı tutun: sıkılaştırma kılavuzundaki taşınmış portta yönetim, konteynere eşlenen ayrı, herkese açık bir portta Git. 2222 geleneksel seçimdir ve onda kutsal hiçbir şey yoktur.

ufw default deny incoming
ufw allow 47222/tcp                  # administrative SSH, moved
ufw allow 80/tcp                     # ACME HTTP-01 challenge
ufw allow 443/tcp                    # the web interface
ufw allow 2222/tcp                   # git over SSH, into the container
ufw enable
ufw status numbered

# Nothing else is open. In particular: PostgreSQL stays on the Docker
# network and is never published to the host, let alone the internet.

Docker'ı dağıtım paketi yerine resmi depodan kurun, böylece Compose v2 mevcut olur ve sürüm güncel kalır. Ardından yığın için bir dizin oluşturun ve onu sunucuda durum tutan tek yer yapın — bu, adım 06'nın yedeklediği dizindir.

curl -fsSL https://get.docker.com | sh
docker compose version

install -d -m 0750 /srv/forgejo
cd /srv/forgejo

Genel anahtarınızı profil ayarlarına yapıştırın, ardından istemcinize forge'un nerede yaşadığını öğretin. Git standart olmayan bir portta olduğu için SSH yapılandırmanıza bir girdi eklemek otuz saniyeye değer — bu, portu yazacağınız her URL'nin dışında tutar ve remote'ları taşınabilir kılar.

# ~/.ssh/config
Host git.example.com
    Port 2222
    User git
    IdentityFile ~/.ssh/id_ed25519

# Then, in any repository:
git remote set-url origin git@git.example.com:you/project.git
git push -u origin main
ssh -T git@git.example.com        # expect a greeting, not a shell

O son komut, port eşlemesinin, konteynerin SSH sunucusunun ve anahtarınızın hepsinin uyuştuğunu size söyleyen komuttur. Forgejo'dan bir selamlama, tüm zincirin çalıştığı anlamına gelir. Bir parola istemi ise bunun yerine host'un yönetimsel sshd'sine ulaştığınız ve port eşlemesinin yanlış olduğu anlamına gelir.

Şimdi commit'lerinizi imzalayın. Bu, çoğu kendi kendine barındırma kılavuzunun atladığı adımdır ve kendi barındırdığınız bir forge'da bir platformda olduğundan daha fazla önem taşır. Bir commit'in yazar alanı serbest metindir — gönderim yapabilen herkes adınızı oraya yazabilir. Bir imza, belirli bir anahtarın belirli bir commit'i yaptığının kanıtıdır ve gönderildiği sunucu ele geçirilse, taşınsa veya atılsa bile kanıt olmaya devam eder. Git, zaten sahip olduğunuz SSH anahtarıyla imzalayabilir, artık bir PGP dolambacına gerek yok:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

git commit --allow-empty -m "signed"
git log --show-signature -1

Ardından aynı genel anahtarı forge'a bir kez daha, bir kimlik doğrulama anahtarı değil bir imzalama anahtarı olarak ekleyin. Forgejo imzayı sunucu tarafında doğrular ve commit'i doğrulanmış olarak gösterir; bu ikinci girdi olmadan imzayı hesabınızla ilişkilendirmenin bir yolu yoktur ve doğru şekilde imzalanmış olsa bile her commit doğrulanmamış görünür.

Yalnızca okuyan makineler için dağıtım anahtarları. Bir üretim sunucusunun, bir derleme sunucusunun veya bir yansının forge'da bir kullanıcı hesabına ihtiyacı yoktur. Bunun yerine ona bir dağıtım anahtarı verin: tek bir depoya eklenen, siz açıkça yazma izni vermedikçe salt okunur olan ve kurulumdaki başka hiçbir şeye erişim vermeyen bir anahtar çifti. İptal etmek tek bir girdiyi silmektir. Bu, kendi barındırdığınız bir forge'u düzenli tutmanın tek en etkili alışkanlığıdır, çünkü kullanıcı hesapları izin biriktirir, dağıtım anahtarları ise biriktiremez.

Bir platformdan taşınmak, bütün bunları doğru şekilde yapmak için iyi bir andır. Forgejo'nun Yeni Taşıma akışı bir depo URL'si ve bir erişim belirteci alır ve dalları, etiketleri, sorunları, yorumları, etiketleri, kilometre taşlarını, sürümleri ve pull request'leri karşıya taşır. Sonucun neye benzediğini görmek için önce bir depoyu çalıştırın, büyük grupların API hız sınırlamalarına takılıp yavaşlamasını bekleyin ve kaynağı aynı gün silmek yerine birkaç hafta salt okunur tutun.

Git burada alışılmadık derecede bağışlayıcıdır ve nedenini net bir şekilde ortaya koymaya değer. Her klon, geçmişin eksiksiz bir kopyasıdır, bu yüzden bir geliştiricinin güncel bir çalışma kopyası olduğu sürece kod sunucudan sağ çıkar. Bu gerçekten güven vericidir ve forge'unuzun tuttuğu iki şeyden tam olarak birini kapsar. Diğeri — sorunlar, pull request tartışmaları, inceleme dizileri, sürümler, wiki sayfaları, kullanıcılar, ekipler, izinler, CI geçmişi — yalnızca veritabanında var olur, kimsenin bunun bir klonu yoktur ve genellikle birikmesi üç yıl süren kısım budur.

İlk olarak, bir gönderim yansısı. Ücretsizdir ve kendi kendine çalışır. Bir depoda: Ayarlar → Yansı ayarları → hedef için URL ve bir erişim belirteciyle bir gönderim yansısı ekleyin. Forgejo ardından her gönderimden sonra her dalı ve etiketi ikinci bir Forgejo'ya, Codeberg'e veya bir yuva yerine bir vitrin olarak tutmaya karar verdiğiniz bir platforma çoğaltır. Açıkça belirtilmeye değer bir uyarı: bir gönderim yansısı, kaldırmayı amaçladığınız bir sır dahil olmak üzere geçmişi sadakatle yeniden yayımlar.

Ardından, yerleşik arşiv olmayan gerçek bir yedek. Forgejo, yapılandırmayı, depoları, verileri ve bir veritabanı dökümünü tek bir zip dosyasına paketleyen bir forgejo dump komutu sunar. Bir hata bildirirken bir sürdürücüye vermek için gerçekten faydalı bir şeydir. Ölümden dönmek için güvenmeniz gereken şey değildir: ürettiği SQL'in yeniden içe aktarmada uzun süredir bilinen sorunları vardır ve arşiv her çalıştırmada tüm depo kümesini yeniden yazar, bu da gerçek bir kurulumda her gece sıfırdan yazılan büyük bir dosya anlamına gelir. Bunun yerine sıkıcı ama doğrulanabilir yolu kullanın — veritabanını kendi aracıyla dökün ve veri dizinini dosyalar olarak yedekleyin:

#!/bin/sh
# /usr/local/bin/forgejo-backup — run from a systemd timer, nightly
set -eu
cd /srv/forgejo

# 1. Consistent database dump, written next to the data.
docker compose exec -T db pg_dump -U forgejo -Fc forgejo > ./db.dump

# 2. Everything that matters, to an encrypted offsite repository.
restic backup ./data ./db.dump ./docker-compose.yml ./.env ./Caddyfile

# 3. Retention, then prove the repository is still readable.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check

Bunu forge'dan farklı bir yargı alanındaki bir makineye, forge'un ele geçirilmesinin kendi geçmişini silememesi için yalnızca eklemeye izin veren bir depo üzerinden gönderin — şifreli yedekler kılavuzu, systemd zamanlayıcısı ve yalnızca eklemeye izin veren anahtar kısıtlaması dahil olmak üzere yukarıdaki üç satırın uzun versiyonudur.

Ardından bunu bir kez, bilerek geri yükleyin. Bir taslak VPS sipariş edin, anlık görüntüyü onun içine geri yükleyin, aynı Compose dosyasını geri yüklenen veri dizinine karşı ayağa kaldırın, veritabanı dökümünü yükleyin, bir hosts dosyası girdisini ona yönlendirin ve oturum açın. Bütün bunun süresini ölçün. O sayı — yedekleme işinin var olması değil — sizin gerçek kurtarma konumunuzdur ve bu alıştırmayı yapan herkes ilk seferinde dahil etme listesinden eksik en az bir şey bulmuştur.

# restic keeps absolute paths, so the stack reappears under the target.
restic restore latest --target /srv/restore
cd /srv/restore/srv/forgejo

docker compose up -d db                # empty volume: the entrypoint creates the database
docker compose exec -T db pg_restore -U forgejo -d forgejo \
  --clean --if-exists --no-owner < db.dump

docker compose up -d                   # then sign in and walk the issue tracker

Kısaca, yükseltmeler. İmajı :latest yerine büyük bir sürüme sabitleyin, böylece gözetimsiz bir çekme işlemi siz uyurken sizi bir kırılma değişikliğinin öte tarafına taşıyamaz. Büyük bir sınırı geçmeden önce sürüm notlarını okuyun, önce bir anlık görüntü alın ve bir veritabanı taşıma işleminin yeni sürümün ilk başlangıcında çalıştığını unutmayın — bu tek yönlü bir kapıdır. Watchtower tarzı otomatik güncelleme statik bir site için iyi bir fikirdir ama sahip olduğunuz her dalı tutan makine için kötü bir fikirdir.

Bitti demeden önce dört kontrol. Oturumu kapatın ve kurulumun hesap oluşturmanın hiçbir yolunu sunmadığını doğrulayın. Oturumu olmayan bir tarayıcıdan, özel bir deponun sadece yasak değil, görünmez olduğunu doğrulayın. Runner'ın forge'un veri dizinini okuyamadığını doğrulayın. Ve son restic kontrolünün başarılı olduğunu doğrulayın — sessizce başarısız olan yedekleme işi, ihtiyaç duyulduğu güne kadar herkesin sahip olduğu şeydir.