Slik drifter du Gitea selv i 2026: repositories, SSH og trygge oppgraderinger

Hvis du allerede har prøvd å drifte Gitea selv, kjenner du sannsynligvis denne frustrerende situasjonen: Grensesnittet vises, men ROOT_URL genererer localhost-lenker for kloning, eller SSH-porten blir ikke videresendt. Å opprette containeren på nytt løser sjelden uoverensstemmelser mellom URL-er, state og avhengigheter.

Denne gjennomgangen bruker ett konkret ferdigkriterium — klon over HTTPS og SSH, push en commit og et LFS-objekt, åpne en issue og kjør én jobb på en separat registrert Actions-runner. Hvert konfigurasjonsvalg vurderes opp mot dette kriteriet, ikke ut fra et grønt containermerke.

Finn alle persistente data i Gitea

Kartlegg state før den første reelle posten opprettes: repositories, LFS-objekter, vedlegg, konfigurasjon og database. Monter /data før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Bekreft monteringen ved å skrive ufarlige data, erstatte Gitea og lese dataene tilbake.

Snapshots er nyttige for rask rollback, men du trenger en uavhengig backup når verten eller volumet forsvinner. Gjenopprett til et tomt miljø med det pinnede imaget, og bekreft at repositories består fsck, at LFS-objekter kan lastes ned, og at issues, releases og brukertillatelser samsvarer med tilstanden før backupen. Bruk persistente volumer og snapshots for å holde disse to gjenopprettingsmekanismene adskilt.

Bygg en Gitea-container som kan erstattes

Følgende kommando synliggjør containergrensen uten å late som den setter opp alle eksterne tjenester.

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

Før du åpner ingress, inspiser det evaluerte miljøet, monteringer og listeneren. Legg til de gjennomgåtte tilkoblingsinnstillingene for Postgres eller MySQL for en mer omfattende installasjon, samt en SSH-rute ved behov; bruk private navn for private tjenester. En vellykket oppstart er fullført når du kan klone over HTTPS og SSH, pushe en commit og et LFS-objekt, åpne en issue og kjøre én jobb på en separat registrert Actions-runner — ikke når docker ps skriver ut Up.

Skill Gitea fra avhengighetene

Prosesshelse og produkthelse er separate ting for Gitea. Port 3000 kan svare selv om den brukerrettede transaksjonen fortsatt feiler. Nettverkskontrakten for Gitea er Postgres eller MySQL for en mer omfattende installasjon, samt en SSH-rute ved behov. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Gitea en tjenestekredential med begrenset tilgang.

Bruk denne readiness-øvelsen etter meningsfulle konfigurasjonsendringer: klon over HTTPS og SSH, push en commit og et LFS-objekt, åpne en issue og kjør én jobb på en separat registrert Actions-runner. Hold kostbare eksterne kontroller ute av liveness-prober, slik at et leverandørutfall ikke fører til en restart-loop. Kapasitetsarbeid bør følge med på antall repositories, Git object packing, LFS-lagring, databaseforsinkelse og runner-belastning i stedet for vanlige sideforespørsler. Dette ligger nærmere Giteas reelle belastning enn sideforespørsler.

TLS er enkelt; genererte URL-er er det ikke

Eksponer ett HTTPS-vertsnavn for Gitea, og hold råport 3000 privat. Angi ROOT_URL og SSH_DOMAIN til adressene brukerne faktisk kloner fra. Dette hindrer nettlesere og API-klienter i å lære to konkurrerende adresser.

Kjør den kjente, fungerende transaksjonen fra en ren klient, og inspiser den første forespørselen som feiler. Bruk veiledningen for egendefinert domene når DNS eller TLS er feil. Behandle «ROOT_URL genererer localhost-lenker for kloning, eller SSH-porten blir ikke videresendt» som en separat applikasjonsdiagnose når ruten er bekreftet.

Verifiser Gitea-distribusjonen fra ende til ende

Ikke bruk trafikk fra den første brukeren som akseptansetest for Gitea. Forbered ufarlig eksempel-state og kjør hele handlingen «klon over HTTPS og SSH, push en commit og et LFS-objekt, åpne en issue og kjør én jobb på en separat registrert Actions-runner». Noter den nøyaktige offentlige URL-en, resultatet, imagereferansen og loggintervallet som er knyttet til kjøringen.

Erstatt containeren og gjenta uten å bygge dataene på nytt. Gjenopprett deretter til en tom vert; gjenopprettingskravet er at repositories består fsck, at LFS-objekter kan lastes ned, og at issues, releases og brukertillatelser samsvarer med tilstanden før backupen. Følg med på antall repositories, Git object packing, LFS-lagring, databaseforsinkelse og runner-belastning i stedet for vanlige sideforespørsler i hver gjennomkjøring, og definer et alert rundt forringelse av transaksjonen i stedet for inaktive containermålinger.

