↓Aller au contenu

To Jekyll and Beyond

·1000 mots·5 mins
Sommaire

Après avoir pas mal chipoté entre Pelican, Wordpress, mon propre générateur, mes envies, mes râleries, j’ai finalement switché vers Jekyll.

A première vue, c’est un générateur qui fait un peu figure de mamie, au milieu des petits nouveaux que sont Hugo, Hexo ou Zola. Ce qui m’a décidé:

  1. Quel que soit le générateur, il m’aurait fallu repasser dans tous mes articles pour compléter le frontmatter en YAML.
  2. Je n’ai jamais accroché à la syntaxe des templates de Hugo (ce qui a même valu au créateur de Zola de démarrer son propre générateur de site statique)
  3. Le frontmatter de Zola est en … TOML. Il est prévu d’autoriser une version stricte de YAML, mais ce n’est pas encore intégré sur la branche principale. Quitte à retravailler tous mes articles dans un format, autant que ce format soit relativement portable et ne me demande pas trop de travail la prochaine que j’aurai une envie de changement.
  4. Jekyll est orienté blogs. Il n’est pas nécessaire de trop réfléchir à sa structuration, dans la mesure où toute l’architecture est orientée vers du contenu chronologique.
  5. Jekyll vient avec un répertoire fourni de plugins et de thèmes. A nouveau, comme la structure est bien documentée, ce sont les thèmes qui s’adaptent au contenu, et pas l’inverse - je pense principalement à Hugo, où chaque thème peut définir un ensemble de nouvelles propriétés pour présenter un affichage cohérent, ou à Zola où certains thèmes ne fonctionnent que si la structure des répertoires exigée par le thème est respectée.

Et pour couronner le tout, certains plugins permettent de se passer de frontmatter, disposer d’un moteur de recherche (basé sur lunr.js) ou d’une table des matières.

En bref, c’est joli, fonctionnel, facile à mettre en place, permissif et flexible. Tout ce que j’aime dans un outil :-)

Le seul point un chouia négatif concernerait la mise en place en elle-même, puisqu’il faut disposer d’un environnement Ruby, de plusieurs dépendances, que l’installation sous Windows n’est pas des plus faciles, … et en même temps, je m’en fiche, parce que la génération va passer par Drone.

Zou, c’est parti pour la configuration!

Configuration des clés SSH
#

Par sécurité (?), j’ai créé un nouvel utilisateur jekyll sur le serveur.

adduser --disabled-login --gecos 'jekyll' jekyll
su - jekyll
ssh-keygen -t ed25519
cat .ssh/ed25519 > .ssh/authorized_keys

Configuration de Drone
#

Pour configurer Drone, il n’y a pas grand chose à faire. Juste quelques essais à réaliser (et donc quelques builds qui ont échoué).

Build 1 - ruby:latest
#

Le premier build a réussi, mais je n’ai pas pris beaucoup de risques: j’ai juste câblé la dernière image disponible pour Ruby, puis démarré la construction du site à partir des sources. Forcément, ça a réussi. Mais entre le téléchargement de l’image, la récupération des prérequis et la construction des dépendances, il faut compter près de 5 minutes pour avoir un résultat. Il y a sans doute moyen d’améliorer ça…

Build 2 - ruby:latest + deploy step
#

Le deuxième build ajoute une étape de déploiement via SCP au pipeline. Sauf que comme un gros débile, j’ai mal nommé les secrets entre le pipeline et les secrets. On recommence.

Build 3 - ruby:latest + deploy step (2)
#

Avec les bons secrets, ça passe. Jusqu’à l’authentification de mon utilisateur jekyll sur le serveur. Il fallait encore ajouter la clé dans le fichier /home/jekyll/.ssh/authorized_keys pour qu’il puisse se connecter.

Après cela, le déploiement s’est correctement déroulé! Plus qu’à accélérer les étapes qui peuvent l’être.

Build 4 - jekyll:latest
#

Permission denied @ dir_s_mkdir à l’étape de construction :-( Après une petite recherche, il fallait ajouter chown -R jekyll:jekyll /drone dans les commandes à exécuter.

Build 5 - jekyll:latest + deploy = everything’s fine!
#

Le fichier .drone.yml final ressemble à ceci:

kind: pipeline
name: default

steps:
- name: build
    image: jekyll/jekyll:latest
    commands:
    - chown -R jekyll:jekyll /drone
    - gem update --system
    - gem install bundler
    - bundle install
    - bundle exec jekyll build
- name: deploy
    image: appleboy/drone-scp
    settings:
    host: grimbox.be
    user:
        from_secret: ssh_user
    key:
        from_secret: ssh_key
    port: 22
    source:
        - _site/
    target: /var/www/grimbox.be

trigger:
    branch: [master]
    event: [push, tag]

Il y a sans doute moyen d’améliorer encore une étape ou deux, par exemple une petite notification avec l’état final via Telegram ou par email.

Configuration d’Nginx
#

Avec le pipeline ci-dessus, les fichiers sources sont copiés vers le répertoire /var/www/grimbox.be/_site. J’ai simplement modifié la variable root dans mon fichier de configuration.

Conclusion
#

A chaque push ou tag sur la branche principale, les sources sont envoyées dans un container avec la dernière version de jekyll, qui s’occupe de la construction, pour ensuite la passer via SCP à mon serveur.

Au final, je pense que c’est un tout petit peu de l’overkill que d’instancier un nouveau container juste pour envoyer des fichiers via SCP… Et je me demande si ce type d’outil ne serait pas simplement présent sur l’image jekyll de base, pour économiser un chouia en ressource. Le soucis alors serait que l’étape de déploiement serait inclue dans l’étape de construction…

Mais au final, j’ai ce que je voulais:

  • Mes sources dans un dépôt Git, avec historique.
  • Un pipeline de déploiement continu (relativement simple, je vous l’accorde)
  • La possibilité d’utiliser n’importe quel éditeur: Codium, l’éditeur de Gitea, …
  • Une fonction de recherche sur le site
  • Quelques friandises utiles et une chouette présentation au travers du thème minimal-mistakes - que j’aimerais encore peaufiner un peu.
  • La possibilité de séparer mes articles selon leur catégorie, tout en conservant une trame chronologique qui ne soit pas proprement séparée en sections.

Et le tout, avec un time-to-market de moins de 40 secondes entre le push et la mise en production :-)

Ressources
#