logiciel on Zwindler's Reflection

Planifier les posts de mon blog Hugo sur Clever Cloud

Mon, 29 Jan 2024 06:00:00 +0200

Suite de la migration

Fin décembre, j’ai migré ce blog sur Clever Cloud.

Cependant, David Legrand m’a fait remarquer que je n’avais plus de méthode pour planifier mes posts.

Depuis quelque temps, je poste à flux tendu donc ça ne m’a pas encore gêné (j’écris un post, je le rends public dans la foulée) mais c’est vrai qu’il me manque cette possibilité par rapport à précédent mon hébergement (une VM).

Cependant, il existe une solution sur Clever Cloud pour le faire. David en a d’ailleurs écrit un petit article sur son blog perso, adapté pour “Astro” son générateur de site statique.

Je vais donc faire pareil pour mon propre blog avec Hugo.

Adaptations

Repartons donc d’où j’en étais au post précédent. Nous avons un blog avec Hugo qui se déploie quand on fait des clever deploy (ou des commits sur le git remote de clever).

La première chose qu’on va devoir faire, c’est récupérer un token. En effet, c’est notre blog qui va déclencher de lui même les redéploiements, on va donc devoir lui donner de quoi s’authentifier.

Si vous n’avez pas de token sous la main, on peut en retrouver un en faisant clever login depuis un terminal, comme je l’expliquais dans l’article précédent.

Et on va rajouter le TOKEN dans la liste des variables d’environnement de notre app :

$ clever env set CC_SECRET "aaaaaaaaaaaaaaaaaaaaaaaaaa"
$ clever env set CC_TOKEN "aaaaaaaaaaaaaaaaaaaaaaaaaa"

A partir de là on va créer plusieurs fichiers. D’abord, un script qui va déclencher ce fameux redéploiement :

cat > clever_rebuild.sh << EOF
#!/bin/bash -l
clever link ${APP_ID}
clever restart --quiet --without-cache
EOF
chmod +x clever_rebuild.sh

Ensuite, je vais créer un fichier qui sera lu par clever-cloud et qui va déclencher ce redéploiement aux heures où je publie mes posts planifiés (le matin, un peu avant 9h) :

mkdir clevercloud
echo '["00 08 * * * $ROOT/clever_rebuild.sh"]' > clevercloud/cron.json

Attention aux petites blaguounettes de timezone. Comme tous sysadmins qui se respectent, les gens de clever utilisent le temps UTC sur leurs serveurs (moi aussi). Cependant, ça nécessite une petite gymnastique intellectuelle si jamais vous n’utilisez pas aussi le temps UTC dans votre tête pour planifier les posts ;-P.

Si tout se passe bien, vous verrez qu’il remarque qu’il y a un cron dans les logs :

[...]
2024-01-25T14:05:21+01:00 Importing cronjobs
2024-01-25T14:05:21+01:00 Starting crons setup
[...]
2024-01-25T14:06:05+01:00 (CRON) INFO (running with inotify support)
2024-01-25T14:06:05+01:00 (CRON) INFO (RANDOM_DELAY will be scaled with factor 89% if used.)
2024-01-25T14:06:05+01:00 (CRON) STARTUP (1.7.0)
[...]

Tout dernier point que j’ai éludé jusqu’à présent, il est possible de redémarrer une application à partir d’un cache (pour que ça aille plus vite). Cependant, il est nécessaire d’indiquer à clever cloud quoi mettre dans ce cache. On va donc ajouter “/clevercloud/cron.json:/clever_rebuild.sh” à la variable existante :

# précédemment CC_OVERRIDE_BUILDCACHE "/public"
$ clever env set CC_OVERRIDE_BUILDCACHE "/public:/clevercloud/cron.json:/clever_rebuild.sh"

(Fail to) hack the template

Si Hugo a bien un flag pour permettre de “builder” les posts dont la date de sortie est postérieure à la date actuelle (buildFuture), mon thème “Stack” les affiche par défaut dans la liste des derniers posts ainsi que dans le flux RSS.

La solution la plus simple à ce problème est de laisser les paramètres par défaut, et d’attendre que la date de publication soit dépassée (idéalement juste avant le passage d’un cron) et le tour est joué.

Mais David a eu une autre approche qui m’a bien plu : ajouter une condition dans le template pour que le post ne soit pas visible dans la liste des posts, mais quand même publié.

Avantage : on peut consulter l’article à paraître, si on a le lien. Il se rajoute à la liste des articles de la homepage de lui-même lors du prochain rebuild, une fois la date dépassée.

Dans mon thème, la page d’accueil qui liste les posts est définie ici dans le code :

 {{ define "main" }}
 {{ $pages := where .Site.RegularPages "Type" "in" .Site.Params.mainSections }}
 {{ $notHidden := where .Site.RegularPages "Params.hidden" "!=" true }}
+ {{ $notFuture := where .Site.RegularPages ".Date" "le" now }}
+ {{ $filtered := ($pages | intersect $notHidden | intersect $notFuture) }}
- {{ $filtered := ($pages | intersect $notHidden) }}
 {{ $pag := .Paginate ($filtered) }}

 <section class="article-list">
 {{ range $index, $element := $pag.Pages }}
 {{ partial "article-list/default" . }}
 {{ end }}
 </section>

 {{- partial "pagination.html" . -}}
 {{- partial "footer/footer" . -}}
 {{ end }}
[...]

En théorie, ça fonctionne. Sauf que je n’ai pas réussi à le faire marcher avec le thème “Stack” que j’utilise sur le site (j’ai réussi avec un thème “blank”).

C’est peut-être lié à un problème d’appel multiple à la fonction .Paginate(), qui “cache” la pagination la première fois qu’elle est lancée.

If you call .Paginator or .Paginate multiple times on the same page, you should ensure all the calls are identical. Once either .Paginator or .Paginate is called while generating a page, its result is cached, and any subsequent similar call will reuse the cached result. This means that any such calls which do not match the first one will not behave as written.

https://gohugo.io/templates/pagination/

Même en partant du principe que j’arrive à le faire marcher, reste encore la problématique du flux RSS, comme j’ai pu le remarquer avec Seboss666 ;-)

J’ai donc laissé tomber cette idée. De toute façon, je n’avais jamais vraiment eu besoin jusqu’à présent puisque je n’y avais pas pensé ;-P.

J’ai donc, comme avant, mes posts “planifiés” qui sont visible le matin de leur publication et c’est déjà bien comme ça (pour l’instant).

Have fun !

Migration du blog sur Clever Cloud

Sat, 30 Dec 2023 16:00:00 +0200

It’s groundhog migration day, again

Tous les 6 mois environ, une mouche me pique.

Après avoir migré un nombre incalculable de fois mon blog wordpress à droite / à gauche, puis migré sur Hugo, autohébergé, utilisé du managé chez vercel, chez froggit, autohébergé encore…

J’ai décidé (un peu sur un coup de tête) de migrer le blog chez les copain⋅es de chez Clever Cloud.

Et je vous montre comment j’ai fait.

Prérequis

Je pars du principe que vous avez comme moi un dépôt git / site hugo déjà fonctionnel. Et je ne vais pas non plus détailler la procédure pour activer un compte chez Clever Cloud.

Je commence par installer la CLI, les “clever tools”. Pour les installer, il nous faut npm. J’utilise rarement npm, mais quand je le fais, j’utilise un autre tool, volta (volta.sh), qui va me permettre de choisir la version dont j’ai besoin

$ curl https://get.volta.sh | bash

Une fois installé, je peux télécharger la version qui m’intéresse de npm (18 par exemple, la version minimum pour installer les clever tools)

