Git pour les administrateurs système : La Forge

Avant de commencer, prenons quelques minutes pour introduire cette formation.

J’utilise une forge Git (Forgejo) depuis plusieurs années maintenant. Avec le temps, elle est devenue l’une des pièces les plus centrales de mon infrastructure : mes scripts, mes stacks Docker, mes images de conteneurs, ma documentation et une bonne partie de mes configurations y sont. Mais comme pour PowerShell, Docker et Ansible, je ne l’ai pas apprise dans une formation structurée. Je l’ai apprise en me trompant, longtemps.

Et surtout, je suis passé à côté pendant des années.

Parce que Git, dans ma tête, c’était un outil de développeur. J’ouvrais un tutoriel : on me parlait de feature branch, de rebase interactif, de workflow d’équipe pour livrer une application. Je refermais l’onglet. Je ne développe pas d’application. J’écris des scripts, je maintiens des serveurs, je gère un annuaire et des stratégies de groupe. Un partage réseau bien rangé me paraissait largement suffisant.

Puis un jour, j’ai eu le déclic.

Deux incidents, une seule réponse

Sur un partage réseau, un dossier Scripts. Dedans, un script PowerShell exécuté par une GPO sur l’ensemble des postes du domaine. Un vendredi en fin de journée, quelqu’un ouvre le fichier directement sur le partage pour corriger un petit truc, et l’enregistre. Le lundi matin, tous les postes exécutent la nouvelle version au démarrage. Sauf qu’elle ne fait pas tout à fait ce qu’elle devrait.

Je me retrouve devant un fichier dont je ne connais ni l’auteur de la modification, ni l’heure exacte, ni surtout le contenu d’avant. Il n’y a pas d’« avant ». Le fichier a été écrasé. Il me reste une sauvegarde de la veille au soir — dans le meilleur des cas — et une soirée à comparer deux fichiers à l’œil pour deviner ce qui a changé.

Quelques semaines plus tard, un problème qui n’a apparemment aucun rapport. Un docker compose pull de routine s’arrête sur un toomanyrequests du Docker Hub. L’image redis, utilisée par une poignée de mes services, n’est plus téléchargeable pour l’heure qui vient. Mon infrastructure dépendait, sans que je l’aie jamais vraiment décidé, des quotas d’un service public sur Internet.

Deux incidents sans lien apparent. Une seule et même réponse : une forge interne.

Ce que j’avais mal compris

C’est à ce moment-là que Forgejo est entré dans ma vie. Et ce qui m’a le plus marqué, ce n’est pas la syntaxe de Git — elle s’apprend en une" après-midi". C’est d’avoir compris que je m’étais trompé sur la nature même de l’outil.

Un dépôt Git, ce n’est pas un endroit où des développeurs collaborent sur du code. C’est un endroit où l’on sait qui a changé quoi, quand et pourquoi, et d’où l’on peut revenir en arrière. Ce besoin-là n’a rien de spécifique au développement : c’est le quotidien d’un administrateur système. Chaque fichier de configuration modifié à 23h, chaque script ajusté dans l’urgence, chaque GPO retouchée « juste un peu » est un candidat naturel.

Et une forge, c’est encore autre chose qu’un dépôt. C’est le point du système d’information où l’on range ce qu’on a écrit, où l’on consigne ce qu’on n’a pas écrit, d’où l’on distribue vers les machines, et depuis lequel on déclenche des traitements automatiques. Ces quatre mécaniques sont la colonne vertébrale de cette formation, et vous les retrouverez de bout en bout :

• Ranger — le dépôt comme référentiel : scripts, stacks Docker, documentation.
• Pousser — le dépôt comme journal : /etc, configurations Nginx, exports de GPO, sauvegardés automatiquement par les machines elles-mêmes.
• Tirer — le dépôt comme source : une GPO qui exécute un script hébergé sur la forge, un serveur qui s’installe en une commande, des clés SSH distribuées à l’amorçage.
• Déclencher — le dépôt comme moteur : construire vos images Docker, publier votre documentation, vérifier vos scripts, alimenter Semaphore ou Dockerhand.

À partir de là, j’ai voulu comprendre en profondeur : documentation officielle, tests sur ma propre infrastructure, et beaucoup d’erreurs. J’ai aussi cherché des formations. Il en existe énormément sur Git — et c’est bien le problème. Elles sont écrites pour des développeurs. On y apprend à livrer une application en équipe, jamais à versionner un annuaire, à distribuer un script par GPO ou à héberger ses propres images de conteneurs. L’administrateur système qui les suit apprend la syntaxe, mais ne voit jamais à quoi ça sert chez lui.

