Logiciels sur Olivier DOSSMANN

Premiers pas avec Hugo, moteur de blog statique

Tue, 07 Apr 2026 17:19:03 +0200

Introduction

Hugo est un moteur de blog statique célèbre pour sa rapidité et sa souplesse d’utilisation. Il permet de générer un site web contenant des milliers d’articles en quelques secondes.

Qu’entends-tu par générer un site web ?

Dire que c’est un moteur de site statique signifie que l’outil va prendre un répertoire d’origine comme base pour compulser les données et générer des pages webs comme par exemple des pages HTML, CSS, XML ou encore du JS (mais d’autres formats sont possibles).

Quel(s) avantage(s) à ce qu’il soit statique ? Une fois vos fichiers générés dans un dossier cible (par exemple un dossier nommé « public »), vous pouvez le déposer chez n’importe quel hébergeur web.

Imaginez votre blog, votre site vitrine ou un site professionnel : aucune dépendance, pas de faille de sécurité liée au langage ou au framework choisi pour publier le site, pas de surcoût de serveur pour des environnements particuliers, pas de lenteurs sur votre site pour calculer tous les éléments avant de les servir à chaque visiteur, etc.

En somme fournir un site web statique est très pratique, économique et facile. D’autant qu’il existe des hébergeurs gratuits pour fournir vos fichiers HTML, CSS, XML, JS. Pourquoi ne pas en profiter ?

En 2016, j’ai fait le choix de migrer mon blog sur Hugo, j’ai donc un peu de bouteille dans son utilisation. J’ai d’ailleurs proposé un thème nommé Adam & Eve pour Hugo que j’utilise pour l’espace Recueil de ce blog.

Aujourd’hui nous allons faire nos premiers pas dans la création d’un blog statique à l’aide d’Hugo. Nous parlerons de l’installation de l’outil, puis de la création du squelette principal, le choix d’un thème, la configuration du blog et la rédaction d’un article avant de générer notre premier blog Hugo 😎.

Photo trouvée sur le profil de Stephen Bowler sur Flickr sous licence CC BY 2.0.

Installation

Étant donné qu’Hugo est un outil qui s’utilise en ligne de commande, il faut installer le binaire sur notre machine. En fonction de votre système d’exploitation la méthode diffère.

La documentation officielle sur l’installation d’Hugo est bien faite. Je vous invite à la consulter promptement.

Si vous avez une distribution GNU/Linux, il existe sûrement un paquet spécifique d’Hugo pour votre distribution.

Par exemple sous ArchLinux il me suffit de faire :

sudo pacman -S hugo

Et le tour est joué !

Une fois installée, vous pouvez taper la commande suivante dans une console pour vérifier que tout soit en ordre :

hugo version

Cela affiche la version d’Hugo que vous venez d’installer.

Plusieurs méthodes permettent d’avoir des infos sur la commande hugo :

man hugo
hugo help

Ou tout simplement se rendre sur la documentation officielle d’Hugo.

Créer un nouveau site

Pour générer un nouveau site nommé superblog :

hugo new site superblog

Hugo lui-même vous informe des étapes à suivre pour terminer votre projet de site, parmi :

se rendre dans le nouveau répertoire,
choisir et ajouter un thème,
configurer le site à l’aide du fichier hugo.toml,
créer du contenu,
vérifier le résultat avec un serveur local dédié (rien que ça !).

Agissons de suite : rendez-vous dans le répertoire superblog et passons au chapitre suivant.

cd superblog

Choisir un thème

L’avantage d’avoir un outil très connu c’est de bénéficier d’innombrables thèmes proposés par la communauté. Vous les retrouverez sur un site officiel dédié aux thèmes prévus pour Hugo.

Étant donné que le travail est fourni par la communauté, leur qualité ou la couverture de fonctionnalités intégrées est dépendante du temps passé sur ces thèmes et le temps accordé à leur maintenance. Autrement dit : il y a à boire et à manger là dedans !

Parcourez l’annuaire de thèmes Hugo, choisissez un thème, par exemple le thème Clean White pour Hugo et cliquez de droit sur le bouton « Download » pour copier l’adresse où se trouve le thème.

Pour l’installer il suffira de taper la commande suivante dans le répertoire superblog (exemple avec le thème Clean White) :

# Nécessite d'avoir la commande `git` installée sur sa machine
git init && git submodule add https://github.com/zhaohuabing/hugo-theme-cleanwhite themes/cleanwhite

On enregistre ensuite le thème dans la configuration de ce site - dont nous parlerons dans le chapitre suivant :

echo "theme = 'cleanwhite'" >> hugo.toml

Si vous êtes curieux du résultat, vous pouvez directement lancer la commande suivante :

hugo serve -D

qui aura pour effet de lancer un serveur web en arrière plan et de vous fournir une adresse URL où consulter votre nouveau site. Par exemple sur http://localhost:1313/. Pour arrêter le serveur, pressez simultanément les touches [Ctrl]+[c].

Regardons de plus près la configuration du site.

Configuration du site, le fichier hugo.toml

La configuration principale de votre site se trouve dans le fichier hugo.toml (anciennement config.toml). La documentation officielle sur le fichier hugo.toml vous donnera une idée de l’ampleur des possibilités qu’offre la configuration d’un site Hugo.

Cantonnons-nous ici de quelques éléments seulement. Le contenu actuel du fichier hugo.toml est :

baseURL = 'https://example.org/'
locale = 'en-us'
title = 'My New Hugo Project'
theme = 'cleanwhite'

Les éléments sont plutôt parlants :

