Normal sur Olivier DOSSMANN

Encore un autre lecteur de flux RSS, Yarr

Sun, 22 Mar 2026 11:42:00 +0100

Introduction

Il y a fort fort longtemps (en 2009), je testais TinyTinyRSS, un lecteur de flux RSS avec une interface Web. J’en parlais d’ailleurs dans un article pour signaler la venue de deux nouveaux tutoriels (dont TinyTinyRSS) dans mon Recueil d’astuces. Ce lecteur était agréable à l’usage, rapide et utilisait une base de données postgreSQL. Bref, tout ce que je voulais à l’époque. Le temps a passé ; je dépensais moins de temps sur les flux RSS. Puis j’ai arrêté - qu’importe les raisons. Ça fait bientôt 10 ans que j’ai laissé cela derrière moi.

Bouh la honte Olivier !

Certes.

Récemment, une mouche m’a piquée - ou une lubie - et je me suis renseigné sur les outils de lecture de flux RSS façon auto-hébergés et minimalistes. Je ne vais pas détailler la liste dans cet article puisque, vous l’aurez compris, on parle déjà dans le titre de Yarr !

Ainsi nous commencerons par présenter l’outil, pour ensuite décrire comment l’utiliser avec docker-compose pour finalement terminer par mon retour d’expérience après quelques jours d’utilisation (démarrage au 25 février 2026) et via un tour complet de l’outil - ça va être long mais il y a des images 😉 .

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

Découverte de Yarr

Avant de découvrir : on cherche ! J’ai donc établi une petite liste de critères pour la recherche d’un lecteur de flux RSS :

simple, voire basique,
avec une interface Web,
auto-hébergeable,
Open Source,
rapide,
léger,
sans forcément une base de données de type MySQL ou PostgreSQL. SQLite acceptable,
écrit, éventuellement, en Go (j’envisage d’apprendre prochainement le Go).

J’ai donc cherché. J’ai trouvé quelques outils comme :

Miniflux (en Go),
FreshRSS (en PHP),
LeedRSS (en PHP),
feedpushr (en Go),
et Yarr (en Go).

Je l’ai déjà annoncé : nous n’irons pas plus loin avec cette liste.

Nul besoin de faire la promotion de Yarr, je pense qu’Internet fait déjà de belles suggestions d’utilisation de Yarr comme remplaçant de TinyTinyRSS. Petite histoire marrante : le nom est l’acronyme de Yet Another Rss Reader, littéralement « Encore un autre lecteur RSS » ou « L’énième lecteur de flux RSS ».

Une fois cette lecture de blog effectuée, j’ai voulu tester Yarr. Je me suis donc lancé dans l’écriture d’un fichier docker-compose.yml.

Mon fichier docker-compose.yaml pour Yarr

Il aura fallu moins de 20 minutes pour trouver l’image Docker de Yarr sur le dépôt officiel de Yarr sur Github. Cependant l’image étant sur Github Actions - que je connais peu - j’ai eu plus de mal à trouver le nom donné à l’image pour la récupérer depuis Docker. Je vous le donne de suite : ghcr.io/nkanaev/yarr:v2.5.

Une fois le nom de l’image obtenu, il reste à en connaître son usage. Heureusement j’ai trouvé un article sur la création d’un fichier docker-compose.yaml pour Yarr (Cf. https://awesome-docker-compose.com/apps/rss/yarr) dont je me suis, forcément, grandement inspiré. Et oui je le dis quand j’utilise quelque chose qui n’est pas de moi 😉 .

Ainsi j’ai pu construire le fichier docker-compose.yaml suivant :

services:
  yarr:
    image: ghcr.io/nkanaev/yarr:v2.5
    container_name: yarr
    restart: always
    ports:
      - 7070
    volumes:
      - ${DATA_DIR:-./data}:/data
    command:
      - --addr=0.0.0.0:7070
      - --db=/data/yarr.db
      - --auth=${Y_USER}:${PASSWORD}
    environment:
      - TZ=Europe/Paris
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.${SERVICE}.rule=Host(`$DOMAIN_URL`)"
      - "traefik.http.routers.${SERVICE}.entrypoints=websecure"

où :

DATA_DIR, Y_USER, PASSWORD, SERVICE et DOMAIN_URL sont à renseigner dans un fichier .env (avec une valeur),
DATA_DIR est le chemin vers le point de montage où seront stockées les données de Yarr,
Y_USER est le nom d’utilisateur que vous souhaitez utiliser comme login pour s’identifier sur votre Yarr,
PASSWORD… bah le mot de passe pour s’identifier au service Yarr,
SERVICE est un nom (en minuscule, sans espace et sans point) pour le routeur dans Træfik (si vous n’utilisez pas Træfik, supprimez la section “labels” de ce docker-compose.yaml),
DOMAIN_URL est l’adresse web pour accéder au service, mais seulement si vous utilisez Træfik en frontal. Sinon supprimez la section “labels” de ce fichier docker-compose.yaml.

Exemple de fichier .env :

SERVICE=monService
DOMAIN_URL=domain.tld
DATA_DIR=/srv/http/yarr_data
Y_USER=olivier
PASSWORD=mot2passe

Vous noterez qu’on autorise volontairement toutes les IP pour accéder au service (0.0.0.0). Ce dernier s’ouvrira sur le port 7070 dans le conteneur, mais Docker choisira un port aléatoire sur ce service (pour éviter de demander un port déjà utilisé). Nous en parlerons ci-après avec la commande docker compose port.

Une fois le fichier .env configuré, on lance et accède rapidement au service (pour tester par exemple) :

# Lance le service en arrière plan - récupération de la main sur l'invite de commande
docker compose up -d
# Affiche les conteneurs lancés
docker compose ps
# Affiche l'adresse pour accéder au service en local
docker compose port yarr 7070

On lance un navigateur, on tape l’adresse retournée par la dernière commande (chez moi 0.0.0.0:32768) et le lecteur de flux RSS apparaît. C’est parti pour une période d’essai de plusieurs jours (tests commencés à partir du 25 février 2026).

Mon expérience avec Yarr - on fait le tour !

L’authentification

Dans le fichier docker-compose.yml précédent nous avons ajouté l’option --auth afin d’activer l’authentification de Yarr. La première page sur laquelle nous tombons est donc celle pour s’identifier :

Simple, efficace.

L’interface générale

L’accueil est plutôt austère - chouette c’est ce que je voulais ! - et propose une disposition en 3 colonnes :

Chaque colonne sert un objectif précis, de gauche à droite :

la liste des flux RSS,
puis la liste des articles/éléments d’un flux en particulier,
puis l’article choisi parmi la liste précédente.

Donc plus on se dirige à droite, plus la lecture se précise.

Sur téléphone mobile il n’y aura plus qu’une seule colonne : celle tout à gauche. On choisira ainsi un flux, ce qui affichera la liste des articles et si on choisit un article, on verra son contenu. Toujours sur une colonne. Astucieux, logique et presque intuitif.

J’avoue que sur ce dernier point, sur téléphone mobile, j’ai été totalement perdu : je ne savais pas où j’étais et ce que je faisais. Ce n’est qu’en comparant l’usage entre un grand écran et un petit écran que j’ai saisi ce qu’il en était. Sur ce coup-là, je suis le couteau le moins aiguisé du tiroir…

La configuration de l’interface

Je continue ma découverte avec l’icône représentant 3 petits points en haut à droite de la première colonne (ou en haut à droite sur un petit écran ne présentant donc qu’une seule colonne). Les options de l’outil apparaissent :

C’est ici que va se jouer les seules options disponibles dans Yarr :

New Feed : Permet d’ajouter un nouveau flux. Il faut 2 infos : l’adresse URL du flux, et le dossier dans lequel le ranger,
Refresh Feeds : Actualisation des flux,
Theme : Pour changer l’apparence de Yarr. Nous en parlerons tout à l’heure,
Auto Refresh : Permet de choisir le laps de temps entre plusieurs rafraîchissements automatiques. Comprendre : on récupère les flux tous les X temps (de 0mn à 4h),
Show first : Permet de choisir si on préfère afficher les articles parus récemment en premier (New) ou ceux les plus anciens en premier (Old),
Subscriptions :
- Import : Donne la possibilité d’importer une liste de flux (au format OPML),
- Export : Permet d’exporter sa liste de flux (au format OPML) pour la partager par exemple,
- Shortcuts : Affiche un rappel des raccourcis claviers possibles pour naviguer et lire les flux. Et ils sont très utiles,
- Log out : Apparaîtra seulement si l’option --auth a été utilisée. C’est pour se déconnecter.

J’avais peur de tomber sur un lecteur avec des milliers de configurations. Finalement Yarr va à l’essentiel. Cela me plaît - encore une fois.

Choix d’un thème

Vous aurez remarqué que mes impressions écrans présentent les pages d’une couleur simili jaune (qui fait penser à Solarized Light d’Ethan Shoonover). C’est parce que j’ai choisi un thème. On peut choisir entre 3 thèmes :

blanc,
jaune,
noir.

Je suis content du thème jaune car ma vue pose problème avec les thèmes noirs (l’astigmathie a une forme d’opposition rebelle au “dark theme” et peut rendre les textes “flous”). Certes, la performance de lecture est plus importante en mode “light”, mais ça reste trop lumineux pour moi. Je n’aime pas le jaune en tant que tel, mais pour mon efficacité de lecture c’est le “moins pire” 🤣 . Évidemment les tendances s’inversent la nuit (mais pas pour moi), dans la pénombre et/ou dans un environnement peu lumineux. Mais nous ne sommes pas ici pour lancer le troll « Dark Mode vs. Light Mode », ou bien ? Combat !

Les trois icônes principales

Vous avez découvert l’usage en 3 colonnes, cette fois nous allons découvrir l’usage des 3 icônes tout en haut qui sont, en quelque sorte, le menu principal de Yarr :

un rond rempli de noir,
une étoile,
3 traits horizontaux parallèles de longueurs différentes.

La première (le rond noir) permet d’afficher la liste des flux sur lesquels nous avons encore des articles/éléments à lire.

La seconde (étoile noire) affiche une liste des flux sur lequels vous avez marqués des articles/éléments comme favoris.

Et la dernière (les 3 traits horizontaux) affiche la liste complète des flux, qu’importe qu’il vous reste ou non des articles/éléments à lire.

Exemple d’affichage en 3 colonnes sur le rond noir avec le choix d’un article et son affichage :

Simple, basique, sans fioritures. Utilisable avec des raccourcis clavier. Parfait !

Les derniers petits détails - et après j’arrête promis !

Dernière liste d’icônes dans l’interface :

deuxième colonne :
- icône de loupe : Fait une recherche dans la liste d’article de CE flux choisi,
- icône de validation : Marque tous les articles de ce flux comme lus,
- icône de 3 petits points l’un à côté de l’autre verticalement : c’est ici qu’on a les détails du flux. On peut le renommer, le changer de place, le supprimer, aller sur le site Web, etc.,
troisième colonne :
- icône d’étoile (vide/remplie) : Marque l’article en favori ou au contraire l’enlève des favoris,
- icône d’un rond (vide/rempli) : Marque l’article comme lu ou non-lu (suivant de quel état on commence),
- icône de traits verticaux entrecoupés comme de petits pistons : Permet de changer la police d’écriture (parmi sans-serif, serif et monospace) ainsi que la taille de police (petit, ou grand, plus on appuie plus ça réduit/aggrandit),
- icône d’un livre ouvert : Choisi de lire l’article dans Yarr ou bien seulement les informations du flux RSS,
- icône d’un carré avec une flèche qui en sort) : Va directement sur le site Web de l’article en question.

