En liten smedja du kan bygga upp igen.

Välj samarbetslagret

Forgejo och Gitea är exempel på lättvikts-forge-programvara; vanlig SSH Git kan räcka för ett mindre arbetsflöde. Anpassa ärenden, granskningar, paketlagring och identitetskrav till projektet. Verifiera aktuella versioner som stöds och licenser.

Separera byggen från smidesplatsen

En CI-runner kör projektkontrollerad kod och bör inte inneha obegränsade forge- eller värdautentiseringsuppgifter. Isolera runners, begränsa tokens och undvik att köra ej betrodda jobb på samma privilegierade konto som lagringstjänsten.

Skydda åtkomst och registrering

Inaktivera offentlig registrering när tjänsten är privat. Använd individuella konton, stark autentisering och noggrant avgränsade distributionsnycklar. Dokumentera SSH-porten och värdnyckeln; träna inte användare i tysthet att ignorera varningar om värdnycklar.

Säkerhetskopiera hela tjänsten

Enbart kodförråd kanske inte omfattar ärenden, konton, bilagor och konfiguration. Följ forge-plattformens konsekventa säkerhetskopieringsrutin och testa en återställning med filbehörigheter och applikationshemligheter intakta.

En återställningschecklista för forge

Exportera databasen konsekvent och bevara förvarslagring, bilagor, storskalig fillagring om aktiverad, konfiguration och krypteringshemligheter. Verifiera en klon över den avsedda SSH- eller HTTPS-vägen efter återställning. Håll smidesplatsen och eventuella CI-arbetare isolerade så att ett bygge inte kan skriva över tjänstens egen konfiguration.

Håll distributionsrättigheterna snäva

En skrivskyddad distributionsnyckel kan räcka för en server som bara hämtar kod. En releaseautomatisering kan behöva en liten ytterligare behörighet. Föredra oberoende nycklar för olika maskiner, dokumentera deras syfte och ta bort dem när maskinen avvecklas.

Använd den minsta samarbetstjänst som passar

För några få privata arkiv kan bare Git över begränsad SSH vara tillräckligt. Forgejo eller Gitea tillför konton, pull requests, ärenden och valfria paket till priset av en databas, applikationsuppdateringar och mer beständigt tillstånd. Dokumentera vilka funktioner teamet faktiskt kommer att använda. Budgetera arkivtillväxt, stora filobjekt, bilagor och byggartefakter separat; CI-beräkning kan överstiga själva forgen.

• Välj ett kanoniskt HTTPS namn och skydda dess DNS konto.
• Bestäm om registrering är stängd, inbjudningsbaserad eller modererad.
• Ge forge-tjänsten en oprivilegierad identitet och varaktig privat lagring.

Officiell dokumentation: Forgejo-containerinstallation

Separera webb-, SSH- och databassökvägarna

Använd den uppströmskonfiguration som hör till den valda versionen och lås den avsedda avbildningsversionen. En TLS omvänd proxy bör nå den interna webbservern; databasen bör endast vara nåbar av forge. Om Git SSH använder en containerport, håll dess annonserade värd och externa port konsekventa med mappningen. Byt inte ut eller exponera av misstag värdadministratörens SSH lyssnare när du ändrar forge. Stäng installations-/konfigurationsåtkomsten när den första ägaren har skapats.

• Kontrollera ägandet av beständiga volymer innan applikationen startas.
• Använd en databasanvändare som är begränsad till forge-databasen.
• Håll CI-runners på en separat förtroendegräns, särskilt för ej betrodda förråd.

Officiell dokumentation: Forgejo Docker-nätverk och persistens

Verifiera kloning, push och en nekad åtgärd

Skapa ett tillfälligt privat arkiv och testa dess HTTPS- eller SSH-klon URL från ett vanligt utvecklarkonto. Checka in och pusha en ofarlig fil och verifiera sedan att en annan behörig läsare kan hämta den. Ett konto som inte bjudits in måste misslyckas med att läsa det privata arkivet. Kontrollera hantering av stora filer och aviseringsmejl om det är aktiverat. För maskiner som endast används för driftsättning, testa att en skrivskyddad nyckel kan hämta men inte pusha; en lyckad autentisering ensam bevisar inte den avsedda behörighetsgränsen.

# 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 -v

Återställ diskussionen liksom kodförrådet

Ta en konsekvent säkerhetskopia av applikation/databas, kodförrådslagring, bilagor, LFS-data, konfiguration och nödvändiga krypteringshemligheter. Följ backupförfarandet för den installerade forge-versionen; Gitea-backupkommandon är inte automatiskt utbytbara med varje Forgejo-version. Bygg om i isolering och verifiera ett ärende, en bilaga, inloggning och en klon. Om push misslyckas efter en flytt, kontrollera SSH värd/port, nyckelmappning, lagringsbehörigheter och annonserade klon-URLs innan du ändrar kodförrådets behörigheter globalt.

Officiell dokumentation: Säkerhetskopiering och återställning av Gitea