$ volta install node@20
success: installed and set node@20.10.0 (with npm@10.2.3) as default

Je peux donc maintenant installer les clever tools :

npm i -g clever-tools

Puis me loguer depuis mon terminal

$ clever login
Opening https://console.clever-cloud.com/cli-oauth?cli_version=3.0.2&cli_token=xxxxxxxxxxxxxxxxx in your browser to log you in…
Login successful as [unspecified name] <xxx.yyy@example.org>

Si jamais comme indiqué sur l’écran de login, vous avez besoin d’un token + secret (pour de la CI par exemple), sachez qu’ils sont stockés dans un fichier ~/.config/clever-cloud/clever-tools.json

Denier prérequis, je vais ajouter une clé SSH dans ma console clever

Création de l’application

A partir de maintenant, je suis capable d’interagir avec clever cloud en CLI. Je vais commencer par créer l’application qui va héberger mon site statique :

$ clever create -t static-apache blog-zwindler
Your application has been successfully created!

Clever Cloud offre la possibilité de dissocier la taille des instances pour la partie run et la partie build. Je vais donc créer l’instance la plus petite possible pour le run (une nano), et une plus pêchue (une M) pour le build, histoire d’être plus réactif sur les commits de modifications :

$ clever scale --build-flavor M
App rescaled successfully
$ clever scale --flavor nano
App rescaled successfully

Je peux ensuite configurer quelques variables d’environnement (trouvées sur la doc de clever cloud) pour générer mon site statique avec l’image static-apache de clever.

$ clever env set CC_WEBROOT "/public"
$ clever env set CC_OVERRIDE_BUILDCACHE "/public"
$ clever env set CC_PRE_BUILD_HOOK "bash setup_hugo.sh"
$ clever env set CC_POST_BUILD_HOOK "hugo --minify --gc"

Pour finir, on crée le script setup_hugo.sh à la racine de notre site statique Hugo :

cat > setup_hugo.sh << EOF
HUGO_VERSION="0.121.1"
HUGO_URL="https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz"
DEST_BIN="${HOME}/.local/bin"
FILENAME="hugo.tar.gz"

# Download Hugo Extended and place it in a folder in the $PATH
curl --create-dirs -s -L -o ${DEST_BIN}/${FILENAME} ${HUGO_URL}
cd ${DEST_BIN}
tar xvf ${FILENAME} -C ${DEST_BIN}
rm ${FILENAME}
EOF

On commit les fichiers créés :

git add .
git commit -m "Add clever"

Déployer notre code

A partir de là, on a notre instance qui est prête à démarrer, dès qu’elle aura reçu du code.

Ici, clever cloud attend un push sur un dépôt git.

La méthode la plus “simple” pour pousser du code sur clever à ce moment-là est donc de créer un dépôt distance (remote) :

git remote add clever git+ssh://git@push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git
git push clever master

Le “problème” dans mon cas est que (pour l’instant), le nom de la branche n’est pas configurable et est forcément “master”, ce qui ne m’arrange pas puisque je bosse habituellement sur “main”.

remote: Error: You tried to push to a custom branch. This is not allowed.
remote: error: hook declined to update refs/heads/main
To git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git
! [remote rejected] main -> main (hook declined)
error: impossible de pousser des références vers 'git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git'

2 manières de contourner ce problème :

soit je force la branche master sur le remote clever dans git
soit j’utilise la CLI clever deploy

Dans un premier temps, je me contente de feinter git :

git push clever main:master
Énumération des objets: 30, fait.
Décompte des objets: 100% (24/24), fait.
Compression par delta en utilisant jusqu'à 16 fils d'exécution
Compression des objets: 100% (16/16), fait.
Écriture des objets: 100% (16/16), 287.70 Kio | 31.97 Mio/s, fait.
Total 16 (delta 8), réutilisés 0 (delta 0), réutilisés du pack 0
remote: [SUCCESS] The application has successfully been queued for redeploy.
To git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git
54ff42f..960ce62 main -> master

On termine par la configuration du nom de domaine :

$ clever domain add blog.zwindler.fr
Your domain has been successfully saved

Il ne nous reste plus qu’à mettre à jour le CNAME dans notre DNS (domain.par.clever-cloud.com. dans mon cas, mais la bonne configuration est visible dans l’onglet Domain names de l’application)

Et avec `clever deploy` ?

Eh bien en fait, c’est “encore plus simple”. Il me suffit juste de faire une modif, de commit

git add .
git commit -m "test clever deploy"

Puis de simplement lancer la commande clever deploy.

$ clever deploy
Remote git head commit is c4e3c283585cafff44f07c7d78d860065318cd68
Current deployed commit is c4e3c283585cafff44f07c7d78d860065318cd68
New local commit to push is 0b3536a9f1d61178a99f6238831ccb4197989ddf (from refs/heads/main)
Pushing source code to Clever Cloud…
Your source code has been pushed to Clever Cloud.
Waiting for deployment to start…
Deployment started (deployment_b5f841ff-a233-4bb4-8a16-f618ee69ef28)
Waiting for application logs…
[...]

Quelle est donc cette diablerie ?

En réalité, les informations nécessaires pour pousser le code sont en réalité simplement dans un fichier .clever.json qui a été créé à la racine lorsqu’on a lancé la commande clever create -t static-apache blog-zwindler au tout début du tuto.

{
 "apps": [
 {
 "app_id": "app_xxxxxxxxxxxxxxxxxxx",
 "org_id": "user_yyyyyyyyyyyyyyyyyyyyy",
 "deploy_url": "https://push-n3-par-clevercloud-customers.services.clever-cloud.com/xxxxxxxxxxxxxxxxxxxx.git",
 "name": "blog-zwindler",
 "alias": "blog-zwindler"
 }
 ]
}

Évidemment, je ne vais pas m’amuser à faire un clever login / clever deploy à chaque fois que je veux pousser une modif sur mon blog. Et c’est là où nos CLEVER_TOKEN / CLEVER_SECRET seront utiles !

Conclusion

Après quelques heures d’usage, je peux dire que dans le cadre de l’hébergement de mon blog, j’aime bien utiliser Clever Cloud.

Qu’on soit bien clair, c’est pour mon cas d’usage et comparé à :

Vercel : l’expérience utilisateur est incroyable sur Vercel, mais j’ai toujours été un peu gêné par le côté “boite noire” (on a pas accès à beaucoup plus que des variables d’environnement). Et je ne parle pas des problématiques de privacy…
Deux serveurs physiques avec Proxmox VE en cluster étendu chez One-provider : à l’inverse héberger moi-même mon blog sur une machine (en vrai, 2) louée résout les problèmes de privacy et j’ai la main sur toute la stack, mais ça me demande de la maintenance pour des perfs minables. Ok, c’est pas cher, mais j’ai 2 à 3 minutes de rebuild avec le CPU à 100% sur mon Atom de 2010 chez Online…
Froggit : c’était du Gitlab + Gitlab pages et c’était très cool car c’est plus flexible que Vercel, mais j’avais dû passer un peu de temps à configurer la pipeline et leur faire pousser les murs pour que mon site rentre (les 400 Mo de médias n’étaient pas supportés au début et les transferts Gitlab => Gitlab pages étaient un peu longs).

Avec Clever, mes 450 articles (3600 pages générées, 400 Mo de média) sont très rapidement générés, transférés, et enfin mis à disposition (< 1 minute tout compris, plus rapide que les 3 solutions précédentes).

Le tout avec une disponibilité/fiabilité sans aucun doute bien meilleure que ce que j’aurais pu faire moi-même en auto hébergé avec un coût similaire, et en très peu de temps.

