Poste de travail
Machine Linux de développement : VS Code, Git, SSH et administration du lab.
Physique · localPortfolio technique · Infrastructure & DevOps
Dans les coulisses de ce CV en ligne de Thibault MONIN
Un laboratoire personnel pour concevoir et exploiter une infrastructure hybride : Linux, virtualisation KVM, Docker, GitLab CI/CD, réseau privé WireGuard et déploiements vers plusieurs environnements.
Dernière mise à jour : · Schémas simplifiés pour publication publique · Aucune donnée d'accès ni adresse privée exposée.
01 / Vue d'ensemble
Un lab hybride, du domicile au cloud
Le whiteboard distingue trois zones : le poste et l'hyperviseur locaux, le réseau domestique derrière la Freebox, et les ressources OVHcloud. Le diagramme ci-dessous présente les rôles sans divulguer la topologie d'adressage.
Éléments du labInterconnexion VPNExtension planifiée
Pourquoi cette architecture ? Pour travailler les vraies frontières d'exploitation : réseau local contre réseau virtuel, accès privé contre exposition Internet, infrastructure persistante contre application redéployable.
02 / De l'éditeur à la production
GitLab CI/CD : le parcours d'un changement
Un changement de HTML part du poste de travail, passe par GitLab et son registre de conteneurs, puis rejoint deux cibles de déploiement. Le pipeline comporte les étapes test, build, deploy-ovh et deploy-freebox.
Opérationnel · GitLab CI/CD et déploiementsEn cours · Ansible et Jenkins
Écrire et versionner
Le contenu HTML est édité localement puis envoyé dans Git. Le commit devient l'unité de traçabilité.
Contrôler et construire
GitLab exécute le pipeline et construit une image Docker Nginx contenant la version du site. L'image est publiée dans le Container Registry.
Déployer sur deux cibles
Les jobs de déploiement récupèrent l'image et recréent le conteneur applicatif sur OVH et sur le serveur Debian domestique.
Séparer application et terminaison TLS
Sur OVH, Caddy doit devenir le point d'entrée HTTPS permanent. Le CV Nginx reste remplaçable à chaque pipeline, sans recréer les certificats.
Zoom technique · Docker-in-Docker (DinD)
Construire des images Docker à l’intérieur de la CI
Le job de build utilise docker:dind : un service Docker dédié permet au client Docker exécuté dans le job GitLab CI de construire l’image Nginx du CV. Cette image est ensuite taguée avec l’identifiant court du commit et poussée vers le Container Registry privé.
Git push→GitLab Runner→Job + Docker-in-Docker→Image versionnée→Registry privé→Déploiements
Intérêt : builds reproductibles et traçables, séparation construction/déploiement et même artefact livré sur plusieurs cibles. Point de vigilance : DinD nécessite une configuration de sécurité adaptée du runner et du daemon Docker.
Notion clé : une pipeline réussie ne remplace pas la validation de l'exploitation. On vérifie aussi les routes, le DNS, les certificats, les ports publiés et le comportement après redémarrage.
03 / Réseau & sécurité
Comprendre les flux, pas seulement les ouvrir
WireGuard et split tunneling
Le VPS rejoint les réseaux du homelab via un tunnel chiffré. Les routes sont limitées aux sous-réseaux utiles : le trafic Internet ordinaire n'a pas besoin de traverser la maison.
Tunnel opérationnelRoutes ciblées
DNS public et DNS privé
Un serveur peut joindre une adresse IP tout en échouant à résoudre un nom. Le lab a permis d'identifier un DNS poussé par WireGuard qui perturbait la résolution publique du VPS.
Diagnostic validésystemd-resolved
Libvirt, NAT et pare-feu
Les VM utilisent un réseau virtuel distinct du LAN. L'accès depuis le VPS exige une route vers le réseau KVM et des règles de filtrage ciblées, plutôt qu'une ouverture générale.
Flux HTTPS vérifiéiptables / libvirt
TLS et reverse proxy
Sur les deux cibles, Caddy reçoit les connexions HTTPS publiques et les transmet à Nginx sur le réseau Docker privé. Les certificats Let’s Encrypt sont conservés dans des volumes persistants.
HTTPS opérationnel sur deux ciblesCaddy · Let's Encrypt
Architecture opérationnelle sur les deux cibles : Caddy expose HTTPS, reverse-proxy vers Nginx sur cv-web et conserve ses certificats dans des volumes persistants.
04 / Infrastructure physique & virtuelle
Le matériel derrière le laboratoire
Une architecture réellement exploitée : postes et hôtes physiques à domicile, virtualisation KVM, machines hébergées par la Freebox et ressources distantes OVHcloud. Les références CPU, RAM et stockage détaillées ne sont pas publiées ici.
Hyperviseur Debian
Hôte adri3n : KVM/libvirt, réseau virtuel NAT et VM GitLab avec Container Registry.
Physique + VMFreebox & stockage
Routeur Freebox avec serveur WireGuard ; hôtes Debian et Alpine sur l’infrastructure domestique.
Réseau + hôtes locauxVPS OVHcloud
VPS Debian distant : Docker, Nginx pour le CV, tunnel WireGuard et reverse proxy Caddy HTTPS actif.
Hébergé · actifOVH Public Cloud
POC déjà réalisé sur OVH Public Cloud ; environnement utilisé pour expérimenter l’infrastructure cloud et préparer la reproductibilité avec Terraform et Ansible.
POC réalisé · évolutions envisagées05 / Schéma de synthèse
Architecture en production et prochaines évolutions
Lecture rapide du whiteboard : ce qui fonctionne est séparé des travaux prévus. Les adresses privées et les identifiants d'accès ne sont pas publiés.
Actuel · vérifié
INTERNET
|
+--> VPS OVH (Debian)
| |-- Docker : project1 / Nginx --> CV HTTPS public via Caddy
| |-- reseau Docker prive : cv-web [actif]
| `-- WireGuard [actif]
| |
| Freebox [route vers KVM]
| |
| Hyperviseur Debian / KVM
| `-- VM GitLab + Container Registry
|
`--> GitLab CI/CD : test -> build -> deploy OVH + Freebox
LAN : serveur Debian (Nginx + Caddy HTTPS) + Alpine (lab)Cible · évolutions prévues
EVOLUTIONS ENVISAGEES
INTERNET
|
`--> HTTPS / Let's Encrypt
|
Caddy (proxy permanent)
|
cv-web (reseau Docker prive)
|
Nginx / CV (image CI/CD)
LAB + OVH PUBLIC CLOUD
|-- Terraform : provisionnement reproductible
|-- Ansible : configuration idempotente
|-- Vault : secrets (a etudier)
|-- Jenkins : automatisation de scenarios
`-- PRA : DEJA TESTE -> formalisation / automatisation
Ansible Vault : chiffrement des variables de playbooksÀ retenir : Terraform provisionne l'infrastructure, Ansible configure les systèmes, Vault sécurise les secrets et la CI/CD livre l'application. Ces briques n'ont pas toutes le même statut : elles sont présentées comme une trajectoire d'apprentissage et de mise en œuvre.
06 / Ce que démontre ce laboratoire
Une approche systèmes, réseaux et automatisation
01
Administration Linux
Debian, services systemd, réseau, SSH, DNS, analyse des journaux et diagnostic en ligne de commande.
02
Virtualisation & réseau
KVM/libvirt, réseaux NAT, routage, pare-feu, WireGuard et segmentation des flux.
03
Livraison applicative
Git, GitLab CI/CD, Docker, registre d'images, déploiements automatisés et reverse proxy.
04
Résolution d'incidents
Diagnostic progressif, hypothèses vérifiées, captures réseau, tests de connectivité et analyse de la cause racine.
05
Exploitation durable
Persistance des configurations, redémarrages contrôlés, séparation des responsabilités et documentation.
06
Amélioration continue
PRA testé dans le laboratoire ; Terraform, Ansible et Vault intégrés à une feuille de route explicite, sans confondre projets et réalisations.
Déploiements publics · Vérification en direct
Une même image Docker, construite par GitLab CI/CD, est déployée sur deux infrastructures indépendantes :
Deux environnements, deux reverse proxies Caddy, deux certificats TLS publics et un même pipeline de livraison automatisée.
Positionnement : ce lab personnel illustre une pratique transversale — comprendre le besoin, concevoir l'architecture, intervenir techniquement, coordonner les composants et vérifier le résultat. Il complète un parcours professionnel ; il ne prétend pas en remplacer les réalisations.
Clin d’œil à ma règle de conduite ITIL : KISS — Keep It Simple, Stupid. Une architecture compréhensible, des changements mesurés, un test à la fois et pas d’usine à gaz. « Mon impatience est un moteur. Ma méthode est le volant. »