Én siste kontroll bør feile med hensikt: nekt testidentiteten midlertidig tilgang til Postgres eller MySQL for en mer omfattende installasjon, samt en SSH-rute ved behov. Bekreft at den resulterende Gitea-meldingen identifiserer den relevante grensen, i stedet for å utløse sletting av data eller en endeløs restart. Gjenopprett den gyldige tilstanden og bekreft at den samme eksempeltransaksjonen lykkes. Behold denne korte øvelsen i release-sjekklisten.

Øv på den risikable Gitea-endringen

For Gitea bør du overvåke en transaksjon i stedet for en prosess: klon over HTTPS og SSH, push en commit og et LFS-objekt, åpne en issue og kjør én jobb på en separat registrert Actions-runner. Kombiner transaksjonens responstid og feilrate med antall repositories, Git object packing, LFS-lagring, databaseforsinkelse og runner-belastning i stedet for vanlige sideforespørsler, slik at et alert identifiserer den begrensede komponenten.

Oppgraderingsøvelsen må ta høyde for at schema migrations, repository hooks, packages og tredjeparts-runnere krever en trinnvis Gitea-oppgradering. Gjenopprett, migrer og kjør transaksjonen før du erstatter produksjonen. Hvis ROOT_URL genererer localhost-lenker for kloning, eller SSH-porten ikke blir videresendt, må du ikke slette data for å få en grønn oppstart; sammenlign versjon, variabler, monteringer og tilgjengelighet til avhengighetene i denne rekkefølgen.

Beskytt den verdifulle delen av Gitea

Etter den første innloggingen bør du gå gjennom hva en anonym besøkende, en vanlig bruker og en administrator kan gjøre. Gitea-feilen du bør unngå, er å la installasjonsprogrammet eller den første admin-kontoen være tilgjengelig lenger enn nødvendig. Den tiltenkte policyen er å stenge installasjonsprogrammet etter bootstrap, begrense administrasjon av nettstedet og holde registreringstokener for runnere kortvarige.

Behandle GITEA__security__SECRET_KEY i tråd med Gitea-rollen: hold sensitive verdier ute av Git, dokumenter konsekvensene av rotasjon og bruk aldri et offentlig eksempel i produksjon. Hold avhengighetskontoer adskilt fra menneskelige kontoer, nekt unødvendig egress der det er praktisk, og begrens arbeid som påvirkes av antall repositories, Git object packing, LFS-lagring, databaseforsinkelse og runner-belastning i stedet for vanlige sideforespørsler.

Hva Dockup bør automatisere for Gitea

For Gitea kan Dockup opprette ruten og TLS-sertifikatet, bevare monteringer, levere secrets og plassere Postgres eller MySQL for en mer omfattende installasjon, samt en SSH-rute ved behov, på private nettverk mens løsningen distribueres til enten Dockup eller tilkoblede servere.

Release-gaten er fortsatt den konkrete Gitea-transaksjonen: klon over HTTPS og SSH, push en commit og et LFS-objekt, åpne en issue og kjør én jobb på en separat registrert Actions-runner. Bekreft også gjenopprettingskravet — repositories består fsck, LFS-objekter kan lastes ned, og issues, releases og brukertillatelser samsvarer med tilstanden før backupen. Disse to kontrollene viser om distribusjonen fungerer, og om den kan gjenopprettes.

Vanlige spørsmål

Hva trenger Gitea for en produksjonsdistribusjon?

Rout Gitea-containeren på port 3000 gjennom én HTTPS-origin. Det støttende nettverkskravet er Postgres eller MySQL for en mer omfattende installasjon, samt en SSH-rute ved behov. Ikke erklær Gitea som klar før du kan klone over HTTPS og SSH, pushe en commit og et LFS-objekt, åpne en issue og kjøre én jobb på en separat registrert Actions-runner.

Hvilke Gitea-data hører hjemme i en backup?

Gjør /data persistent, og inkluder repositories, LFS-objekter, vedlegg, konfigurasjon og database i det samme gjenopprettingsmanifestet. En ren Gitea-gjenoppretting er bare vellykket når repositories består fsck, LFS-objekter kan lastes ned, og issues, releases og brukertillatelser samsvarer med tilstanden før backupen.

Krever Gitea HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Gitea-originen, og hold port 3000 på den interne ruten. Bruk Gitea-innstillingen riktig: angi ROOT_URL og SSH_DOMAIN til adressene brukerne faktisk kloner fra. For Gitea beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsekvent klientatferd som er avhengig av origin.

Hvordan bør en Gitea-oppgradering testes?

Gjenopprett den gjeldende Gitea-tilstanden til en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at schema migrations, repository hooks, packages og tredjeparts-runnere krever en trinnvis Gitea-oppgradering. Behold det forrige Gitea-imaget til grensen for datamigrering og rollback er forstått.