Comment fonctionne ce site ?

Présentation du projet

Ce site a été créé pour vous offrir un aperçu clair et complet de mes compétences et de mon travail. Mon but est de vous présenter mes projets, les technologies que je maîtrise, et comment je les utilise pour résoudre des problèmes concrets.

Ce portfolio a plusieurs objectifs :

Mettre en avant mes projets : Vous y trouverez des détails sur les projets sur lesquels j’ai travaillé, montrant comment j’ai appliqué mes compétences pour atteindre des résultats tangibles. Illustrer mes compétences : Le site présente les technologies et outils que j’utilise, ainsi que mon approche pour les intégrer efficacement dans mes projets. Partager mon expérience : À travers des articles et des études de cas, je décris les défis que j’ai rencontrés et les solutions que j’ai mises en place, offrant ainsi un aperçu de mon processus de travail. En utilisant Hugo pour créer ce site statique et en le configurant avec Docker, j’ai non seulement développé un espace pour partager mon travail, mais aussi démontré ma capacité à gérer des projets techniques de manière autonome.

Choix de technologies et architecture

1. Pour rendre le site accessible à n’importe quel utilisateur (et pas uniquement en local), plusieurs options sont possibles :

   • Hébergement automatisé : solutions comme GitLab Pages ou GitHub Pages, qui sont simples à mettre en place.
   • Hébergement configurable : un peu plus personnalisable tout en restant facile d’utilisation, comparable à un SaaS, où l’on dispose d’un “logiciel” accessible via le web pour configurer son site en production.
   • J’ai opté pour une solution plus configurable pour des raisons d’apprentissage. J’utilise un serveur de type VPS où j’héberge l’application web. Dans ce cas, je suis dans un modèle IaaS (Infrastructure as a Service), où j’achète directement de l’infrastructure.

2. L’application web est un site web statique, créé avec un générateur de site web, Hugo. Hugo est une solution efficace pour créer rapidement des sites statiques avec un contenu conséquent. J’ai couplé Hugo avec un template adapté à mes besoins. Le template que j’utilise est conçu spécifiquement pour fonctionner avec Hugo, facilitant ainsi la création de contenu et offrant une partie du design déjà prête. Le moteur de template est Hugo Blox.

3. Une fois le site créé en local et le VPS accessible, il est nécessaire d’intégrer le code et de le rendre accessible. Pour ce faire, j’utilise un conteneur Docker avec une version d’Apache à l’intérieur. Il suffit de placer les sources de mon site dans le dossier html du conteneur pour qu’il soit accessible.

Cependant, une fois le site accessible, il reste un problème : il n’y a pas de certificat SSL, donc le site n’est pas en HTTPS.

Pour résoudre ce problème, je me suis basé sur un post LinkedIn de Leon Sczepansky, qui utilise Docker Compose avec Apache et Let’s Encrypt pour publier son site en HTTPS. Le conteneur Apache se construit en cherchant les fichiers nécessaires pour la certification SSL.

Voici la configuration Docker Compose utilisée :

version: '3.7'
services:
  productive-apache:
    container_name: 'productive-apache'
    image: productive-apache:latest
    build:
      context: .
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./httpd.conf:/etc/apache2/httpd.conf
      - ./html/:/var/www/localhost/htdocs/
      - /docker-volumes/etc/letsencrypt/live/martin-genereux.fr/cert.pem:/etc/letsencrypt/live/martin-genereux.fr/cert.pem
      - /docker-volumes/etc/letsencrypt/live/martin-genereux.fr/fullchain.pem:/etc/letsencrypt/live/martin-genereux.fr/fullchain.pem
      - /docker-volumes/etc/letsencrypt/live/martin-genereux.fr/privkey.pem:/etc/letsencrypt/live/martin-genereux.fr/privkey.pem
      - /home/martin/logs/test1/:/var/www/logs/
    networks:
      - docker-network
    environment:
      - server_name=martin-genereux.fr
networks:
  docker-network:
    driver: bridge

