A Gitea saját üzemeltetése 2026-ban: repositoryk, SSH és biztonságos frissítés

Ha már próbáltad saját magad üzemeltetni a Giteát, valószínűleg ismerős ez a bosszantó helyzet: a felület megjelenik, de a ROOT_URL localhostos klónozási linkeket generál, vagy az SSH-port nincs továbbítva. A konténer újralétrehozása ritkán oldja meg az URL-ek, az állapot és a függőségek közötti eltérést.

Ez az útmutató egy konkrét befejezési feltételt használ: lehessen HTTPS-en és SSH-n keresztül klónozni, egy commitot és egy LFS-objektumot pusholni, issue-t nyitni, valamint egy jobot futtatni egy külön regisztrált Actions runneren. Minden konfigurációs döntést ehhez a feltételhez mérünk, nem pedig ahhoz, hogy a konténer állapota zöld-e.

Keresd meg a Gitea minden tartós adatát

Még az első valódi rekord létrehozása előtt listázd az állapotot: a repositorykat, az LFS-objektumokat, a csatolmányokat, a konfigurációt és az adatbázist. A bootstrap előtt csatold a /data könyvtárat, írj bele ártalmatlan mintaadatokat, majd cseréld le a konténert annak bizonyítására, hogy az útvonal valóban perzisztens. A mountolást úgy is ellenőrizd, hogy ártalmatlan adatokat írsz bele, lecseréled a Giteát, majd visszaolvasod az adatokat.

A snapshotok gyors visszaállításnál értékesek, de külön biztonsági mentésre is szükség van, ha a host vagy a volume eltűnik. Állítsd vissza az adatokat üres környezetbe a rögzített image használatával, majd ellenőrizd, hogy a repositoryk átmennek-e az fsck ellenőrzésen, az LFS-objektumok letölthetők-e, illetve az issue-k, release-ek és felhasználói jogosultságok megegyeznek-e a mentés előtti állapottal. A perzisztens volume-ok és snapshotok használatával tartsd külön ezt a két helyreállítási mechanizmust.

Készíts lecserélhető Gitea-konténert

A következő parancs láthatóvá teszi a konténer határát anélkül, hogy úgy tenne, mintha minden külső szolgáltatás provisionálását is elvégezné.

docker run -d \
  --name gitea \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v gitea-data:/data \
  -e GITEA__security__SECRET_KEY=replace-with-a-long-random-value \
  gitea/gitea:latest

A forgalom beengedése előtt vizsgáld meg a feloldott környezetet, a mountokat és a listenert. Terheltebb telepítésnél add hozzá a Postgres vagy MySQL ellenőrzött kapcsolati beállításait, valamint szükség esetén az SSH-útvonalat; privát szolgáltatásokhoz használj privát neveket. Az indulás akkor tekinthető sikeresnek, amikor HTTPS-en és SSH-n keresztül tudsz klónozni, commitot és LFS-objektumot pusholni, issue-t nyitni, valamint egy jobot futtatni egy külön regisztrált Actions runneren — nem pedig akkor, amikor a docker ps azt írja ki, hogy Up.

Válaszd külön a Giteát és a függőségeit

A processz állapota és a termék állapota külön fogalom a Gitea esetében. A 3000-es port válaszolhat úgy is, hogy a felhasználó által indított tranzakció továbbra is hibás. A Gitea hálózati szerződéséhez terheltebb telepítésnél Postgres vagy MySQL, valamint szükség esetén egy SSH-útvonal tartozik. A privát végpontokat tartsd belső DNS-en, csak a szükséges kimenő hívásokat engedélyezd, és adj a Giteának korlátozott hatókörű service credentialt.

Jelentős konfigurációs módosítások után végezd el a következő readiness-gyakorlatot: klónozz HTTPS-en és SSH-n keresztül, pusholj egy commitot és egy LFS-objektumot, nyiss egy issue-t, majd futtass egy jobot egy külön regisztrált Actions runneren. A költséges külső ellenőrzéseket hagyd ki a liveness probe-okból, hogy egy szolgáltatói kiesés ne indítson el restart loopot. A kapacitásmérésnek a repositoryk számát, a Git-objektumok packingjét, az LFS-tárhelyet, az adatbázis késleltetését és a runner terhelését kell követnie a szokásos oldalbetöltések helyett, mert ezek közelebb állnak a Gitea valós terheléséhez.