J’ai passé beaucoup plus de temps à écrire cet article qu’à migrer le blog, puisque la doc est bien écrite, le site est intuitif, et je n’ai été bloqué à aucun moment.

Il me reste encore à optimiser l’étape de déploiement, pour qu’un commit/push sur mon dépôt git déclenche automatiquement un déploiement côté clever. Objectivement, ça ne devrait pas prendre trop longtemps (github action / gitlab CI)…

Et par contre, ça manque d’IPv6 natif, screugneugneu !

D’open source à BullShit Licence (BSL)

Wed, 16 Aug 2023 12:00:00 +0200

Résumé des épisodes précédents

Il y a à peine un mois, j’écrivais mon billet d’humeur annuel sur une boite, championne de l’open source (RHEL), qui utilise une faille de la licence GPL pour gratter un peu de thune en fermant ses sources aux “rebuilders” (je parle évidemment de l’article “Oracle à la rescousse de Linux ? Quelle blague!”).

Je ne pensais pas que je devrais REFAIRE un article d’humeur sur un sujet similaire, un mois plus tard.

Car jusqu’à présent, c’était plutôt des incidents “isolés” et dans des contextes assez spécifiques. En 2021, c’était Elastic qui passait à la licence SSPL pour “lutter” contre les offres managées par AWS (après Mongo qui avait fait pareil en 2018).

Si AWS était évidemment fautif dans cette histoire, ce move est catastrophique et a amorcé pas mal de backlash côté communauté (justifié, à mon avis) ainsi qu’une tempête de FUD de tous les côtés. Au final, c’est l’open source, qui devenait tout juste respectée en entreprise, qui en pâtie.

RHEL ouvre une brèche, l’open source se referme

Car à peine quelque jour après le move de RHEL pour faire la nique à Rocky+Alma, on pensait souffler mais non, les mauvaises nouvelles s’enchaînent.

Canonical, créateur de l’outil LXD (solution pour manager des containers LXC, que j’affectionne particulièrement) retire l’outil du Linux Containers project, un projet communautaire, qui le chapeautait.

While the team behind Linux Containers regrets that decision and will be missing LXD as one of its projects, it does respect Canonical’s decision and is now in the process of moving the project over.

linuxcontainers.org/lxd/

On peut aussi noter que ce move le lendemain de la démission d’un des développeurs de LXD chez Canonical :

stgraber.org/2023/07/10/time-to-move-on/

Et que le créateur de LXD l’a forké :

linuxiac.com/incus-project-lxd-fork/

In response to Canonical’s takeover of LXD, the independent Incus project arose as a fork for this container and virtual machine manager.

Moi je l’aime bien la MPL…

Et la semaine dernière (pendant mes vacances, ces cochons), Hashicorp a changé la licence de leurs produits de la MPL (Mozilla Public Licence, que je trouve être un bon compromis) à la BSL, une licence plus restrictive :

BSL is a new alternative to closed source or open core licensing models. Under BSL, the source code is always publicly available. Non-production use of the code is always free, and the licensor can also make an Additional Use Grant allowing limited production use.

Qu’est ce que la BSL ?

Grosso modo, c’est une licence qui n’est PAS open source (cf ce post de Sentry qui reconnait que BSL n’est pas open source dans le sens OSI du terme), et qui permet à Hashicorp dans le cas présent de tuer la concurrence dans l’oeuf.

You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp’s products

Dans le billet de blog pour parler du changement de licence, voilà comment c’est dit :

Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches contributed to our products.

Si vous voulez creuser un peu plus les réactions, The Register a fait un article assez cool sur ce move, les réactions et les conséquences que ça va avoir.

www.theregister.com/2023/08/11/hashicorp_bsl_licence/

Et je vous partage aussi cet excellent thread sur Twitter et son tout aussi excellent follow up de iamvlaaaaaaad

Autant dire que de nombreuses personnes, dont des développeurs qui ont contribué à un projet open source et qui se retrouvent à avoir engraissé gratuitement Hashicorp, sont assez mécontents.

Pour essayer d’éteindre l’incendie, il y a évidemment une FAQ pour dire que rien ne va changer et que l’utilisateur n’a rien à craindre, mais comme à chaque fois dans ces histoires de licences, c’est la licence qu’il faut lire, pas la FAQ. Ce n’est pas la FAQ qui vous sauvera du tribunal…

C’était exactement la même salade avec MongoDB et Elastic. Beaucoup de craintes, du FUD, notamment de la part des opposants aux modèles open source (ahah vous voyez c’est pas clair l’open source !), et surtout un flou juridique immense que personne n’a encore réellement éclairci…

Le point positif, c’est que ça fait travailler les devrels et les avocats (cf le thread de vlad).

Hashi, c’est fini

Note: ce sous titre est gracieusement offert par (volé à) Clementd.

Autant dans le cas du bras de fer entre Mongo/Elastic avec AWS, j’arrivais à peu près à comprendre les motivations. En revanche, pour Hashicorp, on peine à trouver qui est visé par cette modification.

Qu’avait à gagner Hashicorp à changer son modèle de licence, à part une communauté à dos et un fork dans les start-in blocks ?

La seule cible qui me vient en tête n’est pas un gros méchant cloud provider, mais plutôt des offres alternatives à Terraform Cloud/Entreprise, comme Env0 ou Spacelift. Et aussi de petit éditeurs / cloud providers locaux qui se reposent sur ces outils pour fournir de l’automatisation à leurs clients…

On est bien loin des méchants GAFAM qui “piquent not’ travail” (ref south park, j’innove peu), ici il s’agit d’offres qui se sont construites “au-dessus” de Terraform, car elles ont apporté des choses en plus qu’on ne trouvait pas dans les offres d’Hashicorp. Ces offres se retrouvent tuées dans l’oeuf maintenant qu’elles sont concurrentes à certains produits d’Hashicorp. Pratique…

Plus cynique encore, on pourrait imaginer un scénario où une boite se créerait au dessus de terraform ou tout autre produit d’Hashicorp en étant totalement PAS concurrente de leurs offres, qui se mettrait à bien marcher. Hashicorp n’aurait qu’à artificiellement créer un produit concurrent (même tout pourri) et hop, on rafle le marché.

On est plus proche du EEE que de la philosophie open source.

Sauf que maintenant, c’est plus Microsoft : c’est RHEL, Canonical, Hashicorp…

Conclusion (rédigée par ChatGPT, pour le lulz)

Dans ce spectacle de l’open source, les spectateurs ne savent plus s’ils doivent rire ou pleurer

Les entreprises qui semblaient autrefois être les champions du partage et de la collaboration semblent désormais être en compétition pour le titre de “Licence la plus énigmatique”.

Et tandis que le rideau se lève sur ces actes étonnants, les développeurs, les utilisateurs et la communauté open source dans son ensemble se demandent peut-être si tout cela est un rêve étrange, ou simplement une réalité nouvelle et ironique.

Bonus

Oracle à la rescousse de Linux ? Quelle blague!

Tue, 11 Jul 2023 06:00:00 +0200

Petit billet d’humeur, ça faisait longtemps

Oracle vient à la rescousse de Linux ? Quelle blague…

En 2018, j’écrivais un article intitulé L’open source bashing a encore de beaux jours devant lui, prémisse d’un de mes tout premiers talks. A PSES ensuite, en 2019, je donnais une de mes toutes premières conférences en tant que speaker intitulée “Le logiciel libre a-t-il de beaux jours devant lui ?”.