J’utilise souvent l’icône de validation de la seconde colonne pour marquer tous les articles comme lus une fois que j’ai parcouru la liste des titres et que rien ne m’intéressait.

Les raccourcis claviers sont là pour faciliter le traitement des articles (lu, non-lu, favori, lire à l’extérieur, etc.). Parfois j’utilise le raccourci “o” pour lire l’article sur le site Web.

Du reste, je n’utilise quasiment rien. Après tout je ne viens que pour lire des titres, trier et lire un article de temps en temps 🤷 . Je ne suis pas là pour bosser.

Conclusion

Au début un peu perdu par l’interface afin de comprendre à quoi sert chaque élément - surtout entre interface petit écran et grand écran - j’ai finalement apprécié Yarr à l’usage.

C’est un outil “menu” (maigre, léger), simple, basique, sans fioritures. Configurable un minimum. Utilisable avec des raccourcis clavier. Très efficace d’ailleurs avec un clavier quand on s’y fait. C’est même redoutable de rapidité quand on a le coup de main !

À vrai dire, je ne sais même pas de quoi j’aurais besoin en plus pour lire des flux. J’ajoute rapidement des flux, j’importe et exporte facilement pour partager avec d’autres, je vois de nouveaux articles, je clique sur ce qui m’intéresse, je lis, je note le reste des articles comme lus pour ce flux et voilà.

Ni plus. Ni moins. Parfait 😄 .

Liens utiles

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

RustFS, alternative au service de stockage objet MinIO

Sun, 15 Feb 2026 17:27:26 +0100

Quand on étudie Kubernetes, on arrive tôt ou tard sur la question de la gestion des sauvegardes. Et avec elles le sujet du stockage de ces dernières. La référence en matière de sauvegarde - dont je parlerais sûrement dans un prochain article - est Velero. Cet outil supporte plusieurs fournisseurs de stockage pour ses opérations de sauvegarde comme Amazon Web Services, Google Cloud, Microsoft Azure ou VMware Sphere. Principalement des fournisseurs liés à une entreprise. Que faire dans la situation où nous souhaitons auto-héberger une solution de stockage chez soi ?

C’est ce dont je voudrais parler aujourd’hui : une solution spécifique que j’ai - presque - choisie. Surtout pourquoi cette solution ? Je décrirais son installation sous Docker Compose derrière un proxy nommé Traefik, dont je vous ai déjà parlé. Et j’ajouterais quelques mots sur les ports réseau à ouvrir, l’initialisation des premiers « buckets » (nous y reviendrons) et l’usage de noms de domaines.

Pourquoi cette solution ?

Si vous n’êtes pas fan de l’histoire de « pourquoi choisir cette solution », vous pouvez passer au chapitre suivant, je ne vous en voudrais pas 😉.

En étudiant la documentation de Velero on découvre parmi les fournisseurs de solutions de stockage le célèbre Amazon Web Services. Et avec lui le service Amazon S3. Ce service est une solution de stockage objet qui a développé un protocole ouvert du même nom : S3. Grâce à cela, de nombreux outils compatibles avec ce protocole ont vu le jour ; que ce soit des clients comme des serveurs. Top, c’est ce que je recherche !

Ayant beaucoup entendu parler de MinIO, je m’enquiers de l’installer fin novembre 2025. En Docker Compose, derrière Traefik comme je l’explique dans un précédent article sur le sujet. Mais quelques problèmes se posent successivement :

en août 2025 les dépôts de Bitnami, qui fournissaient jusqu’alors d’excellentes images, chartes Helm et outils en tous genres sont chamboulés par une décision drastique prise par Bitnami. L’impact est énorme sur la communauté,
faute de cette image pratique, je me tourne vers l’image officielle qui demande des ajustements pour avoir des « buckets » à l’initialisation,
finalement le 13 février 2026, l’entreprise qui gérait MinIO décide d’abandonner la maintenance de la version communautaire.

Coup dur. Je recherche des alternatives. Je tombe sur le message de loverustfs qui compare les solutions alternatives à RustFS, dont MinIO, Garage, Ceph, Seaweeedfs, etc..

Edit (24 fév. 2026) : Un fork de MinIO est apparu il y a quelques jours. Si le cœur vous en dit 🤷.

RustFS n’est probablement pas la solution la plus performante (Seaweedfs semble plus performant), mais il se défend bien. Et il semble proche de MinIO en terme d’interface et d’utilisation. Allons donc, ne le faisons pas attendre, installons-le !

RustFS sous Docker Compose

L’idée est d’installer/utiliser RustFS avec Docker Compose. Derrière Træfik. Avec des domaines.

Installation minimale

On commence par une installation de base. On a besoin de :

une image Docker. Ça tombe bien, il y a des images officielles de RustFS sur le Hub Docker,
ouvrir 2 ports :
- 9000,
- 9001,
un volume local pour stocker les données et pouvoir les réutiliser entre 2 redémarrages de conteneurs,
un identifiant et un mot de passe initial.

ATTENTION : le projet RustFS est encore jeune, il est en développement actif et les versions ne sont pas toutes utilisables telles quelles. Par exemple dans ma situation, la version 1.0.0-alpha.83 était inutilisable. Ceci dû à un bug sur l’architecture de ma machine comme le montre ce ticket Github.

Une première ébauche d’un fichier docker-compose.yaml pourrait s’écrire de la manière suivante :

services:
  rustfs:
    image: rustfs/rustfs:1.0.0-alpha.82
    restart: always
    ports:
      - 9000
      - 9001
    volumes:
      - ./storage_data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      - RUSTFS_ACCESS_KEY=olivier
      - RUSTFS_SECRET_KEY=mot2passe
      - RUSTFS_OBS_LOGGER_LEVEL=info
    healthcheck:
      test:
        [
          "CMD",
          "sh", "-c",
          "curl -f http://127.0.0.1:9000/health && curl -f http://127.0.0.1:9001/rustfs/console/health"
        ]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Veillez à changer les éléments suivants - au minimum :

./storage_data dans la section volumes. Renseigner par un dossier dans lequel vous voulez stocker les données,
RUSTFS_ACCESS_KEY dans la section environment. Changez olivier par un identifiant que vous souhaitez utiliser,
RUSTFS_SECRET_KEY dans la section environment. Changez la valeur mot2passe par quelque chose de bien plus long et bien plus compliqué que cela (une clé secrète en somme).

De cette façon, le service va se lancer avec des ports choisis par Docker Compose. Vous pouvez les connaître en tapant les commandes suivantes :

docker compose port rustfs 9000
docker compose port rustfs 9001

On constate sur l’interface (port initial 9001), après s’être authentifié avec l’identifiant et la clé secrète, qu’il n’y aucun bucket.

