Home
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é:
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!
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
Pour configurer Drone, il n’y a pas grand chose à faire. Juste quelques essais à réaliser (et donc quelques builds qui ont échoué).
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…
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.
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.
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.
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.
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.
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:
Et le tout, avec un time-to-market de moins de 40 secondes entre le push et la mise en production :-)
authorized_keys
pour le nouvel utilisateur.