Reboot (forcé) de mon site

Il y a deux semaines environ, j’ai subi sur mon serveur dédié une attaque ayant pour conséquence la totale destruction de mes données. J’ai alors décidé de recréer un nouveau site en me basant cette fois-ci sur des techniques liées aux sites statiques.

Forcé de repartir à zéro

Je dois avouer que je ne me suis jamais senti à l’aise avec le concept de site dynamique. Le serveur PHP, les bases SQL et le traitement dynamique me paraissait bien trop “lourd” pour l’utilisation que je pouvais faire d’un site internet, à savoir exploiter un lieu où présenter mes différentes expérimentations. De plus, j’ai toujours trouvé ce genre de site assez lent à la détente, me faisant regretter les simples pages HTML statiques.

Ayant déjà eu énormément de problèmes avec WordPress ou même Drupal par le passé, je ne voulais surtout pas repartir sur ce modèle. Mon précédent site était quand à lui basé sur le système “Ghost”, qui avait l’avantage d’être plus léger lors de sa mise en place. Celui-ci n’avait pas recours à une base de données, mais à des fichiers locaux rédigés en MarkDown, un langage balisé simplifié que j’ai tout de suite beaucoup aimé. Cette solution me convenait déjà mieux, mais Ghost est un système faisant un usage intensif du serveur nodeJS, afin de tout de même générer à la volée les pages, converties du MarkdDown brut vers le code HTML. On peut donc considérer que Ghost est en quelque sorte, lui aussi, un système dynamique.

Parmi les gros points noirs de ce système, on peut noter la difficulté de faire cohabiter plusieurs sites sur le même serveur, la prise en charge très rudimentaire du multilingue et le fait que l’architecture des fichiers était assez alambiquée.

Quelques semaines avant le hacking de mon serveur, je me posais déjà la question de repartir sur un nouveau site, me permettant d’avoir un meilleur contrôle de la structure produite par tout ces outils. L’idée de repartir sur des pages faites à la main de manière complétement statiques me titillait de plus en plus, au risque assumé de passer pour un vieux débris, utilisant des techniques du passé.


Cependant, lors de mon passage au Capitole du Libre 2018, j’ai eu l’occasion d’assister à une conférence de Frank Taillandier, nommée “La hype statique ne fait que commencer !”, disponible ici :

A la lecture du titre de cette conférence, je me suis dit dans un premier temps que cela n’avait surement aucun rapport avec ma problématique et que les désavantages des sites statiques seraient à jamais rédhibitoires. Pourtant, en lisant la description de cette conférence dans le programme du Capitole du Libre, cela semblait correspondre à ce que je recherchais. Intrigué, je me suis donc rendu à cette conférence qui m’a pas mal éclairci sur les raisons qui poussent les développeurs à revenir à ce type de sites, faisant apparaitre que je n’étais finalement peut-être pas si has-been que cela, en ce qui concerne les technos Web tout du moins.

Après un historique très intéressant sur l’évolution des outils de conception, Frank expliqua que les sites dynamiques dans leur grande majorité, ont eu tendance à s’alourdir de plus en plus, les rendant de moins en moins performants. Les centaines de plugins Wordpress s’accumulant les uns sur les autres, cela n’a fait apparemment que s’aggraver d’année en année.

Dans le cas de mon site personnel, je n’ai pas besoin du côté “dynamique” en soit, puisque chaque ajout (article, tutorials, etc) produit une nouvelle page qui n’a pas lieu de s’ajuster en fonction du lecteur. Chaque page est donc statique, ce qui la rend plus rapide à charger puisque le serveur sert directement une page HTML sans passer par une requête de génération, comme c’est le cas en PHP.

Dans un site purement statique, on note cependant l’aspect rébarbatif de l’ajout d’un nouveau post. Une fois la page rédigée, il faut encore l’insérer dans le menu, le référencer, etc …

La meilleure solution serait donc d’avoir un environnement de développement “dynamique” qui à la fin produirait une suite de fichiers statiques constituant le site. Et bien figurez-vous que c’est justement le principe de ce grand retour des sites statiques ! De plus, afin de rendre certaines parties de ces sites dynamiques, des micro-services sont injectés dans les pages via le concept de la “JAM Stack”, utilisant les API Javascript du côté client et non du côté serveur. Je ne m’étendrai pas sur cette notion ici car Franck l’aborde dans sa conférence et de nombreuses ressources sur ces concepts sont disponibles sur le net.

Dans mon cas, je n’ai même pas besoin de l’aspect dynamique, puisque je veux conserver chaque page dans un état statique. La mise en place d’un tel site est donc encore plus simple.


