Posts on Geraud GAUZINS

👉 🏠 Présentation de mon infrastructure

Mon, 01 Jan 0001 00:00:00 +0000

🧪 Projet personnel – Infrastructure complète

🖥️ Virtualisation – XCP-ng + Xen Orchestra

Hardware : HPE DL380 G9 Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz (28c/56t) - RAM ECC 128 Go
20+ machines virtuelles sous Debian, FreeBSD, Windows Server 2022, Home Assistant OS
Services en VM : GitLab, Jellyfin, Docker, Pterodactyl, AD-DNS-DHCP, OPNsense, GestióIP, Nginx
Services en conteneur : Traefik, Vaultwarden, Prometheus, Grafana, Homarr, Authentik
Supervision centralisée avec Prometheus et Grafana
Réseau segmenté par VLAN (IoT, Admin, LAN, DMZint, DMZext, PROD)

🐳 Conteneurisation – Docker + Portainer CE

Gestion de 5 nœuds Docker via Portainer, répartis sur mes sous-réseaux :
- srv-traefik : héberge le reverse proxy
- srv-docker-PROD : conteneurs de monitoring/gestion (Prometheus, Grafana, Homarr,…)
- srv-docker-DMZint : conteneurs des services exposés sur internet via le reverse proxy
- srv-immich : conteneur Immich (gestionnaire de photos)
- srv-docker-mediarr : services pour la gestion des médias présents sur Jellyfin

💾 Stockage – TrueNAS SCALE

Hardware : HPE DL380 G9 Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz (16c/32t) - RAM ECC 128 Go
2 pools ZFS :
- GGcorp-pool (RAID 6 – 12 HDD de 12 To - 43 To - SMB/NFS)
- nvme-pool (RAID 0 – 2 NVMe de 1 To - 1.76 To - iSCSI)
Connexion iSCSI à l’hyperviseur via switch 10 GbE dédié
Partages SMB/NFS pour les services et sauvegardes
RAM ECC 128 Go – scrubbing régulier, température et S.M.A.R.T surveillés

🌐 Réseau et sécurité

Hardware :
- Switch 24 ports DELL 5524 1 Gb/s
- MikroTik CRS309-1G-8S 10 Gb/s
Schéma réseau complet modélisé avec Draw.io
Routage inter-VLAN via double pare-feu OPNsense EXT/INT
DMZ interne et externe, NAT, reverse proxy Traefik
VLAN :
- VLAN 2 : LAN utilisateur
- VLAN 3 : ADMIN
- VLAN 10 : PROD
- VLAN 11 : IoT
- VLAN 20 : DMZ interne
- VLAN 21 : DMZ externe

🚀🛠️ Déploiement automatisé de mon portfolio avec GitLab et Docker

Sat, 03 May 2025 00:00:00 +0000

🧠 Création et déploiement automatisé de mon portfolio avec GitLab, Docker et Traefik

🎯 Introduction

Dans le cadre de mon portfolio professionnel, j’ai souhaité mettre en ligne un site statique pour présenter mes projets et mes compétences. Ce site devait être simple à maintenir, facilement modifiable et intégré dans une logique DevOps.

🔗 Dépôt GitLab du projet : https://gitlab.ggcorp.ovh/GGauzins/portfolio

🧠 Pourquoi GitLab ?

J’ai choisi d’utiliser GitLab comme plateforme principale pour héberger et déployer mon site pour plusieurs raisons :

Self-hosting possible : GitLab peut être hébergé sur mes propres serveurs, ce qui me donne un contrôle total sur mon infrastructure, la sécurité et les données.
Simplicité du déploiement : je n’ai qu’à cloner le dépôt, modifier, puis git push pour publier.
Automatisation via CI/CD : GitLab construit l’image Docker à chaque commit.
Développement structuré : je peux développer ou tester mon site sur des branches secondaires sans impacter la production. Le déploiement ne se déclenche que sur la branche principale (main).

💡 Idée initiale : GitLab Pages

Mon idée de départ était d’héberger mon site via GitLab Pages directement sur mon instance GitLab auto-hébergée.
Cette solution avait plusieurs avantages :

Tout était intégré à GitLab (CI + Pages).
Le déploiement statique Hugo était très simple.

