Gitean itsehostaus vuonna 2026: repositoriot, SSH ja turvalliset päivitykset

Jos olet jo yrittänyt hostata Giteaa itse, tämä turhauttava tilanne on todennäköisesti tuttu: käyttöliittymä avautuu, mutta ROOT_URL tuottaa localhost-muotoisia kloonauslinkkejä tai SSH-porttia ei ole välitetty. Säiliön luominen uudelleen korjaa harvoin URL-osoitteiden, tilan ja riippuvuuksien välisen ristiriidan.

Tässä ohjeessa käytetään yhtä konkreettista valmistumiskriteeriä: kloonaa HTTPS:n ja SSH:n kautta, puske commit ja LFS-objekti, avaa issue ja suorita yksi työ erikseen rekisteröidyllä Actions-runnerilla. Jokainen määritysvalinta arvioidaan tämän kriteerin, ei vihreän säiliömerkin perusteella.

Selvitä jokainen Gitean säilytettävä tavu

Listaa tila ennen ensimmäisen varsinaisen tietueen luomista: repositoriot, LFS-objektit, liitteet, määritykset ja tietokanta. Liitä /data ennen alustusta, kirjoita sinne harmitonta esimerkkidataa ja vaihda säiliö varmistaaksesi, että polku on todella pysyvä. Vahvista liitos kirjoittamalla harmitonta dataa, vaihtamalla Gitea-säiliö ja lukemalla data takaisin.

Snapshotit ovat hyödyllisiä nopeaan palautukseen, mutta erillinen varmuuskopio tarvitaan, jos host tai volume katoaa. Palauta data tyhjään ympäristöön kiinnitetyllä imagella ja varmista, että repositoriot läpäisevät fsck-tarkistuksen, LFS-objektit latautuvat ja issuet, julkaisut sekä käyttäjäoikeudet vastaavat varmuuskopiointia edeltänyttä tilaa. Käytä persistent volumes and snapshots -ohjetta pitääksesi nämä kaksi palautusmekanismia erillään.

Rakenna korvattava Gitea-säiliö

Seuraava komento tekee säiliön rajapinnan näkyväksi yrittämättä esittää, että kaikki ulkoiset palvelut otetaan käyttöön.

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

Tarkista ennen ingressin avaamista ratkaistu ympäristö, liitokset ja kuuntelija. Lisää Postgres- tai MySQL-yhteyden tarkistetut asetukset vilkkaampaa asennusta varten sekä tarvittaessa SSH-reitti; käytä yksityisille palveluille yksityisiä nimiä. Käynnistys on onnistunut vasta, kun voit kloonata HTTPS:n ja SSH:n kautta, puskea commitin ja LFS-objektin, avata issuen ja suorittaa yhden työn erikseen rekisteröidyllä Actions-runnerilla – ei silloin, kun docker ps tulostaa Up.

Pidä Gitea ja sen riippuvuudet erillään

Prosessin toimintakunto ja tuotteen toimintakunto ovat Giteassa eri asioita. Portti 3000 voi vastata, vaikka käyttäjän käynnistämä toiminto epäonnistuisi edelleen. Gitean verkkosopimukseen kuuluvat Postgres tai MySQL vilkkaampaa asennusta varten sekä tarvittaessa SSH-reitti. Pidä yksityiset päätepisteet sisäisessä DNS:ssä, salli vain tarvittavat lähtevät yhteydet ja anna Gitealle rajatuilla oikeuksilla varustettu service credential.

Käytä tätä valmiusharjoitusta merkittävien määritysmuutosten jälkeen: kloonaa HTTPS:n ja SSH:n kautta, puske commit ja LFS-objekti, avaa issue ja suorita yksi työ erikseen rekisteröidyllä Actions-runnerilla. Pidä raskaat ulkoiset tarkistukset erillään liveness-probeista, jotta palveluntarjoajan häiriö ei aiheuta restart loopia. Kapasiteettia kannattaa seurata repositorioiden määrän, Git-objektien pakkaamisen, LFS-tallennustilan, tietokannan latenssin ja runner-kuorman perusteella tavallisten sivupyyntöjen sijaan, sillä tämä vastaa paremmin Gitean todellista kuormitusta kuin sivupyynnöt.