Initialisation des buckets

Qu’est un bucket ?

C’est un espace qui regroupe plusieurs objets qu’on aurait déposé à cet endroit. Cela permet de se repérer plus facilement dans un espace de stockage objet.

Afin de créer un bucket, soit on utilise l’interface (méthode manuelle), soit on créé un conteneur d’initialisation qui fera le job à notre place (automatique).

J’opte pour le conteneur d’initialisation pour créer 3 buckets. Dans notre fichier docker-compose.yaml on ajoute les lignes suivantes :

  init_buckets:
    image: minio/mc:RELEASE.2025-08-13T08-35-41Z
    depends_on:
      - rustfs
    restart: on-failure
    entrypoint: >
      /bin/sh -c "
      sleep 5;
      /usr/bin/mc alias set s3server http://rustfs:9000 \"olivier\" \"mot2passe\";
      /usr/bin/mc mb s3server/default;
      /usr/bin/mc mb s3server/bucket1;
      /usr/bin/mc mb s3server/bucket2;
      exit 0;
      "

Pensez à changer olivier et mot2passe par les mêmes identifiants/mot de passe que renseignés dans le service rustfs du docker-compose.yaml précédent.

L’astuce est donc d’utiliser le client mc de MinIO pour ajouter les buckets qu’on souhaiterait. Dans l’exemple présenté ci-avant, le conteneur d’initialisation permet de créer 3 buckets :

default,
bucket1,
bucket2.

Libre à vous d’adapter ce conteneur pour répondre à vos besoins en matière de création initiale de bucket.

Il ne reste alors plus que la mise à disposition sur Internet via l’usage de sous-domaines et de Træfik.

Configurer les labels pour Træfik

Træfik est un proxy souvent utilisé avec Docker Compose pour se charger des routes. L’idée de Træfik est d’utiliser le champ labels pour récupérer des instructions utiles à la création des routes en lien avec les domaines.

Pour RustFS sous Docker Compose, et avec Træfik en frontal, je suggère les labels suivants :

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api-rustfs.rule=Host(`api.mondomaine.tld`)"
      - "traefik.http.routers.api-rustfs.entrypoints=websecure"
      - "traefik.http.routers.api-rustfs.service=api-rustfs"
      - "traefik.http.services.api-rustfs.loadbalancer.server.port=9000"
      - "traefik.http.routers.rustfs.rule=Host(`mondomaine.tld`)"
      - "traefik.http.routers.rustfs.entrypoints=websecure"
      - "traefik.http.routers.rustfs.service=rustfs"
      - "traefik.http.services.rustfs.loadbalancer.server.port=9001"

Prenez soin de changer les éléments suivants :

websecure par le nom de votre routeur permettant d’avoir du HTTPS,
api.mondomaine.tld par le domaine de votre choix pour accéder à l’API de RustFS,
mondomaine.tld par le domaine utilisé pour accéder à l’interface Web de RustFS.

Évidemment tout un tas d’autres options sont possibles, il suffit de lire la documentation de Træfik pour cela.

Résultat final complet

Ce qui nous donne :

services:
  rustfs:
    image: rustfs/rustfs:1.0.0-alpha.82
    restart: always
    ports:
      - 9000
      - 9001
    volumes:
      - ./storage_data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      - RUSTFS_ACCESS_KEY=olivier
      - RUSTFS_SECRET_KEY=mot2passe
      - RUSTFS_OBS_LOGGER_LEVEL=info
    healthcheck:
      test:
        [
          "CMD",
          "sh", "-c",
          "curl -f http://127.0.0.1:9000/health && curl -f http://127.0.0.1:9001/rustfs/console/health"
        ]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api-rustfs.rule=Host(`api.mondomaine.tld`)"
      - "traefik.http.routers.api-rustfs.entrypoints=websecure"
      - "traefik.http.routers.api-rustfs.service=api-rustfs"
      - "traefik.http.services.api-rustfs.loadbalancer.server.port=9000"
      - "traefik.http.routers.rustfs.rule=Host(`mondomaine.tld`)"
      - "traefik.http.routers.rustfs.entrypoints=websecure"
      - "traefik.http.routers.rustfs.service=rustfs"
      - "traefik.http.services.rustfs.loadbalancer.server.port=9001"

  init_buckets:
    image: minio/mc:RELEASE.2025-08-13T08-35-41Z
    depends_on:
      - rustfs
    restart: on-failure
    entrypoint: >
      /bin/sh -c "
      sleep 5;
      /usr/bin/mc alias set s3server http://rustfs:9000 \"olivier\" \"mot2passe\";
      /usr/bin/mc mb s3server/default;
      /usr/bin/mc mb s3server/bucket1;
      /usr/bin/mc mb s3server/bucket2;
      exit 0;
      "

Avec ce contenu vous devriez pouvoir démarrer une instance RustFS sans problème 😉.

Quelle aventure !

Au bout du compte, avoir cherché à lancer un service de stockage objet a été une sacrée odyssée pour moi. Beaucoup d’aléas liés au changement de politique de Bitnami (pour les images MinIO), à l’arrêt de maintenance du code du serveur MinIO par AIStor et aux effets de bord de RustFS en plein développement.

Mes besoins spécifiques en terme d’infrastructure (Docker Compose et Træfik) m’ont amené à devoir retravailler plusieurs fois le fichier docker-compose.yaml. Et j’ai essuyé quelques plâtres avant d’avoir une instance fonctionnelle.

Je suis ainsi content de partager ce fichier docker-compose.yaml. Bien qu’il y a matière à faire évoluer ce fichier. On peut imaginer améliorer ce fichier en utilisant des variables pour le dossier où seront stockées les données, le nom du service, le domaine et bien évidemment l’identifiant et le mot de passe du service RustFS. Et déposer les valeurs dans un fichier .env.

On pourrait également trouver un autre client que mc pour initialiser les buckets au départ. Voire trouver un autre outil permettant de créer les buckets plus facilement. Imaginons une nouvelle image Docker ayant un script d’initialisation avec des variables d’environnement le permettant.

Je laisse votre imagination faire le reste 😊.

Sources utilisées pour la mise en place de RustFS

Liens utiles

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 ?

Mes conseils pour réussir une formation Bootcamp

Sun, 13 Oct 2024 10:14:59 +0200

Introduction

Il y a peu je commençais une formation chez DataScientest. En Bootcamp. Ce format est l’équivalent d’un temps complet (lundi à vendredi de 8h à 18h) passé sur le contenu du programme pédagogique. Durée prévue dans ma situation : 3 mois.

Ce temps est nécessaire pour apprendre les différentes notions. C’est à la fois long et court : c’est dense et le temps accordé est parfois « tout juste » pour lire. Alors comment tenir ce Marathon de 3 mois ?

J’aborderais dans un premier temps les éléments qui m’ont permis d’organiser mon plan de la semaine. Après quoi j’aborderais des sujets proches du contenu des cours comme les exercices et les examens. Finalement je donnerais des astuces diverses que j’ai listées au fur et à mesure de mon avancée dans l’aventure. Cette liste risque donc de s’allonger avec le temps !

À noter que ces conseils sont forcément emprunts de mon expérience de vie, mes compétences et mes particularités (la folie, ça compte ? 🤔)

Photo trouvée sur le profil de Aurélien Adoue sur Flickr sous Licence Attribution 2.0 Generic.

Organisation

1 mois que j’ai commencé la formation. Une durée prévue de 3 mois. Une vie à mener à côté. Des objectifs professionnels en lien avec le résultat de ce Bootcamp. Vous ne pouvez pas vous pointer les mains dans les poches.

Il est évident qu’il faut un plan. Tous les conseils pointent sur la même chose : il faut compartimenter son temps. Et s’y tenir ; oui s’y tenir. Faites-le suivant votre vie et vos possibilités. Mais tenez-y vous ! Et mettez au courant votre entourage de votre planning.

Mon planning

Dans mon cas, j’ai opté pour le planning suivant :

les matins du lundi au jeudi : lecture des nouveaux cours. Apprentissage et exercices, voire examens ;
les après-midi du lundi au jeudi : révision des cours lus les jours précédents (parfois semaines précédentes), sinon faire des exercices ;
le vendredi : mise en pratique des outils/notions appri(e)s(es) sur des projets personnels.

De cette manière la nouveauté arrive quand je suis frais, c’est à dire le matin.

Viens ensuite l’après-midi, après le repas, où je suis moins attentif que le matin. Idéal pour des révisions sur des sujets déjà abordés les jours précédents. Et cela fait une fin de journée plus tranquille que le matin.

Une révision passe par la rédaction de « fiches » de synthèse pour créer des récapitulatifs de ce qui a été vu. Parfois je dessine des cartes heuristiques : plus parlantes pour moi.

Pendant la lecture des cours je note des idées d’utilisation des outils découverts (en somme des projets qui germent dans ma tête). Ce qui me permet d’aborder le vendredi un projet réfléchi pendant la semaine. Exemple : à la lecture du contenu, j’ai noté qu’il y avait beaucoup d’abréviations. Par ailleurs, un des modules du cours apprend à utiliser un outil de création d’API. Quoi de mieux que de créer une API pour lister les abréviations ? Et hop!, un projet à faire le vendredi.