Mais j’ai vite rencontré une limitation : l’utilisation d’un domaine personnalisé (www.ggauzins.fr) n’est pas possible sans une deuxième adresse IP publique sur le serveur GitLab. Cette contrainte réseau ne s’adaptait pas à mon infrastructure personnelle.

🔁 Nouvelle stratégie : Docker + Watchtower

Pour pallier cette contrainte, j’ai opté pour une solution Dockerisée :

Le site est généré avec Hugo via GitLab CI.
Une image Docker est construite et poussée dans le GitLab Container Registry.
Une VM personnelle sous Docker exécute un conteneur basé sur cette image.
Watchtower surveille ce conteneur et tire automatiquement la dernière version publiée.

Résultat : je garde la simplicité d’un git push pour publier, tout en gardant le contrôle total de l’hébergement et de mon domaine personnalisé.

🛠️ Technologies utilisées

Hugo — Générateur de site statique
Docker — Conteneurisation du site
GitLab CI/CD — Build et déploiement automatisé
GitLab Container Registry — Stockage des images
Watchtower — Déploiement automatisé des mises à jour Docker
Traefik — Reverse proxy + gestion SSL avec Let’s Encrypt
DNS OVH + (DNS challenge et wildcard)

⚙️ CI/CD avec GitLab

Le pipeline GitLab CI (.gitlab-ci.yml) est structuré en deux étapes :

`build_image`

Construction de l’image Docker avec Hugo.
Push dans le Container Registry GitLab.

`pages`

Build statique Hugo (non utilisé ici en production, mais disponible).

Seule la branche main déclenche le build et le push de l’image.

🧾 Fichier `.gitlab-ci.yml`

Voici la configuration complète utilisée pour automatiser la génération du site et la création de l’image Docker :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74


variables:
 DART_SASS_VERSION: "1.85.0"
 GIT_DEPTH: 0
 GIT_STRATEGY: clone
 GIT_SUBMODULE_STRATEGY: recursive
 HUGO_VERSION: "0.144.2"
 NODE_VERSION: "23.x"
 TZ: "Europe/Paris"

stages:
 - build_image
 - pages

build_image:
 stage: build_image
 image: docker:latest

 services:
 - name: docker:dind
 alias: docker

 variables:
 DOCKER_HOST: "tcp://docker:2375"
 DOCKER_TLS_CERTDIR: ""

 before_script:
 - docker login -u gitlab-ci-token -p "$CI_JOB_TOKEN" "$CI_REGISTRY"
 script:
 - docker info
 - |
 docker build \
 --build-arg HUGO_VERSION=$HUGO_VERSION \
 -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
 - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
 - |
 if [ "$CI_COMMIT_BRANCH" = "$CI_DEFAULT_BRANCH" ]; then
 docker tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" "$CI_REGISTRY_IMAGE:latest"
 docker push "$CI_REGISTRY_IMAGE:latest"
 fi

 allow_failure: true
 rules:
 - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
 when: on_success
 - when: never

pages:
 stage: pages
 image:
 name: golang:1.23.4-bookworm
 script:
 - apt-get update
 - apt-get install -y brotli
 - curl -LJO https://github.com/sass/dart-sass/releases/download/${DART_SASS_VERSION}/dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz
 - tar -xf dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz
 - cp -r dart-sass/ /usr/local/bin
 - rm -rf dart-sass*
 - export PATH=/usr/local/bin/dart-sass:$PATH
 - curl -LJO https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb
 - apt-get install -y ./hugo_extended_${HUGO_VERSION}_linux-amd64.deb
 - rm hugo_extended_${HUGO_VERSION}_linux-amd64.deb
 - curl -fsSL https://deb.nodesource.com/setup_${NODE_VERSION} | bash -
 - apt-get install -y nodejs
 - '[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true'
 - hugo --gc --minify --baseURL ${CI_PAGES_URL}
 - find public -type f -regex '.*\.(css|html|js|txt|xml)$' -exec gzip -f -k {} \;
 - find public -type f -regex '.*\.(css|html|js|txt|xml)$' -exec brotli -f -k {} \;
 artifacts:
 paths:
 - public
 rules:
 - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
 when: always
 - when: never

🐋 Dockerfile

Le fichier Dockerfile utilisé pour builder l’image Docker à partir du site Hugo :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