Dans cet article et ce talk, j’avais parlé des “super-vilains” de l’histoire, les géants du monde propriétaires.

Ceux qui étaient passés de l’ignorance du logiciel libre, à la moquerie, puis au combat. Et finalement du rachat de RedHat par IBM.

First they ignore you,

Then they laugh at you,

Then they fight you,

Then they buy you

RedHat verrouille des sources RHEL derrière un paywall

Aujourd’hui, rien n’a changé.

Les super-vilains cyniques sont les mêmes, ils changent juste alternativement de rôles dans le triangle de karpman.

Note: Si vous avez loupé cette news qui a pas mal chahuté le petit monde de l’OSS et du logiciel libre, je vous ai fait une petite compilation de liens en fin d’article.

IBM/RedHat tue CentOS en 2020 (alors que normalement le support de la 8 courrait pendant encore plusieurs années), puis utilise en juin 2023 “une faille” (selon Jeff Geerling) de la GPL pour empêcher les clones de RHEL.

Et comme la saison du troll semble ainsi ouverte, aujourd’hui Oracle fait semblant d’aider l’open source (juste pour troller IBM), tout en ayant été de l’autre côté de la barrière tout aussi récemment.

Oracle.com - Keep Linux Open and Free—We Can’t Afford Not To

Et au milieu de tout ça, Microsoft Loves Linux, bien entendu 😏

Bref, l’histoire de l’informatique est un éternel recommencement.

Addendum : SUSE

SUSE vient (aujourd’hui !) de rajouter un pavé dans la marre en annonçant forker RHEL et investissant plus de 10 millions de dollars dessus.

*SUSE Preserves Choice in Enterprise Linux by Forking RHEL with a $10+ Million Investment

SUSE is committed to working with the open source community to develop a long-term, enduring compatible alternative for RHEL and CentOS users. SUSE plans to contribute this project to an open source foundation, which will provide ongoing free access to alternative source code.

Merci à ceux qui me l’ont forwardé :)

Sources

Pour comprendre rapidement (mais faut aimer les vidéos)

Vidéo Adrien LinuxTricks - Edito Red Hat : Debrief autour de la “fermeture des sources”

Les différents billets de blogs

Ma conférence à PSES 2019 / BDX I/O 2019 (sur mon peertube)

redalert : gérer les incidents avec un bot Slack

Mon, 15 Jun 2020 06:40:00 +0000

Il y a quelques mois, j’ai vu passer cet article écrit par un SRE de chez ManoMano : Incident Management with a bot. Il a été pas mal partagé et il m’a beaucoup plus, car il me permettait de creuser 2 sujets qui m’intéressaient justement à ce moment-là : les bots slack et la gestion d’incidents.

Dans mon équipe actuelle, nous utilisons énormément Slack pour communiquer en interne. Au-delà du chit-chat quotidien, nous avons également pour habitude de créer des channels dédiés et d’y inviter les personnes concernées lors d’incidents sur la plateforme que nous administrons, de manière à centraliser les efforts entre les Ops, les Devs et les équipes support client.

L’idée de pouvoir avoir un tool permettant à la fois de nous éviter de gérer à la main ces incidents tout en restant dans Slack était hyper séduisante… Malheureusement, après avoir contacté l’auteur, celui-ci m’a confirmé qu’à l’heure actuelle, le tool de ManoMano n’était pas Open Source.

Moult déceptions.

Yet another standard

Clairement, j’étais grognon à l’idée de passer à côté d’un tool qui faisait EXACTEMENT ce que je voulais. Comme je n’aime pas réinventer la roue, je suis allé voir sur les Internets ce qui se fait ailleurs.

Grosso modo, la solution qui m’a le plus plu est un outil qui a été open sourcé par Netflix et qui s’appelle Dispatch.

Dispatch est un VRAI outil d’Incident Management, avec des workflows et de nombreuses interactions avec des outils tiers. C’est très très classe, il y a une doc superbe. Bref, c’est Netflix.

Mais ce n’était pas tout à fait ce que je voulais. Aujourd’hui, Dispatch est clairement overkill pour les besoins de l’équipe. A l’heure actuelle, un simple workflow « j’ouvre un channel, j’invite des gens, j’archive le channel » nous suffit. D’où l’idée du bot slack de ManoMano.

Make it so

Bon… ManoMano a pondu l’idée du bot slack… j’ai toujours eu envie d’écrire un bot slack… et je suis en train de me (re)former à Python. Vous me voyez venir ?

Et c’est ainsi que naquit Redalert, mon propre bot slack d’Incident Management (très… très très) basique.

Pour ceux qui ont un doute sur l’inspiration pour le nom, sachez que j’ai l’infâme défaut de n’avoir jamais joué à « Command and Conquer » (pas tapper), mais qu’en revanche je suis très fan de Star Trek.

A quoi ça ressemble ?

Assez de teasing, voilà à quoi ressemble l’outil une fois installé. Lorsqu’un incident arrive, n’importe qui peut écrire dans le channel slack « /incident open » et une fenêtre de dialogue va s’ouvrir dans Slack avec un certain nombre d’options.

Quand on tape « /incident open » dans un channel, voilà la popup qui s’ouvre

C’est simple (voire simpliste) mais efficace.

Ce que l’outil fait

Je ne vais pas vous copier-coller le contenu du README.md du projet, mais grosso modo les features actuelles (le « MVP » comme on dit dans le milieu) sont :

ouvrir une popup dans Slack via une commande « /incident open », permettant d’entrer un certain nombre d’informations puis d’ouvrir un channel Slack en fonction de ces paramètres
configurer soit même les différents niveaux d’incident possibles
ajouter de manière automatique une liste d’individus dans certains ou tous les niveaux d’incidents (de manière configurable)
lister tous les incidents ouverts et/ou fermés (archivés)
fermer un incident (en utilisant la fonction archiver de Slack)

Ce que l’outil ne fait pas (encore)

Idéalement, dans le futur j’aimerais ajouter les fonctionnalités suivantes (quelque part entre « un jour » et « jamais »).

Faciliter l’installation de redalert via une application packagée slack
ajouter de manière optionnelle une base externalisée des incidents pour permettre des analyses a posteriori
une gestion du « problem management » (au sens ITIL du terme, càd relier des incidents entre eux, entre autre)
interagir avec des systèmes tiers tels que PagerDuty (prévenir l’OPS en astreinte), Trello, Confluence (Postmortems), …
Permettre dans le dialog d’ouverture d’incident d’ajouter plusieurs personnes d’un coup (a priori pas techniquement possible pour l’instant dans l’API Slack)
Un vrai fichier de configuration custom qui remplace les valeurs par défaut du config.py pour ne pas avoir à le réécrire complètement.

Comment l’installer ?

Comme je suis sympa avec vous, j’ai mis à disposition sur le projet Github zwindler/redalert toute la documentation d’installation.

Actuellement, le projet est distribué de 3 manières :

les sources du code python, que vous pouvez lancer sur n’importe quelle machine disposant de python 3.6+ avec les modules (pip) slack et flask
une image Docker préconfigurée, disponible sur le Dockerhub
un Chart que vous pouvez déployer sur Kubernetes avec Helm

Tout est décrit pas à pas dans le README.md du projet.

Je pense que le plus important a été dit. Donc en attendant vos retours => Have fun :D

Bonus : comment ça marche ?

Je ne vais pas passer trop de temps là-dessus (quitte à faire un article un peu plus long dédié à ça une autre fois), mais l‘API mise à disposition par Slack est relativement bien documentée et il existe des modules dans la plupart des langages courants qui intègrent des méthodes pour toutes les appels qui existent sur l’API.