A TLS egyszerű; a generált URL-ek már nem

A Giteához egyetlen HTTPS-hostnevet tegyél elérhetővé, a nyers 3000-es portot pedig tartsd privátan. A ROOT_URL és az SSH_DOMAIN értékét állítsd azokra a címekre, amelyeket a felhasználók ténylegesen használnak klónozáskor. Így a böngészők és az API-kliensek nem tanulnak meg két egymással versengő címet.

Egy tiszta kliensről futtasd le a bevált tranzakciót, és vizsgáld meg az első hibás kérést. Ha a DNS vagy a TLS hibás, használd az egyéni domainről szóló útmutatót. A „ROOT_URL localhostos klónozási linkeket generál, vagy az SSH-port nincs továbbítva” problémát külön alkalmazásszintű hibakeresésként kezeld, miután az útvonal működését már igazoltad.

Ellenőrizd a Gitea-telepítést végponttól végpontig

Ne az első felhasználó forgalmát használd a Gitea átvételi tesztjeként. Készíts elő ártalmatlan mintaállapotot, majd futtasd le a teljes műveletet: „klónozz HTTPS-en és SSH-n keresztül, pusholj egy commitot és egy LFS-objektumot, nyiss egy issue-t, és futtass egy jobot egy külön regisztrált Actions runneren”. Jegyezd fel a futtatáshoz tartozó pontos nyilvános URL-t, eredményt, image-hivatkozást és naplózási időintervallumot.

Cseréld le a konténert, majd ismételd meg a műveletet az adatok újraépítése nélkül. Ezután állítsd helyre a rendszert egy üres hoston; a helyreállítási feltétel az, hogy a repositoryk átmenjenek az fsck ellenőrzésen, az LFS-objektumok letölthetők legyenek, az issue-k, release-ek és felhasználói jogosultságok pedig megegyezzenek a mentés előtti állapottal. Minden futtatás során figyeld a repositoryk számát, a Git-objektumok packingjét, az LFS-tárhelyet, az adatbázis késleltetését és a runner terhelését a szokásos oldalbetöltések helyett, és a riasztást a tranzakció romlására, ne pedig az üresjárati konténermetrikákra alapozd.

Egy utolsó ellenőrzésnek szándékosan meg kell hibásodnia: ideiglenesen vond meg a tesztidentitás hozzáférését a Postgreshöz vagy a MySQL-hoz terheltebb telepítésnél, valamint szükség esetén az SSH-útvonalhoz. Ellenőrizd, hogy a létrejövő Gitea-üzenet azonosítja-e a releváns határt, ahelyett hogy adattörlést vagy végtelen újraindítást váltana ki. Állítsd vissza a helyes állapotot, és győződj meg róla, hogy ugyanaz a minta-tranzakció ismét sikeres. Ezt a rövid gyakorlatot tartsd meg a release-ellenőrzőlistán.

Gyakorold be a kockázatos Gitea-módosítást

A Gitea esetében processz helyett tranzakciót figyelj: klónozz HTTPS-en és SSH-n keresztül, pusholj egy commitot és egy LFS-objektumot, nyiss egy issue-t, és futtass egy jobot egy külön regisztrált Actions runneren. A késleltetést és a hibaarányt a repositoryk számával, a Git-objektumok packingjével, az LFS-tárhellyel, az adatbázis késleltetésével és a runner terhelésével együtt értékeld a szokásos oldalbetöltések helyett, hogy a riasztás azonosítani tudja a korlátozott erőforrást.

A frissítési próba során számolj azzal, hogy a séma-migrációk, a repository hookjai, a package-ek és a külső gyártótól származó runnerek fokozatos Gitea-frissítést igényelnek. Állítsd vissza az adatokat, migrálj, majd éles környezetben végrehajtott cseréjük előtt futtasd le a tranzakciót. Ha a ROOT_URL localhostos klónozási linkeket generál, vagy az SSH-port nincs továbbítva, ne töröld az adatokat csak azért, hogy az indulás sikeresnek tűnjön; ebben a sorrendben hasonlítsd össze a verziót, a változókat, a mountokat és a függőségek elérhetőségét.

Védd a Gitea értékes részét

