Au revoir Ghost, bonjour Hugo

Avertissement : Cet article a été traduit de l’anglais par un LLM. La précision n’est pas garantie. Vous pouvez lire l’article original en anglais.

Depuis sa création, ce blog fonctionnait avec Ghost sur un serveur dédié. Comme j’en étais de moins en moins satisfait, j’ai décidé qu’il était temps de changer, et de donner sa chance à Hugo, un générateur de sites statiques open source.

Dans cet article, j’expliquerai pourquoi j’ai effectué cette migration, et comment j’ai configuré S3 et CloudFront sur AWS (en utilisant Terraform) pour héberger mon blog.

Pourquoi cette migration ?

#

Il y avait pas mal de choses qui me dérangeaient avec Ghost. Parmi elles :

• Le manque de thèmes et modules maintenus (par exemple : les modules d’hébergement d’images AWS n’ont eu aucun commit depuis des années ; au bout d’un certain temps, j’ai dû arrêter d’utiliser le thème que j’avais payé et installé quand j’ai commencé à utiliser Ghost parce qu’il n’était plus mis à jour, causant des problèmes partout, …)
• À un moment, j’ai commencé à utiliser Casper, le thème officiel, avec quelques modifications, mais cela signifiait que je devais appliquer ces modifications à chaque fois que je mettais à jour le thème
• Pas de bon système de gestion des médias, et l’éditeur n’est pas si agréable à utiliser (surtout quand on écrit du markdown simple, comme des listes imbriquées)
• Le rendu des pages était lent
• Du point de vue de l’administration système, Ghost se plaint si son répertoire d’installation n’a pas ses droits configurés au moins à chmod 755, même s’il tourne sous son propre utilisateur, et le dernier 5 n’est pas utile (aussi, j’ai un profond dégoût pour les technologies JS-ish)

Le coup de grâce a été d’essayer de migrer mon blog vers un nouveau serveur. L’export ne contient pas tout, et ensuite, Ghost ne fonctionnait pas correctement après la mise à jour de Node.js (que j’aurais pu corriger, mais à ce stade, toutes ces petites choses m’ont donné envie d’essayer autre chose). Ne vous méprenez pas, je pense toujours que Ghost est une assez bonne plateforme, mais je ne crois pas que ce soit actuellement le meilleur outil pour ce que je veux faire.

À partir de là, j’ai considéré WordPress : facile à installer et maintenir, beaucoup de modules et thèmes disponibles, … Mais je vois des CVE liées à WordPress dans mon flux RSS un jour sur deux. Aussi, cette plateforme n’est pas connue pour sa rapidité.

Dans le passé, j’avais entendu parler de Hugo, un générateur de sites statiques open source, et sachant que je ne tirais de toute façon pas vraiment parti des fonctionnalités non-statiques de Ghost, j’ai décidé de l’essayer. Par rapport à Ghost :

• C’est plus rapide (évidemment, puisque le site est statique)
• C’est plus facile à héberger (d’abord parce que c’est juste un site statique, et ensuite parce que Hugo peut déployer le site automatiquement vers une variété de services comme AWS, Azure ou Cloudflare), et c’est moins cher
• Cela ne nécessite virtuellement aucune maintenance (pas besoin de s’inquiéter de mettre à jour un serveur régulièrement, plus facile à sauvegarder, …)
• Le site et le thème sont plus faciles à personnaliser (bien qu’il n’y ait pas beaucoup plus de choix que pour Ghost en ce qui concerne les thèmes)
• Bien sûr, je perds un peu de commodité du fait que le site devienne statique (par exemple si je décide de donner aux lecteurs la possibilité d’ajouter des commentaires, je devrai utiliser Disqus ou quelque chose du genre)

Configuration AWS

#

Comme je l’ai mentionné précédemment, mon blog Hugo est hébergé sur AWS, en utilisant S3 et CloudFront. Tout est configuré avec Terraform, et poussé grâce aux capacités de déploiement intégrées de Hugo. Passons en revue les étapes que j’ai suivies pour mettre mon blog en ligne.

AWS Certificate Manager

#

La première étape était de créer un certificat pour ixonae.com et www.ixonae.com en utilisant ACM. J’ai utilisé la méthode de validation DNS basique et RSA 2048. Ensuite, j’ai ajouté les entrées CNAME appropriées à mes paramètres DNS pour prouver que j’en étais propriétaire. Il aurait été possible de le faire depuis Terraform également, mais comme mon fournisseur DNS n’est pas AWS, j’ai trouvé plus facile de générer le certificat à la main (à cause de l’étape de validation).