TLS on helppo; generoidut URL-osoitteet eivät

Aseta Gitealle yksi HTTPS-hostname ja pidä raaka portti 3000 yksityisenä. Aseta ROOT_URL ja SSH_DOMAIN osoitteisiin, joita käyttäjät todella käyttävät kloonaukseen. Näin selaimet ja API-asiakkaat eivät opi kahta keskenään kilpailevaa osoitetta.

Suorita tunnetusti toimiva toiminto puhtaalta clientilta ja tarkista ensimmäinen epäonnistuva pyyntö. Käytä custom-domain guide -ohjetta, jos DNS tai TLS on väärin määritetty. Käsittele tilanne ”ROOT_URL tuottaa localhost-muotoisia kloonauslinkkejä tai SSH-porttia ei ole välitetty” erillisenä sovellusdiagnoosina vasta, kun reitin toimivuus on todistettu.

Todista Gitea-käyttöönotto päästä päähän

Älä käytä ensimmäisen käyttäjän liikennettä Gitean hyväksymistestinä. Valmistele harmiton esimerkkitila ja suorita koko toiminto ”kloonaa HTTPS:n ja SSH:n kautta, puske commit ja LFS-objekti, avaa issue ja suorita yksi työ erikseen rekisteröidyllä Actions-runnerilla”. Kirjaa suoritukseen liittyvä tarkka julkinen URL, tulos, image-viite ja lokijakso.

Vaihda säiliö ja toista testi rakentamatta dataa uudelleen. Palauta seuraavaksi ympäristö tyhjälle hostille; palautuksen edellytyksenä on, että repositoriot läpäisevät fsck-tarkistuksen, LFS-objektit latautuvat ja issuet, julkaisut sekä käyttäjäoikeudet vastaavat varmuuskopiointia edeltänyttä tilaa. Seuraa jokaisella kierroksella repositorioiden määrää, Git-objektien pakkaamista, LFS-tallennustilaa, tietokannan latenssia ja runner-kuormaa tavallisten sivupyyntöjen sijaan, ja määritä hälytys toiminnon heikkenemisen, ei joutilaiden säiliömittareiden perusteella.

Yhden viimeisen tarkistuksen pitäisi epäonnistua tarkoituksella: estä testikäyttäjän pääsy Postgresiin tai MySQL:ään vilkkaampaa asennusta varten sekä tarvittaessa SSH-reitille. Varmista, että syntyvä Gitea-viesti tunnistaa oikean rajapinnan eikä käynnistä datan poistamista tai loputonta restart loopia. Palauta toimiva tila ja varmista, että sama esimerkkitoiminto onnistuu. Pidä tämä lyhyt harjoitus mukana release-tarkistuslistassa.

Harjoittele riskialtis Gitea-muutos

Seuraa Gitean osalta toimintoa prosessin sijaan: kloonaa HTTPS:n ja SSH:n kautta, puske commit ja LFS-objekti, avaa issue ja suorita yksi työ erikseen rekisteröidyllä Actions-runnerilla. Yhdistä sen latenssi ja virheprosentti repositorioiden määrään, Git-objektien pakkaamiseen, LFS-tallennustilaan, tietokannan latenssiin ja runner-kuormaan tavallisten sivupyyntöjen sijaan, jotta hälytys tunnistaa rajoittavan komponentin.

Päivitysharjoituksen on katettava se, että skeeman migraatiot, repository hookit, paketit ja kolmannen osapuolen runnerit edellyttävät vaiheistettua Gitea-päivitystä. Palauta data, suorita migraatiot ja aja toiminto ennen tuotantokorvausta. Jos ROOT_URL tuottaa localhost-muotoisia kloonauslinkkejä tai SSH-porttia ei ole välitetty, älä poista dataa saadaksesi käynnistyksen näyttämään onnistuneelta; vertaa versiota, muuttujia, liitoksia ja riippuvuuksien tavoitettavuutta tässä järjestyksessä.

Suojaa Gitean arvokas osa

