Vælg samarbejdslaget
Forgejo og Gitea er eksempler på letvægts-forge-software; almindelig SSH Git kan være nok til en mindre arbejdsgang. Match issues, reviews, pakkelagring og identitetskrav til projektet. Verificér aktuelle understøttede versioner og licenser.
Adskil builds fra forge
En CI-runner udfører projektstyret kode og bør ikke have ubegrænsede forge- eller host-legitimationsoplysninger. Isolér runners, begræns tokens og undgå at køre ikke-betroede jobs på samme privilegerede konto som repository-tjenesten.
Beskyt adgang og registrering
Deaktiver offentlig tilmelding, når tjenesten er privat. Brug individuelle konti, stærk godkendelse og omhyggeligt afgrænsede deployment-nøgler. Dokumentér SSH-porten og host-nøglen; undlad i det stille at træne brugere til at ignorere host-key-advarsler.
Sikkerhedskopier hele tjenesten
Kun repositories indeholder muligvis ikke issues, konti, vedhæftede filer og konfiguration. Følg forge'ens konsistente backup-procedure, og test en gendannelse med filrettigheder og applikationshemmeligheder intakte.
En tjekliste til gendannelse af forge
Eksportér databasen konsistent, og bevar repository-lager, vedhæftede filer, stort fil-lager hvis aktiveret, konfiguration og krypteringshemmeligheder. Bekræft en klon over den tilsigtede SSH eller HTTPS-rute efter gendannelse. Hold forge og eventuel CI-worker isoleret, så et build ikke kan overskrive tjenestens egen konfiguration.
Hold udrulningsrettigheder snævre
En skrivebeskyttet udrulningsnøgle kan være tilstrækkelig til en server, der kun henter kode. En release-automatisering kan kræve et lille ekstra omfang. Foretræk uafhængige nøgler til forskellige maskiner, registrer deres formål, og fjern dem, når maskinen tages ud af drift.
Brug den mindste samarbejdstjeneste, der passer
For få private repositories kan bare Git over begrænset SSH være tilstrækkeligt. Forgejo eller Gitea tilføjer konti, pull requests, issues og valgfrie pakker på bekostning af en database, applikationsopdateringer og mere vedvarende tilstand. Notér, hvilke funktioner teamet faktisk vil bruge. Budgetlæg repository-vækst, store filobjekter, vedhæftninger og build-artefakter separat; CI-compute kan overstige selve forge'en.
- Vælg et kanonisk HTTPS-navn, og beskyt dens DNS-konto.
- Beslut, om tilmelding er lukket, invitationsbaseret eller modereret.
- Giv forge-tjenesten en uprivilegeret identitet og holdbar privat lagring.
Officiel dokumentation: Forgejo-containerinstallation
Adskil web-, SSH- og databasestierne
Brug upstream-konfigurationen til den valgte udgivelse, og fastlås den tilsigtede image-version. En TLS reverse proxy bør kunne nå den interne weblytter; databasen bør kun kunne nås af forge. Hvis Git SSH bruger en containerport, skal dens annoncerede vært og eksterne port være i overensstemmelse med mappingen. Erstat eller eksponér ikke ved et uheld værtens administrator-SSH-lytter, mens du ændrer forge. Luk adgangen til installation/opsætning, når den oprindelige ejer er oprettet.
- Kontroller ejerskab af persistent volume, før applikationen startes.
- Brug en databasebruger, der er begrænset til forge-databasen.
- Hold CI-runnere på en separat tillidsgrænse, især for ikke-betroede repositories.
Officiel dokumentation: Forgejo Docker-netværk og persistens
Verificér kloning, push og en afvist handling
Opret et midlertidigt privat repository, og test dets HTTPS- eller SSH-klon URL fra en almindelig udviklerkonto. Commit og push en uskadelig fil, og bekræft derefter, at en anden autoriseret læser kan hente den. En ikke-inviteret konto skal ikke kunne læse det private repository. Kontroller håndtering af store filer og notifikations-e-mail, hvis aktiveret. For maskiner, der kun bruges til udrulning, skal du teste, at en skrivebeskyttet nøgle kan hente og ikke kan pushe; en vellykket godkendelse alene beviser ikke den tilsigtede tilladelsesgrænse.
# Use the disposable repository URL advertised by your forge:
git clone ssh://[email protected]:2222/team/check.git
# In a clone, inspect which remote is configured:
git remote -vGendan diskussionen såvel som repositoryet
Tag en konsistent sikkerhedskopi af applikation/database, repository-lagring, vedhæftede filer, LFS-data, konfiguration og nødvendige krypteringshemmeligheder. Følg backup-proceduren for den installerede forge-version; Gitea-backupkommandoer kan ikke automatisk udskiftes med enhver Forgejo-udgivelse. Genopbyg isoleret, og verificér et issue, en vedhæftet fil, login og kloning. Hvis push fejler efter en flytning, skal du kontrollere SSH-vært/port, nøglemapping, lagerrettigheder og annoncerede klon-URLer, før du ændrer repository-rettigheder globalt.
Officiel dokumentation: Gitea backup og gendannelse