Autant dire que même pour un OPS, c’est accessible, si jamais vous avez une autre idée de bot slack en tête.

Le seul vrai souci que j’ai rencontré a été que les exemples donnés pour le sdk python du client Slack le sont dans 2 versions, et que les premiers exemples de code sur lesquels je suis tombé (les plus approchant de ce que je voulais faire) sont en version 1 alors que la version actuelle est la 2 (bien sûr…).

Le code source du projet en lui-même est relativement trivial. Mon serveur Flask écoute sur 3 URLs :

un /, notamment pour les healthchecks dans Kubernetes
un /incident qui reçoit toutes les commandes « /incident open|list|close » et qui redispatche ensuite en fonction du contexte
un /dialog qui, comme son nom laisse penser, permet de gérer le retour POST du dialog qui est popé après le /incident open

Bonus 2 : contribuer ?

Pour être parfaitement honnête, il y a peu de chance que je bosse énormément dessus. Ce projet a été développé sur mon temps perso initialement, en side project un peu bébête. Et même si au final, on a fini par l’adopter en production sur notre Slack pro, pour l’instant il nous suffit tel qu’il est.

Néanmoins, je suis plus qu’ouvert à toutes les propositions d’amélioration ou de contributions, dans le cas où cet outil vous plairait.

Cela se fera en best effort et sans aucune garantie, mais si on est d’accords sur ce point, moi ça me fera plaisir de savoir que ça peut être utile à quelqu’un !

Déléguer l’authentification Gitlab à Azure AD avec OAuth2

Tue, 14 May 2019 11:45:56 +0000

Gérer les comptes internes à Gitlab, c’est bof, le SSO, c’est mieux !

Dans le cadre de l’hébergement d’un nouveau serveur Gitlab, j’ai voulu intégrer notre base de compte existante, synchronisée dans Azure à l’aide de l’outil Azure AD, qui est le pendant « cloud » de l’Active Directory, bien connus de mes amis Windowiens (oui, il y en a). La plupart des applications savent aujourd’hui déléguer l’authentification à des fournisseurs tiers, généralement de type LDAP, via des protocoles tels que SAML(2) ou OAuth(2).

Cependant, bien que ces protocoles soient standards, leur implémentation dépend fortement du logiciel en question et il n’est pas toujours facile de s’y retrouver.

Pour faciliter cette opération, Azure a mis à disposition, directement dans Azure AD, des objets préconfigurés pour des milliers d’applications tierces. C’est comme ça qu’on peut implémenter, de manière simple et rapide, le SSO Active Directory avec les produits Atlassian (JIRA + Confluence), par exemple.

Tout commence dans Azure

Dans le portail Azure, ouvrir « Entreprise applications », puis cliquer sur « New Application »

Malheureusement pour nous, il n’y a pas de template pour Gitlab ! Il va falloir le faire à la main.

A noter, le principe déroulé dans ce tutoriel est valable pour n’importe quelle autre application supportant des mécanismes similaire. Il est possible de réutiliser un template utilisé pour un soft et le réadapter pour d’autres logiciels qui fonctionnent de la même façon. C’est juste une histoire de paramètres.

Le menu nous conseille donc de choisir « Non-gallery application », puisque nous ne trouvons pas Gitlab. Sauf que, bizarrement, il faut un compte Premium pour utiliser cette feature.

On se rabat donc sur « Application you’re developing ». C’est d’ailleurs ce que conseille d’utiliser la documentation de Gitlab. Sauf que, pas de chance non plus, ça ne marche plus comme ça, maintenant ;)

Créer une App registration pour Gitlab

Pour toutes les applications qui ne sont pas dans le store, on ne peut donc plus passer par les « Entreprise Applications ». On va donc créer une « App registration », qui n’est ni plus ni moins qu’un compte de service avec un ID et un (ou plusieurs) secrets.

Cliquer sur « New registration », puis lui donner un nom.

Sélectionner le type de comptes qui pourront accéder à cette application. Dans mon cas, il s’agit uniquement d’autoriser les comptes provenant de mon AD, mais on peut imaginer le cas d’une application ouverte en BtoB ou carrément ouverte à tout Internet.

Enfin, renseigner l’URL de callback, qui permettra à Azure de rediriger l’utilisateur qui s’est authentifié avec succès vers notre Gitlab.

We’ll return the authentication response to this URI after successfully authenticating the user. Providing this now is optional and it can be changed later, but a value is required for most authentication scenarios.

Dans le cas précis de Gitlab, cette URL aura la forme : mongitlab.example.org/users/auth/azure_oauth2/callback

Récupérer des valeurs qui intéressent Gitlab

Retourner ensuite dans l’overview de notre nouvelle « App registration ». Dans les détails, elle dispose d’un Application ID, aussi appelé Client ID et d’un Tenant ID :

On va maintenant créer un Secret. Pour les secrets, on peut choisir soit d’uploader un certificat (conseillé car plus sécurisé), ou de lui générer un mot de passe. Pour la simplicité de ce tutoriel, je vais créer un mot de passe pour notre application, mais je le répète, mieux vaut uploader un certificat.

On dispose maintenant de notre CLIENT_ID, notre TENANT_ID et de notre CLIENT_SECRET. Notez les bien, car une fois que la fenêtre sera fermée, il ne sera plus possible de relire à nouveau le secret et il faudra en générer un nouveau…

Ajouter des restrictions ou des fonctionnalités complémentaires

En fonction de votre niveau de licence pour Azure AD, vous aurez accès à plus ou moins de choses. Moi, je n’ai accès à pratiquement aucune feature, mais si vous avez mieux, vous aller pouvoir ajouter des options très pratiques telles que le self service (les utilisateurs peuvent demander eux même à avoir accès à l’application, et si c’est validé, ils sont ajouté dans le bon groupe) et aux autorisations/restrictions par groupes Azure AD.

Pour se faire, il faut RETOURNER dans les Entreprises Applications (#RollingEyes), puis chercher notre « App registration » qui y apparaît maintenant dans la liste (avec le filtre All applications).

Configuration de Gitlab

Gitlab ayant été installé avec les packages, la configuration se situe dans le fichier /etc/gitlab/gitlab.rb.

Dans le fichier de configuration, ajouter le bloc suivant en remplaçant les valeurs en majuscules par celles qu’on vient de récupérer :

gitlab_rails['omniauth_providers'] = [
{
"name" => "azure_oauth2",
"args" => {
"client_id" => "CLIENT_ID",
"client_secret" => "CLIENT_SECRET",
"tenant_id" => "TENANT_ID",
}
}
]

Rechargez ensuite Gitlab pour prise en compte de ce nouveau paramètre

sudo gitlab-ctl reconfigure
[...]
Running handlers complete
Chef Client finished, 13/637 resources updated in 26 seconds
gitlab Reconfigured!

Une boite d’authentification Azure Oauth2 devrait apparaître sous le login classique !! Youpi :)

Et voilà c’est fini… ou presque…

Vous avez maintenant ajouté du SSO et l’authentification via Azure AD pour l’accès à votre Gitlab ! On essaye de se connecter ?

Et Paf !!

Signing in using your Azure Oaut2 account without a pre-existing gitLab account is not allowed

En fait, c’est normal.

Par défaut, il n’est pas possible de s’authentifier avec Azure Oauth2 si un compte n’existe pas préalablement dans Gitlab, ce qui est quand même bien dommage si vous avez beaucoup de comptes à créer.

Deux cas de figure.

Soit vous ne souhaitez pas que n’importe qui dans votre AD puisse se connecter sans votre accord préalable