baseURL : va définir l’adresse URL finale de votre site (par exemple pour mon blog ça sera https://olivier.dossmann.net/),
locale : définit le langage du site au regard de la RFC5646,
title : est le titre affiché sur le site,
et theme est l’adresse vers les fichiers du thème utilisé pour notre site.

Modifions le fichier hugo.toml pour ressembler à ceci :

baseURL = 'https://example.org/'
locale = 'fr'
title = 'Mon Super Blog'
theme = 'cleanwhite'
enableEmoji = true

On relance le serveur local intégré à Hugo pour voir le résultat :

# Faites Ctrl + c pour arrêter le serveur
hugo serve -D

On a rajouté une ligne enableEmoji pour activer l’utilisation des emojis dans les articles. Cf. la page de la documentation officielle consacrée à la liste des émojis disponibles sous Hugo.

Mon premier article

Commençons par créer ledit article :

# Très souvent les thèmes proposés n'utilisent que les articles situés dans le dossier "post"
hugo new content -k post post/mon_premier_post.md

L’extension .md est ici nécessaire. L’option -k va suggérer d’utiliser un template post.md s’il existe. C’est ce qu’on appelle un archétype : un fichier au format Markdown situé dans le dossier themes/monTheme/archetypes/ (par exemple themes/cleanwhite/archetypes/post.md) qui sera copié en lieu et place de l’article demandé ; ici dans post/mon_premier_post.md. Les fichiers sont toujours placés dans le dossier content.

Le fichier est placé dans le dossier content/post/mon_premier_post.md dont voici le contenu :

---
title:       "An Example Post"
subtitle:    ""
description: ""
date:        2018-06-04
author:      ""
image:       ""
tags:        ["tag1", "tag2"]
categories:  ["Tech" ]
---

Les articles auront toujours la même forme :

Une entête délimitée par une chaîne de caractère de début et de fin (ici --- en début et fin),
Le contenu de l’article, écrit au format Markdown (par défaut).

Dans le cas présent, nous n’avons aucun contenu.

L’article propose seulement une entête contenant des informations qui seront utilisées comme méta-données de l’article (par exemple son titre, une description, un sous-titre, l’auteur de l’article, éventuellement une image, des balises (tags) et des catégories). L’exemple utilise les tags nommés tag1 et tag2 ; et une catégorie Tech.

Notez également la date fournie : on peut déterminer la date de publication d’un article. Si c’est une date dans le futur, alors l’article ne sera pas publié - ce qui est très pratique !

Pour empêcher également qu’un article soit publié, on peut rajouter une information comme :

draft: true

Ce qui aura pour effet, excepté si l’option -D est ajoutée, de ne pas rendre disponible cet article - très pratique aussi !

Ajoutez quelques lignes à la fin du fichier (après les méta-données et la chaîne de caractère ---) pour regarder le résultat :

# Titre 1

Quelques lignes avec du texte en **gras**, ou *italique*, c'est comme vous voulez.

# Titre 2

## Sous-titre

Avec un lien vers [mon blog](https://olivier.dossmann.net/).

On vérifie à l’aide de la commande hugo serve -D.

Compilation du site

Maintenant que nous avons un site, un thème configuré dans le fichier hugo.toml et un article, voyons l’étape de compilation.

La compilation, avec Hugo, c’est le fait de prendre l’ensemble des fichiers et informations du site et de les transformer en un dossier complet qui fournit les pages Web - et tout autre fichier nécessaire à l’élaboration du site. Hugo stocke le résultat dans un dossier nommé public.

Pour lancer la compilation complète, on peut, à la racine du site, taper la commande suivante :

hugo

Cette commande seule suffit à compiler l’ensemble du site et le rendre disponible dans le dossier public. C’est le contenu de ce dernier que vous devez déposer dans l’espace fourni par votre hébergeur de site web.

On peut agrémenter la commande de plusieurs options, par exemple :

hugo -D --minify

L’option -D va aussi compiler les articles dits « brouillons » (ayant draft: true dans la section des méta-données).

L’option –minify va réduire la taille des fichiers en enlevant le plus possible les espaces, retour à la ligne et assimilés.

Il y a énormément d’options et là encore la documentation officielle d’Hugo sur la commande hugo permet d’en savoir plus.

Conclusion

À travers quelques étapes simples, nous avons vu comment installer la commande hugo, créer un nouveau site, ajouter un thème, configurer le site, rédiger un article et compiler l’ensemble pour générer les fichiers suffisants pour créer un nouveau site web statique.

Hugo est un moteur de site statique très riche et bourré de fonctionnalités en tous genres comme la gestion de contenu multilingue, l’usage de « bouts de code » réemployables, le redimensionnement des images, les commentaires, la génération d’un ou plusieurs flux RSS, la personnalisation des thèmes, une page 404 personnalisée, l’usage de coloration syntaxique pour les balises HTML code, le serveur web embarqué, une commande de déploiement et bien plus encore…

C’est mon outil favori depuis 2016. Je prévois cette année encore de concocter un article supplémentaire à son sujet qui dépendra du présent article qui, je l’espère, vous plaira.

Qui sait, peut-être vous lancerez-vous, vous aussi, dans la création et la publication d’un blog - et cela gratuitement 😉.

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Mon Labo K8S pour essayer des applications

Sun, 09 Nov 2025 06:25:39 +0100

Introduction

Quand on commence à étudier Kubernetes (k8s), on a besoin d’un environnement où tester ce qu’on apprend. Les environnements possibles sont nombreux : Minikube, Kubernetes (k8s) officiel, k0s, k3s, etc. Cela ne s’arrête plus !

Entre les difficultés à installer l’environnement et celles à appliquer ce qu’on apprend, on ne s’en sort plus. Cela devient vite compliqué au point de vouloir tout arrêter ; c’était mon cas.

De plus je souhaitais avoir un environnement reproductible et spécifique à chacun de mes projets, de quoi travailler unitairement sur un service particulier.

Avant de décrocher complètement, j’ai fait une pause, pris du recul et étudié la question. Je vous relate ici le résultat de cette petite aventure dans le monde de Kubernetes et des outils envisagés pour créer un labo de développement d’applications tournant sous Kubernetes.

Dans un premier temps nous poserons le problème, après quoi nous étudierons quelques solutions pour finalement détailler le produit de cette pérégrination.

Photo trouvée sur publicdomainpictures.net sous Licence CC0 Public Domain.

Le contexte

Venant du monde de Docker et Docker Compose, il me semblait aller de soi d’étudier ensuite le monde de Kubernetes - qui utilise la conteneurisation. Seulement je ne pensais pas que l’installation même de Kubernetes était un cap à franchir.

Je souhaite en profiter pour migrer petit à petit mes services sur Kubernetes. Chacun d’eux devient donc un projet en soi. Et comme souvent, j’aime avoir un environnement spécifique de développement pour créer les fichiers nécessaires à Kubernetes et permettre a posteriori d’améliorer le service. Je cherche donc à avoir un simili de docker-compose.yml pour chaque service et permettant de développer l’application dans un environnement Kubernetes propre.

Au début on découvre Minikube. Du moins c’est un outil très souvent conseillé. Pratique sur une machine bureautique pour triturer rapidement quelques fichiers Kubernetes (des fichiers au format YAML). Il est bien documenté et possède plusieurs plugins pour faciliter l’étude du Kubernetes en place ; par exemple un plugin Dashboard permet de visualiser les métriques du serveur et les objets instanciés. J’ai la sensation que cet outil reste « trop spécifique ». Il ne représente pas totalement un « vrai » Kubernetes. Ça peut parfois causer des torts au moment de déployer sur un autre serveur Kubernetes. L’outil est également lourd et relativement lent pour instancier un nouvel environnement.

Pourquoi ne pas tester un Kubernetes connu pour sa légèreté ? Par exemple k3s. D’autant qu’il s’installe rapidement à l’aide de k3sup (qui fonctionne à merveille). Sur le papier c’est une bonne idée : léger, facile à installer. En revanche il ne permet pas d’instancier un nouvel environnement ; il faut donc jouer avec les namespaces Kubernetes. Rebelote : ce n’est pas un outil adapté à l’apprentissage de Kubernetes. Au départ on fait forcément des erreurs dues à l’incompréhension ou l’ignorance ; ce qui peut rendre l’environnement rapidement inutilisable.

Après ces deux premières tentatives, je sais désormais ce que je veux :

possibilité de créer un environnement « propre »,
encore mieux s’il peut créer plusieurs environnements,
si possible léger (petit) - ce qui exclue les machines virtuelles,
facile à installer,
et rapide.

Nous avons nos critères, il ne reste plus qu’à chercher le(s) outil(s) permettant de créer rapidement un environnement de développement autour de Kubernetes.

Solutions étudiées

À la recherche des mots clés « lightweight » (similaire au mot léger) et « kubernetes » dans un moteur de recherche, on trouve plusieurs outils comme :

MicroK8S,
k0s,
k3s,
et kind.

k3s a déjà été cité dans cet article. Il ne me convient pas pour un environnement de développement/d’étude concernant k8s. Il est sûrement très redoutable à l’installation rapide sur une quantité importante de machines à l’aide de k3sup. Mais ce n’est pas le sujet de cet article.

La liste mentionne également MicroK8S, le petit rejeton de la famille Ubuntu, qui semble être une alternative à Minikube avec des plugins (Dashboard, DNS, registry, istio, etc.). Je pense qu’il est effectivement intéressant pour un usage complet entre des développeurs, une intégration continue (CI) / déploiement continue (CD) et plusieurs environnements allant jusqu’à des environnements dit « de production ». Je sens cependant que la similitude avec Minikube ne puisse me convenir. Je le laisse de côté pour l’instant.

k0s, quant à lui, semble être la solution idéale pour une installation sur une machine physique. À usage privé. Bien qu’il semble léger, facile à installer et utiliser, je comprends rapidement qu’il est fait pour avoir une installation unique sur une machine physique précise. Il ne répond pas à mon critère de création multiple d’environnements.

Et un de plus en moins !

Il reste le dernier de cette liste : kind. A priori il semble léger, prévu pour un usage spécifique au développement ou de l’intégration continue (CI) et utilise Docker pour créer un cluster complet à chaque fois. Waouh, rien que ça ! Sur le papier, cet outil est très prometteur car il répond aux critères précédemment listés :

créer des environnements « propres » grâce à l’usage de Docker,
ainsi il permet l’usage de plusieurs environnements,
il est léger, petit,
facile à installer puisque kind est disponible dans les dépôts AUR d’ArchLinux,
et pour la rapidité nous verrons.

À l’usage, kind (qui veut dire Kubernetes IN Docker) semble facile à prendre en main :

# Créer un cluster nommé olivier
kind create cluster --name olivier
# Supprime le cluster nommé olivier
kind delete cluster --name olivier

Une fois le cluster créé, il s’agit simplement de jouer avec la commande kubectl habituelle pour contacter le cluster. Et la commande étant à taper, je peux tout à fait scripter la création du cluster et sa destruction.

Il serait plus pratique de l’utiliser avec d’autres outils pour en faciliter l’usage. J’ai donc cherché au fur et à mesure de nouveaux outils dont voici la liste :

kubectx va permettre de commuter d’un contexte Kubernetes à un autre. Autrement dit passer d’un cluster à un autre facilement,
kubeconform pour valider nos fichiers YAML,
kube-linter pour pousser à l’usage des bonnes pratiques en matière de rédaction de fichiers YAML,
skaffold pour surveiller la moindre modification (équivalent d’un « watcher ») sur nos fichiers YAML et les déployer directement sur le cluster,
et make (avec un fichier Makefile) pour mélanger tout ça.

Mon idée est d’utiliser un fichier Makefile pour fournir plusieurs commandes permettant de créer le cluster, le détruire, vérifier les fichiers YAML ou encore lancer un déploiement automatique s’il y a des changements dans les fichiers en cours de développement.

J’imagine quelque chose comme :

make cluster pour créer un cluster,
make dev pour lancer skaffold et écouter le moindre changement sur le dossier de développement de l’application,
make kubeconform pour vérifier les fichiers une fois écrits,
make lint pour vérifier les bonnes pratiques avec kube-linter,
et make clean pour détruire le cluster.

Tentons l’aventure et voyons le résultat !

Ce que j’ai finalement produit

En bref

Le fichier Makefile :

CLUSTER_NAME := k8s-dev-example
KUBECTL := kubectl
SKAFFOLD := skaffold
KIND := kind
KUBECONFORM := kubeconform
KUSTOMIZE := kustomize

NAMESPACES := dev

.PHONY: help
help:
	@echo "Commandes disponibles :"
	@echo "  make cluster       - Crée un cluster Kind"
	@echo "  make namespaces    - Crée les namespaces Kubernetes (dev/staging/prod)"
	@echo "  make dev           - Lance Skaffold pour l'env dev"
	@echo "  make kubeconform   - Lance kubeconform sur l'env de DEV"
	@echo "  make clean         - Supprime le cluster Kind"

cluster:
	$(KIND) create cluster --name $(CLUSTER_NAME) ||:

namespaces:
	@for ns in $(NAMESPACES); do \
		$(KUBECTL) get ns $$ns >/dev/null 2>&1 || $(KUBECTL) create ns $$ns; \
	done

dev: cluster namespaces
	$(SKAFFOLD) dev

kubeconform: kubeconform-dev

kubeconform-dev:
	$(KUSTOMIZE) build overlays/dev | $(KUBECONFORM) -strict -summary -ignore-missing-schemas

clean:
	$(KIND) delete cluster --name $(CLUSTER_NAME)

Ce fichier Makefile est disponible sur le dépôt Gitlab d’ODTRE.

Il va utiliser deux dossiers principaux :

base qui contient les fichiers YAML de l’application qu’on souhaite implémenter sur Kubernetes,
overlays/dev qui contient un fichier kustomization.yaml pour surcharger le dossier base.

Et 2 fichiers de configuration :

kube-linter.yaml avec votre configuration de l’outil,
skaffold.yaml avec le contenu suivant :

apiVersion: skaffold/v4beta13
kind: Config
metadata:
  name: k8s-demo-app
manifests:
  kustomize:
    paths:
      - ./overlays/dev
# Exemple de redirection de port sur le service nommé dev-nginx (car l'overlay ajoute dev- devant tout)
portForward:
  - resourceType: service
    resourceName: dev-nginx
    namespace: dev
    port: 80
    localPort: 4000

Cela permet de surveiller le dossier ./overlays/dev avec kustomize pour interpréter les fichiers. Et il va ouvrir le port 4000 sur la machine locale pour rediriger sur le port 80 du service Nginx d’exemple (fourni dans le dépôt Gitlab mentionné précédemment).

À l’usage

Tout n’est pas parfait. Cependant ce fichier Makefile permet de lancer quelques commandes make utiles :

# Lance l'environnement de DEV. Si le cluster n'existe pas : il le créé. Sinon il ignore.
make dev
# Vérifie la conformité des fichiers YAML en utilisant le dossier overlays/dev
make kubeconform
# Détruit le cluster de DEV
make clean
# Pousse à l'usage des bonnes pratiques sur les fichiers contenus dans le dossier ./base
kube-linter lint --config kube-linter.yaml ./base

Pour toute aide supplémentaire, faites : make help.

Ainsi il devient facile de travailler sur un nouvel environnement :

je copie les fichiers disponible sur un dépôt template sur Gitlab,
j’ouvre le fichier Makefile en écriture,
j’édite la ligne suivante pour adapter le nom du cluster de travail :

CLUSTER_NAME := k8s-dev-example

Et le tour est joué !

Je suis assez satisfait de cet environnement. Il répond aux critères édictés plusieurs fois dans cet article. Et je me sens plus à l’aise de pouvoir modifier comme bon me semble cet environnement de développement/travail.

Les outils utilisés me font penser à une boîte à outil de base pour le travail sur Kubernetes. Même sans utiliser le fichier Makefile je suis amené à pratiquer les outils comme kubeconform, kubectl, kube-linter et kustomize.

C’est donc une très bonne chose d’avoir regroupé ces outils autour de Makefile et de les utiliser régulièrement sur mes projets Kubernetes.

Conclusion

Nous avons posé le contexte d’une recherche d’outil simple, rapide et léger pour créer de nombreux environnements Kubernetes afin de travailler sur ces environnements dans le cadre d’un développement de fichiers YAML.

Après quelques essais sur Minikube et k3s, mes recherches se sont portées sur l’utilisation de kind. Puis j’ai utilisé make pour le manipuler et regrouper aussi les différents outils utiles.

La boîte à outil se compose de :

kind,
skaffold,
kubectl,
kubeconform,
kube-linter,
et make.

J’aborde désormais de manière plus sereine le développement d’une application qui sera hébergée par un Kubernetes. J’ai un template à ma disposition pour ces fichiers. Template que je peux faire évoluer au gré des obstacles rencontrés. Il utilise tous les outils que j’ai appréciés. J’en suis pleinement satisfait 😎 .

Et vous, quel environnement Kubernetes utilisez-vous pour vos développements de fichiers YAML ?

Liens utiles

Ce que j'aurais voulu savoir sur Gitlab CI

Sun, 18 May 2025 13:55:39 +0200

Introduction

Il y a quelques mois je parlais de ma formation Bootcamp pour devenir Ingénieur DevOps. J’y ai utilisé - à nouveau - Gitlab CI (Continuous Integration). Vous savez, cet outil permettant d’exécuter des actions après avoir envoyé votre code/dépôt sur la plateforme Gitlab ?

C’est très utile, par exemple pour lancer les tests sur votre code, vérifier que le code s’exécute dans un environnement précis ou tout simplement vérifier que le code compile. Et si votre dépôt n’est pas du code, par exemple un site web, vous pouvez tester les liens morts ; voire publier votre site ! Les possibilités sont - finalement - nombreuses !

En revanche, un tel outil est parfois déstabilisant. Et des cheveux, j’en ai arrachés ! J’aurais apprécié tomber sur un article explicatif. Avec des astuces. Peut-être que le présent article m’aurait convenu, qui sait !

J’aurai par exemple aimé savoir comment publier facilement un site web, tester localement le fichier .gitlab-ci.yml avant de l’envoyer sur Gitlab, connaître plus d’astuces pour les mots clés Gitlab, savoir utiliser Docker dans Gitlab CI et ce que sont les composants réutilisables.

Ce sont ainsi tous les sujets que nous allons aborder aujourd’hui.

Photo trouvée sur le profil de didier.camus sur Flickr sous Licence Œuvre du domaine public.

Publier rapidement un site statique

Gitlab met à disposition des utilisateurs un espace permettant d’héberger des sites webs statiques. Incroyable n’est-ce pas ? Cet espace est Gitlab Pages.

Comment cela fonctionne ? Il suffit de créer un dépôt Gitlab, d’ajouter un fichier .gitlab-ci.yml contenant la section suivante :

image: busybox

pages:
  stage: deploy
  script:
    - echo "The site will be deployed to $CI_PAGES_URL"
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Code récupéré du projet https://gitlab.com/pages/plain-html.

Cela signifie qu’au terme de la CI/CD (dans l’étape nommée deploy), le contenu du dossier public sera publié sur Gitlab Pages. À quelle adresse ? Imaginons que vous partez d’un dépôt dont l’adresse est : https://gitlab.com/blankoworld/monprojet/, l’adresse URL d’accès à votre site publié sera : https://blankoworld.gitlab.io/monprojet/. Pratique non ?

Astuce : Si votre dépôt est privé, vous pouvez quand même rendre votre site public. Il suffit d’aller dans Settings > General, Section « Visibility, project features, permissions » et dans le sous-titre « Pages », activez la fonctionnalité. Et dans le menu déroulant à côté, choisissez « Everyone ». N’oubliez pas de sauvegarder cette configuration. Le code sera privé, le site web statique public !

Pour plus d’exemple, veuillez vous rendre sur la page Gitlab présentant la liste de projets utilisant Gitlab Pages.

Tester avant d’envoyer sur le dépôt ?

Le truc vraiment embêtant avec les fichiers .gitlab-ci.yml, c’est qu’on ne peut pas les tester sur notre machine (localement). Pour avancer il faut :

modifier le fichier .gitlab-ci.yml,
le valider (faire un commit),
l’envoyer sur Gitlab,
patienter que la pipeline se lance (et parfois se termine),
bénéficier du résultat ou, dans la plupart des cas, recommencer à l’étape 1…

À une époque on pouvait utiliser une commande gitlab-runner exec en local. Mais celle-ci a été supprimée : https://gitlab.com/gitlab-org/gitlab-runner/-/commit/f8508c924f80b104ec7353353e6ad0edb5daae66 .

Suivant ce que nous faisons dans la CI/CD de Gitlab, il est possible d’utiliser un outil bien pratique nommé gitlab-ci-local : gitlab-ci-local.

Vous trouverez quelques détails de gitlab-ci-local sur mon recueil d’astuces.

Généralités

Voici quelques pistes intéressantes sur le sujet Gitlab :

Une documentation de départ est : https://docs.gitlab.com/topics/build_your_application/. Elle permet d’en savoir plus sur la syntaxe de gitlab-ci.yaml, les variables pré-définies ou encore le fonctionnement d’un pipeline dans Gitlab CI,
Toujours utiles : les actions que je nomme comme « globales ». Par exemple les mots clés image, variables ou before_script peuvent être utilisés en début du fichier pour définir des actions ou des valeurs qui seront utilisées dans toutes les étapes du pipeline. Ce qui peut être un avantage, ou un inconvénient. Exemple : image: ubuntu:latest va définir que toutes les étapes se lanceront dans un docker partant de l’image Ubuntu,
Entrées/sorties : un artefact = une sortie. C’est à dire des fichiers utilisables/disponibles pour les étapes suivantes (donc en entrée pour les autres étapes) en utilisant le mot clé dependencies (Cf. https://docs.gitlab.com/ci/jobs/job_artifacts/#fetching-artifacts). Sauf si dependencies = [] est utilisé.
Utiliser des variables globales en début du fichier (par exemple pour les numéros de versions) fait gagner du temps sur le long terme. Exemple :

variables:
  DOCKER_VERSION: "27.3.1"
  UBUNTU_VERSION: "24.04"

Concernant le mot clé script :
- si on veut écrire plusieurs lignes, utiliser la syntaxe suivante :
```
script:
  - echo "première étape des scripts"
  - |
    echo "première ligne"
    echo "seconde ligne"
    echo "etc."
```
- limiter à 10 lignes maximum,
- si on utilise la syntaxe pour écrire plusieurs lignes, le debug est plus difficile
Pour organiser les étapes, on peut donner à chacune d’elle une étape pré-requise en utilisant le mot clé « needs », cela permet de chaîner les étapes dans un certain ordre. Exemple : si on veut que l’étape « deploy » se fasse après « compile », alors à la fin de l’étape « deploy » on met needs: [compile].

Le Cas Docker

Création d’une image Docker… dans un conteneur Docker

Dans la situation où vous voudriez fabriquer des images Docker, vous allez être confrontés à plusieurs problématiques :

il faut utiliser des commandes docker pour créer des images,
mais la plupart des Gitlab Runner exécutent les étapes de Gitlab CI dans un Docker,
donc on se retrouve à vouloir exécuter des commandes docker dans un environnement Docker.

Vous voyez le problème ?

Pour contourner cette situation il suffit d’utiliser Docker-in-Docker.

En somme le début du fichier .gitlab-ci.yml ressemblera à :

variables:
  DOCKER_VERSION: "27.4.1"

image: docker:$DOCKER_VERSION

services:
  - docker:$DOCKER_VERSION-dind

S’identifier

Pour utiliser les dépôts de conteneurs de Gitlab, rien de plus simple il suffit d’écrire le code suivant dans le fichier .gitlab-ci.yml :

before_script:
  - docker info
  - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin

Nul besoin de renseigner les variables. Elles sont renseignées par Gitlab CI.

Construire l’image

Pour construire l’image cela va ressembler à :

variables:
  CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

build-image:
  stage: build
  script:
    - docker pull "$CONTAINER_TEST_IMAGE" || true
    - docker build --build-arg BUILDKIT_INLINE_CACHE=1 -t $CONTAINER_TEST_IMAGE .
    - docker push $CONTAINER_TEST_IMAGE

On part du principe que le fichier Dockerfile est situé à la racine de votre projet Gitlab.

CONTAINER_TEST_IMAGE est une variable globale construite à partir des variables pré-définies de Gitlab CI.

Pousser l’image sur le dépôt

Dans cette situation nous sommes contents d’avoir déjà ajouté l’authentification aux dépôts de conteneurs Gitlab.

Cette fois on fait une étape pour récupérer l’image précédente et lui donner un nouveau nom :

push-image:
  stage: push
  script:
    - export IMAGE_TAG="$(date +'%Y%m%d')-${CI_COMMIT_SHORT_SHA}"
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CI_REGISTRY_IMAGE:$IMAGE_TAG
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

L’idée est :

de créer un nom de tag pour l’image (variable IMAGE_TAG),
récupérer l’image précédente - puisque les étapes d’un fichier .gitlab-ci.yml s’exécutent dans des conteneurs isolés les uns des autres,
apposer un nouveau tag sur l’image récupérée,
publier le résultat en poussant l’image ainsi étiquetée.

Ceci ne s’exécute que si la branche est nommée main. Donc chaque commit sur cette branche générera une image Docker et un tag.

Ordre d’exécution des étapes

Afin que les deux étapes précédentes s’exécutent dans un certain ordre, ne pas oublier les lignes suivantes dans le fichier .gitlab-ci.yml :

stages:
  - build
  - push

Comme si ça ne suffisait pas…

En outre, voici d’autres éléments à rajouter dans son fichier .gitlab-ci.yml :

variables:
  # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
  DOCKER_HOST: tcp://docker:2376
  DOCKER_TLS_CERTDIR: "/certs"

Ces lignes permettent de renseigner un autre accès à l’API Docker pour lancer les commandes docker.

Les composants réutilisables

Gitlab CI offre la possibilité d’utiliser des composants réutilisables pour agrémenter les étapes de son fichier .gitlab-ci.yml. Ceci évite de réinventer la roue (en codant soi-même).

Plusieurs composants sont disponibles sur la page Gitlab components.

Exemple d’utilisation d’un composant :

include:
  - component: gitlab.com/components/container-scanning/container-scanning@5.1.0

C’est très utile dans certaines situations comme pour tester des fichiers Terraform (avec le composant OpenTofu), le composant Go, le composant Rust ou même utiliser les fonctionnalités Autodevops de Gitlab.

Conclusion

Au premier abord Gitlab CI paraît complexe et maigre en fonctionnalités. Cependant la lecture de la documentation (très fournie !) donne rapidement un aperçu bien plus avantageux de cet outil. On y découvre les composants réutilisables, les mots clés image, variables, before_script, les artefacts (sorties), les variables globales, le déploiement de sites statiques et j’en passe !

Certaines difficultés telles que Docker viennent s’immiscer dans nos essais. Mais une fois les obstacles franchis c’est un outil très satisfaisant. Je l’apprécie.

Je serais ravi de tomber plus souvent sur des articles décrivant ses fonctionnalités. J’espère participer à une diffusion plus grande de la connaissance Gitlab CI et, qui sait, peut-être partagerais-je prochainement d’autres astuces ?

Cookiecutter-trognon pour initialiser mes scripts Bash

Sun, 28 Apr 2024 13:20:47 +0200

Introduction

Pour la petite histoire, l’année dernière je lisais l’article de deblan sur la création d’un modèle de script Shell sur le journalduhacker. Cela m’a rappelé que tôt ou tard dans la quête de l’automatisation on arrive toujours à faire nos propres modèles de scripts.

La plupart de mes projets utilisent le modèle de script Trognon.

Comment, en partant de ce modèle, pourrais-je automatiser la création de nouvelles commandes ? C’est là qu’entre en jeu cookiecutter, une commande et une méthode permettant de transformer n’importe lequel de vos projet en template pour les suivants !

Nous commencerons par voir le résultat de l’adaptation d’un script avec cookiecutter. Ensuite nous verrons ce qu’est cookiecutter. Finalement nous expliquerons comment adapter son projet avec cookiecutter en présentant le cas pratique de cookiecutter-trognon.

Photo trouvée sur le profil de Alan Levine sur Flickr sous Domaine public.

Le résultat : cookiecutter-trognon

Pour une fois nous commencerons par la fin, c’est à dire le résultat ! L’automatisation de Trognon a donné un dépôt : cookiecutter-trognon.

Grâce à lui, créer un nouveau script Bash suivant le modèle de Trognon revient à taper les commandes suivantes :

# Installe cookiecutter sur notre machine (à ne faire que la première fois)
pipx install cookiecutter
# Utilise mon dépôt Github de cookiecutter-trognon comme modèle
cookiecutter gh:blankoworld/cookiecutter-trognon

Ensuite 2 questions sont posées pour définir :

le nom du dossier dans lequel ma commande se trouvera
le nom souhaité pour la commande

Évidemment j’ai défini les questions à poser et ce que je faisais des réponses dans le résultat. C’est là tout l’intérêt de cookiecutter : vous définissez les questions à poser, les réponses possibles s’il en est, quoi faire des réponses et où les utiliser dans vos templates.

Voyons donc cookiecutter.

Présentation de cookiecutter

cookiecutter est un outil Python qui duplique un répertoire, vous pose des questions et modifie le duplicat en remplaçant certaines chaînes de caractères par les réponses données aux questions.

Il sait agir de manière conditionnelle : c’est-à-dire qu’il peut aussi ajouter/enlever des pans de code/texte en fonction de la valeur d’une variable. Ceci grâce au moteur de template Jinja.

Autrement dit : vous définissez les fichiers dont vous avez besoin (parfois un copier/coller suffit), puis vous insérez dans vos fichiers des chaînes de caractères que vous souhaitez remplacer dans le projet. Vous pouvez également définir des valeurs conditionnelles. Par exemple : si je souhaite avoir une licence MIT, alors le fichier LICENSE contiendra un certain texte. Si je choisis la licence LPRÀB/WTFPL, alors j’aurais un autre texte.

Un exemple concret serait plus parlant, essayons avec cookiecutter-trognon !

Comment transformer Trognon en cookiecutter-trognon ?

En rapide

Pour rendre un projet compatible avec cookiecutter, il va falloir suivre quelques étapes clés :

Créer un nouveau répertoire pour votre projet,
Y créer un fichier nommé cookiecutter.json,
Créer un répertoire nommé {{ cookiecutter.project_slug }} (oui oui, AVEC les accolades),
Déposer les fichiers nécessaires au projet dans le répertoire {{ cookiecutter.project_slug }},
Remplacer dans les fichiers tous les mots à adapter à chaque nouveau projet : pour cela utiliser les mots clés fournis dans le fichier cookiecutter.json (variables).

Dans le cas de Trognon, j’ai déposé les fichiers du projet dans le répertoire {{ cookiecutter.project_slug }}.

cookiecutter.json, la configuration du projet

J’ai ensuite rempli le fichier cookiecutter.json tel que montré ici :

{
  "project_name": "Mon projet",
  "__project_slug": "{{ cookiecutter.project_name.lower().replace(' ', '_').replace('-', '_') }}",
  "command_shortname": "CommandePrincipale",
  "__command_slug": "{{ cookiecutter.command_shortname.lower().replace(' ', '_').replace('-', '_') }}",
  "__prompts__": {
    "project_name": "Choisissez un nom de projet court",
    "command_shortname": "Que voudriez-vous comme nom court de commande ?"
  }
}

Je défini des variables comme :

project_name : le nom du projet, avec comme valeur par défaut Mon projet,
command_shortname : le nom de la commande Bash que nous utiliserons.

D’autres variables ne demanderont rien à l’utilisateur car elles commencent par deux espaces soulignes __. Je parle bien entendu de __project_slug, __command_slug et __prompts__.

Cependant __prompts__ a une particularité : il permet de personnaliser la question posée pour chaque variable.

Ainsi pour définir project_name, l’utilisateur verra la question suivante : Choisissez un nom de projet court.

Remplacer des mots par des variables

Maintenant que le fichier cookiecutter.json possède des mots clés spécifiques (des variables), nous allons pouvoir modifier les fichiers de notre projet pour contenir des « mots-clés ». Par exemple voici le début du fichier README.md de Trognon (AVANT modifications) :

# Trognon

Un lanceur de commandes personnalisées pour votre projet de développement.

Exemple : 

# Affiche l'aide
./agnes help

# Installe votre projet (vous devez définir ce que `install` fait)
./agnes install

# créé un dump de la base de données
./agnes dump

Ce qui donne le fichier README.md suivant dans notre projet cookiecutter-trognon (APRÈS modifications) :

# {{ cookiecutter.project_name }}

Un lanceur de commandes personnalisées pour votre projet de développement.

Exemple : 

# Affiche l'aide
./{{ cookiecutter.__command_slug }} help

# Installe votre projet (vous devez définir ce que `install` fait)
./{{ cookiecutter.__command_slug }} install

# créé un dump de la base de données
./{{ cookiecutter.__command_slug }} dump

Nous avons ainsi remplacé respectivement le titre du fichier et les commandes d’exemple en {{ cookiecutter.project_name }} et {{ cookiecutter.__command_slug }}.

Vous pouvez en savoir plus sur la documentation officielle de cookiecutter.

Conclusion

J’espère qu’à travers cet article vous aurez compris l’avantage d’utiliser cookiecutter et que vous envisagerez à l’avenir de l’intégrer dans votre processus d’automatisation de la génération initiale de vos projets et de vos scripts.

L’informatique énonce souvent d’éviter de réinventer la roue ; je pense que cookiecutter est l’outil indispensable pour favoriser ce concept.

Une fois ce processus de création automatisé, vous vous rendrez compte que vous générerez plus souvent des scripts/projets, que vous vous concentrerez uniquement sur le contenu du projet et pas sur tout l’environnement autour : c’est un gain de temps et de qualité ! Une belle valeur ajoutée en somme.

La Genèse d'un projet

Wed, 13 Sep 2023 12:13:23 +0200

Il y a quelques temps je lançais un billet sur le projet Gachette qui permet de publier mon blog. Dans la même lancée je souhaite aujourd’hui vous présenter un autre projet sur lequel je travaille de temps en temps : Genèse. Genèse est assez difficile à définir. Cependant je l’imagine comme une commande unique pour permettre à plusieurs développeurs de travailler sur un environnement commun et en lançant une instance par ticket/problème relevé.

Cet outil, bien qu’il soit utile et facile à utiliser, demande un minimum d’explication pour comprendre à la fois le concept et l’utilité réelle.
C’est pourquoi je vais avant tout poser la problématique principale qui a initiée le projet, puis montrer quelques usages intéressants qui sont plus parlants et finalement tenter d’expliquer son fonctionnement en interne.

Photo trouvée sur le profil de Damian Gadal sur Flickr sous licence CC BY 2.0.

Ce qui a initié le projet

De nombreuses années d’expérience professionnelle dans le domaine informatique m’ont amené à rencontrer plusieurs problèmes et à réfléchir sur énormément de sujets.

L’un d’eux se porte sur l’environnement de travail : je parle de l’environnement système utilisé pour travailler sur un projet. J’ai relevé quelques éléments intéressants, similaires à des postulats :

on essaie souvent de se rapprocher de l’environnement système de la production : ceci pour repérer assez tôt d’éventuels problèmes
plus l’environnement entre collègues est similaire, mieux nous travaillons : si un collaborateur rencontre un problème il peut se tourner vers le reste de l’équipe pour avoir de l’aide
nous en arrivons souvent à faire un fichier docker-compose.yml pour cela : peut-être est-ce initialement plus facile de partager un fichier léger (docker-compose.yml) qu’une machine virtuelle entière ?
quand on nouveau collaborateur arrive dans l’équipe, il a pas mal de choses à apprendre sur le projet. Et il peine souvent - en plus de toutes les choses à apprendre - à devoir installer l’environnement initial
on utilise souvent un fichier docker-compose.yml très proche entre plusieurs projets : ce qui est normal puisqu’on utilise très souvent des technologies similaires qu’on maîtrise pour les vendre à nos clients
on travaille souvent sur plusieurs tickets, c’est à dire plusieurs problèmes émis par le client. Chaque fois que nous démarrons un nouveau ticket, dans l’idéal, nous devrions avoir un environnement sain et propre pour ne pas avoir de fioritures de nos travaux précédents

En discutant avec Richard Dern (qui a d’ailleurs fait une refonte de son site web avec un nouveau moteur de blog), nous avons réfléchi à un outil capable de résoudre plusieurs de ces problématiques. Le fil rouge était :

les environnements doivent rester isolés : utilisation d’un fichier docker-compose.yml pour générer un environnement
création d’un répertoire unique pour chaque nouveau ticket/projet/autre afin de garder quelque chose de sain et propre
éviter de devoir se répéter entre plusieurs projets : mettre en commun les éléments qui le peuvent, comme par exemple le type de base de données
permettre à plusieurs utilisateurs de travailler sur la même machine : nommage des environnements d’une manière particulière (avec le nom de l’utilisateur par exemple)
permettre à chaque développeur de personnaliser son environnement : par exemple s’il souhaite avoir une interface web pour la base de données, qu’il puisse rajouter l’outil qu’il souhaite
si nous travaillons sur 2 tickets d’un même projet, sachant que l’environnement est similaire pour un même projet, ces deux environnements doivent pouvoir exister en même temps : s’ils utilisent les mêmes ports d’adresses, cela va échouer. Il faut donc des ports aléatoires.
si les ports sont aléatoires, alors il faut un accès facile à chacun des environnements, par exemple à l’aide d’une interface Web commune à tous ces environnements

C’est assez difficile à se l’imaginer sans des explications, une démonstration et/ou quelqu’un qui nous guide pour nous montrer le fonctionnement, alors je vais vous présenter un cas d’usage.

Usage et exemple de Genèse

Imaginons un cas d’usage typique : un client détient une application web (faite avec un framework) qui utilise une base de données MySQL. Appelons cette application : memory_game.

Il est très probable que nous ayons d’autres clients qui utilisent MySQL. Et il est très probable que notre client fera des tickets de bugs que nous aurons à résoudre. Nous aurons probablement plusieurs collaborateurs (pour lesquels nous allons répartir les tickets).

Il utilise un fichier docker-compose.yml avec le contenu suivant :

version: '3'

services:
  php:
    image: toasterlint/php-apache-mysql
    ports:
      - "8888:80"
    volumes:
      - ./:/var/www/html

  db:
    image: mysql
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: mot2passe
      MYSQL_DATABASE: maBdd
    volumes:
      - ./base_de_donnees:/docker-entrypoint-initdb.d

On comprend donc qu’il y a :

un service (nommé db) pour une base de données MySQL,
un service (nommé php) pour l’application écrite en PHP sur le port 8888.

Avec Genèse, générer un nouvel environnement de développement reviendrait à faire :

# Génère un docker-compose.yml dans le dossier instances/memory_game à partir du profil nommé memory_game
./genese -p memory_game

instances/memory_game est un répertoire de travail :

avec le dépôt de version du projet memory_game,
un fichier docker-compose.yml prévu pour lancer un environnement complet,
et un fichier .env contenant des variables permettant au projet d’être autonome.

Si l’exécutable ./genese venait à disparaître, le dossier reste fonctionnel pour travailler (avec Docker Compose évidemment).

Si on travaille sur plusieurs problèmes en parallèle, on peut vouloir créer un dossier par problème. Imaginons le ticket 42 et le ticket 16 :

# Génère une instance du projet dans le dossier instances/ticket42
./genese -p memory_game -n ticket42
# Même chose avec le dossier instances/ticket16
./genese -p memory_game -n ticket16

Il faut récupérer une branche spéciale du service memory_game ?

# Récupère dans le dépôt Git fourni dans le service memory_game la branche maBrancheSpeciale
BRANCHE_MEMORY_GAME="maBrancheSpeciale" ./genese -p memory_game -n essaiautrebranche

Vous découvrirez dans un prochain article à quel usage je réserve cela 😉

Quelles sont les instances dont je dispose ?

# Liste l'ensemble des instances
./genese -i

Et j’obtiens une liste des dossiers ayant été créés.

Si je veux supprimer une instance spécifique :

# Supprimer l'instance ticket16
./genese -s ticket16

Et si on veut avoir une visualisation des instances lancées, d’accéder à leur détail, éteindre un conteneur, le rallumer, regarder les fichiers de journalisation (logs) ou encore entrer dans un conteneur avec une invite de commande, on peut utiliser l’interface Web Portainer fournie avec Genèse. Cela ressemble à quelque chose comme :

Seriez-vous curieux de savoir comment cela fonctionne (sans entrer dans le technique évidemment !) ?

Comment ça marche ?

Nous allons voir que Genèse s’appuie sur quelques éléments clés comme :

l’instance : version autonome et isolée, située dans le dossier instance,
le service : la description nécessaire pour générer un service, par exemple MySQL,
le profil : contient une liste de services permettant de démarrer une instance.

Prenons l’exemple précédent, nous aurons :

deux services :
- l’un nommé mysql pour la base de données,
- l’autre nommé memory_game pour notre application,
un profil nommé memory_game qui liste les services mysql et memory_game.

Chaque fois que nous lancerons la commande ./genese avec le profil memory_game nous aurons la possibilité de générer une instance avec un nom spécifique.

Comment cela peut-il fonctionner ? Les services ont une structure permettant de décrire :

la partie du fichier docker-compose.yml qui va être utilisée,
la possibilité de donner le dépôt Git utilisé pour récupérer les sources du projet et la branche par défaut à récupérer,
la possibilité de donner un dossier extras permettant de surcharger les sources du projet récupéré (par exemple pour mettre des fichiers de configuration),
la possibilité d’agir à des moments clés de la génération de l’instance via des déclencheurs qui sont des scripts pour :
- procéder à des changements AVANT le lancement des conteneurs Docker, par exemple modifier des fichiers de configuration,
- agir APRÈS le lancement des conteneurs, par exemple pour lancer des commandes dans les conteneurs Docker lancés,
- afficher des informations à la fin du processus de création de l’instance, par exemple pour afficher les ports utilisés par les différents conteneurs

À cela s’ajoute une interface Web (Portainer) permettant de contrôler les instances lancées et accéder à des fonctionnalités particulières de Docker.

La documentation de Genèse devrait se charger bien mieux que moi pour les détails techniques et les possibilités de cet outil.

Conclusion

Malgré l’exemple d’utilisation et quelques détails sur son fonctionnement, Genèse mérite qu’on s’y attarde : nous n’avons gratté que la surface.

Cela ressemble à un framework pour des profils de personnes de type devops afin de leur fournir un outil unique ; à la fois déployer des instances pour les développeurs ; et des instances de type test pour les personnes fonctionnelles.

Je ne sais pas comment suggérer de passer un peu de temps sur l’outil pour comprendre que c’est un bon investissement de temps. Surtout pour des personnes d’un profil DevOps et qui connaissent le scripting Bash. J’espère que la curiosité vous piquera au vif !

Nous nous retrouverons très probablement pour en reparler dans un cadre différent encore.

La Gachette qui publie mon blog

Fri, 20 Jan 2023 17:46:32 +0200

Introduction

Peut-être serez-vous surpris d’apprendre que la publication d’un article sur ce blog revient simplement à écrire du texte dans un fichier et envoyer un commit sur un dépôt Git. Ni plus, ni moins.

C’est là que commence toute une chaîne de publication afin de mettre à disposition le fameux article sur le Web ! Pour cela j’ai utilisé très peu d’outils et un peu d’imagination.

Le but du présent article est de vous présenter l’outil de la chaîne que j’ai dû développer pour mener à bien ce projet : Gachette. Puis de vous décrire comment le mettre en place.

Mais avant tout commençons à planter le décor !

Photo trouvée sur le profil de Nikk sur Flickr sous licence CC BY 2.0.

Plantons le décor avec l’Histoire logicielle de ce blog

(je comprendrais que ce chapitre ne soit pas très enthousiasmant pour vous, si c’est le cas, passez au suivant 😉)

En 2016 je vous parlais d’Hugo, le moteur de blog statique que j’utilise pour « confectionner » ce blog. Outil très intéressant qui utilise de simples fichiers pour générer un site web entier, statique ; c’est à dire en pur HTML et ne demandant aucune autre ressource finale qu’un serveur Web tel qu’Apache2, nginx, lighttpd, Caddy Server et j’en passe… Dans ma situation, le serveur Web en question est Nginx depuis 2013 environ - mais qu’importe.

Afin de garder en mémoire les travaux effectués, je vous partageais en 2017 l’outil Gitea, service Git sans prise de tête issu de Gogs.

À cette époque (entre 2016 et 2019/2020), pour publier mon blog il me faut :

(manuel) écrire l’article dans un fichier texte
(manuel) (facultatif) l’enregistrer sous Git avec un commit
(manuel) (facultatif) envoyer l’article sur Gitea
(manuel) compiler le site à l’aide de la commande hugo
(manuel) synchroniser les fichiers résultants sur mon serveur doté de Nginx, par exemple avec une commande rsync simple

À force de traîner à FOSDEM en 2016 et en 2017, j’ai non seulement appris que l’informatique sert à automatiser des tâches mais qu’il est aussi possible de le faire de manière « simple ».

Je me renseigne et j’apprends que sous Gitlab, Github et Gitea (plateformes que j’utilise à l’époque), il existe un système de webhooks. Qu’est-ce à dire ? Grossomodo je peux configurer ces plateformes pour qu’à chaque envoi de mon travail peut résulter un appel à une adresse Web.

Il suffit ensuite, à l’adresse appelée, de pouvoir étudier la requête envoyée et d’agir en conséquence (par exemple déployer un site).

Sur le papier ça a l’air fun :

(manuel) j’écris mon article dans un fichier texte
(manuel) je commite et pousse sur Gitea/Github/Gitlab
(automatique) la plateforme de réception envoie un appel à un de mes serveurs
(automatique) un de mes serveurs reçevant l’appel lance un script ou une action pour publier les dernières nouveautés

Parfait on se lance là dedans !

La naissance de Gachette

En 2019 où j’étudiais la question, je ne trouvais pas de serveur simple et léger qui puisse supporter les appels envoyés par Github, Gitlab et Gitea. Hors de question d’avoir 3 serveurs de webhooks différents sur mes machines.

Comme j’ai cru comprendre être ingénieur logiciel au travail 🤣, je me suis dit pouvoir l’être aussi à la maison sur mon temps personnel. À l’époque je m’amusais un peu avec le langage Crystal avec des amis, c’était l’occasion.

C’est ainsi qu’est né Gachette, un serveur de webhooks sous Licence MIT en Crystal (une syntaxe comme Ruby, mais compilé) qui supporte les plateformes Github, Gitlab et Gitea.

Sous ce langage, il existe quelques frameworks, dont Kemal, un framework web minimaliste qui permet d’ouvrir quelques routes très facilement. C’est ce que j’ai utilisé pour créer la première version 0.1 de Gachette en 2019.

À tout casser on doit être à 100 lignes de code. Bref. À aujourd’hui, plutôt 200+ lignes de code Crystal.

Voyons les particularités de mise en place de Gachette.

Mise en place de Gachette sur un serveur

Je ne vais pas reproduire ce que le fichier README de Gachette énonce si bien pour l’installation, cependant je peux vous faire un résumé rapide de l’installation/configuration :

# On récupère le projet
git clone https://github.com/blankoworld/gachette.git
cd gachette
# Pré-requis : Crystal, Shards et make doivent être installés
shards install
# On compile le logiciel
make

À l’issue de ces commandes devrait apparaître un fichier bin/gachette qui est un exécutable utilisable tel quel.

On le place où on veut, par exemple dans /srv/www/gachette/gachette puis on édite le fichier /etc/systemd/system/gachette.service dont le contenu est le suivant :

[Unit]
Description=Gachette webhooks service
After=network.target

[Service]
Type=simple
User=http
WorkingDirectory=/srv/www/gachette
ExecStart=/srv/www/gachette/gachette -c /etc/gachette.ini -b 0.0.0.0 -p 3000
Environment="KEMAL_ENV=production"
Restart=always

[Install]
WantedBy=multi-user.target

À noter qu’il faut adapter User=http par l’utilisateur de votre système d’exploitation, par exemple sous Debian c’est User=www-data. Mais également le port utilisé, ici c’est le port 3000.

Ensuite créez le fichier /etc/gachette.ini avec un contenu qui va décrire les dépôts/projets qui vont contacter le serveur webhooks et déclencher une action. Imaginons que le projet Gachette, sur Github, à l’adresse https://github.com/blankoworld/gachette veuille qu’à chaque commit nous exécutions le contenu du script /srv/www/gachette/deploiement.sh, nous allons écrire :

# contenu du fichier /etc/gachette.ini
[Un_nom_au_hasard]
service = github
namespace = blankoworld/gachette
key = monMot2Passe
scriptfile = /srv/www/gachette/deploiement.sh

Une fois la configuration faite, le service installé, vous pouvez faire en tant qu’utilisateur root :

# pour lancer le service
systemctl start gachette.service
# pour voir l'état du service
systemctl status gachette.service
# pour lancer le service à chaque redémarrage : 
systemctl enable gachette.service
# pour suivre ce qu'il se passe dans Gachette : 
journalctl -xe -f -u gachette.service

Tout résidera ensuite dans votre capacité à créer des scripts qui feront le travail de déploiement.

Dans ma situation, pour le présent blog, j’ai un script qui :

récupère la dernière version du dépôt Git du blog
compile le site pour générer les fichiers statiques
synchronise le résultat - si réussi - vers un dossier particulier
relance le serveur Web avec les nouveaux fichiers

Suite à mon dernier article sur Træfik pour publier ses conteneurs Docker, je me suis même essayé à l’utilisation de conteneurs Docker pour isoler les environnements, voire même à avoir des images Docker communes pour l’ensemble des sites Web statiques : très pratique !

On s’amuse bien par ici en somme 😉.

Conclusion

Bien que certains jugerons ma chaîne de publication assez alambiquée, utilisant des outils peu communs, voire pas du tout utilisés (Gachette notamment), ce système a déjà fait ses preuves et tourne bien : moins d’une minute après avoir enregistré un article, il est publié sur le web sans action humaine.

Il n’y a pour cela que 3 outils simples :

Gitea comme dépôt Git ; qui déclenche une demande auprès d’un serveur distant (ici Gachette)
Gachette qui reçoit la demande et lance un script de compilation/déploiement/traitement (bref, une action est menée)
Nginx comme serveur Web pour diffuser les pages statiques ainsi générées

L’utilisation de Docker en sus améliore le côté réutilisable des outils : pour plusieurs sites statiques j’utilise la même image qui va compiler les fichiers puis les mettre à disposition sur le net.

La difficulté réside cependant à notre capacité à créer des scripts pour lancer les différentes actions sur le serveur. La ligne de commande et Bash sont de fidèles alliés !

Liens utiles

Utilisation de træfik pour publier ses conteneurs Docker

Wed, 07 Dec 2022 07:16:11 +0100

Introduction

Il y a 8 ans je vous faisais découvrir Docker. À l’époque je ne savais pas encore à quel point cet outil très controversé serait utilisé !

Docker est quasiment devenu un standard. Qu’on le veuille ou non il arrive souvent qu’on ait un conteneur Docker à lancer. On finit toujours par devoir lire la documentation de Docker.

Avant de continuer sur la problématique du présent article, je tiens à vous signaler qu’il est important de savoir un minimum jouer avec les fichiers docker-compose.yml. Cas échéant je crains que cet article ne vous soit d’aucune autre utilité que nourrir votre curiosité.

Ainsi, un problème qui survient fréquemment quand on a crée nos images, nos conteneurs puis que nous lançons ces derniers : comment publier nos conteneurs afin qu’ils soient disponibles sur Internet ? En général la solution est d’utiliser un proxy (par exemple Nginx) qui va étudier les requêtes HTTP demandées sur le serveur puis rediriger vers le port choisi d’un conteneur Docker qu’on a lancé.

Dans cet article je vais rapidement expliquer pourquoi le choix de Træfik plutôt que Nginx que j’utilisais avant ça. Ensuite j’expliquerai les configurations utilisées pour mettre à disposition nos conteneurs. Nous aborderons rapidement quelques points pour aller plus loin et finirons par une conclusion.

Choix du proxy

Habituellement, pour mettre en place l’accès à des sites web que j’héberge, j’utilisais Apache, Nginx ou encore Caddy.

Cependant il y avait pas mal de contraintes :

chaque nouveau domaine demandait une configuration spécifique avec un fichier spécifique, des dossiers spécifiques,
pour avoir un certificat SSL par Let’s Encrypt, il fallait parfois user d’intelligence, même une fois qu’on utilise Certbot, notamment pour redémarrer le serveur Web une fois les certificats renouvelés,
quand on lançait un conteneur Docker, il valait mieux choisir un port spécifique, par exemple 8081, puis recopier ce nombre en dur dans la configuration du serveur Web (Nginx dans mon cas) et je ne suis pas le plus imaginatif pour les numéros de ports qui se cumulaient…

Ce qui est assez pénible. Très consommateur de temps.

Étant donné que nous utilisons déjà les possibilités de Docker et Docker Compose, autant continuer en utilisant un outil ayant un backend avec Docker, non ?

C’est là que Træfik entre en jeu :

il permet avec quelques lignes dans vos fichiers docker-compose.yml de définir le domaine à utiliser pour tel ou tel conteneur Docker
il s’occupe de faire la demande de certificat Let’s Encrypt et le renouvellement de ces derniers
le lancement d’un conteneur Docker ne demande pas de relancer Træfik, il y a une détection automatique des configurations
on laisse les ports choisis par Docker pour nos conteneurs, ce qui nous évite d’en faire une gestion
étant codé en Go (tout comme Docker et Docker Compose), Træfik fait partie du même monde, il est donc aussi rapide et compatible avec les outils utilisés
pas besoin d’installer Træfik : il sera un conteneur Docker comme le reste des services de la machine 😃

Au final ce sont les contraintes des serveurs Web dont j’ai eu l’usage qui m’ont convaincu d’essayer Træfik. Voyons donc à quoi cela ressemble !

ATTENTION : Træfik ne résoud pas tous les problèmes du monde. Il va falloir expérimenter, recommencer plusieurs fois, plier son cerveau pour saisir de quoi il retourne. Parfois demander de l’aide. C’est un processus d’apprentissage qui en vaut la peine cependant !

Configuration de træfik

Pour mettre en place Træfik nous allons procéder comme la documentation de Træfik Proxy le propose :

faire un docker-compose.yml pour décrire notre service Træfik
utiliser un fichier de configuration externe pour configurer le service : le fichier traefik.yml
demander à exposer les ports 80 et 443

Pour cela, voici le fichier docker-compose.yml pour lancer le service Træfik :

version: '3'

services:
    proxy:
      image: traefik:v2.8
      restart: always
      ports:
      	- 80:80
        - 443:443
      volumes:
        # pour que Træfik écoute les événements Docker : à adapter chez vous
        - /var/run/docker.sock:/var/run/docker.sock
        # Utilisation d'un fichier de configuration
        - ${PWD}/traefik.yml:/etc/traefik/traefik.yml
        # Mémorisation des certificats TLS (par Let's Encrypt)
        - ${PWD}/acme.json:/acme.json
      labels:
        # Activation du tls
        - "traefik.http.routers.api.tls"
        # nawak, pour que les logs la boucle sur service error: port is missing
        - "traefik.http.services.nawak.loadbalancer.server.port=8484"

Ce qui va monter le fichier local /var/run/docker.sock pour discuter avec Docker : adaptez-le au fichier Socket de votre service Docker.

Cela va utiliser le fichier traefik.yml local qui contient notre configuration pour notre service Træfik.

On stocke les données des certificats dans le fichier local acme.json : pensez à faire touch acme.json pour créer le fichier avant de lancer.

Et voici le contenu de notre fichier traefik.yml :

api:
  dashboard: true # pour activer un tableau de bord

providers:
  docker:
    network: traefik # réseau de discussion entre les conteneurs et traefik
    exposedByDefault: false # n'active pas les conteneurs par défaut sur le web

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure # pointe sur websecure plus bas (port 443 en somme)
          scheme: https

  websecure:
    address: ":443"
    http:
      tls: # configuration par défaut
        certResolver: letsencrypt # pointe sur la config. letsencrypt plus bas

  traefik: # adresse pour le dashboard ;-)
    address: ":8080"

certificatesResolvers:
  letsencrypt:
    acme:
      email: "mon-courriel@domaine.tld"
      storage: "/acme.json"
      httpChallenge: # le type utilisé pour valider les certificats Let's Encrypt
        entryPoint: web

Je me suis permis de commenter un peu partout pour savoir de quoi il retourne.

Sachez qu’il existe aussi une méthode pour créer un fichier sur lequel Traefik va lire régulièrement pour mettre à jour sa configuration. Peut-être ferais-je un autre article sur ce sujet un jour. Petite piste : c’est le Provider nommé file qui permet de faire ça.

Une fois configuré, les autres conteneurs Docker que nous lançons n’ont plus besoin que des lignes suivantes dans leur fichier docker-compose.yml :

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.un-nom-de-service.rule=Host(`mon.domaine.com`)"
  - "traefik.http.routers.un-nom-de-service.entrypoints=websecure"

Au lancement de vos conteneurs via un fichier docker-compose.yml, Træfik lira les informations contenues dans labels et tentera de les analyser puis utiliser à bon essien.

Dans l’exemple donné ci-avant, on comprend que :

trafik.enable : le service doit être publié par Traefik (car dans la configuration nous avions mis exposedByDefault: false, donc pas de publication par défaut)
traefik.http.routers.un-nom-de-service.rule=Host(`mon.domaine.com`) : pour votre service remplacez un-nom-de-service par ce que vous voulez. Et mon.domaine.com par le domaine que vous détenez
la dernière ligne ne sert qu’à indiquer quel entrée par défaut accepter/utiliser. En l’occurence celle nommée websecure qui, dans notre configuration du fichier traefik.yml est configurée pour être disponible sur le port 443 avec un résolveur de certificat Let’s Encrypt

Exemple de docker-compose.yml pour lancer un service :

version: '3'

services:
    whoami:
      image: traefik/whoami
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.whoami.rule=Host(`whoami.domaine.com`)"
        - "traefik.http.routers.whoami.entrypoints=websecure"

Y aurait-il encore d’autres fonctionnalités sympas ?

Pour aller plus loin

Dans ce que j’ai pratiqué, voici quelques points à étudier pour aller plus loin :

utilisation de Let’s Encrypt par challenge DNS qui permet de gérer les DNS de son fournisseur de domaine en direct. Par exemple pour Gandi il suffit de fournir la variable d’environnement GANDIV5_API_KEY
utilisation d’un fichier externe avec watch: true pour appliquer les changements dès modification du fichier
utilisation de middleware pour une authentification basique
activer un port, par exemple 8080 pour l’accès au tableau de bord
dans certains cas où les services ne sont pas forcément dans des Docker, il peut être intéressant de fournir une IP et un port spécifique par un loadBalancer, Cf. https://doc.traefik.io/traefik/routing/services/#servers

Il y a beaucoup plus à découvrir avec Træfik. Je vous invite à lire la documentation qui est très riche et bien expliquée.

Conclusion

Utiliser Træfik a permis de réduire considérablement le temps de maintenance de mes services, que ce soit en terme de mises à jour, de renouvellement de certificats et d’organisation des dossiers/fichiers.

Cependant qu’on se le dise, ce n’est pas exempt de quelques difficultés :

il n’y a pas toujours des images Docker de vos services, il faut donc parfois fabriquer soi-même les conteneurs,
la courbe d’apprentissage de Træfik est assez difficile,
on se casse les méninges jusqu’à comprendre comment fournir un service sur Træfik

Si on fait l’effort d’apprendre Træfik et d’investir du temps, c’est surtout pour assurer la possibilité de connecter tout cela à un système de métriques, pouvoir faire de la journalisation, vérifier l’état de santé des serveurs, etc.

Il y a de quoi faire !

Cron sous Docker avec Alpine

Wed, 12 Oct 2022 21:41:39 +0200

Introduction

Chose promie, chose due ! J’écris un article sur mes pérégrinations en informatique.

Cette fois, je fais suite à l’état des lieux 2022 de mon espace numérique. Certains de mes services/sites nécessitent régulièrement d’être mis à jour. Pour cela je souhaite utiliser Cron, un service sous GNU/Linux qui permet de planifier le lancement de script(s) à des fréquences définies.

Comme je souhaite utiliser Docker, je me suis demandé s’il était possible de créer un service dédié avec Cron, Docker et Alpine.

Cet article explique quelques règles que j’ai dû suivre pour y parvenir. Il vous faudra a minima connaître Docker, voire Docker Compose pour comprendre quelque chose. À la rigueur vous connaissez déjà Cron et souhaitez l’utiliser sous Docker.

Nous allons d’abord réflechir sur le sujet. Puis nous utiliserons l’exemple d’un site pour expliquer la solution choisie avant de conclure sur cette histoire.

Pour les pressés, j’ai fais un chapitre « En bref » à la fin de cet article.

Photo trouvée sur le profil de Duc Ly sur Flickr sous licence CC BY-SA 2.0.

Réflexion sur le sujet

Ce que nous souhaitons faire, c’est lancer un service, par exemple almanax, et le mettre à jour régulièrement avec une tâche dans le service cron. Je vais expliquer un peu ma réflexion, si vous voulez entrer plus rapidement dans le vif du sujet, rendez-vous au chapitre suivant.

Tout d’abord il faut savoir que l’environnement choisi est Docker. Un système qui permet, à partir d’une image de générer plusieurs conteneurs ayant des points de montage différents pour changer les données qui s’y trouvent.

Docker propose plusieurs bonnes pratiques, parmi lesquelles :

ne lancer qu’un seul processus/service dans chaque conteneur
réutiliser les images ou les parties d’images au maximum pour réduire à la fois la maintenance des images/conteneurs, le travail effectué et la place système utilisée pour les images de base

Sachant que nous ne lançons qu’un seul processus par conteneur Docker, et que je souhaite utiliser Cron, je vais devoir lancer cron dans un autre service. Concrètement, Docker propose Docker Compose qui est un outil permettant de lancer plusieurs services à la fois, avec des dépendances entre eux (si besoin), une description des points de montage, des commandes à lancer sur chaque service, les ports ouverts, etc.

On peut également choisir l’image qu’on souhaite utiliser pour chaque service.

Certes nous allons lancer Cron dans un service à part, pour lancer les scripts que notre autre service a besoin pour mettre à jour ce dernier - je pense notamment à un script qui recompile et reconstitue mes pages webs statiques -, mais nous allons devoir avoir accès à notre service almanax qui contient la logique principale du site.

Pour cela, l’idée est de modifier l’image de almanax pour qu’elle contienne elle aussi cron. Ainsi on pourra lancer la même image sous Docker Compose, avec une commande de lancement différente.

On utilise des services Docker. Chacun ayant déjà leur propre image sous Alpine. Ainsi, chaque image possède déjà Cron inclut dans Alpine.

J’allais dire qu’une image vaut mieux que 1 000 mots, mais là nous allons donner un exemple avec Docker Compose pour comprendre de quoi il s’agit.

Mise en place, exemple avec l’Almanax

Peut-être le savez-vous déjà : j’ai crée une page statique qui liste une quinzaine de quêtes de l’Almanax dans un jeu nommé Dofus.

Cet outil est un de mes services fourni aux utilisateurs, mais également un projet Open Source, dofus-almanax que je fournis via Github. C’est dans ce dépôt Github que vous trouverez la plupart des fichiers nécessaires au bon lancement d’un service Cron que nous allons décrire.

On va étudier le fichier docker-compose.yml suivant :

version: '3'
services:
  generator:
    build: .
    image: dofus-almanax:0.2
    volumes:
      - almanax_public:/opt/almanax/public:rw
      - almanax_data:/opt/almanax/dl:rw
  web:
    image: caddy:2-alpine
    restart: always
    depends_on:
      - generator
    volumes:
      - almanax_public:/usr/share/caddy:ro
      - ${PWD}/Caddyfile:/etc/caddy/Caddyfile
    ports:
      - 8888:80
  cron:
    image: dofus-almanax:0.2
    restart: always
    entrypoint: /usr/sbin/crond
    command: ["-f", "-l", "2", "-L", "/dev/stdout"]
    volumes:
      - almanax_public:/opt/almanax/public:rw
      - almanax_data:/opt/almanax/dl:rw

volumes:
  almanax_public:
  almanax_data:

Nous avons 3 services :

generator : qui génère le site web au lancement, suite à quoi il s’éteint,
web : un service pour mettre à disposition les fichiers statiques générés par generator,
cron : un service pour mettre à jour régulièrement les fichiers statiques.

La particularité de la solution :

generator et cron utilisent la même image : dofus-almanax:0.2
ces deux services n’ont cependant pas la même commande au lancement : l’un prend la commande par défaut de l’image dofus-almanax:0.2, l’autre lance spécifiquement cron
pour le service cron, il spécifie avec le mot clé entrypoint d’utiliser /usr/sbin/crond (chemin absolu du binaire sous Alpine) et donne les paramètres -f -l 2 -L /dev/stdout

Que font les paramètres ?

-f définit de lancer le service en foreground, nécessaire sous Docker, sinon cela ne fonctionne pas
-l 2 définit un niveau de journalisation, habituellement c’est 8 (Cf. une explication des niveaux crond sous Stackoverflow
-L /dev/stdout permet d’avoir une sortie à l’écran dans Docker Compose

Ça, c’est les éléments de base. Cependant comment fonctionne la mise à jour, la configuration de cette dernière, etc.?

Fonctionnement de Cron dans l’image dofus-almanax:0.2

Nous l’avions dit, l’idée est de tout mettre dans l’image dofus-almanax:0.2 (à la fois nos scripts, nos fichiers et crond). Mais comment configurer le service Cron pour lui indiquer la fréquence à laquelle mettre à jour et comment mettre à jour nos fichiers ?

Regardons l’image Docker, écrite sous le fichier Dockerfile suivant :

FROM alpine:3.16

RUN apk update && \
    apk add --no-cache \
        py3-lxml \
	py3-mechanize \
	tzdata && \
    rm -rf /var/cache/apk/*

ENV TZ=Europe/Paris

WORKDIR /opt/almanax

VOLUME /opt/almanax/public
VOLUME /opt/almanax/dl

ENTRYPOINT ["python3", "almanax_next_week.py"]
CMD ["/opt/almanax/public/index.html"]

COPY ./src /opt/almanax
COPY ./crontabs /etc/crontabs/root

RUN chown root:root /etc/crontabs/root && \
    chmod 600 /etc/crontabs/root

COPY ./cron_scripts/generate.sh /opt/generate

Étudions ce fichier dans les grandes lignes concernant le service Cron notamment.

Nous partons d’une image Alpine 3.16 qui contient déjà crond (le service Cron)
Nous installons tzdata qui nous permettra de choisir correctement un fuseau horaire
ENV TZ=Europe/Paris définit notre fuseau horaire, histoire de lancer le script au moment où nous nous y attendons
Le fichier le plus important, cronbtabs est copié vers /etc/crontabs/root, la ligne COPY ./crontabs /etc/crontabs/root est déterminante pour remplacer le fichier du service crond d’Alpine Linux
On copie aussi un script generate.sh dont nous parlerons après
Ce même fichier nécessite des permissions spécifiques, notifiée vers la fin du fichier Dockerfile :

RUN chown root:root /etc/crontabs/root && \
    chmod 600 /etc/crontabs/root

Que contient le fichier crontabs et generate.sh ?

La configuration du service crond

Sous Alpine, le fichier utilisé pour configurer les éléments à lancer par crond est /etc/crontabs/root. Dans le chapitre précédent nous parlions de comment le remplacer, voici désormais son contenu :

5       0       *       *       *       /bin/sh /opt/generate

Nous voyons que nous utilisons effectivement le script generate.sh - qui a d’ailleurs été renommé generate.
Nous utilisons /bin/sh devant notre script :
- c’est un chemin absolu vers le binaire sh
- et nous utilisons sh, pas bash (car bash n’est, à défaut, pas délivré sous Alpine Linux)
Nous utilisons des caractères spécifique, formatés spécifiquement pour dire que nous lançons le service à 00h05 du matin

Pour générer un fichier compatible avec crond, je vous suggère Crontab Generator.

Il va falloir appliquer quelques règles pour être sûr que tout cela fonctionne évidemment.

En bref, les règles à appliquer pour crond

Voici les règles à retenir pour rédiger le fichier que le service crond va étudier :

7 espaces entre chaque élément défini dans le crontab (le fichier se nomme ainsi)
utiliser /bin/sh sous Alpine pour lancer un script, puis le nom de votre script
ne pas mettre de point dans le script qu’on lance (mettre par exemple generate au lieu de generate.sh)
le fichier /etc/crontabs/root doit appartenir à root (root:root) et avoir les permissions 600 (chmod 600)
utilisez -L /dev/stdout sous votre Docker Compose pour avoir une sortie lisible et -l 2 pour plus de logs, mais -l 8 suffit

Ce qui fait déjà pas mal de choses à savoir !

Conclusion

Bien que la réflexion ait été longue (et croyez moi j’ai pris plusieurs jours pour tester au fur et à mesure ce que je souhaitais), nous avons réuni les seules règles à appliquer pour que cela fonctionne, tout en trouvant une solution sympathique qui a plusieurs avantages :

le service Cron accède à tous les fichiers communs de notre service initial
le service Cron accède également à tous les scripts utiles de notre service initial
il suffit de changer le script d’entrée de l’image initiale pour lancer Cron
on a peu de changement à faire pour utiliser Cron finalement !

L’inconvénient reste cependant qu’il faut pouvoir modifier l’image initiale. Si nous n’avions pas la possibilité de faire ça, j’imagine qu’on devrait créer un point de montage commun entre le service initial et le service cron pour accéder à la fois aux fichiers mais aussi aux binaires… ce qui est bien plus complexe/casse-tête !

Liens utiles

Je me suis grandement inspiré, pour mes pérégrinations sur Cron dans Alpine sous Docker par :

Installation de PixelFed, une alternative à Instagram

Fri, 14 Sep 2018 23:34:55 +0200

Introduction

Peut-être le saviez-vous, ma curiosité m’a amenée à parcourir les réseaux sociaux. Ainsi je réside sur GNU Social, un réseau alternatif. Àla Twitter. Mais décentralisé. Depuis début 2018, ce réseau évolue rapidement. De nouvelles applications basées sur celui-ci fleurissent :

Mastodon : encore meilleur que Twitter !
PeerTube : YouTube sans la censure
Funkwhale : Groovshark chez soi, à partager en famille
PixelFed : alternative à Instagram
etc.

Nous allons nous intéresser au dernier de la liste : PixelFed, un outil pour publier et partager des photos. Un tutoriel plus accessible sur son installation manque cruellement sur le web, alors pourquoi ne pas se lancer ici ?

Je vous expliquerai en plusieurs étapes ma procédure d’installation. Le logiciel n’est pas encore stable, je préfère donc en parler ici plutôt que sur mon recueil d’astuces.

Avant-propos

Ce « tutoriel » est très probablement réservé à des personnes ayant un minimum d’assurance avec la ligne de commande ; les serveurs et probablement d’autres compétences dont je ne me rends pas compte. La lecture sera probablement longue, prenez votre temps et achevez les tâches progressivement.

PixelFed est un outil récent qui n’a pas été testé ni longtemps ni sur énormément d’instances. Je crois qu’il est sage de dire qu’il est réservé aux têtes brûlées. Ces personnes qui souhaitent être à la fois « hype » mais se casser les dents sur des soucis. Cela m’est arrivé : j’ai mis plusieurs heures à trouver ce qui n’allait pas.

Je ne serais en aucun cas tenu pour responsable de toute perte de données, de problèmes ou de catastrophe résultant de l’application des commandes de ce tutoriel. Vous êtes assez intelligents pour vous renseigner si le besoin s’en fait sentir. D’ailleurs un canal IRC pour PixelFed existe pour vous aider. Vous n’êtes pas seul, l’univers que nous connaissons est rempli d’aliens comme vous et moi :)

Prérequis

Sur la page du dépôt du projet on lit que l’application requièrt PHP supérieur ou égal à 7.1. Pour Debian c’est mort, à moins que vous soyez le roi du pinning. Pour Ubuntu, c’est déjà mieux : PHP 7.1 (sous bionic).

Dans le présent tutoriel j’ai travaillé sur une machine possédant ArchLinux et PHP 7.2. J’ai donc utilisé les éléments suivants :

php, Cf. https://wiki.archlinux.org/index.php/PHP
php-fpm, Cf. https://wiki.archlinux.org/index.php/nginx#PHP_implementation
postgreSQL, Cf. https://olivier.dossmann.net/wiki/services/postgres/ et https://wiki.archlinux.org/index.php/PostgreSQL
redis, https://wiki.archlinux.org/index.php/redis
git
nginx, Cf. https://wiki.archlinux.org/index.php/nginx

J’ai installé les paquets suivants :

sudo pacman -S php php-fpm php-gd php-pgsql git postgresql redis

Puis à la lecture du fichier README sur le dépôt git officiel de PixelFed, j’ai du installer plusieurs autres logiciels, y compris sur les dépôts AUR d’ArchLinux en utilisant l’outil trizen - que je recommande.

Voici les logiciels supplémentaires :

trizen -S optipng jpegoptim pngquant gifsicle svgo composer

Éditez également le fichier /etc/php/php.ini et décommentez (enlever le “;”) devant les lignes suivantes :

extension=bcmath.so
extension=gd.so
extension=iconv.so
extension=pdo_pgsql.so
extension=pgsql.so
extension=zip.so

Nous lancerons les différents services plus tard, passons déjà à l’installation de PixelFed.

Installation

Nous vérifions que le dossier /srv/http/ existe :

sudo mkdir -p /srv/http

puis nous créeons le dossier pixelfed et lançons l’installation des dépendances :

cd /srv/http
sudo git clone https://github.com/dansup/pixelfed.git
cd pixelfed
composer install

Le plus gros de l’installation est faite ! Faisons de la configuration avant le grand lancement !

Configuration

La configuration va se passer en quelques étapes :

configuration d’un fichier pour php-fpm, spécifique à PixelFed
configuration du fichier .env de PixelFed
lancement de postgreSQL
configuration d’une base de données pour postgreSQL
ajout d’un fichier de service pour systemd afin de lancer horizon pour PixelFed
configuration de Nginx
création d’une clé pour PixelFed
création du lien sur les storage de PixelFed
modification des permissions du dossier /srv/http/pixelfed

On crée le fichier /etc/php/php-fpm.d/pixelfed.conf avec le contenu suivant :

[pixelfed]
user = http
group = http
listen = /run/php-fpm/php-fpm-pixelfed.sock
listen.owner = http
listen.group = http
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Au cas où, on crée nous même le fichier /run/php-fpm/php-fpm-pixelfed.sock :

sudo mkdir -p /run/php-fpm
sudo touch /run/php-fpm/php-fpm-pixelfed.sock && sudo chown http:http /run/php-fpm/php-fpm-pixelfed.sock

Rendons-nous dans le dossier PixelFed pour créer le fichier de configuration et l’éditer :

cd /srv/http/pixelfed
sudo cp .env.example .env

avec le contenu suivant :

APP_NAME="Le plus terrible des noms d'instance que tu peux trouver"
APP_ENV=production
APP_DEBUG=false
APP_URL=http://tondomaine.tld

# Language configuration
#APP_LOCALE=fr
#APP_FALLBACK_LOCALE=fr

ADMIN_DOMAIN="tondomaine.tld"
APP_DOMAIN="tondomaine.tld"

LOG_CHANNEL=stack

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE="pixelfed"
DB_USERNAME="roidumonde"
DB_PASSWORD="ilestdesnôootres,ilabusonverrecommeuxlesôÔtres"

BROADCAST_DRIVER=log
CACHE_DRIVER=redis
SESSION_DRIVER=redis
SESSION_LIFETIME=120
QUEUE_DRIVER=redis

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

MAIL_DRIVER=smtp
MAIL_HOST=smtp.tondomaine.tld
MAIL_PORT=587
MAIL_USERNAME=tonpseudo@tondomaine.tld
MAIL_PASSWORD=mot2passe
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS="contact@tondomaine.tld"
MAIL_FROM_NAME="Le nom d'expéditeur que tu veux que les personnes voient"

SESSION_DOMAIN=".tondomaine.tld"
SESSION_SECURE_COOKIE=true
API_BASE="/api/1/"
API_SEARCH="/api/search"

OPEN_REGISTRATION=true
RECAPTCHA_ENABLED=false
ENFORCE_EMAIL_VERIFICATION=false

MAX_PHOTO_SIZE=15000
MAX_CAPTION_LENGTH=150
MAX_ALBUM_LENGTH=4

MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"
MIX_APP_URL="${APP_URL}"
MIX_API_BASE="${API_BASE}"
MIX_API_SEARCH="${API_SEARCH}"

Pour certaines variables vous trouverez des informations dans la documentation de Laravel, outil utilisé pour crée PixelFed.

Puis on lance postgreSQL et on crée une base de données suivant les informations ajoutées dans le fichier de configuration précédent :

sudo systemctl start postgresql.service
sudo systemctl enable postgresql.service
sudo su - postgres
createuser roidumonde
createdb -O roidumonde -E UTF-8 pixelfed
psql pixelfed
ALTER USER roidumonde WITH PASSWORD 'ilestdesnôootres,ilabusonverrecommeuxlesôÔtres';
\q
exit

Maintenant on va créer le fichier de service systemd pour lancer horizon. Éditez /etc/systemd/system/horizon.service et mettez y ceci :

[Unit]
Description=Service horizon pour PixelFed
After=network.target

[Service]
Type=simple
User=http
WorkingDirectory=/srv/http/pixelfed
ExecStart=php artisan horizon
Restart=on-failure

[Install]
WantedBy=multi-user.target

suivi de :

sudo systemctl daemon-reload

Edit : À la lecture d’un ticket sur Github qui m’a été signalé par raphgilles, le fichier /etc/systemd/system/horizon.service peut ressembler à ceci :

[Unit]
Description=Service horizon pour PixelFed
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/php7.2 /srv/http/pixelfed/artisan horizon
Restart=on-failure

[Install]
WantedBy=multi-user.target

De là on édite le fichier /etc/nginx/nginx.conf et on rajoute la section suivante sous la ligne :

# HTTPS Server

avec :

server {
  listen         *:80;
  listen         [::]:80;
  server_name    tondomaine.tld;

  root /srv/http/pixelfed/public;
  index index.php index.html;

  location / {
    try_files $uri $uri/ /$is_args$args;
  }

  location ~ \.php$ {
    try_files $uri =404;
    fastcgi_split_path_info  ^(.+\.php)(.*)$;
    fastcgi_pass unix:/run/php-fpm/php-fpm-pixelfed.sock;
    fastcgi_index index.php;
    include fastcgi.conf;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
  }

}

Il n’y a plus qu’à lancer redis, générer une clé pour PixelFed, générer le lien vers le dossier storage, migrer la base de données et changer les permissions du dossier :

sudo systemctl start redis.service
sudo systemctl enable redis.service
cd /srv/http/pixelfed
php artisan key:generate
php artisan storage:link
php artisan migrate
cd /srv/http
sudo chown http:http pixelfed -R

Chaud bouillant pour tester si tout va bien ? C’est parti !

Ça passe ou ça casse !

Tout est prêt, il ne reste plus qu’à :

lancer horizon
lancer php-fpm
lancer Nginx
tout casser 😭

Faites :

sudo systemctl start horizon.service
sudo systemctl enable horizon.service
sudo systemctl start php-fpm.service
sudo systemctl enable php-fpm.service
sudo systemctl start nginx.service
sudo systemctl enable nginx.service

Alors, si vous allez sur tondomaine.tld, tout fonctionne ?

Accéder au Dashboard admin

Au moment où j’ai écris ce tutoriel, le bug 327 avait encore cours. Pour pallier à ce problème, j’ai lancé la commande suivante :

sudo mkdir -p /srv/http/pixelfed/storage/app/public/m && sudo chown http:http /srv/http/pixelfed/storage/app/public/m

Et pour devenir administrateur, sachant que nous sommes le premier utilisateur (id : 1) à s’être enregistré :

sudo su - postgres
psql pixelfed
UPDATE users SET is_admin = 't' WHERE id = 1;
\q
exit

Et vous voilà administrateur !

Conclusion

Je dois avouer que l’installation est non seulement longue, mais compliquée. Le nombre de problèmes à régler est plus important que pour l’installation d’une autre application PHP que j’ai eu l’occasion d’utiliser.

J’ai par exemple encore quelques soucis pour comprendre comment personnaliser les pages d’à propos, de licence, la page d’accueil, etc. sans casser mon installation et ses mises à jours. J’aimerais également savoir si le lien entre PixelFed et Redis fonctionne réellement, parce que d’après le Dashboard admin, Redis est inactif…

Je suis pressé d’être à l’année prochaine pour voir ce que ce projet donnera ! Et peut-être aurons-nous une application mobile pour faciliter l’envoi de données ? Voire la possibilité d’utiliser AndStatus, Twidere ou Tusky pour envoyer nos belles images et nos têtes curieuses 👽 .

Les Rencontres Mondiales du Logiciel Libre à Strasbourg en 2018

Wed, 18 Jul 2018 19:29:42 +0200

Introduction

Peut-être vous souvenez-vous de mes récits et péripéties aux Rencontres Mondiales du Logiciels Libre (ou RMLL) ? Ou peut-être n’avez vous jamais entendu parler des RMLL ?

C’est un évènement crée en 2000 et dont le lieu change chaque année : il passe de ville en ville. Le sujet principal est comme son nom l’indique : le Libre, c’est à dire les musiques libres, les logiciels libres, les vidéos libres, l’art libre, les prix libres, les plans libres pour confectionner des appareils, etc.

J’ai pu me rendre aux RMLL de l’année 2006 (Nancy), 2009 (Nantes), 2010 (Bordeaux), 2011 (Strasbourg), 2012 (Genève), 2013 (Bruxelles) et 2018 (Strasbourg) ! Je vous propose de dire quelques mots sur les éléments que j’ai repérés, les différentes activités dont j’ai entendu parler et celles auxquelles j’ai participées.

[](/images/evenement/rmll/2018_goodies.jpg" >}})

Bilan

Ça commence souvent comme ça : on lit une news sur LinuxFR, on tombe sur le site très disruptif des RMLL 2018 et on se rend compte qu’effectivement c’est dans notre ville. Et ils ont besoin d’aide !

J’ai donc - encore - participé à cet événement en tant que bénévole, visiteur, mais aussi coordinateur de la captation. Je tiens d’ailleurs à profiter de ce paragraphe pour remercier l’ensemble des personnes qui ont participé de prêt ou de loin à la réalisation de la captation durant les RMLL 2018. Vous qui lisez ces lignes vous reconnaîtrez sûrement !

Ce qui est particulièrement appréciable cette année :

la proximité. Nous en profitons bien plus quand c’est proche de chez soi !
la bière était bonne. Cette année c’était La Mercière
les T-shirt bénévoles - violets - ont été si bien accueillis et appréciés que le staff a hésité à les vendre
le site a été tellement disruptif et décalé par rapport à l’habitude des gens qu’il a souvent été critiqué. À mon sens il restera dans les esprits et c’est l’essentiel ! À noter qu’importe que le site plaise ou non, l’ensemble de la communication, des graphismes, des flyers, des affiches, des T-shirts, des marquages au sol, des pancartes ont été dans le même thème visuel. C’est appréciable !
il y a eu une réunion CHATONS, ce qui m’a permis de rencontrer des personnes que je ne connaissais que sur la liste de discussion
il y a eu un concert de musique Libre - que j’ai loupé
la soirée jeux vidéos au Shadok, la Fabrique Numérique de Strasbourg a été sympathique et accessible aux plus jeunes (testée et approuvée par un enfant de 5 ans). Il y a même eu un bal avec des danses et un joueur de flûte devant le bâtiment
la lecture par la méthode de l’arpentage a fait des émules : il s’agit de découper un livre en plusieurs sections et de faire lire à chacun du groupe une partie. Une fois la lecture terminée, chacun raconte ce qu’il a compris de sa lecture. On parcourt donc un livre assez rapidement.

Là où les RMLL nous surprennent souvent, c’est avec les enfants : ils sont tout fou de venir regarder les huluberlus que nous sommes. Notamment au « village du Libre » qui est un ensemble de stands avec des associations, des projets ou des groupes de personnes voulant présenter ce qu’ils font. C’est riche en conversations, en goodies et en autocollants. Ceux que vous voyez sur l’image d’illustration de cet article ont été récupérés durant l’évènement par mon enfant ! Sacrée bestiole ! Merci aux personnes des stands d’avoir été aussi généreux !

Et pour le plaisir des enfants, on a même eu droit à des démonstrations de trajets de locomotives - alimentées par batterie USB - sur des rails officiels, mais sans utiliser le protocole électrique propriétaire des rails (car oui apparemment si on envoie du courant dans les rails, ça ne donne rien). Sans l’appareil propriétaire aucun résultat. On arrête pas le progrès…

Je crois avoir fait le tour des moments clés des RMLL 2018.

Conclusion

Cette année a eu un programme très chargé, une période assez courte de préparation, des personnes investies et des dons curieux d’associations qui ne se sont jamais présentées à l’événement, comme Renewable Freedom Foundation.

Côté captation, j’ai apprécié travailler aux côtés de ljf (de YunoHost). Nous étions coordinateurs de la captation. C’est une expérience enrichissante qui continue puisqu’une fois les enregistrements effectués, il va falloir les passer en revue !

Tout ceci a été formidable grâce :

à la ville de Strasbourg
aux personnes qui ont organisé les RMLL 2018 à Strasbourg
aux bénévoles quels qu’ils soient
à PSES
aux CHATONS
aux visiteurs
aux personnes que j’ai oubliées et qui mériteraient toute mon attention
à mon enfant d’avoir judicieusement récupéré et partagé de nombreuses étiquettes et goodies, mais aussi d’avoir pu montrer que les bénévoles de 5 ans existent. J’ai aussi sourit en le voyant faire de la publicité pour sa Debian chérie alors même que son papa n’utilise pas ce système d’exploitation.

Quoiqu’en disent les mauvaises langues, il y a de bons côtés aux événements. J’invite chaque personne qui lit cet article à s’intéresser aux événements du Libre qui se déroulent autour de chez elle afin d’y participer. Il y a une véritable expérience humaine à faire. Soyez souriants et partagez !

Wekan, mon alternative à MyTinyTodo

Wed, 21 Feb 2018 19:07:46 +0100

Introduction

Pour encore beaucoup de personnes, s’organiser n’est pas une tâche facile. On commence par faire des pense-bête sur de petits papiers. Puis les notes s’accumulent et le bureau se retrouve complètement recouvert !

Pour pallier à ce genre de problèmes, j’utilise MyTinyTodo. Cependant c’est un outil mono-utilisateur et la dernière version date de 2014.

Je commence donc à tester plusieurs alternatives. Aujourd’hui je vais vous parler de l’une d’entre elles : Wekan, un kanban Libre façon “Trello” (service de pense-bête en ligne).

Photo trouvée sur le profil de Michael Arrighi sur Flickr

Présentation de Wekan

Wekan se base sur les kanban, un système de colonne et de lignes (appelées couloirs) pour trier ses tâches.

Par exemple on pourrait imaginer des colonnes “À faire”, “En cours”, “En attente” et “Terminées” pour trier ses tâches suivant leur état d’avancement. C’est vous qui choisissez !

Ce logiciel utilise des technologies Web assez modernes, ce qui permet une utilisation agréable de l’interface. C’est assez intuitif de manière générale, bien plus que MyTinyTodo ne l’est !

Je pense d’ailleurs que ça vaut le coup de comparer un peu MyTinyTodo et Wekan pour comprendre ce que Wekan peut apporter.

Comparaison succinte des deux outils

MyTinyTodo utilise GTD, une technique qui « trie » les tâches par un degré d’importance (4 niveaux). Pour agir sur l’interface et changer rapidement quelques tâches de degré d’importance, c’est une torture parce qu’il faut les sélectionner une à une. Là où Wekan propose simplement de déplacer la tâche dans la colonne appropriée.

En revanche, la méthode de Kanban énnoncée auparavant sous Wekan implique que vous sachiez comment organiser vos tickets. Alors que MyTinyTodo propose plutôt des catégories de tâches. Mais dont le déplacement n’est pas aussi simple qu’un glisser/déposer.

MyTinyTodo est mono-utilisateur. Wekan multi-utilisateur, avec un partage des tâches/tableaux et des sections privées/publiques.

MyTinyTodo consomme peu : 20Mo de mémoire vive à tout péter, avec une base SQLITE3 facile à sauvegarder. Tandis que Wekan utilise 120Mo de mémoire vive, utilise MongoDB qui utilise 20 Mo de mémoire vive et est embêtant à sauvegarder car il faut un script pour lancer la sauvegarde de la base (si on l’utilise dans un Docker c’est légèrement plus complexe).

C’était, dans les grandes lignes, ce qui diffère des deux outils. J’ai tout de même mon opinion sur l’outil Wekan, dont nous allons tout de suite parler.

Mon expérience de Wekan

Wekan, est une brise fraîche pour la gestion des tâches car le glisser/déposer d’une colonne ou d’une ligne (ils appellent ça des couloirs) à l’autre est aisé. Ce qui implique moins de temps à trier et plus de temps pour réellement faire les tâches. C’est agréable.

Seulement cet outil est de la folie furieuse pour tout le reste :

il consomme pas mal en mémoire vive (120Mo) et en processeur (CPU)
supprimer une tâche n’est pas intuitif : il faut aller dans “plus” puis trouver un petit lien souligné nommé « Supprimer »
supprimer un tableau ? Pas possible ! On peut l’archiver oui. Et plus tard, si vous êtes un guerrier, vous pouvez utiliser wekan-cleanup (un script) pour nettoyer votre base MongoDB
l’outil n’est pas disponible sur ARM en 32 bits. Notamment à cause de meteorJS qui est le framework utilisé pour développer l’outil
pas encore de possibilité d’utiliser autre chose que la base de données MongoDB
il utilise NodeJS. Sérieux, c’est assez galère de faire une installation propre sans exploser son propre système qui contient lui aussi du Javascript en pagaille

Le produit final est certes agréable pour l’utilisateur, mais côté serveur il faut pallier aux problèmes cités.

Conclusion

Vous l’aurez compris, je suis mitigé sur Wekan. Je souhaite trouver un outil plus léger, disponible sur ARM, avec une interface web et une méthode simple et « raffinée » pour déplacer rapidement les tâches d’une priorité ou d’une catégorie à une autre. Peut-être que je cherche le mouton à 5 pattes, mais mon petit doigt me dit que je trouverai une solution pour « créer » un outil capable de saisir et organiser rapidement mes tâches et les accomplir plutôt qu’à perdre du temps à les gérer !

Suivre la progression de ses jeux vidéos

Sat, 12 Aug 2017 19:32:37 +0100

Introduction

Précédemment je parlais de mon application de la méthode de Project Zero sur ma liste de jeux vidéos. Je réduis en effet ma liste de jeux en cours à 3 maximum par console. Ce qui me permet d’achever plus rapidement les jeux vidéos l’un après l’autre sans me disperser.

Seulement voilà, la collection s’aggrandissant, il a fallu trouver un outil pour suivre facilement l’ensemble de mes jeux vidéos, triés par console, savoir lequel a été terminé, ceux qu’il me reste à finir, les jeux en cours, etc.

Je vais donc vous faire part de mon expérience sur 2 outils qui permettent de gérer sa collection de jeux vidéos :

Backloggery (site web)
My Game Collection (Android)

Backloggery.com

Après quelques recherches sur le Web je suis tombé sur un site intéressant : Backloggery.com.

Il permet à un utilisateur de créer une liste de titres (jeux vidéos). Pour chacun d’eux, vous pouvez renseigner (liste non exhaustive) :

le titre du jeu
la console/système sur lequel il tourne
votre progression parmi :
- unfinished : jeu non terminé
- unplayed : pas encore joué
- beaten : jeu terminé
- completed : jeu terminé totalement
- mastered : jeu terminé avec un défi personnel fixé
votre avis de 1 à 5 (ou pas d’avis)
si vous jouez actuellement à ce jeu ou non

Ce site permet également de créer sa liste de jeux vidéos souhaités. Il propose de noter le jeu comme détenu, à la maison, souscris par abonnement, des commentaires, des notes de progression, le nombre de succès accomplis, etc.

Puis, une fois le détail de vos jeux enregistrés, le site fait une page de statistiques de vos jeux, comme par exemple le profil de MetalMan1230 sur Backloggery.

Ce que j’aime :

un thème un peu rétro qui tient la route
ses règles d’utilisation qui stipulent qu’aucune donnée à caractère personnel ne sera collectée. Au pire anonymisée.
le côté simple pour la saisie des jeux, pas de chi-chi, tu entres le titre, la console et ton pourcentage d’accomplissement du jeu
la page de statistiques est une très bonne idée car elle permet de visuellement comprendre notre état d’avancement

Ce que j’aime moins :

le site n’est pas du tout mobile-friendly, c’est à dire qu’il ne s’adapte pas bien aux petits écran, c’est une galère.
il n’y a pas d’API pour récupérer des infos de son compte (pour éventuellement créer une page web statique récapitulative)

Il n’en reste pas moins que c’est un site que je conseille vivement !

My Game Collection

Sur Android, il en est tout autrement : le Play Store propose tout un tas d’application, mais une d’entre elle semble se démarquer par sa richesse de fonctionnalités : my-game-collection.

L’idée de l’application : récupérer sa liste de jeux sur un nombre important de services comme Steam, Backloggery, HowLongToBeat, Collectorz, Desura, Itch.io, vgcollect, etc. afin d’en créer une liste à suivre.

L’outil propose ensuite d’ajouter des tags à vos jeux pour les filtrer par la suite. Il gère aussi la collection d’amiibo, de Skylanders, de personnages Disney Infinity, etc.

Voici les éléments que j’apprécie particulièrement :

import de jeux parmi une liste bien fournie de site web
pendant la synchronisation de notre liste avec une plateforme distante, on peut choisir au cas par cas de modifier les données du jeu vidéo tel qu’il apparaît dans notre liste (image de présentation, titre du jeu, tags utilisés pour l’œuvre, etc.). Si vous avez la flemme, il y a la synchronisation automatique
avoir pensé aux figurines des jeux vidéos, comme pour Lego Dimensions
gère aussi sa liste de consoles et d’accessoires
le côté mobile est intéressant car on peut saisir à côté de sa collection sans déplacer le PC
affichage - en utilisant le site HowLongToBeat - du nombre d’heure pour accomplir le jeu en totalité

En revanche, je peux lister bon nombre de soucis :

l’interface n’est pas simple à utiliser. C’est trop fourni donc on se retrouve avec de petits boutons, voire même avec des choses qui se chevauchent sans qu’on puisse appuyer sur le bouton situé derrière
l’outil propose un compte premium afin de pouvoir bénéficier de toutes les possibilités, c’est compréhensible mais assez dommage
la synchronisation des données ne fonctionne que dans un sens (on récupère, on envoie pas). Du coup ça reste moyen pour gérer ses jeux Backloggery…
quand la base de données igdb.com n’est pas suffisante pour les informations d’un jeu, il faut utiliser GiantBomb.com, mais ça demande une clé API. Quand on y connaît pas grand chose, c’est juste impossible

Je dois l’avouer, ce dernier outil ne correspond pas du tout à mes attentes, bien qu’il contienne la liste des Skylanders (qui me serait utile) mais aussi une récupération sur HowLongToBeat du temps approximatif pour terminer le jeu.

Si vous avez la flemme d’utiliser un ordinateur pour gérer votre collection, utilisez cet outil, sinon ravisez-vous et continuez sur d’autres services prévus à cet effet.

Conclusion

Après avoir eu du mal à trouver une application qui permette de suivre la progression pour chaque jeu vidéo détenu, je m’attendais à trouver quelque chose de plus basique que les outils présentés. Je reste donc étonné de ces derniers. Mais quelque peu déçu du manque de finition de ces applications.

Dans l’idéal, et comme souvent, il faudrait que je crée mon propre outil pour correspondre à mes attentes. Mais qui a du temps pour ça ?

Je vais donc rester sur une approche temporaire et double : utiliser Backloggery, exporter chaque fois vers My Game Collection pendant que je développerai un outil similaire ralliant le meilleur des deux dans un seul outil :)

S'organiser avec Lessy

Fri, 30 Jun 2017 20:05:16 +0100

Introduction

Ce n’est pas un secret, j’ai toujours été électroniquement dispersé. Toujours plein d’idées, peu de temps pour les accomplir et 1000 manières de résoudre des problèmes.

Est-ce bon ou mal ? Ce billet ne permettra pas de répondre à cette question. En revanche j’ai peut-être trouvé une méthode pour avancer dans ses projets personnels sans perdre de vue l’ensemble des projets.

Après une petite histoire sur la découverte - piquante - d’un outil, je vous présenterai ce dernier.

Photo trouvée sur le profil de Steve Childs sur Flickr

La découverte

Tout commence par l’idée saugrenue d’iGor de partager partiellement ses découvertes. Et je ne l’en remercierai jamais assez ! Je découvre un lien vers un projet, une méthode, un outil pour gérer les idées saugrenues qui nous trottent dans la tête. Comme quoi partager, même en vrac, participe à l’évolution possible de son entourage 😤.

Je suis donc arrivé sur un ensemble de billets présentant une méthode. Billets que vous n’avez pas besoin de lire puisque je tenterais de faire un résumé dans le paragraphe suivant. Mais rien ne vous empêche d’y faire un - grand - tour 😏.

Ce qui m’a paru curieux sur le coup : suite à l’acquisition récente de la Nintendo Switch™ - notamment - je procédais à une méthode similaire pour ma gestion des jeux en cours.

Je vous en parlerais après, place à la description de Lessy !

Découverte de la méthode Lessy

Je tiens avant tout à préciser que je vous partage ma compréhension de la méthode Lessy. Elle doit sûrement différer quelque peu de celle dont Marien Fressinaud décrit.

L’outil développé par Marien est disponible sur Github : https://github.com/marienfressinaud/lessy

Et disponible en ligne : https://lessy.io/

Mais alors, Lessy, qu’est-ce ? Je dirais un ensemble de règles :

chaque fois qu’on a une idée de projet, on la note sur un bout de papier (ou en numérique) et on le dépose dans une boîte
si on veut travailler sur un projet on le sort de la boîte
on ne travaille jamais à plus de 3 projets à la fois
quand on sort un projet de la boîte, on se fixe une date maximum avant de remettre le projet dans la boîte. Ceci pour permettre à des projets qui n’avancent pas de retourner dans la boîte au profit d’autres projets

Ces règles impliquent qu’on peut travailler sur moins de 3 projets. Et que ne nous sommes pas obligés de finir le projet avant de le remettre dans la boîte.

Ce que j’ai trouvé bluffant, c’est que j’utilisais une méthode similaire depuis quelques temps avec mes… jeux vidéos.

Application de la méthode par l’exemple

Je vous le disais, suite à l’acquisition d’une console dernièrement, je n’arrivais plus à gérer le nombre de jeux en cours. Alors j’ai mis en place les quelques règles citées précédemment de la manière suivante :

les jeux représentent les projets
je mets donc tous les jeux dans une boîte (carton)
je ne sors que 3 jeux maximum à la fois
quand j’ai terminé d’avancer sur un jeu : je le remets dans le carton
tout jeu terminé va sur une étagère

Et petite différence avec la méthode :

pour chaque console je fais un carton

Je gère ainsi 3 jeux par console.

Quand je veux jouer, généralement je réfléchis en terme de console du moment plutôt que jeu du moment. Et je choisirai parmi les 3 jeux sortis celui que je préfère au moment où je veux jouer.

Cela m’a déjà permis de mieux avancer sur les jeux vidéos, voire d’en terminer quelques uns. Ce qui ne m’était pas arrivé depuis des années !

Conclusion

Bien que mon application de la méthode soit assez atypique, je dois dire que je suis très heureux d’avoir découvert Lessy.

Je pensais qu’une RFC serait de bonne augure, qu’une bibliothèque pouvait être construire pour gérer ce type de gestion de “papiers dans une boîte”, mais finalement c’est tout aussi bien d’adapter selon ses besoins.

Lessy va-t-il révolutionner votre gestion des priorités et la finalisation de vos projets ?

Migrer son wiki de Dokuwiki à Hugo

Sun, 25 Jun 2017 11:08:23 +0100

Introduction

Il y a quelques mois je vous parlais de ma découverte d’Hugo, le moteur de site statique. J’en profitais pour faire la transition de mon blog vers Hugo. Mais aussi d’outils spécifiques comme hugo-portal, un portail web de ma fabrication.

Vous l’aurez compris, dans la continuité de ma démarche, je me devais de passer également mon wiki à ce formidable outil qu’est Hugo. Ceci pour simplifier ma chaîne de publication Web et n’avoir qu’un outil à maintenir.

Nous verrons ici les étapes successives par lesquelles je suis passé pour obtenir un premier résultat :

la recherche d’un outil de migration de Dokuwiki vers Hugo
la recherche d’un thème Hugo spécialisé wiki
mes impressions sur cette migration

Photo trouvée sur le profil de silkeremmery sur flickr sous licence cc by 2.0.

Outil de migration de Dokuwiki → Hugo

Généralement, la première chose à faire quand on veut migrer depuis un outil vers un autre, c’est de regarder dans la documentation de ce dernier s’il existe un script de migration. Et Ô bonheur : Hugo propose une page complète sur les outils de migration. Et plus encore : un script pour Dokuwiki existe.

En revanche, j’ai tenté de l’utiliser, et j’ai dû modifier le script dokuwiki-to-hugo. Dans les grandes lignes j’ai :

ajouté le script main.py à la racine du projet (sinon ça ne fonctionnait pas comme la documentation le signalait) sans cela je n’obtenais aucun résultat
ajouté la prise en compte du mot clé “this” qui semble apparaître à plusieurs endroit de mon Dokuwki. Mot clé utilisé pour la création de liens

Avec ce script, on simplifie grandement la tâche de migration, car il suffit :

de récupérer son dossier Dokuwiki contenant les pages, par exemple wiki/data/pages
de le copier quelque part sur notre disque local. Par exemple : /home/olivier/wiki
de lancer notre script dokuwiki-to-hugo (situé dans le répertoire /home/olivier/dokuwiki-to-hugo/) de la manière suivante :

python3 main.py -d /home/olivier/wiki/data/pages

Vous obtenez un dossier /home/olivier/dokuwiki-to-hugo/output/home/od/projets/wiki/data/pages qui contient des fichiers Markdown compatibles avec Hugo. La grande classe !

Il ne reste plus qu’à ajouter un beau thème pour obtenir un wiki tout neuf !

Un thème wiki pour Hugo

Dans le même ordre d’idée que le paragraphe précédent, quand on cherche quelque chose de particulier sur un outil, on regarde dans la documentation et/ou sur le site web. Ça tombe bien, Hugo propose une galerie de thèmes.

Mon problème : Je ne vois rien qui soit dans l’esprit d’un wiki. Il n’y a même pas de tag wiki dans la liste des thèmes. Évidemment il y a bien un tag documentation dans la liste de thèmes Hugo, mais ça ne ressemble pas vraiment à mon habitude de wiki.

Je me suis donc improvisé créateur de thème Hugo avec les contraintes non-moins compliquées :

de rendre le site responsive un maximum : qu’il soit utilisable sur mon mobile et sur mon desktop
de rester le plus simple possible, dans l’esprit de Dokuwiki, voire assez proche
de ne pas y passer énormément de temps
de partager mon travail. Et qui sait, le proposer sur la galerie de thèmes Hugo ?

J’ai donc créé le thème Adam & Eve pour Hugo. Il peut se résumer à 2 types d’écran :

la page d’accueil, qui affiche le titre de notre wiki et contient des liens vers du contenu qu’on veut partager
une page spécifique, qui propose un retour vers l’accueil, un sommaire du contenu de notre page et le contenu de notre page

Voici un aperçu d’une page spécifique sur laquelle on remarque notamment des encarts jaune et rouge que j’ai repris de certains modules Dokuwiki :

La page d’accueil ressemble plutôt à :

Et sous sa version mobile :

Ce thème ne ment pas, il reste dans son plus simple apparât : celui d’Adam et Eve.

Mon ressenti sur cette migration

Je ne vais pas le cacher, je reste mitigé sur la migration d’un Dockuwiki vers Hugo. Pour plusieurs raisons :

suivant la taille de son wiki précédent, la migration prendra plus de temps. Je parle bien sûr de la relecture et le peaufinage. Dans mon cas : 375+ pages à vérifier. J’y suis encore à l’écriture de ces lignes…
l’outil de migration n’est pas parfait, il ne gère pas les tableaux, certains morceaux de code qu’on a mis sur nos pages, la conversion des liens est loin d’être parfaite et parfois ça cafouille quand il y a plusieurs signes égal à la suite

Mais soyons positif : vous partez avec une épine de moins que moi, à savoir le thème wiki ! Soyez heureux de pouvoir enfin profiter d’un si merveilleux thème wiki pour votre outil 😇.

Conclusion

De nos jours, faut pas rêver, peu d’outils font les choses à votre place :

j’ai dû compléter le script de migration Dokuwiki vers Hugo pour assurer les particularités de mon wiki
j’ai dû créer mon propre thème wiki pour avoir quelque chose qui corresponde à mes attentes d’un wiki responsive simple
j’ai passé - et passe encore - un temps fou à peaufiner et traiter mes anciennes pages pour avoir quelque chose de potable sur la nouvelle mouture

C’est un bilan très mitigé. Mais j’ai migré mon Dokuwiki vers Hugo 😄. C’est le plus important. Maintenant que j’ai Hugo pour mon blog, et pour mon wiki, je vais pouvoir passer pas mal de temps sur le contenu. Au bienfait des visiteurs !

EDIT : à la mi-août 2017 (mais en ayant passé peu de temps dessus), la migration n’est toujours pas complète : je remanie sans cesse la structure et le contenu de mes pages wiki. Il sera donc réellement en ligne tardivement cette année !

Gitea, service git sans prise de tête issu de Gogs

Fri, 07 Apr 2017 17:33:55 +0200

Introduction

Que ce soit au travail comme à la maison, j’utilise Git, le logiciel de gestion de version décentralisé, au quotidien. J’ai plusieurs projets, parfois publics, parfois privés.

Jusqu’à maintenant, pour gérer mes dépôts, j’utilisais un mix de :

et le petit nouveau que j’utilise chez Framasoft :

Gitlab

Chacun de ces outils apporte quelque chose, que ce soit l’outil de gestion des tickets, un wiki attaché, des dépôts (public/gratuit) publics, un environnement d’intégration continu, etc. Mais utiliser ces outils nous fait dépendre d’une entreprise, et à tout moment le service - gratuit jusque là - peut couper.

Je me suis dit qu’il était temps d’héberger une interface à mes dépôts (avec copie de sauvegarde en prime).

Photo trouvée sur le profil de chumsdock sur Flickr sous licence CC BY-SA 2.0.

Comment en être arrivé au choix de Gitea ?

Dans mes possibles il y avait :

Gitlab : récent, écrit à l’aide de Ruby On Rails et complet (propose l’intégration continue, les pages webs, la génération d’une version production, etc.)
un agglomérat de git daemon, gitolite et git web : pour bénéficier d’un accès en git://, gérer les dépôts publics/privés et avoir une interface web pour naviguer dans le dépôt de code
Gogs : un outil léger, écrit en Go, se voulant être une solution sans prise de tête

Mes problèmes avec ces outils :

Gitlab : trop gourmand en mémoire vive. J’aimerais la possibilité de migrer sur une machine plus légère en cas de besoin
le mix daemon+gitolite+web : mes essais sur l’interface web des dépôts privés n’étaient pas concluant. La mise en relation des outils était embêtante. Et pas de gestion de tickets sur chaque projet.
Gogs : documentation d’installation peu détaillée

Vu mes maigres solutions, j’ai tenté l’aventure avec Gogs. L’envoi de courriel sous Gogs ne semble pas fonctionner pour tout le monde et l’alternative via sendmail n’est pas encore implémentée, du coup à la lecture de ce dernier lien j’ai visé Gitea. Et je ne suis pas déçu du voyage.

Gitea

Gitea est un fork de Gogs. Un outil pour gérer des dépôts Git via une interface web. Cela propose une gestion des tickets attachés au projet, des pages de Wiki, une gestion des utilisateurs et des groupes d’utilisateurs et des liens vers de l’intégration continue.

Gitea, tout comme Gogs, se veut être multiplateforme, léger, en un binaire unique et Open Source !

L’équipe de Gitea explique sur son blog pourquoi elle a forké le projet. Je résumerais la chose ainsi : Gogs ne possède qu’une et une seule porte d’entrée aux contributions, c’est à dire un seul développeur. Ce qui, à long terme, ne permet probablement pas d’en assurer la pérénité. Gitea résout le problème en proposant plusieurs personnes pour maintenir le projet. Personnes précédemment choisies par la communauté.

Quelles différences avec Gogs ?

Outre la centaine de participations au projet et la quarantaine de bugs résolus par Gitea, l’outil propose quelques fonctionnalités supplémentaires comme :

la prise en charge d’OpenID pour s’identifier
l’option sendmail pour envoyer des courriels
le support de git-lfs afin d’inclure le versionnement de fichiers de plus grosse volumétrie

Par ailleurs la plupart des variables autrefois connues sous le nom GOGS_WORK_DIR sont remaniées en GITEA_WORK_DIR.

L’apparence visuelle est aussi légèrement modifiée aux couleurs de Gitea.

Ce choix est tout de même risqué

Utiliser un projet forké a des risques, comme je l’ai vu pour ChiliProject, fork de Redmine qui a donné lieu 4 ans plus tard à un essouflement des personnes et un beau script de migration vers Redmine. Ce qui est tout de même atypique de pouvoir revenir au projet initial sans casse !

Je risque :

d’utiliser un projet sans mises-à-jour
de ne plus pouvoir retourner à Gogs le jour J
perdre mon temps

Défi accepté, j’utilise Gitea 😃.

Conclusion

À première vue l’outil semble fonctionner. Il est agréable à utiliser. Me fournit les dépôts publics et privés dont j’avais besoin. Un accès SSH aux dépôts. La possibilité d’ajouter plusieurs clés d’accès à ces dépôts suivant mes machines. La gestion du projet via tickets, wiki, etc. Et il reste léger, la page de statistiques affichant une utilisation de 20MB sur le serveur.

En outre j’ai profité de l’installation de cet outil pour rédiger une page recensant les variables d’environnement disponibles sur Gitea. Je souhaite à Gitea une longue vie afin de pouvoir maintenir mon service Git à flot ;).

J’ai d’ailleurs participé à la rédaction complète d’une page sur les variables d’environnement spécifiques à Gitea