Autre exemple : on apprend le scripting Bash ? Quoi de mieux que de faire un outil pour automatiser l’installation de nos logiciels habituels sur les machines virtuelles fournies par le centre de formation ? Ou bien simplifier la vie en ajoutant des raccourcis (alias) Bash pour les commandes usuelles pendant les cours ?

On apprend la méthode ETL (Extract, Transform, Load) sur des API ? Utilisons notre API des abréviations pour extraire les données !

Que faire une fois les données extraites ? On a appris à utiliser - en bonus - SQLAlchemy (bibliothèque pour faire des requêtes sur une base de données), pourquoi ne pas l’utiliser pour insérer les données extraites de l’API pour les charger dans une base de données à nous ?

Mais en dehors de ces moments, que fais-tu Olivier ?

Hors planning

Si le planning existe, c’est pour une raison : il est nécessaire d’avoir une vie à côté ! Il faut du temps pour :

la famille (conjoint(e), enfants, parents, etc.),
des pauses,
avoir du temps à soi,
dormir,
manger,
etc.

Réellement, il FAUT ce temps pour votre famille et vous !

La famille apporte un entourage (indirectement ça peut être de la confiance en soi), les pauses un souffle pour votre cerveau, le temps à soi pour se retrouver, dormir pour ranger les informations dans votre cerveau et manger pour redonner de l’énergie à votre corps !

Chacun de ces éléments va permettre de franchir plus facilement les obstacles de votre parcours en Bootcamp. D’où le côté strict des horaires que vous vous donnez.

Ainsi après une matinée de lecture de nouveaux cours, vers midi, je m’arrête. Et je passe à autre chose : le repas, une pause et un repos allongé sur le dos pendant 10 mn environ. Avant de recommencer sur l’après-midi avec les révisions de la veille.

Après 17h ? Je m’arrête également. Je passe aux tâches quotidiennes, de la famille et du repas du soir. Un peu de détente. Un bon gros sommeil de plus de 8h.

Et la journée recommence.

Le week-end ? Pas de formation. La famille, les amis, du temps pour notre conjoint, pour soi, etc. On fait toutes ces choses qui donnent de l’énergie et remplissent notre cœur, notre corps et notre moral.

La partie organisation est très importante, elle va définir si vous aurez la tête sous l’eau ou pas. Prenez donc le temps de définir tout ça. Respectez votre planning et les personnes qui vous entourent. Par ailleurs, ce n’est qu’une seule clé parmi d’autres : pour que cela fonctionne il est nécessaire d’être efficace lors de sa période de travail. C’est ce que nous allons voir dans le prochain chapitre.

Travail efficace

Il n’y a pas de secrets selon moi, un travail efficace est déterminé par :

un environnement spécifique de travail,
une technique d’assimilation particulière,
et une façon d’agir durant les examens chronométrés.

Je vais donc vous parler de chacun des ces points en donnant quelques astuces issues d’études faites sur la question.

Point 1 : l’environnement de travail

À la lecture du livre Deep work, retrouver la concentration dans un monde de distractions écrit par Cal NEWPORT (un professeur dans les sciences informatiques du MIT - rien que ça!), j’ai bien compris qu’il fallait un environnement sans distractions.

Exit les téléphones mobiles : on le met sur mode avion. On s’enferme dans une pièce, à clé. On mobilise toutes nos ressources pour se concentrer sur la tâche à accomplir : apprendre les cours.

Toute perturbation est à proscrire et malheureusement pour certains : la musique en fait partie. Il semble que des études ont déterminé que cela activait des zones du cerveau qui empêchent une concentration complète.

L’idée du livre « Deep work » est que si vous êtes concentrés vous prendrez moins de temps à travailler. Ce qui me semble tout à fait adapté pour une formation en Bootcamp, n’est-ce pas ?

Point 2 : assimiler les cours

Là encore, les scientifiques ont étudié la question. Et c’est au travers d’une vidéo de Science étonnante concernant les (vraies) techniques pour mieux apprendre et étudier que j’ai pu améliorer mon apprentissage.

Je vous conseille de regarder la vidéo - YouTube - et d’imaginer une nouvelle façon d’étudier, de réviser et de travailler.

De mon côté j’ai opté pour la relecture régulière, la lecture de plusieurs cours qui font souvent des liens sur le domaine étudié et la mise en pratique par des cas concrets de la vie courante pour s’entraîner avec les outils étudiés. J’en parlais tout à l’heure : la création d’une API, l’extraction des données de cette dernière pour les introduire ensuite dans une autre base de données sous un autre format.

À noter que plus loin dans cet article je vous demanderais de ne pas suivre de vidéos YouTube pendant vos études Bootcamp, je ne suis pas schizophrène : considérez cette vidéo comme l’exception qui confirme la règle 😃 .

Point 3 : les examens

Certains examens sont chronométrés. Ce qui peut très vite être déstabilisant !

Je propose plusieurs choses pour s’en sortir :

Rien de mieux que la préparation : si vous avez fait les cours régulièrement et que vous avez révisé 1 jour après, 2 jours après, 1 semaine après, vous retiendrez bien mieux les cours ;
Faites des exercices avant et sentez-vous un minimum à l’aise, travaillez les points sensibles ;
Lors des examens : ouvrez en avance les documentations qui vous aident ;
Dans les examens, optez pour des noms de variables courts : plus vous rallongez le nom des fonctions et des variables, plus vous aurez à taper du code. Indirectement vous prenez un temps fou pour rédiger au lieu de réfléchir !
Pour les examens, préparez déjà à côté vos codes sur le sujet : c’est votre code, celui qui vous ressemble. Rien n’interdit un copier-coller de votre propre travail !

Avec ces 3 points, vous devriez déjà avoir de bonnes bases pour aborder la formation. Il y a d’autres astuces diverses que nous allons découvrir maintenant.

Diverses astuces

Ne sachant dans quelles catégories mettre ces astuces, mais considérant ces dernières comme tout aussi importantes, je vous les dépose là. Piochez selon vos envies ;)

Revoyez chaque semaine le planning que vous allez suivre : quel cours étudier chaque jour. Prenez en compte les sujets sur lesquels vous avez déjà des connaissances pour passer plus de temps sur ceux que vous ne connaissez pas ;
Ne prenez des notes qu’à une seconde lecture (lors de révisions par exemple) : sinon vous allez passer trop de temps sur un cours ;
Si vous avez un souci logiciel qui empêche de travailler : passez à autre chose !
Quand vous revenez sur un souci logiciel - plus tard - si vous ne réussisez pas mieux, utilisez ChatGPT pour décrire votre problème. Cet outil est plutôt efficace pour donner des pistes. Rappelez vous, ChatGPT est un assistant, vous le dirigez. Ce n’est pas lui qui doit vous diriger. ;
N’utilisez pas de vidéos pour apprendre - YouTube ou autre - c’est une perte de temps considérable. Pourquoi ? Tout simplement car vous ne pourrez pas voir rapidement si la vidéo vous apporte quelque chose de concret ou non. Et parfois ce qu’ils disent est tout bonnement faux ! Cela vous apporte plus de confusion qu’autre chose. En revanche chez DataScientest ils ont des vidéos de cours. Cela apporte généralement quelque chose de concret et de vrai ;
Lisez de la documentation des outils utilisés : elles ne mentent pas. Elles décrivent. Et peut-être retiendrez-vous des options qui vous feront gagner plus tard un temps fou !
Restez humbles : même si vous maîtrisez un sujet, vous trouverez souvent des nouveautés et des détails que vous ne connaissiez pas dans les cours ;
Si vous avez la possibilité, apprenez à utiliser des dépôts Git rapidement pour enregistrer votre travail sur les machines virtuelles distantes proposées par la formation. Cela vous évitera de mauvaises surprises quand les machines se réinitialisent…

Si jamais je trouve d’autres astuces je les rajouterai ici.

Conclusion

Cette formation m’a permis de travailler mon environnement, mes méthodes de travail et découvrir des astuces pour être plus efficace en journée. Et cela sans mettre de côté la famille et la maison. Ce qui donne de l’énergie pour continuer chaque semaine de travailler.

C’est un cercle vertueux que je conseille à chacun pour améliorer son quotidien et être plus productif.

Je souhaite de tout cœur que chacun trouve son équilibre dans sa vie et réussisse sa formation en Bootcamp. Bonne chance à vous et bon travail !

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.

Vers quelle console se tourner en 2024 ?

Wed, 10 Apr 2024 16:24:18 +0200

Introduction

Après plusieurs échanges similaires avec des amis, il était temps de lister ce que je trouve intéressant et/ou problématique dans chacune des 3 consoles suivantes :

Nintendo Switch (Switch)
Microsoft Xbox Serie X (Xbox)
Sony Playstation 5 Standard FAT (PS5)

Ceci est mon avis, cela représente ce que je pense sur ces dernières. Il reste à chacun de juger selon lui et suivant ses infos.

Je regarde essentiellement le coût de ces consoles et ce que nous avons à disposition. Si vous détestez voir des chiffres défiler, arrêtez la lecture de cet article 😉. Par ailleurs chaque console représente un écosystème entier, il est difficile d’être réellement objectif dans leur comparaison, tant ils sont différents.