Je suis alors parti à la recherche d’un “moteur de site statique”, qui serait capable de prendre des templates pour la génération des pages, des articles rédigés en MarkDown et de mélanger le tout dans un shaker afin de produire autant de pages HTML statiques qu’il y aurait de posts sur sur mon site. Après de nombreuses lectures, il me fallait faire un choix entre les deux stars de la catégorie, à savoir Jekyll et Hugo. Ce dernier, bien que plus jeune, me semblait aussi plus robuste notamment de part l’absence de plugins … ce qui lui conférait une certaine légèreté. Malgré le fait que celui-ci avait pour réputation d’être un peu plus complexe que Jekyll, il ne m’a fallu qu’une journée pour comprendre le concept, ajouter un thème, le modifier à ma guise (css, template, layout, etc …) et commencer à rédiger des posts.

Je vous conseille la lecture de ces deux articles dont la simplicité m’a beaucoup aidé à avoir rapidement un résultat à l’écran et de quoi expérimenter :

Un premier article en anglais :

Start a blog in 30 minutes with Hugo, a static site generator written in Go

Et un autre en français :

Passer aux générateurs de sites statiques

Le concept est on ne peut plus simple. Une fois l’executable Hugo téléchargé (un seul fichier de moins de 20 Mo), il suffit à la manière du gestionnaire Cargo en RUST, de taper la ligne de commande suivante pour créer un nouveau site :

hugo start new le_Nom_De_Votre_Site

Une arborescence sera alors créée. Il suffit d’entrer dans celle-ci, puis d’ajouter un thème (non fourni par défaut, ce qui fera apparaître votre site initialement blanc et vide)

Les thèmes pour Hugo sont disponibles à cette adresse :

https://themes.gohugo.io/

Ajouter une nouveau post se fait via la commande :

hugo new mon_Post

Un nouveau fichier MarkDown (qui est en fait un simple fichier texte) sera alors créé avec avec en entête certaines données comme la date ou le nom de l’auteur. Cependant, il est aussi possible de créer un fichier texte vide et de commencer à rédiger ces informations, voir de faire un copier/coller d’un fichier précédent pour générer une nouvelle article dans le bon dossier.


Le système est d’une telle légèreté que j’ai retrouvé le plaisir de rédiger des articles dans le train sur mon bon vieux netbook de plus de 10 ans d’âge. Equipé d’une distribution Manjaro et du navigateur Chromium (Firefox commençait à devenir trop lourd pour cette machine), il faut reconnaitre que cela fonctionne super bien. Avec le navigateur sur un bureau virtuel et un l’éditeur de texte sur un autre, il suffit de sauver son fichier MarkDown via un Ctrl+S pour que le Hugo rafraichisse automatiquement le contenu, Chromium gardant la pagination actuelle, ce qui est bien pratique pour voir tout de suite le résultat.

Il suffit de lancer la commande suivante pour démarrer le serveur Hugo en mode dynamique :

hugo server

Par défaut, la création d’un nouvel article via la commande consacrée ajoute au début du fichier une variable “draft” dont la valeur est “true”. Cette option permet de ne pas afficher l’article dans la liste du blog, de part son état de “brouillon”.

Si l’on désire afficher tous les articles, y compris ceux dans cet état, il suffit de lancer Hugo en mode :

hugo server -D

Hugo scan à présent l’arborescence de votre site et le rend visible sur le port 1313, de votre machine locale. Il suffit donc de taper dans la barre d’adresse de votre navigateur :

localhost:1313

Et voilà ! Votre site est maintenant visible. Une fois tous les éléments développés comme vous l’entendez, vous aller pouvoir générer les pages statiques qu’il vous suffira d’uploader chez votre hébergeur. Il suffit pour cela de couper Hugo via Ctrl+C, puis de le relancer sans aucun argument :

hugo

Un nouveau dossier “Public” est à présent disponible dans votre arborescence, contenant la totalité des fichiers constituants votre site. Si un arborescence était déjà présente, alors une mise à jour des fichiers modifiés depuis la dernière fois sera opérée. Cela dit, même si la génération devait être effectuée de manière complète, cette phase de production des fichiers statiques est extrêmement rapide ! C’est un des points forts de Hugo sur ses concurrents.

Il vous suffit de transférer ces fichiers chez votre hébergeur et voilà votre site en ligne. Deniers petits conseils, dans le fichier config.toml se trouvant la racine du dossier contenant votre site, pensez à remplir la variable baseurl avec le nom de votre site, comme exemple https://www.coyhot.com. De plus, vérifiez bien dans votre éditeur de texte que l’encodage de vos fichier MarkDown sont bien en UTF-8. Cela vous évitera de voir tout vos accents remplacés par des caractères étranges.


En conclusion, bien que l’attaque sur mon serveur m’ait causé bien des désagréments, cela m’aura au moins permis de mettre en place ce nouveau site et de découvrir une nouvelle manière de la créer, qui me correspond beaucoup mieux d’un point de vue technique.