Choisissez la couche de collaboration
Forgejo et Gitea sont des exemples de logiciels de forge légers ; un simple Git SSH peut suffire pour un flux de travail plus modeste. Adaptez les tickets, les revues, le stockage de paquets et les exigences d'identité au projet. Vérifiez les versions prises en charge et les licences actuelles.
Séparez les builds de la forge
Un runner CI exécute du code contrôlé par le projet et ne doit pas détenir d'identifiants de forge ou d'hôte non restreints. Isolez les runners, limitez la portée des jetons et évitez d'exécuter des tâches non fiables sur le même compte privilégié que le service de dépôt.
Protéger l'accès et l'inscription
Désactivez l'inscription publique lorsque le service est privé. Utilisez des comptes individuels, une authentification forte et des clés de déploiement soigneusement limitées. Documentez le port SSH et la clé d'hôte ; n'habituez pas silencieusement les utilisateurs à ignorer les avertissements de clé d'hôte.
Sauvegardez le service complet
Les dépôts seuls peuvent ne pas inclure les tickets, les comptes, les pièces jointes et la configuration. Suivez la procédure de sauvegarde cohérente de la forge et testez une restauration en conservant les permissions de fichiers et les secrets applicatifs.
Une liste de contrôle de récupération de forge
Exportez la base de données de manière cohérente et conservez le stockage du dépôt, les pièces jointes, le stockage de fichiers volumineux si activé, la configuration et les secrets de chiffrement. Vérifiez un clone via la route SSH ou HTTPS prévue après restauration. Isolez la forge et tout worker CI afin qu'une compilation ne puisse pas réécrire la configuration du service lui-même.
Limitez les droits de déploiement
Une clé de déploiement en lecture seule peut suffire pour un serveur qui ne fait que récupérer du code. Une automatisation de release peut nécessiter un léger périmètre supplémentaire. Privilégiez des clés indépendantes pour chaque machine, consignez leur usage et supprimez-les lorsque la machine est retirée.
Utilisez le service de collaboration le plus léger qui convienne
Pour quelques dépôts privés, un Git nu sur SSH restreint peut suffire. Forgejo ou Gitea ajoute des comptes, des pull requests, des tickets et des paquets optionnels au prix d'une base de données, de mises à jour applicatives et d'un état persistant plus important. Notez les fonctionnalités que l'équipe utilisera réellement. Budgétez séparément la croissance des dépôts, les objets volumineux, les pièces jointes et les artefacts de build ; le calcul CI peut dépasser le forge lui-même.
- Choisissez un nom HTTPS canonique et protégez son compte DNS.
- Déterminez si l'inscription est fermée, sur invitation ou modérée.
- Attribuez au service de forge une identité non privilégiée et un stockage privé durable.
Documentation officielle : Installation du conteneur Forgejo
Séparez les chemins web, SSH et base de données
Utilisez la configuration amont de la version sélectionnée et épinglez la version d'image prévue. Un reverse proxy TLS doit joindre l'écouteur web interne ; la base de données ne doit être accessible que par la forge. Si Git SSH utilise un port de conteneur, maintenez son hôte annoncé et son port externe cohérents avec le mappage. Ne remplacez pas et n'exposez pas accidentellement l'écouteur SSH de l'administrateur de l'hôte lors du changement de forge. Fermez l'accès d'installation/configuration une fois le propriétaire initial créé.
- Vérifiez la propriété du volume persistant avant de démarrer l’application.
- Utilisez un utilisateur de base de données restreint à la base de données de la forge.
- Gardez les runners CI sur une frontière de confiance séparée, en particulier pour les dépôts non fiables.
Documentation officielle : Réseau Docker et persistance de Forgejo
Vérifiez le clonage, le push et une opération refusée
Créez un dépôt privé jetable et testez son clone HTTPS ou SSH URL depuis un compte développeur normal. Validez et poussez un fichier inoffensif, puis vérifiez qu’un autre lecteur autorisé peut le récupérer. Un compte non invité doit échouer à lire le dépôt privé. Vérifiez la gestion des fichiers volumineux et l’e-mail de notification s’il est activé. Pour les machines dédiées au déploiement, testez qu’une clé en lecture seule peut récupérer et ne peut pas pousser ; un simple succès d’authentification ne prouve pas la frontière de permission voulue.
# 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 -vRécupérez la discussion ainsi que le dépôt
Effectuez une sauvegarde cohérente de l'application et de la base de données, du stockage du dépôt, des pièces jointes, des données LFS, de la configuration et des secrets de chiffrement requis. Suivez la procédure de sauvegarde de la version de forge installée ; les commandes de sauvegarde Gitea ne sont pas automatiquement interchangeables avec chaque version de Forgejo. Reconstruisez en isolation et vérifiez un ticket, une pièce jointe, une connexion et un clone. Si le push échoue après un déplacement, vérifiez l'hôte et le port SSH, le mappage des clés, les permissions de stockage et les URL de clone annoncés avant de modifier globalement les permissions du dépôt.
Documentation officielle : Sauvegarde et restauration Gitea