Dans ce cas là, ce cas vous est finalement assez favorable, puisque vous allez pouvoir explicitement dire qui peut ou ne peut pas se connecter. Si vous ne disposez pas des bonnes licences et que vous avez pas pu restreindre l’accès à un groupe d’utilisateurs, c’est une « solution » de contournement acceptable.

Cependant, pour éviter de créer à la main tous les comptes, il sera probablement préférable de les créer de manière automatique à l’aide de l’API Gitlab et même du très bon module Ansible gitlab_user :

- name: "Create Gitlab User"
gitlab_user:
server_url: "{{gitlab_api}}"
login_token: "{{token}}"
validate_certs: True
name: "Zwindler"
username: "zwindler"
password: "{{ 99999999 | random | to_uuid }}"
confirm: no
email: "zwindler@zwindler.fr"
state: present

Soit, à l’inverse, vous souhaitez que tous les utilisateurs de votre AD puissent avoir accès, sans pour autant devoir les ajouter uns par uns

Il existe alors des lignes sont à ajouter dans la configuration gitlab pour autoriser cette option :

gitlab_rails['omniauth_allow_single_sign_on'] = ['azure_oauth2']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['sync_profile_from_provider'] = ['azure_oauth2']
gitlab_rails['sync_profile_attributes'] = ['name', 'email']

D’un point de vue sécurité, c’est un peu moins bien puisque n’importe qui avec un compte pourra se connecter, sans que vous le sachiez.

Cependant, ce problème est un peu moins grave qu’il n’y parait puisque l’utilisateur sera logué mais n’aura accès à rien (ou juste ce qui est « public »).

Dans le cas d’un Gitlab d’entreprise, où tous les développeurs doivent pouvoir se connecter, cette seconde option me parait quasi obligatoire. C’est encore plus acceptable si vous avez pu restreindre l’accès au SSO par groupe dans Azure AD, comme indiqué plus haut.

Have fun :)

Sources

Suivez le lapin Orange – Intro et bonnes pratiques d’infra RabbitMQ

Tue, 16 Apr 2019 11:45:07 +0000

C’est quoi RabbitMQ ?

RabbitMQ® est un logiciel open source, développé par Pivotal. Il s’agit d’un message broker (bus/agent de messages), très simple à mettre en place, multiplateforme et multiprotocole (AMQP, MQTT, STOMP).

RabbitMQ est donc particulièrement adapté pour monter rapidement une architecture microservice, voire même IoT, nécessitant un bus de message pour garantir les communications entre les différentes briques de cette architecture.

C’est justement dans mon contexte pro : nous disposons d’une architecture logicielle aux composantes très différentes (microservices, machines outils connectées, …). Nous avons donc besoin de cette agilité, qu’on ne retrouve pas forcément dans les autres messages brokers, mais aussi de garanties et des contrôles sur les transports des messages que nous n’aurions pas forcément avec des API REST.

Architecture et bonnes pratiques

Voici à quoi ressemble l’architecture RabbitMQ que nous utilisons :

A première vue, c’est assez simple. Mais si vous vous demandez si nous n’aurions pas pu faire encore plus simple, alors cet article est fait pour vous ;).

AMQPS / WebMQTTS

Les plus observateurs d’entre vous auront peut être remarqués le « S » à la fin des deux protocoles que nous utilisons pour faire communiquer nos services entre eux :

AMQP / AMQPS
WebMQTT / WebMQTTS

Vous l’aurez sûrement deviné, il s’agit de la déclinaison non-sécurisée/sécurisée (chiffrée) de chacun de ces protocoles.

Par défaut dans RabbitMQ, les échanges ne sont pas chiffrés. Bien qu’il n’y ait pas de réponse universelle à la question « dois-je chiffrer l’ensemble de mes flux ? », l’Ops que je suis ne peux pas s’empêcher de répondre un grand OUI.

C’est particulièrement vrai dans notre cas, où une partie des flux transite par Internet, et l’autre transite à l’intérieur du réseau de notre cloud provider. L’ajout du chiffrement est obligatoire. Le risque d’espionnage, de détournement d’information, de Man in the Middle, sont suffisamment sérieux pour qu’on prenne le temps de configurer un chiffrement TLS.
Cependant, l’impact sur les performances globales de la plateforme est réel et devra être pris en compte lors du choix de l’architecture.

Comment activer le chiffrement TLS sur mes interfaces RabbitMQ ?

Tout se passe dans les fichiers de configuration. Il faudra déposer les fichiers de certificats (CA, certificat public et clé privée) et rajouter les lignes suivantes dans votre configuration :