Alerte spoiler : Cet article sera long.

Photo trouvée sur le profil de Aurélien Adoue sur Flickr sous licence CC BY 2.0.

Avant de commencer

Dans cet article je comparerais plusieurs éléments comme :

le prix d’achat de la console
l’abonnement pour bénéficier de sauvegardes de ses parties (et parfois l’accès à un catalogue de jeux)
la quantité de jeux disponibles (la variété du catalogue de jeux vidéos par exemple)
le prix des jeux d’occasion, ce qui permet d’estimer l’accès aux jeux pour les petits budgets
les problèmes matériels connus qui peuvent engendrer un rachat de la console ou bien des accessoires
le prix d’une manette

Je cherche plus ou moins à savoir ce qui pourrait - économiquement parlant - être plus accessible. Autrement dit sur quelle console pourrais-je estimer pouvoir dépenser le moins d’argent par an pour jouer et renouveler mon catalogue de jeux joués ? Évidemment les prix fluctuent beaucoup, notamment pour les consoles PS5 et Xbox qui varient parfois de 50€ à 100€. À vos calculatrices !

Nous commencerons avec la Nintendo Switch, puis la Microsoft Xbox Serie X et enfin la Sony Playstation 5 Standard FAT. Ce sont 3 consoles que j’ai eu en main, que j’ai pu tester et où j’ai pu expérimenter quelques éléments entre 2 et 5 ans (suivant les consoles).

J’insiste sur les modèles disposant d’un compartiment pour accueillir les jeux vidéos (lecteur DVD, slot pour des cartouches de jeu, etc.) car cela permet d’avoir accès à des jeux d’occasion (donc coûter moins que les jeux neufs).

Les 3 modèles visés/testés se branchent au minimum sur une télévision.

On part du principe qu’on joue environ 500 heures par an, c’est à dire environ 1h30 par jour. Si les jeux prennent une cinquantaine d’heures à finir, on consommerait 10 jeux par an. Tout ceci est relatif et doit bien être pris en compte dans vos calculs. C’est intéressant de faire le calcul pour soi, histoire de voir si le jeu vidéo est un loisir très dépensier dans VOTRE budget. Mine de rien, ça consomme de l’argent tout cela, comme nous le verrons ci-après !

Nintendo Switch

Les chiffres

Commençons par la plus ancienne console sur le marché : la Nintendo Switch.

Prix d’achat (sur Amazon) : ~ 250€
Prix abonnement annuel minimum : ~ 20€
Avantage abonnement : jeux NES, SNES et Gameboy (color) (~ 30 jeux)
Abonnement familial : ~ 35€
Manettes disponibles à l’achat : 2 (gauche et droite, même si petites)
Particularité : utilisable en console portable, prend peu de place (~ 3h30 d’autonomie)
Prix d’un jeu neuf : ~ 50€
Prix du même jeu en occasion : ~30 (varie en fonction des régions et de l’interlocuteur + capacité à discuter le prix)
Prix d’une manette (simple) : ~ 45€ à l’unité, ou ~ 65€ les deux

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

Avantage(s)

L’avantage principal de cette console : elle est aussi portable. C’est à dire qu’elle s’enlève du socle de la télévision pour être utilisable partout dans la maison (ou ailleurs). Sa batterie tient au moins 3h30.

Elle est relativement petite pour une console de salon, ce qui fait un gain de place.

Le catalogue des jeux est un des plus riches et des plus complets. Avec des jeux variés : il y en a pour tous les goûts ! Certaines exclusivités d’autres consoles sont portés sur la Nintendo Switch, ce qui est très plaisant.

Inconvénient(s)

Du fait de la « petitesse » de cette console, il y a une limitation sur le matériel embarqué, notamment pour ce qui est du refroidissement de la carte graphique. Ceci implique des graphismes moins proches de la réalité (comparé à d’autres consoles).

Cependant sachez qu’au lieu de se concentrer sur la parfaite illusion de réalité dans les jeux vidéos, les concepteurs de jeu peuvent s’atteler à la jouabilité.

Autre point négatif : le problème connu dit du « Joy-Con Drift ». Après un certain temps d’utilisation, il arrive que la manette gauche pose problème : le personnage que vous dirigez dans le jeu bouge tout seul. Bien que ce soit problématique, au lieu de racheter une manette il existe une solution « maison » tel que vous pouvez le lire dans l’article expliquant la solution avec… un bout de carton ! Cette solution ne fonctionnera pas avec une Nintendo Switch Lite dont les manettes ne sont pas détachables.

Au minimum (sans jeux)

1^ère année : 270€ (250€ HA + 20€ abonnement simple)
années suivantes : 20€ (20€ abonnement simple)

Au minimum (avec HA de jeux)

1^ère année : 770€ (250€ HA + 20€ abonnement simple + 10 jeux neufs × 50€)
années suivantes : 520€ (20€ abonnement simple + 10 jeux neufs × 50€)

Minimum familial

1^ère année : 785€ (250€ HA + 35€ abonnement familial + 10 jeux neufs × 50€)
années suivantes : 535€ (35€ abonnement familial + 10 jeux neufs × 50€)

Au maximum (familial + pack additionnel à 70€/an)

Avec le pack additionnel vous avez, en plus des jeux NES, SNES et GameBoy (color), un accès à :

des jeux GameBoy Advance
des jeux Nintendo 64
des jeux Mega Drive

Ainsi :

1^ère année : 320€ (250€HA + 70€ abonnement familial + pack additionnel)
années suivantes : 70€ (70€ abonnement familial + pack additionnel)

Conclusion intermédiaire - Switch

On notera :

la différence négligeable entre abonnement simple et familial : très rentable quand nous sommes plusieurs à la maison (même avec chacun une console)
le pack aditionnel (abonnement supplémentaire) permet de jouer à des jeux rétros mais pas avec des jeux modernes
le catalogue (Nintendo eShop) est large, varié, avec des réductions fréquentes de 80% sur de bons jeux
vous jouez sur la TV et quelqu’un de la famille voudrait regarder la TV ? Pas de souci : vous enlevez la console du socle et pouvez continuer votre partie ailleurs. Le côté portable de cette console est très pratique !

La Nintendo Switch est donc une console bas prix avec beaucoup de possibilités !

Microsoft Xbox Série X

Les chiffres

Prix d’achat (sur Amazon) : ~ 550€
Prix abonnement annuel minimum : ~ 84€ (7€ × 12 mois)
Avantage abonnement : petit catalogue de jeux (~ 25 jeux)
Abonnement familial : aucun
Manettes disponibles à l’achat : 1
Particularité : prend peu de place, même debout
Prix d’un jeu neuf : ~80€
Prix du même jeu en occasion : ~40 (varie en fonction des régions et de l’interlocuteur + capacité à discuter le prix)
Prix d’une manette : ~ 60€

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

Avantage(s)

console puissante, ce qui permet d’accéder à des images plus fines et proches de la réalité
esthétique de la console, tout en prenant peu de place ET passe inaperçue dans le salon (vous ne passerez pas pour un gosse en soirée 🤣).
tout repose sur l’abonnement au Game Pass : accès illimité pour 11€/mois à une quantité incroyable de jeux. Vous trouverez toujours votre bonheur.
accès dès le premier jour à des jeux dès leur sortie (Halo, Starfield, Sea of thieves, etc.)

Inconvénient(s)

le budget d’achat initial est conséquent (550€)
jeux neufs très chers
pour jouer en ligne : abonnement nécessaire (7€/mois minimum)

Au minimum (sans jeux)

1^ère année : 634€ (550€ HA + 84€ abonnement)
années suivantes : 84€ (84€ abonnement)

Au minimum (avec HA de jeux)

1^ère année : 1434€ (550€ HA + 84€ abonnement + 10 jeux neufs × 80€)
années suivantes : 884€ (84€ abonnement + 10 jeux neufs × 80€)

Au maximum (abonnement Game Pass Console à 11€/mois)

Avec l’achat d’un abonnement - complet - donnant accès à un catalogue de plus de 100 jeux vidéos, soit 11€ × 12 mois = 132€. Ceci enlève le besoin d’avoir 10 jeux neufs par an…

1^ère année : 682€ (550€ HA + 132€ abonnement Game Pass Console)
années suivantes : 132€ (132€ abonnement Game Pass Console)

Conclusion intermédiaire - Xbox X

Le catalogue de jeux vidéos du Game Pass Console (à 11€/mois) donne non seulement accès à beaucoup de jeux vidéos, mais il permet en plus d’accéder à la plupart des sorties de jeux vidéos dès le premier jour !

C’est ce qui fait toute la force de cette console : tant que le Game Pass Console existe, l’accès à des jeux vidéos coûte 132€ par an - excepté toute modification du prix évidemment.

Si vous consommez plus de 2 jeux par an, la Xbox Serie X sera très rentable dès les premières années.

En revanche, je trouve que sans l’abonnement Game Pass Console (11€/mois), la console est coûteuse. Cela revient à acheter une brique de 550€ à poser dans le salon sans jamais y toucher, avec des jeux horriblement chers.

