Pourquoi ce blog ?
- blog
- nextjs
- gitlab ci
- docker
- aws
Introduction
Je travaille depuis plus de dix ans dans le domaine des infrastructures de virtualisation et du cloud privé (notamment VMware). Depuis cinq ans je me suis spécialisé dans le cloud automation, ce qui m'a permis de découvrir le monde merveilleux du code. "Le dev dans les nuages" est donc pour moi un side project qui représente ces deux facettes : le developpement et l'infrastructure (le cloud).
L'idée de faire un blog me trotait dans le tête depuis un moment, et j'ai finis par sauter le pas !
Vous allez donc pouvoir retrouver ici des articles sur de sujets tels que :
- le code
- le web dev
- le devops
- le cloud
- l'automatisation
- la domotique
Le blog
Les motivations
N'étant pas développeur web de métier, je n'ai pas le niveau en web dev d'un professionnel. J'ai un niveau débutant de quelqu'un qui s'est auto-formé sur HTML, CSS, JS et React (merci Udemy et youtube), et a appliqué ces technos sur certains side projects.
Ce que je voulais à l'origine du projet :
- objectif : partager des articles sur les sujets IT qui m'intéressent
- me former sur : Nextjs, Gitlab CI, Docker, AWS
- réaliser le projet de bout en bout, du developpement au déploiement (pas de CMS type wordpress, pas de WIX...)
- site light : pas de commentaires, pas d'API, pas de backend, pas de DB
- hébergement : cloud publique
Les choix
- site statique : pour ce qui est du web dev j'avais déjà expérimenté le CSR (Client Side Rendering) avec React, ainsi que le Server Side Rendering (SSR) avec Nodejs et le moteur de template EJS. Le cas d'un blog simple se prétant bien au Static Site Generation (SSG), j'ai opté pour Nextjs qui est l'un des principal framework React permettant de faire du SSG
- dev front : page d'accueil avec recherche par nom d'article et filtrage par tag (en React). Chaque article correspond à une route dans /posts/* généré lors du build
- hébergement : le choix du cloud provider AWS a été stratégique, sachant que j'avais déjà investit en 2022 dans une formation A Cloud Guru AWS puis la certification AWS Certified Cloud Practitioner. De plus, mon compte AWS free tier auquel j'avais toujours accès me permettait de tester gratuitement énormément de fonctionnalités. Le choix a donc été vite fait
- déploiement : je voulais monter en compétence sur Docker car j'avais très peu d'expérience dessus et je savais que cette techno était incontournable dans le monde de l'infrastructure et du devops. Quand on veut héberger du conteneur chez AWS, on se retrouve face à plusieurs offres, et notamment : EKS (Elastic Kubernetes Service) et ECS (Elastic Container Service). Etant donné la taille de mon application et de mon budget, j'ai assez rapidement opté pour ECS avec instance EC2. En effet ECS permet de monter un cluster à partir d'un seul host EC2, contrairement à EKS qui nécessite plus de host, et donc me reviendrait plus cher. J'aurai également pu utiliser docker compose sur une instance EC2 sans passer par ECS ou EKS, mais le but était d'utiliser au maximum les services AWS dans la mesure où ils ne sont pas payants (c'est le cas d'ECS)
- CI/CD : le fait que j'utilise du docker pour cette application m'a orienté en faveur de GitLab CI plutôt que Jenkins. En effet, choisir GitLab CI dans ce cas là apporte plusieurs avantages / facilités : la gestion native des conteneurs, et le container registry
- point de départ : ne connaissant pas Nextjs, j'ai simplement suivi le tutoriel dans la documentation nextjs blog tuto. Ce tutoriel correspond tout à fait à mon use case : la création d'un blog en SSG. L'exemple en sortie du tutoriel est visible ici nextjs blog demo, et le code ici nextjs blog code. Enfin, le Markdown est le choix fait pour la gestion du contenu (un fichier local .md = un article)
Le design
Le schéma général
Ci-dessous un schéma orienté accès, hébergement et mise à jour du contenu représentant une partie des services AWS utilisés :
Note : Les sites statiques sont la plupart du temps hébergés sur des CDN (Content Delivery Network) type CloudFront chez AWS. J'ai choisis de ne pas utiliser de CDN car un de mes objectifs était de monter en compétences sur des technos et services dont Docker, et passer par un CDN ne m'aurait pas fait utiliser Docker.
Les technos
Les technos et composants utilisés :
Development | CI/CD | Deployment | Hosting |
---|---|---|---|
Nextjs (SSG) | gitlab-ci.yml | Docker | Route S3 |
React | Gitlab CI runner | Dockerfile | VPC |
Javascript | Branching stategy | Docker registry | EC2 |
HTML | Cypress (test) | Nginx | Security Group |
CSS | Certbot | IP Table | |
Markdown (CMS) | Elastic IP | ||
ECR | |||
ECS | |||
Internet Gateway |
Les étapes
Les étapes du développement au déploiement, et où elles se déroulent :
Le mot de la fin
Voilà pour ce premier article 😉 J'avais initié ce projet il y a un an, et l'avais mis en suspend au bout de quelques semaines par manque de temps. J'ai repris le projet récemment, et aujourd'hui le blog n'est pas terminé, beaucoup de choses sont perfectibles, mais il fallait sortir ce projet, car je crois que le plus important dans un projet c'est d'agir même si ce qu'on fait n'est pas parfait. De nouvelles fonctionnalités arriveront probablement avec le temps.
Lors des prochains articles j'aborderai en détail les technos et étapes qui m'ont permis de mettre au jour ce projet.