Tarkista ensimmäisen kirjautumisen jälkeen, mitä anonyymi vierailija, tavallinen käyttäjä ja ylläpitäjä voivat kukin tehdä. Gitean vältettävä vikatilanne on se, että asennusohjelma tai ensimmäinen admin-tili jää saavutettavaksi tarpeettoman pitkäksi aikaa. Suunniteltu käytäntö on sulkea asennusohjelma alustuksen jälkeen, rajoittaa sivuston hallintaa ja pitää runnerien rekisteröintitunnisteet lyhytikäisinä.

Käsittele GITEA__security__SECRET_KEY-muuttujaa sen Gitea-roolin mukaisesti: pidä arkaluonteiset arvot poissa Gitistä, dokumentoi kierrätyksen vaikutukset äläkä koskaan käytä julkista esimerkkiä tuotannossa. Pidä riippuvuuksien tilit erillään henkilökohtaisista tileistä, estä käyttämätön lähtevä liikenne mahdollisuuksien mukaan ja rajoita repositorioiden määrän, Git-objektien pakkaamisen, LFS-tallennustilan, tietokannan latenssin ja runner-kuorman vaikutusta tavallisten sivupyyntöjen sijaan.

Mitä Dockupin pitäisi automatisoida Giteaa varten

Gitean tapauksessa Dockup voi luoda reitin ja TLS-varmenteen, säilyttää liitokset, välittää salaisuudet ja sijoittaa Postgresin tai MySQL:n vilkkaampaa asennusta varten sekä tarvittaessa SSH-reitin yksityiseen verkkoon, kun käyttöönotto tehdään joko Dockupiin tai liitettyihin palvelimiin.

Release-portti perustuu silti konkreettiseen Gitea-toimintoon: kloonaa HTTPS:n ja SSH:n kautta, puske commit ja LFS-objekti, avaa issue ja suorita yksi työ erikseen rekisteröidyllä Actions-runnerilla. Vahvista myös palautusehto: repositoriot läpäisevät fsck-tarkistuksen, LFS-objektit latautuvat ja issuet, julkaisut sekä käyttäjäoikeudet vastaavat varmuuskopiointia edeltänyttä tilaa. Nämä kaksi tarkistusta osoittavat, toimiiko käyttöönotto ja voidaanko se palauttaa.

Usein kysytyt kysymykset

Mitä Gitea tarvitsee tuotantokäyttöönottoon?

Reititä Gitea-säiliö portista 3000 yhden HTTPS-originin kautta. Tukiverkon vaatimus on Postgres tai MySQL vilkkaampaa asennusta varten sekä tarvittaessa SSH-reitti. Älä kutsu Giteaa valmiiksi, ennen kuin voit kloonata HTTPS:n ja SSH:n kautta, puskea commitin ja LFS-objektin, avata issuen ja suorittaa yhden työn erikseen rekisteröidyllä Actions-runnerilla.

Mitkä Gitean tiedot kuuluvat varmuuskopioon?

Säilytä /data ja sisällytä repositoriot, LFS-objektit, liitteet, määritykset ja tietokanta samaan palautusmanifestiin. Puhdas Gitea-palautus onnistuu vasta, kun repositoriot läpäisevät fsck-tarkistuksen, LFS-objektit latautuvat ja issuet, julkaisut sekä käyttäjäoikeudet vastaavat varmuuskopiointia edeltänyttä tilaa.

Vaatiiko Gitea HTTPS:ää reverse proxyn takana?

Käytä julkisessa Gitea-originissa HTTPS:ää ja pidä portti 3000 sisäisessä reitissä. Määritä Gitean asetus oikein: aseta ROOT_URL ja SSH_DOMAIN osoitteisiin, joita käyttäjät todella käyttävät kloonaukseen. Gitean tapauksessa HTTPS suojaa tunnistetietoja ja käyttäjäsisältöä siirron aikana sekä pitää origin-riippuvaisen client-käyttäytymisen yhdenmukaisena.

Miten Gitean päivitys pitäisi testata?

Palauta nykyinen Gitea-tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista sen hyväksymistoiminto. Kiinnitä erityistä huomiota siihen, että skeeman migraatiot, repository hookit, paketit ja kolmannen osapuolen runnerit edellyttävät vaiheistettua Gitea-päivitystä. Säilytä edellinen Gitea-image, kunnes sen datamigraation ja rollbackin rajat ovat selvillä.