Sony Playstation 5 FAT

Les chiffres

Prix d’achat (sur Amazon) : ~ 525€
Prix abonnement annuel minimum : ~ 72€
Avantage abonnement : 3 jeux par mois (~ 36 jeux sur l’année)
Abonnement familial : aucun
Manettes disponibles à l’achat : 1
Particularité : très puissante pour les graphismes
Prix d’un jeu neuf : ~80€
Prix du même jeu en occasion : ~40 (varie en fonction des régions et de l’interlocuteur + capacité à discuter le prix)
Prix d’une manette : ~ 70€

À noter : Le prix d’une Playstation 5 SLIM est quasi similaire (525€).

Avantage(s)

console puissante, ce qui permet d’accéder à des images plus fines et proches de la réalité
la plupart des jeux PS4 fonctionnent sur cette console avec une amélioration graphique
rapidité de chargement des niveaux, grâce à un disque dur SSD embarqué

Inconvénient(s)

le budget d’achat initial est conséquent (525€)
jeux neufs très chers
pour jouer en ligne : abonnement nécessaire (6€/mois minimum)
le DualSense Drift de la manette de PS5 qui réduit la durée de vie d’une manette à 417h, soit environ 7 mois d’utilisation (à raison de 2h par jour) - sans possibilité de réparation pour le moment
un potentiel problème de liquide de refroidissment sur la PS5 ? sur une petite partie des consoles
prend une place monstrueuse au salon

Au minimum (sans jeux)

1^ère année : 597€ (525€ HA + 72€ abonnement)
années suivantes : 72€ (72€ abonnement)

Au minimum (avec HA de jeux)

1^ère année : 1397€ (525€ HA + 72€ abonnement + 10 jeux neufs × 80€)
années suivantes : 872€ (72€ abonnement + 10 jeux neufs × 80€)

Au maximum (abonnement Premium à ~152€/an)

L’abonnement Premium donne accès à un bon catalogue de jeux vidéos. Cependant vous n’aurez pas accès aux sorties des jeux vidéos : il faudra patienter quelques années à chaque fois.

1^ère année : 677€ (525€ HA + 152€ abonnement Premium)
années suivantes : 152€ (152€ abonnement Premium)

Conclusion intermédiaire - PS5

Se tourner vers cette console paraît curieux, à moins que vous n’êtes un grand fan de Playstation - comme je l’ai été de la PS1 à la PS4 - et que vous appréciez à la fois la qualité d’image et des jeux en exclusivité sur cette console.

En effet, malgré la qualité des jeux vidéos (souvent à 1 seul joueur), ces jeux ont un prix élevé. On se tournerait alors vers l’abonnement premium (152€/an) qui est « rentable » si vous consommez plus de 2 jeux par an.

Cependant l’abonnement Premium ne permet pas d’accéder régulièrement à des nouveautés (comprendre des jeux qui viennent de sortir), il y a une forme de patience à avoir.

Si vous achetez 1 jeu neuf et l’abonnement pour jouer en ligne, cela vous revient au prix de l’abonnement Premium.

Au final il bien trop d’inconvénients à cette console pour si peu d’avantages comparé à la concurrence : que se passe-t-il chez Sony ? 🤔

Récapitulatif des chiffres

	Switch	Switch OLED	Switch Lite	Xbox S	Xbox X	PS5 FAT	PS5 Slim	PS5 Digital Slim
Achat	250 €	300 €	200 €	300 €	550 €	525 €	550 €	450 €
Abonnement	20 €	20 €	20 €	84 €	84 €	72 €	72 €	72 €
Abo. Familial (switch)	35 €	35 €	35 €	Aucun	Aucun	Aucun	Aucun	Aucun
Game Pass Console (xbox)	Aucun	Aucun	Aucun	132 €	132 €	Aucun	Aucun	Aucun
Abo. Premium (PS5)	Aucun	Aucun	Aucun	Aucun	Aucun	152 €	152 €	152 €
Jeu neuf	50 €	50 €	50 €	80 €	80 €	80 €	80 €	80 €
Jeu occasion	30 €	30 €	30 €	40 €	40 €	40 €	40 €	40 €
Manette	45 €	45 €	45 €	60 €	60 €	70 €	70 €	70 €
Totaux :
1^ère année (HA + abo)	270 €	320 €	220 €	384 €	634 €	597 €	622 €	522 €
Nbre jeux rentabilité (Abo)	0,4	0,4	0,4	1,05	1,05	0,9	0,9	0,9
1^ère année (HA + abo. Prem/Fam/Console)	285 €	335 €	235 €	432 €	682 €	677 €	702 €	602 €
Nbre jeux rentabilité (HA + abo. Prem/Fam/Console)	0,7	0,7	0,7	1,65	1,65	1,9	1,9	1,9
Si budget de 700€ :
Nbre jeux neufs rentabilité (Abo)	8,60	7,60	9,60	3,95	0,83	1,29	0,98	2,23
Nbre jeux neufs rentabilité (Abo. Prem/Fam/Console)	8,30	7,30	9,30	3,35	0,23	0,29	-0,03	1,23

2 possibilités la première année :

achat de la console et abonnement simple (HA + abo),
ou achat de la console avec l’abonnement « intéressant » : Premium pour PS5, Familial pour Switch et Game Pass Console pour Xbox (HA + abo. Prem/Fam/Console).

Ensuite, pour chacune des possibilités nous calculons le nombre de jeux gratuits à consommer sur l’abonnement pour arriver à rentabilité ; en comparaison au prix de jeux neufs donc. Le calcul est : prix de l’abonnement à l’année divisé par le prix d’un jeu neuf.

Finalement les deux dernières lignes calculent le nombre de jeux neufs qu’on peut acheter ((700 - prix HA - abonnement choisi) ÷ prix jeu neuf) si on avait un budget initial de 700€. Et cela dans deux situations :

avec un abonnement simple,
avec un abonnement premium/familial/console tel qu’évoqué ci-avant.

Notez que si le chiffre est négatif alors il faudra ajouter un peu d’argent pour acheter un jeu.

Conclusion

Après avoir traité chaque console en étudiant son prix, les abonnements possibles, ce à quoi nous avons accès, les problèmes matériels éventuels et le prix des jeux neufs et d’occasion, je pense qu’on peut imaginer quelques types de public pour chacune des consoles.

À mon sens les petits budgets se tourneront vers la Nintendo Switch pour 270€ (HA console + abonnement simple), ce qui permettra d’accéder à des jeux NES, SNES et GameBoyColor, le temps de regarder sur l’eShop (magasin virtuel) pour acheter des jeux à bas prix (soit à plus de 80% de réduction, soit pour petits budgets), il y a même des jeux gratuits comme des courses de voiture, des combats de Pokémon, etc. C’est une bonne entrée en matière avec une souplesse « console de salon » vs. « portable ».

Si, pour vous, la qualité d’image doit se rapprocher de la réalité dans les jeux vidéos, sachez qu’on passe du simple au double avec la Xbox Serie X et la PS5 FAT aux alentours de 500€. À ce prix là, il faut tout de même prendre un abonnement pour les jeux en ligne, pour une copie des sauvegardes des jeux, etc. Et là on douille : c’est plus de 70€ par an (soit quasiment le prix d’un jeu). Vu le prix des jeux sous ces consoles, il est clair que pour 132€/mois avec le Game Pass Console, c’est rentable en moins de 2 jeux par an ET avec un catalogue de plus de 100 jeux ET des nouveautés. C’est donc la Xbox Serie X avec abonnement Game Pass Console que vous devriez vous tourner.

Malheureusement la PS5, avec ses problèmes de manettes, un abonnement qui ne donne accès qu’à peu de jeux, va être plus coûteuse sur le long terme. Deux raisons pourraient justifier, selon moi, l’achat et l’utilisation de la console :

accéder à des jeux en exclusivité sous PS5 (comme God of War, Horizon Forbidden West, Kena : bridge of spirit, Ratchet & Clank, etc.). Mais là encore les jeux deviennent disponibles sur PC généralement (plateforme Steam par exemple)
améliorer les performances de nos jeux PS4 et passer à une console plus moderne

Au final je ne conseillerais que 2 consoles (suivant les budgets) - alors que je suis pourtant un grand fan des consoles Sony :

la Nintendo Switch pour les petits budgets et une utilisation plutôt familiale (jeux à plusieurs, jeux « good vibes » simples, etc.), elle permet l’accès à des jeux rétros Nintendo (NES, SNES, GameCube, Mega Drive, Nintendo 64, etc.),
la Xbox Série X pour des budgets plus conséquents avec l’abonnement Game Pass Console (11€/mois) pour accéder régulièrement à des nouveautés, des jeux variés et récents et le plaisir des yeux niveau qualité d’image.

Ma préférence, quitte à payer un abonnement mensuel, est d’utiliser le Game Pass Console sur la Xbox Série X pour pouvoir tester plusieurs jeux dès leur sortie. Et d’éventuellement acheter lesdits jeux en occasion dès que le prix me convient (pour les finir ou les garder à la maison).

