La tech stack derrière christ.azika-eros.org V3

Mes projets personnels ont toujours été l’occasion pour moi de ne pas perdre la main en développement logiciel et cette troisième version de christ.azika-eros.org n’est pas une exception. Voyons ensemble les différentes technologies que j’ai utilisées.

Pourquoi pas Wordpress ?!

La réponse courte est que je n’ai pas l'intention ni un quelconque intérêt à apprendre à utiliser, customiser, gérer et sécuriser Wordpress. C'est une prouesse à part entière qu’il faut saluer, vu l’usine à gaz que c’est à la fin d’un déploiement.

Tout comme la V2, j’ai opté pour le développement d’un petit CMS à la différence que je n’utiliserai pas le langage Ruby et son mini framework Sinatra.

Django unchained !

Dans la V2, j’ai voulu capitaliser sur mon expérience en Ruby on Rails. Pour la V3, l’objectif était de disposer d’un mini CMS opérationnel en 2 / 3 jours. Rien de mieux pour cela que d’utiliser Django, le framework “des perfectionnistes pressés par une deadline”.

Django est un framework en Python que j’utilise depuis 2010 donc je capitalise clairement sur mon expérience dessus, sans devoir apprendre quelque chose de nouveau. De plus, il fournit clé en main une interface d’administration pour réaliser en quelques clics les opérations CRUD sur les différents modèles (tables). Vous disposez d’emblée d’un mini back-end, pratique pour les tests voire gérer le contenu !

Python/Django n’est pas bien supporté par les hébergements mutualisés mais dans mon cas, je dispose de VMs sous utilisées déjà administrées dans ce problème ne se pose pas.

Le stockage des données

La V2 affichait uniquement des articles donc l’usage d’une base de données étaient totalement inutiles.

Cette V3 doit gérer plusieurs rubriques ainsi que des transactions diverses (fichiers, formulaires, paiements ?...). L’usage d’une base de données s’est naturellement imposé et bien sûr, le choix s’est porté sur le GOAT, SQLite qui peut supporter jusqu'à 281 To de données et 4 millions de QPS (queries per second) sans broncher. Cerise sur le gâteau, la base tient sur un seul fichier, pratique pour les backup !

12 facteurs

Je suis un grand fervent du respect des 12 facteurs qui facilitent grandement le développement, le déploiement et la maintenance des applications serveurs. Contrairement aux apparences, ces règles ne s’appliquent pas qu’aux micro-services. Dans mon cas, cela donne :
_ gestion du code : Git ;
_ dépendances : Python/virtualenv + requirements.txt déclarant les modules utilisés installables facilement avec Pip ;
_ Configuration : Utilisation des variables d’environnement déclarant les variables et services externes nécessaires ;
_ Services externes rattachés : Les services rattachés sont Mailchimp et la base de données. Les fichiers statiques (images, ...) sont sur le disque du serveur. L’idéal aurait été de les pusher sur un service comme S3 ou R2 de Cloudflare (moins cher et efficace) mais ce serait de l’over-engineering vu le niveau faible de criticité du site à ce stade ;
_ Séparation de l’assemblage et l’exécution : L’application peut être packagée dans une image puis exécutée sous forme de conteneur ;
_ Processus sans état : Non respectée car l’application est monolithique et donc non scalable horizontalement, la base de données étant sur le même serveur ;
_ Associations de ports : seuls les ports HTTP et HTTPS sont utilisés ;
_ Concurrence : Pas de scalabilité horizontale (ajout de serveurs) possible car non nécessaire ;
_ Jetable : L’application est packagée et lancée dans un conteneur donc facilement manipulable et jetable ;
_ Parité dev/prod : l’usage des conteneurs permet de développer dans un environnement iso-prod ;
_ Logs : Les logs sont exportés dans la sortie standard stdout ;
_ Process d’administration : Django fournit des scripts d’administration pratiques clefs en main.

Comme vous pouvez le voir, certaines règles ne sont pas respectées car j’ai opté pour une architecture monolithique simple, ne considérant pas le site comme critique (pour le moment…).

Environnement de production

Le site a été déployé dans une VM hébergée chez OVH Cloud (ils sont experts en goumins IT mais bon, on continue encore un peu à les encourager).
L’architecture adoptée est la suivante :
_ Code hébergé sur Gitlab ;
_ VM ubuntu ;
_ Let’s Encrypt assure le déploiement et la mise à jour du certificat TLS à travers le fabuleux outil Cerbot ;
_ Nginx joue le rôle de reverse proxy pour servir les différents sites et conteneurs écoutant sur un port différent en localhost. Nginx assure également la terminaison TLS ;
_ L’application tourne dans un conteneur issu d’une image ubuntu customisée pour le site.

Pour faciliter la mise à jour rapide du site en production, le code est dans un dossier de la VM, monté en volume dans le conteneur. Idem pour les dossiers des logs et des fichiers uploadés (images du blog, etc...)

Environnement de dev

Mon mac ayant rendu l'âme, j’ai dû basculer à moyen terme sur Windows. J’ai lâché vim pour Visual Studio Code (avec le mode vim…) qui est prometteur (bravo Microsoft).

La configuration se veut iso-prod. L’application tourne en local dans le même conteneur que celui de la production avec les différents volumes montés (code, logs, assets).

Je code sur Windows et teste directement dans le conteneur Linux de prod. Excepté les retours chariots qui diffèrent selon l’OS (\n vs \r\n) et le maintien des droits exécutables bancal, je trouve ce montage relativement efficace pour réduire les disparités dev/prod.

C’est tout ?

Oui, pour le moment. Le plus important est de lancer rapidement une version que l’on peut améliorer sans trop de difficulté. C’est une fois confronté au public que les améliorations efficaces s'opèrent.

Je pense par exemple à basculer sur AWS là encore pour ne pas perdre la main et continuer à découvrir le boss du cloud. En attendant, voici la V3.0.0.