Notez que pour être utilisable avec CloudFormation, le certificat doit être créé dans la zone us-east-1.

Configuration S3 et CloudFront via Terraform

#

La configuration fait plus de 100 lignes, donc je ne la collerai pas ici, mais vous pouvez la voir sur GitHub. Ce qu’elle fait est le suivant :

• Crée un bucket nommé example-website qui
  • Conserve l’historique des modifications de fichiers pendant 30 jours, ensuite il ne gardera que la modification la plus récente
  • A son accès défini comme non-public, et son contenu ne peut être demandé qu’à travers CloudFront
  • Utilise une clé de chiffrement de bucket (“la clé de bucket réduit les coûts de chiffrement en diminuant les appels à AWS KMS”)
• Crée une distribution CloudFront qui
  • Utilise le bucket S3 précédemment créé comme source de données
  • Autorise l’IP v6
  • Définit la politique de cache comme Managed-CachingOptimized (recommandé par AWS)
  • Utilise TLSv1.2_2021
  • Supporte HTTP/2 (HTTP/1 est par défaut, et HTTP/3 peut être ajouté)
  • Configure le certificat SSL grâce à son ARN ID codé en dur, et ajoute des noms de domaine alternatifs
  • Compresse les objets automatiquement
  • Redirige HTTP vers HTTPS
  • Autorise les méthodes HTTP GET et HEAD
  • Configure une fonction CloudFront à appliquer aux requêtes des visiteurs (par défaut les clients accèderont à des URLs telles que ixonae.com/blog/ mais nous voulons que CloudFront accède à ixonae.com/blog/index.html. Cela ne sera pas montré au client qui n’utilisera que l’URL “propre”)
• Crée un bucket S3 example-website-logs, et configure CloudFront pour écrire les logs dans le répertoire logs de ce bucket
• Crée et applique une politique S3 pour permettre à la distribution CloudFront d’accéder au bucket S3 example-website

Notez que si vous voulez réutiliser ma configuration, vous devrez changer ce qui suit :

• Le nom du bucket doit être unique, et il est très probable que quelqu’un utilise déjà example-website
• Vous devez choisir une région (actuellement définie comme xx-xxxx-xx)
• Vous devez définir acm_certificate_arn avec l’ARN du certificat ACM créé à l’étape précédente, et remplacer aliases par les valeurs appropriées

Après avoir appliqué ce Terraform, il ne reste plus qu’à configurer vos enregistrements DNS avec une entrée CNAME pointant vers le nom de domaine de la distribution généré par CloudFront (par exemple abcd.cloudfront.net).

Configuration Hugo

#

La configuration de Hugo est assez triviale. Il suffit que votre fichier de configuration contienne ce qui suit (bien qu’il y ait beaucoup plus d’options d’optimisation disponibles)

[deployment.targets]
name = "mydeployment"
url = "s3://example-website?region=xx-xxxx-x"
cloudFrontDistributionID = "xxxxxxxx"

Et le déploiement peut être fait avec les commandes suivantes (à condition que vous ayez déjà un fichier ~/.aws/credentials avec les bons identifiants)

hugo # Pour compiler le site
hugo deploy # Pour tout uploader et invalider le cache CloudFront

Conclusion et travaux futurs

#

Mon blog est maintenant en ligne avec Hugo et AWS, et je n’ai plus besoin de me soucier de la maintenance serveur ni de m’inquiéter de pouvoir remettre rapidement mon site en ligne en cas de panne. Aussi, j’ai maintenant un score de 100/100 en testant mon site avec PageSpeed Insights.

Ensuite, il y a quelques améliorations de workflow que je prévois de faire :

• Quand quelque chose est poussé sur la branche master de mon dépôt git, déclencher un déploiement vers la stack AWS de production
• Ajouter une tâche cron à mon pipeline CI/CD pour que Hugo essaie régulièrement de compiler et déployer le site (afin que les articles avec une date dans le futur soient automatiquement poussés au moment opportun)
• Quand la même chose est faite sur la branche dev, déclencher un déploiement vers un environnement de test nécessitant une authentification
• Petites améliorations de la configuration AWS (meilleure surveillance et stockage des logs, réplication inter-régions, …)

Crédits

#

• Photo de couverture par Glenn Carstens-Peters sur Unsplash