Pipeline as Code
Jenkinsfile conservé dans un dépôt GitLab dédié, récupéré via un Deploy Token limité à read_repository.
Validé
Portfolio technique · Infrastructure & DevOps
Dans les coulisses de ce CV en ligne de Thibault MONIN
Un laboratoire personnel pour concevoir, automatiser et exploiter une infrastructure hybride : Linux, KVM, Docker, GitLab CI/CD, Jenkins, Ansible, WireGuard et déploiements multi-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. Un contrôleur Ansible Debian 13 reconstruit via Cloud-init complète désormais le lab, avec un tunnel WireGuard dédié vers GitLab. 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éploiements DockerOpérationnel · Jenkins → Ansible (diagnostic)
É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 les deux cibles, Caddy est le point d’entrée HTTPS permanent ; le conteneur Docker Nginx du CV est 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 / Automatisation · 14 octobre 2026
Jenkins + Ansible : du code à l’exécution
Une seconde chaîne d’automatisation, distincte du pipeline GitLab qui publie le CV. Jenkins récupère un Jenkinsfile versionné dans GitLab et exécute déjà un diagnostic Ansible sur une VM Debian 13 de recette via SSH. Le nouveau contrôleur Ansible du lab dispose désormais de son propre bootstrap Cloud-init et d’une liaison WireGuard validée avec GitLab ; les playbooks de configuration restent à construire.
Jenkins conteneurisé
Image personnalisée avec Ansible et client SSH ; Docker Compose, volume persistant et autorité de certification interne reconnue.
Validé
Exécution distante
Authentification SSH via Jenkins Credentials, vérification des hôtes et exécution d’un diagnostic Ansible sur Debian 13.
Build réussi
Périmètre actuel : la chaîne Jenkins → Ansible exécute un diagnostic validé. Le déploiement de configuration, l’idempotence et la promotion recette → production sont des étapes à venir, pas des fonctions déjà livrées.
04 / Infrastructure as Code · 21 octobre 2026
Reconstruction complète : Cloud-init, Ansible et WireGuard
Un contrôleur Ansible Debian 13 peut désormais être recréé à partir d’un fichier cloud-init.yaml. La liaison chiffrée avec la VM GitLab est rétablie après régénération des clés : scénario de reconstruction exécuté et vérifié sur le laboratoire.
Bootstrap reproductible
Cloud-init prépare l’utilisateur d’administration, l’accès SSH par clé, l’autorité de certification interne, les paquets système, Ansible et WireGuard. Le YAML a été contrôlé syntaxiquement puis validé par le schéma Cloud-init.
Reconstruction testéeDebian 13 · systemd
Identité cryptographique locale
Au premier démarrage, la VM génère sa clé privée WireGuard sur place, avec des permissions restrictives, puis prépare l’interface serveur et active wg-quick@server. Aucune clé privée n’est intégrée au dépôt Git.
Service démarréCloud-init · WireGuard
Synchronisation de clé publique
Depuis le poste d’administration, un script Bash récupère par SSH la clé publique du serveur Ansible et la transmet à GitLab. Un utilitaire local, autorisé par une règle sudo dédiée, actualise la configuration du pair sans ouvrir de shell administrateur générique.
Rotation après rebuild validéeSSH · Bash · sudoers
Recréer la VM depuis Cloud-init
Installation des composants, génération locale des clés, création de la configuration WireGuard et activation automatique du service.
Synchroniser depuis le poste d’administration
Le script gitl4b-wg-update.sh lit la nouvelle clé publique du serveur et actualise le pair WireGuard côté GitLab.
Constater la reconnexion
Après reconstruction et synchronisation, le tunnel a présenté un handshake récent et des compteurs de trafic dans les deux sens.
Périmètre validé : bootstrap Cloud-init, régénération des clés, synchronisation de la nouvelle clé publique et communication WireGuard. Étape suivante : préparer l’inventaire Ansible et faire exécuter les premiers playbooks de configuration du lab par Jenkins. La chaîne Jenkins → Ansible a déjà été validée pour le diagnostic ; les déploiements de configuration ne sont pas encore réalisés.
05 / 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é. Un second tunnel WireGuard relie désormais le contrôleur Ansible à GitLab sur le réseau virtuel KVM. 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 et Nginx tournent dans des conteneurs Docker distincts. Caddy reçoit le HTTPS et transmet les requêtes au conteneur applicatif Nginx sur le réseau privé cv-web. Les certificats 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.
06 / 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.
Poste de travail
Machine Linux de développement : VS Code, Git, SSH et administration du lab.
Physique · localHyperviseur 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 : conteneurs Docker Caddy (HTTPS) et Nginx (CV), réseau privé Docker et tunnel WireGuard.
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ées07 / Schéma de synthèse
Architecture opérationnelle et évolutions planifiées
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 · PRODUCTION
| |-- Docker : Caddy HTTPS --> project1 / Nginx
| |-- Réseau privé Docker : cv-web
| `-- WireGuard vers homelab
|
`--> Freebox · RECETTE (VM Debian 13)
`-- Docker : Caddy HTTPS --> project1 / Nginx
GitLab CI/CD : test --> build --> déploiements OVH + Freebox
GitLab SCM --> Jenkins (Docker) --> Ansible --> Debian recette
GitLab + Registry : VM KVM sur hyperviseur Debian
Cloud-init --> contrôleur Ansible Debian 13
WireGuard : contrôleur Ansible <--> VM GitLab
SSH : synchronisation de clé publique après rebuildCible · évolutions prévues
EVOLUTIONS ENVISAGEES
RECETTE · FREEBOX
|-- Ansible : configuration et déploiement
|-- Tests de validation et idempotence
`-- Promotion contrôlée vers production
INFRASTRUCTURE & AUTOMATISATION
|-- Kubernetes : orchestration de conteneurs
|-- Terraform : provisionnement reproductible
|-- Ansible Vault : secrets des playbooks
|-- Vault : gestion centralisée des secrets (étude)
|-- Jenkins : pipelines enrichis, tests, PRA
`-- Supervision, observabilité, documentationÀ 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.
08 / Résilience
Plan de reprise d’activité : exercice réalisé
Le laboratoire a également servi à expérimenter un scénario de PRA. Cet exercice est distinct des pipelines de livraison et du diagnostic Jenkins / Ansible.
Test PRA réaliséHomelab · retour d’expérience
Une pratique de la reprise, pas seulement un schéma théorique
Un test de reprise a été effectué dans le laboratoire. Les procédures détaillées, les mesures de temps de reprise et les preuves d’exécution ne sont pas publiées sur cette page ; la formalisation d’un scénario reproductible et son automatisation restent dans la roadmap.
09 / Trajectoire technique
Roadmap : construire, valider, approfondir
Une feuille de route progressive, construite autour d’un lab personnel. Les technologies planifiées ne sont pas présentées comme déjà mises en production.
GitLab CI/CD, Docker et livraison sur deux cibles Opérationnel
Build d’image Nginx, registre privé, déploiements Freebox et OVH ; Caddy en conteneur Docker pour HTTPS.
Jenkins + Ansible Diagnostic validé
Pipeline as Code, credentials, TLS interne, Docker Compose et exécution SSH sur Debian 13.
Cloud-init + WireGuard : reconstruction du contrôleur Ansible Testé de bout en bout
Bootstrap Debian 13, génération locale des clés, synchronisation SSH de la clé publique vers GitLab et tunnel rétabli avec handshake vérifié.
Jenkins → Ansible : playbooks du lab et idempotence À réaliser
Inventaire du lab, playbooks de configuration exécutés depuis Jenkins, contrôles post-déploiement, idempotence et gestion des erreurs.
Kubernetes et orchestration Planifié
Pods, Deployments, Services, configuration, stockage et stratégies de mise à jour ; expérimentation sur un environnement isolé.
Terraform, Ansible Vault et gestion des secrets Planifié
Infrastructure as Code, chiffrement des variables et étude de Vault pour la gestion centralisée des secrets.
CI/CD avancée, observabilité et PRA Planifié
Tests automatisés, validation en recette avant promotion, supervision, journalisation et scénarios de reprise documentés.
Roadmap indicative : les priorités seront ajustées selon les besoins des missions et les compétences à développer.
10 / 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é ; Jenkins et Ansible validés pour le diagnostic ; contrôleur Debian 13 reconstruit par Cloud-init et liaison WireGuard rétablie après rotation de clé. Terraform, Kubernetes et Vault restent des axes d’évolution.
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. »