Sachez que, quoiqu’il arrive, dès que vous souhaitez jouer en ligne, la plupart des consoles vous amèneront à prendre un abonnement minimal pour cela… Une console de jeu est finalement un budget à part entière de nos jours !

Ordinateur portable Xiaomi Book Air 13 (version 2022)

Fri, 01 Dec 2023 21:17:01 +0200

Edit : article rédigé et publié ultérieurement (courant 2024). La date du 1er décembre représente approximativement l’arrivée de l’appareil dans le foyer.

Présentation

2024, écologiquement parlant nous devrions faire durer un ordinateur un minimum de 5 à 7 ans ! Mon dernier achat d’ordinateur portable était en décembre 2018, il y a exactement 5 ans ! C’était un Xiaomi Mi Notebook Air 13.3 (version 2017).

Techniquement il fonctionne encore très bien. C’est pourquoi je l’ai donné à quelqu’un (en installant Windows 10 dessus, berk!). Je n’avais pas à en racheter un.

Seulement voilà, les habitudes ont la vie rude ! Le confort de la mobilité (travail à l’extérieur, déplacements et utilisation dans différentes pièces de la maison) me manquait énormément.

C’est ainsi que mon côté technophile a eu raison de moi : j’ai fais l’acquisition d’un Xiaomi Book Air 13 (version 2022).

Description du produit

Le Xiaomi Book Air 13 (version 2022) possède les caractéristiques suivantes :

un processeur Intel Core i5-1230U (12e génération, 10 cœurs, 12 threads, jusqu’à 4.40Ghz)
une mémoire vive de 16 Go de RAM LPDDR5 cadencé à 5200 Mhz
un disque dur SSD de 512Go
une carte graphique intégrée Intel Iris Xe graphics
une batterie de 12 heures d’utilisation et 1 à 2h de charge
un écran 13 pouces 360° OLED tactile avec une résolution 2.8K
un lecteur d’empreinte
Bluetooth 5.2
Wifi 6E
2 prises USB 3 de Type C Thunderbolt
une prise jack
poids de 1,3 kg
épaisseur de 12 mm

Il n’y a pas de ventilation ni d’aération : vous n’entendrez jamais tourner cet ordinateur.

Mes impressions

Cet ordinateur, en plus d’avoir de bonnes caractéristiques pour l’année 2022, ressemble à un véritable bijou : il est brillant, présenté comme une parure qu’on mettrait sur soi.

Il est pratique : très léger, très maniable (se plie même en mode tablette, c’est dire !) et tient longtemps (entre 10h et 12h d’autonomie). Il est très impressionnant.

Cependant sans le stylo spécifique (non fourni par Xiaomi) de cet ordinateur, l’écran tactile n’est pas très utile. Au contraire : il me pose problème régulièrement. Sans doute ne suis-je pas habitué aux écrans taciles. Par contre plier l’ordinateur et le poser comme un écran de TV est pratique !

Étant donné qu’il est silencieux, car aucune ventilation, on pourrait s’attendre à ce qu’il chauffe énormément. Mais ce n’est pas le cas. Il chauffe, certes, mais avec l’assemblage aluminium tout autour cela passe très bien.

Je regrette qu’il soit si fin et donc quasiment pas réparable : si la moindre pièce venait à tomber en panne, il faudrait quasiment changer l’ordinateur portable entier. Cela m’embête un peu.

On notera également un écran avec une définition et des couleurs à couper le souffle ! Et surtout un peu compliqué à configurer pour moi sur ArchLinux car la résolution était tellement grande qu’il a fallu déterminer un ratio d’aggrandissement. J’ai ri - de honte 😉.

A contrario je déplore le manque d’informations pour savoir comment faire fonctionner la Webcam sur GNU/Linux pour cette machine. Impossible pour le moment 🤷.

Conclusion

Je dois dire que cet ordinateur est un objet de très bonne facture. Avec du matériel à la hauteur, de bonnes caractéristiques techniques, léger, pratique et silencieux. Et pas cher pour ce que c’est !

Pourtant le côté peu réparable, un écran tactile - presque - inutile et une webcam ne fonctionnant pas sous GNU/Linux, m’ont légèrement irrité.

Je pense ne pas garder cet ordinateur portable longtemps et le revendre dès que j’aurais trouvé un ordinateur qui me seille bien plus.

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.

Bye Bye Gandi Mail, Bonjour Mailo

Fri, 25 Aug 2023 21:26:05 +0200

Ça fait quelques mois qu’on nous rabache que Gandi Mail va devenir payant. NextInpact affirme aussi que Gandi passe les mails en payant. Quel problème cela pose ? Où en suis-je ? Y a-t-il d’autres alternatives à cela ?

Photo trouvée sur le profil d’irio sur Flickr sous licence BY 2.0.

Problèmes posés

Gandi annonce la mise du service Gandi Mail payant à partir de fin septembre/début octobre. Le prix des boîtes mail passe de gratuit à 4.79€ par mois. C’est à dire 57.48€/an. Et cela pour chaque boîte courriel !

Le souci ? Quand on utilise plusieurs boîtes courriel, ça douille tout de suite plus ! Exemple : j’ai 4 boîtes courriel utilisées chez Gandi, ce qui me ferait passer de 0€/an à… 229.92€ !!

Avouez que la facture est plutôt corsée quand on a été habitué plus de 10 ans à ne rien débourser pour cela. Et encore, j’abuse un peu car il faut savoir que les domaines sous Gandi sont généralement plus chers que d’autres fournisseurs de domaines. Les adresses courriel gratuites et de bonne qualité amenait des clients chez Gandi.

J’utilise Gandi pour l’ensemble de mes domaines car j’apprécie le service, les possibilités (comme le « Live DNS ») et - antérieurement - la possibilité de créer des adresses courriels avec 1 000 alias de redirection courriels (vous choisissez des adresses courriels qui vont rediriger vers 1 à plusieurs adresses courriels, même si les adresses cibles ne vous appartiennent pas).

Et dans tout cela, où me situe-je ?

Où j’en suis

Si j’écris cet article, c’est parce que j’aimerais partager à la fois le fait qu’il y a du changement chez Gandi Mail, mais aussi mes pérégrinations en matière de recherche d’un fournisseur de mail prenant en compte les noms de domaine sans forcément les gérer.

On le dit souvent, en informatique il est intéressant de pouvoir changer un service sans avoir d’impact sur un autre : choisir un fournisseur d’adresses courriels sans changer de fournisseur de domaine par exemple. Et c’est ce que je visais.

Quelles alternatives ?

Si SebSauvage propose Infomaniak en migrant ses domaines là bas, d’autres proposent différents services comme FastMail, Ikoula.

La plupart du temps, il faut migrer ses domaines avec : ce que je ne recherche pas du tout. C’est le cas pour OVH qui propose des offres quand on gère les domaines chez eux.

Je suis alors tombé sur un article intéressant sur le passage à Mailo.com, service que je ne connaissais pas. Mailo.com est Français, garantit aux utilisateurs d’être respectueux de leurs données, ne pas les vendre à des tiers et visant une utilisation éthique et responsable du Web. Le service Mailo est gratuit, mais une option à 2€/mois existe, ce qui permet de gérer 5 adresses mails. Ça tombe bien, j’ai 4 adresses à créer !

Quelques détails sur ma migration

Ce qui est intéressant dans ce dernier article sur Mailo.com, c’est que l’auteur suggère l’utilisation d’imapsync comme outil pour synchroniser son ancienne boîte aux lettres avec la nouvelle. Et il donne les détails sur comment configurer tout cela.

À noter une petite subtilité que je n’avais pas prise en compte : si sous Gandi Mail vous avez droit à 1 000 redirections courriel, sous Mailo c’est limité à 100 redirection par boîte courriel. Quand on a 390+ redirections… il faut faire du tri ! Fort heuresement, Mailo propose un fonctionnement intéressant : ajouter ++ dans l’adresse courriel. Par exemple si vous faites une boîte prenom.nom@domaine.tld, vous pouvez créer dynamiquement prenom.nom++quelquechose@domaine.tld. Autant que vous voulez. Sans utiliser d’ordinateur. À la volée je vous disais !

Autre chose à viser aussi : le catch-all. C’est le fait que n’importe quelle adresse mal écrite, ou différente de votre boîte courriel entraînera quand même la redirection vers votre boîte courriel. Exemple : au lieu d’écrire prenom.nom@domaine.tld, si je me trompe en écrivant prenmo.nmo@domaine.tld, je recevrais quand même l’adresse courriel.

Conclusion

Je joue les montagnes russes avec les prix : je suis passé de 4 boîtes Gandi Mail gratuites à potentiellement 230€/an pour finalement payer 24€/an. Le coût numérique augmente légèrement. Je pense être en droit de me demander jusqu’où cela ira pour bénéficier d’un pseudo contrôle de mes données et le choix de mes fournisseurs sur Internet ?

Quoiqu’il en soit le passage de Gandi Mail à Mailo, même si rocambolesque et pas de tout repos, a été plus serein avec l’aide de l’article de Jonathan Tremesaygues sur le passage de Gandi Mail à Mailo à l’aide d’imapsync.

Je trie encore mes 390+ redirections Gandi Mail vers Mailo au fur et à mesure, mais c’était nécessaire et je suis bien content de l’avoir fait, malgré le côté payant de la chose !