C’est pour combler ce manque que j’ai décidé de créer cette formation.

Ce que nous allons construire ensemble

À travers cette formation gratuite, nous allons découvrir Git et les forges ensemble, étape par étape, et exclusivement du point de vue de l’administration système.

Pour rendre les choses concrètes, nous allons suivre la suite de l’histoire de Nordika. La PME fictive a bien grandi : après avoir automatisé ses tâches en PowerShell et piloté son parc avec Ansible, son service IT accumule maintenant des scripts sur trois partages réseau, des stacks Docker copiées de serveur en serveur, et personne ne sait plus quelle version tourne où. Nous allons lui monter son atelier.

Nous imaginerons donc la forge comme… une forge, justement. Un lieu où les outils sont rangés à leur place et non éparpillés sur l’établi, où chaque pièce produite est poinçonnée et datée, où l’on tient un registre de ce qui a été fait, où un guichet permet à chacun de venir retirer la pièce dont il a besoin, et où un marteau-pilon se met en marche tout seul dès qu’on lui apporte de la matière.

L’objectif n’est pas seulement d’apprendre les commandes Git, mais de comprendre les quatre mécaniques qui font d’une forge une pièce centrale du SI — afin que vous puissiez ensuite inventer vos propres usages, ceux dont je n’ai pas parlé.

Prérequis

Côté connaissances

Aucune connaissance de Git n’est nécessaire : nous partons de la première commande.

En revanche, cette formation suppose que vous êtes à l’aise en ligne de commande, sous Linux comme sous Windows, et que vous savez administrer un serveur Linux au quotidien (paquets, services, permissions, SSH).

Docker et Docker Compose sont fortement recommandés. Nous déployons la forge en conteneurs dès la section 2, et deux sections entières portent sur les images et le registre. Si Docker ne vous est pas familier, la formation Docker pour les débutants : Le Chantier Naval couvre exactement ce dont vous aurez besoin ici.

Les formations PowerShell et Ansible ne sont pas requises, mais plusieurs exemples y font écho.

Côté laboratoire

Contrairement à d’autres formations du site, il n’y a pas de laboratoire intégré au navigateur. Ce n’est pas un oubli : nous allons manipuler des systèmes complets — un serveur Linux qui héberge des conteneurs, un poste Windows joint à un domaine, un annuaire Active Directory. Ça ne rentre pas dans les conteneurs légers utilisés pour les autres labs. Vous allez donc monter votre propre environnement, ce qui est de toute façon la meilleure façon d’apprendre.

Peu importe l’hyperviseur : Proxmox, Hyper-V, VMware, VirtualBox ou même une machine physique feront l’affaire.

Le minimum indispensable (suffisant pour les sections 1 à 5 et 9 à 13) :

• Une VM Linux — Debian 13 recommandé — avec Docker et Docker Compose installés. Comptez 2 vCPU, 4 Go de RAM et 40 Go de disque : elle hébergera la forge, son runner et le registre d’images.
• Un poste de travail (Windows, Linux ou macOS) avec Git et un éditeur, VS Code par exemple.
• Une résolution de nom pour joindre la forge autrement que par son IP : une entrée dans votre DNS interne, ou à défaut dans le fichier hosts de votre poste.

Recommandé pour aller au bout des travaux pratiques :

• Une seconde VM Linux « cible », légère (1 vCPU, 2 Go de RAM). Elle servira de cobaye pour la section 6 (versionner /etc, centraliser des configurations Nginx) et la section 8 (amorçage, post-installation, clés SSH).

Pour la partie Windows (leçons 6.5 et 6.6 sur les GPO, et toute la section 7) :

• Un contrôleur de domaine Active Directory de test et un poste joint au domaine. Si vous n’en disposez pas, ces leçons restent parfaitement lisibles et compréhensibles — vous pourrez les mettre en pratique plus tard, sur votre environnement professionnel.

Optionnel :

• Un fournisseur d’identité (Authentik ou Keycloak, en conteneur sur la même VM) pour la leçon consacrée à l’authentification OIDC. Sans lui, l’authentification locale ou LDAP suffit pour toute la suite.
• Traefik, si vous souhaitez publier la forge en HTTPS proprement — la configuration est reprise de la formation Docker.

Au total, comptez environ 6 à 8 Go de RAM pour l’ensemble du laboratoire, contrôleur de domaine compris.

Une dernière chose : la forge que vous allez monter dans cette formation, vous pourrez la garder. Ce n’est pas un lab jetable. À la fin de la section 2, vous aurez une instance parfaitement utilisable en production, et il serait dommage de la supprimer.