Choix de la plateforme
Dis, comment on crée un blog ?
Techniquement parlant, il y a de multiples façons de publier et gérer un blog. Peut-être pas autant de façon de faire que de personnes sur terre mais il y en a bien assez :
- Utiliser un CMS (« Content Management System », traduisible par « Système de gestion de contenu »), le plus connu étant le fameux WordPress, avec deux possibilité :
- en l'installant et en l'hébergeant soi-même (par là, j'inclus le fait de passer par un hébergeur qui propose des facilités d'installation et de maintenance) ;
- en choisissant un service de gestion de contenu sans installation, d'ailleurs WordPress en propose un sur wordpress.com mais on peut aussi évoquer des plateformes aux sources fermées comme Medium.
- Créer sa propre plateforme (et après, on peut même publier les sources ou encore en faire une plateforme d'hébergement payante ) ;
- Utiliser un outil de génération statique et héberger ça là où ça nous intéresse (chez un hébergeur de contenu statique, sur un serveur chez un fournisseur cloud ou bien sur un serveur qu'on a chez soi).
Voilà les solutions « habituelles », j'ai pu en oublier une ou deux moins courantes.
Bien sûr, chaque personne ou entreprise choisira sa solution selon ses propres critères.
Mes critères
Justement, j'ai mes propres critères « de base ».
Je souhaite respecter un objectif de faible consommation de ressources, c'est-à-dire que je ne veux pas une plateforme « usine à gaz » qui nécessiterait trop de puissance processeur ou de quantité de mémoire vive. J'ai déjà un serveur très peu cher (mais très peu performant) qui héberge le site statique de mon entreprise (vous me voyez venir, j'avais des critères similaires pour ce dernier), il m'arrangerait de mutualiser mon site dessus pour des raisons économiques et écologiques (surtout que je prévois très peu de traffic pour les deux sites).
De manière un peu similaire, j'ai envie d'avoir pas ou peu de maintenance à faire (pour éviter de la consommation de mes ressources humaines, qui sont constituées de moi et qui dépendent fortement d'une liste de paramètre qui est trop longue pour être explicitée ici), ce qui sous-entend : pas trop de choses à mettre à jour, pas de migration lourde en cas de grosse mise à jour, pas trop de dépendances à installer.
Aussi, j'apprécie vraiment l'utilisation d'un gestionnaire de version pour tout ce qui est code et j'ai tendance à trouver que c'est bien pratique au delà de ça, donc j'aimerais pouvoir stocker mes articles sur un dépôt Git.
Éventuellement, j'aimerais une compatibilité ActivityPub mais c'est très optionnel et plutôt pour la satisfaction personnelle. Si toutefois ce critère n'est pas rempli, avoir la possibilité de générer des flux RSS/Atom me semble être le minimum.
Enfin, je veux que la solution soit open source, parce qu'il y en a plein et que ça me ferait mal de choisir une plateforme propriétaire quand il y a du choix libre.
Qu'est-ce qui nous reste ?
De là, ça filtre :
- Les solutions qui utilisent une base de données, parce que soit je dois la gérer (donc ça me coûte en ressources personnelles de l'ordre de la charge de travail), soit je dois en prendre une gérée par un fournisseur (donc ça me coûte en ressources personnelles de type financières) ;
- Les solutions qui utilisent un langage interprété, comme PHP/Ruby/Python, parce que ça rajoute une dépendance lourd (on notera que je prône la conteneurisation donc la gestion peut être simplifiée, mais ça reste du CPU et de la RAM à consommer pour peu de choses).
Il reste donc :
- Les générateurs de sites statiques, ça reste un peu de travail mais beaucoup moins (et rappelons que j'ai un déjà serveur pour un autre site statique donc ce sera mutualisé) ;
- Les solutions hébergées qui utilisent un CMS open source comme plateforme.
Bref, j'ai choisi un générateur de site statique. Et comme il faut en choisir un seul alors qu'il y en a plétore, j'utilise Zola car il correspond à mes critères et pour d'autres raisons qui nécessiteraient presque un nouvel article.
Maintenant, l'hébergement
Tout ça c'est chouette et en sautant quelques étapes, admettons que j'ai maintenant mes fichiers HTML et CSS qui sont générés, comment je les déploie et comment je les sers ?
Déjà, je réutilise le serveur que j'ai cité plus haut et qui me coûte presque rien (ce n'est pas de la radinerie, c'est du bon sens).
En terme de logiciels, j'ai besoin d'un simple serveur HTTP qui permet de délivrer des fichiers statiques. Je dois aussi pouvoir configurer le HTTPS dessus : on est en 2024, ça fait presque dix ans qu'on peut avoir des certificats gratuits avec Let's Encrypt donc il est inconcevable de ne pas mettre en place du HTTPS (si vous voyez un site qui ne propose toujours pas du HTTPS, fuyez ne serait-ce que pour le principe, mais je m'égare).
Ça tombe bien, j'ai fait le choix de la simplicité sur la machine virtuelle que j'ai déjà : on y trouve Debian et Podman. Et grâce à un conteneur lancé par ce dernier, Caddy tourne en dernière version.
Caddy, c'est un serveur HTTP à la configuration très simpliste et lisible, qui intègre l'automatisation de la gestion des certificats HTTPS avec le protocole ACME (en utilisant Let's Encrypt par défaut). Il fait donc tout le travail dont j'ai besoin. Et pour prouver que c'est facile, voici la base de mon Caddyfile, le fichier de configuration de Caddy :
1 # redirection permanente de ces deux domaines vers le domaine principal
2 candy.pm, www.candy.pm {
3 redir https://sam.candy.pm{uri} permanent
4 }
5
6 # le fameux domaine pricinpal
7 sam.candy.pm {
8 encode zstd gzip # activation de la compression du contenu envoyé en HTTP
9 root * /var/www/sam.candy.pm # chemin du dossier qui contient les fichiers statiques
10 file_server # quand un chemin fini par /, on tente index.html
11 }
Sans aucune indication spécifique, Caddy va tenter de générer les certificats HTTPS pour tous les domaines listés automatiquement. Fini le certbot ou autre (qui ne donnait pas un travail fastidieux mais il fallait configurer le serveur HTTP, tout ça… Bref, il fallait faire des choses et j'ai horreur de faire des choses ) !
De manière un peu plus complète, j'y ai ajouté la gestion du cache et des pages d'erreurs :
1 # les règles de caches : 90 jours pour les polices d'écritures, 30 jours pour les images
2 (cache) {
3 @image {
4 path *.svg *.png *.jpg *.jpeg *.gif *.ico
5 }
6
7 @font {
8 path *.ttf *.eot *.woff2
9 }
10
11 header @font Cache-Control "public, no-transform, max-age=7776000"
12 header @image Cache-Control "public, no-transform, max-age=2592000"
13 }
14
15 # la gestion des erreurs, il faut donc bien avoir un fichier 404.html et un 500.html
16 (errors_handling) {
17 handle_errors {
18 @404 {
19 expression {http.error.status_code} == 404
20 }
21
22 @500 {
23 expression {http.error.status_code} == 500
24 }
25
26 rewrite @404 /404.html
27 rewrite @500 /500.html
28
29 file_server
30 }
31 }
32
33 # redirection permanente de ces deux domaines vers le domaine principal
34 candy.pm, www.candy.pm {
35 redir https://sam.candy.pm{uri} permanent
36 }
37
38 # le fameux domaine pricinpal
39 sam.candy.pm {
40 encode zstd gzip # activation de la compression du contenu envoyé en HTTP
41 root * /var/www/sam.candy.pm # chemin du dossier qui contient les fichiers statiques
42 file_server # quand un chemin fini par /, on tente index.html
43 }
Ce Caddyfile est dans un dépôt Git, le site Zola a son propre dépôt.
Et voilà, cet article est donc sur tous les écrans qui le désirent grâce à Zola, Debian, Podman et Caddy.
Pour plus tard
Actuellement, je gère tout ça avec une certaine flemme, parce que c'était un des objectifs principaux (pas d'avoir la flemme mais de composer avec). Sauf que je suis irrécupérable et que je sais qu'un jour, je changerai complètement ma manière d'héberger tout ça.
Pour l'instant, j'utilise un conteneur pour Caddy qui gère tous mes sites. Mais à terme j'espère avoir une architecture de qualité encore plus professionnelle :
- Chaque site (actuellement deux) serait dans son propre conteneur ;
- Les conteneurs ne feraient que lancer un
zola builden premier « stage » et récupérer les fichiers résultants dans un deuxième stage, avec un simple serveur HTTP (sans HTTPS) comme commande par défaut ; - Du coup, le serveur frontal ne servirait plus des fichiers statiques mais aurait plutôt un rôle de proxy.
Jusque là, on pourrait trouver peu d'intérêt à cette évolution. Pour mieux comprendre, voici deux rappels : je n'aime pas maintenir les choses et là, je dois maintenir un serveur Debian ainsi que mettre à jour le conteneur de Caddy. Du coup, pour héberger des fichiers statiques je pourrais me contenter de Netlify ou équivalent.
Mais je n'aime pas trop ces plateformes, je ne saurais pas vraiment expliquer pourquoi, c'est peut-être simplement « pas mon genre ».
Je compte plutôt exploiter les connaissances que j'utilise professionnellement pour faire évoluer mon hébergement vers une solution d'orchestration de conteneurs avec un cluster Kubernetes auto-géré chez un fournisseur cloud français (certainement OVH ou Scaleway) dans lequel j'installerai la gateway Envoy avec cert-manager pour versionner le routage et automatiser le TLS. Oui, ça a l'air de faire « usine à gaz », pas très « low tech » (mais quand même « low maintenance » puisque le cluster serait infogéré). Pour couronner le tout, je ferais fonctionner Renovate pour automatiser la mise à jour des dépendances sus-citées.
Pour autant, c'est un projet qui n'a pas lieu d'être actuellement pour quelques raisons :
- Le fonctionnement actuel me convient ;
- Le coût de mon serveur actuel est dérisoire et ce serait dommage de payer plus cher ;
- Tant que je n'ai pas de besoins au delà de l'hébergement de fichiers statiques, ça ne vaudra donc pas les efforts que ça me demanderait ni le coût.
Bref, c'est une ouverture que je regarde de loin pour l'instant et que j'approcherais quand j'aurais des besoins plus « importants » (le choix du futur conditionnel n'est pas anodin ici). En attendant, mon petit Caddy dans un conteneur m'est amplement suffisant (et je m'attache même un peu à lui).