Phase 4 (2/3) — Le code : Git & GitHub

L’idée reçue

« Mon code est sur ma VM, sauvegardé, c’est suffisant. »

Un dossier sur une VM n’a pas d’historique, pas de traçabilité, et disparaît avec la machine. Le code d’une infrastructure sérieuse vit dans Git, avec un dépôt central (GitHub) accessible et versionné. On met ça en place — depuis une machine dédiée à piloter tout le projet.

On introduit ici la VM mgmt (management) : le poste de pilotage du projet. C’est là que vivent tes codes locaux, que tourne Git, et d’où tu te connecteras aux autres briques (Jenkins, plus tard le cluster Kubernetes, et GitHub) de façon standard. Reste sobre en ressources : une petite VM suffit.

À la fin de ce module, tu sauras…

Mettre en place une machine de management et y installer Git
Créer un dépôt local, faire des commits, comprendre l’historique
Connecter ta machine à GitHub par clé SSH (méthode standard)
Pousser le code de SORIA Web sur un dépôt distant

01La machine de management

Expérience 1

Préparer mgmt et installer Git

Crée une VM mgmt (Debian 13) sur le LAN, avec une IP réservée. Installe Git et configure ton identité :

Manipule

sudo apt update &amp;&amp; sudo apt install -y git
git config --global user.name "Ton Nom"
git config --global user.email "toi@exemple.fr"
git --version

Comprends pourquoi une machine dédiée ?

La VM de management centralise le pilotage : code, Git, et bientôt les accès à Jenkins et Kubernetes. Séparer ce rôle est une bonne pratique : on ne pilote pas l’infrastructure depuis un serveur de production, mais depuis un poste dédié et maîtrisé.

02Un dépôt local, des commits

Expérience 2

Versionner SORIA Web

Récupère (ou recrée) le code de SORIA Web sur mgmt, puis fais-en un dépôt Git :

Manipule

mkdir ~/soria-web &amp;&amp; cd ~/soria-web
# place ici index.html, Dockerfile, .dockerignore ...
git init
git add .
git commit -m "Première version de SORIA Web"

Manipule

git log --oneline
git status

Observe

a1b2c3d Première version de SORIA Web
nothing to commit, working tree clean

Ton code a désormais un historique. Chaque commit est un instantané daté et signé de ton travail.

Comprends add, commit, historique

git init crée le dépôt ; git add prépare les changements ; git commit les enregistre comme un instantané. L’ensemble forme un historique que tu peux parcourir, comparer, et restaurer. C’est la mémoire de ton projet.

03Se connecter à GitHub par clé SSH

Expérience 3

La méthode standard, sans mot de passe

Manipule

ssh-keygen -t ed25519 -C "mgmt-soria"
cat ~/.ssh/id_ed25519.pub

Copie la clé publique affichée, puis dans GitHub : Settings → SSH and GPG keys → New SSH key, colle-la. Vérifie la connexion :

Manipule

ssh -T git@github.com

Observe

Hi ton-compte! You've successfully authenticated ...

Ta machine mgmt est authentifiée auprès de GitHub par sa clé — plus besoin de mot de passe à chaque opération.

Comprends pourquoi une clé, pas un mot de passe

Une paire de clés SSH (privée sur ta machine, publique sur GitHub) authentifie sans transmettre de secret réutilisable. C’est la méthode standard, sûre et automatisable — la même logique qu’on utilisera pour que Jenkins accède au code plus tard.

04Pousser sur GitHub

Expérience 4

Le dépôt distant

Crée un dépôt vide soria-web sur GitHub (sans README), puis relie ton dépôt local et pousse :

Manipule

git remote add origin git@github.com:ton-compte/soria-web.git
git branch -M main
git push -u origin main

Observe

Ton code apparaît sur GitHub. À partir de maintenant, chaque git push synchronise ton travail avec le dépôt distant : sauvegardé, partageable, traçable.

Comprends remote, origin, push

Un remote est un dépôt distant ; origin est son nom par convention. git push envoie tes commits locaux vers ce remote. Le code vit désormais à deux endroits synchronisés — ta machine et GitHub — ce qui prépare le travail d’équipe et l’automatisation.

✓Ce que tu retiens

Le code d’une infrastructure vit dans Git, avec un historique de commits, piloté depuis une machine de management, et centralisé sur GitHub via une clé SSH. Images (Harbor) et code (GitHub) sont maintenant tous deux hébergés proprement — la base indispensable avant d’orchestrer et d’automatiser.

Mini-projet — clôture de la Phase 4

Code et images, sous contrôle

À faire

Mets en place la VM mgmt avec Git configuré.
Versionne SORIA Web (au moins 2 commits significatifs).
Connecte mgmt à GitHub par clé SSH et pousse le dépôt.
Fais une petite modification, commit, push — vérifie qu’elle apparaît sur GitHub.
Snapshot de mgmt nommé mgmt-git-ok.
Documente dans BookStack le lien entre code (GitHub), image (Dockerfile) et registre (Harbor).

Fil rouge — Tu as maintenant tout le nécessaire : du code versionné, une image, un registre. Le déploiement « à la main » d’un conteneur ne suffira bientôt plus. À la Phase 5, on passe à l’échelle avec Kubernetes — d’abord manuellement, pour bien comprendre, avant d’automatiser.

?Auto-évaluation

1. Que gagne-t-on à mettre le code dans Git plutôt que dans un simple dossier ?

Un historique traçable, la possibilité de comparer/restaurer, et une base pour le travail d’équipe et l’automatisation.

2. Pourquoi utiliser une clé SSH pour GitHub ?

Elle authentifie sans transmettre de secret réutilisable, de façon sûre et automatisable — sans ressaisir un mot de passe.

3. Que fait git push -u origin main ?

Il envoie la branche main vers le remote origin (GitHub) et mémorise le lien pour les prochains push.