[
{rabbit, [{ssl_options, [{cacertfile, /path/to/testca/cacert.pem"},
{certfile, /path/to/server_certificate.pem"},
{keyfile, /path/to/server_key.pem"},
{verify, verify_peer},
{fail_if_no_peer_cert, true}]}]}
].

Cependant, là aussi par défaut, il n’y a pas de restrictions sur les protocoles disponibles. Or, les failles sur SSL et TLS 1.0 de ces dernières années nous obligent à désactiver ces protocoles obsolètes (voire même TLS 1.1 aussi), ainsi que tous les ciphers non sécurisés, ce qui va nettement complexifier notre configuration :

%% -*- mode: erlang -*-
[
{ssl, [
{versions, ['tlsv1.2']}
]},
{rabbit, [
{ssl_listeners, [5672]},
{ssl_options, [
{cacertfile, /etc/rabbitmq/certs/cacert.pem"},
{certfile, /etc/rabbitmq/certs/cert.pem"},
{keyfile, /etc/rabbitmq/certs/key.pem"},
{versions, ['tlsv1.2']},
{ciphers, [
{ecdhe_ecdsa,aes_256_gcm,null,sha384},
{ecdhe_rsa,aes_256_gcm,null,sha384},
{ecdhe_ecdsa,aes_256_cbc,sha384,sha384},
{ecdhe_rsa,aes_256_cbc,sha384,sha384},
{ecdh_ecdsa,aes_256_gcm,null,sha384},
{ecdh_rsa,aes_256_gcm,null,sha384},
{ecdh_ecdsa,aes_256_cbc,sha384,sha384},
{ecdh_rsa,aes_256_cbc,sha384,sha384},
{dhe_rsa,aes_256_gcm,null,sha384},
{dhe_dss,aes_256_gcm,null,sha384},
{dhe_rsa,aes_256_cbc,sha256},
{dhe_dss,aes_256_cbc,sha256}
]},
{verify, verify_peer},
{fail_if_no_peer_cert, false}]}
]}
].

A noter, depuis la version 3.7 de RabbitMQ (dernière version en date, la 3.8 sort bientôt), le format de la configuration a changé (erlang => sysctl) pour être plus lisible et plus simple à automatiser. Cependant, à ma connaissance, il n’est pas possible de configurer l’ensemble des limitations de ciphers/protocoles.

« While the new config format is more convenient for humans to edit and machines to generate, it is also relatively limited compared to the classic config format used prior to RabbitMQ 3.7.0. »

Et pourquoi 3 nœuds et pas juste un, au milieu ?

Cette question est volontairement provocatrice ;-p.

Comme tout service informatique, les objectifs en terme d’indisponibilités tendent forcément vers 0. Un moyen classique d’approcher cet objectif est de redonder les composants informatiques, pour éviter tout Single Point of Failure.

Ça tombe très bien, puisque RabbitMQ propose nativement un mécanisme de clustering. Et comme dans tout cluster disposant d’un mécanisme de vote/d’élection, il est fortement conseillé d’avoir un nombre impair de nodes pour résoudre les cas de split brain (la majorité l’emporte en cas de partition réseau). D’où les 3 nœuds (mais on peut en avoir 5, 7, …).

Le clustering dans RabbitMQ, comment ça marche ?

Pour simplifier notre vie, le cluster RabbitMQ agit de telle sorte que tous les objets logiques (utilisateurs, queues, …), où qu’ils soient, sont connus et adressables depuis tous les membres (attention, je n’ai pas dis répliqués, on y reviendra).

Ça, c’est super pratique. Quel que soit le nœud qu’on va contacter, si la queue est présente sur un autre serveur RabbitMQ, le message sera redistribué de manière transparente vers le nœud qui possède la queue.

Pour « masquer » la complexité induite par l’ajout de serveurs RabbitMQ supplémentaires, on a donc juste à ajouter un loadbalancer en amont du cluster. Le développeur envoie simplement le message au loadbalancer. Peu importe le nœud sur lequel le message sera réellement envoyé ensuite, il sera transféré instantanément.

Comment démarrer un cluster ?

Sans rentrer dans le détail de toutes les opérations nécessaires pour bootstrapper un cluster, ce qu’il faut savoir c’est que tous les nœuds doivent évidemment pouvoir se contacter et si possible être relativement proches (en terme de latence).

Les serveurs RabbitMQ doivent être configurés de manière à partager une même passphrase dans le fichier /var/lib/rabbitmq/.erlang.cookie, et on doit ensuite joindre un des noeuds depuis les deux autres avec la commande suivante :

#sur le node rabbit2, puis rabbit3
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@rabbit1

la documentation qui est très bien écrite.

Maintenant, on est hautement disponibles ?

Vous vous dites : « Chouette ! J’ai un cluster ! Je suis hautement disponible ! »

Et bien… non.

Un point pouvant induire une grande confusion dans RabbitMQ est la terminologie « cluster RabbitMQ ». Le fait de monter un cluster laisse penser que tout devient automatiquement hautement disponible.

Or, en réalité, comme je l’ai écris plus haut, il s’agit uniquement de rendre accessible et addressable l’ensemble des objets logiques depuis tous les nœuds. En revanche, les queues, et a fortiori leur contenu, ne sont physiquement présentes que sur un nœud et un seul.

Ainsi, si un nœud du cluster disparaît, toutes les queues qu’il possède seront détruites (si elles sont Transient), ou bloquées jusqu’à ce que le nœud soit de nouveau disponible (si elles sont Durable).

Dans tous les cas, il y aura interruption de service et éventuellement perte de messages, malgré le fait qu’on ait un cluster !

Haute disponibilité des queues

Heureusement, il est également possible de répliquer les queues et leur contenu sur une partie ou la totalité des nœuds disponibles dans le cluster. On dispose alors d’une queue principale et de miroirs qui pourront prendre le relai en cas de défaillance d’un nœud.

Ceci est configurable, par queue ou par policy (applicable à toutes les queues correspondant au pattern), avec les options ha-mode, ha-params et ha-sync-mode.

ha-mode
- all : synchronisera votre queue sur des miroirs présents sur tous les nœuds du cluster
- exactly : permettra d’indiquer, en positionnant également un nombre sur ha-params, le nombre exact de nœuds sur lesquels les queues sont répliquées
- nodes : synchronisera des miroirs sur une liste de nœuds explicitement nommés
ha-sync-mode
- automatic : en cas d’apparition d’un nouveau miroir, tous les messages sont synchronisés immédiatement
- manual : en cas d’ajout d’un nouveau miroir, seul les nouveaux messages sont synchronisés

Attention au mode automatic, surtout en conjugaison avec le ha-mode à all. En effet, si ce mode est plus sécurisé puisqu’il garantie que tous les nœuds ont bien la totalité des messages, il a aussi l’inconvénient de bloquer les queues « à synchroniser » (tant que l’ensemble des messages ne sont pas répliqués partout).
Dernier point d’attention, au même titre que le chiffrement, l’ajout de la haute disponibilité (et du clustering, dans une moindre mesure) a un impact sur les performances globales de la plateforme.

Conclusion

RabbitMQ est un outil puissant et extrêmement simple à mettre en place. On peut le lancer et obtenir un broker de message robuste avec une simple commande « docker run ».

docker run -d --hostname my-rabbit --name some-rabbit rabbitmq:3

Pour autant, dans un environnement de production avec des objectifs en terme de haute disponibilité, il n’est pas si trivial de trouver les bons paramètres. Certains nécessiteront un peu de recherche et de configuration erlang, d’autres nécessiteront un peu de benchmarking et de tuning, si les performances commencent à devenir un problème.

Pour cette seconde catégorie, j’y reviendrai dans un autre article. Cependant, sachez quand même qu’on peut traiter sans trop de difficulté des milliers de messages par secondes, même avec des machines disposant de peu de CPU. Vous aurez surement le temps de voir venir ;).

Migration mongoDB à chaud depuis une 3.4 vers une 4.0 (replicaSet)

Tue, 05 Feb 2019 11:45:02 +0000

MongoDB

Depuis peu, j’administre des bases de données MongoDB !

Pour le fun (et ceux qui ne connaissent pas), la définition qu’en donne Wikipedia :

MongoDB (de l’anglais humongous qui peut être traduit par « énorme ») est un système de gestion de base de données orientée documents, répartissable sur un nombre quelconque d’ordinateurs et ne nécessitant pas de schéma prédéfini des données. Il est écrit en C++. Le serveur et les outils sont distribués sous licence AGPL{.new}, les pilotes sous licence Apache et la documentation sous licence Creative Commons. Il fait partie de la mouvance NoSQL.

Comme dans la vie de tout projets, on installe un logiciel, et sur le moment ça nous suffit, on est contents.

Mais arrive le jour fatidique où le logiciel est obsolète et il faut mettre à jour la base. Sans aucun créneau de maintenance pour le faire bien entendu car elles sont évidemment utilisées en production ;-).

Prérequis

Bon point pour moi, je n’ai pas fais l’erreur d’avoir une base de données mongoDB « standalone ». Je dispose de cluster de bases de données MongoDB (replicaSet, dans la terminologie mongo), que je vais donc pouvoir mettre à jour à chaud. Ça sera juste un peu plus long ;-).

3.4 => 4.0 = pas possible

Bon quand même, fallait bien que je tombe dans le piège.

La version majeure 3.4 (la dernière en date est la .19) ne peut pas directement être mise à jour vers une 4.0. Comme c’est une majeure, il faut passer d’abord par la majeure suivante, la 3.6 (c’est classique comme limitation).

On passe en 3.6 alors

Pour me simplifier la vie, j’ai un mini playbook Ansible qui me permet d’ajouter les dépôts en fonction de la version que je veux.

- name: Prepare mongodb upgrade
hosts: all
vars:
#mongo_repo : "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse"
mongo_repo: "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.6 multiverse"
#mongo_repo: "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.0 multiverse"
tasks:
- name: "Add mongodb repository key"
apt_key:
keyserver: keyserver.ubuntu.com
id: "{{item}}"
state: present
loop:
- 0C49F3730359A14518585931BC711F9BA15703C6
- 2930ADAE8CAF5059EE73BB4B58712A2291FA4AD5
- 9DA31620334BD75D9DCB49F368818C72E52529D4
- name: "Add mongodb repository"
apt_repository:
repo: "{{ mongo_repo }}"
state: present
update_cache: yes

Clairement, on peut faire plus propre. Ici, c’est du oneshot sur quelques machines Ubuntu, donc je n’ai pas automatisé plus que ça. Mais si vous avez plus de machines à faire que moi, je vous invite à le raffiner un peu, par exemple en ajoutant le repo et la clé en fonction de la version donnée en paramètre.

ansible-playbook -i inventory/prod/mongo-prod prepare_mongo_upgrade.yml -b

Mise à jour des binaires vers la 3.6

Maintenant qu’on a bien les dépôts pour la version 3.6, on peut mettre à jour nos serveurs. Idéalement si on avait de nombreux clusters à migrer, il faudrait le faire avec un playbook Ansible (ou autre) qui passe sur les serveurs, uns par uns, les mets à jour et les redémarre.

Cependant, pour simplifier l’explication, je vais laisser la procédure telle quelle et tout faire à la main.

Sur les SECONDARY, uns par uns, mettre à jour manuellement le serveur, puis le redémarrer :

apt-get update
apt-get upgrade mongodb-org-server mongodb-org-shell
[...]
Unpacking mongodb-org-server (3.6.10) over (3.4.19) ...
[...]
systemctl restart mongod

Vérifier que tout fonctionne à nouveau après redémarrage

mongo
MongoDB shell version v3.6.10
connecting to: mongodb://127.0.0.1:27017/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("17272d4e-ecd0-49c2-a672-8804227ab0e4") }
MongoDB server version: 3.6.10
rs:SECONDARY>

Puis, se connecter sur le PRIMARY, et lui passer la commande suivante (qui va avoir pour effet de le rétrograder proprement et temporairement en tant que SECONDARY) :

$> mongo
rs:PRIMARY> use admin
switched to db admin
rs:PRIMARY> db.auth('myadmin', 'myawesomepassword')
1
rs:PRIMARY> rs.stepDown(180)
[...]
2019-01-25T15:23:02.520+0000 I NETWORK [thread1] trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2019-01-25T15:23:02.548+0000 I NETWORK [thread1] reconnect 127.0.0.1:27017 (127.0.0.1) ok
rs:SECONDARY>

Et enfin, mettre à jour manuellement le serveur de la même manière que les autres :

apt-get update
apt-get upgrade mongodb-org-server mongodb-org-shell
systemctl restart mongod

Compatibilité 3.6

Ici, je viens de faire la migration de 3.4 vers 3.6. En réalité, ce n’est pas complètement terminé. L’ensemble des binaires ont beau être en version 3.6, la base elle, reste en « compatibilité » 3.4.

Pour s’en assurer, une connexion sur n’importe quel serveur permet de le vérifier :

$> mongo
rs:SECONDARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.4" }, "ok" : 1 }

On va donc aller sur le nœud PRIMARY pour passer la base en compatibilité 3.6 (le seul prérequis est qu’une majorité de serveurs aient leurs binaires mis à jour en 3.6 et redémarrés) :

$> mongo
MongoDB shell version v3.6.10
connecting to: mongodb://127.0.0.1:27017/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("aaa-aaa-aaa-aaa-aaa") }
MongoDB server version: 3.6.10
rs:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.4" }, "ok" : 1 }
rs:PRIMARY> use admin
switched to db admin
rs:PRIMARY> db.auth('myadmin', 'myawesomepassword')
1
rs:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )
{ "ok" : 1 }
rs:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.6" }, "ok" : 1 }

OK ! on a fait la moitié du chemin…

Mettre à jour le ReplicaSet dans la version 1

Différence notable entre la version 3.4 et la version 3.6, c’est la façon dont sont gérés les replicaSets. La version 3.6 introduit la version 1 du protocol des replicaSet, et empêche les précédents clusters déclarés de fonctionner.
Il est donc nécessaire de mettre à jour le protocole avant de mettre à jour en 4.0.

Ouvrir un shell mongo sur le PRIMARY, et modifier la configuration du replicaset (rs) :

cfg = rs.conf();
cfg.protocolVersion=1;
rs.reconfig(cfg);

Mise à jour des binaires vers la 4.0

Bon, je ne vais pas vous refaire l’affront de vous copier coller la procédure de mise à jour : maintenant qu’on a mis à jour la version du replicaSet, c’est la même.

Pour rappel :

Relancer le playbook pour ajouter le dépôt de la version 4.0 (décommenter la ligne 4.0)
Mise à jour des serveurs SECONDARY puis redémarrage du serveur
Step down du PRIMARY
Mise à jour du PRIMARY devenu SECONDARY après le stepdown, puis redémarrage du serveur
Mise à niveau de la compatibilité de la base en 4.0

rs:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )
{
"ok" : 1,
[...]
}
rs:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{
"featureCompatibilityVersion" : {
"version" : "4.0"
},
[...]
}

Et voilà, votre cluster est « up-to-date », après 2 upgrades de versions majeures et sans aucune interruption de service. Alors, comme on dit chez moi :

Encore une victoire de Canard !

source : player.ina.fr/player/embed/PUB417943064/1/1b0bd203fbcd702f9bc9b10ac3d0fc21

logiciel on Zwindler's Reflection

Planifier les posts de mon blog Hugo sur Clever Cloud

Suite de la migration

Adaptations

(Fail to) hack the template

Migration du blog sur Clever Cloud

It’s groundhog migration day, again

Prérequis

Création de l’application

Déployer notre code

Et avec clever deploy ?

Conclusion

D’open source à BullShit Licence (BSL)

Résumé des épisodes précédents

RHEL ouvre une brèche, l’open source se referme

Moi je l’aime bien la MPL…

Hashi, c’est fini

Conclusion (rédigée par ChatGPT, pour le lulz)

Bonus

Oracle à la rescousse de Linux ? Quelle blague!

Petit billet d’humeur, ça faisait longtemps

RedHat verrouille des sources RHEL derrière un paywall

Addendum : SUSE

Sources

redalert : gérer les incidents avec un bot Slack

Yet another standard

Make it so

A quoi ça ressemble ?

Ce que l’outil fait

Ce que l’outil ne fait pas (encore)

Comment l’installer ?

Bonus : comment ça marche ?

Bonus 2 : contribuer ?

Déléguer l’authentification Gitlab à Azure AD avec OAuth2

Gérer les comptes internes à Gitlab, c’est bof, le SSO, c’est mieux !

Tout commence dans Azure

Créer une App registration pour Gitlab

Récupérer des valeurs qui intéressent Gitlab

Ajouter des restrictions ou des fonctionnalités complémentaires

Configuration de Gitlab

Et voilà c’est fini… ou presque…

Soit vous ne souhaitez pas que n’importe qui dans votre AD puisse se connecter sans votre accord préalable

Soit, à l’inverse, vous souhaitez que tous les utilisateurs de votre AD puissent avoir accès, sans pour autant devoir les ajouter uns par uns

Sources

Suivez le lapin Orange – Intro et bonnes pratiques d’infra RabbitMQ

C’est quoi RabbitMQ ?

Architecture et bonnes pratiques

AMQPS / WebMQTTS

Comment activer le chiffrement TLS sur mes interfaces RabbitMQ ?

Et pourquoi 3 nœuds et pas juste un, au milieu ?

Le clustering dans RabbitMQ, comment ça marche ?

Comment démarrer un cluster ?

Maintenant, on est hautement disponibles ?

Haute disponibilité des queues

Conclusion

Migration mongoDB à chaud depuis une 3.4 vers une 4.0 (replicaSet)

MongoDB

Prérequis

3.4 => 4.0 = pas possible

On passe en 3.6 alors

Mise à jour des binaires vers la 3.6

Compatibilité 3.6

Mettre à jour le ReplicaSet dans la version 1

Mise à jour des binaires vers la 4.0

Sources

Et avec `clever deploy` ?