Wählen Sie die Kollaborationsebene
Forgejo und Gitea sind Beispiele für leichtgewichtige Forge-Software; reines SSH Git kann für einen kleineren Workflow ausreichen. Passen Sie Issues, Reviews, Paketspeicherung und Identitätsanforderungen an das Projekt an. Prüfen Sie die aktuell unterstützten Versionen und Lizenzen.
Builds von der Forge trennen
Ein CI-Runner führt projektgesteuerten Code aus und sollte keine uneingeschränkten Forge- oder Host-Anmeldedaten besitzen. Isolieren Sie Runner, begrenzen Sie Token und vermeiden Sie es, nicht vertrauenswürdige Jobs unter demselben privilegierten Konto wie der Repository-Dienst auszuführen.
Zugriff und Registrierung schützen
Deaktivieren Sie die öffentliche Registrierung, wenn der Dienst privat ist. Verwenden Sie individuelle Konten, starke Authentifizierung und sorgfältig begrenzte Deployment-Schlüssel. Dokumentieren Sie den SSH-Port und den Hostschlüssel; gewöhnen Sie Benutzer nicht stillschweigend daran, Hostschlüssel-Warnungen zu ignorieren.
Den vollständigen Dienst sichern
Repositories allein enthalten möglicherweise keine Issues, Konten, Anhänge und Konfiguration. Befolgen Sie das konsistente Backup-Verfahren der Forge und testen Sie eine Wiederherstellung mit intakten Dateiberechtigungen und Anwendungsgeheimnissen.
Eine Checkliste zur Forge-Wiederherstellung
Exportieren Sie die Datenbank konsistent und bewahren Sie Repository-Speicher, Anhänge, Großdateispeicher (falls aktiviert), Konfiguration und Verschlüsselungsgeheimnisse auf. Überprüfen Sie nach der Wiederherstellung einen Klon über die vorgesehene SSH- oder HTTPS-Route. Halten Sie die Forge und jeden CI-Worker isoliert, damit ein Build nicht die eigene Konfiguration des Dienstes überschreiben kann.
Bereitstellungsrechte eng halten
Ein schreibgeschützter Deployment-Schlüssel kann für einen Server ausreichen, der nur Code abruft. Eine Release-Automatisierung benötigt möglicherweise einen kleinen zusätzlichen Berechtigungsumfang. Bevorzugen Sie unabhängige Schlüssel für verschiedene Maschinen, dokumentieren Sie deren Zweck und entfernen Sie sie, wenn die Maschine außer Betrieb genommen wird.
Nutzen Sie den kleinsten passenden Kollaborationsdienst
Für einige wenige private Repositories kann reines Git über eingeschränktes SSH ausreichen. Forgejo oder Gitea fügen Konten, Pull Requests, Issues und optionale Pakete hinzu, auf Kosten einer Datenbank, Anwendungsupdates und mehr persistentem Zustand. Halten Sie fest, welche Funktionen das Team tatsächlich nutzen wird. Kalkulieren Sie Repository-Wachstum, Large-File-Objekte, Anhänge und Build-Artefakte separat ein; CI-Rechenleistung kann die Forge selbst übertreffen.
- Einen kanonischen HTTPS-Namen wählen und dessen DNS-Konto schützen.
- Entscheiden Sie, ob die Anmeldung geschlossen, einladungsbasiert oder moderiert ist.
- Geben Sie dem Forge-Dienst eine unprivilegierte Identität und dauerhaften privaten Speicher.
Offizielle Dokumentation: Forgejo-Container-Installation
Die Pfade für Web, SSH und Datenbank trennen
Verwenden Sie die Upstream-Konfiguration für die ausgewählte Version und legen Sie die vorgesehene Image-Version fest. Ein TLS-Reverse-Proxy sollte den internen Web-Listener erreichen; die Datenbank sollte nur von der Forge erreichbar sein. Wenn Git SSH einen Container-Port verwendet, halten Sie den angekündigten Host und den externen Port konsistent mit der Zuordnung. Ersetzen oder legen Sie beim Ändern der Forge nicht versehentlich den SSH-Listener des Host-Administrators offen. Schließen Sie den Installations-/Einrichtungszugang, sobald der erste Eigentümer erstellt ist.
- Prüfen Sie die Eigentümerschaft persistenter Volumes, bevor Sie die Anwendung starten.
- Verwenden Sie einen Datenbankbenutzer, der auf die Forge-Datenbank beschränkt ist.
- Halten Sie CI-Runner auf einer separaten Vertrauensgrenze, insbesondere für nicht vertrauenswürdige Repositories.
Offizielle Dokumentation: Forgejo-Docker-Netzwerk und Persistenz
Klonen, Push und eine verweigerte Operation überprüfen
Erstellen Sie ein temporäres privates Repository und testen Sie dessen HTTPS- oder SSH-Klon URL von einem normalen Entwicklerkonto. Committen und pushen Sie eine harmlose Datei und prüfen Sie dann, ob ein anderer autorisierter Leser sie abrufen kann. Ein nicht eingeladenes Konto muss beim Lesen des privaten Repositorys scheitern. Prüfen Sie die Handhabung großer Dateien und die Benachrichtigungs-E-Mail, falls aktiviert. Testen Sie für reine Deployment-Maschinen, dass ein schreibgeschützter Schlüssel abrufen und nicht pushen kann; ein erfolgreicher Authentifizierungsvorgang allein beweist nicht die beabsichtigte Berechtigungsgrenze.
# 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 -vStellen Sie die Diskussion ebenso wie das Repository wieder her
Erstellen Sie eine konsistente Anwendungs-/Datenbank-Sicherung, Repository-Speicher, Anhänge, LFS-Daten, Konfiguration und erforderliche Verschlüsselungsgeheimnisse. Folgen Sie dem Sicherungsverfahren der installierten Forge-Version; Gitea-Sicherungsbefehle sind nicht automatisch mit jeder Forgejo-Version austauschbar. Bauen Sie isoliert neu auf und verifizieren Sie ein Issue, einen Anhang, eine Anmeldung und einen Clone. Wenn Push nach einem Umzug fehlschlägt, prüfen Sie SSH Host/Port, Schlüsselzuordnung, Speicherberechtigungen und beworbene Clone-URLs, bevor Sie Repository-Berechtigungen global ändern.
Offizielle Dokumentation: Gitea-Backup und -Wiederherstellung