Liens utiles

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 !

Jeu, Dreamlight Valley

Fri, 04 Nov 2022 21:58:39 +0100

Introduction

Dans l’état des lieux 2022 de mon espace numérique (un précédent article de ce blog) j’énonçais DreamLight Valley, un jeu vidéo Disney créé par GameLoft.

Parlons un peu de DreamLight Valley, décrivons le un peu pour ensuite s’intéresser à quelques éléments de la composition du jeu. Puis nous donnerons notre avis avant de conclure sur cet article.

Description

Qu’est DreamLight Valley ? C’est un jeu vidéo sorti en accès anticipé en France le 6 septembre 2022. Disponible sur de nombreuses consoles comme Microsoft Xbox, Nintendo Switch, PC et Playstation 4 et 5.

C’est un jeu à la troisième personne où le joueur évolue dans un monde en 3 dimensions et doit effectuer des quêtes pour avancer dans l’histoire.

Vous êtes le héros principal de cette histoire et arrivez dans un univers qui a été frappé par l’Oubli : tous les personnages ont perdu la mémoire et plusieurs maléfices parcourent ce monde.

Comme dans beaucoup de jeux vous allez devoir sauver ce monde, lever les maléfices, nettoyer l’endroit et faire recouvrir la mémoire aux personnages autour de vous.

Quelques exemples de personnages :

Mickey,
Picsou,
Merlin l’enchanteur,
Wall-E,
Dingo,
etc.

Ce jeu est fait pour les enfants, il n’y a donc pas de système de combats. Et vous évoluez dans un monde où vous devez travailler sur l’amour, l’amitié, etc. C’est à dire que vous allez devoir cultiver vos amitiés avec les différents protagonistes.

Dans ce jeu, vous avez plusieurs “monnaies” :

des pièces d’or quand vous vendez/achetez des graines/fruits/légumes/autres aux stands de Dingo
des points Dreamlight à utiliser pour débloquer des parties de l’univers ou bien ouvrir des portes

D’autres points font penser à d’autres jeux vidéos connus.

Éléments du jeu

Qu’on se le dise, DreamLight Valley n’invente rien en la matière :

on retrouve le système d’outils de Stardew Valley comme la pioche, l’arrosoir, la pelle pour interagir avec l’univers dans lequel on se trouve
on discute avec les personnes comme dans beaucoup de jeux de rôle, on pourrait même penser au jeu « Les Sims »
il y a un peu du Animal Crossing dans la façon de présenter les quêtes journalières pour obtenir des points
le château et ses portes pour transiter vers d’autres univers fait penser à Mario 64
le choix des outils sur un cercle au milieu de l’écran fait penser à Fortnite
le système de différentes monnaies fait penser à Animal Crossing
on cultive des légumes comme dans Stardew Valley
on décore la maison comme dans Animal Crossing

Le jeu est donc assez commun dans ses comportements et les éléments du jeu sont assez vus partout ailleurs pour ne pas se sentir dépaysé !

C’est dans ce système que nous avons évolué et nous allons exprimer notre ressenti à ce sujet.

Avis

Bon enfant, ce jeu est purement et simplement de la détente où on évolue dans un univers où il fait bon vivre, bien qu’on commence la partie de nuit, dans un monde tombé dans l’Oubli où même Merlin l’enchanteur ne se souvient plus de grand chose.

La particularité de ce jeu ira surtout dans le fait de se lier d’amitié avec les personnages, de leur faire de bons petits plats avec les ingrédients récoltés ici ou là, de pêcher, de planter, arroser, cueillir, etc.

C’est agréable, on apprécie !

Cependant le jeu étant encore en accès anticipé, le contenu est encore limité : même avec 18 personnages (depuis une mise à jour récente) les quêtes sont vites finies.

Au départ la difficulté est assez grande pour obtenir des DreamLight et pouvoir débloquer les parties de la carte pour accéder à de nouveaux personnages et nouvelles denrées. Mais avec quelques habitudes on arrive ensuite à cumuler assez de DreamLight pour continuer sereinement.

Dans la partie on récupère des morceaux de souvenirs mais on ne sait pas à quoi cela sert pour le moment.

Il y a aussi des quêtes événementielles qui permettent de débloquer des objets spécifiques à l’événement pour les joueurs. D’un point de vue “monnaie”, ils ne sont pas du tout intéressants, mais il reste facile de les débloquer sur la période limitée. À condition de jouer un peu tous les jours évidemment.

On regrette aussi beaucoup d’être interrompu une fois par jour (voire plus) pour des bugs du jeu qui se fige, s’arrête carrément sous Nintendo Switch sans avoir sauvegardé ! Très pénible. Mais le jeu étant en accès anticipé, on se fait une raison.

Conclusion

Bien que nous ayons un jeu simple et bon enfant, avec de quoi s’occuper la journée, les nombreux bugs du début et la rapidité de finition des quêtes nous laisse beaucoup sur notre faim !

En revanche le monde de Disney nous rappelant beaucoup de souvenirs - et on imagine bien que Disney s’appuie là dessus pour vendre des produits dérivés - on a hâte de savoir quels seront les prochains personnages et comment les débloquer au plus vite lors des prochaines mises à jour !

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 :

Mise à jour des DNS Gandi (v5) avec la bbox de Bougues

Mon, 06 May 2019 20:18:29 +0200

Figurez-vous qu’après mes pérégrinations dans le monde de l’Internet nomade, j’ai eu l’occasion de passer à la Fibre. Et avec elle son lot de « malheurs » : une IP dynamique.

En quoi est-ce problématique ?

Une IP fixe permet de bénéficier d’une adresse constante, c’est à dire qu’elle permet, par exemple, d’avoir un nom de domaine qui redirige vers une à plusieurs machines de la maison. Par exemple avec bogossdu69.fr je pourrais éventuellement arriver sur mon partage de fichiers.

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

La situation

Mon but est donc de mettre à jour régulièrement mes noms de domaine lorsque mon IP change.

Je dispose de :

une box Bouygues nommée bbox
une ip dynamique
un nom de domaine chez Gandi.net
une machine allumée en permanence sur la box

L’objectif

Mettre à jour régulièrement le nom de domaine pour qu’il pointe vers ma box en permanence.

Ma solution en 1 commande

En une commande :

curl -s https://mabbox.bytel.fr/api/v1/wan/ip |jq '.[0].wan.ip.address'| xargs -I{} curl -X PUT -H "X-Api-key: LaSuperCleAPIdeGandiV5" -H "Content-Type: application/json" -d '{"rrset_ttl":"1800","rrset_values":["{}"]}' https://dns.api.gandi.net/api/v5/domains/domain.tld/records/bogossdu69/A

En remplaçant :

LaSuperCleAPIdeGandiV5 par la clé de sécurité dans votre interface Gandi sur Tableau de Bord > Paramètres > Sécurité > (Re)Générer la clé d’API
domain.tld par votre domaine, par exemple dossmann.net
bogossdu69 par votre sous-domaine, par exemple olivier (ce qui donnera olivier.dossmann.net)

Le détail

L’idée est de lancer un script régulièrement (par exemple toutes les 5 minutes) sur la machine branchée à la Box.

Pour cela on va utiliser les outils suivants :

l’IP donnée par l’API de votre bbox et dont la documentation est sur le site officiel de l’API de Bouygues
curl fourni dans la plupart des distributions GNU/Linux (et plus encore !)
jq
l’outil timerctl fourni dans le système pour planifier l’exécution de tâches régulières
et la commande précédente aménagée dans un script

L’API de notre box va fournir l’IP publique dynamique de notre connexion internet. jq va permettre la récupération de la bonne information parmi l’ensemble fourni par notre box. Après quoi curl mettra à jour les DNS dynamiques de Gandi (notre fournisseur de nom de domaine).

Il ne nous reste plus qu’à taper la commande entière dans le fichier /etc/systemd/system/maj_domaine.service sous la forme suivante :

[Unit]
Description=Mise a jour du domaine Gandi

[Service]
Environment="API_KEY=oefijzoifjzeoifjzeoifjeo"
ExecStart=/usr/bin/bash /home/user/maj_domaine.sh
Type=simple

N’oubliez pas d’adapter API_KEY avec votre clé d’API et /home/user/ par l’adresse où se trouve le script !

Puis de renseigner le fichier /etc/systemd/system/maj_domaine.timer avec :

[Unit]
Description=Lance maj du domaine toutes les 8 min

[Timer]
OnBootSec=8min
OnUnitActiveSec=8min
Persistent=True
Unit=maj_domaine.service

[Install]
WantedBy=multi-user.target

Il ne nous reste plus qu’à prévenir systemd via les commandes suivantes :

sudo systemctl daemon-reload
sudo systemctl enable maj_domaine.timer
sudo systemctl start maj_domaine.timer
sudo systemctl start maj_domaine.service

Et le tour est joué !

Conclusion

À l’aide des outils listés dans ce billet on peut sans problème survivre à une IP dynamique à la maison chez Bouygues Telecom. Je n’ai eu jusqu’à ce jour aucun problème et espère que cela continuera ainsi.