Az első bejelentkezés után ellenőrizd, hogy egy anonim látogató, egy átlagos felhasználó és egy adminisztrátor pontosan milyen műveleteket végezhet. A Gitea esetében azt a hibát kell elkerülni, hogy az installer vagy az első adminisztrátori fiók a szükségesnél tovább elérhető maradjon. A kívánt szabályzat szerint a bootstrap után le kell zárni az installert, korlátozni kell a site administration hozzáférést, a runner-regisztrációs tokeneket pedig rövid élettartamúvá kell tenni.

A GITEA__security__SECRET_KEY értékét a Giteában betöltött szerepe szerint kezeld: az érzékeny értékeket tartsd távol a Gittől, dokumentáld a rotáció hatásait, és éles környezetben soha ne helyettesítsd nyilvános példával. A függőségekhez tartozó fiókokat válaszd külön az emberi fiókoktól, ahol lehetséges, tiltsd a nem használt kimenő kapcsolatokat, és a repositoryk száma, a Git-objektumok packingje, az LFS-tárhely, az adatbázis késleltetése és a runner terhelése által befolyásolt munkát korlátozd a szokásos oldalbetöltések helyett.

Mit automatizáljon a Dockup a Giteához?

A Dockup a Gitea esetében létrehozhatja az útvonalat és a TLS-tanúsítványt, megőrizheti a mountokat, átadhatja a secret értékeket, valamint privát hálózaton elhelyezheti a Postgrest vagy MySQL-t terheltebb telepítéshez és szükség esetén az SSH-útvonalat, miközben a telepítés történhet a Dockupon vagy csatolt szervereken.

A release-gate továbbra is a konkrét Gitea-tranzakció: klónozz HTTPS-en és SSH-n keresztül, pusholj egy commitot és egy LFS-objektumot, nyiss egy issue-t, és futtass egy jobot egy külön regisztrált Actions runneren. Ellenőrizd a helyreállítási feltételt is: a repositoryk menjenek át az fsck ellenőrzésen, az LFS-objektumok legyenek letölthetők, az issue-k, release-ek és felhasználói jogosultságok pedig egyezzenek a mentés előtti állapottal. Ez a két ellenőrzés mutatja meg, hogy a telepítés működik-e, illetve helyreállítható-e.

Gyakran ismételt kérdések

Mire van szüksége a Giteának éles környezetben?

A Gitea-konténert a 3000-es porton keresztül egyetlen HTTPS-origin mögött tedd elérhetővé. A támogató hálózati követelmény terheltebb telepítésnél a Postgres vagy MySQL, valamint szükség esetén egy SSH-útvonal. Ne tekintsd késznek a Giteát addig, amíg HTTPS-en és SSH-n keresztül nem tudsz klónozni, commitot és LFS-objektumot pusholni, issue-t nyitni, valamint egy jobot futtatni egy külön regisztrált Actions runneren.

Mely Gitea-adatoknak kell szerepelniük a biztonsági mentésben?

Tedd perzisztenssé a /data könyvtárat, és ugyanabba a helyreállítási manifestbe vedd fel a repositorykat, az LFS-objektumokat, a csatolmányokat, a konfigurációt és az adatbázist. A tiszta Gitea-visszaállítás csak akkor sikeres, ha a repositoryk átmennek az fsck ellenőrzésen, az LFS-objektumok letölthetők, az issue-k, release-ek és felhasználói jogosultságok pedig megegyeznek a mentés előtti állapottal.

Szüksége van a Giteának HTTPS-re reverse proxy mögött?

A nyilvános Gitea-originhez használj HTTPS-t, a 3000-es portot pedig tartsd a belső útvonalon. A Gitea-beállítást megfelelően alkalmazd: a ROOT_URL és az SSH_DOMAIN értéke legyen az a cím, amelyet a felhasználók ténylegesen használnak klónozáskor. A Gitea esetében a HTTPS védi az átvitt hitelesítő adatokat vagy felhasználói tartalmakat, és egységessé teszi az origintől függő kliensviselkedést.

Hogyan kell tesztelni egy Gitea-frissítést?

Állítsd vissza az aktuális Gitea-állapotot egy izolált telepítésbe, alkalmazd a kiadásra jelölt verziót, majd ismételd meg az átvételi tranzakciót. Különösen figyelj arra, hogy a séma-migrációk, a repository hookjai, a package-ek és a külső gyártótól származó runnerek fokozatos Gitea-frissítést igényelnek. Tartsd meg az előző Gitea-image-et addig, amíg nem tisztázott az adat-migráció és a rollback határa.