Les fichiers cert.pem, fullchain.pem, et privkey.pem sont chargés dans le conteneur pour obtenir la certification SSL. Avant cela, il faut lancer le conteneur Let’s Encrypt pour obtenir ces fichiers de certification.

Voici la commande Docker pour exécuter Certbot et obtenir les certificats :

# Exécuter la commande Certbot pour renouveler les certificats
sudo docker run -it --rm \
-v /docker-volumes/etc/letsencrypt:/etc/letsencrypt \
-v /docker-volumes/var/lib/letsencrypt:/var/lib/letsencrypt \
-v "$PWD/html:/data/letsencrypt" \
-v /docker-volumes/var/log/letsencrypt:/var/log/letsencrypt \
certbot/certbot \
certonly --webroot \
--email martingenereuxccl@gmail.com --agree-tos --no-eff-email \
--webroot-path=/data/letsencrypt \
-d martin-genereux.fr -d www.martin-genereux.fr

Ce script shell est exécuté tous les 3 mois grâce à un cron pour renouveler les certificats automatiquement.

Déploiement

Le déploiement du site a été automatisé grâce à un pipeline CI/CD que j’ai configuré avec GitLab. Ce pipeline simplifie le processus de déploiement et garantit que les mises à jour du site sont effectuées de manière fluide et sans erreur. Voici comment ce pipeline est structuré :

1. Configuration du Pipeline GitLab CI/CD

   Le pipeline est divisé en deux étapes principales : build-sources et deploy-sources.

   • Étape build-sources : Cette étape utilise Docker pour construire le site statique. Il s’exécute dans un conteneur Alpine, où les outils nécessaires sont installés (Git, Go, et Hugo). La commande hugo est exécutée pour générer le site, et le dossier public/ contenant les fichiers statiques est enregistré comme un artefact.

   • Étape deploy-sources : Après la construction, cette étape s’occupe du déploiement sur le serveur VPS. Elle utilise également un conteneur Alpine pour installer openssh-client et configurer les clés SSH nécessaires pour se connecter au serveur. Le pipeline supprime les anciens fichiers de la destination sur le serveur, puis copie les nouveaux fichiers générés dans le répertoire approprié.

   Voici le fichier .gitlab-ci.yml que j’utilise pour ce processus :

   stages:
     - build-sources
     - deploy-sources
   
   build-sources:
     tags:
       - springVps
     image: alpine:latest
     stage: build-sources
     before_script:
       - apk add --update --no-cache git go
       - apk add --no-cache --repository=https://dl-cdn.alpinelinux.org/alpine/edge/community hugo
     script:
       - hugo
     artifacts:
       paths:
         - public/
   
   deploy-sources:
     tags:
       - springVps
     image: alpine:latest
     stage: deploy-sources
     before_script:
       - apk update
       - apk add --no-cache openssh-client
       - chmod 400 $SSHVPS
       - mkdir -p ~/.ssh
       - chmod 700 ~/.ssh
     script:
       - ssh -i $SSHVPS -o StrictHostKeyChecking=no -p 2879 root@martin-genereux.fr "rm -rf /home/apache-and-letsencrypt/production/html/*"
       - scp -i $SSHVPS -o StrictHostKeyChecking=no -P 2879 -r public/* root@martin-genereux.fr:/home/apache-and-letsencrypt/production/html
   

2. Automatisation et Avantages

L’automatisation du déploiement réduit le risque d’erreurs humaines et accélère le processus de mise en production des nouvelles versions du site. En utilisant GitLab CI/CD, je m’assure que chaque modification apportée au code est automatiquement testée et déployée de manière cohérente, garantissant ainsi une intégrité constante du site.

3. Future évolutions

Pour l’avenir, je prévois d’intégrer des tests automatisés dans le pipeline afin de vérifier la qualité du code avant le déploiement. De plus, des ajustements pourront être apportés pour améliorer les performances du pipeline et s’adapter à l’évolution des besoins du site.

En mettant en place ce pipeline CI/CD, je m’assure que le site reste toujours à jour et fonctionne de manière optimale, tout en minimisant les interventions manuelles nécessaires pour le déploiement.