Aller au contenu
English
Compte : non connecté, synchronisation possible Mon apprentissage
Selectionner le thème
English

Formation Administrer une forge Git auto-hébergée

  • 10 min

Par mis à jour le

Améliorer cette page

Faire tourner sa propre forge Git, c'est tenir un service que toute une équipe utilise chaque jour : il doit être installé proprement, gouverné, protégé et restaurable. Cette formation vous fait installer Forgejo sur PostgreSQL derrière un proxy TLS, organiser ses équipes et son authentification, durcir l'instance, exploiter son runner de CI, puis l'entretenir : sauvegarde restaurée, montée de version, supervision. Elle s'adresse aux administrateurs système, aux ingénieurs CI/CD et aux Platform Engineers qui doivent offrir une forge à leurs développeurs.

  • Choisir une forge d'après des critères d'exploitant (ressources, gouvernance, maintenance), et comprendre ses composants : web, SSH, base de données, stockage, proxy et runner.
  • Installer Forgejo LTS sur PostgreSQL derrière un proxy TLS, jusqu'à un git clone en SSH qui réussit, puis le configurer : courrier, LFS, inscriptions.
  • Gouverner l'instance : organisations, équipes et droits, connexion par un fournisseur OIDC avec second facteur obligatoire, assistance aux comptes en ligne de commande.
  • Sécuriser l'instance : webhooks fermés au réseau interne, force brute bloquée, compte de secours, jetons bornés, commits signés.
  • Exploiter un runner cloisonné, sauvegarder et restaurer l'instance avec un runbook, monter de version avec des contrôles avant et après, superviser et migrer une organisation.

Il faut savoir utiliser Git et lancer des conteneurs. Une forge est un serveur Git doté d'une interface web, de comptes et d'un moteur de CI : sans le modèle de Git (dépôts, branches, clone en SSH), les réglages d'une instance restent abstraits. Le guide Git couvre ce socle, et la page Git sur un serveur explique comment un serveur héberge des dépôts.

