Infrastructure Serverless – Partie 1/5 : Générateur de site (Patreon)

Comme vous le savez sûrement, au fil du temps le blog écrire pour un client, une série d'articles sur la mise en place d'une infrastructure Serverless. Le deal est tombé à l'eau mais les articles étant rédigés, je me suis dit que ça pourrait vous aider / inspirer pour mettre en place votre propre site sans serveur.

Merci à Léo pour le travail. Bonne lecture à tous !

Korben

Infrastructure Serverless – Générateur de site

Comme vous le savez sûrement, au fil du temps le blog korben.info est devenu un site conséquent et par son nombre de page que par sa sollicitation.Régulièrement,  nous cherchons et mettons en place divers outils ou méthodes dans le  but d’optimiser son exploitation, c’est à dire le rendre plus  performant, plus rapide, mais aussi plus stable. Inévitablement il arrive que soit l’infrastructure elle-même qui nécessite une optimisation.

Ces derniers temps, nous avons étudié la possibilité d’une  transition vers une nouvelle forme d’infrastructure. Cette forme,  récemment popularisé sous le nom un peu buzzword de  « serverless », propose de distinguer les différentes parties d’une  structure web classique pour les placer dans des environnements qui leur  sont adaptés et ainsi optimiser à chaque étape.

De manière générale, nous avons définis les objectifs avec les points suivants.

Optimiser le rendu web pour gagner en performances et en dynamisme ;

Bénéficier d’un dimensionnement dynamique pour absorber le trafic tout en économisant des ressources ;

Réduire la surface d’attaque pour maximiser sa sécurité ;

Favoriser la portabilité pour simplifier le changement de solution ou de prestataire.

Dans ce dossier, nous vous proposons d’explorer et de mettre en place un schéma d’infrastructure serverless, étape par étape.

Notre dossier sur l’infrastructure serverless

Infrastructure Serverless – Partie 1 : Générateur de site (cet article)

Infrastructure Serverless – Partie 2 : Hébergement statique (à venir)

Infrastructure Serverless – Partie 3 : Gestion de contenu (à venir)

Infrastructure Serverless – Partie 4 : Fonctions cloud (à venir)

Infrastructure Serverless – Partie 5 : Micro-services et conclusion (à venir)

<figure></figure>

Générateur de site

L’origine

Tout le monde un peu tech connais WordPress, Drupal ou un  équivalent. Souvent regroupés sous le terme de CMS (Content Management  System), ils fournissent une fonctionnalité primordiale : le rendu de  page.

Le rendu de page consiste à utiliser des templates, des bout de page  HTML, et des les associer entre eux, en fonction du contenu, pour  obtenir une page HTML complète.

Problème, ces rendus sont fait à la volée. Chaque visite  d’une page du site demande au serveur web de lui-même demander au  service de rendu (WordPress, Drupal, etc.) de générer la page, et ce que  ce soit la première visite ou millième.

Or pour le frontend d’un  blog, les pages HTML ne varient que très peu. Il n’y pas de rendu  spécifique à chaque visite, ou très peu, la grande majorité des réponses  sont identiques à leurs sœurs. Elles pourraient donc être  intégralement statiques, générée une fois pour la vie, ou plutôt jusqu’à  une opération qui change le contenu.

Le principe

Pourquoi donc ne pas se contenter de simples fichiers HTML ?Évidement,  en 2022, la manipulation directe de fichiers HTML n’est pas  envisageable, en particulier à grande échelle. On ne saurait écrire à la  main 15 000 pages HTML, même 10 c’est pénible.Se passer d’un gestionnaire de thème/template est inimaginable.

L’objectif est donc de troquer le serveur de rendu, qui consomme des  ressources en excès en effectuent un calcul répété, à un générateur qui  fournis le rendu unique, dit statique (les fichiers sont immuables en  quelque sorte).En outre, bonne surprise, les solutions d’hébergement  de fichiers statiques sont très nombreuses et bon marché. Nous en  reparlerons dans la prochaine partie.

La solution

Du coup, pour la génération des pages, nous allons utiliser un outils de templating.

Il en existe beaucoup,  tous avec leur spécificité, leurs points forts. Le plus gros  différenciateur est le langage (JavaScript, Go, etc.) et/ou le  templating (Vue.js, React, etc.).

Le principe d’un tel outil est d’utiliser une implémentation  locale (le thème) et connecter une source de donnée locale ou distante  (voir Gestion de contenu) pour construire l’intégralité de  site. L’implémentation locale et la source sont agnostiques sur la  technologie utilisée, des changements et des migrations peuvent être  effectuées simplement, avec seul une réécriture de la pile logicielle  concernée et clairement délimitée.

<figure></figure>

Les générations des fichiers statiques sont déclenchées par les  éditions de contenus sur le gestionnaire de contenu par l’éditeur du  site, ou par les modification du thème ou des éléments techniques par  les développeurs.

L’usage simple

De notre côté, nous avons choisi Gatsby,  car ils convient bien à nos exigences et est stable et bien maintenu.  Il est aussi open source, mais soutenu par la version commerciale de  Gatsby, ce qui rassure sur sa pérennité.Enfin, Gatsby a fait office d’une revue complète des performances pour la génération de sites volumineux (~20 K pages).

Pour un petit site de démonstration, la mise en place est simplissime (un très bon guide existe sur le site de Gatsby) :

Dans un environnement Node.js et Git, installons l’outil de commande Gatsby.

npm install -g gatsby-cli

Initialisons un dépôt comportant le thème et les couches techniques.L’initialisation  est interactive avec des questions de métadonnées et techniques. Mise à  part le nom, tous les paramètres peuvent être laissés par défaut.

gatsby new<figure></figure>

Une fois l’initialisation terminée, une sortie indique les commandes pour commencer à développer.Mais le dépôt est déjà exploitable et un génération pour un déploiement statique est déjà possible.

gatsby build<figure></figure>

Le résultat

Les pages statiques se trouvent alors dans le dossier public/.On a ainsi obtenu un site statique, i.e. des pages HTML/CSS « simples », tout en conservant la puissance des templates.

On notera que les résultats de tests de performance aves un tel rendu  sont évidemment excellents, et tous les éléments sont présents pour  obtenir des progressive web apps, des sites compatibles au mode  hors-ligne, etc.

Côté code, on obtient un dépôt relativement simple et surtout bien structuré. Notre dépôt de démo est disponible sur GitHub, si vous souhaitez y jeter un coup d’oeil.

La suite

Cette construction étant statique, elle est directement déployable sur un hébergement statique.Nous reverrons ensemble la problématique de l’Hébergement statique dans la prochaine partie.