# --- ÉTAPE 1 : builder avec Go et Hugo Extended ---
 FROM golang:1.23.4-bookworm AS builder

 # variables
 ARG HUGO_VERSION=0.144.2
 
 # installer git et ca-certificates pour cloner Hugo et gérer HTTPS
 RUN apt-get update \
 && apt-get install -y --no-install-recommends git ca-certificates \
 && rm -rf /var/lib/apt/lists/*
 
 # récupérer le code source de Hugo
 WORKDIR /go/src/hugo
 RUN git clone --branch v${HUGO_VERSION} https://github.com/gohugoio/hugo.git . 
 
 # compiler Hugo avec le tag 'extended'
 RUN go build --tags extended -ldflags="-s -w" -o /usr/local/bin/hugo
 
 # copier votre site et générer
 WORKDIR /src
 COPY . .
 RUN /usr/local/bin/hugo --gc --minify
 
 # --- ÉTAPE 2 : runtime léger avec Nginx ---
 FROM nginx:1.25-alpine AS runtime
 
 # on ne conserve que le dossier public généré
 COPY --from=builder /src/public /usr/share/nginx/html
 
 EXPOSE 80
 CMD ["nginx", "-g", "daemon off;"]

🌍 Reverse Proxy avec Traefik

🌐 Site principal – `www.ggauzins.fr`

Voici la configuration utilisée pour exposer mon conteneur hugo-portfolio :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


http:
 routers:
 hugo-portfolio:
 entryPoints:
 - websecure
 rule: "Host(`www.ggauzins.fr`)"
 tls:
 certResolver: lets-encr
 domains:
 - main: "www.ggauzins.fr"
 service: hugo-portfolio

 redirect-naked:
 entryPoints:
 - websecure
 rule: "Host(`ggauzins.fr`)"
 middlewares:
 - redirect-to-www
 service: noop@internal
 tls:
 certResolver: lets-encr
 domains:
 - main: "ggauzins.fr"

 middlewares:
 redirect-to-www:
 redirectRegex:
 regex: "^https?://ggauzins\.fr/(.*)"
 replacement: "https://www.ggauzins.fr/"
 permanent: true

 services:
 hugo-portfolio:
 loadBalancer:
 servers:
 - url: "http://172.16.20.7:8086/"

Cela permet :

De sécuriser les deux domaines (www. et nu) avec HTTPS via Let’s Encrypt.
De rediriger automatiquement ggauzins.fr vers www.ggauzins.fr.

📁 GitLab Pages – `*.pages.ggcorp.ovh`

Même si je n’utilise pas GitLab Pages pour le site final, j’ai quand même configuré Traefik pour qu’ils soient accessibles si besoin :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


http:
 routers:
 gitlab-pages:
 entryPoints:
 - "websecure"
 rule: "HostRegexp(`^.+\.pages\.ggcorp\.ovh$`)"
 tls:
 certResolver: lets-encr
 domains:
 - main: "pages.ggcorp.ovh"
 sans:
 - "*.pages.ggcorp.ovh"
 service: gitlab-pages

 services:
 gitlab-pages:
 loadBalancer:
 servers:
 - url: "http://172.16.20.8:8090"

⚠️ Cette configuration nécessite un certificat wildcard via DNS challenge.
J’ai donc configuré Traefik avec le DNS challenge OVH pour obtenir ce certificat automatiquement via Let’s Encrypt.

🐳 Docker Compose utilisé

Voici le fichier docker-compose.yml que j’utilise sur ma VM pour exécuter le site et Watchtower :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


services:
 portfolio:
 image: registry.gitlab.ggcorp.ovh/ggauzins/portfolio:latest
 container_name: portfolio
 restart: unless-stopped
 ports:
 - "8086:80"

 watchtower:
 image: containrrr/watchtower
 container_name: watchtower
 environment:
 - WATCHTOWER_POLL_INTERVAL=300  # toutes les 10 minutes
 - WATCHTOWER_CLEANUP=false  # supprime les anciennes images
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 command: portfolio

Ce fichier permet :

D’exécuter automatiquement l’image Docker générée par GitLab CI
De mettre à jour automatiquement le conteneur dès qu’une nouvelle image est disponible dans le registre

✅ Résultat final

Site en ligne avec HTTPS à l’adresse : https://www.ggauzins.fr
Déploiement 100 % automatisé : un simple git push suffit
Image Docker toujours à jour sur ma VM grâce à Watchtower
Domaine personnalisé et infrastructure maîtrisée

🔚 Conclusion

Ce projet m’a permis de mettre en pratique des compétences DevOps complètes :
CI/CD, conteneurisation, reverse proxy, gestion de certificat SSL, automatisation du déploiement.

🎓🖥️ Projet BTS : présentation de l'infrastructure

Thu, 23 May 2024 00:00:00 +0000

Plan du réseau

Schéma physique

Notre réseau physique est composé de deux switch Cisco Catalyst 2960 qui sont notre cœur de réseau, d’un autre switch Cisco que nous n’utilisons pas et d’un switch DELL PowerConnect 2708 qui interconnecte nos 3 serveurs HPE de virtualisation. Nous avons aussi un NAS qnap nous permettant de stocker les backups des machines virtuelles et les ISO des OS utilisés pour la création des VM. Sur nos quatre switch nous utilisons le protocole 802.1q afin de taguer certains liens, notamment les trois liens allant des trois switch cœur de réseau au switch DELL et trois autres liens allant des serveurs au switch DELL nous permettant de créer des machines virtuelles sur n’importe quel VLAN (réseau). Notre lien internet arrive sur un port de SW02 qui se trouve dans le vlan WAN, ce qui nous permet de virtualiser notre pare-feu.

Sur nos serveurs, nous avons installé l’OS XCP-ng pour la virtualisation. XCP‑ng est un projet de plate‑forme de virtualisation permettant de déployer des infrastructures de Machines Virtuelles. La plate‑forme est basée sur l’hyperviseur Xen et embarque l’API Xen (XAPI). XCP‑ng est un fork de la solution Citrix Hypervisor. Pour pouvoir administrer les serveurs XCP-ng, nous avons installé Xen Orchestra qui est une solution de gestion et de backup d’infrastructures et d’environnements virtuels basés sur Xen. Elle fonctionne aussi bien avec Citrix XenServer qu’avec XCP-ng.

Schéma logique

Mots de passe des services, des machines virtuelles et du matériel

Identifiant et mots de passe des machines virtuelles accessibles en ssh/rdp

Nom du serveur	Identifiant	Mot de passe
srv-glpi (ssh)	glpi	glpi
srv-docker-PROD (ssh)	docker	gsb$generique,1234
srv-docker-DMZ (ssh)	docker	gsb$generique,1234
srv-docker-MGT (ssh)	docker	gsb$generique,1234
srv-xoa (ssh)	xoa	gsb$generique,1234
srv-ad [DHCP,DNS,AD] (rdp)	administrateur	gsb$generique,1234

Identifiant et mots de passe des services

Nom du service	Nom de la VM où tourne le service	Protocole/port d’accès	Identifiant	Mot de passe
Xen Orchestra	srv-xoa	HTTPS	admin	gsb$generique,1234
qnap	qnap	HTTPS	admin	gsb$generique,1234
Portainer	srv-docker-MGT	HTTPS:9443	admin	gsb$generique,1234
Heimdall	srv-docker-MGT	HTTPS dashboard.a.net
Grafana	srv-docker-MGT	HTTP:3000	admin	gsb$generique,1234
Prometheus	srv-docker-MGT	HTTP:9090
snmp-exporter	srv-docker-MGT
xen01,02	srv-docker-MGT
Wordpress	srv-docker-PROD	wordpress.a.net	admin	gsb$generique,1234

Identifiants et mots de passe du matériel

Matériel	Identifiant	Mot de passe	Accès
Switchs	admin	changeme	SSH
XCP-NG01,02	root	changeme	Physique via KVM
Linksys05253		admin	linksys.a.net

Description des services

Service	Description
Wordpress	Site vitrine exposé au réseau externe via le reverse-proxy Traefik.
Traefik	Reverse proxy pour rediriger les requêtes http en fonction de l’url utilisée.
Heimdall	Dashboard pour centraliser l’accès aux outils de gestion et de monitoring.
OPNsense	OPNsense est une distribution open-source de pare-feu et de routeur basée sur le système d’exploitation FreeBSD. Elle offre une interface utilisateur conviviale et une gamme de fonctionnalités de sécurité avancées, y compris la détection d’intrusion, le filtrage de contenu, la gestion des réseaux privés virtuels (VPN),…
XCP-ng	XCP‑ng est un projet de plate‑forme de virtualisation permettant de déployer des infrastructures de Machines Virtuelles. La plate‑forme est basée sur l’hyperviseur Xen et embarque l’API Xen (XAPI). XCP‑ng est un fork de la solution Citrix Hypervisor.
Xen orchestra	Xen Orchestra est une solution de gestion et de backup d’infrastructures et d’environnements virtuels basés sur Xen. Elle fonctionne aussi bien avec Citrix XenServer qu’avec XCP-ng.
Grafana	Grafana est une plateforme open source de monitoring, analyse et visualisation des données systèmes en temps réel.
Prometheus	Prometheus est un logiciel libre de surveillance informatique. Il enregistre des métriques en temps réel dans une base de données de séries temporelles (avec une capacité d’acquisition élevée) en se basant sur le contenu de point d’entrée exposé à l’aide du protocole HTTP.
snmp-exporter	Le snmp-exporter est un composant utilisé dans l’écosystème de surveillance Prometheus pour collecter des données à partir d’appareils utilisant le protocole SNMP
xen-exporter	Le “xen-exporter” est un outil conçu pour exporter des métriques de XCP-ng (XenServer) vers Prometheus. Il s’agit d’un script Python qui collecte diverses statistiques système à partir de l’API RRD de XCP-ng.
Docker	Service de conteneurisation pour faciliter le déploiement d’applications et optimiser les ressources utilisées. Trois serveurs Docker sont utilisés dans trois VLANs différents pour séparer les services.
Portainer	Outil de gestion centralisée des serveurs docker. Nous l’utilisons pour déployer des stacks sur chaque serveur (équivalent au fichier docker-compose). Un conteneur Portainer est installé sur le serveur Docker-MGT et un conteneur Portainer-Agent est installé sur les deux autres.
GLPI	GLPI est un logiciel de gestion de services informatiques qui permet de gérer les ressources informatiques de l’infra. Il offre des fonctionnalités telles que l’inventaire des équipements et la gestion des tickets d’incidents et des demandes de support.
Active Directory	Un serveur AD est un service de gestion d’annuaire pour les réseaux Windows. Il centralise l’administration et la sécurité des utilisateurs et des ressources, permettant l’authentification et l’autorisation sur le réseau. Nous l’utilisons pour les comptes d’utilisateur.
DNS	Un serveur DNS interne traduit les noms de domaine en adresses IP pour les ordinateurs d’un réseau privé. Il facilite la résolution des noms pour les ressources internes, comme les sites web et les serveurs locaux. Cela améliore la gestion et l’efficacité des communications au sein du réseau d’entreprise.
DHCP	Un serveur DHCP dans un réseau local attribue automatiquement des adresses IP aux dispositifs connectés, comme les ordinateurs et les smartphones. En présence d’une borne Wi-Fi, il permet aux appareils de se connecter sans configuration manuelle, simplifiant ainsi la gestion du réseau.
QNAP	Serveur NAS utilisé pour stocker les images ISO nécessaires à la création des machines virtuelles. Nous stockons également les backups des VMs*.

*Nous n’avons pas mis en place de réelle stratégie de sauvegarde dû au fait que nous devions éteindre fréquemment les serveurs, on effectue une sauvegarde manuelle des VM avant chaque extinction. Une tâche de sauvegarde complète est programmée à 2h du matin mais dû à ces contraintes, elles ne sont pas effectuées.

Plan du réseau

Vlans

Nom	N° VLAN	Adresse CIDR	Description
PROD	10	172.16.10.0/24	Serveurs de production
MGT	11	172.16.11.0/24	VLAN Management
DMZ	100	172.16.100.0/24	DMZ
SI	2	192.168.2.0/24	Service Informatique
DG	3	192.168.3.0/24	Direction Générale
EMP	4	192.168.4.0/24	Employé
WAN	110	192.36.253.0/24	WAN

Notre adresse externe : 192.36.253.10/24

Switchs

A-SW01

État : Pas utilisé / pas configuré
Fast Ethernet : Aucun port utilisé

A-SW02

Adresse de management : 172.16.11.2
Ports Fast Ethernet :
- VLAN 11 : Fa0/1, Fa0/2
- VLAN 2 : Fa0/3
- VLAN 4 : Fa0/4
Ports Gigabit Ethernet :
- Trunk : Gi0/1 (vert), Gi0/2 (orange)

A-SW03

Adresse de management : 172.16.11.3
Ports Fast Ethernet :
- VLAN 2 : Fa0/1
- VLAN 3 : Fa0/2
- VLAN 4 : Fa0/3, Fa0/4
Ports Gigabit Ethernet :
- Trunk : Gi0/1 (vert), Gi0/2 (bleu)

A-SW04

Gi0/1, Gi0/2, Gi0/3 et Gi0/4 : Vers les serveurs
Gi0/5 et Gi0/6 : Vers les switch A-SW02 et A-SW03
Gi0/7 : Vers le NAS de backup

Gi0/1 - Gi0/2	Gi0/3 - Gi0/4	Gi0/5 - Gi0/6	Gi0/7 - Gi0/8
Trunk	Trunk	Trunk	VLAN 2
Trunk	Trunk	Trunk	-

Plan des IPs

VLAN de Management (MGT)

Plage d’adresses : 172.16.11.0/24
DHCP : de 172.16.11.100 à 172.16.11.150

Adresses statiques :

Adresse IP	Nom
172.16.11.1
172.16.11.2	A-SW02
172.16.11.3	A-SW03
172.16.11.4	srv-xoa
172.16.11.5	qnap
172.16.11.6	srv-docker
172.16.11.7
172.16.11.8
172.16.11.9
172.16.11.10
172.16.11.11	XCP-NG01
172.16.11.12	XCP-NG02
172.16.11.13	XCP-NG03
172.16.11.14
172.16.11.254	OPNsense (FW + NTP)

Services hébergés sur srv-docker (172.16.11.6)

Port	Service
80	Heimdall
443	Heimdall
9443	Portainer
9090	Prometheus
3000	Grafana
3100	Loki
9116	SNMP Exporter
9116	SNMP Exporter
116	SNMP Exporter

VLAN de Production (PROD)

Plage d’adresses : 172.16.10.0/24
DHCP : non

Adresses statiques :

Adresse IP	Nom
172.16.10.1	srv-dc
172.16.10.2	srv-glpi
172.16.10.3	srv-docker-prod
172.16.10.4
172.16.10.5
172.16.10.6
172.16.10.7
172.16.10.254	OPNsense (FW + NTP)

Services hébergés sur srv-docker-prod (172.16.10.3)

Port	Service
8081	Wordpress

VLAN zone DMZ

Plage d’adresses : 172.16.100.0/24
DHCP : non

Adresses statiques :

Adresse IP	Nom
172.16.100.1	srv-docker-dmz
172.16.100.2
172.16.100.3
172.16.100.4
172.16.100.5
172.16.100.6
172.16.100.7
172.16.100.8
172.16.100.9
172.16.100.10
172.16.100.11
172.16.100.254	OPNsense (FW + NTP)

Services hébergés sur srv-docker-dmz (172.16.100.1)

Port	Service
80	EntryPoint HTTP
8080	Web UI Traefik
443	EntryPoints HTTPS

VLAN service informatique (SI)

Plage d’adresses : 192.168.2.0/24
DHCP : de 192.168.2.1 à 192.168.2.252

Adresses statiques :

Adresse IP	Nom
192.168.2.1
192.168.2.2
192.168.2.3
192.168.2.253	Borne Wifi
192.168.2.254	OPNsense (FW + NTP)

VLAN employés (EMP)

Plage d’adresses : 192.168.4.0/24
DHCP : de 192.168.4.1 à 192.168.4.253

Adresses statiques :

Adresse IP	Nom
192.168.4.1
192.168.4.2
192.168.4.254	OPNsense (FW + NTP)

VLAN direction générale (DG)

Plage d’adresses : 192.168.3.0/24
DHCP : de 192.168.3.1 à 192.168.3.253

Adresses statiques :

Adresse IP	Nom
192.168.3.1
192.168.3.2
192.168.3.254	OPNsense (FW + NTP)

La VM srv-ad

L’annuaire AD, DHCP et DNS sont hébergés sur la même machine virtuelle appelée srv-ad.
Cette VM assure plusieurs rôles essentiels au bon fonctionnement du réseau :

Annuaire Active Directory (AD) : centralise l’authentification des utilisateurs et des équipements, permettant une gestion centralisée des comptes, des permissions et des politiques de sécurité.
Serveur DNS interne : résout les noms de domaine privés en adresses IP pour faciliter l’accès aux ressources internes (serveurs, sites internes, services réseau).
Serveur DHCP : attribue automatiquement des adresses IP aux équipements connectés aux VLANs, assurant une gestion dynamique et sans conflit des adresses réseau.
Authentification SSO (Single Sign-On) : l’Active Directory est également utilisé pour permettre l’authentification unique (SSO) sur différents services internes, évitant ainsi aux utilisateurs d’avoir à saisir leurs identifiants multiples fois.

Règles de NAT (Port Forward)

Traduction d’adresses réseau pour accéder aux ressources internes depuis l’extérieur.

Port 80 (HTTP) :
- Redirection de l’IP public 192.36.253.10 vers IP interne 172.16.100.1 (Traefik) sur le port 80.
- Interface : WAN.
- Port externe : 80 ➔ Port interne : 80 (HTTP).

Règles de pare-feu (Firewall Rules)

Définissent les autorisations et les blocages du trafic réseau entrant et sortant.
Priorité donnée à la sécurité des VLANs et à l’accès contrôlé aux services.

WAN

Autoriser (pass) :
- Protocole : IPv4 TCP
- Destination : 172.16.100.1 (port 80 / HTTP)
- Action : Autoriser le trafic entrant (Régle qui est associée avec celle du NAT)
Bloquer (block) :
- Rejet des connexions non sollicitées.

MGT (Management)

Autoriser (pass) :
- Trafic sortant autorisé.
Bloquer (block) :
- Rejet explicite de connexions non autorisées.

EMP (Employés)

Autoriser (pass) :
- Trafic sortant vers le réseau interne autorisé.
Bloquer (block) :
- Refus des connexions sortantes vers PROD.

DMZ

Autoriser (pass) :
- Trafic autorisé vers Internet et vers PROD pour le serveur web.
Bloquer (block) :
- Rejet par défaut de tout trafic non autorisé.

Relai DHCP

Mise en place d’un relai DHCP permettant aux VLANs de recevoir des adresses IP dynamiquement depuis le serveur DHCP centralisé (srv-ad).

Auteur

Projet réalisé dans le cadre de l’épreuve de fin d’année de BTS
📅 Année : 2024
👨‍🎓 Étudiant : Géraud GAUZINS
🏫 Établissement : Lycée Monnet-Mermoz à Aurillac

Posts on Geraud GAUZINS

👉 🏠 Présentation de mon infrastructure

🧪 Projet personnel – Infrastructure complète

🖥️ Virtualisation – XCP-ng + Xen Orchestra

🐳 Conteneurisation – Docker + Portainer CE

💾 Stockage – TrueNAS SCALE

🌐 Réseau et sécurité

🚀🛠️ Déploiement automatisé de mon portfolio avec GitLab et Docker

🧠 Création et déploiement automatisé de mon portfolio avec GitLab, Docker et Traefik

🎯 Introduction

🧠 Pourquoi GitLab ?

💡 Idée initiale : GitLab Pages

🔁 Nouvelle stratégie : Docker + Watchtower

🛠️ Technologies utilisées

⚙️ CI/CD avec GitLab

build_image

pages

🧾 Fichier .gitlab-ci.yml

🐋 Dockerfile

🌍 Reverse Proxy avec Traefik

🌐 Site principal – www.ggauzins.fr

📁 GitLab Pages – *.pages.ggcorp.ovh

🐳 Docker Compose utilisé

✅ Résultat final

🔚 Conclusion

🎓🖥️ Projet BTS : présentation de l'infrastructure

Plan du réseau

Schéma physique

Schéma logique

Mots de passe des services, des machines virtuelles et du matériel

Identifiant et mots de passe des machines virtuelles accessibles en ssh/rdp

Identifiant et mots de passe des services

Identifiants et mots de passe du matériel

Description des services

Plan du réseau

Vlans

Switchs

A-SW01

A-SW02

A-SW03

A-SW04

Plan des IPs

VLAN de Management (MGT)

VLAN de Production (PROD)

VLAN zone DMZ

VLAN service informatique (SI)

VLAN employés (EMP)

VLAN direction générale (DG)

La VM srv-ad

Règles de NAT (Port Forward)

Règles de pare-feu (Firewall Rules)

WAN

MGT (Management)

EMP (Employés)

DMZ

Relai DHCP

Auteur

`build_image`

`pages`

🧾 Fichier `.gitlab-ci.yml`

🌐 Site principal – `www.ggauzins.fr`

📁 GitLab Pages – `*.pages.ggcorp.ovh`