Prévoyez aussi une machine virtuelle Linux (AlmaLinux 10 ou Ubuntu 24.04) : les leçons y déploient Forgejo, PostgreSQL et le proxy dans des conteneurs avec Docker Compose, et la formation Docker suffit pour les suivre. Le reste (proxy TLS, fournisseur d'identité) est présenté au moment où une leçon s'en sert, et chaque leçon rappelle la version et l'environnement sur lesquels ses commandes ont été jouées.

Pourquoi Forgejo en référence, et GitLab en option ?

Section intitulée « Pourquoi Forgejo en référence, et GitLab en option ? »

Forgejo est la référence parce qu'il se prête à l'apprentissage de l'administration : un binaire unique, léger, sous gouvernance communautaire. La formation enseigne la branche LTS, la règle d'une formation d'administrateur : une instance se maintient plusieurs mois entre deux montées de version, et la leçon de montée de version franchit ensuite le pas vers la branche stable. Les Actions de Forgejo ressemblent à celles de GitHub sans leur être compatibles : la leçon sur le runner détaille les quatre écarts mesurés.

GitLab figure en module facultatif. C'est la forge que l'on rencontre le plus en entreprise, et ses gestes d'administrateur (installation Omnibus, sauvegarde, montée de version) sont les mêmes que ceux de Forgejo, avec un outil plus lourd. Soyons clairs sur son état : ce module est en cours de reprise, et rien dans le reste de la formation n'en dépend.

Gitea, dont Forgejo est un fork, a ses propres guides de référence, comme GARM et Plane : ils sortent de la formation, mais restent consultables sur Gitea, GARM et Plane. Pour comparer les forges avant de choisir, la page Plateformes Git met GitHub, GitLab, Gitea et Forgejo côte à côte.

La formation suit deux niveaux : mettre en service et gouverner une forge, puis la sécuriser et l'exploiter. Le programme détaillé, avec votre progression leçon par leçon, est sur la page Mon parcours. Elle fait foi pour les intitulés et les durées ; cette section en donne seulement le fil.

Le module Comprendre pose la question de départ avec Qu'est-ce qu'une forge Git et laquelle exploiter ?, qui décrit les composants d'une forge et les critères du choix. Le module Mettre en service installe ensuite l'instance, avec Forgejo LTS sur PostgreSQL derrière un proxy TLS, puis la règle avec le courrier, LFS et les inscriptions.

Le module Gouverner la forge organise ce qui sera utilisé par des humains : les droits, l'authentification et le support, avec organisations, équipes et droits, connexion par un fournisseur OIDC avec second facteur obligatoire et assistance aux comptes en ligne de commande. Le niveau se conclut par une épreuve : mettre en service et gouverner une forge, sans énoncé qui dicte les commandes.

Le second niveau suppose une forge qui tourne et s'intéresse à ce qui la garde sûre et récupérable dans la durée. Le module Sécuriser durcit l'instance, avec sécuriser une instance Forgejo. Le module CI auto-hébergée installe, enregistre et cloisonne le runner, avec exploiter le runner Forgejo, ce qui inclut le refus de l'exécuteur host et le mode éphémère.

Le module Exploiter rassemble les gestes de la vie d'une instance, de la sauvegarde à la migration : sauvegarder, restaurer et documenter la reprise, la maintenance courante, la montée de version avec ses critères de validation, la supervision et le dépannage et la migration d'une organisation. Une seconde épreuve termine la formation : sécuriser et exploiter une forge.

Le module GitLab (facultatif) refait les mêmes gestes d'administrateur sur GitLab self-managed, mais il est en cours de reprise : on aligne ses pages sur le programme officiel GitLab System Administration, et la zone d'administration, la ligne de commande, la supervision et le dépannage de GitLab ne sont pas encore couverts. Il compte aujourd'hui quatre pages : la présentation de la plateforme, la configuration initiale, la sauvegarde et la restauration et la mise à jour.

Les guides d'installation et de runner existent aussi, mais comme références hors parcours. Les pipelines GitLab CI/CD ont leur propre formation : GitLab CI/CD.

Chaque niveau se termine par un challenge que vous évaluez vous-même. Une épreuve donne un besoin et des contraintes, sans la liste des commandes, puis une grille avec les preuves à relever sur votre instance : un git clone qui réussit, un webhook refusé, une instance restaurée. Vous comparez ce que vous observez à la grille, et un corrigé replié renvoie, contrainte par contrainte, à la leçon et à la section à revoir. Chaque épreuve indique le temps de manipulation à prévoir.

La formation le dit franchement : ces épreuves ne sont ni chronométrées ni notées automatiquement sur l'état du système. Un catalogue de labs chronométrés, corrigés par un script qui lit l'état réel de la machine, est prévu pour une étape ultérieure. En attendant, la valeur de l'épreuve dépend de votre honnêteté : ne regardez pas le corrigé avant d'avoir tenté.

Les sujets d'échelle, de fédération et de contenu public sont volontairement laissés de côté. Ils demandent une formation à eux seuls ou ne concernent pas une forge d'équipe.

  • La haute disponibilité et la réplication géographique (Geo) : une instance unique sauvegardée et restaurée prouvée est le périmètre ici.
  • Kubernetes et Helm pour Forgejo : la formation déploie sur machine ou en conteneurs, pas sur un orchestrateur.
  • La fédération entre instances, et le fait de faire de la forge un fournisseur OAuth2 pour d'autres applications.
  • La modération de contenu, l'indexation par les moteurs de recherche et les pages légales d'une forge publique.
  • L'adoption de dépôts existants sur disque, le courrier entrant (répondre à une issue par courriel) et les rendus externes de fichiers.

La gestion des identités a sa propre formation, la formation Gestion des identités et des accès : la leçon sur l'authentification se contente de brancher la forge sur un fournisseur OIDC existant.

  • Administrer une forge, c'est la mettre en service, la gouverner, la sécuriser et l'exploiter, pas seulement l'installer.
  • Forgejo LTS est la référence de la formation ; GitLab est un module facultatif, en cours de reprise, dont rien ne dépend.
  • La formation compte deux niveaux : mettre en service et gouverner, puis sécuriser et exploiter.
  • Chaque niveau se termine par un challenge auto-évalué, ni chronométré ni noté automatiquement pour l'instant.
  • Le runner est cloisonné et l'exécuteur host refusé ; une sauvegarde ne compte que si elle est restaurée.
  • Haute disponibilité, Kubernetes, fédération et modération restent hors périmètre.

Ce projet vous est utile ?

Les guides, formations, quiz et labs restent gratuits. Si vous les utilisez régulièrement, vous pouvez contribuer à leur maintenance et à leur développement.

Devenir membre de soutien (nouvel onglet) Soutenir une fois (nouvel onglet) En savoir plus

Suivez aussi le projet sur LinkedIn